Защита среды разработчика для нулевого доверия

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

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

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

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

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

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

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

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

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

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

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

• Реализуйте минимальные привилегии и JIT-доступ для DevOps. Убедитесь, что участники команды поддерживают только минимальный доступ к средам в течение короткого времени. Поместите политики для покрытия прав доступа администратора на основных устройствах, средствах DevOps, конвейерах выпуска, репозиториях кода, средах, хранилищах секретов и базах данных. Для команд DevOps базовым требованием является подключение к хранилищу удостоверений организации. Используйте федерацию удостоверений для интеграции с средами SaaS, чтобы избежать дублирования удостоверений на сторонних платформах и снизить риск воздействия.
• Не используйте личные маркеры доступа для доступа к исходному коду. Безопасные методики для команд DevOps включают доступ к инструментам DevOps на основе SaaS, репозиториям кода (через SSH, HTTPS или личный маркер доступа). Для доступа к среде на основе SaaS есть четкие инструкции по тому, как принципы доступа определяют, кто может загружать (клонировать) системные репозитории и с которых устройства (локальные, облачные и контейнеры). Например, OneDrive может блокировать или ограничивать неуправляемый доступ к устройству.
• Стандартизация и синхронизация учетных записей пользователей GitHub Enterprise Enterprise (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) настолько продуктивна, что она, по сути, является обязательной функцией. Вы полагаетесь на возможность применять и курировать расширения в Marketplace определенной интегрированной среды разработки для разработки оптимальной рабочей среды.

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

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

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

• Внедрение безопасности нулевого доверия в рабочий процесс разработчика помогает быстро и безопасно внедрять инновации.
• Защита среды платформы DevOps помогает реализовать принципы нулевого доверия в среде платформы DevOps и выделяет рекомендации по управлению секретами и сертификатами.
• Безопасные среды DevOps для Нулевого доверия описывают рекомендации по защите сред DevOps с помощью подхода "Нулевое доверие" для предотвращения взлома хакеров в полях разработчиков, заражения конвейеров выпуска вредоносными сценариями и получения доступа к рабочим данным через тестовые среды.
• Реализуйте принципы нулевого доверия, как описано в меморандуме 22-09 (в поддержку исполнительного указа США 14028 года, улучшения кибербезопасности страны) с помощью Идентификатора Microsoft Entra в качестве централизованной системы управления удостоверениями.
• Ускорьте и защитите код с помощью Azure DevOps с помощью средств, которые предоставляют разработчикам самый быстрый и безопасный код для облачного интерфейса.
• Настройте Azure для доверия OIDC OIDC GitHub в качестве федеративного удостоверения. OpenID Подключение (OIDC) позволяет рабочим процессам GitHub Actions получать доступ к ресурсам в Azure без необходимости хранить учетные данные Azureв виде секретов GitHub.