🛠 Нетривиальное Reco для сети и управления репозиториями

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

Сам контроль репозиториями на уровне доступов мы посмотрим позже вместе и да, мы рассмотрим роли со стороны ИБ. Будем брать то, что можно достать из коробки на CE. Кастом всегда можно запилить 🙃

Сегментация и связанность

1 - GitLab CE:

— bastion‑узлов: админ‑доступ (Web, SSH для root/ maintenance) только из jump‑host’ов

— Inbound: HTTPS (443)/SSH (22) с рабочих подсетей, сегмента раннеров

— Outbound: только к корпоративному SMTP, мониторингу/ логам, внутреннему Nexus/ registry, внешнему интернету через прокси при необходимости зависимости, с явным egress‑ACL

2 - GitLab Runner (инфраструктурные раннеры, не shared в DMZ):

— Размещение в отдельном сегменте «CI‑runner zone» с доступом Outbound к GitLab по HTTPS/SSH (API для регистрации, получения job, push артефактов)

— Размещение в отдельном сегменте «CI‑runner zone» с доступом Outbound к Nexus/иному артефакт‑репозиторию только по нужным портам (например, 8081/8082 для HTTP(S))

— Запрет прямого доступа раннеров к боевым БД и внутренним бизнес‑сервисам, кроме явно необходимых для тестов стендов

— Outbound к Интернету — через прокси и только для скачивания зависимостей/ баз уязвимостей; при возможности использовать зеркала в Nexus

— Inbound к раннерам: закрыт (только инициатива от раннера к GitLab/Nexus); управляющее соединение runner → GitLab по HTTPS

3 - Nexus/ репозиторий артефактов:

— Inbound: доступ только из сегмента раннеров и, при необходимости, из сегмента сборочных серверов/релиз‑оркестраторов

— Outbound: к внешним central‑репозиториям (Maven Central, PyPI, npm и т.п.) через контролируемый прокси; к Internet — только через egress‑фильтрацию и инспекцию

Практика управления репозиториями

- При построении ACL использовать принцип белых списков: запрещено всё, что не разрешено явно

- Сетевой трафик между всеми сегментами VLAN должен быть запрещен по умолчанию

- Административный доступ (SSH, RDP, доступы к DB и тд.) ко всем узлам во всех сегментах должен быть разрешен только со специально выделенного сегмента управления Management VLAN

- Должна соблюдаться четкая классификация всех проектов в соответствии с уровнем конфиденциальности данных: Private (конфиденциальные данные), Internal (внутренняя информация), Public (открытые данные)

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

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

- В защищённых ветках должно быть запрещено выполнение force push

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

- Рекомендуется включать этап проверки подписи коммитов в конвейер CI/CD

- Артефакты CI/CD должны храниться в корпоративных зашифрованных хранилищах с ограничением срока жизни (пример S3)

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

- Необходимо использовать защиту тегов для контроля над развертыванием и выпуском версий

- Джобы, работающие с секретами или производящие сборку для продакшена, должны запускаться на выделенных раннерах со строгим контролем доступа

- Видимость секретов, хранящихся в переменных CI/CD должны быть «masked and hidden»

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

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

#appsec #devsecops #reco #pmcases #toolchain