Облачная безопасность после первой волны контейнеров: не сетью единой
Почему периметровая модель безопасности не работает в контейнерной среде - и что нужно защищать вместо неё.
Прошло несколько лет с момента, когда контейнеры из инструмента для разработчиков превратились в стандарт развёртывания. Kubernetes стал де-факто платформой для оркестрации. Компании, которые прошли первую волну внедрения, теперь сталкиваются с вопросом, который на этапе пилота оставляли на потом: как это всё правильно защищать.
Ответ, к которому привыкли в традиционной инфраструктуре - настроить сетевой периметр, закрыть порты, поставить межсетевой экран - в контейнерной среде работает частично. Сеть важна, но недостаточна.
Почему сетевой периметр теряет смысл
В классической инфраструктуре у вас есть серверы с IP-адресами, и периметр строится вокруг них. В контейнерной среде сервисы эфемерны: контейнер запустился, отработал, остановился. IP-адреса динамические. Граница между "внутренним" и "внешним" размыта, потому что микросервисы активно общаются между собой.
Традиционный межсетевой экран не понимает контексти - кто именно запустил этот контейнер, из какого образа, с какими правами, в рамках какого пайплайна. А именно этот контекст важен для безопасности контейнерной среды.
Что нужно защищать вместо периметра
Первый слой - образы контейнеров. Атакующий, который попадает в цепочку поставки образов, получает доступ ко всем средам, где этот образ запускается. Нужен контроль: что за образы используются, откуда они берутся, кто и когда их проверял, есть ли известные уязвимости в зависимостях.
Второй слой - конфигурация оркестратора. Kubernetes имеет богатую модель прав доступа - RBAC. Но "богатую" не значит "безопасную по умолчанию". На многих установках права выдаются широко, потому что так проще на этапе разработки. В продуктиве это становится риском: сервис с избыточными правами может делать то, чего не должен.
Третий слой - секреты. Пароли, токены, ключи доступа к внешним системам - как они хранятся и как попадают в контейнер? Секреты в переменных среды, зашитые в образ или лежащие в открытом виде в манифестах - распространённая проблема.
Четвёртый слой - поведение во время выполнения. Что контейнер делает, пока работает? Какие системные вызовы использует, с какими внешними адресами соединяется, какие файлы читает? Аномальное поведение контейнера - часто первый признак компрометации.
Практический порядок действий
Для компании, которая уже использует контейнеры в продуктиве, я рекомендую начать с инвентаризации, а не с покупки нового инструмента.
Что за образы сейчас работают в продуктиве, и когда они последний раз проверялись на уязвимости? Какие сервисные аккаунты имеют права в кластере, и нужны ли им эти права? Как секреты попадают в контейнеры прямо сейчас? Есть ли журналирование системных событий на уровне узлов?
Ответы на эти вопросы часто обнаруживают проблемы без единого нового инструмента.
Вопросы для оценки зрелости
- Есть ли процесс сканирования образов на уязвимости до деплоя в продуктив?
- Используется ли принцип минимальных привилегий для сервисных аккаунтов Kubernetes?
- Где хранятся секреты и как они доставляются в контейнеры?
- Есть ли мониторинг аномального сетевого поведения контейнеров?
- Кто в компании отвечает за безопасность контейнерной платформы - конкретный человек, не "команда вообще"?
Контейнеры ускорили разработку и деплой. Теперь пришло время убедиться, что скорость не была достигнута за счёт безопасности, которую оставили "на потом".