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

26/02/26

Б-152

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

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

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

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

Наиболее ранним примером такой системы является механизм работы операционной системы 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, которые сделали технологию доступной для массового использования.

Контейнер в рамках операционной системы 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 соответственно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На практике отказ или отзыв согласия чаще всего ломает процессы там, где изначально неверно выбрано правовое основание обработки.

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

Последствия определяются основанием обработки.

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

Работа не останавливается, но охват данных и операций должен соответствовать этому основанию. Договор не становится пропуском на все случаи. Если целью является запись на прием, достаточно ФИО и контакта. Анкета со сбором «всего на свете» без явной нужды создает риски избыточности.

Отказ от согласия не всегда нейтрален для сервиса, но и санкцией он быть не может.

Пример из трудовых отношений: визитки для сотрудника печатает подрядчик. Передача данных третьему лицу в таких случаях опирается на согласие работника (ст. 88 ТК РФ; п. 1 ч. 1 ст. 6 и ч. 4 ст. 9 152‑ФЗ). Если работник от подписи отказался, работодатель вправе не изготавливать визитки. Сама работа от этого не страдает.

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

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

Отдельный запрет действует для биометрии: нельзя прекращать обслуживание или отказывать в нем из‑за нежелания сдавать биометрические данные и/или подписывать согласие, если соответствующая обязанность прямо не установлена федеральным законом (ч. 3 ст. 11 152‑ФЗ).

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

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

Обработка без законного основания или с нарушением требований к согласию влечет административную ответственность по ст. 13.11 КоАП РФ. Состав конкретизируется обстоятельствами: работа без письменного согласия, когда оно обязательно; несоблюдение принципов и условий обработки.

Отдельно рискуют те, кто забывает удалить данные после отзыва, не ограничивает доступ и не оформляет акт уничтожения. Это не только вопрос содержания, но и доказательств: при проверке спрашивают не про уничтожение, а про то, как, когда и чем подтверждено (приказ Роскомнадзора № 179 о содержании акта об уничтожении персональных данных).

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

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

Оказание помощи и ведение меддокументации — это законное основание; маркетинг, публикация фото «до/после», напоминания с рекламными элементами только с согласия. При отказе пациента от маркетинга лечение не прекращается.

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

Не путайте «согласие на обработку» с «согласием на распространение» (ст. 10.1 152‑ФЗ и приказ Роскомнадзора № 18): публикация профиля сотрудника или клиента в открытом доступе требует отдельного документа с условиями распространения.

Фотография в медкарте или в личном деле сама по себе не делает обработку биометрической. 

Биометрия — это использование физиологических характеристик для установления личности при соблюдении критериев закона (ст. 11 152‑ФЗ). Если внедряется идентификация по отпечатку пальца для прохода на объект, готовьте письменные согласия. Отказ предоставить биометрию не может блокировать доступ к основной услуге, если закон не обязывает иначе (ч. 3 ст. 11 152‑ФЗ).

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

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

3. Архитектура согласий. Разведите согласия по смыслу:

— на обработку персональных данных;
— на распространение в открытом доступе (ст. 10.1 152‑ФЗ, приказ № 18);
— на биометрию и спец категорию (письменная форма).

Добавьте понятные сроки действия: конкретная дата, событие или период, связанный с целью. Избегайте «бессрочно».

4. Механика отказа и отзыва. Опишите каналы, сроки, роли и артефакты. Внедрите журналы регистрации отзывов, шаблоны актов уничтожения (приказ № 179), чек‑листы для ИТ по блокированию доступа и удалению копий/бэкапов.

5. Внешние контрагенты. Для передачи по поручению заключайте договоры с конкретикой: цели, перечень данных, действия с данными, меры защиты, учет субподрядчиков. Проверьте локализацию первичной записи на территории РФ, если сбор идет через сайт или приложение (ч. 5 ст. 18 152‑ФЗ).

Форма заявки на собеседование требовала паспортные данные и СНИЛС. После аудита поля перенесли в этап оформления договора, а сбор на этапе отклика ограничили ФИО и контактами. Конверсия выросла, претензии исчезли. Основание: заявка по инициативе субъекта (п. 5 ч. 1 ст. 6 152‑ФЗ).

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

Отказ от согласия не останавливает все процессы. Обработка держится на правовом основании: где оно есть в законе или договоре, процесс продолжится; где единственным фундаментом было согласие, операции придется прекратить. 

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

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

Практический шаг для граждан — спрашивать про основания и условия заранее и помнить о праве в любой момент изменить решение (ч. 2 ст. 9 и ч. 5 ст. 21 152‑ФЗ).

Ввод оборотных штрафов за утечки откладывается минимум до 1 июля 2023 года

Практику отказов, отзывов согласий, разборы пограничных ситуаций (работники, клиенты, биометрия, онлайн-сервисы) и свежие позиции регуляторов мы регулярно публикуем в нашем Telegram-канале.

Материалы по теме