Рекомендации по обеспечению безопасности. Защита пакета SDK Microsoft Entra для AgentID

В этом руководстве приведены комплексные рекомендации по настройке безопасности и обеспечению защиты для безопасного развертывания и эксплуатации пакета SDK Microsoft Entra для идентификатора агента в рабочих средах. В ней рассматриваются основные элементы управления безопасностью, включая сетевую изоляцию, управление учетными данными, проверку маркеров, безопасность среды выполнения и мониторинг, чтобы обеспечить развертывание пакета SDK следует рекомендациям по обеспечению безопасности.

Caution

Пакет SDK Microsoft Entra для API идентификаторов агента никогда не должен быть общедоступным. Оно должно быть доступно только приложениям в пределах той же границы доверия (например, в том же pod, в той же виртуальной сети). По умолчанию разрешенные хосты — localhost. Публичное предоставление этого API может привести к несанкционированному получению токена, что является критически важным риском безопасности. Кроме того, обратите внимание, что все приложения в пределах одной границы доверия будут иметь доступ к этому API. Убедитесь, что каждое приложение в этой границе является доверенным и должным образом защищенным.

Безопасно ли запустить пакет SDK?

Пакет SDK Microsoft Entra для идентификатора агента разработан с учетом безопасности, но его безопасность зависит от надлежащей конфигурации и методики развертывания. Чтобы обеспечить безопасное развертывание, следуйте приведенным ниже рекомендациям.

  • Запуск только в контейнерных средах
  • Ограничьте доступ только к localhost/pod-internal
  • Использование политик сети Kubernetes
  • Безопасное хранение учетных данных (Key Vault, секреты)
  • Запуск от имени пользователя, не являющегося корневым пользователем
  • Включение ведения журнала аудита

Сетевая безопасность

Сетевая изоляция важна для защиты операций проверки подлинности. Пакет SDK Microsoft Entra для идентификатора агента должен выполняться в пределах доверенных границ с строгими элементами управления доступом и комплексным фильтрацией трафика. К ним относятся привязка только к localhost, внутриподовая связь и сетевые политики, которые предотвращают несанкционированный доступ к конечным точкам проверки подлинности.

Ограничение доступа к пакету 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

Настройте приложение для взаимодействия с Microsoft Entra SDK для идентификатора агента через localhost, чтобы убедиться, что трафик остается в одном поде и не проходит по сети.

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

Никогда не публикуйте через LoadBalancer или Ingress (что позволит несанкционированное получение токена из-за пределов доверенной области).

# WRONG - exposes Microsoft Entra SDK for Agent ID 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 для контейнерных развертываний (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"

Benefits: идентификация рабочей нагрузки устраняет необходимость хранения или смены секретов с обеспечением автоматизированного управления учетными данными, интеграции Azure RBAC и полного журнала аудита. Маркер автоматически проецируется в Pod с помощью веб-перехватчика идентификации рабочей нагрузки, а SDK считывает его с помощью типа учетных SignedAssertionFilePath данных. Этот подход значительно снижает риски безопасности и операционные издержки по сравнению с традиционной проверкой подлинности на основе секретов.

Note. Для работы с виртуальными машинами 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

Caution

Никогда не фиксируйте конфиденциальные данные в системе контроля версий. Используйте управление внешними секретами (Azure Key Vault, запечатанные секреты и т. д.).

Безопасность токена

Безопасность маркеров гарантирует, что принимаются и обрабатываются пакетом 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>

Безопасность среды выполнения

Элементы управления безопасностью среды выполнения защищают контейнер ПАКЕТА SDK от изменения, эскалации привилегий и несанкционированного доступа к возможностям. Настройте контейнер для запуска с минимальными привилегиями и файловыми системами только для чтения, чтобы уменьшить область атаки.

корневая файловая система только для чтения

Запретить изменение файловой системы контейнера:

securityContext:
  readOnlyRootFilesystem: true

Политика безопасности 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"

Включение мониторинга здоровья

Настройте пробы активности и готовности:

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
  • [ ] Использование управляемого удостоверения для виртуальных машин и служб приложений с SignedAssertionFromManagedIdentity
  • [ ] Предпочитать сертификаты вместо секретов
  • [ ] Секреты, хранящиеся в защищенной системе управления
  • [ ] Обычная смена учетных данных

Маркеры:

  • [ ] Включена проверка области видимости
  • [ ] Проверка аудитории настроена
  • [ ] Маркеры, проверенные перед использованием

Время выполнения

  • [ ] Контейнер запускается как некорень
  • [ ] Корневая система только для чтения
  • [ ] Применен контекст безопасности
  • [ ] Набор ограничений ресурсов

Контроль:

  • [ ] Соответствующая конфигурация ведения журнала
  • [ ] Включена проверка работоспособности
  • [ ] Ведение журнала аудита включено
  • [ ] Оповещения, настроенные

Общие шаблоны безопасности

Эталонные реализации демонстрируют объединение нескольких элементов управления безопасностью в согласованные шаблоны развертывания. Эти шаблоны служат шаблонами для рабочих развертываний в различных моделях угроз.

развертывание с высоким уровнем безопасности

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

Регулярно обновлять учетные данные

Смена учетных данных сокращает окно возможностей для злоумышленников, если учетные данные утекли или скомпрометированы. Частота смены зависит от типа учетных данных и политики безопасности вашей организации:

  • Секреты клиента: каждые 90 дней (рекомендуется)
  • Сертификаты: до истечения срока действия обычно каждые 1–2 года
  • Ключи для подписанных HTTP-запросов (SHR): следуйте политике безопасности вашей организации

Руководство по реализации: используйте Azure Key Vault с функциями автоматической ротации или интегрируйте внешние менеджеры секретов (например, Sealed Secrets) в вашу цепочку развертывания. Это сводит к минимуму ручное вмешательство и гарантирует согласованность расписаний ротации.

Реагирование на скомпрометированные учетные данные

Если вы подозреваете, что учетные данные были скомпрометированы, выполните следующие действия, чтобы немедленно содержать инцидент и предотвратить несанкционированный доступ:

  1. Отозвать скомпрометированные учетные записи в Microsoft Entra ID — удалите учетные данные из регистрации приложения, чтобы немедленно заблокировать их использование.
  2. Создайте новые учетные данные — создайте новые секреты или сертификаты клиентов в Microsoft Entra ID для замены скомпрометированных.
  3. Обновите систему управления секретами. Сохраните новые учетные данные в секретах Kubernetes или Azure Key Vault с соответствующими элементами управления доступом.
  4. Повторное развертывание контейнеров SDK - обновите развертывания для использования новых учетных данных, чтобы все работающие экземпляры могли применить изменения.
  5. Проверка журналов доступа — проверьте журналы аудита Azure Monitor и Kubernetes на наличие признаков несанкционированных запросов токенов или подозрительных действий в период скомпрометации.
  6. Задокументируйте инцидент - Запишите сведения об инциденте (когда инцидент был обнаружен, как это произошло, что было доступно) и следуйте процедурам реагирования на инциденты вашей организации, чтобы предотвратить повторение.

Связанный контент

  • Last updated on