🛠 Нетиповые практики DevSecOps для CI/CD

Салют,

Давай с тобой продолжим смотреть в сторону практик DevSecOps и в этот раз обсудим CI/CD, где я хочу поделиться с тобой выработанными принципами, которые считаю актуальными и основными при проработке концептов.

Continuous Integration/ Continuous Delivery — это автоматизация процессов разработки, которая включает непрерывную интеграцию и непрерывную доставку. Автоматизация нацелена на SDLC цикл.

А теперь давай рассмотрим сами практики и начнем с базы:

- Изоляция контроллера: сборки не на встроенном узле, а инициализируются из глобальных переменных

- Не допускается наличие не используемых переменных среды

- Не запускать сборку от ТУЗ с привилегированными правами

- Средства сборки и деплоя не должны требовать расширение прав доступа

- Обеспечивать строгий рендеринг пользовательского контента: файлы из рабочих директорий, архивные артефакты и т.д.

- В процессе CI\CD должна быть исключена возможность переполнений и несанкционированной перезаписи.

- Не допускается вызов внешних зависимостей на этапе деплоя

Stages

- Каждый Stage изолируется и разделяет операции функционально

- Учётные записи, используемые или вызываемые при сборке или деплое, должны проходить предварительную аутентификацию:

- аутентификация должна быть персональной и обеспечивать возможность отслеживать действия;

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

- Все jobs необходимо разделять по назначению: CI (сборка, тестирование, анализ кода и т.д. - обособленно и не взаимодействует со средами эксплуатации, а CD использует отдельные УЗ

- Библиотеки, сборки и шаблоны конвейеров следует хранить отдельно от управляющего конфига

- Рекомендуется использовать отдельные репозитории для сборок и шаблонов для изоляции конфигураций

- Подключаемые скрипты: Groovy, Shell, Python и др. не должны содержать проверок или условий, позволяющих обходить этапы сборки, тестирования или других критических стадий конвейера

- Для обеспечения целостности и отслеживания изменений необходимо автоматически собирать хэш-сумму профиля конвейера или конфигурации при каждой сборке

- На этапе CD требуется проверка хэш-суммы профайла

Особенности

- Ниже maintainer нет возможности самостоятельно выбирать окружение и быть ограничены

- Деплой не должен выполняться без MR

- Все pre-действия должны включать полные метаданные артефакта — параметры сборки, атрибуты поставки и идентификаторы версий

- Все callback-действия внутри конвейера,

- Build и тд. должны выполняться только для приложений, упакованных в Docker-контейнеры для единообразия сред

- В CI рекомендуется запускать несколько типов тестов: интеграционные, unit-тесты, регрессионные тесты

- При неуспешной сборке артефакт не должен попадать в репозиторий артефактов

- Среды деплоя: staging, production и тд. должны быть логически и физически разделены

- Все post-действия в конвейере не должны вызываться независимо и обязаны выполняться только после завершения соответствующих pre- или main-этапов

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

#appsec #devsecops #reco #specialty #pmcases