Procedure consigliate per la sicurezza: protezione avanzata di Microsoft Entra SDK per AgentID

Questa guida fornisce procedure consigliate complete per la configurazione della sicurezza e la protezione avanzata per la distribuzione e l'uso sicuro di Microsoft Entra SDK per AgentID negli ambienti di produzione. Include controlli di sicurezza essenziali, tra cui isolamento della rete, gestione delle credenziali, convalida dei token, sicurezza del runtime e monitoraggio per garantire che la distribuzione dell'SDK segua le procedure consigliate per la sicurezza.

È sicuro eseguire l'SDK?

Microsoft Entra SDK per AgentID è progettato tenendo presente la sicurezza, ma la sicurezza dipende dalle procedure di configurazione e distribuzione appropriate. Seguire queste procedure consigliate per garantire una distribuzione sicura:

Sicurezza di rete

L'isolamento della rete è fondamentale per proteggere le operazioni di autenticazione. Microsoft Entra SDK per AgentID deve essere eseguito entro limiti attendibili con controlli di accesso rigorosi e filtri completi del traffico. Sono incluse l'associazione localhost-only, la comunicazione interna dei pod e le politiche di rete che impediscono l'accesso non autorizzato agli endpoint di autenticazione.

Limitare l'accesso all'SDK

Configurare Kestrel per l'ascolto solo in localhost per impedire l'accesso alla rete esterna agli endpoint di autenticazione:

containers:
- name: sidecar
  image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
  env:
  - name: Kestrel__Endpoints__Http__Url
    value: "http://127.0.0.1:5000"

In alternativa, usare il filtro host di Kestrel con AllowedHosts per limitare l'accesso:

containers:
- name: sidecar
  image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
  env:
  - name: AllowedHosts
    value: "localhost;127.0.0.1"

Usare Pod-Local per la comunicazione

Configurare l'applicazione per comunicare con Microsoft Entra SDK per AgentID tramite localhost per garantire che il traffico rimanga all'interno dello stesso pod e non attraversi la rete:

containers:
- name: app
  env:
  - name: SIDECAR_URL
    value: "http://localhost:5000" # Pod-local communication only

Non esporre mai tramite LoadBalancer o Ingress (ciò consente l'acquisizione di token non autorizzati dall'esterno del limite attendibile):

# WRONG - exposes Microsoft Entra SDK for AgentID publicly
apiVersion: v1
kind: Service
metadata:
  name: sidecar-service
spec:
  type: LoadBalancer # Exposes SDK publicly - INSECURE
  selector:
    app: myapp
  ports:
  - port: 5000

Gestione delle credenziali

La gestione sicura delle credenziali è fondamentale per la sicurezza dell'SDK. Usare le identità gestite quando possibile per eliminare i segreti e seguire il principio dei privilegi minimi durante la configurazione delle credenziali di autenticazione.

Preferire l'identità del Workload per i container

Usa l'identità del carico di lavoro di Azure AD per le distribuzioni containerizzate (AKS) per eliminare completamente i segreti e garantire una gestione sicura delle credenziali con la proiezione di token basati su file.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myapp-sa
  annotations:
    azure.workload.identity/client-id: "<managed-identity-client-id>"

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: myapp-sa
      containers:
      - name: sidecar
        image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
        env:
        - name: AzureAd__ClientId
          value: "<web-api-client-id>"
        
        # Workload Identity credentials - uses file-based token projection
        - name: AzureAd__ClientCredentials__0__SourceType
          value: "SignedAssertionFilePath"

Vantaggi: l'identità del carico di lavoro elimina la necessità di archiviare o aggiornare i segreti, fornendo una gestione automatizzata delle credenziali, integrazione con Azure RBAC e una tracciabilità completa delle attività di audit. Il token viene proiettato automaticamente nel pod dal webhook di identità del carico di lavoro e l'SDK lo legge usando il SignedAssertionFilePath tipo di credenziale. Questo approccio riduce significativamente i rischi per la sicurezza e il sovraccarico operativo rispetto all'autenticazione basata su segreti tradizionale.

Nota: per le macchine virtuali di Azure e i servizi app (ambienti non in contenitori), usare invece identità gestite assegnate dal sistema o dall'utente con il SignedAssertionFromManagedIdentity tipo di credenziale. Per altre informazioni, vedere Usare l'identità gestita.

Usare i certificati invece dei segreti

Preferire i certificati per l'autenticazione quando non è possibile evitare segreti client. I certificati offrono una sicurezza più avanzata rispetto ai segreti client perché usano la crittografia a chiave pubblica e sono più difficili da estrarre o usare in modo improprio. Archiviare i certificati in Azure Key Vault per la gestione centralizzata e il rinnovo automatico:

- name: AzureAd__ClientCredentials__0__SourceType
  value: "KeyVault"
- name: AzureAd__ClientCredentials__0__KeyVaultUrl
  value: "https://your-keyvault.vault.azure.net"
- name: AzureAd__ClientCredentials__0__KeyVaultCertificateName
  value: "your-cert-name"

Vantaggi: Azure Key Vault offre una gestione centralizzata dei certificati con rotazione automatizzata, criteri di accesso e controllo completo, garantendo al tempo stesso che i certificati non siano mai incorporati nelle immagini del contenitore. Per altre informazioni, vedere Usare i certificati per l'autenticazione.

Archiviare i segreti in modo sicuro

I Secrets di Kubernetes sono un'opzione adatta per l'archiviazione dei segreti del client se le identità o i certificati gestite non sono un'opzione, assicurandosi però che i segreti siano crittografati a riposo e che l'accesso sia strettamente controllato.

apiVersion: v1
kind: Secret
metadata:
  name: app-cert
type: Opaque
data:
  certificate.pfx: <base64-encoded-pfx>
  certificate.password: <base64-encoded-password>

---
containers:
- name: sidecar
  volumeMounts:
  - name: cert-volume
    mountPath: /certs
    readOnly: true
  env:
  - name: AzureAd__ClientCredentials__0__SourceType
    value: "Path"
  - name: AzureAd__ClientCredentials__0__CertificateDiskPath
    value: "/certs/certificate.pfx"
  - name: AzureAd__ClientCredentials__0__CertificatePassword
    valueFrom:
      secretKeyRef:
        name: app-cert
        key: certificate.password

volumes:
- name: cert-volume
  secret:
    secretName: app-cert
    items:
    - key: certificate.pfx
      path: certificate.pfx
    defaultMode: 0400  # Read-only for owner

Segreti client (evitare, se possibile)

Se è necessario usare i segreti client, implementare misure di sicurezza aggiuntive per ridurre al minimo i rischi. I segreti client sono meno sicuri delle identità gestite o dei certificati, quindi richiedono una protezione aggiuntiva, inclusi brevi periodi di scadenza, archiviazione sicura con crittografia dei dati inattivi, accesso limitato tramite il controllo degli accessi in base al ruolo e pianificazioni frequenti di rotazione. Non archiviare mai segreti in immagini contenitore o variabili di ambiente visibili nei manifesti della distribuzione:

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
stringData:
  client-secret: "<your-client-secret>"

---
containers:
- name: sidecar
  env:
  - name: AzureAd__ClientCredentials__0__SourceType
    value: "ClientSecret"
  - name: AzureAd__ClientCredentials__0__ClientSecret
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: client-secret

Sicurezza dei token

La sicurezza dei token garantisce che solo i token con ambito appropriato vengano accettati ed elaborati dall'SDK. Implementare la convalida dei token, i requisiti di ambito e i controlli dei destinatari per impedire l'accesso non autorizzato e limitare l'uso improprio dei token.

Abilitare la convalida dell'ambito

Richiedi ambiti specifici per i token in ingresso (spazi separati):

- name: AzureAd__Scopes
  value: "access_as_user"

Imposta gruppo di destinatari appropriato

Configurare il gruppo di destinatari previsto per la convalida dei token:

- name: AzureAd__Audience
  value: "api://your-api-id"

Convalidare i token prima dell'uso

Chiamare sempre /Validate prima di accettare gli token utente.

GET /Validate
Authorization: Bearer <user-token>

Sicurezza del runtime

I controlli di sicurezza di runtime proteggono il contenitore SDK dalla modifica, dall'escalation dei privilegi e dall'accesso non autorizzato alle funzionalità. Configurare il contenitore per l'esecuzione con privilegi minimi e file system di sola lettura per ridurre la superficie di attacco.

Filesystem di root di sola lettura

Impedire la modifica del file system del contenitore:

securityContext:
  readOnlyRootFilesystem: true

Criteri di sicurezza dei pod

Applicare gli standard di sicurezza:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: sidecar-psp
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
  - ALL
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'MustRunAs'
  fsGroup:
    rule: 'MustRunAs'
  readOnlyRootFilesystem: true

Registrazione e monitoraggio

La registrazione e il monitoraggio efficaci consentono di rilevare anomalie, risolvere i problemi e gestire i audit trail per la conformità. Configurare i livelli di registrazione appropriati per l'ambiente e implementare probe di integrità per assicurarsi che l'SDK funzioni come previsto.

Configurare la registrazione appropriata

Ambiente di produzione:

- name: Logging__LogLevel__Default
  value: "Warning"
- name: Logging__LogLevel__Microsoft.Identity.Web
  value: "Information"

Ambiente di sviluppo (dettagliato):

- name: Logging__LogLevel__Default
  value: "Debug"
- name: ASPNETCORE_ENVIRONMENT
  value: "Development"

Abilitare il monitoraggio dello stato

Configurare le verifiche di vitalità e prontezza:

livenessProbe:
  httpGet:
    path: /health
    port: 5000
  initialDelaySeconds: 10
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /health
    port: 5000
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3

Elenco di controllo delle procedure consigliate

Usare questo elenco di controllo completo per garantire che la distribuzione dell'SDK segua tutte le procedure di sicurezza consigliate in rete, credenziali, token, runtime e dimensioni di monitoraggio.

Rete:

• [ ] SDK è in ascolto solo su localhost/127.0.0.1
• [ ] Mai esposto tramite LoadBalancer o Ingress
• [ ] I criteri di rete limitano l'accesso esterno
• [ ] HTTPS/TLS per la comunicazione esterna

Credenziali:

• [ ] Usare Workload Identity per i contenitori (AKS, Kubernetes, Docker) con SignedAssertionFilePath
• [ ] Usare l'identità gestita per macchine virtuali e servizi app con SignedAssertionFromManagedIdentity
• [ ] Preferire i certificati ai segreti
• [ ] Segreti archiviati nel sistema di gestione sicura
• [ ] Rotazione regolare delle credenziali

Token:

• [ ] Abilitata la convalida dell'ambito
• [ ] Convalida del gruppo di destinatari configurata
• [ ] Token convalidati prima dell'uso

Runtime:

• Il contenitore viene eseguito come utente non root
• [ ] File system radice di sola lettura
• [ ] Contesto di sicurezza applicato
• [ ] Set di limiti delle risorse

Monitoraggio:

• [ ] Configurazione della registrazione appropriata
• [ ] Verifiche dello stato abilitate
• [ ] Registrazione di controllo abilitata
• [ ] Avvisi configurati

Modelli di sicurezza comuni

Le implementazioni di riferimento illustrano come combinare più controlli di sicurezza in modelli di distribuzione coesi. Questi modelli fungono da modelli per le distribuzioni di produzione in vari modelli di minaccia.

Distribuzione ad alta sicurezza

apiVersion: v1
kind: ServiceAccount
metadata:
  name: secure-app-sa
  annotations:
    azure.workload.identity/client-id: "<managed-identity-id>"

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: secure-app-sa
      securityContext:
        fsGroup: 2000
      containers:
      - name: sidecar
        image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
        ports:
        - containerPort: 5000
        env:
        - name: Kestrel__Endpoints__Http__Url
          value: "http://127.0.0.1:5000"
        - name: AzureAd__TenantId
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: tenant-id
        - name: AzureAd__ClientId
          value: "<managed-identity-client-id>"
        securityContext:
          runAsNonRoot: true
          runAsUser: 1000
          readOnlyRootFilesystem: true
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "250m"
        livenessProbe:
          httpGet:
            path: /health
            port: 5000
          initialDelaySeconds: 10
          periodSeconds: 10

Ruotare regolarmente le credenziali

La rotazione delle credenziali riduce la finestra di opportunità per gli utenti malintenzionati se le credenziali vengono perse o compromesse. La frequenza di rotazione dipende dal tipo di credenziale e dai criteri di sicurezza dell'organizzazione:

• Segreti client: ogni 90 giorni (raccomandato)
• Certificati: prima della scadenza, in genere ogni 1-2 anni
• Chiavi per le richieste HTTP firmate (SHR): seguire i criteri di sicurezza dell'organizzazione

Indicazioni sull'implementazione: usare Azure Key Vault con funzionalità di rotazione automatizzate o integrare i gestori segreti esterni (ad esempio Sealed Secrets) nella pipeline di distribuzione. Ciò riduce al minimo l'intervento manuale e garantisce pianificazioni di rotazione coerenti.

Risposta alle credenziali compromesse

Se si sospetta che le credenziali siano state compromesse, seguire questa procedura immediatamente per contenere l'evento imprevisto e impedire l'accesso non autorizzato:

1. Revocare le credenziali compromesse in Microsoft Entra ID : rimuovere le credenziali dalla registrazione dell'applicazione per bloccare immediatamente l'uso.
2. Genera nuove credenziali : creare nuovi segreti client o certificati in Microsoft Entra ID per sostituire quelli compromessi.
3. Aggiornare il sistema di gestione dei segreti : archiviare le nuove credenziali nei segreti Kubernetes o in Azure Key Vault con i controlli di accesso appropriati.
4. Ridistribuire i contenitori SDK : aggiornare le distribuzioni per usare le nuove credenziali, assicurandosi che tutte le istanze in esecuzione rilevino le modifiche.
5. Esaminare i log di accesso : controllare i log di controllo di Monitoraggio di Azure e Kubernetes per verificare la presenza di richieste di token non autorizzate o attività sospette durante la finestra di compromissione.
6. Documentare l'evento imprevisto : registrare i dettagli dell'evento imprevisto (quando è stato individuato, come è accaduto, cosa è stato eseguito) e seguire le procedure di risposta agli eventi imprevisti dell'organizzazione per evitare la ricorrenza.

Vedere anche

• Guida all'installazione
• Informazioni di riferimento sulla configurazione
• Informazioni di riferimento sugli endpoint
• Risoluzione dei problemi