Используйте сторонние артефакты программного обеспечения в цепочке поставок, только если они проверяются и помечены как безопасные для использования, определенными процессами. Этот шаблон является операционным боковином элементе процесса разработки. Потребитель этого шаблона вызывает этот процесс, чтобы проверить и заблокировать использование программного обеспечения, которое может потенциально привести к уязвимостям безопасности.
Контекст и проблема
Облачные решения часто используют стороннее программное обеспечение, полученное из внешних источников. Двоичные файлы с открытым исходным кодом, общедоступные образы контейнеров, образы ОС поставщика являются примерами этих типов артефактов. Все такие внешние артефакты должны рассматриваться как ненадежные.
В типичном рабочем процессе артефакт извлекается из хранилища за пределами области решения, а затем интегрируется в конвейер развертывания. В этом подходе существуют некоторые потенциальные проблемы. Источник может быть ненадежным, артефакт может содержать уязвимости, или он может быть не подходит другим способом для среды разработчика.
Если эти проблемы не устранены, гарантии целостности и конфиденциальности решения могут быть скомпрометированы или вызвать нестабильность из-за несовместимости с другими компонентами.
Некоторые из этих проблем безопасности можно избежать путем добавления проверок в каждый артефакт.
Решение
Перед вводом в рабочую нагрузку необходимо проверить программное обеспечение для обеспечения безопасности. Во время процесса каждый артефакт проходит тщательную операционную страсти, которая проверяет его в определенных условиях. Только после того, как артефакт удовлетворяет этим условиям, процесс помечает его как доверенные.
Процесс карантина является мерой безопасности, которая состоит из ряда контрольных точек, которые используются до использования артефакта. Эти контрольные точки безопасности позволяют убедиться, что артефакт переходит из ненадежного состояния в доверенное состояние.
Важно отметить, что процесс карантина не изменяет состав артефакта. Процесс не зависит от цикла разработки программного обеспечения и вызывается потребителями по мере необходимости. В качестве потребителя артефакта блокируйте использование артефактов до тех пор, пока они не прошли карантин.
Ниже приведен типичный рабочий процесс карантина:
Потребитель сообщает о своем намерении, указывает источник входных данных артефакта и блокирует его использование.
Процесс карантина проверяет источник запроса и получает артефакты из указанного хранилища.
Процесс пользовательской проверки выполняется в рамках карантина, включающее проверку входных ограничений и проверку атрибутов, источника и типа в соответствии с установленными стандартами.
Некоторые из этих проверок безопасности могут быть сканирование уязвимостей, обнаружение вредоносных программ и т. д. на каждом отправленном артефакте.
Фактические проверки зависят от типа артефакта. Оценка образа ОС отличается от оценки пакета NuGet, например.
Если процесс проверки выполнен успешно, артефакт публикуется в безопасном хранилище с четкими заметками. В противном случае он остается недоступным для потребителя.
Процесс публикации может включать накопительный отчет, показывающий подтверждение проверки и критическость каждой проверки. Включение срока действия в отчет, за пределами которого отчет должен быть недопустимым, и артефакт считается небезопасным.
Процесс помечает конец карантина, сигналив о событии с сведениями о состоянии, сопровождаемым отчетом.
На основе информации потребители могут принять меры для использования доверенного артефакта. Эти действия находятся вне области шаблона карантина.
Проблемы и рекомендации
Как команда, которая использует сторонние артефакты, убедитесь, что она получена из доверенного источника. Ваш выбор должен соответствовать утвержденным организацией стандартам для артефактов, приобретенных сторонними поставщиками. Поставщики должны соответствовать требованиям безопасности рабочей нагрузки (и вашей организации). Например, убедитесь, что ответственный план раскрытия информации поставщика соответствует требованиям безопасности вашей организации.
Создайте сегментацию между ресурсами, которые хранят доверенные и ненадежные артефакты. Использование удостоверений и сетевых элементов управления для ограничения доступа к авторизованным пользователям.
Надежный способ вызова процесса карантина. Убедитесь, что артефакт не используется непреднамеренно, пока не помечается как доверенный. Сигнал должен быть автоматизирован. Например, задачи, связанные с уведомлением ответственных сторон при приеме артефакта в среду разработчика, фиксации изменений в репозитории GitHub, добавлении образа в частный реестр и т. д.
Альтернативой реализации шаблона карантина является аутсорсинг. Есть практики карантина, которые специализируются на проверке государственных активов в качестве бизнес-модели. Оцените финансовые и операционные затраты на реализацию шаблона и аутсорсинг ответственности. Если требования к безопасности требуют больше контроля, рекомендуется реализовать собственный процесс.
Автоматизируйте процесс приема артефактов, а также процесс публикации артефакта. Так как задачи проверки могут занять время, процесс автоматизации должен продолжаться до завершения всех задач.
Шаблон служит первой возможностью для мгновенной проверки. Успешное прохождение карантина не гарантирует, что артефакт остается надежным на неопределенный срок. Артефакт должен продолжать проходить непрерывную проверку, проверку конвейера и другие стандартные проверки безопасности, которые служат в качестве последней возможности проверки перед продвижением выпуска.
Шаблон можно реализовать центральными командами организации или отдельной рабочей нагрузки. Если существует множество экземпляров или вариантов процесса карантина, эти операции должны быть стандартизированы и централизованны в организации. В этом случае команды рабочей нагрузки совместно используют процесс и получают выгоду от разгрузки управления процессами.
Когда следует использовать этот шаблон
Используйте этот шаблон, когда:
Рабочая нагрузка интегрирует артефакт, разработанный вне области рабочей нагрузки. Ниже приведены распространенные примеры:
Артефакт Open Container Initiative (OCI) из общедоступных реестров, таких как DockerHub, реестр контейнеров GitHub, реестр контейнеров Майкрософт
Библиотека программного обеспечения или пакет из общедоступных источников, например коллекция NuGet, индекс пакета Python, репозиторий Apache Maven
Внешний пакет "Инфраструктура как код" (IaC), например модули Terraform, книги повара сообщества, проверенные модули Azure
Предоставленный поставщиком образ ОС или установщик программного обеспечения
Команда рабочей нагрузки рассматривает артефакт как риск, который стоит смягчить. Команда понимает негативные последствия интеграции скомпрометированных артефактов и значения карантина в обеспечении надежной среды.
Команда имеет четкое и общее представление о правилах проверки, которые должны применяться к типу артефакта. Без консенсуса шаблон может оказаться не эффективным.
Например, если при каждом приеме образа ОС в карантин применяется другой набор проверок, общий процесс проверки образов ОС становится несогласованным.
Этот шаблон может оказаться не полезным, если:
Артефакт программного обеспечения создается командой рабочей нагрузки или доверенным партнером.
Риск того, что артефакт не проверяется, дешевле, чем стоимость строительства и поддержания процесса карантина.
Проектирование рабочей нагрузки
Архитектор и команда рабочей нагрузки должны оценить, как шаблон карантина можно использовать в рамках методик DevSecOps рабочей нагрузки. Основные принципы рассматриваются в
| Столб | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| решения по проектированию безопасности помогают обеспечить конфиденциальность, целостностьи доступность данных и систем рабочей нагрузки. | Первая ответственность за проверку безопасности выполняется шаблоном карантина. Проверка внешнего артефакта проводится в сегментированной среде, прежде чем она используется процессом разработки. - жизненный цикл разработки se:02 Secured development - SE:11 Тестирование и проверка |
| Шаблон карантина поддерживает безопасные методики развертывания (SDP), убедившись, что скомпрометированные артефакты не используются рабочей нагрузкой, что может привести к нарушениям безопасности во время прогрессивных развертываний. - методики разработки программного обеспечения OE:03 - OE:11 Тестирование и проверка |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Пример
Этот пример применяет рабочий процесс решения к сценарию, в котором группа рабочей нагрузки хочет интегрировать артефакты OCI из общедоступных реестров с экземпляром Реестра контейнеров Azure (ACR), который принадлежит группе рабочей нагрузки. Команда рассматривает этот экземпляр как доверенное хранилище артефактов.
Среда рабочей нагрузки использует политику Azure для Kubernetes для обеспечения управления. Он ограничивает извлечение контейнера только из своего доверенного экземпляра реестра. Кроме того, оповещения Azure Monitor настраиваются для обнаружения любых импортов в этот реестр из непредвиденных источников.
Запрос внешнего образа выполняется командой рабочей нагрузки через пользовательское приложение, размещенное в веб-приложениях Azure. Приложение собирает необходимые сведения только от авторизованных пользователей.
контрольная точка безопасности: проверяется удостоверение запрашивающего, целевого реестра контейнеров и запрошенного источника образа.
Запрос хранится в Azure Cosmos DB.
Контрольная точка безопасности: в базе данных сохраняется след аудита, отслеживая происхождение и проверку образа. Этот путь также используется для исторических отчетов.
Запрос обрабатывается оркестратором рабочего процесса, который является устойчивой функцией Azure. Оркестратор использует метод точечной сборки для выполнения всех проверок.
контрольная точка безопасности: оркестратор имеет управляемое удостоверение с достаточным доступом для выполнения задач проверки.
Оркестратор отправляет запрос на импорт образа в реестр контейнеров Azure (ACR), который считается ненадежным хранилищем.
Процесс импорта в реестре карантина получает образ из ненадежного внешнего репозитория. Если импорт выполнен успешно, реестр карантина имеет локальную копию образа для выполнения проверок.
контрольная точка безопасности: реестр карантина защищает от изменения и потребления рабочих нагрузок во время процесса проверки.
Оркестратор выполняет все задачи проверки в локальной копии образа. К задачам относятся такие проверки, как обнаружение распространенных уязвимостей и уязвимостей (CVE), оценка программного обеспечения (SBOM), обнаружение вредоносных программ, подпись изображений и другие.
Оркестратор решает тип проверок, порядок выполнения и время выполнения. В этом примере в качестве средств выполнения задач используется экземпляр контейнера Azure и результаты находятся в базе данных аудита Cosmos DB. Все задачи могут занять значительное время.
Контрольная точка безопасности: этот шаг является ядром процесса карантина, который выполняет все проверки проверки. Тип проверок может быть пользовательскими, открытыми или приобретенными поставщиками решениями.
Оркестратор принимает решение. Если образ проходит все проверки, событие отмечается в базе данных аудита, образ отправляется в доверенный реестр, а локальная копия удаляется из реестра карантина. В противном случае образ удаляется из реестра карантина, чтобы предотвратить его непреднамеренное использование.
контрольная точка безопасности: оркестратор поддерживает сегментацию между доверенными и ненадежными расположениями ресурсов.
Заметка
Вместо того чтобы оркестратор принимает решение, команда рабочей нагрузки может взять на себя ответственность. В этом варианте оркестратор публикует результаты проверки через API и сохраняет образ в реестре карантина в течение определенного периода времени.
Команда рабочей нагрузки принимает решение после проверки результатов. Если результаты соответствуют их допустимости риска, они извлекают образ из репозитория карантина в экземпляр контейнера. Эта модель извлечения более удобна, если этот шаблон используется для поддержки нескольких групп рабочих нагрузок с различными отказоустойчивыми рисками безопасности.
Все реестры контейнеров охватываются Microsoft Defender для контейнеров, которые постоянно сканируют новые обнаруженные проблемы. Эти проблемы отображаются в службе "Управление уязвимостями Microsoft Defender".
Дальнейшие действия
При реализации этого шаблона может потребоваться следующее руководство.
Рекомендации по защите жизненного цикла разработки предоставляют рекомендации по использованию доверенных единиц кода на всех этапах жизненного цикла разработки.
рекомендации по безопасной цепочке поставок программного обеспечения особенно при наличии зависимостей NuGet в приложении.
защита от вредоносных общедоступных пакетов с помощью артефактов Azure.