Контейнеры ускоряют доставку приложений, но для систем с персональными данными скорость – не главный аргумент. Docker 1.8 и связанные инструменты дают удобную упаковку, однако модель изоляции пока слабее, чем у виртуальных машин: контейнеры на одном хосте делят общее ядро. Для оператора ПДн это означает простое правило – изоляцию нужно проектировать отдельно, а не полагаться на runtime «из коробки». Разберём, что делать на практике.

Где проходит граница доверия

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

Минимальный набор мер:

  • Никаких привилегированных контейнеров. Флаг --privileged для нагрузок с ПДн запрещаем. Сбрасываем лишние Linux capabilities (--cap-drop ALL и точечный возврат нужных).
  • Только непривилегированные процессы внутри. Образ не должен запускать приложение от root. User namespaces в Docker 1.8 уже доступны – включаем их там, где позволяет нагрузка.
  • Read-only файловая система для контейнера и отдельные именованные тома под изменяемые данные. Это сужает поверхность атаки и упрощает аудит.
  • Лимиты ресурсов через cgroups, чтобы один контейнер не уронил соседей и хост.

Образы берём из доверенного приватного реестра, а не из публичного хаба. Базовый слой фиксируем по дайджесту и регулярно пересобираем – патчи ядра и библиотек должны доезжать до продакшна. Сама идея стандартизованного формата контейнера описана в нашем разборе Open Container Initiative; стандарт упрощает контроль, но безопасность всё равно настраивается руками.

Сеть, секреты и хранение данных

Контейнеры по умолчанию слишком разговорчивы между собой. Сегментируем трафик: контур с ПДн – отдельная сеть без выхода в интернет, доступ к базе только от приложения, межсервисные соединения шифруем TLS. Порты наружу публикуем минимально и только через обратный прокси.

Секреты – пароли БД, ключи – не зашиваем в образ и не передаём через переменные окружения в открытом виде, потому что они утекают в логи и метаданные. Монтируем их в рантайме из защищённого хранилища.

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

Соответствие требованиям РФ

Технической изоляции недостаточно – есть регуляторный контур. С 1 сентября 2015 года действует требование о хранении и обработке персональных данных россиян на серверах в РФ; что именно изменилось, мы разбирали в заметке про вступление закона о локализации в силу. Для контейнерной платформы это значит: хосты, реестр образов, хранилища томов и резервные копии физически размещаются в российских ЦОД. «Облачный» характер контейнеров не отменяет географию данных – оператор обязан знать, где лежит каждый байт ПДн.

Дальше – стандартный набор оператора: модель угроз, аттестация информационной системы, разграничение доступа, шифрование и журналирование. Контейнеры здесь – лишь способ упаковки нагрузки, ответственность по 152-ФЗ остаётся на операторе.

Вывод

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