🛠 Нетривиальное Reco при разрабоке ПО

Салют,

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

Docker игнорирование

Необходимо для .dockerignore, который указывает докеру какие файлы не стоит копировать в образ при сборке образа, вносить минимально необходимые параметры, такие как:

— Секреты и ключи: .env, *.pem, *.key, id_rsa, как полный доступ к БД, серверам, API, приватные ssh ключи

— Конфигурации с паролями: config/*.json, settings.yml, как утечка учётных данных и внутренних настроек

— Данные пользователей: *.sqlite, *.db, exports/, как утечка персональных данных

— Служебные файлы системы и IDE: .git/, .idea/, .vscode/, как раскрытие истории изменений, путей, логинов

— Временные и кэш-файлы: tmp/, cache/, __pycache__/, как утечка отладочной информации

- Аналогичный формат для helm-чартов. Все описаное для dockerignore также верно и для .helmignore

Git игнорирование

— Баз данных

— Файлов, образующихся в процессе и результате компиляции проекта вроде target/, output/, release/, debug/

— Разные сторонние инструменты

— Файлы, генерируемые тестовым фреймворком, профилировщиком, дебаггером и т.п.

— Сгенерированная из кода документация только в отдельный удаленный репозиторий, через который потом развертываете сайт с документацией (пример mkdocs + gpages)

— Файлы, создаваемые при выполнении кода: журналы (*.log), результаты работы и т.п.

— Временные файлы текстового редактора или среды разработки типа *~.

— Файлы, создаваемые операционной системой, например thumbs.db, .DS_Store

CI/CD

- Необходимо реализовать раздельные CI workflow для каждого контура внутри стендов, как пример DEV, TEST, CERT, PROD и тд

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

- Хранение секретов в коде, в репозитории или в конфигурационных файлах запрещено. В случае обнаружения секретов в MR, пайплайн должен автоматически блокировать merge/ pull

- Неиспользуемые сервисы должны быть отключены, брандмауэр настроен и ограничен сетевой доступ к инстансу

- Доступ должен осуществляться исключительно по протоколу TLS 1.3 с современными шифрами. Использование HTTP или устаревших алгоритмов шифрования запрещено

- Все Runner'ы должны быть размещены в изолированных сетях с строгим контролем исходящего трафика

Архитектура

- Доступ в интернет должен быть запрещен по умолчанию и предоставляться только выделенным Runner'ам через прокси-серверы с white-list фильтрацией по FQDN для загрузки исключительно необходимых зависимостей

- Должен быть разработан и поддерживаться Disaster Recovery Plan (DRP), включая периодическую проверку восстановления

- База данных должна размещаться в отдельном инстансе/ кластерe, с ограничением доступа только для серверов repo hpsts с применением шифрования

Инфраструктура внутри периметра

- Развёртывание repo host в выделенном серверном сегменте VLAN с ограниченным входом только по HTTPS/SSH с рабочих сетей и из сегмента раннеров

- Белые списки должны быть только реализованы для доверенных пользователей и только через сторонний jump сервер и/или песочницу

- Использовать отдельные VM, а также кластера под Web UI, API, Sidekiq тд, включая отдельный экземпляра для PostgreSQL, Redis и тд либо управляемых сервисов БД, кэша

- Необходимо достичь отказа от «all‑in‑one» на PROD

- Обязательное включение HTTPS с внутренним корпоративным PKI, запрет plain HTTP, настройка HSTS и TLS 1.3

- Необходима реализация для ограничения протоколов, шифров по корпоративному криптопрофилю

- Необходимо использование 2FA, SSO при IdP, а также принудительная 2FA политика для всех пользователей

- Использование только сильных ключей SSH Ed25519, RSA с достаточной длиной, реализовать запрет DSA

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

#appsec #devsecops #reco #pmcases #toolchain