Комплексное управление DevOps в Azure

В этой статье описывается, как тщательно управлять и реализовывать методики управления звуком для вашей команды, например разрешения на управление доступом на основе ролей.

Не достаточно просто спланировать и реализовать модель управления доступом на основе ролей (RBAC) Azure для шаблонов Azure Resource Manager (ARM), чтобы ограничить доступ посредством портала Microsoft Azure и интерфейса командной строки Azure (Azure CLI).

Если не зеркалировать эту модель в среде автоматизации DevOps, вы оставляет открытым черный ход для угроз безопасности. Рассмотрим пример, когда разработчик не имеет доступа через шаблоны ARM, но по-прежнему располагает разрешениями, достаточными для изменения кода приложения или инфраструктуры как кода и запуска рабочего процесса автоматизации. Разработчик может опосредованно (через DevOps) получить доступ и внести необратимые изменения в шаблоны ARM.

Одна плоскость управления удостоверениями с группами Microsoft Entra

Первым шагом является интеграция Идентификатора Microsoft Entra для использования единого входа на каждую рекомендацию по управлению удостоверениями.

Если вы не используете сторонний продукт CI Azure, например Azure DevOps, проверка, если поставщик предлагает интеграцию Microsoft Entra.

Второй шаг — использовать группы Microsoft Entra, те же группы, которые уже используются для модели RBAC шаблонов ARM. Рекомендуется назначать роли группам Microsoft Entra, а не отдельным лицам. Чтобы создать комплексную модель управления, необходимо выполнить этот шаг и для шаблонов ARM, и для DevOps.

Azure DevOps тесно интегрируется с идентификатором Microsoft Entra, включая членство в группах Microsoft Entra, что упрощает применение назначений ролей к той же группе Microsoft Entra.

Примечание.

Если вы используете другой поставщик CI, у вас может быть промежуточный логический контейнер для управления членством в группах, который также необходимо сохранить, если членство в группе Microsoft Entra не синхронизировано.

На следующей схеме показано, как идентификатор Microsoft Entra используется в качестве единой плоскости управления удостоверениями. В шаблонах ARM и в наших инструментах DevOps (Azure DevOps в этом примере) нам нужно управлять только назначениями ролей, а не членством, которые должны управляться в идентификаторе Microsoft Entra. Обратите внимание, что имена ресурсов соответствуют соглашениям об именовании и сокращениям, рекомендуемым для ресурсов Azure.

Пример сценария: удаление доступа подрядчика с одним шагом, членством в Microsoft Entra

Чтобы четко понимать преимущества комплексного управления, рассмотрим этот сценарий.

Если вы используете идентификатор Microsoft Entra в качестве одной плоскости управления удостоверениями, вы можете удалить доступ разработчика к ресурсам Azure в одном действии, изменив членство в группах Microsoft Entra. Например, если доступ подрядчика должен быть отменен после завершения проекта, при удалении членства подрядчика из соответствующих групп Microsoft Entra доступ к шаблонам ARM и Azure DevOps удаляется.

Зеркальная модель RBAC с назначениями ролей

При должном планировании модель RBAC вашего средства непрерывной интеграции будет точно соответствовать модели RBAC Azure. Хотя примеры имен группы Microsoft Entra на схеме выше подразумевают правила безопасности, членство в одиночку не обеспечивает безопасность. Помните, что RBAC — это сочетание субъектов, определений и областей, которые не вступают в силу до назначения роли.

• Схема иллюстрирует назначение ролей для одной группы Microsoft Entra. contoso-admins-group
• Эта группа Microsoft Entra назначается роль владельца для шаблонов Azure ARM в нескольких область подписки:
  • подписка contoso-dev-sub;
  • подписка contoso-prod-sub;
• contoso-admins-group добавляется в группу администраторов проектов для Azure DevOps в единой области проекта.

Группа Microsoft Entra имеет аналогичные привилегированные роли для шаблонов ARM и DevOps. Следуя этой логике, группа разработчиков с назначенной ролью "Участник" для шаблонов ARM не может входить в группу администраторов проекта в DevOps.

Теперь, когда мы разобрали необходимость защиты шаблонов ARM и рабочих процессов DevOps, вам необходимо выполнить следующие действия.

• Посмотрите на вашу модель RBAC и подумайте, как роли и обязанности, определенные для шаблонов ARM, соответствуют рабочему процессу CI/CD.
• Просмотрите решения по управлению удостоверениями платформы CI и интегрируйте идентификатор Microsoft Entra. В идеале вы хотите включить членство в группе Microsoft Entra.
• Проверьте, какие роли и уровни доступа предлагает ваше средство непрерывной интеграции, и сравните их с ролями и уровнями доступа в модели RBAC Azure. Роли и уровни доступа не будут совпадать точь в точь. Проверьте конфигурацию. Если у разработчика нет доступа к шаблонам ARM, у них не должно быть доступа и к DevOps. Простейший пример: разработчик, у которого нет прав на запись в отношении рабочих ресурсов, не должен иметь прямого доступа к запуску рабочих конвейеров.

Дополнительные сведения о разработке системы управления и разрешениях см. в следующих статьях.

• Рекомендуемый метод предоставления и ограничения разрешений
• Разрешения по умолчанию и доступ к Azure DevOps
• Управление доступом пользователей к ресурсам организации с помощью ролей

Следующие шаги

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

Архитектура безопасности разработки