Контейнеризация для ИСПДн: от основ до соответствия 152-ФЗ

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

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

Цель этой статьи — дать полную картину: от технических основ работы контейнеров до конкретных требований регуляторов. Мы разберемся, почему эта технология получила такое распространение, какие риски она несет и как построить защищенную контейнерную инфраструктуру в соответствии с 152-ФЗ и требованиями ФСТЭК.

Часть 1. Техническая основа: как работают контейнеры

1.1. Исторические корни: от Plan 9 до Linux

Технология контейнеризации далеко не так нова, как кажется. Изначально она попросту не предполагалась в том виде, в котором используется сейчас. Основой контейнеров является паравиртуализация на основе механизма пространств имен — элементов разграничения общих ресурсов на уровне ядра.

Наиболее ранним примером такой системы является механизм работы операционной системы Plan 9, построенной в качестве продолжения UNIX. Так же, как и UNIX, Plan 9 унаследовал концепцию представления всех ресурсов в виде файлов. Отличительная особенность Plan 9 — различие отображений файловой системы для каждого процесса.

В Plan 9 впервые введён механизм пространств имен, реализующий отображение файловой системы в виде сложения файловых иерархий, предоставляемых различными ресурсами.

Для этого был введён протокол 9P, взаимодействие с которым обеспечивает прозрачное взаимодействие с гетерогенными файловыми иерархиями. Так, в рамках системы Plan 9 процесс не сможет отличить удалённый ресурс от локального, ровно как и не сможет различить границы разных иерархий.

Механизм пространств имён вводился в Linux с 2002 по 2006 год и дополнялся новыми видами изоляции. Сначала он был перенят ядром Linux для пространства имен монтирования. Этот механизм позволял ядру предоставлять процессам разные файловые иерархии, однако этого было недостаточно для разграничения остальных ресурсов. Так, например, все процессы по-прежнему могли индексировать все остальные процессы в силу общей виртуальной файловой системы proc.

С 2002 по 2006 год продолжалось расширение механизма пространства имён, в рамках которого также появилось разделение: групп процессов, групп SysV IPC, групп сетевых устройств и прочих. В совокупности с механизмом chroot, позволяющим переместить индексирование динамических библиотек и доступных утилит в иную файловую иерархию, появилась возможность организации контейнеров.

Cgroups (2007) стали вторым критически важным механизмом для управления ресурсами. Параллельно с развитием пространств имён, в ядро Linux были добавлены Cgroups (control groups) — механизм для ограничения и учета ресурсов. Если пространства имён отвечали за изоляцию на уровне того, что процесс может видеть, то cgroups отвечали за контроль использования ресурсов процессами.

Именно объединение пространств имён и cgroups в технологии LXC (Linux Containers) создало ту самую основу, на которой позже выросли Docker и другие системы контейнеризации.

В 2009 году началось внедрение файловых систем каскадно-объединённого монтирования — UnionFS и OverlayFS. В дальнейшем стала ясна необходимость в системе каскадно-объединённого монтирования для ядра Linux, нишу которой заняла сначала UnionFS, а затем OverlayFS, ставшая основой для многих систем контейнеризации.

Затем началась разработка LXC, и впоследствии Docker. Идея контейнеров получила своё развитие в виде системы LXC, разработанной компанией IBM, а затем и в виде систем паравиртуализации, таких как Docker, которые сделали технологию доступной для массового использования.

1.2. Механизм работы: изоляция на уровне ОС

Контейнер в рамках операционной системы Linux представляет собой изолированное древо процессов, запущенное в выделенном пространстве имён. Находясь в отдельном пространстве имен, процессы в древе не могут видеть и коммуницировать с процессами в соседних деревьях. Также предполагается отдельная файловая иерархия, созданная для контейнера, в рамках которой работают процессы.

Основу контейнера представляет файловая иерархия, которая является образом корневой файловой системы Linux. Все процессы в Linux взаимодействуют с учетом набора «стандартных» по большей части путей поиска. Так, например, процессы будут подключать динамические библиотеки из директорий /lib, /lib64, /usr/lib, /usr/lib64, /usr/libexec и иных директорий, указанных для механизма LD.

Механизм, обеспечивающий переход в иную файловую иерархию — chroot. Аналогично, консольные утилиты и другие программы, с которыми взаимодействуют сценарии оболочки и скрипты на высокоуровневых языках преимущественно будут находится в /bin, /usr/bin/, /usr/local/bin и иных указанных в переменной окружения PATH директориях. Механизм chroot позволяет процессу Linux перенести представление корневой папки относительно другой директории. Так, например, процесс может перенести корневое представление в папку /my_root, после чего обращения к /bin, /lib, /usr/lib, и др. будут перенаправляться в /my_root/bin, /my_root/lib, /my_root/usr/lib соответственно.

Однако, chroot не изолирует иерархию монтирования — процесс внутри chroot способен внести изменения в список монтирования для внешних процессов, что может нарушить их работу. Для изоляции точек монтирования применяется механизм пространства имён монтирования.

Следующим слоем изоляции контейнера является пространство имён процессов. При возможности монтировать файловую систему proc внутрь нового корневого представления, процесс может узнать состояние и взаимодействовать с другими процессами, находящимися в реальном корневом представлении, что также нарушает изоляцию.

Для разграничения групп процессов существует пространство имён процессов, в рамках которого процессы могут видеть только выделенную им часть древа.

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

Чаще всего оно используется в совокупности с эмулятором сетевого интерфейса (таким как например slirp4netns), который позволяет создать виртуальный сетевой интерфейс, назначить ему виртуальный мост, IP- и MAC-адрес. Таким образом контейнер становится отдельной сетевой сущностью.

cgroups обеспечивают контроль и ограничение ресурсов. Каждое пространство имён создаёт собственный слой изоляции, что в совокупности приближает работу процесса в контейнере к работе в изолированном экземпляре ядра. Однако без контроля ресурсов один «прожорливый» контейнер мог бы истощить ресурсы всей системы.

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

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

1.3. Сравнение с технологией виртуальных машин

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

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

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

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

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

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

1.4. Docker, OverlayFS и свойство неизменяемости контейнеров

Контейнеры, не имеющие состояния, именуются stateless. Контейнеры Docker основываются на технологии неизменяемых файловых систем. Все корневые файловые системы внутри контейнера представляют собой неизменяемый образ, который является одинаковым для всех контейнеров при запуске.

Очевидно, если программе доступно только чтение файловой системы, совместимость с работой многих программ будет нарушена. Для этого у каждого контейнера имеется несохраняемое пространство для записи, которое создается поверх корневого образа. Контейнеры могут записывать свои данные в это пространство, но как только контейнер будет уничтожен, Docker автоматически очистит это пространство.

Контейнеры сами по себе хранят состояние лишь временно, до момента уничтожения. С ростом распространенности контейнеров появилась необходимость в механизме, позволяющем сохранять состояние между перезапусками. Для этого в рамках технологии Docker появилась возможность монтирования внешних разделов, они же Docker Volume.

Контейнеры, использующие механизмы сохранения состояния, именуются stateful. Такими, например, являются контейнеры СУБД. Основной механизм сохранения состояния — внешние разделы, или Docker Volume. Volume позволяет создать персистентное хранилище, привязать его к определенному расположению и задать ограничения на размер. Все файлы, сохраняемые в Volume, остаются после перезапуска или создания нового контейнера.

Образ корневой файловой системы, в которой запускается контейнер, именуется Docker Image. Корневая файловая система Docker-контейнера формируется из наложения нескольких слоев файлов друг на друга. Наложение совершается за счет применения OverlayFS. Каждый накладываемый слой изменяет структуру файловой системы, изменяя, перезаписывая и удаляя файлы и директории.

Слои формируются из атомарных шагов построения контейнера, описанных в Dockerfile. Так, команда RUN внутри Dockerfile создаёт новый слой и записывает изменения, сделанные командой RUN. Аналогично работает команда COPY. Это сделано как для экономии пространства для ответвляющихся контейнеров, использующих общий снимок базовой ОС, так и для экономии ресурсов при повторной сборке образа контейнера (все шаги, предшествующие измененным при пересборке восполняются из кэша, а не запускаются по новой).

Часть 2. Бизнес-преимущества: почему ИТ-команды так рвутся к контейнеризации

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

2.1. Экономика контейнеризации: цифры и факты

Представьте классическую ситуацию: у компании есть сервер с 64 ГБ оперативной памяти. При использовании виртуальных машин типичная загрузка составляет 40-60%, потому что каждая ВМ требует резервирования ресурсов «про запас». В контейнерной инфраструктуре тот же сервер может работать с загрузкой 70-85% без риска для стабильности.

Реальная экономия выглядит так:

• Снижение затрат на оборудование на 30-40% за счет более плотного размещения

• Экономия на лицензиях ОС — вместо 20 лицензий Red Hat Enterprise Linux или Astra Linux Special Edition для ВМ достаточно одной для хостовой системы

• Сокращение затрат на электроэнергию и охлаждение на 50-60%

• Высвобождение времени администраторов — автоматизация рутинных задач экономит до 15 человеко-часов в неделю

Но экономика — это не только прямая экономия. Косвенные выгоды часто оказываются значительнее:

2.2. Скорость как конкурентное преимущество

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

Пример из практики: Одна из российских ритейл-компаний внедрила контейнеры для своего мобильного приложения. Результат: время развертывания новых функций сократилось с 3 недель до 2 дней. Когда конкуренты выпускали 4-5 крупных обновлений в год, они могли выпускать до 20 минорных улучшений, постоянно усиливая пользовательский опыт.

2.3. Гибкость и отказоустойчивость

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

Сезонность больше не проблема: Интернет-магазин во время распродажи может автоматически увеличить количество экземпляров каталога товаров в 5 раз, а после окончания акции так же автоматически уменьшить. Платить за ресурсы только когда они действительно нужны — это философия cloud native, которую реализуют контейнеры.

2.4. Единая среда от разработки до продакшена

Классическая проблема «на моей машине работает» стоит компаниям миллионов рублей ежегодно. Контейнеры решают ее радикально: один и тот же образ проходит все стадии от разработки через тестирование до промышленной эксплуатации.

Для бизнеса это означает:

• Сокращение количества инцидентов на 60-70%

• Ускорение расследования проблем — воспроизведение окружения занимает минуты

• Снижение рисков при обновлениях — откат к предыдущей версии делается одной командой

Часть 3. Темная сторона контейнеризации: риски, о которых не говорят на митапах

Когда технология становится популярной и модной, о ее проблемах начинают говорить меньше. Но для специалистов по ИБ именно понимание рисков — ключ к построению безопасной инфраструктуры.

3.1. Цепочка поставок: троянский конь в вашем образе

Публичные реестры контейнеров — это кладезь уязвимостей. Исследования показывают, что 51% образов из Docker Hub содержат критические уязвимости. Проблема усугубляется тем, что разработчики часто используют образы как черные ящики.

Реальный пример: В 2021 году в образе alpine:3.13 обнаружили уязвимость, позволяющую удаленное выполнение кода. Казалось бы: ну и что? Но этот образ используется как базовый для тысяч других образов. Одна уязвимость в базовом образе — и тысячи приложений оказываются под угрозой.

Как это работает на практике:

• Разработчик берет «официальный» образ node.js из Docker Hub

• В этом образе используется устаревшая версия библиотеки openssl

• Злоумышленник использует известную уязвимость в этой версии

• Результат — компрометация всего кластера

3.2. Нарушение изоляции: когда стены рушатся

Самая страшная угроза в контейнеризации — container breakout (побег из контейнера). Поскольку все контейнеры используют общее ядро ОС, уязвимость в ядре может позволить злоумышленнику вырваться из контейнера и получить контроль над всей системой.

Исторические примеры:

• CVE-2016-5195 (Dirty COW) — уязвимость в подсистеме памяти Linux, позволявшая выйти за пределы контейнера

• CVE-2019-5736 (runc) — уязвимость в container runtime, позволявшая выполнить код на хосте

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

3.3. Ошибки конфигурации: когда удобство побеждает безопасность

Docker и Kubernetes по умолчанию настроены на удобство, а не на безопасность. Типичные ошибки:

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

Privileged mode — флаг —privileged отключает все ограничения безопасности. Контейнер получает доступ ко всем устройствам хоста, может монтировать файловые системы и делать многое другое. В production-среде это должно быть запрещено категорически.

Монтирование docker.sock является распространенной практикой для управления контейнерами изнутри других контейнеров. По сути, это передача ключей от королевства любому, кто скомпрометирует такой контейнер.

3.4. Сетевая безопасность: невидимые мосты между контейнерами

В Kubernetes по умолчанию все поды могут общаться со всеми. Представьте: frontend, backend и база данных находятся в одной плоской сети. Скомпрометировав frontend, злоумышленник получает прямой доступ к базе данных.

Проблема усугубляется тем, что:

• Сетевые политики по умолчанию отключены

• Service mesh технологии сложны в настройке

• Трафик между подами часто не шифруется

Часть 4. Соответствие требованиям: как обуздать технологию в рамках регуляторики

Для ИСПДн контейнеризация — вопрос соответствия жестким требованиям законодательства. Давайте разберемся, как совместить гибкость контейнеров и строгость 152-ФЗ.

4.1. Новые угрозы — новые требования

ФСТЭК не остался в стороне от тренда контейнеризации. В 2025 году в Банк данных угроз были добавлены пять новых угроз, специфичных для контейнерных сред:

УБИ.223 — Несанкционированный доступ к контейнерам с расширенными привилегиями
Это прямое указание на риски privileged-контейнеров и запуска с правами root. Требует внедрения политик безопасности Pod и контроля security context.

УБИ.224 — Нарушение целостности (подмена) контейнеров
Угроза целостности образов. Требует внедрения цифровой подписи образов и контроля целостности на всех этапах жизненного цикла.

УБИ.225 — Нарушение изоляции контейнеров
Прямое указание на риски container breakout. Требует регулярного обновления ядра ОС, использования security profiles и мониторинга аномальной активности.

УБИ.226 — Внедрение вредоносного ПО в контейнеры
Угроза цепочки поставок. Требует сканирования образов на уязвимости, проверки SBOM (Software Bill of Materials) и использования доверенных реестров.

УБИ.227 — Модификация (подмена) образов контейнеров
Расширение угрозы целостности. Требует контроля доступа к реестрам образов и верификации источников.

4.2. Практическая реализация мер защиты

Теория теорией, но как это выглядит на практике? Рассмотрим конкретные меры для разных уровней защиты ИСПДн.

Для ИСПДн уровня 3-4 (базовые требования):

• Сканирование образов в CI/CD — интеграция Trivy или Grype в процесс сборки. Любой образ с критическими уязвимостями не должен попадать в продакшен.

• Pod Security Standards — использование встроенных политик Kubernetes:

• Сетевые политики — запрет всего трафика по умолчанию с постепенным открытием только необходимых направлений.

Для ИСПДн уровня 1-2 (повышенные требования):

• Цифровая подпись образов — использование Cosign или Notary для гарантии целостности и аутентичности образов.

• Runtime security — внедрение Falco или аналогичных инструментов для обнаружения аномального поведения в реальном времени.

• Мандатный контроль доступа — использование SELinux или AppArmor профилей для дополнительной изоляции.

• Шифрование томов — криптографическая защита данных как в состоянии покоя, так и при передаче.

4.3. Документирование и аудит

Любая система защиты бесполезна без чёткой и понятной документации и возможностей аудита. Для контейнерной инфраструктуры это особенно важно.

Обязательные документы:

• Модель угроз с учетом новых УБИ.223-227

• Регламент управления образами контейнеров

• Политика безопасности container runtime

• Процедуры реагирования на инциденты

Аудит и мониторинг:

• Централизованный сбор логов со всех компонентов

• Мониторинг изменений конфигураций

• Регулярные penetration tests контейнерной инфраструктуры
• Аудит на соответствие CIS Kubernetes Benchmark

Баланс между инновациями и безопасностью

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

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

Ключ к успеху в сбалансированном подходе, где:

• Разработчики понимают основы безопасности и следуют best practices

• Бизнес инвестирует не только в технологии, но и в экспертизу команды

• Специалисты по ИБ активно участвуют в проектировании архитектуры с самого начала

Контейнеризация для ИСПДн является сложным инструментом, который требует глубокого понимания. При грамотном использовании она позволяет не только соответствовать требованиям 152-ФЗ, но и создавать более надежные и управляемые системы.

Технология продолжает развиваться, и мы видим появление новых инструментов безопасности: от confidential containers до advanced threat detection systems. Будущее за теми, кто сможет совместить гибкость контейнеров с надежностью традиционных подходов к безопасности.