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 Storage, Azure SQL и Azure Cosmos DB, выбрать правильную стратегию для удостоверений и ключей, а также предотвратить эксфильтрацию данных. Каждый описанный элемент управления сопровождается операционным обоснованием, чтобы вы могли аргументировать и поддерживать конфигурацию в производственной среде.

Защита учетных записей хранения Azure и доступа к данным

Авторизация и совместное использование учетной записи хранения

• Azure RBAC для Azure Storage: Предпочитайте авторизацию на основе Azure AD (для Blob и Queue) с использованием встроенных ролей, таких как Storage Blob Data Reader/Contributor. Обоснование: доступ на основе токенов, ограниченный по времени через условный доступ (Conditional Access), регистрируемый в Entra ID; позволяет избежать использования бессрочных ключей учетной записи и поддерживает JIT-назначение (just-in-time).
• Общие ключи: Первичный/вторичный ключи учетной записи предоставляют полные права на плоскость данных. Отключите использование ключей в коде и часто их ротируйте. Обоснование: общие ключи — это секреты-носители (bearer secrets) без привязки к пользователю или условному доступу; компрометация означает полную утечку данных.
• Типы SAS:
  • SAS для службы: Предоставляет ограниченный доступ к конкретным ресурсам (blob, file, queue, table) с разрешениями, ограничениями по IP, протоколу и времени. Обоснование: точное соблюдение принципа наименьших привилегий для приложений, которые не могут использовать токены AD.
  • SAS для учетной записи: Более широкая область действия (например, между службами); используйте с осторожностью. Обоснование: увеличивает радиус поражения в случае утечки.
  • SAS с делегированием пользователя: Выпускается с использованием Azure AD и ключа делегирования пользователя для Blob. Обоснование: привязывается к удостоверению Azure AD и условному доступу (CA); обеспечивает превосходные возможности аудита и отзыва.
• Сохраненные политики доступа: Определяют многоразовые ограничения (срок действия, разрешения) для SAS на контейнерах/общих ресурсах; отзыв или обновление политики делает недействительными все SAS, выпущенные на ее основе. Обоснование: централизованный отзыв без необходимости пересоздавать токены, встроенные в клиенты.

Пример: создание SAS с делегированием пользователя для blob-объекта с помощью Azure AD

az storage blob generate-sas \
  --account-name mystorage \
  --container-name data \
  --name report.csv \
  --permissions r \
  --expiry 2026-12-31T23:59Z \
  --as-user \
  --auth-mode login

Безопасность служб по типам

• Blob/Queue/Table: Используйте Azure AD RBAC там, где это поддерживается (Blob, Queue). Установите AllowBlobPublicAccess в false, требуйте HTTPS, включите версионирование и обратимое удаление (soft delete). Обоснование: устраняет пути анонимного доступа и обеспечивает возможность восстановления.
• Azure Files: Используйте Azure AD Kerberos для SMB с Entra ID (или интеграцией с AD DS) и применяйте принцип наименьших привилегий для разрешений на уровне общих ресурсов/файлов. Требуйте шифрование SMB. Обоснование: доступ, привязанный к удостоверению, с транспортной безопасностью по SMB; отсутствие общих ключей в пространстве пользователя.
• Служба таблиц (Table service): Используйте SAS со строгими ограничениями по IP/времени и избегайте SAS для учетной записи. Обоснование: гранулярность на уровне службы не так высока; агрессивно сужайте область действия.

Сетевая изоляция для всех служб хранения

• Правила брандмауэра хранилища: Ограничивайте доступ только выбранными диапазонами публичных IP-адресов, когда использование Private Link невозможно. Обоснование: уменьшает поверхность атаки, но трафик все равно проходит через публичный интернет.
• Частные конечные точки (Private endpoints): Предпочитайте Private Link для Blob, Queue, Table и Files. Сопоставьте частные зоны DNS с именами конкретных ресурсов. Установите для доступа из общедоступной сети значение Disabled (Отключено). Обоснование: трафик остается в магистральной сети Azure; подлинность ресурса проверяется через частный DNS; снижает риск эксфильтрации данных в похожие службы.
• Конечные точки служб и политики: Если Private Link недоступен, включите конечные точки служб и примените политики конечных точек служб, чтобы ограничить исходящий трафик только определенными учетными записями хранения. Обоснование: ограничивает трафик даже при его выходе из виртуальной сети; снижает риск отправки данных на учетные записи, принадлежащие злоумышленникам.

Операционные настройки для стандартизации

• Принудительно использовать только HTTPS, минимальная версия TLS 1.2.
• Отключить доступ по общим ключам для Blob и Queue при использовании AD (зависит от поддержки функции).
• Политики неизменяемости для критически важных контейнеров/общих ресурсов для соблюдения нормативных требований по хранению и устойчивости к программам-вымогателям.

Шифрование и управление ключами

Уровни шифрования неактивных данных

• Ключи, управляемые службой (SMK): Серверное шифрование по умолчанию, управляемое Azure. Обоснование: нулевые операционные издержки; подходит для многих рабочих нагрузок.
• Ключи, управляемые клиентом (CMK): Ключи в Key Vault или Managed HSM для Storage, SQL и Cosmos DB. Обоснование: вынесенная за пределы службы граница доверия, контроль клиента над ротацией/отзывом и подтверждение соответствия требованиям.
• Инфраструктурное шифрование (двойное шифрование): Дополнительный уровень с использованием отдельных ключей. Обоснование: глубокоэшелонированная защита на случай обхода шифрования носителя или компрометации криптографической границы.

Ротация ключей и операции с ними

• SMK ротируются автоматически; никаких действий не требуется.
• CMK ротируются путем создания новой версии ключа, предоставления разрешений на wrap/unwrap и перенаправления ресурса на последнюю версию (или на ссылку на ключ без версии, если это поддерживается). Обоснование: ротация без прерывания работы с аудируемым изменением.
• Защищайте ключи с помощью обратимого удаления (soft delete) и защиты от очистки (purge protection) в Key Vault; управляйте административным доступом через RBAC, а доступом к плоскости данных — через политики доступа или RBAC (для Managed HSM используйте RBAC). Обоснование: предотвращает необратимую потерю ключей и обеспечивает соблюдение принципа наименьших привилегий.

Пример: установка CMK для учетной записи хранения

az storage account update \
  --name mystorage \
  --resource-group rg-secure \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.KeyVault/vaults/mykv \
  --encryption-key-name stor-cmk

Области шифрования

• Используйте области шифрования для каждого контейнера в Storage, когда разные наборы данных требуют отдельных ключей. Обоснование: сегментирует радиус поражения и позволяет использовать разные жизненные циклы ключей.

Безопасность платформ баз данных: Azure SQL и Azure Cosmos DB

Аутентификация и доступ в Azure SQL

• Аутентификация Microsoft Entra: Создайте администратора Azure AD на уровне сервера; используйте автономных пользователей базы данных (CREATE USER FROM EXTERNAL PROVIDER). Обоснование: позволяет избежать использования логинов/паролей SQL и задействовать Conditional Access и PIM.
• Автономные пользователи: Идентификационные данные хранятся в самой базе данных, а не в master. Обоснование: упрощает геовосстановление и отработку отказа (failover) без необходимости повторного создания логинов.
• Правила брандмауэра: Избегайте широких правил для IP-адресов клиентов; отдавайте предпочтение Private Link с отключенным доступом из публичной сети. Если правила для IP все же необходимы, ограничьте их точными адресами и автоматизируйте проверку. Обоснование: сужает поверхность атаки и снижает вероятность обнаружения через публичные конечные точки.
• Частные конечные точки (Private endpoints): Направляйте весь трафик плоскости данных (data-plane) через VNet с частным DNS. Обоснование: исключает публичное размещение и упрощает предотвращение утечки данных.
• Паттерны аутентификации: Используйте интегрированную аутентификацию Active Directory (для устройств, присоединенных к домену) или интерактивный/device code для получения токенов; рабочие нагрузки служб должны использовать управляемые удостоверения (managed identities). Обоснование: избавляет от паролей и позволяет управлять временем жизни токенов и политиками.

Функции защиты данных

• Прозрачное шифрование данных (TDE): Включено по умолчанию; шифрует данные, журналы и резервные копии. Обоснование: защищает неактивные данные (at-rest) на носителях без внесения изменений в приложение. Используйте TDE с ключами, управляемыми клиентом (CMK), для внешнего контроля.
• Always Encrypted: Шифрование на стороне клиента для конфиденциальных столбцов с ключами в Key Vault. Обоснование: не позволяет операторам SQL или самому движку видеть данные в открытом виде; используйте для полей с PII/PCI.
• Динамическое маскирование данных (DDM): Маскирует результаты запросов для непривилегированных пользователей. Обоснование: снижает вероятность случайного раскрытия данных, но не является средством разграничения безопасности; используйте в сочетании с RBAC.
• Аудит: Отправляйте данные в Log Analytics, Event Hubs или Storage. Обоснование: создает неизменяемый журнал для расследований и соответствия требованиям.

Пример: включение аудита на уровне сервера с отправкой в Log Analytics

az sql server audit-policy update \
  --name sql-secure \
  --resource-group rg-secure \
  --state Enabled \
  --log-analytics-workspace /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.OperationalInsights/workspaces/la-secure

Microsoft Defender for SQL

• Оценка уязвимостей (Vulnerability Assessment, VA): Создает базовые конфигурации и сканирует схему/настройки; экспортирует результаты в хранилище; интегрируется с проверками в DevSecOps. Обоснование: обеспечивает постоянную гигиену и обнаружение отклонений с четкими рекомендациями по исправлению.
• Обнаружение угроз (Threat Detection): Обнаруживает SQL-инъекции, аномальные входы в систему, вход из незнакомого местоположения, злоупотребление привилегиями. Обоснование: управляемое обнаружение с низкими операционными издержками; дополняет средства сетевого контроля.
• Реагирование на оповещения: Направляйте в Logic Apps, на электронную почту, в SIEM. Создавайте сценарии реагирования (playbooks) для сортировки, приостановки пользователей, отзыва токенов и ужесточения правил брандмауэра. Обоснование: формализованное реагирование сокращает среднее время сдерживания угрозы.

Безопасность Azure Cosmos DB

• Ключи и токены: Первичные/вторичные ключи имеют высокие привилегии; регулярно их ротируйте. Для операций с плоскостью данных (data-plane) предпочитайте Azure AD RBAC с ролями, такими как Cosmos DB Built-in Data Contributor/Reader. Обоснование: доступ, привязанный к удостоверению, с возможностью применения CA и аудита.
• Сетевой контроль: Список разрешенных IP-адресов в брандмауэре для непредвиденных обстоятельств; Private Endpoints как основной путь; по возможности отключайте публичный доступ. Обоснование: гарантированный контроль пути и проверка конечной точки.
• Шифрование: Шифрование неактивных данных (at rest) включено по умолчанию; включите CMK для дополнительного контроля. Обоснование: соответствует внешним криптографическим требованиям и принципу разделения обязанностей.
• Журналы диагностики и метрики: Включите категории DataPlaneRequests, ControlPlaneRequests и специфичные для API (например, MongoRequests). Обоснование: сквозная наблюдаемость для анализа паттернов доступа, регулирования (throttling) и аномальных запросов.

Мониторинг, классификация и контроль эксфильтрации

Секреты и строки подключения, управляемые через Key Vault

• Используйте управляемые удостоверения для получения секретов/ключей во время выполнения; никогда не храните секреты в коде или настройках. Обоснование: устраняет разрастание учетных данных и необходимость ротации секретов в приложениях.
• Ссылка на Key Vault в App Service/Functions

ConnectionStrings__Sql=@Microsoft.KeyVault(SecretUri=https://mykv.vault.azure.net/secrets/sql-connstr/)

• По возможности отдавайте предпочтение токенам доступа Azure AD для SQL вместо строк подключения на основе секретов. Обоснование: более строгие политики и возможности отзыва.

Защита информации и классификация данных

• Метки конфиденциальности Microsoft Purview Information Protection: применяйте метки с шифрованием и правами использования для документов и электронных писем; интегрируйте с автоматической установкой меток. Обоснование: постоянная защита за пределами хранилища.
• SQL Information Protection (Azure SQL): используйте встроенные средства обнаружения и классификации данных, рекомендуйте метки для столбцов и экспортируйте в Purview. Обоснование: централизованное управление и согласованная политика для всех данных.

Средства контроля эксфильтрации данных и шаблоны безопасного доступа

• Private Link в первую очередь: для Storage, SQL и Cosmos DB. Отключите публичные конечные точки. Обоснование: предотвращает доступ из публичного интернета и обеспечивает прохождение трафика только из утвержденных VNet.
• Фильтрация исходящего трафика (Egress): используйте Azure Firewall с тегами FQDN и правилами DNAT, разрешающими только необходимые конечные точки Azure; добавляйте политики для конечных точек служб (service endpoint policies), где использование Private Link нецелесообразно. Обоснование: использование разрешающего списка для исходящего трафика блокирует утечку данных на конечные точки, контролируемые злоумышленниками.
• Правила для экземпляров ресурсов: в брандмауэре Storage разрешайте доступ только определенным доверенным экземплярам ресурсов (например, рабочей области Synapse). Обоснование: привязывает доступ к известным источникам/потребителям данных, а не только к сетям.
• Усиление защиты SAS: по возможности используйте SAS с делегированием пользователя, ограничивайте доступ по HTTPS, IP-адресам, предоставляйте минимальные разрешения и кратчайшее время жизни; привязывайте к сохраненным политикам доступа для возможности отзыва. Обоснование: снижает риск неправомерного использования токена и упрощает его экстренную деактивацию.
• AKS и конечные точки служб: если вы используете конечные точки служб, применяйте Azure CNI, чтобы поды получали IP-адреса из VNet и наследовали доступ через конечные точки. Обоснование: это позволяет применять нативные средства контроля VNet к трафику контейнеров; в противном случае конечные точки не применяются к трафику подов, проходящему через NAT.
• Сбор логов и аналитика: включите отправку диагностических логов Storage, SQL и Cosmos DB в Log Analytics; создайте оповещения об аномальном объеме данных, всплесках выдачи SAS и частых ошибках 403. Обоснование: раннее обнаружение попыток эксфильтрации данных.

Практический сценарий

Компании Spotify необходимо предотвратить эксфильтрацию данных из подсетей разработчиков и рабочих нагрузок AKS на неавторизованные конечные точки Storage и SQL, обеспечив при этом возможность запуска интеграционных тестов в конвейерах CI/CD.

1. Отключить публичный сетевой доступ и создать Private Endpoints для всех производственных учетных записей Storage и серверов Azure SQL. Обоснование: направляет все потоки плоскости данных через Private Link, устраняя публичный входящий/исходящий трафик и обеспечивая строгий контроль источника через VNet и частные DNS-зоны.

2. Настроить частные DNS-зоны с A-записями, сопоставляющими FQDN ресурсов хранилища и базы данных с IP-адресами частных конечных точек; привязать все необходимые VNet. Обоснование: предотвращает утечку DNS-запросов на публичные конечные точки и гарантирует, что клиенты разрешают имена в IP-адреса нужных частных ресурсов.

3. В брандмауэрах Storage добавить правила для экземпляров ресурсов только для удостоверений производственного кластера AKS и масштабируемого набора агентов сборки; установить действие по умолчанию на «запретить» (deny). Обоснование: даже в пределах одной VNet доступ к учетной записи могут получить только утвержденные удостоверения ресурсов, что предотвращает горизонтальное перемещение и эксфильтрацию из недоверенных рабочих нагрузок.

4. Принудительно использовать Azure CNI в AKS и включить конечные точки служб с политиками (service endpoint policies), чтобы разрешить пространствам имен для разработки доступ только к выделенной непроизводственной учетной записи хранения. Обоснование: поды разработки получают IP-адреса из VNet, что позволяет применять сетевые политики; политики конечных точек строго ограничивают любой не-приватный трафик только разрешенными учетными записями.

5. Заменить общие ключи доступом на основе ролей Azure AD (RBAC) для Blob и Queue в коде приложений; там, где совместное использование для тестов неизбежно, выдавать SAS с делегированием пользователя с сохраненными политиками доступа и сроком действия 1 час. Обоснование: токены, привязанные к удостоверениям, можно аудировать и отзывать; короткоживущие SAS минимизируют риск, если токен попадет в логи сборки.

6. Включить Defender for SQL с обнаружением угроз и оценкой уязвимостей (Vulnerability Assessment); направлять оповещения и аудиторские логи SQL в центральную рабочую область Log Analytics с автоматизированными Logic Apps для реагирования (отключение пользователя, отзыв сессий, добавление временного запрещающего правила в брандмауэр). Обоснование: управляемые средства обнаружения ускоряют сдерживание SQL-инъекций и аномального доступа, а сценарии автоматизации (playbooks) стандартизируют и ускоряют реагирование.

7. Использовать Key Vault для ключей, управляемых клиентом (CMK), защищающих TDE и области шифрования (encryption scopes) в Storage; включить обратимое удаление (soft delete) и защиту от очистки (purge protection); ежеквартально ротировать ключи и обновлять ссылки на ресурсы до последней версии ключа. Обоснование: вынесенный вовне криптографический контроль с безопасной ротацией соответствует требованиям комплаенса и снижает риск операционных ошибок.

8. Классифицировать конфиденциальные столбцы в Azure SQL с помощью SQL Information Protection и подключить к Microsoft Purview; применять метки конфиденциальности MIP для последующего экспорта данных. Обоснование: постоянная маркировка сохраняется при извлечении данных, ограничивая неправомерное использование и позволяя инструментам DLP применять средства контроля в различных инструментах и на устройствах.

9. Заблокировать исходящий трафик с помощью Azure Firewall, разрешив доступ только к службам Azure, необходимым для сборки/тестирования, используя теги FQDN для Storage и SQL и запретив исходящий трафик по HTTP(S) с использованием wildcard. Обоснование: модель позитивной безопасности гарантирует, что трафик может достигать только утвержденных конечных точек, предотвращая утечку данных на домены злоумышленников.

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

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

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

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