Osvědčené postupy zabezpečení: Zabezpečení sady Microsoft Entra ID Auth SDK (sidecar)

Tato příručka poskytuje komplexní osvědčené postupy konfigurace zabezpečení a posílení zabezpečení pro bezpečné nasazení a provoz sady Microsoft Entra ID Auth SDK (sidecar) v produkčních prostředích. Zahrnuje základní bezpečnostní prvky, včetně izolace sítě, správy přihlašovacích údajů, ověřování tokenů, zabezpečení modulu runtime a monitorování, aby se zajistilo, že nasazení sady SDK dodržuje osvědčené postupy zabezpečení.

Upozornění

Rozhraní API sady Microsoft Entra ID Auth SDK (sidecar) nesmí být nikdy veřejně dostupné. Měla by být dosažitelná pouze aplikacemi ve stejné hranici důvěry (např. stejný pod, stejná virtuální síť). Ve výchozím nastavení je povoleným hostitelem localhost. Zveřejnění tohoto rozhraní API veřejně může povolit neoprávněné získání tokenu, což je kritické bezpečnostní riziko. Všimněte si také, že všechny aplikace ve stejné hranici důvěryhodnosti budou mít přístup k tomuto rozhraní API. Zajistěte, aby každá aplikace v této hranici byla důvěryhodná a správně zabezpečená.

Je bezpečné spustit SDK?

Sada Microsoft Entra ID Auth SDK (sidecar) je navržena s důrazem na zabezpečení, ale její bezpečnost závisí na správné konfiguraci a postupech nasazení. Pokud chcete zajistit zabezpečené nasazení, postupujte podle těchto osvědčených postupů:

Spustit pouze v kontejnerizovaných prostředích
Omezení přístupu pouze k localhost/pod-internal
Použití zásad sítě Kubernetes
Bezpečné ukládání přihlašovacích údajů (Key Vault, tajné kódy)
Spustit jako uživatel bez kořenového adresáře
Povolení protokolování auditu

Zabezpečení sítě

Izolace sítě je důležitá pro ochranu operací ověřování. Sada Microsoft Entra ID Auth SDK (sidecar) musí běžet v rámci důvěryhodných hranic s přísnými kontrolami přístupu a komplexním filtrováním provozu. To zahrnuje přiřazení pouze pro localhost, komunikaci mezi pody a zásady sítě, které zabraňují neoprávněnému přístupu k ověřovacím koncovým bodům.

Omezení přístupu k sadě SDK

Nakonfigurujte Kestrel tak, aby naslouchal jenom na místním hostiteli, aby zabránil externímu síťovému přístupu ke koncovým bodům ověřování:

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"

Případně můžete pomocí filtrování hostitelů Kestrel s AllowedHosts omezit přístup:

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

Použít pod-lokální komunikaci

Nakonfigurujte aplikaci tak, aby komunikoval se sadou Microsoft Entra ID Auth SDK (sidecar) přes localhost, aby se zajistilo, že provoz zůstane ve stejném podu a neprochází přes síť:

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

Nikdy nezpřístupňujte prostřednictvím LoadBalanceru nebo Ingress (to by umožnilo neoprávněné získání tokenu mimo důvěryhodné prostředí):

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

Správa přihlašovacích údajů

Zabezpečení správy přihlašovacích údajů je zásadní pro zabezpečení sady SDK. Spravované identity používejte vždy, když je to možné, abyste odstranili tajné kódy, a při konfiguraci přihlašovacích údajů pro ověřování postupujte podle principu nejnižšího oprávnění.

Preferovat identitu úloh pro kontejnery

Pomocí ID úloh Microsoft Entra pro kontejnerizovaná nasazení (AKS) můžete zcela eliminovat tajné kódy a zajistit zabezpečenou správu přihlašovacích údajů pomocí projekce tokenu založeného na souborech:

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"

Benefits: Identita úloh eliminuje potřebu ukládat nebo obměňovat tajné kódy a současně poskytuje automatickou správu přihlašovacích údajů, Azure integraci RBAC a úplný záznam auditu. Token se automaticky promítá do podu webhookem identity úlohy a sada SDK ho přečte pomocí SignedAssertionFilePath typu přihlašovacích údajů. Tento přístup výrazně snižuje rizika zabezpečení a provozní režii v porovnání s tradičním ověřováním založeným na tajných klíčích.

Note: Pro virtuální počítače Azure a služby App Services (nekotenerizovaná prostředí) použijte spravované identity přiřazené systémem nebo uživatelem s typem přihlašovacích údajů SignedAssertionFromManagedIdentity. Další informace najdete v tématu Použití spravované identity.

Používejte certifikáty namísto tajemství

Upřednostňujte certifikáty pro ověřování, pokud se tajné kódy klienta nedají vyhnout. Certifikáty poskytují silnější zabezpečení než tajné kódy klienta, protože používají kryptografii s veřejným klíčem a jsou obtížnější extrahovat nebo zneužít. Ukládat certifikáty v Azure Key Vault pro centralizovanou správu a automatické prodlužování platnosti:

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

Benefits: Azure Key Vault poskytuje centralizovanou správu certifikátů pomocí automatizované obměny, zásad přístupu a komplexního auditování a zároveň zajišťuje, aby se certifikáty nikdy nevkály do imagí kontejnerů. Další informace naleznete v tématu Použití certifikátů pro ověřování.

Bezpečné ukládání tajných kódů

Tajné kódy Kubernetes jsou vhodné pro ukládání tajných kódů klientů, pokud spravované identity nebo certifikáty nejsou volbou, i když se ujistěte, že jsou tajné kódy zašifrované v klidovém stavu a přístup je pevně řízen:

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

Tajemství klienta (pokud možno vyhnout se)

Pokud je potřeba použít tajné kódy klienta, implementujte další bezpečnostní opatření pro minimalizaci rizika. Tajné kódy klientů jsou méně zabezpečené než spravované identity nebo certifikáty, takže vyžadují dodatečnou ochranu, včetně krátkých období vypršení platnosti, zabezpečeného úložiště s šifrováním neaktivních uložených dat, omezeného přístupu prostřednictvím RBAC a častých plánů obměny. Nikdy neukládejte tajné kódy do imagí kontejnerů nebo proměnných prostředí viditelných v manifestech nasazení:

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

Upozornění

Nikdy neukládejte tajné informace do správy zdrojového kódu. Používejte externí správu tajných kódů (Azure Key Vault, zapečetěné tajné kódy atd.).

Zabezpečení tokenů

Zabezpečení tokenů zajišťuje, že sada SDK přijme a zpracuje pouze platné tokeny s odpovídajícím oborem. Implementujte ověřování tokenů, požadavky na obor a kontroly cílové skupiny, abyste zabránili neoprávněnému přístupu a omezení zneužití tokenu.

Povolit validaci rozsahu

Vyžadovat pro příchozí tokeny konkrétní rozsahy (oddělené mezerou):

- name: AzureAd__Scopes
  value: "access_as_user"

Nastavení vhodné cílové skupiny

Nakonfigurujte očekávanou cílovou skupinu pro ověření tokenu:

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

Poznámka:

Očekávaná hodnota cílové skupiny závisí na verzi požadovaného tokenu Access Token vaší registrace:

Verze 2: Použití {ClientId} hodnoty přímo
Verze 1 nebo null: Použijte identifikátor URI ID aplikace (obvykle api://{ClientId} pokud ho nenazpůsobíte).

Ověření tokenů před použitím

Před přijetím tokenů uživatele vždy volejte /Validate :

GET /Validate
Authorization: Bearer <user-token>

Zabezpečení modulu runtime

Ovládací prvky zabezpečení modulu runtime chrání kontejner sady SDK před úpravami, eskalací oprávnění a neoprávněným přístupem k funkcím. Nakonfigurujte kontejner tak, aby běžel s minimálními oprávněními a systémy souborů jen pro čtení, aby se snížil prostor pro útoky.

Systém souborů pouze pro čtení

Zabránit úpravám systému souborů kontejneru:

    securityContext:
      readOnlyRootFilesystem: true

SDK používá klíče uložené v paměti a mezipaměti tokenů, takže při nasazení pouze pro čtení nejsou vyžadovány žádné zapisovatelné připojené svazky.

Zásady zabezpečení podů

Vynucování standardů zabezpečení:

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

Protokolování a monitorování

Efektivní protokolování a monitorování umožňuje zjišťovat anomálie, řešit problémy a udržovat záznamy auditu pro dodržování předpisů. Nakonfigurujte odpovídající úrovně protokolování pro vaše prostředí a implementujte sondy stavu, aby sada SDK fungovala podle očekávání.

Nastavte vhodné protokolování

Produkční prostředí:

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

Vývojové prostředí (podrobné):

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

Povolení monitorování stavu

Konfigurujte sondy živosti a připravenosti:

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

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

Kontrolní seznam osvědčených postupů

Pomocí tohoto komplexního kontrolního seznamu se ujistěte, že nasazení sady SDK dodržuje všechny doporučené postupy zabezpečení napříč sítěmi, přihlašovacími údaji, tokeny, moduly runtime a monitorováním dimenzí.

Síť:

[ ] SDK naslouchá pouze na localhost/127.0.0.1
[ ] Nikdy nevyužívá LoadBalancer nebo Ingress
[ ] Zásady sítě omezují externí přístup
[ ] HTTPS/TLS pro externí komunikaci

Pověření:

[ ] Použití identity úloh pro kontejnery (AKS, Kubernetes, Docker) s využitím SignedAssertionFilePath
[ ] Použít Managed Identity pro virtuální počítače/Služby aplikací s SignedAssertionFromManagedIdentity
[ ] Preferovat certifikáty před tajnými kódy
[ ] Tajné kódy uložené v zabezpečeném systému pro správu
[ ] Běžná obměně přihlašovacích údajů

Odznaky:

[ ] Povolené ověřování rozsahu
[ ] Nakonfigurované ověření cílové skupiny
[ ] Tokeny ověřeny před použitím

Runtime:

[ ] Kontejner běží jako uživatel bez oprávnění root.
[ ] Kořenový systém souborů jen pro čtení
[ ] Použitý kontext zabezpečení
[ ] Nastavené limity prostředků

Monitorování:

[ ] Nakonfigurováno vhodné protokolování
[ ] Povoleny kontroly stavu
[ ] Protokolování auditu povoleno
[ ] Nakonfigurovaná upozornění

Běžné vzory zabezpečení

Referenční implementace ukazují, jak kombinovat více kontrolních mechanismů zabezpečení do soudržných vzorů nasazení. Tyto vzory slouží jako šablony pro produkční nasazení v různých modelech hrozeb.

nasazení s vysokou úrovní zabezpečení

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: 1654
      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: 1654
          runAsGroup: 1654
          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

Pravidelná obměna přihlašovacích údajů

Obměna přihlašovacích údajů snižuje příležitost pro útočníky, pokud dojde k úniku nebo ohrožení zabezpečení přihlašovacích údajů. Frekvence rotace závisí na typu přihlašovacích údajů a zásadách zabezpečení vaší organizace:

Tajné kódy klienta: Každých 90 dnů (doporučeno)
Certifikáty: Před vypršením platnosti obvykle každých 1 až 2 roky
Klíče pro podepsané požadavky HTTP (SHR): Postupujte podle zásad zabezpečení vaší organizace.

Pokyny pro zavedení: Použijte Azure Key Vault s možnostmi automatizované obměny nebo integrujte externí správce tajemství (například Sealed Secrets) do kanálu nasazení. Tím se minimalizuje ruční zásah a zajistí se konzistentní plány rotace.

Reakce na ohrožené přihlašovací údaje

Pokud máte podezření, že došlo k ohrožení přihlašovacích údajů, okamžitě proveďte následující kroky, aby bylo možné incident zvládnout a zabránit neoprávněnému přístupu:

Odvolejte ohrožené přihlašovací údaje v Microsoft Entra ID – Odeberte přihlašovací údaje z registrace aplikace, aby bylo jejich použití okamžitě zablokováno.
Generate nové přihlašovací údaje – Vytvořte nové tajné klíče klienta nebo certifikáty v Microsoft Entra ID, které nahradí ohrožené přihlašovací údaje.
Aktualizujte systém pro správu tajemství – Nové přihlašovací údaje uložte do Kubernetes Secrets nebo Azure Key Vault s využitím příslušných řízení přístupu.
Opětovné nasazení kontejnerů sady SDK – Aktualizujte nasazení tak, aby využívala nové přihlašovací údaje a zajistila, že všechny spuštěné instance změny přijmou.
Pozorujte protokoly přístupu – Zkontrolujte protokoly auditu Azure Monitor a Kubernetes, jestli se během okna ohrožení neoznamují neoprávněné žádosti o tokeny nebo podezřelá aktivita.
Zdokumentujte incident – zaznamenejte podrobnosti incidentu (při zjištění, jak k němu došlo, co se stalo) a postupujte podle postupů reakce na incidenty vaší organizace, abyste zabránili opakování.

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-06-16