Najlepsze rozwiązania w zakresie zabezpieczeń: wzmacnianie zabezpieczeń zestawu Microsoft Entra SDK dla identyfikatora AgentID

Ten przewodnik zawiera kompleksową konfigurację zabezpieczeń i najlepsze rozwiązania dotyczące wzmacniania zabezpieczeń w celu bezpiecznego wdrażania i obsługi zestawu Microsoft Entra SDK for AgentID w środowiskach produkcyjnych. Obejmuje ona podstawowe mechanizmy kontroli zabezpieczeń, w tym izolację sieci, zarządzanie poświadczeniami, walidację tokenów, zabezpieczenia środowiska uruchomieniowego i monitorowanie w celu zapewnienia, że wdrożenie zestawu SDK jest zgodne z najlepszymi rozwiązaniami w zakresie zabezpieczeń.

Czy można bezpiecznie uruchomić zestaw SDK?

Zestaw Microsoft Entra SDK for AgentID został zaprojektowany z myślą o zabezpieczeniach, ale jego bezpieczeństwo zależy od odpowiedniej konfiguracji i praktyk wdrażania. Postępuj zgodnie z tymi najlepszymi rozwiązaniami, aby zapewnić bezpieczne wdrożenie:

Bezpieczeństwo sieci

Izolacja sieci ma kluczowe znaczenie dla ochrony operacji uwierzytelniania. Zestaw Microsoft Entra SDK for AgentID musi działać w granicach zaufanych z rygorystycznymi mechanizmami kontroli dostępu i kompleksowym filtrowaniem ruchu. Obejmuje to wiązanie tylko do lokalnego hosta, komunikację wewnętrzną podu oraz zasady sieciowe, które uniemożliwiają nieautoryzowany dostęp do punktów końcowych uwierzytelniania.

Ograniczanie dostępu do zestawu SDK

Skonfiguruj usługę Kestrel tak, aby nasłuchiwać tylko na hoście lokalnym, aby uniemożliwić dostęp sieci zewnętrznej do punktów końcowych uwierzytelniania:

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"

Alternatywnie użyj filtrowania hostów Kestrel z allowedHosts, aby ograniczyć dostęp:

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

Korzystanie z komunikacji podlokalnej

Skonfiguruj aplikację tak, aby komunikowała się z zestawem Microsoft Entra SDK for AgentID za pośrednictwem hosta lokalnego, aby zapewnić, że ruch pozostaje w tym samym zasobniku i nie przechodzi przez sieć:

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

Nigdy nie ujawniaj za pośrednictwem LoadBalancer lub Ingress (umożliwiłoby to nieautoryzowane pozyskiwanie tokenów z zewnątrz zaufanej granicy):

# 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

Zarządzanie poświadczeniami

Bezpieczne zarządzanie poświadczeniami jest fundamentalne dla zabezpieczeń zestawu SDK. Używaj tożsamości zarządzanych, gdy tylko to możliwe, aby wyeliminować tajemnice, i kieruj się zasadą najmniejszych uprawnień, konfigurując poświadczenia uwierzytelniania.

Preferuj tożsamość obciążenia dla kontenerów

Użyj Tożsamości Obciążenia Azure AD do wdrożeń konteneryzowanych (AKS), aby całkowicie wyeliminować tajne dane i zapewnić bezpieczne zarządzanie poświadczeniami przez projekcję tokenów opartych na plikach.

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"

Korzyści: tożsamość pracy eliminuje konieczność przechowywania lub rotacji tajnych danych, zapewniając jednocześnie automatyczne zarządzanie poświadczeniami, integrację Azure RBAC i z pełnym dziennikiem inspekcji. Token jest automatycznie umieszczany w podzie przez webhook tożsamości obciążenia, a zestaw SDK odczytuje go przy użyciu SignedAssertionFilePath typu poświadczeń. Takie podejście znacznie zmniejsza ryzyko związane z zabezpieczeniami i obciążenie operacyjne w porównaniu z tradycyjnym uwierzytelnianiem opartym na wpisach tajnych.

Uwaga: w przypadku maszyn wirtualnych platformy Azure i usług App Services (środowisk niekontenerowanych) używaj tożsamości zarządzanych przypisanych do użytkownika lub przypisanych do systemu za pomocą typu poświadczeń . Aby uzyskać więcej informacji, zobacz Używanie tożsamości zarządzanej.

Używaj certyfikatów zamiast sekretów

Preferuj certyfikaty do uwierzytelniania, gdy nie można uniknąć tajemnic klienta. Certyfikaty zapewniają silniejsze zabezpieczenia niż wpisy tajne klienta, ponieważ używają kryptografii klucza publicznego i są trudniejsze do wyodrębnienia lub nieprawidłowego użycia. Przechowywanie certyfikatów w usłudze Azure Key Vault na potrzeby scentralizowanego zarządzania i automatycznego odnawiania:

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

Korzyści: usługa Azure Key Vault zapewnia scentralizowane zarządzanie certyfikatami dzięki zautomatyzowanej rotacji, zasadom dostępu i kompleksowej inspekcji, zapewniając jednocześnie, że certyfikaty nigdy nie są osadzone w obrazach kontenerów. Aby uzyskać więcej informacji, zobacz Używanie certyfikatów do uwierzytelniania.

Bezpieczne przechowywanie wpisów tajnych

Kubernetes Secrets jest odpowiednią opcją do przechowywania sekretów klienta, jeśli zarządzane tożsamości lub certyfikaty nie są opcją, należy się upewnić, że sekrety są szyfrowane podczas spoczynku i dostęp do nich jest ściśle kontrolowany.

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

Sekrety klienta (unikać, jeśli to możliwe)

Jeśli należy użyć tajnych kluczy klienta, zaimplementuj dodatkowe środki bezpieczeństwa, aby zminimalizować ryzyko. Sekrety klienta są mniej bezpieczne niż tożsamości zarządzane lub certyfikaty, dlatego wymagają dodatkowej ochrony, w tym krótkich okresów wygaśnięcia, bezpiecznego przechowywania z szyfrowaniem danych w spoczynku, ograniczonego dostępu za pośrednictwem kontroli dostępu opartej na rolach i harmonogramy częstej rotacji. Nigdy nie przechowuj tajnych danych w obrazach kontenerów lub zmiennych środowiskowych widocznych w plikach manifestu wdrożeniowego.

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

Zabezpieczenia tokenu

Bezpieczeństwo tokenów zapewnia, że tylko prawidłowe, posiadające odpowiednie zakresy tokeny są akceptowane i przetwarzane przez zestaw SDK. Zaimplementuj weryfikację tokenu, wymagania dotyczące zakresu i kontrole odbiorców, aby zapobiec nieautoryzowanemu dostępowi i ograniczeniu nieprawidłowego użycia tokenu.

Włączanie walidacji zakresu

Wymagaj określonych zakresów dla tokenów przychodzących (oddzielone spacją):

- name: AzureAd__Scopes
  value: "access_as_user"

Ustawianie odpowiednich odbiorców

Skonfiguruj oczekiwanych odbiorców na potrzeby weryfikacji tokenu:

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

Weryfikowanie tokenów przed użyciem

Zawsze wywołaj /Validate przed zaakceptowaniem tokenów użytkownika.

GET /Validate
Authorization: Bearer <user-token>

Zabezpieczenia środowiska uruchomieniowego

Mechanizmy zabezpieczeń środowiska uruchomieniowego chronią kontener zestawu SDK przed modyfikacją, eskalacją uprawnień i nieautoryzowanym dostępem do możliwości. Skonfiguruj kontener do uruchamiania z minimalnymi uprawnieniami i systemami plików tylko do odczytu, aby zmniejszyć obszar ataków.

System plików główny tylko do odczytu

Zapobiegaj modyfikacji systemu plików kontenera:

securityContext:
  readOnlyRootFilesystem: true

** Zasady zabezpieczeń Podów

Wymuszanie standardów zabezpieczeń:

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

Rejestrowanie i monitorowanie

Efektywne rejestrowanie i monitorowanie umożliwia wykrywanie anomalii, rozwiązywanie problemów i utrzymywanie dzienników inspekcji pod kątem zgodności. Skonfiguruj odpowiednie poziomy rejestrowania dla środowiska i zaimplementuj sondy kondycji, aby upewnić się, że zestaw SDK działa zgodnie z oczekiwaniami.

Konfigurowanie odpowiedniego rejestrowania

Środowisko produkcyjne:

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

Środowisko programistyczne (szczegółowe):

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

Włączanie monitorowania kondycji

Skonfiguruj sondy kondycji i gotowości:

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

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

Lista kontrolna najlepszych rozwiązań

Skorzystaj z tej kompleksowej listy kontrolnej, aby upewnić się, że wdrożenie zestawu SDK jest zgodne ze wszystkimi zalecanymi rozwiązaniami zabezpieczeń w sieci, poświadczeniami, tokenami, środowiskiem uruchomieniowym i wymiarami monitorowania.

Sieć:

• [ ] SDK nasłuchuje tylko na localhost/127.0.0.1
• [ ] Nigdy nie ujawniane za pośrednictwem LoadBalancer lub Ingress
• [ ] Zasady sieciowe ograniczają dostęp zewnętrzny
• [ ] Protokół HTTPS/TLS na potrzeby komunikacji zewnętrznej

Poświadczenia:

• [ ] Użyj Workload Identity dla kontenerów (AKS, Kubernetes, Docker) z SignedAssertionFilePath
• [ ] Używanie tożsamości zarządzanej dla maszyn wirtualnych/usług App Services za pomocą polecenia SignedAssertionFromManagedIdentity
• [ ] Preferuj certyfikaty zamiast wpisów tajnych
• [ ] Wpisy tajne przechowywane w bezpiecznym systemie zarządzania
• [ ] Zwykła rotacja poświadczeń

Tokeny:

• [ ] Włączono walidację zakresu
• [ ] Skonfigurowano walidację odbiorców
• [ ] Tokeny zweryfikowane przed użyciem

Środowisko uruchomieniowe

• [ ] Kontener uruchomiony bez uprawnień roota
• [ ] System plików root tylko do odczytu
• [ ] Zastosowany kontekst zabezpieczeń
• [ ] Zestaw limitów zasobów

Monitoring:

• [ ] Skonfigurowane odpowiednie rejestrowanie
• [ ] Włączone kontrole kondycji
• [ ] Włączono rejestrowanie inspekcji
• [ ] Skonfigurowane alerty

Typowe wzorce zabezpieczeń

Implementacje referencyjne pokazują, jak połączyć wiele mechanizmów kontroli zabezpieczeń w spójnych wzorcach wdrażania. Te wzorce służą jako szablony wdrożeń produkcyjnych w różnych modelach zagrożeń.

Wdrażanie wysokiego bezpieczeństwa

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

Regularnie zmieniaj poświadczenia

Rotacja poświadczeń zmniejsza ryzyko wycieku lub naruszenia zabezpieczeń poświadczeń przez osoby atakujące. Częstotliwość rotacji zależy od typu poświadczeń i zasad zabezpieczeń organizacji:

• Wpisy tajne klienta: co 90 dni (zalecane)
• Certyfikaty: Przed wygaśnięciem zazwyczaj co 1–2 lata
• Klucze dla podpisanych żądań HTTP (SHR): postępuj zgodnie z zasadami zabezpieczeń organizacji

Wskazówki dotyczące implementacji: korzystanie z usługi Azure Key Vault z funkcjami zautomatyzowanego rotacji lub integrowanie zewnętrznych menedżerów wpisów tajnych (takich jak zapieczętowane wpisy tajne) do potoku wdrażania. Minimalizuje to interwencję ręczną i zapewnia spójne harmonogramy rotacji.

Reagowanie na naruszone poświadczenia

Natychmiast wykonaj następujące kroki, jeśli podejrzewasz, że poświadczenia zostały naruszone, aby ograniczyć incydent i zapobiec nieautoryzowanemu dostępowi:

1. Odwoływanie poświadczeń z naruszonymi zabezpieczeniami w identyfikatorze Entra firmy Microsoft — usuń poświadczenia z rejestracji aplikacji, aby natychmiast zablokować ich użycie.
2. Generowanie nowych poświadczeń — utwórz nowe tajne klucze klienta lub certyfikaty w Microsoft Entra ID, aby zastąpić skompromitowane poświadczenia.
3. Zaktualizuj system zarządzania wpisami tajnymi — zapisz nowe poświadczenia w wpisach tajnych platformy Kubernetes lub usłudze Azure Key Vault przy użyciu odpowiednich mechanizmów kontroli dostępu.
4. Przeprowadź ponowne wdrażanie kontenerów SDK — zaktualizuj wdrożenia, aby korzystały z nowych poświadczeń i upewnij się, że wszystkie uruchomione instancje przejmują zmiany.
5. Przejrzyj dzienniki dostępu — sprawdź dzienniki inspekcji usług Azure Monitor i Kubernetes pod kątem oznak nieautoryzowanych żądań tokenów lub podejrzanych działań w oknie naruszenia zabezpieczeń.
6. Udokumentuj incydent — zanotuj szczegóły incydentu (moment wykrycia, jak do niego doszło, co zostało skontrolowane) i postępuj zgodnie z procedurami reagowania na incydenty w twojej organizacji, aby zapobiec ich powtórzeniu.

Zobacz też

• Przewodnik instalacji
• Dokumentacja konfiguracji
• Referencja punktów końcowych
• Troubleshooting