0Pricing
Azure Fundamentals · Урок

Проектирование корпоративных удостоверений и доступа

Разработайте крупномасштабную модель RBAC с помощью групп управления, пользовательских ролей и Privileged Identity Management, чтобы обеспечить своевременный доступ к конфиденциальным операциям.

«Проектирование корпоративных удостоверений и доступа» — бесплатный урок Azure Fundamentals на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Azure Fundamentals, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Azure Fundamentals содержит 4 уроков всего.

Управление удостоверениями в корпоративном масштабе

В корпоративных средах Azure управление удостоверениями и доступом должно масштабироваться до сотен подписок, тысяч пользователей и десятков команд — у каждой из них свои требования к доступу к ресурсам. Хорошо спроектированная модель удостоверений предотвращает как чрезмерное предоставление разрешений (у пользователей слишком большой доступ), так и недостаточное предоставление разрешений (пользователи не могут выполнять свою работу). Её основу составляют Microsoft Entra ID в сочетании с Azure RBAC и такими средствами управления, как Privileged Identity Management (PIM).

Повторение основ RBAC

Azure Role-Based Access Control (RBAC) предоставляет доступ через три компонента:

  • субъект безопасности — кто (пользователь, группа, субъект-служба или управляемое удостоверение)
  • определение роли — что (набор разрешённых действий, например 'Contributor')
  • область действия — где (группа управления, подписка, группа ресурсов или отдельный ресурс)

Объединение этих трёх элементов создаёт назначение роли. Роли наследуются вниз по иерархии — роль, назначенная на уровне группы управления, применяется ко всем расположенным ниже подпискам.

# Assign the Reader role at a management group level:
az role assignment create \
  --assignee 'user@company.com' \
  --role 'Reader' \
  --scope '/providers/Microsoft.Management/managementGroups/LandingZones'

Встроенные и пользовательские роли

Azure предоставляет более 100 встроенных ролей для распространённых сценариев (Owner, Contributor, Reader и роли для отдельных служб). Для большинства корпоративных сценариев встроенных ролей достаточно. Однако если Вам нужны разрешения, не соответствующие ни одной встроенной роли — например, роль, позволяющая читать VMs, но не удалять их, — Вы можете создать пользовательскую роль с точно заданными необходимыми разрешениями, следуя принципу минимально необходимых привилегий.

# Create a custom role:
az role definition create --role-definition '{
  "Name": "VM Operator",
  "Description": "Can start and stop VMs but cannot create or delete them",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/<subscription-id>"]
}'

Назначение доступа на основе групп

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

# Create a group and assign a role to the group:
az ad group create \
  --display-name 'ProductionContributors' \
  --mail-nickname 'prod-contributors'

az role assignment create \
  --assignee '<group-object-id>' \
  --role 'Contributor' \
  --scope '/subscriptions/prod-subscription-id'

Privileged Identity Management (PIM)

Privileged Identity Management (PIM) — это служба Entra ID, предоставляющая привилегированный доступ по требованию (JIT) к ресурсам Azure и ролям Entra ID. Вместо постоянного доступа Owner или Global Administrator пользователи получают статус кандидатов на привилегированные роли и должны запросить активацию, когда им нужен расширенный доступ. Для активации могут потребоваться MFA, обоснование и одобрение назначенного утверждающего.

# Workflow with PIM:
# 1. Security team makes 'alice@company.com' eligible for 'Owner' on prod subscription
# 2. Alice requests activation via PIM portal or myaccess.microsoft.com
# 3. Alice provides justification: 'Emergency patching for CVE-2026-1234'
# 4. Manager approves the request (optional step)
# 5. Alice receives Owner access for 4 hours, then access expires automatically
# 6. All activation events are logged in Entra ID audit logs

Преимущества PIM в корпоративной среде

PIM обеспечивает несколько преимуществ для защиты корпоративных сред:

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

Проектирование модели RBAC

Хорошо спроектированная корпоративная модель RBAC обычно включает следующие уровни:

  • уровень группы управления — широкий доступ для просмотра для команд управления; назначения политик
  • уровень подписки — доступ Contributor на уровне команды для команд приложений, управляющих одной подпиской
  • уровень группы ресурсов — роли для отдельных служб (например, Storage Blob Contributor для приложения, которому нужен только доступ к двоичным объектам)
  • уровень ресурса — только для особых случаев, когда требуется детализированный контроль

Субъекты-службы и управляемые удостоверения

Приложения и автоматизированные процессы не должны использовать учетные записи пользователей для аутентификации в Azure. Вместо этого используйте:

  • Субъекты-службы — регистрации приложений в Entra ID с идентификатором клиента и секретом или сертификатом; используются конвейерами CI/CD и автоматизацией в локальной инфраструктуре
  • Управляемые удостоверения — автоматически управляемые учетные данные для ресурсов, размещенных в Azure (VM, App Service, AKS); секретами не нужно управлять или выполнять их ротацию

Назначайте субъектам-службам и управляемым удостоверениям минимально необходимые роли RBAC.

# Assign a role to a managed identity:
az role assignment create \
  --assignee-object-id '<managed-identity-object-id>' \
  --assignee-principal-type ServicePrincipal \
  --role 'Storage Blob Data Contributor' \
  --scope '/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>'

Условный доступ к ресурсам

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

  • Соответствующие требованиям устройства (управляются с помощью Intune)
  • Именованные расположения (корпоративная сеть или VPN)
  • После выполнения MFA (всегда применяется для привилегированных действий)

Сочетание условного доступа с PIM обеспечивает очень высокий уровень безопасности административного доступа к Azure.

Проверки доступа

Проверки доступа Entra ID позволяют администраторам периодически подтверждать, что пользователям по-прежнему нужен предоставленный им доступ. Проверки можно делегировать владельцам ресурсов или руководителям: для каждого пользователя они отвечают «Да, этому человеку по-прежнему нужен доступ» или «Нет, удалите этот доступ». Проверки доступа можно планировать ежеквартально и автоматизировать удаление доступа, который больше не одобрен, предотвращая постепенное расширение доступа со временем.

Аварийные учетные записи доступа

Каждая организация должна иметь как минимум две аварийные учетные записи доступа (break-glass) — учетные записи глобального администратора, на которые не распространяются требования условного доступа или MFA (вместо этого они используют аппаратные ключи FIDO2). Эти учетные записи используются только в случаях, когда системы Entra ID или MFA недоступны и обычные учетные записи администраторов нельзя использовать. Использование аварийной учетной записи доступа должно немедленно вызывать оповещения системы безопасности и тщательно регистрироваться в журналах аудита.

Быстрая проверка

Проверьте свое понимание концепций Microsoft Azure Fundamentals (AZ-900) из этого урока.

Итоги урока

В этом уроке Вы узнали, что корпоративный RBAC использует назначения на основе групп на уровне групп управления, подписок и групп ресурсов; Privileged Identity Management предоставляет своевременный доступ, устраняя постоянные роли администраторов; а для аутентификации приложений вместо учетных записей пользователей следует использовать управляемые удостоверения и субъекты-службы. Поздравляем — Вы завершили раздел об архитектуре и управлении корпоративной средой в рамках трека AZ-900!

Часто задаваемые вопросы

Урок «Проектирование корпоративных удостоверений и доступа» бесплатный?

Да — полный текст урока «Проектирование корпоративных удостоверений и доступа» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Azure Fundamentals, подпишись на CoddyKit PRO. Курс Azure Fundamentals содержит 4 уроков всего.

Чему я научусь в уроке «Проектирование корпоративных удостоверений и доступа»?

Разработайте крупномасштабную модель RBAC с помощью групп управления, пользовательских ролей и Privileged Identity Management, чтобы обеспечить своевременный доступ к конфиденциальным операциям. Ты практикуешь Azure Fundamentals с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Azure Fundamentals?

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

Сколько времени занимает урок «Проектирование корпоративных удостоверений и доступа»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Azure Fundamentals?

Да. Каждый урок Azure Fundamentals включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. Обзор Cloud Adoption Framework
  2. Целевые зоны Azure
  3. Топология сети «концентратор и периферийные сети»
  4. Проектирование корпоративных удостоверений и доступа
← Назад к Azure Fundamentals