В данной статье рассмотрим основные проблемы безопасности CI/CD и передовые стратегии предотвращения возможных угроз.
Компании-разработчики программного обеспечения уже давно полагаются на DevOps-подход с целью повышения уровня гибкости и качества коллабораций при поставке программного обеспечения. Пайплайны-CI/CD автоматизируют процессы в жизненном цикле разработки программного обеспечения (SDLC), осуществляя плавную интеграцию и поставку новых функций. Совершенствование программного обеспечения за счет преобразования процессов автоматизации и гибкости предполагает интеграцию многочисленных инструментов и сервисов, что может привести к возникновению пробелов в защите. Их выявление и устранение является ключом к обеспечению безопасности CI/CD. В данной статье рассмотрим, как защитить ваш пайплайн CI/CD.
Знакомство с основами безопасности CI/CD
В то время как конвейеры CI/CD повышают эффективность разработки и доставки программного обеспечения за счет автоматизации, основные этапы пайплайна по умолчанию не включают обеспечение безопасности. Защита CI/CD - это набор методов и практик, направленных на выявление и устранение уязвимостей без существенного замедления процессов пайплайна. Такие методы в основном включают пентесты и активные аудиты безопасности c целью уменьшения проблем, вызванных поздней передачей управления командам безопасности и контроля качества. Защищенные пайплайны CI/CD позволяют командам разработчиков автоматизировать безопасность для нескольких сред развертывания и уровней SDLC, обеспечивая максимальную гибкость.
Основные угрозы безопасности для пайплайна CI/CD
Конвейер CI/CD каждой организации обладает уникальным набором характеристик, основанным на бизнес-модели, рабочей нагрузке и используемом технологическом стеке. Именно поэтому особенности обеспечения безопасности CI/CD могут отличаться в зависимости от конкретного случая. Однако, риски безопасности в разных пайплайнах могут быть очень похожими друг на друга и требуют аналогичных методов выявления и устранения неполадок. Такие риски включают в себя:
Неавторизованный доступ к коду
Функционирование CI/CD базируется на общих репозиториях для управления процессами совместной работы, конфигурациями, обновлениями и контролем версий. Весь исходный код и конфигурационные файлы хранятся в репозитории Git как едином источнике информации. Репозитории общего доступа популярны в современных конвейерах CI/CD, т.к они сокращают затраты и время на разработку. Однако, такие репозитории представляют немалую угрозу безопасности, поскольку разработчики публикуют исходный код со своих частных компьютеров в общедоступных папках. Злоумышленники могут осуществлять поиск в реестрах с открытым исходным кодом с целью разведки и использования полученных данных для целенаправленного фишинга, обратной разработки и атак удаленного выполнения кода.
Небезопасный код
Требования быстрой разработки и доставки в конвейерах CI/CD привели к более широкому использованию интеграции со сторонними опенсорс-платформами. Как результат, некоторые команды могут импортировать интеграции со сторонними платформами в среду развертывания без надлежащей проверки исходного кода на наличие пробелов в безопасности. Такие интеграции могут привести к возникновению уязвимостей в пайплайне CI/CD. Более того, иногда разработчики могут не следовать рекомендациям по обеспечению безопасности кода, что увеличивает вероятность атаки. Среди прочих распространенные слабые места кода включают в себя уязвимости форматной строки, переполнение буфера, неправильную обработку ошибок и проблемы с канонизацией.
Ненадлежащее управление секретами
Секреты помогают управлять доступом к данным и ресурсам в рамках конвейера CI/CD. К ним относятся пароли, токены, API-ключи и другие учетные данные аутентификации, используемые для проверки пользователей, получающих доступ к конфиденциальным системам в пайлайне. Таким образом, открытые секреты могут предоставить злоумышленнику контроль над частью или всеми CI/CD-процессами. Неправильные настройки управления секретами включают в себя, среди прочего, жестко закодированные секреты, хранение секретов в общедоступных облачных средах и ручное управление секретами.
Обеспечение безопасности с помощью техники “Shifting Left”
В старых пайплайнах обеспечение безопасности часто было последним шагом, что приводило к узким местам при развертывании. На сегодняшний день более продвинутые практики требуют интеграции элементов управления безопасностью ранее - на этапе SDLC. Этот метод также называют "сдвиг безопасности", что предполагает внедрение проверок безопасности на каждом уровне конвейера CI/CD, позволяя более точно обнаруживать угрозы на каждом этапе. Цель такой практики состоит в том, чтобы устранить разногласия между DevOps и командами безопасности, повысить эффективность разработки и обеспечить надежность систем безопасности.
Основы внедрения средств обеспечения безопасности CI/CD
Учитывайте следующие факторы при выборе инструмента защиты конвейера CI/CD:
Охват сканирования
Стоимость владения и условия лицензирования
Необходимые усилия по техническому обслуживанию и настройке
Масштабируемость
Интеграция с существующим стеком разработки и безопасности
Администрирование безопасности в конвейере CI/CD
В условиях постоянно меняющегося ландшафта угроз, администрирование безопасности является одним из ключевых аспектов конвейера CI/CD. Первый шаг в обеспечении безопасности рабочих процессов DevOps заключается в оценке возможностей применения принципов DevSecOps на ваших конвейерах CI/CD. Одной из целей тщательной оценки является определение инструментов и стратегий для обеспечения надежной безопасности.
Рекомендации по обеспечению безопасности пайплайна CI/CD
Чтобы в полной мере реализовать преимущества интеграции безопасности в жизненный цикл программного обеспечения, команды должны:
Избегать жесткого кодирования секретов в файлах конфигурации и инструментах сборки CI/CD
Секреты необходимы на различных этапах SDLC. Простой способ предоставить эти секреты - ссылаться на них как на переменные среды в файлах конфигурации и манифестах. Любой, кто имеет доступ к этим шаблонам и файлам, может извлечь учетные данные из этих файлов, что потенциально может привести к их утечке. Команды разработчиков программного обеспечения должны использовать инструменты, которые шифруют, хранят и позволяют централизованно управлять секретами, чтобы защитить учетные данные от злоумышленников. Чтобы безопасно управлять секретами и распространять их, администраторам следует уладить вопрос с шифрованием, прежде чем сохранить их на сервере ETCD.
Сначала закодируйте секреты в формате Base64, как показано ниже:
$ username=$(echo -n "admin" | base64)
$ password=$(echo -n "a62fjbd37942dcs" | base64)Определите секреты в файле YAML:
$ username=$(echo -n "admin" | base64)
$ password=$(echo -n "a62fjbd37942dcs" | base64)echo "apiVersion: v1
> kind: Secret
> metadata:
> name: test-secret
> type: Opaque
> data:
> username: $username
> password: $password" >> secret.yamlСразу после создания секретов вы можете использовать их для применения в поде Kubernetes. Это можно сделать, создав файл .yaml, secret-env.yaml, переменные среды которого заполняются данными из секрета. Спецификации файла будут выглядеть следующим образом:
apiVersion: v1
kind: Pod
metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: alpine:latest
command: ["sleep", "9999"]
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: test-secret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: test-secret
key: password
restartPolicy: NeverПри заполнении переменных среды Kubernetes декодирует значения Base64. Эти переменные среды могут использоваться во всех объектах API Kubernetes, что устраняет необходимость в жестком кодировании секретных данных.
Обеспечьте контроль доступа инструментов сборки CI/CD
Специалисты DevOps должны внедрить механизмы аутентификации и авторизации для управления объектами, которые могут получать доступ к определенным процессам и инструментам в пайплайне CI/CD. В данном случае важно применять принцип наименьших привилегий, чтобы гарантировать, что доступ к ресурсам предоставляется только тем, кто в этом максимально нуждается. Данные в конвейере CI /CD также должны быть защищены с помощью токенов, ключей доступа и паролей, во избежание возникновения дополнительной вредоносной нагрузки на пайплайн.
Создайте механизмы аутентификации для управления версиями
Репозитории контроля версий (чаще всего в Git) являются обязательными для конвейеров CI/CD. Они способствуют сотрудничеству и обеспечивают непрерывное развертывание функций. Поскольку репозиторий Git содержит исходный код приложения, Infrastructure-as-Code-манифесты и интеллектуальную собственность, уязвимость в системе управления версиями может предоставить злоумышленникам доступ к логике разработки и реализации приложения. Доступ к репозиториям Git, являющийся желанной добычей для хакеров, должен быть защищен с помощью многофакторной аутентификации. Плюс ко всему, команды могут предотвратить возникновение случайных веток и коммитов с помощью файла .gitignore, а также обучать разработчиков передовым методам Git.
Обеспечьте равенство конфигураций во всех средах конвейера
Команды DevOps должны убедиться в том, что все среды (разработка, тестирование, производство и т. д.) настроены одинаково. Благодаря паритету группы контроля качества смогут с точностью обнаруживать проблемы безопасности во время тестирования, ведь такие неполадки могут возникать во всех конфигурациях среды. Подобное равенство может быть достигнуто с помощью внедрения технологий виртуализации и абстракции, таких, например, как контейнеры и принципы подхода Infrastructure-as-Code.
Настройте возможность отката
Команды безопасности и контроля качества часто обнаруживают проблемы безопасности после обновления или развертывания приложений. Для администраторов это приводит к возникновению необходимости отката развертывания к более ранней версии. Развертывание должно быть настроено таким образом, чтобы обеспечить плавный откат, устраняющий проблему безопасности, пока команда разработчиков не разрешит ее. Откаты лучше всего достигаются путем сохранения артефактов более старой версии до тех пор, пока новое развертывание не будет одобрено для производства.
Внедрите процесс постоянного сканирования и мониторинга уязвимостей
Важно отслеживать и тестировать каждую составляющую пайплайна CI/CD. Подберите оптимальное решение сканирования уязвимостей для тестирования кода приложения, конфигураций среды и сценариев развертывания на основе базы данных известных уязвимостей для устранения потенциальных атак. Такие инструменты сканирования и мониторинга должны быть развернуты по всему SDLC для выявления неполадок на ранней стадии, чтобы предотвратить эксплоиты.
Регулярно чистите ненужные ресурсы и утилиты
Конвейеры CI/CD обычно работают на неизменяемой инфраструктуре, которая запускает определенные процессы, а затем завершает работу. Команды DevOps, в свою очередь, должны обеспечить очистку всех временных ресурсов, таких как контейнеры, службы и виртуальные машины, после завершения работы. Учитывайте, что злоумышленники могут использовать открытые порты для получения первоначального доступа к среде развертывания, поэтому важно правильно управлять этими ресурсами, чтобы уменьшить брешь в безопасности.
Уровни безопасности CI/CD
Управление безопасностью CI/CD требует комплексного, многоуровневого подхода для усиления защиты в каждой точке конвейера. Такие уровни безопасности включают в себя:
Сканирование уязвимостей
Сканирование уязвимостей включает в себя использование баз данных известных угроз для выявления и устранения пробелов безопасности во всем пайплайне CI/CD. Автоматизированные тесты сканируют приложения и среду развертывания для выявления и классификации слабых мест в коде, инфраструктуре и сторонних службах.
Статическое тестирование безопасности
Это практика анализа состава программного обеспечения, направленная на выявление потенциальных уязвимостей кода, написанном внутренними командами разработчиков. Команды обеспечения безопасности часто используют эти инструменты для разработки тестовых примеров, чтобы точно определить уязвимости небезопасного кода перед развертыванием новых сборок приложений.
Безопасность во время выполнения
Этот уровень основан на инструментах самозащиты приложений во время выполнения (RASP) для обнаружения угроз безопасности приложений в реальных производственных средах. Эти инструменты сканируют шаблоны конфигурации и непрерывно проверяют состояние среды развертывания, а затем используют сравнение для выявления угроз и реагирования на них.
Аудит и мониторинг
Журналы приложений и инфраструктуры непрерывно отслеживают и хранят данные приложений и развертывания. Аудит включает в себя анализ этих журналов для определения шаблонов, которые могут быть использованы для улучшения состояния безопасности приложения. Мониторинг - это развертывание диагностических инструментов, которые анализируют показатели, чтобы составить представление о большинстве проблем, связанных с системой.
Постоянный аудит и мониторинг помогают командам создавать контекст и прогнозировать базовое поведение пользователей. Команды безопасности могут выявлять угрозы, анализируя действия пользователей, которые отклоняются от установленного базового уровня.
Подведем итоги
Поскольку код, выполняемый в конвейере CI/CD, может быть использован любым пользователем, имеющим доступ к репозиторию исходного кода конвейера или реестру контейнеров, неудивительно, что рабочие процессы DevOps могут неизбежно привести к возникновению проблем безопасности. Недавний опрос показал, что примерно 55% организаций откладывают развертывание приложений из-за соображений безопасности. Обратите внимание на возможности расширения возможностей совместной работы и автоматизации на базе DevOps. Настало время внедрять модель непрерывной безопасности, учитывая передовые стратегии и инструменты для обеспечения всеобъемлющей защиты на всех уровнях конвейера CI/CD.
Ещё больше материалов по теме DevOps (и не только) в нашем телеграм-канале DevOps FM, присоединяйся :)