Средняя
Согласно новости https://www.securitylab.ru/news/570412.php Взломщик ByteToBreach опубликовал внутренности шведских госуслуг. Кейс CGI Sverige с заявленной утечкой исходного кода шведской e-government платформы интересен не только самим фактом компрометации. В публичных материалах описывалась цепочка через Jenkins, Docker-привилегии, SSH-ключи и дальнейшее перемещение по инфраструктуре. При этом важно оговориться: публично не подтверждено, что первичный доступ был получен именно из-за ошибки в правилах межсетевого экрана.
Но этот кейс хорошо подсвечивает другой вопрос: что может сделать атакующий после компрометации одного узла?
Первичный вход может произойти по‑разному: через уязвимость, утёкший токен, слабую учётную запись, ошибку конфигурации или открытый тестовый endpoint. Масштаб инцидента определяется не только точкой входа, но и тем, куда атакующий может пойти дальше.
Содержание
CI/CD — это критичная инфраструктура
Jenkins, GitLab Runner, TeamCity, Nexus, Docker-хосты и artifact registry часто воспринимаются как часть dev-инфраструктуры. Но это не просто инструменты разработки.
CI/CD-системы обычно имеют доступ к исходному коду, секретам, артефактам сборки, тестовым средам, контейнерным registry, базам данных, API и SSH-ключам. Если такая система скомпрометирована, атакующий получает удобную стартовую площадку для дальнейшего движения.
Поэтому правильный вопрос звучит не только так:
— Как атакующий попал на Jenkins?
Не менее важный вопрос:
— Почему после попадания на Jenkins он смог двигаться дальше?
Ответ часто лежит в области сетевой сегментации и матриц доступа.
Что такое матрица сетевого доступа?
Матрица сетевого доступа описывает, какие сегменты, системы или роли имеют право взаимодействовать друг с другом.
В простом виде она отвечает на четыре вопроса:
- Кто является источником трафика?
- Куда он может обращаться?
- По каким портам и протоколам?
- Зачем этот доступ нужен?
| Источник | Назначение | Сервис | Решение |
|---|---|---|---|
| Jenkins | Git repository | HTTPS | Разрешено |
| Jenkins | Artifact registry | HTTPS | Разрешено |
| Jenkins | Test environment | SSH/HTTPS | Разрешено |
| Jenkins | Production DB | Any | Запрещено |
| Jenkins | Management network | Any | Запрещено |
| User segment | Jenkins admin UI | Any | Запрещено |
| User segment | Jenkins admin UI | HTTPS | Разрешено |
Где сегментация ломается?
На старте инфраструктура обычно выглядит аккуратно: dev отдельно, test отдельно, prod отдельно, management отдельно. Но со временем появляются исключения.
Jenkins временно открывают SSH в соседний сегмент. Разработчикам дают доступ к тестовой базе. Интегратор просит правило «на пару дней». Для миграции открывают доступ к старому серверу. Потом проект заканчивается, люди меняются, а правила остаются.
Через год в политике МЭ уже есть широкие группы, временные правила без срока действия, устаревшие объекты и доступы вида «dev → почти всё». Формально сеть сегментирована. Практически — атакующий, попав в один сегмент, может двигаться намного дальше, чем должен.
Как должна выглядеть сегментация CI/CD?
Для CI/CD-сегмента можно задать несколько базовых принципов:
- Jenkins доступен только из административного сегмента.
- Jenkins может обращаться к Git и registry по HTTPS.
- Jenkins может деплоить только в test/stage-сегменты.
- Jenkins не имеет прямого SSH-доступа к production.
- Jenkins не имеет доступа к management-сети.
- Runner“ы не имеют произвольного egress в интернет.
- Базы данных доступны приложениям, а не CI/CD-серверам.
- Docker API и Kubernetes API доступны только с ограниченного набора адресов.
- Все временные доступы имеют срок действия и владельца.
Дальше эти принципы переводятся в матрицу доступа и сравниваются с реальными правилами на межсетевых экранах.
Именно на этом этапе обычно находятся самые опасные отклонения: Jenkins имеет SSH-доступ к большому количеству серверов, test-сегмент ходит в production-базы, management-интерфейсы доступны из dev, а старые временные правила никто не удалил.
Где помогает NSPM?
NSPM-система помогает проверить, соответствует ли реальная политика доступа ожидаемой модели.
Она может:
- построить модель сети с учётом МЭ, маршрутизаторов, зон, NAT, VRF и маршрутов;
- проверить, есть ли путь из CI/CD-сегмента к production DB, management-сети или SSH на серверах;
- найти избыточные правила с any, широкими группами объектов и устаревшими доступами;
- показать нарушение сегментации не на одном МЭ, а по всей цепочке устройств;
- зафиксировать изменение, если кто‑то открыл новый доступ вне согласованной матрицы.
Это важно, потому что в крупной сети доступ часто проходит через несколько firewall, NAT и маршрутизаторов. Ручной анализ такой цепочки быстро становится ненадёжным.
Матрица доступа как живой процесс
Матрица доступа не должна быть Excel-файлом, который обновляют перед аудитом. Она должна быть живой моделью.
Рабочий вариант — описывать доступы на уровне сегментов и сервисных групп:
- CI/CD → Git: HTTPS;
- CI/CD → Artifact Registry: HTTPS;
- CI/CD → Test servers: SSH/HTTPS;
- Admin segment → Jenkins: HTTPS;
- CI/CD → Production servers: запрещено;
- CI/CD → Management network: запрещено;
- User segment → CI/CD: запрещено;
- Test → Production DB: запрещено.
Для исключений нужен отдельный процесс: владелец, срок действия, обоснование, номер заявки и регулярный пересмотр.
Вывод
Кейс CGI Sverige не доказывает, что первичный доступ был получен из-за ошибки в правилах МЭ. Но он хорошо показывает важный принцип: CI/CD-инфраструктура должна быть жёстко сегментирована, потому что её компрометация может открыть путь к коду, секретам, тестовым средам и внутренним сервисам.
Сетевая безопасность не всегда предотвращает первичный взлом. Но она должна ограничивать последствия.
Матрица доступа задаёт, какие взаимодействия допустимы. NSPM помогает проверить, совпадает ли эта матрица с реальной конфигурацией сети.
Практическая сегментация — это не просто зоны на схеме. Это регулярное доказательство, что между сегментами разрешены только необходимые доступы. Чем меньше избыточных путей остаётся после компрометации одного узла, тем меньше радиус инцидента и тем выше шанс остановить атаку до того, как она станет инфраструктурной.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
