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.

Обзор

Управление идентификацией и доступом (IAM) в Microsoft Azure сосредоточено вокруг Microsoft Entra ID (ранее Azure AD). Оно определяет, кто, к каким ресурсам, при каких условиях и с какими привилегиями может получить доступ. Эффективная архитектура IAM минимизирует постоянные привилегии, обеспечивает условный и основанный на риске доступ, а также внедряет современную аутентификацию как для людей, так и для рабочих нагрузок, поддерживая при этом сценарии гибридного и внешнего взаимодействия.

Конструкции и области действия удостоверений в Microsoft Entra

• Клиенты, пользователи и группы
  • Клиент (tenant) представляет собой границу идентификации и структуру доверия вашей организации. Пользователи могут быть учетными записями участников или гостевыми (B2B). Используйте группы безопасности для авторизации и группы Microsoft 365 для функций совместной работы; предпочитайте динамические группы, чтобы сократить ручное управление членством.
• Административные единицы (AU)
  • AU позволяют делегировать роли каталога для подмножества пользователей/устройств (например, региональная служба поддержки может управлять только пользователями из Европы). Это поддерживает принцип наименьших привилегий для задач каталога.
• Роли каталога и области назначения ролей
  • Роли каталога (например, Глобальный администратор, Администратор пользователей) применяются к ресурсам Microsoft Entra. По возможности ограничивайте область действия ролей каталога до уровня AU, чтобы уменьшить радиус поражения. Роль Глобального администратора необходима для первоначальной настройки Privileged Identity Management (PIM).
• Области действия управления доступом на основе ролей Azure (Azure RBAC)
  • Azure RBAC управляет доступом к ресурсам Azure. Назначайте роли на уровне группы управления, подписки, группы ресурсов или отдельного ресурса. Наследование происходит сверху вниз; всегда выбирайте самую узкую практическую область действия, чтобы уменьшить избыточные привилегии.
• Операционное обоснование
  • Разделяйте роли каталога (Entra) и Azure RBAC (авторизация ресурсов). Используйте AU и узкие области действия RBAC, чтобы ограничить административный доступ, сократить возможности для бокового перемещения и упростить проверки доступа.

Управление доступом с помощью Azure RBAC и принципа наименьших привилегий

• Встроенные роли и принцип наименьших привилегий
  • Предпочитайте наиболее специфичную встроенную роль, подходящую для задачи. Пример: предоставьте доступ только для извлечения образов контейнеров с помощью роли AcrPull и доступ для загрузки/отправки с помощью AcrPush вместо широкой роли Contributor. Для Key Vault предоставляйте административный контроль через RBAC только администраторам хранилища, используя гранулярные политики доступа для конкретных операций с объектами, таких как управление сертификатами.
• Наследование назначений ролей
  • Назначайте роли на минимально возможном уровне. Назначения на уровне группы управления или подписки каскадируются; избегайте широких, унаследованных прав, если это не сделано намеренно. Когда вам нужен единообразный RBAC для нескольких подписок, применяйте согласованные назначения ролей через Azure Blueprints (или современные альтернативы IaC) вместо ручного назначения в PIM.
• Запрещающие назначения
  • Запрещающие назначения явно блокируют действия независимо от разрешающих назначений и обычно создаются службами Azure, такими как Azure Policy или Blueprints. Используйте их для применения непреложных защитных механизмов (например, для предотвращения правил публичной сети для чувствительных ресурсов).
• Пользовательские роли
  • Когда встроенные роли слишком широки, определяйте пользовательские роли только с необходимыми действиями. Проверяйте их с помощью тестирования на соответствие принципу наименьших привилегий и проверок доступа.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

• Операционное обоснование
  • Ограничение области действия RBAC и пользовательские роли сокращают избыточные права и поверхность аудита. Запрещающие назначения кодируют «жесткие» требования соответствия, которые нельзя обойти из-за ошибочно широких разрешающих назначений, повышая устойчивость состояния безопасности.

Привилегированный доступ, условный доступ и Identity Protection

• Privileged Identity Management (PIM)

  • Допустимые и активные назначения: допустимые назначения не предоставляют постоянных разрешений; пользователи должны активировать их по принципу JIT (Just-In-Time), чтобы стать активными. Требуйте утверждение, обоснование и MFA при активации; устанавливайте ограниченную продолжительность и требуйте ссылки на заявки для прослеживаемости. Начните с обнаружения привилегированных ролей, чтобы понять текущий уровень уязвимости. Используйте периодические проверки доступа, в идеале с владельцами ресурсов или групп в качестве рецензентов, для подтверждения постоянной необходимости.

• Условный доступ (CA)

  • Назначения нацелены на пользователей/группы, удостоверения рабочих нагрузок, облачные приложения и действия. Условия включают риск входа, платформу/состояние устройства, местоположения, клиентские приложения и фильтры для устройств и приложений. Элементы управления доступом могут требовать MFA, соответствующие требованиям или гибридно присоединенные к Azure AD устройства, политики защиты приложений или принятие условий использования. Элементы управления сеансом ограничивают частоту входа, постоянные сеансы и ограничения, применяемые приложениями (например, только веб-доступ для SharePoint). Используйте режим «только отчет», чтобы безопасно оценить влияние политики перед ее применением. Поддерживайте исключения для аварийных учетных записей и поэтапного развертывания, чтобы предотвратить блокировки.

• Identity Protection

  • Риск пользователя отражает вероятность компрометации учетной записи; риск входа отражает вероятность того, что конкретный сеанс является рискованным. Настройте политики для требования безопасного устранения угроз:
    • Пользователи с утекшими учетными данными: считайте это высоким риском пользователя; принудительно сбрасывайте пароль и блокируйте доступ до устранения проблемы.
    • Входы с IP-адресов с подозрительной активностью: считайте это как минимум средним риском входа; требуйте MFA или блокируйте доступ к чувствительным приложениям.
  • Интегрируйте с CA для адаптации уровня доверия в реальном времени. Отслеживайте историю рисков и их устранение для оценки эффективности.

• Операционное обоснование

  • PIM устраняет постоянные привилегии и обеспечивает строгую, аудируемую активацию. CA и Identity Protection применяют принцип нулевого доверия — проверяя каждую попытку доступа на основе пользователя, устройства, сеанса и риска, — что снижает вероятность успешной кражи учетных данных и повторного использования токенов.

Гибридные удостоверения и удостоверения рабочих нагрузок

• Варианты гибридной идентификации
  • Синхронизация хэшей паролей (PHS): синхронизирует хэши паролей в Entra ID. Простой и отказоустойчивый метод; не применяет локальные политики входа в момент аутентификации.
  • Сквозная аутентификация (PTA): проверяет пароли через локальные контроллеры домена (DC) с помощью легковесных коннекторов; применяет локальные политики паролей и ограничения учетных записей в реальном времени, без использования AD FS.
  • Федерация (например, AD FS): переносит аутентификацию на локальную службу токенов безопасности (STS). Используйте только при необходимости для сложных утверждений (claims) или устаревших сценариев; добавляет больше серверов и операционных издержек.
  • Прозрачный единый вход (Seamless SSO): обеспечивает вход пользователей на присоединенных к домену устройствах внутри корпоративной сети с минимальным количеством запросов.
  • Операционный выбор: для применения локальных политик паролей и ограничений учетных записей при минимизации количества серверов разверните PTA и Seamless SSO, а также включите PHS для отказоустойчивости/аварийного переключения в сценариях, не зависящих от PTA. Одна лишь федерация увеличивает сложность и не соответствует цели «минимизировать количество серверов».
• Аутентификация приложений в Azure SQL с гибридно-присоединенных устройств Windows
  • Используйте встроенную аутентификацию Active Directory, чтобы минимизировать запросы и задействовать Kerberos/SSO, где это применимо.
• Управляемые удостоверения и субъекты-службы
  • Управляемые удостоверения (назначаемые системой или пользователем) — основной выбор для рабочих нагрузок, размещенных в Azure, поскольку они устраняют необходимость в секретах и автоматически ротируют учетные данные. Назначайте удостоверению роли RBAC с минимальными привилегиями на уровне ресурса.
  • Субъекты-службы лежат в основе регистраций приложений; используйте учетные данные на основе сертификатов вместо секретов клиента и устанавливайте минимально возможный срок их действия.
• Федерация удостоверений для рабочих нагрузок
  • Используйте федерацию OIDC, чтобы позволить внешним удостоверениям рабочих нагрузок (например, GitHub Actions, Kubernetes) получать токены для приложений Entra без хранения секретов. Точно определите утверждения (claims) издателя (issuer), субъекта (subject) и аудитории (audience), чтобы ограничить, кто может обменивать токены.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

• Доступ из AKS в ACR
  • Предоставьте управляемому удостоверению кластера AKS роль AcrPull для целевого реестра, используя процесс attach-acr, который автоматизирует правильное определение области действия и позволяет избежать неверных назначений.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

• Операционное обоснование
  • Связка PTA+PHS+Seamless SSO обеспечивает применение локальных политик в реальном времени, сохраняя при этом отказоустойчивость в облаке. Управляемые удостоверения и федерация устраняют статические секреты из конвейеров и среды выполнения, перекрывая распространенные пути кражи учетных данных.

Внешнее взаимодействие, методы аутентификации и доступ к приложениям

• Внешние удостоверения и B2B-взаимодействие
  • Используйте гостевые учетные записи B2B с настройками межклиентского доступа, условиями использования и политиками условного доступа (CA), нацеленными на гостей. Ограничьте круг лиц, которые могут отправлять приглашения, и отдавайте предпочтение JIT-доступу (just-in-time) через управление правами.
• Управление правами и пакеты доступа
  • Объединяйте группы, приложения и сайты SharePoint в пакеты доступа с политиками, которые определяют, кто может запрашивать доступ (включая внешних пользователей), процессы утверждения, сроки назначения и проверки доступа. При выборе проверяющих используйте владельцев групп (Group Owners), чтобы сохранить бизнес-ответственность за хранителями ресурсов.
• Методы аутентификации и беспарольный вход
  • Стандартизируйте использование надежных методов: ключи безопасности FIDO2, Windows Hello for Business и вход в систему с помощью телефона через Microsoft Authenticator. Используйте комбинированную регистрацию данных безопасности (SSPR + MFA) и принудительно применяйте политику регистрации MFA для всех пользователей. Включите SSPR с обратной записью в локальную среду (on-prem writeback), если это необходимо; требуйте использования безопасных методов и, по возможности, ограничивайтесь факторами, управляемыми корпорацией. Отключите устаревшие/базовые протоколы аутентификации и блокируйте слабую MFA только по SMS, где это оправдано риском.
• Прокси приложения Microsoft Entra
  • Публикуйте локальные веб-приложения без открытия входящих портов в брандмауэре. Используйте группы коннекторов для высокой доступности (HA), предварительную аутентификацию с помощью Entra ID и применяйте политики условного доступа (CA), соответствия устройств и Identity Protection для реализации принципа нулевого доверия (zero trust) для устаревших приложений.
• Безопасность регистрации приложений
  • Требуйте использования рабочих процессов согласия администратора; ограничивайте круг лиц, которые могут создавать приложения; классифицируйте разрешения; отдавайте предпочтение разрешениям приложений только тогда, когда контекст пользователя не требуется, и ограничивайте область действия API до минимума. По возможности отключайте неявное предоставление разрешений (implicit grant), требуйте назначения для корпоративных приложений и предпочитайте сертификаты секретам с автоматической ротацией.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

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

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

Компании Adobe Inc. необходимо предоставить стороннему поставщику временный административный доступ к подмножеству ресурсов Azure и опубликовать для него внутреннее устаревшее веб-приложение, обеспечив при этом строгую аутентификацию и отсутствие постоянных привилегий (zero standing privilege).

1. Определите область действия и смоделируйте доступ

• Создайте группу ресурсов rg-vendor-ops и переместите в нее только необходимые ресурсы. Назначьте минимально необходимые роли Azure RBAC (например, Contributor для rg-vendor-ops; Reader для группы ресурсов с диагностикой).
• Обоснование: Узкая область действия предотвращает боковое перемещение. Наследование ролей ограничено группой rg-vendor-ops, что сдерживает радиус поражения (blast radius).

2. Управляйте удостоверениями и активацией с помощью PIM

• Сделайте администраторов поставщика имеющими право (eligible), а не постоянными, на требуемые роли; требуйте утверждения, указания ID заявки, MFA при активации и ограничьте время активации 4 часами. Начните с запуска функции PIM «Обнаружение привилегированных ролей» (Discover privileged roles), чтобы определить базовый уровень существующих назначений.
• Обоснование: Назначения с правом на активацию устраняют постоянные привилегии. Утверждение и MFA обеспечивают JIT-доступ, согласованный с окнами поддержки, и предоставляют аудируемый контроль.

3. Применяйте политики условного доступа (Conditional Access) и рисков

• Создайте политику CA, нацеленную на группу поставщика, портал Azure и API-интерфейсы ARM, требующую MFA, соответствующее требованиям/гибридно-присоединенное устройство и блокирующую доступ из рискованных местоположений. Сначала включите режим «Только отчет» (report-only), а затем примените политику. Настройте Identity Protection: блокируйте высокий риск пользователя (утекшие учетные данные) до сброса пароля; требуйте MFA при среднем риске входа (подозрительный IP-адрес).
• Обоснование: CA связывает доступ с доверием к устройству и уровнем риска в реальном времени. Режим «Только отчет» предотвращает сбои во время развертывания. Политики рисков автоматически устраняют последствия скомпрометированных сессий и учетных записей.

4. Опубликуйте устаревшее приложение с помощью прокси приложения Microsoft Entra

• Разверните два коннектора в отдельных подсетях, доступных поставщику, для обеспечения высокой доступности (HA). Настройте предварительную аутентификацию с помощью Entra ID, требуйте назначения для корпоративного приложения и примените ту же политику CA. Используйте пакеты доступа, чтобы предоставить пользователям поставщика ограниченный по времени доступ как к корпоративному приложению, так и к ролям в группе ресурсов; назначьте владельцев групп (Group Owners) в качестве проверяющих.
• Обоснование: Прокси приложения устраняет уязвимость для входящих подключений и централизует аутентификацию. Управление правами стандартизирует процессы подключения/отключения и обеспечивает периодические проверки владельцами ресурсов.

5. Защитите учетные данные рабочих нагрузок и приложений

• Замените все секреты клиента на учетные данные на основе сертификатов для субъектов-служб; для CI/CD используйте федерацию удостоверений рабочих нагрузок вместо хранения секретов. Для рабочих нагрузок AKS, которым требуются образы, подключите ACR к кластеру, чтобы предоставить управляемому удостоверению разрешение AcrPull.
• Обоснование: Удаление статических секретов закрывает распространенный вектор атак; федерация и управляемые удостоверения обеспечивают доступ с минимальными привилегиями и автоматической ротацией.

6. Защитите аварийные учетные записи и осуществляйте мониторинг

• Исключите две аварийные учетные записи (break-glass) из политик CA, но защитите их длинными случайными паролями, хранящимися в автономном режиме. Включите ежеквартальные проверки доступа и экспортируйте журналы PIM и CA в рабочую область Log Analytics с оповещениями об аномальных активациях.
• Обоснование: Аварийные учетные записи предотвращают блокировку клиента, оставаясь при этом безопасными в эксплуатации. Непрерывный мониторинг позволяет быстро обнаруживать неправомерное использование, поддерживая соответствие требованиям и готовность к реагированию на инциденты.

Все домены · Архитектура сетевой безопасности →

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

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