Freigeben über

Bewährte Methoden für Sicherheit: Härtung des Microsoft Entra SDK für AgentID

Dieses Handbuch enthält detaillierte Sicherheitskonfigurationen und bewährte Methoden zur sicheren Bereitstellung und zum Betrieb des Microsoft Entra SDK (Software-Entwicklungssatz) für AgentID in Produktionsumgebungen. Es umfasst wichtige Sicherheitskontrollen, einschließlich Netzwerkisolation, Anmeldeinformationsverwaltung, Tokenüberprüfung, Laufzeitsicherheit und Überwachung, um sicherzustellen, dass Ihre SDK-Bereitstellung bewährte Methoden befolgt.

Vorsicht

Das Microsoft Entra SDK für die AgentID-API darf niemals öffentlich zugänglich sein. Es sollte nur von Anwendungen innerhalb derselben Vertrauensgrenze erreichbar sein (z. B. denselben Pod, dasselbe virtuelle Netzwerk). Standardmäßig ist der zulässige Host localhost. Durch die öffentliche Bereitstellung dieser API kann der nicht autorisierte Tokenerwerb aktiviert werden, was ein kritisches Sicherheitsrisiko darstellt. Beachten Sie außerdem, dass alle Anwendungen innerhalb derselben Vertrauensgrenze Zugriff auf diese API haben. Stellen Sie sicher, dass jede Anwendung innerhalb dieser Grenze vertrauenswürdig und ordnungsgemäß gesichert ist.

Ist es sicher, das SDK auszuführen?

Das Microsoft Entra SDK für AgentID ist mit Sicherheit konzipiert, aber seine Sicherheit hängt von den richtigen Konfigurations- und Bereitstellungspraktiken ab. Befolgen Sie die folgenden bewährten Methoden, um eine sichere Bereitstellung sicherzustellen:

  • Nur in containerisierten Umgebungen ausgeführt
  • Zugriff auf "localhost/pod-internal" einschränken
  • Verwenden von Kubernetes-Netzwerkrichtlinien
  • Sicheres Speichern von Anmeldeinformationen (Key Vault, Geheimnisse)
  • Als Nicht-Stammbenutzer ausführen
  • Aktivieren der Überwachungsprotokollierung

Netzwerksicherheit

Die Netzwerkisolation ist wichtig für den Schutz von Authentifizierungsvorgängen. Das Microsoft Entra SDK für AgentID muss innerhalb vertrauenswürdiger Grenzen mit strengen Zugriffskontrollen und umfassender Datenverkehrsfilterung ausgeführt werden. Dazu gehören localhost-only-Bindung, podinterne Kommunikation und Netzwerkrichtlinien, die nicht autorisierten Zugriff auf Authentifizierungsendpunkte verhindern.

Einschränken des SDK-Zugriffs

Konfigurieren Sie Kestrel so, dass sie nur auf localhost lauschen, um den Zugriff auf externe Netzwerke auf Authentifizierungsendpunkte zu verhindern:

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"

Alternativ können Sie die Hostfilterung von Kestrel mit AllowedHosts verwenden, um den Zugriff einzuschränken:

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

Verwenden Sie pod-lokale Kommunikation

Konfigurieren Sie Ihre Anwendung so, dass sie mit dem Microsoft Entra SDK für AgentID über localhost kommunizieren kann, um sicherzustellen, dass der Datenverkehr innerhalb desselben Pods verbleibt und das Netzwerk nicht durchläuft:

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

Nie über LoadBalancer oder Ingress offenlegen (dies würde eine unautorisierte Token-Erfassung von außerhalb der vertrauenswürdigen Grenze zulassen):

# 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

Verwaltung von Anmeldeinformationen

Die sichere Verwaltung von Anmeldeinformationen ist für die SDK-Sicherheit von grundlegender Bedeutung. Verwenden Sie verwaltete Identitäten, wenn möglich, um geheime Schlüssel zu beseitigen und dem Prinzip der geringsten Berechtigungen beim Konfigurieren von Authentifizierungsanmeldeinformationen zu folgen.

Workload-Identität für Container bevorzugen

Verwenden Sie Azure AD Workload Identity für containerisierte Bereitstellungen (AKS), um geheime Schlüssel vollständig zu beseitigen und die sichere Verwaltung von Anmeldeinformationen mit dateibasierter Tokenprojektion sicherzustellen:

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"

Vorteile: Der Workload-Identitätsdienst beseitigt die Notwendigkeit, geheime Schlüssel zu speichern oder zu wechseln, während die automatische Verwaltung von Anmeldeinformationen, die Azure RBAC-Integration und ein vollständiges Prüfprotokoll bereitgestellt werden. Das Token wird automatisch vom Workload Identity Webhook auf den Pod projiziert, und das SDK liest es mithilfe des SignedAssertionFilePath Anmeldeinformationstyps vor. Dieser Ansatz reduziert im Vergleich zur herkömmlichen geheimen Authentifizierung erheblich Sicherheitsrisiken und betrieblichen Aufwand.

Hinweis: Verwenden Sie für Azure VMs und App Services (nicht containerisierte Umgebungen) stattdessen system- oder vom Benutzer zugewiesene verwaltete Identitäten mit dem SignedAssertionFromManagedIdentity Anmeldeinformationstyp. Weitere Informationen finden Sie unter "Verwaltete Identität verwenden".

Verwenden Sie Zertifikate statt geheimer Schlüssel

Bevorzugen Sie Zertifikate für die Authentifizierung, wenn geheime Clientschlüssel nicht vermieden werden können. Zertifikate bieten eine stärkere Sicherheit als geheime Clientschlüssel, da sie Kryptografie mit öffentlichem Schlüssel verwenden und schwieriger zu extrahieren oder zu missbrauchen sind. Speichern Sie Zertifikate in Azure Key Vault für die zentrale Verwaltung und automatische Verlängerung:

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

Vorteile: Azure Key Vault bietet eine zentralisierte Zertifikatverwaltung mit automatisierter Rotation, Zugriffsrichtlinien und umfassendem Audit, während sichergestellt wird, dass Zertifikate niemals in Container-Images eingebettet sind. Weitere Informationen finden Sie unter Verwenden von Zertifikaten für die Authentifizierung.

Sicheres Speichern von geheimen Schlüsseln

Kubernetes Secrets ist eine geeignete Option zum Speichern von Clientgeheimnissen, wenn verwaltete Identitäten oder Zertifikate keine Option sind. Stellen Sie jedoch sicher, dass die Geheimnisse im Ruhezustand verschlüsselt sind und der Zugriff streng kontrolliert wird.

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

Geheime Clientschlüssel (soweit möglich vermeiden)

Wenn geheime Clientschlüssel verwendet werden müssen, implementieren Sie zusätzliche Sicherheitsmaßnahmen, um das Risiko zu minimieren. Geheime Clientschlüssel sind weniger sicher als verwaltete Identitäten oder Zertifikate, sodass sie zusätzlichen Schutz erfordern, einschließlich kurzen Ablaufzeiten, sicherer Speicherung mit Verschlüsselung im Ruhezustand, eingeschränktem Zugriff über RBAC und häufigen Rotationsplänen. Speichern Sie geheime Schlüssel niemals in Containerimages oder Umgebungsvariablen, die in Bereitstellungsmanifesten sichtbar sind:

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

Vorsicht

Übernehmen Sie niemals geheime Schlüssel zur Quellcodeverwaltung. Verwenden Sie die externe geheime Verwaltung (Azure Key Vault, versiegelte Geheime Schlüssel usw.).

Tokensicherheit

Die Tokensicherheit stellt sicher, dass nur gültige, entsprechend bereichsbezogene Token vom SDK akzeptiert und verarbeitet werden. Implementieren Sie Tokenüberprüfungen, Umfangsanforderungen und Zielgruppenüberprüfungen, um unbefugten Zugriff zu verhindern und Tokenmissbrauch einzuschränken.

Aktivieren der Bereichsüberprüfung

Spezifische Bereiche für eingehende Token erforderlich (durch Leerzeichen getrennt):

- name: AzureAd__Scopes
  value: "access_as_user"

Festlegen der geeigneten Zielgruppe

Konfigurieren der erwarteten Zielgruppe für die Tokenüberprüfung:

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

Hinweis

Der erwartete Benutzergruppenwert hängt von der angefordertenAccessTokenVersion Ihrer App-Registrierung ab:

  • Version 2: Verwenden des Werts {ClientId} direkt
  • Version 1 oder null: Verwenden Sie den App-ID-URI (in der Regel api://{ClientId}, es sei denn, Sie haben ihn angepasst).

Validierung von Token vor der Verwendung

Rufen Sie immer auf /Validate , bevor Sie Benutzertoken annehmen:

GET /Validate
Authorization: Bearer <user-token>

Laufzeitsicherheit

Laufzeitsicherheitssteuerelemente schützen den SDK-Container vor Änderung, Berechtigungseskalation und unbefugtem Zugriff auf Funktionen. Konfigurieren Sie den Container so, dass er mit minimalen Berechtigungen und schreibgeschützten Dateisystemen ausgeführt wird, um die Angriffsfläche zu reduzieren.

Schreibgeschütztes Root-Dateisystem

Änderung des Containerdateisystems verhindern:

securityContext:
  readOnlyRootFilesystem: true

Pod-Sicherheitsrichtlinie

Sicherheitsstandards erzwingen:

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

Protokollierung und Überwachung

Mithilfe der effektiven Protokollierung und Überwachung können Sie Anomalien erkennen, Probleme beheben und Überwachungspfade für die Compliance verwalten. Konfigurieren Sie geeignete Protokollierungsebenen für Ihre Umgebung, und implementieren Sie Integritätssonden, um sicherzustellen, dass das SDK erwartungsgemäß funktioniert.

Konfigurieren der geeigneten Protokollierung

Produktionsumgebung:

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

Entwicklungsumgebung (ausführlich):

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

Aktivieren der Gesundheitsüberwachung

Konfigurieren Sie Liveness- und Readiness-Sonden:

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

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

Checkliste für bewährte Methoden

Verwenden Sie diese umfassende Checkliste, um sicherzustellen, dass Ihre SDK-Bereitstellung alle empfohlenen Sicherheitsmethoden über Netzwerk-, Anmeldeinformationen, Token, Laufzeit- und Überwachungsdimensionen hinweg befolgt.

Netz:

  • [ ] SDK lauscht nur auf localhost/127.0.0.1
  • [ ] Nie über LoadBalancer oder Ingress verfügbar gemacht
  • [ ] Netzwerkrichtlinien beschränken den externen Zugriff
  • [ ] HTTPS/TLS für die externe Kommunikation

Anmeldedaten:

  • [ ] Verwenden der Workload-Identität für Container (AKS, Kubernetes, Docker) mit SignedAssertionFilePath
  • [ ] Verwenden einer verwalteten Identität für VMs/App-Dienste mit SignedAssertionFromManagedIdentity
  • [ ] Zertifikate vor geheimen Schlüsseln bevorzugen
  • [ ] Geheime Schlüssel, die im sicheren Verwaltungssystem gespeichert sind
  • [ ] Regelmäßiger Wechsel der Anmeldeinformationen

Tokens

  • [ ] Bereichsüberprüfung aktiviert
  • [ ] Zielgruppenüberprüfung konfiguriert
  • [ ] Tokens vor der Nutzung validiert

Laufzeit:

  • [ ] Container läuft als Nicht-Root
  • [ ] Schreibgeschütztes Stammdateisystem
  • [ ] Angewendeter Sicherheitskontext
  • [ ] Ressourcenbeschränkungen festgelegt

Überwachung:

  • [ ] Geeignete Protokollierung konfiguriert
  • [ ] Gesundheitsprüfungen aktiviert
  • [ ] Überwachungsprotokollierung aktiviert
  • [ ] Konfigurierte Warnungen

Allgemeine Sicherheitsmuster

Referenzimplementierungen veranschaulichen, wie mehrere Sicherheitskontrollen in zusammenhängenden Bereitstellungsmustern kombiniert werden. Diese Muster dienen als Vorlagen für Produktionsbereitstellungen in verschiedenen Bedrohungsmodellen.

Hochsicherheitsbereitstellung

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

Anmeldeinformationen regelmäßig ändern

Durch das regelmäßige Ändern von Anmeldeinformationen wird das Zeitfenster für Angreifer reduziert, wenn Anmeldeinformationen verloren gehen oder kompromittiert werden. Die Rotationsfrequenz hängt vom Anmeldedatentyp und der Sicherheitsrichtlinie Ihrer Organisation ab.

  • Geheime Clientschlüssel: Alle 90 Tage (empfohlen)
  • Zertifikate: Vor Ablauf, in der Regel alle 1-2 Jahre
  • Schlüssel für signierte HTTP-Anforderungen (SHR): Folgen Sie der Sicherheitsrichtlinie Ihrer Organisation

Implementierungsleitfaden: Verwenden sie Azure Key Vault mit automatisierten Rotationsfunktionen oder integrieren Sie externe geheime Manager (z. B. versiegelte Geheime Schlüssel) in Ihre Bereitstellungspipeline. Dadurch wird ein manueller Eingriff minimiert und ein konsistenter Drehplan sichergestellt.

Reagieren auf kompromittierte Anmeldeinformationen

Wenn Sie vermuten, dass Anmeldeinformationen kompromittiert wurden, führen Sie die folgenden Schritte sofort aus, um den Vorfall zu enthalten und unbefugten Zugriff zu verhindern:

  1. Widerrufen kompromittierter Anmeldeinformationen in der Microsoft Entra-ID – Entfernen Sie die Anmeldeinformationen aus der Anwendungsregistrierung, um die Verwendung sofort zu blockieren.
  2. Generieren Sie neue Anmeldeinformationen – Erstellen Sie neue geheime Clientschlüssel oder Zertifikate in der Microsoft Entra-ID, um die kompromittierten zu ersetzen.
  3. Aktualisieren Sie Ihr geheimes Verwaltungssystem – Speichern Sie die neuen Anmeldeinformationen in Kubernetes Secrets oder Azure Key Vault mit den entsprechenden Zugriffssteuerungen.
  4. Erneutes Bereitstellen von SDK-Containern – Aktualisieren Sie Ihre Bereitstellungen, um die neuen Anmeldeinformationen zu verwenden, und stellen Sie sicher, dass alle ausgeführten Instanzen die Änderungen übernehmen.
  5. Überprüfen Sie Zugriffsprotokolle – Überprüfen Sie die Azure Monitor- und Kubernetes-Überwachungsprotokolle auf Anzeichen nicht autorisierter Tokenanforderungen oder verdächtiger Aktivitäten während des Kompromittierungsfensters.
  6. Dokumentieren Sie den Vorfall – Zeichnen Sie Details des Vorfalls auf (wann er entdeckt wurde, wie es passiert ist, worauf zugegriffen wurde) und folgen Sie den Verfahren zur Reaktion auf Vorfälle In Ihrer Organisation, um eine Wiederholung zu verhindern.

Siehe auch

  • Last updated on