Delen via

Aanbevolen beveiligingsprocedures: De Microsoft Entra SDK voor AgentID beveiligen

Deze handleiding bevat uitgebreide beveiligingsconfiguratie en "hardening" best practices voor het veilig implementeren en gebruiken van de Microsoft Entra SDK voor AgentID in productieomgevingen. Het omvat essentiële beveiligingscontroles, waaronder netwerkisolatie, referentiebeheer, tokenvalidatie, runtimebeveiliging en bewaking om ervoor te zorgen dat uw SDK-implementatie de best practices voor beveiliging volgt.

Waarschuwing

De Microsoft Entra SDK voor agentID-API mag nooit openbaar toegankelijk zijn. Het mag alleen bereikbaar zijn voor toepassingen binnen dezelfde vertrouwensgrens (bijvoorbeeld dezelfde pod, hetzelfde virtuele netwerk). De toegestane hosts zijn standaard localhost. Als u deze API openbaar beschikbaar maakt, kan onbevoegde tokenverwerving worden ingeschakeld. Dit is een kritiek beveiligingsrisico. Houd er ook rekening mee dat alle toepassingen binnen dezelfde vertrouwensgrens toegang hebben tot deze API. Zorg ervoor dat elke toepassing in die omgeving wordt vertrouwd en goed beveiligd.

Is het veilig om de SDK uit te voeren?

De Microsoft Entra SDK voor AgentID is ontworpen met beveiliging in het achterhoofd, maar de veiligheid is afhankelijk van de juiste configuratie- en implementatieprocedures. Volg deze aanbevolen procedures om een veilige implementatie te garanderen:

  • Alleen uitvoeren in containeromgevingen
  • Toegang beperken tot alleen localhost/pod-internal
  • Kubernetes-netwerkbeleid gebruiken
  • Referenties veilig opslaan (Key Vault, Geheimen)
  • Uitvoeren als niet-hoofdgebruiker
  • Auditlogboekregistratie inschakelen

Netwerkbeveiliging

Netwerkisolatie is essentieel voor het beveiligen van verificatiebewerkingen. De Microsoft Entra SDK voor AgentID moet worden uitgevoerd binnen vertrouwde grenzen met strikte toegangsbeheer en uitgebreide verkeersfiltering. Dit omvat alleen-localhost-binding, interne communicatie tussen pods en netwerkbeleid waarmee onbevoegde toegang tot verificatie-eindpunten wordt voorkomen.

SDK-toegang beperken

Configureer Kestrel om uitsluitend op localhost te luisteren en externe netwerktoegang tot authenticatie-eindpunten te voorkomen.

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"

U kunt ook de hostfiltering van Kestrel gebruiken met AllowedHosts om de toegang te beperken:

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

Pod-Local Communication gebruiken

Configureer uw toepassing om te communiceren met de Microsoft Entra SDK voor AgentID via localhost om ervoor te zorgen dat verkeer binnen dezelfde pod blijft en het netwerk niet doorkruist:

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

Maak nooit beschikbaar via LoadBalancer of Ingress (hierdoor is ongeautoriseerde verwerving van tokens mogelijk van buiten de vertrouwde grens):

# 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

Referentiebeheer

Beveiligd referentiebeheer is essentieel voor SDK-beveiliging. Gebruik waar mogelijk beheerde identiteiten om geheimen te elimineren en volg het principe van minimale bevoegdheden bij het configureren van verificatiereferenties.

Geef de voorkeur aan workloadidentiteit voor containers

Gebruik Azure AD Workload Identity voor containerimplementaties (AKS) om geheimen volledig te elimineren en te zorgen voor veilig referentiebeheer met op bestanden gebaseerde tokenprojectie:

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"

Voordelen: De workloadidentiteit elimineert de noodzaak om geheimen op te slaan of te roteren, terwijl automatisch referentiebeheer, Azure RBAC-integratie en een volledige audit trail worden geboden. Het token wordt automatisch naar de pod geprojecteerd door de workload-identiteitwebhook en de SDK leest het met behulp van het SignedAssertionFilePath referentietype. Deze aanpak vermindert aanzienlijk de beveiligingsrisico's en operationele overhead vergeleken met traditionele verificatie op basis van geheimen.

Opmerking: Gebruik voor Azure-VM's en App Services (niet-containeromgevingen) in plaats daarvan systeem- of door de gebruiker toegewezen beheerde identiteiten met het SignedAssertionFromManagedIdentity referentietype. Zie Beheerde identiteit gebruiken voor meer informatie.

Certificaten gebruiken in plaats van geheimen

Geef de voorkeur aan certificaten voor verificatie wanneer clientgeheimen niet kunnen worden vermeden. Certificaten bieden een sterkere beveiliging dan clientgeheimen omdat ze openbare-sleutelcryptografie gebruiken en moeilijker kunnen worden geëxtraheerd of misbruikt. Certificaten opslaan in Azure Key Vault voor gecentraliseerd beheer en automatische verlenging:

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

Voordelen: Azure Key Vault biedt gecentraliseerd certificaatbeheer met geautomatiseerde rotatie, toegangsbeleid en uitgebreide controle, terwijl certificaten nooit worden ingesloten in containerinstallatiekopieën. Zie Certificaten voor verificatie gebruiken voor meer informatie.

Geheimen veilig opslaan

Kubernetes Secrets zijn een geschikte oplossing voor het opslaan van cliëntgeheimen wanneer beheerde identiteiten of certificaten geen optie zijn, mits de geheimen in rust worden versleuteld en dat de toegang strikt wordt beheerd.

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

Clientgeheimen (vermijd indien mogelijk)

Als clientgeheimen moeten worden gebruikt, moet u aanvullende beveiligingsmaatregelen implementeren om het risico te minimaliseren. Clientgeheimen zijn minder veilig dan beheerde identiteiten of certificaten, dus ze vereisen extra beveiliging, waaronder korte verloopperioden, beveiligde opslag met versleuteling-at-rest, beperkte toegang via RBAC en regelmatige rotatieschema's. Sla nooit geheimen op in containerinstallatiekopieën of omgevingsvariabelen die zichtbaar zijn in implementatiemanifesten:

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

Waarschuwing

Voer nooit geheimen door aan broncodebeheer. Gebruik extern geheimbeheer (Azure Key Vault, verzegelde geheimen, enzovoort).

Beveiliging van tokens

Beveiliging van tokens zorgt ervoor dat alleen geldige, toepasselijk afgebakende token worden geaccepteerd en verwerkt door de SDK. Implementeer tokenvalidatie, bereikvereisten en doelgroepcontroles om onbevoegde toegang te voorkomen en tokenmisbruik te beperken.

Bereikvalidatie inschakelen

Specifieke toepassingen vereisen voor binnenkomende tokens (gescheiden met spaties):

- name: AzureAd__Scopes
  value: "access_as_user"

De juiste doelgroep instellen

Configureer de verwachte doelgroep voor tokenvalidatie:

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

Opmerking

De verwachte doelgroepwaarde is afhankelijk van de aangevraagdeAccessTokenVersion van uw app-registratie:

  • Versie 2: Gebruik de {ClientId} waarde rechtstreeks
  • Versie 1 of null: gebruik de URI van de app-id (meestal api://{ClientId} tenzij u deze hebt aangepast)

Tokens valideren voor gebruik

Roep altijd aan /Validate voordat u gebruikerstokens accepteert:

GET /Validate
Authorization: Bearer <user-token>

Runtimebeveiliging

Runtimebeveiligingsmechanismen beschermen de SDK-container tegen wijziging, uitbreiding van bevoegdheden en onbevoegde toegang tot mogelijkheden. Configureer de container om te werken met minimale bevoegdheden en alleen-lezen-bestandssystemen om het aanvalsoppervlak te verkleinen.

Read-Only basisbestandssysteem

Voorkomen dat containerbestandssysteem wordt gewijzigd:

securityContext:
  readOnlyRootFilesystem: true

Beveiligingsbeleid voor Pods

Beveiligingsstandaarden afdwingen:

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

Logboekregistratie en bewaking

Met effectieve logboekregistratie en bewaking kunt u afwijkingen detecteren, problemen oplossen en audittrails onderhouden voor naleving. Configureer de juiste logboekregistratieniveaus voor uw omgeving en implementeer statustests om ervoor te zorgen dat de SDK werkt zoals verwacht.

De juiste logboekregistratie configureren

Productieomgeving:

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

Ontwikkelomgeving (uitgebreid):

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

Statuscontrole inschakelen

Liveness- en gereedheidsprobes configureren.

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

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

Controlelijst voor aanbevolen procedures

Gebruik deze uitgebreide controlelijst om ervoor te zorgen dat uw SDK-implementatie alle aanbevolen beveiligingsprocedures in het netwerk, referenties, tokens, runtime en bewakingsdimensies volgt.

Netwerk:

  • [ ] SDK luistert alleen op localhost/127.0.0.1
  • [ ] Nooit beschikbaar gesteld via LoadBalancer of Ingress
  • [ ] Netwerkbeleid beperkt externe toegang
  • [ ] HTTPS/TLS voor externe communicatie

Geloofsbrief:

  • [ ] Workloadidentiteit gebruiken voor containers (AKS, Kubernetes, Docker) met SignedAssertionFilePath
  • [ ] Beheerde identiteit gebruiken voor VM's/App Services met SignedAssertionFromManagedIdentity
  • [ ] Geef de voorkeur aan certificaten boven geheimen
  • [] Geheimen die zijn opgeslagen in een beveiligd beheersysteem
  • [ ] Reguliere referentierotatie

Tokens:

  • [] Bereikvalidatie ingeschakeld
  • [ ] Validatie van doelgroep geconfigureerd
  • [ ] Tokens gevalideerd voor gebruik

Uitvoeringstijd:

  • [ ] Container draait als niet-rootgebruiker
  • [ ] Alleen-lezen hoofdbestandssysteem
  • [ ] Beveiligingscontext toegepast
  • [ ] Resourcelimieten ingesteld

Monitoring:

  • [ ] De juiste logboekregistratie geconfigureerd
  • [ ] Gezondheidscontroles ingeschakeld
  • [ ] Auditlogboek ingeschakeld
  • [ ] Waarschuwingen geconfigureerd

Algemene beveiligingspatronen

Referentie-implementaties laten zien hoe u meerdere beveiligingscontroles combineert in samenhangende implementatiepatronen. Deze patronen fungeren als sjablonen voor productie-implementaties in verschillende bedreigingsmodellen.

implementatie van High-Security

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

Referenties regelmatig roteren

Het roteren van referenties vermindert het kansvenster voor aanvallers als referenties worden gelekt of aangetast. De rotatiefrequentie is afhankelijk van het referentietype en het beveiligingsbeleid van uw organisatie:

  • Clientgeheim: elke 90 dagen (aanbevolen)
  • Certificaten: voordat deze verloopt, meestal om de 1-2 jaar
  • Sleutels voor ondertekende HTTP-aanvragen (SHR): volg het beveiligingsbeleid van uw organisatie

Implementatierichtlijnen: Gebruik Azure Key Vault met geautomatiseerde rotatiemogelijkheden of integreer externe geheime managers (zoals verzegelde geheimen) in uw implementatiepijplijn. Dit minimaliseert handmatige interventie en zorgt voor consistente rotatieschema's.

Reageren op gecompromitteerde referenties

Als u vermoedt dat er inbreuk is gemaakt op inloggegevens, volgt u deze stappen onmiddellijk om het incident onder controle te krijgen en om onbevoegde toegang te voorkomen:

  1. Gecompromitteerde referenties intrekken in Microsoft Entra-id : verwijder de referenties uit de registratie van de toepassing om het gebruik onmiddellijk te blokkeren.
  2. Nieuwe referenties genereren : maak nieuwe clientgeheimen of -certificaten in Microsoft Entra-id om de aangetaste referenties te vervangen.
  3. Werk uw geheimenbeheersysteem bij: sla de nieuwe referenties op in Kubernetes Secrets of Azure Key Vault met de juiste toegangsbeheer.
  4. SDK-containers opnieuw implementeren : werk uw implementaties bij om de nieuwe referenties te gebruiken, zodat alle actieve exemplaren de wijzigingen ophalen.
  5. Bekijk toegangslogboeken- Controleer de auditlogboeken van Azure Monitor en Kubernetes op tekenen van niet-geautoriseerde tokenaanvragen of verdachte activiteiten tijdens het inbreukvenster.
  6. Documenteer het incident - Noteer details van het incident (wanneer dit is ontdekt, hoe het is gebeurd, wat er is geopend) en volg de procedures voor het reageren op incidenten van uw organisatie om terugkeerpatroon te voorkomen.

Zie ook

  • Last updated on