Соответствие PCI DSS на Kubernetes с Cozystack

Cozystack предоставляет большинство технических мер контроля, на которые опирается оценка PCI DSS 4.0.1, и несколько из них активны на свежей установке. Это облачная платформа с открытым исходным кодом на базе Kubernetes, KubeVirt и Talos Linux, работающая на вашем собственном bare metal. Сетевая изоляция тенантов, ограничения привилегий для рабочих нагрузок, автоматический TLS для опубликованных сервисов и зашифрованные резервные копии не требуют никакой настройки.

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

Пройдёт ли это наш аудит? Этот вопрос возникает на первой встрече каждый раз, когда среда обработки данных держателей карт (CDE) переходит на новую платформу. Никакая платформа не проходит аудит. Квалифицированный оценщик безопасности (QSA) сертифицирует определённую среду — ваши системы, ваши процессы, ваши доказательства. Что может сделать платформа — это предоставить технические меры контроля, на которые опирается оценка, и сделать их легко демонстрируемыми.

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

Какие требования PCI DSS 4.0.1 покрывает Cozystack

Таблица ниже сопоставляет все двенадцать требований PCI DSS v4.0.1 с тем, что предоставляет Cozystack. «По умолчанию» означает, что мера контроля активна на свежей установке. «Встроено, выключено по умолчанию» означает, что платформа поставляет её, а вы включаете — это настройка, а не разработка.

Что вы включаете для среды держателей карт

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

Перенос области PCI DSS с VMware

Команды, заменяющие VMware vSphere, обычно уже имеют среду обработки данных держателей карт, определённую в границах кластеров, VLAN и ролей vCenter, и первый вопрос — как будет выглядеть эквивалентная граница после переноса. Виртуальные машины продолжают работать — KubeVirt запускает их как рабочие нагрузки Kubernetes, — а границей области становится тенант. Сегментация переходит от VLAN и правил распределённого межсетевого экрана к сетевым политикам Cilium, создаваемым вместе с тенантом; роли и разрешения vCenter переходят в группы Keycloak, отображаемые на RBAC, ограниченный тенантом. Требования ниже — те же самые, по которым ваш оценщик проверял vSphere.

Требование 1: сегментация среды обработки данных держателей карт

Сегментация — это то, с чего обычно начинается большинство оценок платформы, потому что она задаёт размер области вашего аудита. Размещение CDE в собственном тенанте даёт защищаемую границу сегментации, но сама по себе не выводит остальную часть кластера из области: control plane, Cilium, LINSTOR, Keycloak и узлы — это общие службы, поддерживающие CDE, и оценщики обычно считают их относящимися к области. Сегментация ограничивает, какие рабочие нагрузки находятся в области, а не какие компоненты платформы.

В Cozystack тенант — это не просто соглашение об именовании. Его создание одновременно создаёт набор сетевых политик Cilium, и эти политики по умолчанию запрещают трафик от других тенантов. Ничего писать вручную, ничего запоминать.

Вы можете проверить это сами за минуту. Запустите под в одном тенанте, затем попробуйте достучаться до него из другого:

kubectl -n tenant-a run target --image=nginx:alpine --restart=Never
kubectl -n tenant-a wait --for=condition=Ready pod/target --timeout=60s
TARGET_IP=$(kubectl -n tenant-a get pod target -o jsonpath='{.status.podIP}')

# положительный контроль: доступен внутри того же тенанта
kubectl -n tenant-a run probe --rm -i --restart=Never --image=curlimages/curl:8.11.1 -- \
  curl -s -m 5 -o /dev/null -w '%{http_code}\n' "http://${TARGET_IP}/"

# сам тест: заблокирован из другого тенанта
kubectl -n tenant-b run probe --rm -i --restart=Never --image=curlimages/curl:8.11.1 -- \
  curl -s -m 5 -o /dev/null -w '%{http_code}\n' "http://${TARGET_IP}/"

Зонд возвращает 000. Запустите тот же зонд из tenant-a в качестве положительного контроля: он должен вернуть 200, что доказывает, что цель работает и 000 — результат политики, а не пода, который никогда не был готов.

Обратите внимание, что политики по умолчанию не делают. Исходящий трафик от тенанта в интернет не ограничен, тогда как требование 1.3.2 ожидает, что исходящий трафик из CDE ограничен только необходимым. Поэтому среда держателей карт нуждается в явных правилах исходящего трафика — SecurityGroup или CiliumNetworkPolicy со списком разрешённых адресов — сверх настроек тенанта по умолчанию.

Cozystack v1.6 добавляет API SecurityGroup, обращённый к тенанту, для команд, которым нужны более точные правила внутри собственного тенанта без обращения к администратору платформы.

Требование 2: безопасная конфигурация и отсутствие настроек по умолчанию от поставщика

Узлы Cozystack работают на Talos Linux — неизменяемой операционной системе без оболочки, без демона SSH и без менеджера пакетов. Конфигурация приходит через API и декларируется, а не набирается вручную. Целое семейство находок — устаревшие локальные учётные записи, отклонившаяся конфигурация, чья-то забытая отладочная правка — становится значительно сложнее произвести, потому что изменения проходят через декларативный API, а не через оболочку. Доступ на уровне узла всё же существует через API Talos, и он заслуживает того же обращения, что и любой другой административный интерфейс.

Cozystack — это контейнерная платформа, и специфическое для контейнеров требование здесь — что рабочие нагрузки не могут повышать привилегии. Допуск Pod Security обеспечивает baseline и только предупреждает на уровне restricted. Baseline отклоняет очевидные обходы — привилегированные контейнеры, пространства имён хоста, hostPath — но всё ещё разрешает запуск от имени root и не требует профиля seccomp. Стандарты усиления защиты, которые скорее всего процитирует оценщик, ожидают restricted, поэтому пометьте пространства имён, содержащие среду держателей карт, соответствующим образом:

kubectl label namespace tenant-cde \
  pod-security.kubernetes.io/enforce=restricted --overwrite

На уровне по умолчанию baseline рабочая нагрузка, запрашивающая привилегии, отклоняется на входе:

Error from server (Forbidden): violates PodSecurity "baseline:latest":
host namespaces (hostNetwork=true, hostPID=true), privileged

Анонимный доступ к API отключён, а эндпоинт профилирования выключен.

Требование 3: шифрование хранимых данных — секреты да, тома не по умолчанию

Здесь важны два уровня, и они ведут себя по-разному.

Секреты Kubernetes шифруются в etcd, когда API-сервер работает с --encryption-provider-config. Этот флаг, как и --anonymous-auth=false, политика аудита и --profiling=false, задаётся конфигурацией машины Talos, предоставляемой при установке, а не самим Cozystack — поэтому проверьте это на своём собственном кластере, а не принимайте на веру. Стоит отметить и границы этой меры контроля: она защищает данные etcd на диске и в резервных копиях etcd, ничего не делает против принципала, способного прочитать Secret через API, и мало помогает, если ключ шифрования находится на том же узле control plane, что и etcd.

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

# локальный (нереплицированный)
parameters:
  linstor.csi.linbit.com/layerList: "luks storage"
  linstor.csi.linbit.com/encryption: "true"

# реплицированный — слой DRBD идёт первым
parameters:
  linstor.csi.linbit.com/layerList: "drbd luks storage"
  linstor.csi.linbit.com/encryption: "true"

Два операционных следствия нужно учесть. Парольную фразу нужно вводить вручную после каждого перезапуска контроллера LINSTOR (linstor encryption enter-passphrase); зашифрованные тома не поднимаются сами. И механизм — это единая общая парольная фраза без процедуры ротации, без разделения знания и без двойного контроля, поэтому требования 3.6 и 3.7 должны выполняться процессом управления ключами, который вы строите вокруг него.

Полная процедура — в Создании зашифрованного хранилища на LINSTOR. Решите этот вопрос до того, как среда будет построена: преобразование заполненного тома позже означает миграцию данных.

Резервные копии

Velero — это уровень резервного копирования платформы, использующий загрузчик kopia, поэтому данные резервных копий шифруются в объектном хранилище ключом репозитория, хранящимся в кластере. Это покрывает копии, но не отвечает на вопрос, где они находятся: резервные копии, управляемые платформой, попадают в общий бакет cozy-backups в tenant-root, разделённый между тенантами по пути объекта. Если резервируются данные держателей карт, согласуйте с вашим оценщиком, входит ли этот бакет в вашу область, и рассмотрите направление BackupClass на хранилище с собственным управлением ключами.

Для персональных данных, хранящихся уровнем идентификации, в v1.6 представлен шифрующий прокси перед базой данных Keycloak, на основе статического ключа или Vault Transit. Он выключен, пока вы не включите его.

Требование 4: шифрование данных при передаче с TLS

cert-manager является частью платформы, с настроенными эмитентами для Let’s Encrypt или вашего собственного удостоверяющего центра. Сертификаты запрашиваются и продлеваются автоматически, что устраняет самую распространённую причину находки о шифровании при передаче — просроченный сертификат, за которым никто не следил.

Начиная с v1.6, предоставленный оператором wildcard-сертификат распространяется на каждую точку завершения TLS тенанта, поэтому тенанты получают валидный TLS в готовом виде, а не настраивают его сами.

Требование 4 касается открытых публичных сетей, но оценщики также спрашивают про внутренний путь, и два потока не зашифрованы, пока вы не примете меры: трафик под-под внутри кластера, для которого Cilium предлагает прозрачное шифрование WireGuard или IPsec, выключенное по умолчанию, и репликация DRBD между узлами хранения. Если сеть, несущая тот или другой поток, не полностью под вашим контролем, включите прозрачное шифрование и разместите репликацию в собственной изолированной сети.

Требования 7 и 8: RBAC тенанта и единый вход Keycloak

Аутентификация может быть централизована в Keycloak, и это не значение по умолчанию. Свежий кластер аутентифицируется статическими учётными данными кластера — общей учётной записью, что не допускается требованием 8.2.2. Включение OIDC — это шаг на этапе установки, и он относится к моменту до того, как среда начнёт содержать данные держателей карт. Многофакторная аутентификация, политика паролей и тайм-аут неактивной сессии — тогда настройка Keycloak, а не работа разработки. После включения API-сервер принимает токены OIDC и читает членство в группах из токена, поэтому появление и уход пользователей обрабатывается в одном месте, а каталог, который вы уже используете, остаётся источником истины.

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

Квоты иерархические, поэтому суб-тенант не может превысить бюджет своего родителя — полезно, когда CDE должна быть ограничена в размере, а не только изолирована.

Требование 10: журналирование аудита Kubernetes и хранение журналов

API-сервер записывает журнал аудита в файл на узле control plane, регулируемый политикой, которую вы задаёте, и вращает его по возрасту. Централизованный сбор журналов и хранение метрик поставляются с платформой для рабочих нагрузок — но передача журнала аудита API в них не настроена по умолчанию, а требование 10.3.3 ожидает, что журналы аудита оперативно попадают на отдельный, централизованно управляемый сервер.

Ещё две вещи стоит проверить, а не принимать на веру. Содержание политики аудита. Политика уровня Metadata не даст детализации по событиям, которую ожидает требование 10.2.1 — но повышение всего до RequestResponse — неверная поправка, потому что тела запросов несут значения Secret и персональные данные, и журнал аудита становится ещё одним хранилищем данных, которые вы защищаете. Разделите его по ресурсам: RequestResponse для привязок ролей и конфигурации допуска, Metadata для секретов. И защита самой цепочки: требования 10.3.2–10.3.4 требуют, чтобы журнал был неизменяемым и наблюдался механизмом обнаружения изменений — ни то, ни другое платформа не предоставляет.

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

Синхронизация времени

Требование 10.6 легко упустить и дёшево удовлетворить. Talos синхронизирует время узла через machine.time, и значение по умолчанию — публичный пул NTP. Для среды держателей карт направьте каждый узел на один и тот же назначенный внутренний источник, который сам синхронизируется с признанным внешним эталоном, храните эту настройку под управлением конфигурации, чтобы никто не мог изменить её на живом узле, и убедитесь, что изменения этой настройки попадают в журнал аудита.

Требования 6 и 11: обновления и тестирование безопасности

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

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

Сертифицирован ли Cozystack по PCI DSS?

Нет — и никакая инфраструктурная платформа не сертифицирована. Сертификация PCI DSS применяется к среде обработки данных держателей карт, определяется организацией, которой она принадлежит, и подписывается квалифицированным оценщиком безопасности. Поставщик, рекламирующий «платформу, сертифицированную по PCI DSS», описывает то, чего не существует.

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

Эта страница носит информационный характер. Это не юридическая консультация, не оценка, не сертификация и не гарантия того, что какая-либо конфигурация удовлетворит квалифицированного оценщика безопасности. Утверждения описывают Cozystack v1.6, наблюдаемый на эталонном кластере; ваша установка может отличаться. Поддержка во время оценки — коммерческая договорённость с отдельными поставщиками, а не то, что предоставляет сам проект.

Часто задаваемые вопросы

Как Cozystack влияет на область аудита PCI DSS?

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

Шифрует ли Cozystack данные держателей карт в покое по умолчанию?

Для секретов Kubernetes — да. Для томов — нет: это поддерживаемая опция, которую вы включаете для каждого StorageClass, и решение относится к этапу проектирования.

Можем ли мы использовать собственный удостоверяющий центр и поставщика идентификации?

Да. cert-manager работает с внутренним удостоверяющим центром, а Keycloak федерируется с корпоративными каталогами и внешними поставщиками идентификации.

Может ли Cozystack работать на нашем собственном оборудовании для области PCI DSS?

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

Получение помощи в оценке PCI DSS

Cozystack распространяется по лицензии Apache 2.0, и его исходный код публичен, поэтому ничего из вышеперечисленного не нужно принимать на веру. Если вы готовитесь к оценке и хотите, чтобы сопоставление мер контроля было проверено относительно вашей области, корпоративная поддержка доступна от нескольких поставщиков.