安全最佳實務：強化 Microsoft Entra ID Auth SDK（sidecar）

本指南提供在生產環境中安全部署及操作 Microsoft Entra ID Auth SDK（sidecar）所需的完整安全性設定與強化最佳做法。 它涵蓋了基本的安全控制，包括網路隔離、憑證管理、令牌驗證、運行時安全性和監控，以確保您的 SDK 部署遵循安全最佳實踐。

謹慎

Microsoft Entra ID 認證 SDK（側車）API 絕不能公開存取。 它應該只能由相同信任界限內的應用程式存取 （例如，相同的 Pod、相同的虛擬網路）。 依預設，允許的主機是 localhost。 公開此 API 可能會實現 未經授權的令牌獲取，這是一個嚴重的安全風險。 另外要注意，同一信任邊界內的所有應用程式都會有權限存取這個 API。 確保該邊界內的每個應用程式都被信任且妥善保護。

運行 SDK 安全嗎？

Microsoft Entra ID 認證 SDK（側車）設計時以安全性為核心，但其安全性取決於正確的設定與部署作法。 請遵循下列最佳做法，以確保安全部署：

  • 僅在容器化環境中執行
  • 僅限 localhost/pod-internal 的存取
  • 使用 Kubernetes 網路原則
  • 安全儲存憑證（金鑰保存庫、Secrets）
  • 以非 root 使用者身分執行
  • 啟用稽核記錄

網路安全性

網路隔離對於保護身份驗證作業至關重要。 Microsoft Entra ID 認證 SDK（Sidecar）必須在可信任邊界內執行，並採用嚴格的存取控制與完整的流量過濾機制。 這包括僅限本地主機繫結、Pod 內部通訊，以及防止未經授權存取驗證端點的網路原則。

限制 SDK 存取

將 Kestrel 設定為僅接聽 localhost ，以防止外部網路存取驗證端點：

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"

或者，使用 Kestrel 的主機篩選搭配 AllowedHosts 來限制存取：

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

使用 Pod 本地通訊

請設定您的應用程式透過 localhost 與 Microsoft Entra ID Auth SDK（側車）通訊，以確保流量保持在同一個 pod 內，不會穿越網路：

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

切勿透過 LoadBalancer 或 Ingress 公開 （這會允許從受信任邊界外部取得未經授權的權杖）：

# 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

認證管理

安全憑證管理是 SDK 安全性的基礎。 盡可能使用受控識別來消除秘密，並在設定驗證認證時遵循最低許可權原則。

建議容器使用工作負載識別

使用 Microsoft Entra 工作負載 ID 進行容器化部署（AKS），完全消除祕密，並透過基於檔案的憑證投影確保安全的憑證管理：

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"

優點：工作負載身份識別消除儲存或輪換秘密的需要，同時提供自動憑證管理、Azure RBAC 整合及完整稽核追蹤。 權杖會由工作負載身分識別的 Webhook 自動投影至 Pod，然後 SDK 會使用 SignedAssertionFilePath 認證類型來讀取該權杖。 與傳統的基於秘密的身份驗證相比，這種方法顯著降低了安全風險和運營開銷。

註：對於Azure虛擬機和應用程式服務（非容器化環境），請使用系統或使用者指派的管理身份，並使用SignedAssertionFromManagedIdentity憑證類型。 如需詳細資訊，請參閱 使用受控識別。

使用憑證而非秘密

當無法避免用戶端密碼時，偏好憑證進行驗證。 憑證提供比用戶端密碼更強的安全性，因為它們使用公開金鑰加密，而且更難擷取或誤用。 將憑證儲存在 Azure Key Vault 以作集中管理與自動更新：

- 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 提供集中式憑證管理，具備自動輪換、存取政策及全面稽核，並確保憑證不會嵌入容器映像檔中。 如需詳細資訊，請參閱 使用憑證進行驗證。

安全儲存機密

如果受控識別或憑證不是選項，Kubernetes 秘密是儲存用戶端秘密的適當選項，但請確定秘密會在待用時加密，並嚴格控制存取：

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

客戶端秘密（盡量避免）

如果必須使用用戶端密碼，請實作額外的安全措施，以將風險降至最低。 用戶端密碼的安全性低於受控識別或憑證，因此需要額外的保護，包括較短的到期期間、具有待用加密的安全儲存體、透過 RBAC 限制存取，以及頻繁的輪替排程。 切勿將秘密儲存在部署資訊清單中可見的容器映像或環境變數中：

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

謹慎

不要將秘密添加至版本控制系統。 使用外部秘密管理（Azure Key Vault、Sealed Secrets 等）。

令牌安全性

權杖安全性可確保 SDK 只會接受和處理有效且範圍適當的權杖。 實施令牌驗證、範圍要求和受眾檢查，以防止未經授權的存取並限制令牌濫用。

啟用範圍驗證

需要傳入權杖的特定範圍 （空格分隔）：

- name: AzureAd__Scopes
  value: "access_as_user"

設定合適的觀眾

設定令牌驗證的目標受眾：

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

備註

根據應用程式註冊的 requestedAccessTokenVersion，預期的受眾價值有所不同：

  • 版本 2：直接使用 {ClientId} 值
  • 第 1 版 或 Null：使用應用程式識別碼 URI （通常 api://{ClientId} 除非您自訂）

使用前驗證代幣

在接受使用者權杖之前，請務必先呼叫 /Validate ：

GET /Validate
Authorization: Bearer <user-token>

安全入站 PoP 驗證

備註

入站 SHR PoP 驗證需使用側車版本或更新版本 1.1.2-preview 。

對於僅限應用程式的 SHR PoP 憑證，請從受信任的要求處理路徑推導出 original-method 和 original-uri。 不要接受不信任客戶提供的替換值。 sidecar 代理程式會依據這些值驗證 SHR 憑證，但不會直接查看原始請求。

理賠時 ts 會用 Sidecar:PopValidation:SignedHttpRequestLifetime來決定 SHR 到期時間，預設為五分鐘。 此檢查並非重放快取，且不支援伺服器 nonce 驗證。

驗證後，使用角色、應用程式權限或其他受信任的聲明授權應用程式身份。 AzureAd:Scopes 適用於承載驗證，並未用於授權僅應用程式的 PoP 憑證。

執行時安全性

執行階段安全控制可保護 SDK 容器免於修改、權限提升和未經授權的功能存取。 將容器設定為以最低權限和唯讀檔案系統執行，以減少受攻擊面。

唯讀根檔案系統

防止修改容器檔案系統：

    securityContext:
      readOnlyRootFilesystem: true

SDK 使用記憶體內金鑰與令牌快取，因此只讀部署不需要可寫掛載。

Pod 安全政策

執行安全標準：

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

記錄和監視

有效的日誌記錄和監控使您能夠檢測異常、疑難排解問題並維護審計跟踪以確保合規性。 為您的環境設定適當的記錄層級，並實作健康情況探查，以確保 SDK 如預期般運作。

配置適當的日誌

生產環境：

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

開發環境 （詳細）：

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

啟用健康監測

配置 Liveness 和 Readiness 探针：

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

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

最佳做法檢查清單

使用此全面的檢查清單，確保您的 SDK 部署遵循跨網路、認證、權杖、執行階段和監控維度的所有建議安全做法。

網：

  • [ ] SDK 僅在 localhost/127.0.0.1 上監聽
  • [ ] 從未透過 LoadBalancer 或 Ingress 公開
  • [ ] 網路原則限制外部存取
  • [ ] 用於外部通訊的 HTTPS/TLS

證件：

  • [ ] 使用工作負載身分識別於容器（AKS、Kubernetes、Docker）與 SignedAssertionFilePath
  • [ ] 使用受控識別於 VM/App Services 與 SignedAssertionFromManagedIdentity
  • [ ] 偏好憑證而不是秘密
  • [ ] 儲存在安全管理系統中的秘密
  • [ ] 定期認證輪替

代幣：

  • [ ] 已啟用範圍驗證
  • [ ] 已設定受眾驗證
  • [ ] 令牌在使用前已驗證

運行時間：

  • [ ] 容器以非 root 身分執行
  • [ ] 唯讀根檔案系統
  • [ ] 已套用安全性內容
  • [ ] 設定的資源限制

監控：

  • [ ] 已配置適當的日誌記錄
  • [ ] 已啟用健康檢查
  • [ ] 已啟用稽核記錄
  • [ ] 已設定通知

常見的安全模式

參考實作示範如何將多個安全性控制結合成一致的部署模式。 這些模式可作為各種威脅模型中生產部署的範本。

高安全性部署

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

定期輪替認證

輪換憑證可以減少憑證外洩或被洩露時，攻擊者進行攻擊的可乘之機。 輪換頻率取決於認證類型和組織的安全政策：

  • 用戶端密碼：每 90 天一次 （建議）
  • 證書：到期前，通常每 1-2 年一次
  • 已簽署 HTTP 要求 （SHR） 的金鑰：遵循組織的安全原則

實作指引：使用具備自動輪換功能的Azure Key Vault，或將外部秘密管理器（如 Sealed Secrets）整合進您的部署流程中。 這最大限度地減少了人工幹預並確保了一致的輪換時間表。

回應遭洩露的憑證

如果您懷疑憑證已遭到入侵，請立即遵循下列步驟來遏制事件並防止未經授權的存取：

  1. 撤銷在 Microsoft Entra ID 中被入侵的憑證 - 立即從應用程式註冊中移除這些憑證，以立即阻止它們的使用。
  2. 產生新憑證 - 在Microsoft Entra ID建立新的客戶端秘密或憑證，以取代被入侵的憑證。
  3. Update Your secrets management system - 將新的憑證儲存在 Kubernetes Secrets 或 Azure Key Vault 中，並加上適當的存取控制。
  4. 重新部署 SDK 容器 - 更新您的部署以使用新的憑證，確保所有運行中的執行個體都能反映變更。
  5. 審查存取日誌 - 檢查 Azure 監視器 和 Kubernetes 的審計日誌，尋找在入侵期間是否有未經授權的令牌請求或可疑活動跡象。
  6. 記錄事件 - 記錄事件的詳細資料 （發現時、發生方式、存取內容） ，並遵循組織的事件回應程序以防止再次發生。

相關內容

  • 上次更新時間：