Microsoft AZ-500: Управление ключами, криптография и сертификаты — Руководство по подготовке

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Часть Microsoft Azure Security Engineer Associate AZ-500 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Управление ключами в Azure сосредоточено вокруг служб Azure Key Vault и Azure Managed HSM. Эти службы обеспечивают безопасное хранение криптографических материалов, согласованные API и аудируемые операции, которые лежат в основе шифрования неактивных данных, данных при передаче и криптографии на уровне приложений. Операционная цель заключается в том, чтобы отделить хранение ключей от среды выполнения приложений, минимизировать радиус поражения с помощью авторизации и сетевых настроек с ограниченной областью действия, а также обеспечить возможность восстановления и ротации для снижения риска, связанного с долгоживущими секретами.

Архитектура и авторизация Azure Key Vault и Managed HSM

Архитектура Azure Key Vault

• Состав службы: многопользовательские (multi-tenant) внешние интерфейсы, региональные разделы для уровня данных, изоляция для каждого клиента (tenant) и аутентификация на базе Azure AD. Ключи защищаются либо программно (уровень Standard), либо с помощью HSM (уровень Premium). Секреты и сертификаты всегда защищаются программно.
• Уровни: Standard (программные ключи) для общего назначения и экономической эффективности; Premium (ключи, защищенные HSM), когда требуется защита, эквивалентная FIPS 140-2 Level 2/3, или выделенная граница HSM для материалов ключей. Выбирайте уровень Premium для соответствия нормативным требованиям или при использовании ключей типа «RSA-HSM» или «EC-HSM».
• Обратимое удаление и защита от очистки: Обратимое удаление всегда включено с настраиваемым периодом хранения (7–90 дней, обычно 90). Защита от очистки, если она включена, предотвращает окончательное удаление хранилища или объектов до истечения периода хранения даже пользователями с высокими привилегиями. Операционное обоснование: включайте защиту от очистки для любого хранилища, в котором хранятся ключи, управляемые клиентом (CMK). Без нее случайная или злонамеренная очистка может сделать зависимые данные (например, хранилище или базы данных, зашифрованные этим ключом) невосстановимыми.
• Восстановление: Удаленные объекты хранилища можно просматривать и восстанавливать; поддерживается восстановление на уровне хранилища. Резервные копии создают зашифрованные BLOB-объекты, которые можно восстановить в совместимые хранилища в том же регионе и облаке Azure. Обоснование: периодически экспортируйте резервные копии ключей и храните их отдельно; тестируйте восстановление для проверки RTO.

Модель авторизации

• Модели разрешений: Политики доступа к хранилищу (устаревшие) и Azure RBAC (рекомендуется).
  • Политики доступа: определяются для каждого хранилища; предоставляют гранулярные разрешения для ключей, секретов и сертификатов. Оптимальны, когда вам нужны очень строгие права времени выполнения, специфичные для типа объекта, для небольшого набора субъектов.
  • Azure RBAC: установите для модели разрешений хранилища значение «Управление доступом на основе ролей Azure» (Azure role-based access control), чтобы использовать роли RBAC для уровня данных. Преимущества: область действия на уровне подписки/группы ресурсов/хранилища; назначения, совместимые с PIM; централизованное управление и аудит. Рекомендуется для новых развертываний и для административных операций.
• Встроенные роли хранилища (примеры): Key Vault Administrator (полное управление), Key Vault Crypto Officer (управление ключами, но не политиками доступа), Key Vault Secrets Officer, Key Vault Certificates Officer, Key Vault Reader. Операционные рекомендации:
  • Используйте RBAC (например, Key Vault Administrator) при делегировании настройки моделей доступа и сетевых ACL.
  • Используйте политику доступа или роль RBAC уровня данных, такую как Key Vault Certificates Officer, для предоставления минимально необходимых привилегий на вставку/удаление сертификатов в одном хранилище.
• Проектирование области действия: Предпочитайте назначать RBAC на уровне хранилища, чтобы избежать избыточного предоставления привилегий. Используйте область действия группы ресурсов только тогда, когда несколько хранилищ обслуживаются одними и теми же командами операторов; избегайте назначений на уровне подписки для доступа во время выполнения.

Managed HSM

• Архитектура и домены безопасности: Managed HSM — это однопользовательский (single-tenant) кластер HSM, проверенный на соответствие FIPS 140-2 Level 3, для каждого клиента. Домен безопасности защищает переносимость материалов ключей кластера; для резервного копирования/восстановления между кластерами требуется кворум закрытых ключей домена безопасности. Обоснование: сгенерируйте и депонируйте ключи домена у разных хранителей; протестируйте восстановление на HSM для аварийного восстановления.
• Модель ролей: Интегрирована с Azure RBAC. Роли включают Managed HSM Administrator, Crypto Officer, Crypto User и Reader. Разделение обязанностей: администраторы управляют кластером; крипто-офицеры управляют ключами; крипто-пользователи используют ключи для операций.
• Высокая доступность: Регионально избыточный сервис с несколькими разделами HSM и поддержкой SLA; зональная избыточность доступна в поддерживаемых регионах. Для аварийного восстановления между регионами (disaster recovery) используйте резервные копии + домен безопасности.
• Сценарии использования: Обработка платежей, подписание кода, обертывание ключей для конвертного шифрования и регулируемые рабочие нагрузки, требующие границ HSM уровня Level 3.

Объекты и жизненный цикл: ключи, секреты, сертификаты и ротация

Ключи, секреты, сертификаты

• Ключи: для криптографических операций (подпись, проверка, упаковка/распаковка, шифрование/дешифрование). Выбирайте тип/размер ключа в зависимости от стойкости алгоритма и производительности (например, RSA 3072/4096 для соответствия требованиям или ECC P-256/P-384 для производительности).
• Секреты: произвольные байты/строки, такие как пароли, строки подключения и токены API. Не используются для криптографических операций.
• Сертификаты: X.509 с закрытыми ключами. Хранятся как объект сертификата и соответствующий секрет (PFX/PEM). Полезны для жизненных циклов TLS/MTLS и подписи кода.

Операции жизненного цикла и ротация

• Версионирование: каждая операция установки или импорта создает неизменяемую версию. Приложения должны ссылаться на секреты с указанием версии для детерминированного поведения или на URI без версии для автоматического получения последней версии в зависимости от потребностей управления изменениями.
• Стратегии ротации:
  • Ключи: предпочитайте URI ключей без указания версии для служб Azure, которые их поддерживают (например, Storage, SQL TDE, секреты, управляемые AKV). Ротация выполняется путем добавления новой версии; службы автоматически перепривязываются, если это поддерживается. Если служба требует привязки к конкретной версии, автоматизируйте шаг перенастройки. Обеспечивайте ротацию с помощью политик ротации AKV и оповещений.
  • Секреты: ротируйте с помощью Azure Automation, Functions или Logic Apps, запускаемых уведомлениями Event Grid, или используйте встроенные средства ротации провайдера (например, ротация SAS или паролей баз данных). Избегайте долгоживущих статических секретов, заменяя их управляемыми удостоверениями везде, где это возможно.
  • Сертификаты: определите политики сертификатов с «действиями в течение жизненного цикла» (lifetime actions) для автоматического продления до истечения срока действия; используйте интегрированных издателей для автоматического обновления.

Управление сертификатами

• Импорт/генерация: импортируйте существующие PFX/PEM (с закрытым ключом) или сгенерируйте CSR и позвольте Key Vault завершить выпуск с помощью настроенного CA.
• Автоматическое продление и издатели: настройте издателей, таких как DigiCert, GlobalSign или корпоративный Microsoft CA, через Key Vault. Включите автоматическое продление с уведомлениями и порогами для обновления.
• Интеграция с приложениями:
  • App Service и Functions: используйте ссылки на Key Vault с управляемым удостоверением; платформа автоматически синхронизирует ротированные секреты.
  • Application Gateway/WAF: ссылайтесь на ID секрета сертификата из Key Vault; шлюз автоматически подхватывает новые версии.
  • AKS: монтируйте сертификаты через драйвер Secrets Store CSI и провайдер Azure Key Vault.

Пример назначения RBAC для операций с сертификатами с минимальными привилегиями:

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

Сетевая безопасность и интеграция со службами

Сетевые настройки Key Vault

• Правила брандмауэра: установите значение «Выбранные сети» (Selected networks), чтобы ограничить доступ до разрешенных источников. Обоснование: предотвращает трафик из интернета даже при наличии действительных токенов.
• Конечные точки служб для виртуальной сети: разрешают трафик из определенных подсетей без использования приватных IP-адресов. Просто включаются и уменьшают поверхность атаки. Используйте, когда нужна быстрая изоляция и не требуются изменения в DNS.
• Приватные конечные точки: назначают хранилищу приватный IP-адрес в вашей VNet для полностью приватного подключения. Блокируют доступ из публичных сетей. Обоснование: самый надежный контроль эксфильтрации данных, требуется в средах с высоким уровнем доверия и при ограничении исходящего трафика в интернет.
• Доверенные службы: опция «Разрешить доверенным службам Майкрософт» (Allow trusted Microsoft services) позволяет определенным службам Azure получать доступ к хранилищу, несмотря на сетевые ограничения. Требуется для сценариев, таких как сканирование ключей шифрования Storage во время ротации. Включайте с осторожностью и документируйте зависимости.

Ключи, управляемые клиентом (CMK), и URI ключей

• Поддерживаемые службы: Azure Storage, SQL Database (TDE), Synapse, Databricks, шифрование секретов AKS в состоянии покоя, App Configuration, Event Hubs, Service Bus и Managed Disks через Disk Encryption Set.
• Стратегия использования URI ключей:
  • URI без указания версии: предпочитайте, когда служба поддерживает автоматическую перепривязку к новым версиям ключа; это обеспечивает бесшовную ротацию без обновления службы.
  • URI с указанием версии: требуются некоторыми службами; автоматизируйте обновление конфигурации службы, привязанное к событиям ротации.
• Паттерны ротации:
  • Поэтапная ротация: создайте новую версию ключа; проверьте, что служба имеет к ней доступ; отслеживайте ошибки; затем, по желанию, отключите старые версии по истечении безопасного периода.
  • На основе событий: используйте Event Grid для событий создания новой версии ключа, чтобы запускать рабочие процессы проверки или перенастройки службы.

Интеграция с использованием конвертного шифрования

• Службы Azure используют ключ шифрования данных (DEK) локально (например, AES-256) и ключ шифрования ключей (KEK) в Key Vault/HSM для упаковки DEK. В эксплуатации обеспечьте доступность KEK и сетевой доступ к нему, поскольку потеря или блокировка доступа может остановить работу службы.

Пример: упаковка DEK с помощью ключа из AKV

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

Криптография, шифрование неактивных данных и гигиена секретов

Основные концепции криптографии

• Симметричное шифрование: Один ключ для шифрования/дешифрования (например, AES-GCM/CTR). Быстрое; идеально для больших объемов данных.
• Асимметричное шифрование: Пары открытого/закрытого ключей (RSA/ECC) для обмена ключами и создания подписей. Медленнее; идеально для установления доверия и оборачивания DEK.
• Хеширование: Односторонний дайджест (например, SHA-256). Для целостности; не является шифрованием.
• Подписывание: Закрытый ключ создает подпись; открытый ключ ее проверяет. Неотказуемость и целостность.
• Конвертное шифрование: Сочетание асимметричного KEK с симметричным DEK для производительности и изоляции хранения ключей.

Azure Disk Encryption и шифрование хранилища

• Шифрование управляемых дисков по умолчанию: Серверное шифрование (SSE) с ключами, управляемыми платформой (PMK). Минимальные операционные издержки.
• CMK с набором шифрования дисков (DES): Используйте DES, ссылающийся на ключ в Key Vault или Managed HSM, для дисков, снимков и образов. Обоснование: централизованное управление жизненным циклом и отзывом ключей; соответствует требованиям комплаенса по контролю со стороны клиента.
• ADE (Azure Disk Encryption): Шифрование внутри гостевой ОС с помощью BitLocker (Windows) или dm-crypt (Linux). Используйте, когда требуется шифрование на уровне ОС, защита ключей на уровне диска с привязкой к домену или при наличии существующих требований комплаенса. Операционный компромисс: более высокая сложность, управление расширениями и возможное влияние на развертывание ВМ.
• Двойное шифрование:
  • Диски: Комбинируйте SSE с PMK на уровне инфраструктуры и CMK через DES для получения двух независимых слоев шифрования.
  • Учетные записи хранения: Используйте области шифрования (encryption scopes) с отдельными CMK для каждого контейнера/рабочей нагрузки; комбинируйте с шифрованием на уровне инфраструктуры, где это доступно, для создания двух слоев.
• Области шифрования (Azure Storage): Определяйте области для каждого контейнера или BLOB-объекта с отдельными CMK для изоляции рисков арендатора/рабочей нагрузки и обеспечения целенаправленной ротации без широкого воздействия.

Гигиена секретов и операционные практики

• Управляемые удостоверения: Используйте системные или назначаемые пользователем управляемые удостоверения для ресурсов Azure, чтобы получать токены для Key Vault и других служб, избавляясь от встроенных учетных данных. Ограничивайте область действия RBAC или политик доступа.
• Сканирование секретов: Включите Microsoft Defender for DevOps, сканирование секретов GitHub Advanced Security и защиту репозиториев. Интегрируйте с pull-запросами для блокировки известных шаблонов учетных данных.
• Конвейеры и IaC: Используйте интеграцию задач Key Vault в Azure Pipelines и федеративные учетные данные на основе OIDC в GitHub Actions, чтобы избежать хранения секретов. Не выводите секреты в логи; маскируйте вывод. Немедленно ротируйте любые скомпрометированные данные.
• Проектирование приложений: По возможности предпочитайте ссылки без указания версии; минимально кешируйте и обрабатывайте ошибки 401/403 путем повторного получения токенов и секретов для поддержки событий ротации.

Углубленное управление сертификатами

• Выпуск на основе политик: Определите субъект, SAN, использование ключа, EKU, тип/размер ключа и настройки повторного использования ключа в политике сертификатов Key Vault. Обоснование: единообразная конфигурация TLS во всех средах.
• Интеграция с издателем: Настройте профиль ЦС (CA) в Key Vault. Для частной PKI интегрируйтесь с Microsoft ADCS через кастомного издателя или используйте Certificate Connector для Azure Key Vault. Публичные ЦС позволяют автоматически продлевать сертификаты, не раскрывая приватные ключи за пределами AKV.
• Операции автоматического продления: Используйте действия в течение жизненного цикла (например, продлить за 60 дней до истечения срока; уведомить за 90 дней). С точки зрения эксплуатации, согласовывайте окна продления с периодами заморозки изменений (change freeze) и убедитесь, что зависимые службы выполняют автосинхронизацию.
• Использование в приложениях: Получайте сертификат как секрет (PFX/PEM) или привязывайте по ссылке в платформенных сервисах. Предпочитайте нативные платформенные привязки (App Service, Application Gateway) для бесперебойного переключения на новые версии. Для Kubernetes монтируйте через CSI, чтобы инициировать последовательные перезапуски (rolling restarts) при ротации.

Сценарий практической задачи

Компания Siemens AG должна защитить телеметрию IoT в Azure, обеспечить строгий контроль над ключами для неактивных данных (data at rest) и автоматизировать ротацию сертификатов и секретов в глобально распределенном парке устройств.

1. Определение границ для хранилищ и HSM

• Создайте региональные Key Vault уровня Premium для секретов/сертификатов приложений и Managed HSM для операций с KEK.
• Обоснование: Хранилища Premium позволяют использовать ключи, защищенные HSM, когда это необходимо; Managed HSM обеспечивает уровень безопасности Level 3 и независимое хранение ключей для операций упаковки (wrapping).

2. Обеспечение восстанавливаемости и защитных механизмов

• Включите защиту от очистки (purge protection) на всех хранилищах и Managed HSM; установите период хранения после обратимого удаления (soft-delete) на 90 дней. Примените Azure Policy для аудита/запрета хранилищ без защиты от очистки.
• Обоснование: Предотвращает катастрофическую потерю данных из-за необратимого удаления; политика гарантирует, что отклонение от конфигурации не может произойти.

3. Централизация авторизации с помощью RBAC

• Установите для хранилищ модель разрешений Azure RBAC. Назначьте роль Key Vault Administrator небольшой команде платформы через PIM; назначьте роль Key Vault Secrets Officer командам приложений в области видимости хранилища; назначьте роль Managed HSM Crypto Officer инженерам по безопасности.
• Обоснование: RBAC + PIM обеспечивают принцип наименьших привилегий, ограниченное по времени повышение прав и согласованный аудит. Разделение обязанностей не позволяет администраторам использовать ключи.

4. Изоляция сети с помощью частных конечных точек (private endpoints)

• Создайте частные конечные точки в центральных виртуальных сетях (hub VNets); отключите публичный доступ к сети. Включите «доверенные службы» только для учетных записей Storage, использующих CMK.
• Обоснование: Частные конечные точки устраняют публичный доступ и блокируют пути для утечки данных, сохраняя при этом необходимые потоки данных между службами и хранилищем.

5. Реализация CMK и стратегии шифрования

• Для Storage определите области шифрования (encryption scopes) для каждой рабочей нагрузки с URI ключей KEK без указания версии в хранилище Premium; для Managed Disks используйте наборы шифрования дисков (Disk Encryption Sets) с CMK из HSM. Включите шифрование на уровне инфраструктуры для двойного шифрования.
• Обоснование: Ключи для каждой рабочей нагрузки уменьшают радиус поражения (blast radius); URI без указания версии обеспечивают бесшовную ротацию; двойное шифрование удовлетворяет строгим требованиям соответствия.

6. Автоматизация ротации ключей и секретов

• Настройте политики ротации ключей AKV (например, ежегодный срок действия, ротация через 9 месяцев) и уведомления Event Grid, которые запускают задания для валидации. Используйте управляемые удостоверения (managed identities) в службах; удалите статические учетные данные.
• Обоснование: Предсказуемая, автоматизированная ротация снижает риск, связанный с долгоживущими ключами и секретами; управляемые удостоверения заменяют хрупкие общие секреты.

7. Ввод сертификатов в эксплуатацию

• Используйте политики сертификатов Key Vault с интеграцией с издателем DigiCert; установите автоматическое продление за 60 дней до истечения срока. Привязывайте сертификаты по ссылке в Application Gateway и App Service.
• Обоснование: Автоматическое продление предотвращает сбои и позволяет избежать ручной обработки ключей; платформенные привязки подхватывают новые версии без повторных развертываний.

8. Валидация и мониторинг

• Включите отправку диагностических журналов Key Vault и Managed HSM в Log Analytics; настройте оповещения о несанкционированных попытках доступа, отказах брандмауэра и событиях скорого истечения срока действия. Проводите ежеквартальные тесты восстановления для резервных копий хранилища и HSM с использованием кворума домена безопасности.
• Обоснование: Непрерывный мониторинг оперативно обнаруживает неверные конфигурации или атаки; тестирование восстановления гарантирует возможность восстановления в стрессовых условиях.

← Безопасность данных · Все домены · Управление состоянием безопасности и корпоративное управление →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →