Обеспечение безопасности окружения разработчика для модели нулевого доверия

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

Скорость разработчика зависит от вашей способности работать тогда и там, где вы хотите, чтобы максимизировать бизнес-результаты. Вам нужны мощные и настраиваемые машины с доступом root или правами администратора. Однако требования разработчиков могут противоречить нормативным требованиям, а также необходимости аудита и контроля доступа к среде частных сотрудников и их данным хранения.

Неуправляемые машины, которые подключаются к сети организации, создают проблему для команд безопасности, отдела закупок и совета по управлению. В идеальном случае предоставление разработчикам сред по умолчанию и укрепленных рабочих сред вызывает недовольство с обеих сторон. Когда сотрудники подключаются из любого места, уязвимые Wi-Fi сети являются открытой дверью для кибератак. Кражи оборудования и потери являются основными проблемами.

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

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

Предоставление участникам команды DevOps гибкости и контроля при предотвращении вредоносных атак является основной проблемой для офисов безопасности. DevOps может управлять средой разработчика с облачной средой (см. доверенный запуск для виртуальных машин Azure и GitHub Enterprise Cloud Docs) и защитить среду разработчика с помощью контейнеров (см. документацию по GitHub Codespaces).

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

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

Рекомендации по наименьшим привилегиям

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

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

• Реализуйте минимальные привилегии и JIT-доступ для DevOps. Убедитесь, что участники команды поддерживают только необходимый минимальный доступ к средам в течение минимально необходимого времени. Создайте политики для контроля прав доступа администратора на основных устройствах, инструментах DevOps, конвейерах релизов, репозиториях кода, средах, хранилищах паролей и секретов и базах данных. Для команд DevOps базовым требованием является подключение к хранилищу удостоверений организации. Используйте федерацию удостоверений для интеграции с средами SaaS, чтобы избежать дублирования удостоверений на платформах, отличных от Майкрософт, и снизить риск воздействия.
• Не используйте личные маркеры доступа для доступа к исходному коду. Безопасные методики для команд DevOps включают доступ к инструментам DevOps на основе SaaS, репозиториям кода (через SSH, HTTPS или личный маркер доступа). Для доступа к среде на основе SaaS есть четкие инструкции по тому, как принципы доступа определяют, кто может загружать (клонировать) системные репозитории и с которых устройства (локальные, облачные и контейнеры). Например, OneDrive может блокировать или ограничивать неуправляемый доступ к устройству.
• Стандартизация и синхронизация учетных записей пользователей GitHub Enterprise Managed User (EMU) с корпоративными удостоверениями. С помощью корпоративных управляемых пользователей вы можете контролировать учетные записи членов вашей компании с помощью провайдера удостоверений (IdP). В хранилище удостоверений вашей организации явно определяются имена пользователей GitHub, адреса электронной почты и отображаемые имена. Затем пользователи легко определяют участников совместной работы.
• Для трех способов, которыми разработчик может подключиться к среде SaaS (с помощью HTTPS с идентификацией, личного маркера доступа, использования ключа SSH), необходимо использовать хранилище идентификаций организации. С помощью GitHub (за исключением учетных записей EMU GitHub), ваше удостоверение всегда является вашим общедоступным удостоверением. Для управляемого доступа через единый вход требуется подключение к хранилищу удостоверений организации.
• Используйте центр сертификации SSH (ЦС), чтобы предоставить подписанные сертификаты SSH для участников для безопасного доступа к ресурсам с помощью Git. Сертификат SSH используется для подписания одного ключа SSH другим ключом SSH. GitHub Enterprise Cloud поддерживает сертификаты SSH, чтобы предоставить организациям больше контроля над доступом к репозиториям участников. Администраторы могут отправлять открытый ключ ЦС SSH и выдавать сертификаты для участников, которые будут использоваться для проверки подлинности Git. Сертификаты могут получать доступ только к репозиториям, принадлежащим организации. Администраторы могут требовать от членов использовать сертификаты при доступе к репозиториям.
• Используйте диспетчер учетных данных Git для защиты доступа к коду. Средства, такие как Visual Studio (VS), имеют встроенную поддержку идентичности. VS Code передаёт диспетчеру учетных данных Git.

Рекомендации по обеспечению безопасности ветви

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

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

• Защита ветвей с помощью проверок кода позволяет командам DevOps контролировать процесс изменения кода и совершенствование аудита. Стратегия ветвления на предыдущей схеме сформулирует управляемый поток изменений, который обеспечивает четкую цепочку команд и схемы для решения изменений кода. Из различных подходов к стратегии ветвления одним из общих элементов является то, что защищенные ветви служат источником для новых выпусков в продакшн.
• Администраторы репозиториев Git контролируют авторизацию утверждения. Механизм контроля стратегий ветвления находится в процессе утверждения. Защищенные ветви требуют валидации, обзора и утверждения перед принятием изменений. Одним из вариантов является создание правила защиты ветви для принудительного применения рабочих процессов. Например, требуется утверждение или прохождение проверки состояния для всех запросов на включение изменений, объединенных в защищенную ветвь. Политики веток помогают командам защищать важные ветки разработки. Политики обеспечивают качество кода и стандарты управления изменениями в команде.

Рекомендации по обеспечению доверия к средствам, расширениям и интеграции

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

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

• Убедитесь, что вы используете инструменты только из доверенных рынков и от надежных издателей. Например, в Marketplace VS Code есть тысячи расширений, которые упрощают работу. Однако, когда команды принимают новые инструменты или расширения, наиболее важным аспектом может быть проверка надежности издателя.
• Настройте безопасные методики управления расширением, чтобы ограничить область атаки сред разработчика. Большинство расширений интегрированной среды разработки требуют утверждения определенных привилегий для работы, часто в виде файла с разрешениями на чтение в системе для анализа кода. Расширения требуют подключения к облачным средам для работы (распространенные в средствах метрик). Утверждение дополнительных функций на основе интегрированной среды разработки открывает организациям больше угроз.
• На компьютерах разработчиков отслеживайте количество и зрелость используемых расширений, чтобы понять потенциальную область атаки. Включите только расширения VS Code Marketplace из проверенных издателей. При установке расширений приложений с помощью VS Code регулярно проверьте расширения, которые вы выполняете с помощью командной строки, кода --list-extensions --show-versions. Имейте хорошее представление о расширяемых компонентах, с которыми вы работаете в среде разработки.

Дальнейшие действия

• Внедрение безопасности нулевого доверия в рабочий процесс разработчика помогает быстро и безопасно внедрять инновации.
• Защита среды платформы DevOps помогает реализовать принципы нулевого доверия в среде платформы DevOps и выделяет рекомендации по управлению секретами и сертификатами.
• Безопасные среды DevOps для обеспечения Нулевого доверия описывают передовые методы по защите сред DevOps с использованием подхода "Нулевое доверие", чтобы предотвратить компрометацию со стороны злоумышленников, внедрение вредоносных сценариев в инфраструктурные конвейеры и предотвращение несанкционированного доступа к рабочим данным через тестовые среды.
• Ускорьте и защитите код с помощью Azure DevOps с помощью средств, которые предоставляют разработчикам самый быстрый и безопасный код для облачного интерфейса.
• Настройте Azure, чтобы доверять OIDC GitHub в качестве федеративного удостоверения. OpenID Connect (OIDC) позволяет рабочим процессам GitHub Actions получать доступ к ресурсам в Azureбез необходимости хранить учетные данные Azure в виде секретов GitHub.