Поделиться через

Управление доступом на основе ролей для средств DevOps

  • Статья

При развертывании облачных решений для развертываний инфраструктуры безопасность всегда должна быть самой важной задачей. Корпорация Майкрософт защищает базовую облачную инфраструктуру. Вы настраиваете безопасность в Azure DevOps или GitHub.

Предпосылки

Как только вы решите, какие шаблоны Azure Landing Zone развернуть, клонируйте их в собственный репозиторий. Настройте конвейеры CI/CD. Для GitHub и Azure DevOps доступны несколько методов проверки подлинности, таких как личные маркеры доступа (PAT) и интеграция с поставщиком удостоверений, например идентификатором Microsoft Entra. Дополнительные сведения см. в разделе "Использование личных маркеров доступа".

Рекомендуется интегрироваться с идентификатором Microsoft Entra, чтобы использовать все его возможности. Интеграция помогает упростить процесс назначения ролей и управление жизненным циклом удостоверений. Дополнительные сведения см. в разделе "Подключение организации к идентификатору Microsoft Entra". Если вы используете GitHub, рассмотрите возможность интеграции GitHub Enterprise с идентификатором Microsoft Entra.

Общие рекомендации по проектированию

Мы рекомендуем обеспечить жесткий контроль над администраторами и группами учетных записей служб в идентификаторе Microsoft Entra и средстве DevOps. Рассмотрите возможность реализации принципа наименьшей привилегии для всех назначений ролей.

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

Для любых администраторов или высоко привилегированных учетных записей в Active Directory рекомендуется не синхронизировать учетные данные с идентификатором Microsoft Entra и наоборот. Такой подход снижает угрозу бокового движения. Если администратор в идентификаторе Microsoft Entra скомпрометирован, злоумышленник не сможет легко получить доступ к любым облачным ресурсам, таким как Azure DevOps. Эта учетная запись не может потенциально внедрять вредоносные задачи в конвейеры CI/CD. Этот шаг особенно важен для всех пользователей, которым назначены повышенные разрешения в среде DevOps, например администраторы сборки или коллекции. Дополнительные сведения см. в разделе "Рекомендации по безопасности" в идентификаторе Microsoft Entra.

Рекомендации по доступу на основе ролей Azure DevOps

Управление безопасностью в Azure DevOps с помощью групп безопасности, политик и параметров на уровне организации или коллекции, проекта или объекта. Чтобы интегрироваться с поставщиком удостоверений, например идентификатором Microsoft Entra, рассмотрите возможность создания политик условного доступа для принудительной многофакторной проверки подлинности для всех пользователей. Политики позволяют получить доступ к организации Azure DevOps и более детализированные ограничения по IP-адресу, типу устройства, используемому для доступа и соответствия устройств.

Для большинства сотрудников вашей команды, работающей с платформой, которая управляет целевыми зонами Azure, уровень доступа "Базовый" и группа безопасности "Сотрудник" по умолчанию должны обеспечить достаточный доступ. Группа безопасности "Участник" позволяет им редактировать шаблоны опорной зоны Azure в вашем репозитории и пайплайны CI/CD, которые проверяют и развертывают эти шаблоны.

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

Снимок экрана: страница параметров проекта, на которой можно сделать назначения.

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

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

После назначения пользователям разрешений периодически просматривайте события аудита, чтобы отслеживать и реагировать на непредвиденные шаблоны использования администраторами и другими пользователями. Начните с создания потока аудита в рабочей области Log Analytics. Если в рабочей области используется Microsoft Sentinel, создайте правила аналитики для оповещения о важных событиях, таких как неправильное использование разрешений.

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

Рекомендации по доступу на основе ролей GitHub

Если основным средством DevOps является GitHub, вы можете назначить пользователям доступ к ресурсам, предоставив им роли на уровне репозитория, уровне группы или организации. После того, как вы форкнете репозиторий Azure Landing Zones и интегрируете его с поставщиком удостоверений, таким как Microsoft Entra ID, рассмотрите возможность создания команды в GitHub. Предоставьте этой команде права на запись в новый репозиторий посадочной площадки Azure. Для большинства членов платформенной команды, которые изменяют и развертывают Landing Zones, достаточно будет прав на запись. Для руководителей проектов или руководителей Scrum в команде может потребоваться назначить им роль обслуживания в этом репозитории.

Мы рекомендуем управлять всеми этими назначениями ролей с помощью интегрированного поставщика удостоверений. Например, вы можете синхронизировать команду Platform для репозитория Azure Landing Zone, созданного в GitHub, с соответствующей группой безопасности команды Platform в Microsoft Entra ID. Затем при добавлении или удалении участников в группу безопасности Microsoft Entra эти изменения отражаются в назначениях ролей GitHub Enterprise Cloud.

Замечание

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

Дальнейшие шаги

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