Partager via

Meilleures pratiques de sécurité : renforcement du Kit de développement logiciel (SDK) Microsoft Entra pour AgentID

Ce guide fournit une configuration de sécurité complète et des meilleures pratiques de renforcement pour le déploiement et l’exploitation sécurisés du Kit de développement logiciel (SDK) Microsoft Entra pour AgentID dans les environnements de production. Il couvre les contrôles de sécurité essentiels, notamment l’isolation réseau, la gestion des informations d’identification, la validation des jetons, la sécurité du runtime et la surveillance pour garantir que votre déploiement du KIT de développement logiciel (SDK) suit les meilleures pratiques de sécurité.

Caution

L’API Microsoft Entra SDK pour AgentID ne doit jamais être accessible publiquement. Elle ne doit être accessible que par les applications au sein de la même limite d’approbation (par exemple, le même pod, le même réseau virtuel). Par défaut, les hôtes autorisés sont localhost. Exposer cette API publiquement peut activer l’acquisition de jetons non autorisée, ce qui constitue un risque de sécurité critique. Notez également que toutes les applications au sein de la même limite d’approbation ont accès à cette API. Assurez-vous que chaque application dans ce périmètre est approuvée et correctement sécurisée.

Est-il sûr d’exécuter le Kit de développement logiciel (SDK) ?

Le Kit de développement logiciel (SDK) Microsoft Entra pour AgentID est conçu avec une sécurité à l’esprit, mais sa sécurité dépend des bonnes pratiques de configuration et de déploiement. Suivez ces bonnes pratiques pour garantir un déploiement sécurisé :

  • Exécuter uniquement dans des environnements conteneurisés
  • Restreindre l’accès à localhost/pod-internal uniquement
  • Utiliser des stratégies réseau Kubernetes
  • Stocker les informations d’identification de manière sécurisée (Key Vault, Secrets)
  • Exécuter en tant qu'utilisateur non-root
  • Activer la journalisation d’audit

Sécurité réseau

L’isolation réseau est essentielle pour protéger les opérations d’authentification. Le Kit de développement logiciel (SDK) Microsoft Entra pour AgentID doit s’exécuter dans des limites approuvées avec des contrôles d’accès stricts et un filtrage complet du trafic. Cela inclut la liaison uniquement sur localhost, la communication interne dans les pods et les stratégies réseau qui empêchent l’accès non autorisé aux points d'accès d'authentification.

Restreindre l’accès au Kit de développement logiciel (

Configurez Kestrel pour écouter uniquement sur localhost uniquement pour empêcher l’accès au réseau externe aux points de terminaison d’authentification :

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"

Vous pouvez également utiliser le filtrage de l’hôte de Kestrel avec AllowedHosts pour restreindre l’accès :

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

Utiliser la communication locale au niveau du Pod

Configurez votre application pour communiquer avec le Kit de développement logiciel (SDK) Microsoft Entra pour AgentID via localhost pour vous assurer que le trafic reste dans le même pod et ne traverse pas le réseau :

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

Ne jamais exposer via LoadBalancer ou Ingress (cela permettrait l'obtention de jetons non autorisée depuis l'extérieur des limites approuvées) :

# 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

Gestion des identifiants

La gestion des informations d’identification sécurisées est fondamentale pour la sécurité du Kit de développement logiciel (SDK). Utilisez des identités managées dans la mesure du possible pour éliminer les secrets et suivez le principe du moindre privilège lors de la configuration des informations d’identification d’authentification.

Privilégiez l'identité de la charge de travail pour les conteneurs

Utilisez l’identité de charge de travail Azure AD pour les déploiements en conteneur (AKS) pour éliminer entièrement les secrets et garantir la gestion sécurisée des informations d’identification avec une projection de jetons basée sur des fichiers :

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"

Avantages : l’identité de charge de travail élimine la nécessité de stocker ou de faire pivoter les secrets tout en fournissant la gestion automatique des informations d’identification, l’intégration RBAC Azure et une piste d’audit complète. Le jeton est automatiquement injecté dans le pod par le webhook d'identité de charge de travail, et le SDK le lit en utilisant le type d'informations d'identification SignedAssertionFilePath. Cette approche réduit considérablement les risques de sécurité et la surcharge opérationnelle par rapport à l’authentification traditionnelle basée sur des secrets.

Remarque : Pour les machines virtuelles Azure et App Services (environnements non conteneurisés), utilisez plutôt des identités managées affectées par le système ou l’utilisateur avec le SignedAssertionFromManagedIdentity type d’informations d’identification. Pour plus d’informations, consultez Utiliser l’identité managée.

Utiliser des certificats plutôt que des secrets

Préférez les certificats pour l’authentification lorsque les secrets client ne peuvent pas être évités. Les certificats offrent une sécurité plus forte que les secrets clients, car ils utilisent le chiffrement à clé publique et sont plus difficiles à extraire ou à mauvaise utilisation. Stockez des certificats dans Azure Key Vault pour la gestion centralisée et le renouvellement automatique :

- 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"

Avantages : Azure Key Vault fournit une gestion centralisée des certificats avec la rotation automatisée, les stratégies d’accès et l’audit complet, tout en garantissant que les certificats ne sont jamais incorporés dans des images conteneur. Pour plus d’informations, consultez Utiliser des certificats pour l’authentification.

Stocker les secrets en toute sécurité

Les secrets Kubernetes sont une option appropriée pour stocker les secrets client si les identités managées ou les certificats ne sont pas une option, bien que les secrets soient chiffrés au repos et que l’accès soit étroitement contrôlé :

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

Secrets client (éviter si possible)

Si les secrets client doivent être utilisés, implémentez des mesures de sécurité supplémentaires pour réduire les risques. Les secrets clients sont moins sécurisés que les identités managées ou les certificats. Ils nécessitent donc une protection supplémentaire, notamment des périodes d’expiration courtes, un stockage sécurisé avec chiffrement au repos, un accès restreint via RBAC et des planifications de rotation fréquentes. Ne stockez jamais de secrets dans des images conteneur ou des variables d’environnement visibles dans les manifestes de déploiement :

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

Caution

Ne validez jamais les secrets dans le système de contrôle de version. Utilisez la gestion des secrets externes (Azure Key Vault, Secrets scellés, etc.).

Sécurité des jetons

La sécurité des jetons garantit que seuls les jetons valides et correctement étendus sont acceptés et traités par le Kit de développement logiciel (SDK). Implémentez la validation des jetons, les exigences d’étendue et les vérifications de l’audience pour empêcher l’accès non autorisé et limiter l’utilisation incorrecte des jetons.

Activer la validation de l’étendue

Exiger des périmètres spécifiques pour les jetons entrants (séparés par des espaces) :

- name: AzureAd__Scopes
  value: "access_as_user"

Définir l’audience appropriée

Configurez l’audience attendue pour la validation des jetons :

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

Note

La valeur d’audience attendue dépend de la requestedAccessTokenVersion de l’inscription de votre application :

  • Version 2 : Utiliser la {ClientId} valeur directement
  • Version 1 ou null : utilisez l’URI d’ID d’application (généralement api://{ClientId} , sauf si vous l’avez personnalisé)

Valider les jetons avant l’utilisation

Appelez /Validate toujours avant d’accepter des jetons utilisateur :

GET /Validate
Authorization: Bearer <user-token>

Sécurité du runtime

Les contrôles de sécurité runtime protègent le conteneur du SDK contre la modification, l’escalade des privilèges et l’accès aux fonctionnalités non autorisées. Configurez le conteneur pour qu’il s’exécute avec des privilèges minimal et des systèmes de fichiers en lecture seule pour réduire la surface d’attaque.

Système de fichiers racine en lecture seule

Empêcher la modification du système de fichiers conteneur :

securityContext:
  readOnlyRootFilesystem: true

Stratégie de sécurité des pods

Appliquer les normes de sécurité :

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

Journalisation et surveillance

La journalisation et la surveillance efficaces vous permettent de détecter les anomalies, de résoudre les problèmes et de gérer les pistes d’audit pour la conformité. Configurez les niveaux de journalisation appropriés pour votre environnement et implémentez des sondes d’intégrité pour vous assurer que le Kit de développement logiciel (SDK) fonctionne comme prévu.

Configurer la journalisation appropriée

Environnement de production :

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

Environnement de développement (détaillé) :

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

Activer la surveillance de l’intégrité

Configurez les sondes de vivacité et de disponibilité :

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

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

Liste de vérification des meilleures pratiques

Utilisez cette liste de contrôle complète pour vous assurer que votre déploiement du Kit de développement logiciel (SDK) suit toutes les pratiques de sécurité recommandées sur le réseau, les informations d’identification, les jetons, le runtime et les dimensions de supervision.

Réseau:

  • [ ] Le SDK écoute uniquement sur localhost/127.0.0.1
  • [ ] Jamais exposé via LoadBalancer ou Ingress
  • [ ] Les stratégies réseau limitent l’accès externe
  • [ ] HTTPS/TLS pour la communication externe

Pouvoirs:

  • [ ] Utiliser l’identité de charge de travail pour les conteneurs (AKS, Kubernetes, Docker) avec SignedAssertionFilePath
  • [ ] Utiliser l’identité managée pour les machines virtuelles/App Services avec SignedAssertionFromManagedIdentity
  • [ ] Préférer les certificats aux secrets
  • [ ] Secrets stockés dans un système de gestion sécurisé
  • [ ] Rotation régulière des informations d’identification

Jetons:

  • [ ] Validation du périmètre activée
  • [ ] Validation de l’audience configurée
  • [ ] Jetons validés avant l’utilisation

Durée d'exécution:

  • [ ] Le conteneur s’exécute en tant qu’utilisateur non-privilégié
  • [ ] Système de fichiers racine en lecture seule
  • [ ] Contexte de sécurité appliqué
  • [ ] Limites de ressources définies

Surveillance:

  • [ ] Journalisation appropriée configurée
  • [ ] Vérifications d’intégrité activées
  • [ ] Journalisation d’audit activée
  • [ ] Alertes configurées

Modèles de sécurité courants

Les implémentations de référence montrent comment combiner plusieurs contrôles de sécurité en modèles de déploiement cohérents. Ces modèles servent de modèles pour les déploiements de production dans différents modèles de menace.

déploiement haute sécurité

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

Faire pivoter régulièrement les informations d’identification

La rotation des informations d’identification réduit la fenêtre d’opportunité des attaquants si les informations d’identification sont divulguées ou compromises. La fréquence de rotation dépend du type d’informations d’identification et de la stratégie de sécurité de votre organisation :

  • Secrets client : tous les 90 jours (recommandé)
  • Certificats : avant expiration, généralement tous les 1 à 2 ans
  • Clés pour les requêtes HTTP signées (SHR) : suivez la stratégie de sécurité de votre organisation

Conseils d’implémentation : Utilisez Azure Key Vault avec des fonctionnalités de rotation automatisées ou intégrez des gestionnaires de secrets externes (tels que des secrets scellés) dans votre pipeline de déploiement. Cela réduit l’intervention manuelle et garantit des planifications de rotation cohérentes.

Répondre aux informations d’identification compromises

Si vous pensez que les informations d’identification ont été compromises, procédez immédiatement comme suit pour contenir l’incident et empêcher l’accès non autorisé :

  1. Révoquer les informations d’identification compromises dans l’ID Microsoft Entra : supprimez les informations d’identification de l’inscription de l’application pour bloquer leur utilisation immédiatement.
  2. Générer de nouvelles informations d’identification : créez de nouveaux secrets client ou certificats dans Microsoft Entra ID pour remplacer les certificats compromis.
  3. Mettez à jour votre système de gestion des secrets : stockez les nouvelles informations d’identification dans les secrets Kubernetes ou Azure Key Vault avec les contrôles d’accès appropriés.
  4. Redéployer des conteneurs sdk : mettez à jour vos déploiements pour utiliser les nouvelles informations d’identification, ce qui garantit que toutes les instances en cours d’exécution récupèrent les modifications.
  5. Passez en revue les journaux d’accès : vérifiez les journaux d’audit Azure Monitor et Kubernetes pour détecter les signes de demandes de jeton non autorisées ou d’activités suspectes pendant la fenêtre de compromission.
  6. Documentez l’incident : enregistrez les détails de l’incident (lorsqu’il est découvert, comment il s’est produit, ce qui a été consulté) et suivez les procédures de réponse aux incidents de votre organisation pour éviter la récurrence.

Voir aussi

  • Last updated on