Требования к безопасности сред контейнеризации

Технологии контейнеризации (Docker, podman, LXC) и оркестрации (Kubernetes как де-факто стандарт) уже давно стали фундаментом для целой философии разработки и эксплуатации ПО [1]. Этот фундамент создал новую, динамичную и сложную среду, где традиционные подходы к безопасности, ориентированные на защиту периметра и статичных систем, оказались малоэффективны.

Высокая скорость развертывания, эфемерная (временная) природа контейнеров и плотная взаимосвязь микросервисов кардинально меняют требования к безопасности, смещая фокус с защиты границ сети на защиту самой цепочки поставки ПО и внутренних взаимодействий. Параллельно с этим растет и рынок средств защиты информации в контейнерном исполнении, что становится новым вызовом как для Испытательных лабораторий, так и для Регуляторов.

Опираясь на данные изменения, ФСТЭК России утвердил на момент декабря 2025 года два ключевых документа, которые описывают требования по безопасности к средствам защиты информации в контейнерном исполнении (далее – СЗИ в контейнерном исполнении):

• Требования по безопасности информации к средствам контейнеризации, утвержденные приказом № 118 ФСТЭК России в 2022 году [2].
• Информационное сообщение ФСТЭК России от 13 января 2025 года «О повышении безопасности средств защиты информации, в состав которых разработчики включают средства контейнеризации или образы контейнеров» [3].

В рамках данной статьи мы подробнее рассмотрим Информационное сообщение и домены, которые оно освещает:

• Средство контейнеризации или Средство в контейнерном исполнении.
• Инвентаризация.
• Контроль целостности.
• Обеспечение совместимости.
• Минимизация привилегий.
• Управление доступом.

Для начала рассмотрим основные сущности (наш небольшой Глоссарий):

• Средство контейнеризации – это ваш рантайм, то, в чем вы запускаете ваши контейнеры, это и docker, и Kubernetes, и podman и другие.
• Средство в контейнерном исполнении – это то, что вы запускаете в средстве контейнеризации, и на что будет сделан основной упор в статье.

Понимание этих требований поможет более качественно и осведомлено подойти к процессу проведения сертификационных испытаний.

Средство контейнеризации или средство в контейнерном исполнении

Информационное сообщение определяет несколько тематических доменов по безопасности средств в контейнерном исполнении, однако, перед реализацией требований нужно ответить на вопрос: «что вы создали?».

«1. В случае если средство контейнеризации не входит в состав средства в контейнерном исполнении и используется в качестве среды его функционирования, такое средство контейнеризации должно быть сертифицировано на соответствие Требованиям к средствам контейнеризации, утвержденным приказом ФСТЭК России от 4 июля 2022 г. N 118.»

Как и любая история эта начинается с вас, вашего средства и Требований.

Ссылаясь на Глоссарий ранее, Средство контейнеризации – это среда или платформа, в которой будет производиться запуск контейнеров – вашего ПО. Тут достаточно просто – его нужно сертифицировать на соответствие Требованиям к средствам контейнеризации.

Средство в контейнерном исполнении – это все то, что будет запускать в упомянутых средах, поэтому его не требуется дорабатывать до соответствия Требованиям Приказа № 118.

Если вы разрабатываете Средство контейнеризации и хотите его сертифицировать, то вам необходимо соответствовать требованиям двух документов.

В случае разработки Средства в контейнерном исполнении, которое, например, является также межсетевым экраном типа «Г», вы также должны учитывать при сертификации «Требования к межсетевым экранам» и требования Информационного сообщения.

Инвентаризация

«2. Разработчик средства должен провести инвентаризацию образов контейнеров, входящих в средство, а также ПО из состава контейнеров. Перечень образов должен быть приведен в проектной документации на средство, оформленный в табличной форме и в машиночитаемом формате в соответствии с приложениями к настоящему порядку, при предоставлении в ФСТЭК России заявки на сертификацию <...>»

Для соответствия требованиям данного домена необходимо сгенерировать перечень программных компонентов (далее — ППК, SBoM) образов ваших контейнеров в формате CycloneDX 1.6 [4]. Для генерации можно использовать open-source инструменты, например, Trivy [5] или Syft [6].

После генерации ППК стоит взглянуть на его содержание, поскольку есть немалая вероятность, что там есть какой-то «мусор» (dev-пакеты, инструменты тестирования и многое другое), о котором вы могли и не догадываться, если не применяли подобной практики ранее.

Следующий возможный шаг – это минимизация состава образа с применением технологии тонких образов: distroless контейнеры [7], образы FROM scratch [8], применение многоэтапных сборок [9] и т.п. Эти практики могут облегчить последующие работы по проведению статического и динамического анализов.

Возвращаясь к результатам генерации ППК, по требованиям Информационного сообщения каждый компонент ППК нужно обогатить дополнительными полями. Эти поля связаны с соотнесением каждого компонента с поверхностью атаки – GOST:attack_surface – и функцией безопасности – GOST:security_function.

В итоге вы должны получить следующие представление о вашем СЗИ в контейнерном исполнении в едином ППК:

• Отнесение к поверхности атаки (далее – ПА) и к реализации функции безопасности (далее – ФБ) происходит на уровне каждого образа и на уровне каждого компонента/пакета, входящего в состав данного образа.
• Помимо полей, связанных с ПА и ФБ, есть поле с отнесением пакета к сертифицированному базовому дистрибутиву ОС – GOST:provided_by. Это поле должно содержать название сертифицированной ОС, из состава которой заимствован компонент, при условии, что Разработчик ОС обеспечивает поддержку безопасности этого компонента, то есть проводит испытания в соответствии с Методикой ВУ и НДВ.

После выполнения ручной разметки необходимо провести формальную верификацию, что файл соответствует требованиям.

Обогащение и формальную верификацию ППК можно выполнить с помощью инструментов, которые предоставил Центр исследования безопасности системного ПО ФСТЭК России на базе ИСП РАН [10].

Компоненты, которые были отнесены к ПА, к ФБ и не взяты из сертифицированного базового дистрибутива ОС, должны быть подвержены тестированию согласно Методике ВУ и НДВ в зависимости от уровня доверия, а полученные артефакты: ППК в машиночитаемом и табличном видах сохраняются в Проектной документации.

Контроль целостности

«3. В средстве должна обеспечиваться целостность образов контейнеров и исполняемых файлов, содержащихся в контейнерах средства. При этом как минимум средство должно обеспечить контроль целостности образов контейнеров и исполняемых файлов, содержащихся в контейнерах средства, при установке или по требованию (периодически в ходе эксплуатации средства).

Контроль целостности образов контейнеров и исполняемых файлов, осуществляется средством самостоятельно, с использованием средства контейнеризации или сертифицированного средства контроля целостности. Методика проверки контроля целостности должна быть приведена в эксплуатационной документации средства.»

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

Как минимум должен быть выбран один из трех вариантов контроля целостности как ОБРАЗОВ КОНТЕЙНЕРОВ, так и ИСПОЛНЯЕМЫХ ФАЙЛОВ внутри этих образов:

• Первый вариант: самостоятельная реализации. Вы реализуете механизм контроля целостности как часть функциональных возможностей вашего СЗИ.
• Второй вариант: использование механизма контроля целостности у сертифицированных средств контейнеризации. Список СЗИ, которые соответствуют требованиям контенейризации можно увидеть в Реестре ФСТЭК России [11], как раз там можно и подобрать себе подходящую среду функционирования хотя бы исходя из соответствия определенным требованиям.
• И третий вариант: использование средства контроля целостности из состава сертифицированной ОС, которая является средой функционирования вашего СЗИ.

Выбрав один из этих вариантов нужно описать алгоритм контроля целостности в Эксплуатационной документации, это возможно сделать либо ПРИ УСТАНОВКЕ, либо ПО ТРЕБОВАНИЮ, которое вы в праве задать сами.

Обеспечение совместимости

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

Согласно данным требованиям вы должны обеспечить совместимость того, что выполняется в контейнере со средами функционирования, которые вы указали в Эксплуатационной документации.

Глобально все сводится к построению образа:

• Вы можете строить его на основе базового образа сертифицированной ОС.
• Альтернативно вы можете пойти в сторону использования тонких образов, что может быть своим испытанием.
• Также можно как упоминалось ранее «брать» компоненты из базового дистрибутива сертифицированных ОС, которые уже подвергались сертификационным испытаниям.

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

Минимизация привилегий

«5. Средство в контейнерном исполнении должно обеспечивать запуск контейнеров с полномочиями, минимально необходимыми для функционирования средства на уровне процессов хостовой операционной системы. Избыточные полномочия компонентов, выявленные при проведении сертификации средства должны быть устранены.»

Все начинается с вашего средства и выявления избыточных привилегий в нем (Linux Capabilities).

Выявить избыточные привилегии можно статическими методами, например, на этапе написания Dockerfile, манифестов Kubernetes с помощью доступных инструментов, например, KICS [12], checkov [13], которые подсветят основные проблемы безопасности и несоответствия best practice, и также проприетарных – Luntry [14], который позволяет взглянуть на полный жизненный цикл контейнеров и Kubernetes решений.

Также можно динамическими методами на уровне процессов на уровне хостовой ОС посмотреть битмапы привилегий CapPrm, CapBnd в /proc//status.

Однако если вам требуются определенные привилегии, то причины их наличия необходимо будет описать в Проектной документации.

Управление доступом

«6. Средство контейнеризации с функцией централизованного управления контейнерами (далее — оркестратор) должно обеспечивать управление доступом между компонентами средства (контейнерами, микросервисами, иными ресурсами, характерными для выбранного типа оркестратора), компонентами среды функционирования, внешними по отношению к средству компонентами в соответствии с заданными разработчиком средства правилами.

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

Правила доступа, содержащие список действий, разрешенных при взаимодействии компонентов средства между собой и компонентами среды функционирования, должны быть описаны в документации средства.»

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

• Первое направление: между компонентами СЗИ. Если вы разворачиваетесь в средстве контейнеризации, то вы, например, должны обеспечить запуск контейнеров в rootless режиме, если это возможно, применять настройки RBAC, обеспечить сегментацию сети и применять политики Policy Engine (Kyverno [15], OPA Gatekeeper [16]).
• Второе направление: между компонентами СЗИ и компонентами среды функционирования. Вам необходимо управлять и контролировать, то как СЗИ взаимодействует с хостом. Достичь этого помогут seccomp-профили, AppArmor-профили [17], наличие разграничения по namespace, ограничения по ресурсам memory и CPU [18], read-onlyFS.
• Третье направление: между компонентами СЗИ и внешними средствами. Здесь вы настраиваете Network Policy, securityContext [17], ingress-egress gateway.

Автор:
Слепых Андрей Александрович, ведущий инженер

Примечания

[1] https://devopsrussia.ru/
[2] https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/trebovaniya-po-bezopasnosti-informatsii-utverzhdeny-prikazom-fstek-rossii-ot-4-iyulya-2022-g-n-118
[3] https://fstec.ru/dokumenty/vse-dokumenty/informatsionnye-i-analiticheskie-materialy/informatsionnoe-soobshchenie-fstek-rossii-ot-13-yanvarya-2025-g-n-240-24-38
[4] https://cyclonedx.org/docs/1.6/json/
[5] https://github.com/aquasecurity/trivy
[6] https://github.com/anchore/syft
[7] https://docs.docker.com/dhi/core-concepts/distroless/
[8] https://docs.docker.com/build/building/base-images/#create-a-minimal-base-image-using-scratch
[9] https://docs.docker.com/build/building/multi-stage/
[10] https://gitlab.community.ispras.ru/sdl-tools/sbom-checker
[11] https://reestr.fstec.ru/reg3
[12] https://github.com/Checkmarx/kics/
[13] https://github.com/bridgecrewio/checkov
[14] https://luntry.ru/
[15] https://kyverno.io/
[16] https://github.com/open-policy-agent/gatekeeper
[17] https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
[18] https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

Ключевые слова