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

Защитите ваш Azure DevOps

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Защита сети

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

  • настройка списка разрешений IP-адресов: ограничить доступ к определенным IP-адресам, чтобы разрешить трафик только из надежных источников, уменьшая область атаки. Дополнительные сведения см. в разделе Настройка списка разрешений IP-адресов.
  • применять шифрование данных: всегда шифровать данные при передаче и хранении. Безопасные каналы связи с помощью протоколов, таких как HTTPS. Дополнительные сведения см. в разделе Использованиешифрования данных.
  • проверить сертификаты: убедитесь, что сертификаты действительны и выданы доверенными учреждениями при установлении соединений. Дополнительные сведения см. в разделе Проверка сертификатов.
  • реализовать брандмауэры веб-приложений (WAFs): фильтровать, отслеживать и блокировать вредоносный веб-трафик с помощью WAFs для дополнительного уровня защиты от распространенных атак. Дополнительные сведения см. в разделе "Брандмауэры веб-приложений (WAFs)".
  • Включить группы безопасности сети (NSG): использовать группы безопасности сети для управления входящим и исходящим трафиком в ресурсы Azure, гарантируя, что разрешен только авторизованный трафик. Дополнительные сведения см. в обзоре групп безопасности сети (NSG).
  • Используйте Брандмауэр Azure: Разверните Брандмауэр Azure для предоставления централизованной политики безопасности сети в нескольких подписках Azure и виртуальных сетях. Для получения дополнительных сведений см. Обзор брандмауэра Azure .
  • Мониторинг сетевого трафика: использовать наблюдатель за сетями Azure для мониторинга и диагностики сетевых проблем, обеспечивая безопасность и производительность сети. Дополнительные сведения см. в обзоре службы "Наблюдатель за сетями Azure".
  • Реализация защиты от атак DDoS: Включить защиту от атак DDoS Azure для защиты приложений от распределенных атак типа "отказ в обслуживании" (DDoS). Для получения дополнительной информации см. Защита от DDoS-атак Azure.

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

Защита среды Azure DevOps

Чтобы обеспечить соответствие среды Azure DevOps отраслевым стандартам и нормативным требованиям, реализуйте меры безопасности и политики. Соответствие таким стандартам, как ISO/IEC 27001, SOC 1/2/3 и General Data Protection Regulation (GDPR), помогает защитить среду и поддерживать доверие с пользователями.

  • обеспечить соответствие отраслевым стандартам: Azure DevOps соответствует различным отраслевым стандартам и нормативным требованиям, таким как ISO/IEC 27001, SOC 1/2/3 и GDPR. Убедитесь, что среда соответствует этим стандартам.
  • Применяйте политики: Реализуйте политики для внедрения передового опыта по обеспечению безопасности в организации. Это действие включает требование проверки кода и применение политик ветви , политик соответствия для конвейеров , и политик безопасности .
  • Внедрение управления компонентами для CI/CD по следующим причинам:
    • Обнаружение уязвимостей системы безопасности: оповещения об известных уязвимостях в компонентах с открытым кодом.
    • Соответствие лицензий. Гарантирует, что компоненты соответствуют политикам лицензирования вашей организации.
    • Применение политик: гарантирует использование только утвержденных версий.
    • Видимость с отслеживанием. Обеспечивает видимость компонентов в разных репозиториях для упрощения управления.

Управление разрешениями на уровне проекта и организации

  • Ограничить доступ к проектам и репозиториям: снизить риск утечки конфиденциальной информации и развертывания небезопасного кода путем ограничения доступа к проектам и репозиториям. Используйте встроенные или настраиваемые группы безопасности для управления разрешениями. Дополнительные сведения см. в разделе Ограничение доступа к проектам и репозиториям.
  • Отключить "Разрешить общедоступные проекты": В параметрах политики организации отключите параметр для создания общедоступных проектов. При необходимости переключите видимость проекта с общедоступной на частную. Пользователи, которые никогда не вошли в систему, имеют доступ только для чтения к общедоступным проектам, в то время как пользователи, вошедшие в систему, могут быть предоставлены доступ к частным проектам и вносить разрешенные изменения. Дополнительные сведения см. в разделе Изменение политик подключения и безопасности приложений для вашей организации.
  • Ограничить создание организации: запретить пользователям создавать новые проекты для поддержания контроля над средой. Дополнительные сведения см. в разделе Ограничить создание организации с помощью политики клиента Microsoft Entra.

Использование функций безопасности и средств

Следующие функции безопасности и средства помогают отслеживать, управлять и повысить безопасность проектов:

  • Используйте OAuth вместо личных токенов доступа (PATs): Используйте поток OAuth вместо PATs и не используйте личные учетные записи GitHub в качестве подключений к службам. Дополнительную информацию см. в обзоре OAuth .
  • Использование сканирования и анализа кода: использовать такие средства, как Microsoft Defender для проверки кода на наличие уязвимостей, секретов и неправильной настройки. Это действие помогает выявлять и устранять проблемы безопасности в начале процесса разработки.
  • Используйте Git Credential Manager: он поддерживает двухфакторную аутентификацию для репозиториев GitHub и позволяет аутентифицироваться в Azure Repos. Дополнительные сведения см. в разделе Настройка диспетчера учетных данных Git.
  • Использовать сканер учетных данных Azure DevOps (CredScan) для GitHub: Если использование управляемого удостоверения недоступно, убедитесь, что учетные данные хранятся в безопасных местах, таких как Azure Key Vault, вместо их встраивания в код и файлы конфигурации. Реализуйте сканер учетных данных Azure DevOps для идентификации учетных данных в коде. Дополнительные сведения см. в разделе Начало работы с CredScan.
  • Используйте проверку собственных секретов для GitHub: Если использование управляемой идентификации невозможно, убедитесь, что секреты хранятся в безопасных местах, таких как Azure Key Vault, вместо их внедрения в код и файлы конфигурации. Используйте функцию сканирования собственных секретов для идентификации секретов в коде. Для получения дополнительной информации см. раздел О сканировании секретов.

Дополнительные сведения см. в обзоре расширенной безопасности GitHub .

Обеспечьте безопасность ваших услуг

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

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

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

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

Разрешения области действия

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

Для эффективного применения разрешений выполните следующие действия.

  • Отключить наследование: Избегайте наследования, предотвращая непреднамеренный доступ. Наследование может непреднамеренно предоставить пользователям разрешения, которые они не должны иметь, из-за своей природы, разрешающей всё по умолчанию. Тщательно управляйте и явным образом устанавливайте разрешения, чтобы обеспечить доступ только предполагаемым пользователям. Дополнительные сведения см. в разделе наследования разрешений.
  • среды сегмента : использовать отдельные учетные записи Azure для различных сред, таких как разработка, тестирование и производство, для повышения безопасности и предотвращения конфликтов. Этот подход сводит к минимуму риск конфликтов ресурсов и загрязнения данных между средами и обеспечивает более эффективное управление ресурсами и изоляцию ресурсов. Для получения дополнительной информации см. Azure Landing Zone.
  • контроль доступа и обеспечение соответствия требованиям: использовать политику Azure для ограничения доступа к неиспользуемых регионах и службам Azure, обеспечивая соответствие стандартам организации. Это действие помогает применять рекомендации и поддерживать безопасную среду, предотвращая несанкционированный доступ и использование. Для получения дополнительной информации см. обзор политики Azure .
  • Реализация управления доступом на основе ролей (ABAC) Azure: Используйте ABAC с правильно отмеченными ресурсами, ограничивая несанкционированный доступ. Это действие гарантирует, что разрешения доступа предоставляются на основе определенных атрибутов, повышая безопасность путем предотвращения несанкционированного создания и доступа к ресурсам. Дополнительные сведения см. в статье Реализация управления на основе ролей Azure (ABAC).
  • использовать группы безопасности: использовать группы безопасности для эффективного управления разрешениями для нескольких пользователей. Этот метод упрощает предоставление и отзыв доступа по сравнению с назначением разрешений по отдельности и обеспечивает согласованность и упрощение управления в организации.
    • Используйте идентификатор Microsoft Entra, Active Directory или группы безопасности Windows при управлении большим количеством пользователей.
    • Используйте встроенные роли и назначайте разработчикам роль "Участник" по умолчанию. Администраторы назначаются в группу безопасности администратора проекта для получения повышенных разрешений, что позволяет им настраивать параметры безопасности.
    • Старайтесь делать группы как можно меньше, ограничивая доступ.
    • Дополнительные сведения см. в разделе Управление группами безопасности.
  • Выберите правильный метод проверки подлинности: Установите безопасные методы проверки подлинности и управляйте политиками авторизации. Дополнительные сведения см. в разделе Выбор правильного метода проверки подлинности в этой статье и методов проверки подлинности.
  • Интеграция с Microsoft Entra ID: Использовать Microsoft Entra ID для единого управления удостоверениями. Дополнительные сведения см. в статье Подключение организации к идентификатору Microsoft Entra ID.
  • Включить многофакторную проверку подлинности (MFA) Microsoft Entra: Добавить дополнительный уровень безопасности с помощью MFA. Дополнительные сведения см. в разделе Включение многофакторной проверки подлинности Microsoft Entra.
  • Изменение политик безопасности: Управление политиками безопасности, включая условный доступ. Дополнительные сведения см. в разделе Изменение политик безопасности подключения приложения & для организации.

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

Выбор правильного метода проверки подлинности

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

  • Использовать служебные принципы: Представлять объекты безопасности в приложении Microsoft Entra. Определите, что может сделать приложение в данном клиенте. Настройка во время регистрации приложения на портале Azure. Настройте доступ к ресурсам Azure, включая Azure DevOps. Полезно для приложений, требующих определенного доступа и контроля.
  • Использовать управляемые удостоверения: Аналогично служебному принципалу приложения. Обеспечьте идентификаторы для ресурсов Azure. Разрешить службам, поддерживающим аутентификацию Microsoft Entra, делиться учетными данными. Azure автоматически обрабатывает управление учетными данными и смену. Идеально подходит для простого управления сведениями о входе.
  • Используйте идентификатор Microsoft Entra:
    • Создайте единое пространство идентификации, подключив Azure DevOps к Microsoft Entra ID. Эта согласованность снижает путаницу и сокращает риски безопасности из ошибок конфигурации вручную.
    • Получите доступ к вашей организации с помощью Microsoft Entra ID и назначьте различные роли и разрешения конкретным группам в различных ресурсных областях. Это действие реализует точное управление, обеспечивает контролируемый доступ и соответствует рекомендациям по обеспечению безопасности.
    • Используйте политики условного доступа, которые определяют правила доступа на основе таких условий, как расположение , устройство или уровень риска.

Управление внешним гостевым доступом

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

  • Блокировать внешний гостевой доступ: Отключить "Разрешить отправку приглашений в любой домен" политики, чтобы предотвратить внешний гостевой доступ, если для него нет бизнес-необходимости.
  • Использовать отдельные адреса электронной почты или учетные имена пользователей: Использовать разные адреса электронной почты или учетные имена пользователей для личных и бизнес-учетных записей, чтобы устранить неоднозначность между личными и рабочими учетными записями.
  • Сгруппировать внешних гостевых пользователей: объединить всех внешних гостевых пользователей в одну группу Microsoft Entra и управлять разрешениями этой группы надлежащим образом. Удалите прямые назначения, чтобы обеспечить применение правил группы к этим пользователям.
  • Регулярный пересмотр правил: Регулярно пересматривайте правила на вкладке "Правила группы" на странице "Пользователи". Рассмотрите любые изменения членства в группах в идентификаторе Microsoft Entra, которые могут повлиять на вашу организацию. Обновление динамического членства в группах в Microsoft Entra ID может занять до 24 часов, и правила автоматически переоцениваются каждые 24 часа и каждый раз при изменении правила группы.

Дополнительные сведения см. в разделе B2B-гостей в Microsoft Entra ID.

Реализация нулевого доверия

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

  • Подход к нулевому доверию: реализация принципов нулевого доверия для укрепления платформы DevOps, защиты среды разработкии интеграции нулевого доверия в рабочие процессы разработчиков . Нулевая модель доверия помогает защитить от поперечного перемещения в сети, гарантируя, что даже если какая-то часть сети скомпрометирована, угроза локализуется и не может распространяться дальше.

Дополнительные сведения см. в руководстве по оценке Zero Trust.

Удаление пользователей

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

  • Удалить неактивных пользователей из учетных записей Майкрософт (MSAs): напрямую удалить неактивных пользователей из организации, если они используют MSAs. Невозможно создавать запросы для рабочих элементов, назначенных удаленным учетным записям MSA. Дополнительные сведения см. в разделе Удаление пользователей из вашей организации.
  • Отключить или удалить учетные записи пользователей Microsoft Entra: Если подключено к идентификатору Microsoft Entra, отключите или удалите учетную запись пользователя Microsoft Entra, сохраняя учетную запись пользователя Azure DevOps активной. Это действие позволяет продолжать запрашивать журнал рабочих элементов с помощью идентификатора пользователя Azure DevOps.
  • Отмена пользовательских PATS: обеспечить безопасное управление этими критически важными маркерами проверки подлинности, регулярно просматривая и отменяя существующие пользовательские PATS. Дополнительные сведения см. в разделе Отзыв пользовательских токенов доступа для администраторов.
  • отозвать специальные разрешения, предоставленные отдельным пользователям: аудировать и отзывать все специальные разрешения, предоставленные отдельным пользователям, чтобы обеспечить соответствие принципу наименьших привилегий.
  • переназначение работы удаленных пользователей: перед удалением пользователей переназначьте рабочие элементы текущим участникам группы, чтобы эффективно распределять нагрузку.

Учетные записи службы области действия

Учетные записи служб используются для запуска автоматизированных процессов и служб, и они часто имеют повышенные разрешения. Правильно определяя учетные записи служб и управляя ими, вы можете свести к минимуму риски безопасности и убедиться, что эти учетные записи используются соответствующим образом.

  • Создание учетных записей службы с одним назначением: каждая служба должна иметь свою выделенную учетную запись для минимизации рисков. Избегайте использования обычных учетных записей пользователей в качестве учетных записей служб .
  • Используйте Azure Resource Manager: Выполняйте аутентификацию с ресурсами Azure с помощью федерации удостоверений рабочей нагрузки с использованием регистрации приложения или управляемого удостоверения вместо использования регистрации приложения с секретом. Дополнительные сведения см. в статье ИспользованиеAzure Resource Manager.
  • Определение и отключение неиспользуемых учетных записей служб: регулярно просматривайте и идентифицируйте учетные записи, которые больше не используются. Отключите неиспользуемые учетные записи перед удалением.
  • ограничить привилегии: ограничить привилегии учетной записи службы до минимально необходимых. Избегайте интерактивных прав входа для учетных записей служб.
  • Используйте отдельные удостоверения для читателей отчетов: если вы используете учетные записи домена для учетных записей служб, используйте другое удостоверение для читателей отчетов, чтобы изолировать разрешения и предотвратить ненужный доступ.
  • использовать локальные учетные записи для установки рабочих групп: при установке компонентов в рабочей группе используйте локальные учетные записи для учетных записей пользователей. Избегайте учетных записей домена в этом сценарии.
  • Использовать подключения служб: Используйте подключения служб, когда это возможно для безопасного подключения к сервисам без непосредственной передачи секретных переменных в сборки. Ограничить соединения для определенных сценариев использования. Дополнительные сведения см. в разделе Подключения службы Scope в этой статье.
  • Мониторинг активности служебной учетной записи: настройте аудит и создайте аудиторские потоки для мониторинга активности служебной учетной записи.

Подключения службы области

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

  • Ограничить доступ: Ограничить доступ путем ограничения подключений службы Azure Resource Manager к определенным ресурсам и группам. Не предоставляйте широкие права участника во всей подписке Azure.
  • Используйте Azure Resource Manager: Выполняйте аутентификацию с ресурсами Azure с помощью федерации удостоверений рабочей нагрузки с использованием регистрации приложения или управляемого удостоверения вместо использования регистрации приложения с секретом. Дополнительные сведения см. в статье Создание подключения службы Azure Resource Manager, использующего федерацию удостоверений рабочей нагрузки.
  • группы ресурсов области: убедитесь, что группы ресурсов содержат только виртуальные машины или ресурсы, необходимые для процесса сборки.
  • Избегайте классических подключений к службам: Предпочтите современные подключения службы Azure Resource Manager вместо классических, которые не имеют возможностей для задания области.
  • Использовать учетные записи службы для конкретных целей: Проверять подлинность подключений к службам с помощью учетных записей службы команды для обеспечения безопасности и контроля.

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

Включение и проверка событий аудита

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

  • Включить аудит: отслеживать и просматривать события, связанные с действиями пользователя, разрешениями, изменениями и инцидентами безопасности. Дополнительные сведения см. в разделе Включение или отключение аудита.
  • регулярно проверять события аудита: регулярно просматривать журналы аудита для мониторинга действий пользователей и обнаружения подозрительного поведения. Ищите непредвиденные шаблоны использования, особенно у администраторов и других пользователей. Это действие помогает выявить потенциальные нарушения безопасности и принять корректирующие действия. Дополнительные сведения см. в разделе Просмотрите журнал аудита и Аудит событий.
  • Настройка оповещений системы безопасности: настроить оповещения для уведомления о любых инцидентах безопасности или нарушениях политики. Это действие обеспечивает своевременное реагирование на потенциальные угрозы.

Защита данных

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

  • Защитить данные: защитить данные с помощью стратегий шифрования, резервного копирования и восстановления. Для получения дополнительной информации см. Защита данных.
  • добавить IP-адреса и URL-адреса в список разрешений: Если ваша организация защищена брандмауэром или прокси-сервером, добавьте IP-адреса и URL-адреса в список разрешений. Дополнительные сведения см. в разделе Разрешенные IP-адреса и URL-адреса домена.