Рекомендации по безопасности для платформ DevOps

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

Рассмотрим следующие критически важные области безопасности независимо от того, развертываете ли среды через инфраструктуру в виде кода в конвейерах непрерывной интеграции и непрерывного развертывания (CI/CD) или развертываете код в приложениях, размещенных в Azure.

Ограничение доступа к инструментам DevOps

Следуйте принципу наименьших привилегий с помощью управления доступом на основе ролей (RBAC) с помощью идентификатора Microsoft Entra. Предоставьте пользователям и службам минимальный объем доступа к платформам DevOps, которые они должны выполнять бизнес-функции. Дополнительные сведения см. в следующих статьях:

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

  • Используйте управление правами идентификатора Microsoft Entra для создания пакетов доступа, позволяющих пользователям Microsoft Entra время, привязанный к необходимым ресурсам для выполнения задач.

  • Вы также можете использовать Microsoft Entra управление привилегированными пользователями для JIT-доступа к роли администратора Azure DevOps в течение определенного периода времени.

Управление безопасностью в Azure DevOps с помощью групп безопасности, политик и параметров в организации, проекте или уровне объектов Azure DevOps. Если это возможно, рассмотрите возможность отключения наследования разрешений в Azure DevOps.

Ограничение доступа к репозиторию и ветви

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

Ограничение доступа к конвейеру и разрешений

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

Рекомендуется использовать добавочный подход к защите конвейеров YAML. Дополнительные сведения см. в разделе "Планирование защиты конвейеров YAML".

Выберите агент DevOps на основе потребностей безопасности

Вы можете использовать размещенные майкрософт или локальные агенты для управления конвейерами Azure DevOps и GitHub. Существуют компромиссы для каждого типа агента.

При использовании агентов, размещенных корпорацией Майкрософт, вам не нужно беспокоиться об обновлениях или обслуживании. При использовании локально размещенных агентов у вас есть более гибкие возможности для реализации охранников. Вы управляете оборудованием агента, операционной системой и установленными средствами. Локальные агенты также могут предоставлять частный сетевой доступ к ресурсам за брандмауэрами или виртуальными сетями.

Ознакомьтесь с агентами Azure Pipelines для проверки различий между типами агентов и выявления потенциальных соображений безопасности.

Использование защищенных удостоверений служб с ограниченной областью действия

Для GitHub, Azure DevOps или сторонних платформ CI/CD используйте безопасные и ограниченные удостоверения для развертывания кода и инфраструктуры в средах Azure.

  • Пользовательские управляемые удостоверения или регистрации приложений (учетные записи служб) в Entra ID можно использовать. Никогда не используйте учетную запись пользователя.
  • Реализуйте аутентификацию OpenID Connect (федерация идентичностей рабочих нагрузок) с помощью федеративных учетных данных. Никогда не используйте секреты клиента или сертификаты.
  • Создайте отдельное удостоверение для каждого приложения и каждой среды, в которых вы осуществляете развертывание, чтобы можно было применять детализированные разрешения.
  • Создайте отдельное удостоверение для каждого приложения и среды для операций только для чтения, таких как план Terraform или Bicep what-if.
  • Указать разрешения удостоверения только для подписки Azure или групп ресурсов, необходимых для развертывания. Используйте принцип наименьших привилегий, чтобы назначить идентификатору только необходимые роли.
  • Разверните идентификационные и федеративные учетные данные через инфраструктуру в виде кода (IaC) в процессе безопасного предоставления подписок. Дополнительные сведения см. в разделе "Автоматизация развертывания и настройки подписки".

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

При использовании самостоятельно размещенных агентов с использованием вычислительных ресурсов Azure можно использовать управляемые удостоверения, назначаемые системой или пользователем, непосредственно на агенте. Хотя этот подход может быть безопасным, рекомендуется использовать OpenID Connect (федерация удостоверений рабочей нагрузки) с управляемыми удостоверениями, назначаемыми пользователем, или регистрациями приложений (субъектами-службами) для повышения гибкости и управления. При использовании управляемого удостоверения, прикрепленного к вычислительной среде, если присоединить несколько управляемых удостоверений, назначенных пользователем, к агенту, все работающие на агенте процессы получают доступ ко всем этим удостоверениям. Обычно экономически нецелесообразным иметь отдельных агентов для каждого приложения и среды, чтобы обеспечить доступ с минимальными привилегиями.

Идентификаторы Azure DevOps

Всегда используйте подключение службы с OpenID Connect (федерация идентичности рабочей нагрузки) для развертывания инфраструктуры или кода приложения в среде Azure. Подключение к службе — это оболочка для удостоверения в Azure.

  • Создайте отдельное подключение и удостоверение службы для каждого приложения и среды, в которой вы развертываете, обеспечивая возможность применения подробных разрешений.
  • Создайте одобрения для подключения к службе. Не создавайте их в средах, так как это можно обойти в коде.
  • Создайте необходимые шаблоны (также известные как управляемые конвейеры) на подключении службы, чтобы убедиться, что вредоносный код не может быть внедрен без утверждения.
  • Убедитесь, что федеративные удостоверяющие учетные данные ограничены только подключением к службе.
  • Разверните подключения к сервису через инфраструктуру как код (IaC) в процессе безопасного распространения подписки. Дополнительные сведения см. в разделе "Автоматизация развертывания и настройки подписки".

Пример кода и конвейеров можно найти в примере кода федерации удостоверений рабочей нагрузки Azure DevOps .

Идентификаторы GitHub Actions

Всегда используйте встроенные действия или переменные среды с OpenID Connect (федерация удостоверений рабочей нагрузки) для развертывания инфраструктуры или кода приложения в среде Azure.

  • Создайте идентификатор для каждого приложения и среды, на которую вы развертываете, обеспечивая возможность применения детализированных разрешений.
  • Создайте утверждения в среде GitHub Actions.
  • Обновите требования субъекта, чтобы включить environment требование и гарантировать, что удостоверение может использоваться только в рамках указанной среды. Это гарантирует, что ваши одобрения не могут быть обойдены. Добавьте это утверждение в федеративные учетные данные удостоверения.
  • Обновите ваши субъектные утверждения, чтобы включить job_workflow_ref (также известный как управляемые конвейеры), чтобы удостоверение могло использоваться только в рамках указанного рабочего процесса. Добавьте это утверждение в федеративные учетные данные удостоверения.
  • Обновите утверждения субъекта, чтобы удалить repository и использовать repository_owner_id и repository_id, чтобы убедиться, что ваша идентификация может использоваться только в сфере указанного репозитория, даже если его имя изменено. Добавьте это утверждение к федеративным учетным данным идентификации.
  • Обновите утверждения субъекта с помощью инфраструктуры в виде кода (IaC) в процессе безопасной подписки. Дополнительные сведения см. в разделе "Автоматизация развертывания и настройки подписки".

Пример кода и рабочих процессов можно найти в примере кода федерации удостоверений рабочей нагрузки GitHub Actions .

Использование хранилища секретов

Всегда избегайте использования секретов, предпочитайте OpenID Connect (федерация удостоверений для рабочих нагрузок) или управляемые идентичности по возможности.

В случае, если вы не можете избежать использования секрета, никогда не жестко кодируйте их в коде или вспомогательной документации в репозиториях. Злоумышленники сканируют репозитории, выполняя поиск предоставленных конфиденциальных данных для использования. Настройте хранилище секретов, например Azure Key Vault, и наведите ссылку на хранилище в Azure Pipelines для безопасного получения ключей, секретов или сертификатов. Дополнительные сведения см. в разделе "Защита рабочего процесса конвейера и CI/CD". Вы также можете использовать секреты Key Vault в рабочих процессах GitHub Actions.

Использование защищенных рабочих станций DevOps для создания и развертывания кода

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

Используйте защищенные защищенные рабочие станции администрирования (SAWs) для развертывания любых изменений в рабочих средах с высоким риском и рабочей среде. Дополнительные сведения см. в разделе "Безопасные конечные точки с нулевой доверием".

Проверка безопасности и тестирование

Независимо от того, развертываете код приложения или инфраструктуру как код, реализуйте рекомендации и элементы управления DevSecOps в конвейерах. Интегрируйте безопасность в начале процесса CI/CD, чтобы предотвратить дорогостоящие нарушения безопасности позже. Создайте стратегию для реализации анализа статического кода, модульного тестирования, сканирования секретов и проверки пакетов и зависимостей в конвейерах.

Корпоративные средства безопасности, такие как Microsoft Defender для облака, могут интегрироваться с средствами DevOps. Например, Defender для облака могут определять уязвимые образы контейнеров в рабочих процессах CI/CD. Для GitHub Actions и репозиториев используйте GitHub Advanced Security для проверки кода и секретов и проверки зависимостей.

Периодически просматривайте события аудита, чтобы отслеживать и реагировать на непредвиденные шаблоны использования администраторами и другими пользователями. Вы можете получить доступ, фильтровать и экспортировать журналы аудита для организации Azure DevOps. Для долгосрочного хранения и подробных запросов к журналам создайте поток аудита в рабочей области Azure Monitor Log Analytics или систему управления безопасностью и событиями (SIEM), например Microsoft Sentinel.

  • Last updated on