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


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

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

Необходимые компоненты

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

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

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

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

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

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

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

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

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

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

Screenshot showing the project settings page where assignments can be made.

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

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

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

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

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

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

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

Примечание.

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

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

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