Справочник - AZ-500 Microsoft Azure Security Engineer Associate

Предоставление доступа just-in-time (JIT) к привилегированным ролям Azure AD, требующего одобрения и обоснования.

Настройте Microsoft Entra Privileged Identity Management (PIM) для роли. Установите "Требовать одобрение для активации", укажите утверждающих, включите "Требовать обоснование при активации" и установите максимальную продолжительность активации.

Почему: PIM - это нативная служба Azure для повышения ролей JIT. Просто сделать пользователя подходящим недостаточно; настройки политики обеспечивают рабочий процесс одобрения и обоснования.

Источник

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

Создайте две политики условного доступа (CA). Политика 1 нацелена на "Всех пользователей", исключая группу поддержки, требуя MFA и соответствующее устройство. Политика 2 нацелена только на группу поддержки, требуя только MFA.

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

Источник

Автоматически реагировать на обнаруженные риски идентификации: блокировать входы с высоким риском и принудительно сбрасывать пароли для пользователей с высоким риском.

Настройте две политики Microsoft Entra ID Protection. Установите "Политику риска входа" на Блокировать доступ при высоком уровне риска. Установите "Политику риска пользователя" на Требовать смены пароля при высоком уровне риска.

Почему: Риск входа связан с одной попыткой аутентификации (в реальном времени), тогда как риск пользователя - это кумулятивный балл о самой идентификации (скомпрометированные учетные данные). Они требуют разных действий по устранению.

Позволить пользователям в гибридной среде идентификации сбрасывать свой облачный пароль и синхронизировать его обратно с локальным Active Directory.

В Microsoft Entra Connect включите функцию "Обратная запись паролей". В Azure AD включите и настройте самостоятельный сброс пароля (SSPR) для целевых пользователей.

Почему: SSPR предоставляет пользовательский интерфейс для сброса пароля на стороне облака, а Password Writeback - это компонент в Entra Connect, который синхронизирует новый хеш пароля обратно в локальный AD.

Периодически проверять доступ всех гостевых пользователей и автоматически удалять гостей, которые больше не одобрены или неактивны.

Создайте проверку доступа (Access Review) в Microsoft Entra ID Governance. Нацельте гостевых пользователей во всех группах, установите повторяющееся расписание (например, ежеквартально) и включите "Автоматическое применение результатов к ресурсу". При желании проверьте неактивных пользователей.

Почему: Проверки доступа - это специализированный инструмент управления для периодической переаттестации доступа. Функция "Автоматическое применение результатов" критически важна для завершения цикла и автоматизации удаления.

Предоставить внешним партнерам возможность самостоятельного запроса пакета доступа (группы, приложения, сайты SharePoint), который автоматически истекает через 90 дней.

Используйте Microsoft Entra Entitlement Management. Создайте Connected Organization для партнера. Создайте Access Package, содержащий ресурсы. Определите политику для пакета, которая позволяет пользователям из подключенной организации запрашивать его с истечением срока действия через 90 дней.

Почему: Entitlement Management предназначен для управления доступом в масштабе, особенно для внешних пользователей. Он объединяет ресурсы и автоматизирует весь жизненный цикл доступа от запроса и одобрения до истечения срока действия и удаления.

Приложение с высоким уровнем безопасности требует от пользователей аутентификации методом, устойчивым к фишингу и атакам типа "человек посередине".

Применяйте методы аутентификации, такие как ключи безопасности FIDO2 или Windows Hello for Business. Эти методы используют криптографию с открытым ключом и привязаны к устройству, предотвращая кражу учетных данных.

Почему: Методы, такие как SMS, голосовые вызовы или простые push-уведомления, подвержены фишингу. FIDO2 и WHfB используют криптографические вызовы, привязанные к источнику запроса, что делает их устойчивыми к фишингу.

Фоновая служба, работающая на виртуальной машине, должна читать все профили пользователей из Microsoft Graph без какого-либо взаимодействия с пользователем.

Зарегистрируйте приложение в Microsoft Entra ID. В разделе разрешений API предоставьте ему разрешения Microsoft Graph "Application" (а не "Delegated") для `User.Read.All`. Администратор должен предоставить административное согласие.

Почему: Разрешения приложения позволяют приложению действовать от своего имени, используя свою собственную идентификацию (ID клиента/секрет или сертификат). Делегированные разрешения требуют контекста вошедшего в систему пользователя, который недоступен в неинтерактивном приложении-демоне.

Разрешить поду в кластере AKS безопасно получать доступ к Azure Key Vault без использования хранимых учетных данных, таких как секреты клиента или сертификаты.

Используйте Azure AD Workload Identity. Создайте управляемое удостоверение, назначаемое пользователем, установите федеративную учетную запись между учетной записью службы K8s и управляемым удостоверением, и предоставьте управляемому удостоверению доступ к Key Vault.

Почему: Workload Identity использует федерацию OIDC для обмена токена Kubernetes на токен Azure AD, полностью устраняя необходимость хранить, управлять или ротировать секреты в кластере.

Источник

Защитить Azure Key Vault, разрешив доступ только из определенных VNets, регистрировать все операции и защищать от случайного удаления критически важных ключей.

Настройте брандмауэр Key Vault так, чтобы он разрешал доступ из "Частной конечной точки и выбранных сетей". Включите диагностическое логирование в рабочую область Log Analytics. Включите как Soft Delete, так и Purge Protection.

Почему: Soft Delete позволяет восстановиться после случайного удаления, но Purge Protection предотвращает даже привилегированному пользователю окончательное удаление хранилища или его содержимого в течение периода хранения. Эта комбинация критически важна для защиты ключей TDE.

Службе Azure App Service необходимо аутентифицироваться в Azure SQL Database для получения данных, не храня пароли строк подключения в конфигурации.

Включите управляемое удостоверение, назначаемое системой, в App Service. В Azure SQL создайте содержащегося пользователя, сопоставленного с именем управляемого удостоверения App Service, и предоставьте ему необходимые роли базы данных (например, db_datareader).

Почему: Управляемое удостоверение предоставляет удостоверение для самого ресурса Azure в Azure AD. Azure автоматически обрабатывает создание и ротацию учетных данных, устраняя хранимые секреты, что является основной лучшей практикой безопасности.

Шифрование управляемых дисков Azure VM в состоянии покоя с использованием ключа, который ваша организация контролирует в Azure Key Vault.

Создайте ресурс Disk Encryption Set. Настройте его на использование ключа, управляемого клиентом (CMK), из вашего Azure Key Vault. Назначьте Disk Encryption Set управляемым дискам VM.

Почему: Это шифрование на стороне сервера (SSE) с CMK, которое шифрует данные в инфраструктуре хранения. Оно проще, чем Azure Disk Encryption (ADE), который использует BitLocker/dm-crypt для шифрования данных внутри гостевой ОС и обычно используется для дисков ОС и данных вместе.

Обеспечить сканирование образов контейнеров, хранящихся в Azure Container Registry (ACR), на наличие уязвимостей перед их развертыванием.

Включите Microsoft Defender for Containers. Это автоматически сканирует образы в ACR при их загрузке, извлечении и на постоянной основе на предмет вновь обнаруженных уязвимостей.

Почему: Эта практика безопасности "сдвига влево" выявляет уязвимости на ранних этапах конвейера CI/CD. Defender for Containers предоставляет эту возможность сканирования нативно в экосистеме Azure.

Обнаружение и получение оповещений о потенциальных SQL-инъекциях и аномальных паттернах доступа к базе данных Azure SQL.

Включите Microsoft Defender for SQL на логическом сервере SQL. Это обеспечивает расширенную защиту от угроз и оценку уязвимостей.

Почему: Defender for SQL - это специализированный план защиты рабочих нагрузок, который использует поведенческую аналитику и машинное обучение для обнаружения угроз, таких как SQL-инъекции, атаки методом перебора и необычный доступ к данным, которые не видны сетевым инструментам.

Ограничить учетную запись хранения определенной VNet, но при этом разрешить доступ к ней доверенным службам Microsoft, таким как Azure Backup.

В сетевых настройках учетной записи хранения выберите "Включено для выбранных виртуальных сетей и IP-адресов". Добавьте требуемую VNet/подсеть. Затем установите флажок "Разрешить доверенным службам Microsoft доступ к этой учетной записи хранения".

Почему: Исключение для доверенных служб создает безопасный путь для определенных служб Microsoft для обхода правил брандмауэра VNet. Без него службы, работающие от имени пользователя (например, Backup или Portal), были бы заблокированы.

Защита определенных конфиденциальных столбцов данных (например, номеров кредитных карт) в базе данных Azure SQL, даже от привилегированных администраторов баз данных (DBA).

Используйте Always Encrypted. Драйвер клиентского приложения прозрачно шифрует данные перед отправкой в базу данных, и ключи шифрования никогда не раскрываются движку базы данных.

Почему: Прозрачное шифрование данных (TDE) шифрует всю базу данных в состоянии покоя (на диске), но DBA с доступом все еще может видеть данные. Always Encrypted обеспечивает шифрование на стороне клиента, разделяя тех, кто управляет данными (DBA), и тех, кто может их видеть.

Обрабатывать высокочувствительные данные на виртуальной машине Azure, обеспечивая их шифрование и защиту даже в памяти от гипервизора и облачных операторов.

Разверните конфиденциальную виртуальную машину Azure (Azure Confidential VM). Эти виртуальные машины используют аппаратные доверенные среды выполнения (TEE), такие как AMD SEV-SNP, для создания изолированного, зашифрованного пространства памяти.

Почему: Стандартное шифрование виртуальных машин (например, ADE или SSE) защищает данные в состоянии покоя. Confidential Computing - единственная технология, которая защищает данные *во время использования* в памяти, обеспечивая высочайший уровень конфиденциальности и изоляции данных в облаке.

Службе App Service требуется использовать секрет из Key Vault в качестве настройки приложения, не изменяя код приложения для использования Key Vault SDK.

Включите управляемое удостоверение в App Service и предоставьте ему разрешения "Get" на секреты в Key Vault. В конфигурации App Service создайте настройку приложения со значением, отформатированным как ссылка на Key Vault: `@Microsoft.KeyVault(SecretUri=...)`.

Почему: Эта функция позволяет платформе App Service разрешать значение секрета во время выполнения, используя управляемое удостоверение. Код приложения просто считывает стандартную переменную среды, абстрагируя взаимодействие с Key Vault.

Хранить данные, связанные с соответствием требованиям, в Azure Blob Storage в состоянии WORM (Write-Once, Read-Many) в течение 7 лет.

Для контейнера хранения настройте политику неизменяемости. Используйте политику хранения на основе времени, установленную на 7 лет, и заблокируйте политику. После блокировки данные не могут быть изменены или удалены кем-либо до истечения периода хранения.

Почему: Эта функция специально разработана для удовлетворения требований нормативного соответствия (например, SEC 17a-4). Блокировка политики является критическим шагом, который делает ее по-настоящему неизменяемой.

В многопользовательском приложении, использующем одну базу данных Azure SQL, убедитесь, что пользователи из одного клиента могут видеть только данные, принадлежащие их собственному клиенту.

Реализуйте безопасность на уровне строк (RLS). Создайте политику безопасности с предикатной функцией, которая фильтрует строки на основе идентификатора клиента пользователя, который хранится в контексте сеанса или в таблице поиска пользователей.

Почему: RLS применяет логику доступа непосредственно в движке базы данных. Это более безопасно и надежно, чем реализация фильтрации на уровне приложения, поскольку ее невозможно обойти, и она прозрачна для кода приложения.

Защита виртуальных машин поколения 2 от буткитов и руткитов путем обеспечения целостности всей цепочки загрузки от UEFI до ядра ОС.

Создайте виртуальную машину с включенной функцией Trusted Launch. Это активирует Secure Boot, который проверяет подписи всех компонентов загрузки, и виртуальный Trusted Platform Module (vTPM) для измеренной загрузки и аттестации.

Почему: Trusted Launch решает проблемы сложного, низкоуровневого вредоносного ПО, которое может подорвать традиционные средства контроля безопасности на уровне ОС. Он устанавливает аппаратный корень доверия для виртуальной машины.

Изолировать трафик между уровнями приложений (веб, приложение, данные), размещенными в отдельных подсетях.

Создайте выделенную группу безопасности сети (NSG) для каждой подсети. В каждой NSG создайте входящие правила, которые разрешают трафик только из исходного диапазона IP-адресов предыдущего уровня по требуемому порту. (например, NSG уровня приложения разрешает TCP/8080 из подсети веб-уровня).

Почему: Применение уникальной NSG с наименьшими привилегиями к каждой подсети обеспечивает многоуровневую защиту и гранулированный контроль над трафиком "восток-запад", что более безопасно, чем одна сложная NSG для VNet.

В топологии "звезда" принудительно направлять весь трафик между связанными виртуальными сетями (spoke VNets) для проверки NVA или Azure Firewall в центральном хабе.

В каждой подсети-спутнике (spoke subnet) создайте определяемый пользователем маршрут (UDR) для адресных пространств других спутников с типом следующего перехода "VirtualAppliance" и IP-адресом NVA/Firewall. Включите IP-пересылку на сетевом адаптере NVA.

Почему: По умолчанию пиринг VNet позволяет спутникам общаться напрямую. UDRs переопределяют это поведение маршрутизации по умолчанию, принудительно направляя трафик к центральной точке проверки.

Предоставить службе PaaS (например, Azure SQL, Storage) частный IP-адрес внутри вашей VNet, гарантируя, что трафик никогда не проходит через общедоступный интернет.

Создайте Private Endpoint для службы PaaS в вашей VNet. Критически важно: в сетевых настройках службы PaaS отключите доступ к общедоступной сети, чтобы заблокировать публичную конечную точку.

Почему: Private Endpoint "внедряет" службу в вашу VNet с частным IP-адресом. Service Endpoint просто оптимизирует маршрут по магистрали Azure к публичному IP-адресу. Отключение публичного доступа требуется для обеспечения только частной связи.

Разрешить исходящий трафик от виртуальных машин к динамическому набору конечных точек служб Microsoft, таких как Windows Update, без ручного ведения списков IP-адресов.

В Azure Firewall создайте коллекцию правил приложений. Добавьте правило с типом целевого FQDN, установленным на "FQDN Tag", и выберите тег "WindowsUpdate".

Почему: FQDN Tags - это курируемые коллекции FQDN, которыми управляет Microsoft. Это правильный способ разрешить доступ к службам PaaS, чьи базовые IP-адреса часто меняются. Service Tags предназначены для правил на основе IP-адресов.

Брандмауэр веб-приложений (WAF) блокирует легитимный трафик к вашему приложению из-за ложного срабатывания управляемого правила (например, SQL-инъекция).

В политике WAF сохраните WAF в режиме предотвращения (Prevention mode). Найдите управляемое правило, которое блокирует трафик, и настройте исключение для конкретного заголовка запроса, куки или параметра тела, который вызывает ложное срабатывание.

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

Предоставить безопасный доступ по RDP/SSH к виртуальным машинам Azure, не открывая порты управления в Интернет и не требуя общедоступных IP-адресов на виртуальных машинах.

Разверните Azure Bastion (SKU Standard для расширенных функций) в выделенной подсети в VNet. Доступ к виртуальным машинам осуществляется через портал Azure, который подключается через службу Bastion.

Почему: Bastion действует как защищенный "jump box", обеспечивая подключение RDP/SSH. Единственный общедоступный IP-адрес находится на самой службе Bastion, которая защищена и управляется Microsoft, что значительно снижает поверхность атаки ваших виртуальных машин.

Предоставить разработчикам ограниченный по времени, аудитируемый доступ к портам управления (RDP/SSH) на виртуальных машинах разработки.

Включите Microsoft Defender for Cloud и настройте доступ к виртуальным машинам Just-in-Time (JIT). Пользователи будут запрашивать доступ через Defender for Cloud, который динамически изменяет правила NSG, чтобы разрешить доступ на ограниченное время с определенного IP-адреса.

Почему: JIT - это основная функция Defender for Cloud, которая укрепляет сетевую позицию виртуальных машин, по умолчанию оставляя порты управления закрытыми и открывая их только по запросу.

Применять лучшие практики безопасности, такие как запрет привилегированных контейнеров, в кластере Azure Kubernetes Service (AKS) во время развертывания.

Включите надстройку Azure Policy для AKS. Назначьте встроенную инициативу политики под названием "Kubernetes cluster pod security restricted standards for Linux-based workloads".

Почему: Это использует Azure Policy как централизованный контроллер допуска в масштабе для Kubernetes, обеспечивая соблюдение правил безопасности и соответствия до того, как рабочие нагрузки будут созданы в кластере.

Маршрутизация всего интернет-трафика из Azure VNet обратно к локальному устройству безопасности для проверки, прежде чем он достигнет интернета.

Настройте VPN типа "сайт-сайт" или ExpressRoute. Создайте определяемый пользователем маршрут (UDR) для префикса адреса 0.0.0.0/0 и установите следующий хоп на Virtual Network Gateway.

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

Проверять исходящий TLS-зашифрованный трафик от виртуальных машин на наличие угроз с помощью Azure Firewall.

Разверните Azure Firewall Premium. Включите проверку TLS (TLS Inspection) и обнаружение вторжений (IDPS). Настройте подчиненный CA-сертификат на брандмауэре и разверните его открытый ключ на клиентских виртуальных машинах в качестве доверенного корневого CA.

Почему: Для проверки зашифрованного трафика брандмауэр должен выполнять операцию "человек посередине". Это требует SKU Premium, IDPS для обнаружения угроз и правильной инфраструктуры сертификатов, чтобы избежать ошибок TLS на клиентских машинах.

Защитить все общедоступные приложения в нескольких VNets и подписках от объемных DDoS-атак экономически эффективным способом.

Создайте единый план защиты от DDoS-атак Azure (Azure DDoS Protection Plan). Свяжите этот план со всеми виртуальными сетями, содержащими общедоступные IP-адреса, нуждающиеся в защите.

Почему: Один план защиты от DDoS может охватывать до 100 VNets, и вы платите фиксированную ежемесячную плату за план, а не за VNet или за IP. Эта централизованная модель гораздо более экономична, чем развертывание нескольких планов или использование SKU защиты на каждый IP-адрес.

Когда в Microsoft Sentinel создается инцидент высокой степени серьезности, автоматически отключать учетную запись затронутого пользователя в Azure AD и уведомлять команду безопасности в Teams.

Создайте правило автоматизации (Automation Rule), которое срабатывает при создании инцидента высокой степени серьезности. Правило должно вызывать Playbook (Logic App). Playbook использует коннектор Azure AD для отключения пользователя и коннектор Teams для публикации сообщения.

Почему: Это демонстрирует шаблон SOAR (Security Orchestration, Automation, and Response). Automation Rule - это движок триггеров/условий, а Playbook - это движок действий/рабочих процессов.

Источник

Применять согласованный набор политик безопасности и включать планы Defender for Cloud для большого количества подписок Azure.

Организуйте все подписки в Группу управления (Management Group). Назначьте инициативу политики Azure Security Benchmark и включите требуемые планы Defender for Cloud на уровне группы управления.

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

Создать пользовательское обнаружение в Sentinel для пользователя, входящего в систему из новой страны в первый раз.

Создайте запланированное правило аналитики запросов. Используйте KQL-запрос, который объединяет недавние `SigninLogs` с суммированной историей прошлых `SigninLogs` для выявления ранее невиданных комбинаций UserPrincipalName/Country.

Почему: Запланированные правила запросов с KQL являются основой пользовательского обнаружения угроз в Sentinel, позволяя использовать сложную, поддерживающую состояние логику, которая выходит за рамки простого сопоставления событий.

Хранить журналы безопасности в Sentinel в течение 2 лет для соответствия требованиям, но при этом сохранять только последние 90 дней для быстрых интерактивных запросов для управления расходами.

В рабочей области Log Analytics установите "Интерактивное хранение" на 90 дней. Установите "Общее хранение" (Архив) на 730 дней (2 года). При необходимости настройте политики хранения для каждой таблицы.

Почему: Этот многоуровневый подход балансирует стоимость и возможности. Интерактивный уровень дорог, но быстр. Уровень архива очень дешев для долгосрочного хранения. Архивированные данные все еще могут быть запрошены через асинхронные задания поиска или временно восстановлены.

Во время расследования инцидента вам необходимо быстро визуализировать взаимосвязи между скомпрометированным пользователем, IP-адресом, с которого он вошел, и ресурсами, к которым он обращался.

Со страницы инцидента в Microsoft Sentinel откройте граф расследования (Investigation Graph). Используйте граф для визуального изучения сущностей и их связей между различными оповещениями и источниками журналов.

Почему: Граф расследования - это мощный инструмент визуализации, который отображает хронологию атаки, значительно упрощая понимание масштаба и временных рамок инцидента, чем ручное сопоставление событий в запросах журналов.

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

Убедитесь, что User and Entity Behavior Analytics (UEBA) включен в Microsoft Sentinel и что соответствующие источники данных (журналы Azure AD, Defender for Endpoint/Security Events) подключены. Отслеживайте UEBA на предмет обнаружения аномалий, связанных с боковым перемещением.

Почему: UEBA создает базовый уровень нормального поведения для каждого пользователя и сущности. Он отлично подходит для обнаружения отклонений, указывающих на боковое перемещение, таких как первый доступ пользователя к серверу или использование необычных протоколов, которые трудно заметить с помощью статических правил.

Сократить затраты на прием данных Microsoft Sentinel для объемных, подробных журналов, которые необходимы для соответствия требованиям, но не для аналитики в реальном времени.

Настройте план таблицы для этих журналов на "Basic Logs". Кроме того, используйте правила сбора данных (DCRs) с запросами XPath или другими преобразованиями для фильтрации шумных, малоценных событий до приема.

Почему: Basic Logs предлагают значительно более низкую стоимость приема в обмен на ограниченные возможности запросов и более короткий срок хранения. Фильтрация на источнике с помощью DCRs является наиболее эффективным способом уменьшения объема, предотвращая попадание нежелательных данных в рабочую область.

Автоматически применять параметры безопасности, например, включение "Требуется безопасная передача" для всех существующих и новых учетных записей хранения Azure.

Назначьте политику Azure с эффектом `DeployIfNotExists` или `Modify`. Для существующих несоответствующих ресурсов создайте задачу исправления из раздела соответствия политики, чтобы применить изменение.

Почему: Политики аудита и отказа только сообщают или блокируют несоответствие. `DeployIfNotExists` и `Modify` с задачами исправления активно исправляют неправильные конфигурации, делая политику мощным инструментом для автоматизированного управления и усиления безопасности.

Обнаружение угроз во время выполнения в кластере AKS, таких как подозрительное выполнение процессов или подключение контейнера к известному вредоносному IP-адресу.

Включите Microsoft Defender for Containers. Это развертывает DaemonSet (агент Defender) на каждом узле в кластере, который собирает сигналы безопасности с хоста и контейнеров для обеспечения обнаружения угроз в реальном времени.

Почему: В то время как сканирование ACR обеспечивает безопасность "сдвига влево", защита во время выполнения имеет решающее значение для обнаружения угроз, возникающих после развертывания. Defender for Containers предоставляет эту видимость на уровне хоста и рабочей нагрузки в кластере.