CozySummit Virtual 2026 - опубликованы записи докладов

Соответствие GDPR на Kubernetes с Cozystack

Персональные данные в Cozystack остаются там, где вы их разместили. Платформа — это программное обеспечение с открытым исходным кодом на базе Kubernetes, KubeVirt и Talos Linux, работающее на вашем собственном оборудовании: никакого control plane в чужом облаке, никакого аккаунта поставщика, никакой регистрации в сервисе. Помимо этого она предоставляет меры, о которых спрашивает статья 32— шифрование при передаче и для резервных копий, централизованная идентификация, изоляция тенантов, обеспечиваемая сетевой политикой, журналирование аудита, резервное копирование и восстановление.

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

Одна формулировка, которую стоит держать в голове. Соответствие принадлежит организации, хранящей данные — почему она их хранит, на каком правовом основании, как долго. Платформа предоставляет меры и делает их демонстрируемыми; полезный ответ на вопрос «соответствует ли Cozystack GDPR» — это то, что изложено ниже, а не «да», которое разваливается при первом вопросе.

Резидентность данных: где физически находятся данные

Резидентность обычно первый вопрос, и на него легче всего ответить хорошо.

Cozystack устанавливается на ваше собственное оборудование, в выбранном вами объекте. Нет control plane в чужом облаке, нет поставщика, которому нужен постоянный доступ для работы платформы, и платформе не нужен канал телеметрии к поставщику для работы. Для главы V — передачи персональных данных в третьи страны — это устраняет самый крупный элемент из анализа.

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

Какие меры по статье 32 покрывает Cozystack

Шифрование персональных данных

Три уровня, и они ведут себя по-разному.

Секреты Kubernetes шифруются в etcd, когда API-сервер работает с --encryption-provider-config. Эта настройка задаётся конфигурацией машины Talos, предоставляемой при установке, поэтому проверьте её на своём собственном кластере.

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

Два следствия относятся к тому же решению, потому что они играют против статьи 32(1)(b) и (c), а не за неё. Парольная фраза — это единственный общий секрет без процедуры ротации, разделения знания или двойного контроля, поэтому управление ключами — это процесс, который вы строите вокруг него. И её нужно вводить вручную после каждого перезапуска контроллера LINSTOR — зашифрованные тома не поднимаются сами, что превращает незапланированный перезапуск в событие недоступности.

Резервные копии шифруются по умолчанию. Velero использует загрузчик kopia, поэтому данные резервных копий записываются в объектное хранилище под ключом репозитория, хранящимся в кластере.

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

Конфиденциальность и контроль доступа

Аутентификация может быть централизована в Keycloak через OIDC, что объединяет управление входом/выходом пользователей, многофакторную аутентификацию и политику паролей в одном месте, а не разбрасывает их по файлам kubeconfig. Это не значение по умолчанию — свежий кластер аутентифицируется с помощью учётных данных кластера, которые являются общей учётной записью и не подходят для чего-либо, содержащего персональные данные. Включите OIDC до того, как среда начнёт содержать реальные данные.

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

kubectl auth can-i --list -n tenant-a
kubectl auth can-i get secrets -n tenant-a

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

Разделение обработки

Тенанты изолированы друг от друга на сетевом уровне политиками Cilium, создаваемыми вместе с тенантом, и эта изоляция обеспечивается, а не просто декларируется. Вы можете проверить это за минуту — запустив под в одном тенанте и попытавшись достучаться до него из другого, с зондом внутри того же тенанта как положительным контролем: межтенантный зонд возвращает 000, зонд внутри того же тенанта — 200.

Читайте это как есть. Сетевое разделение — это не разделение обработки в том смысле, который имеет в виду сотрудник по защите данных. Control plane, etcd, LINSTOR и уровень идентификации — это общие службы, администраторы платформы видят все тенанты, а резервные копии, управляемые платформой, попадают в единый бакет cozy-backups в tenant-root, разделённый между тенантами по пути объекта, а не по учётным данным или ключу. Исходящий трафик тенанта в интернет также не ограничен по умолчанию, поэтому путь утечки данных остаётся открытым, пока вы не добавите SecurityGroup или список разрешённых адресов для исходящего трафика. Если вы обрабатываете персональные данные для нескольких контролёров, относитесь к тенанту как к сильной первичной границе и документируйте общие компоненты и администраторов, которые пересекают эту границу — именно об этом спросит сотрудник по защите данных.

Целостность систем обработки

Статья 32(1)(b) называет целостность рядом с конфиденциальностью, доступностью и устойчивостью, и это мера с самым большим пробелом. Неизменяемые образы узлов и компоненты платформы, зафиксированные по digest, усложняют незаметный дрейф конфигурации, а журнал аудита фиксирует, кто что изменил через API. Но с платформой не поставляется ни система обнаружения вторжений, ни мониторинг целостности файлов, ни механизм обнаружения изменений. Ничто не мешает вам запустить такой инструмент, и если ваша оценка риска требует его — это дополнение, которое вы делаете сами, а не мера, которую вы получаете в готовом виде.

Способность восстановить доступность после инцидента

Статья 32(1)(c) требует способности своевременно восстановить доступ к персональным данным. Velero поставляется с платформой для плановых резервных копий, снапшотов томов и состояния кластера, и восстановления стоит репетировать, а не принимать на веру — резервная копия, которую никто не восстанавливал, это надежда, а не мера.

Регулярное тестирование мер

Статья 32(1)(d) требует процесса тестирования и оценки эффективности. Страница CIS Benchmark показывает один такой тест, выполненный на живом кластере, с ошибками, отсортированными на реальные отклонения и артефакты архитектуры. Ничто не мешает вам запускать его по собственному графику; манифест опубликован там.

Право на удаление, и где оно становится неудобным

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

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

Журналы аудита создают вторую версию той же проблемы. Начните с того факта, что журнал аудита уже является хранилищем персональных данных: на уровне по умолчанию level: Metadata он фиксирует имена пользователей, группы и исходные IP-адреса, что является персональными данными о ваших администраторах независимо от содержания запросов. Он требует записи в ваших записях по статье 30, срока хранения и собственного правила доступа — срок хранения по умолчанию на рассматриваемом кластере составляет тридцать дней.

Ловушка находится на уровень выше. Повышение политики до RequestResponse для удовлетворения какого-то другого стандарта записывает тела запросов — значения секретов и любые персональные данные, которые ваши пользователи разместили в аннотациях — в тот же файл. Разделите политику по ресурсам: RequestResponse там, где знание того, что изменилось, — цель, Metadata для секретов и для всего, что содержит персональные данные.

Что остаётся на вашей стороне

Ни один инфраструктурный продукт не предоставляет следующее: правовое основание для обработки, записи о деятельности по обработке по статье 30, оценки воздействия на защиту данных там, где этого требует статья 35, уведомление надзорного органа о нарушении персональных данных в течение 72 часов по статье 33, ответы на запросы субъектов данных, назначение сотрудника по защите данных там, где этого требует статья 37, и договор по статье 28 с любым, кто обрабатывает персональные данные от вашего имени.

Платформа — это инструмент. Обязательства лежат на том, кто определяет цели и средства обработки.

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

Соответствует ли Cozystack GDPR?

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

Устраняет ли самостоятельный хостинг Cozystack проблемы передачи данных в третьи страны?

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

Шифруются ли персональные данные в покое по умолчанию?

Для хранилища, которое реально содержит персональные данные — томов за базами данных и виртуальными машинами — нет. Шифрование томов включается по желанию для каждого StorageClass и относится к проектированию, а не к последующему изменению. Резервные копии шифруются по умолчанию. Секреты Kubernetes шифруются в etcd, когда API-сервер работает с --encryption-provider-config, что задаётся конфигурацией машины Talos, а не самим Cozystack, поэтому проверьте это на своём собственном кластере — и секреты содержат учётные данные, а не обычно те персональные данные, которые описывают ваши записи об обработке.

Создаёт ли самостоятельный запуск Cozystack обработчика данных?

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

Примечания

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