БДУ ФСТЭК обновился: добавляем контейнерные угрозы в модели защиты клиентов

ФСТЭК очередной раз обновила БДУ - Банк данных угроз безопасности информации на bdu.fstec.ru. Обновление не грандиозное по объёму, но принципиально по направлению: регулятор добавил угрозы, которые явно адресуют контейнерные среды и облачные инфраструктуры. Для нас это прямой сигнал пройтись по моделям угроз клиентов, у которых эти технологии уже есть в составе защищаемых систем.

Проблема не новая, но теперь она стала задокументированной. Раньше при разработке модели угроз для системы, где часть компонентов работает в контейнерах или в облаке, приходилось либо натягивать на неё «классические» угрозы из БДУ с натяжкой, либо формулировать угрозы самостоятельно в свободной форме. Второй путь методически верный, но требует от разработчика серьёзного обоснования, почему именно эти угрозы актуальны. Теперь часть этой работы ФСТЭК сделала за нас.

Что конкретно появилось

Новые записи в БДУ охватывают несколько групп угроз, которых раньше либо не было, либо они были сформулированы слишком обобщённо:

• Угрозы оркестраторов контейнеров - некорректная конфигурация Kubernetes, избыточные привилегии сервисных аккаунтов, несанкционированный доступ к API-серверу кластера.
• Угрозы образам и реестрам - использование скомпрометированных базовых образов, отсутствие верификации образов при деплое, подмена образа в реестре.
• Угрозы изоляции контейнеров - побег из контейнера (container escape) через уязвимости runtime, совместное использование ядра хоста.
• Угрозы облачных сред - несанкционированный доступ через IAM с избыточными правами, утечка через метаданные облачных провайдеров, незащищённые объектные хранилища.

Формулировки в БДУ стандартно немного деревянные - это язык регулятора, тут ничего не поделаешь. Но содержательно угрозы описаны корректно и применимы к реальным инфраструктурам.

Кого это касается в первую очередь

Мы прошлись по активным проектам и выделили два типа клиентов, для которых обновление БДУ создаёт прямую задачу.

Первый тип - клиенты с ГИС или ИСПДн, у которых модель угроз разрабатывалась до появления контейнеров в инфраструктуре. Типичная история: аттестовали систему три года назад, потом разработчики тихо переехали на Docker, потом появился Kubernetes «для удобства деплоя». Модель угроз при этом не трогали - зачем, система же та же самая. Теперь есть конкретные угрозы из БДУ, которые в эту модель не включены, а инфраструктура им подвержена.

Второй тип - клиенты, которые используют ресурсы российских облачных провайдеров в составе защищаемой системы. Здесь ситуация была ещё хуже: угрозы, специфичные для IaaS/PaaS-модели, либо не включались в модель вовсе, либо добавлялись в общем виде без привязки к конкретным облачным механизмам.

Как мы актуализируем модели

Аудит существующих моделей угроз начинаем с инвентаризации: что реально работает в инфраструктуре клиента, и как это соотносится с тем, что описано в документе. Это всегда первый шаг, потому что расхождение между документом и реальностью - самое частое, что мы находим.

Дальше - сопоставление с обновлённым БДУ. Для каждой новой угрозы из релевантных групп оцениваем актуальность применительно к конкретной инфраструктуре. Методика ФСТЭК 2021 года здесь работает ожидаемо: нужно оценить возможности нарушителя и условия реализации угрозы, а не просто включить всё подряд «на всякий случай».

Несколько наблюдений из текущей работы:

• Угрозы оркестраторов актуальны почти всегда, когда Kubernetes присутствует в инфраструктуре, - даже если кластер «внутренний» и «закрытый». API-сервер доступен хотя бы с узлов кластера, и этого достаточно для формулировки угрозы.
• Угрозы образам требуют понимания реального пайплайна сборки и деплоя. Если клиент тянет образы с Docker Hub без верификации - это одна картина. Если есть внутренний реестр с проверкой - другая, но угрозы для самого реестра никуда не деваются.
• Угрозы облаков через метаданные - это специфика, которую легко пропустить. Instance Metadata Service (IMDS) у большинства облачных провайдеров доступен с любой виртуальной машины по локальному адресу и может содержать учётные данные. Без явных мер защиты (IMDSv2, ограничение доступа на уровне сети) угроза вполне реальная.

Что с мерами защиты

Актуализация модели угроз - только половина работы. После того как угрозы зафиксированы, нужно проверить, что меры защиты им соответствуют. Здесь часто выясняется, что мер для «классических» угроз достаточно, а для новых контейнерных и облачных - их нет или они есть только на бумаге.

Типичные пробелы, которые мы находим: нет политики верификации образов при деплое, RBAC в Kubernetes настроен по принципу «работает - не трогаем», логирование API-сервера не включено, IAM-роли в облаке накоплены с избыточными правами за годы эксплуатации.

Часть этих вещей закрывается настройками за разумное время. Часть требует более серьёзных изменений в архитектуре или процессах. Но сначала нужно хотя бы зафиксировать, что проблема есть - и обновлённый БДУ теперь даёт для этого нормальную нормативную основу.

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