Требуется удалить персональные данные пользователя из append-only хранилища, не переписывая весь исторический поток. Какой архитектурный механизм может обеспечить такое удаление?
Для этого применяют криптографическое стирание: персональные данные хранятся зашифрованными, а ключ шифрования выделяется для конкретного пользователя или ограниченного набора данных. При запросе на удаление уничтожают этот ключ, после чего зашифрованные значения становятся практически невосстановимыми без переписывания append-only потока.
Это не отменяет необходимости удалить персональные данные из производных витрин, индексов, кэшей и резервных копий, если этого требуют политика или законодательство. Механизм работает только при корректной изоляции ключей и отсутствии незашифрованных копий.
Append-only-хранилища появились как способ сохранять неизменяемую историю событий, обеспечивать аудит и упрощать повторную обработку данных. Их сильная сторона — добавление новых записей вместо изменения старых, но это создаёт конфликт с требованиями на удаление персональных данных.
Физическое удаление из большого исторического набора обычно требует переписывания файлов, сегментов или партиций. Криптографическое стирание возникло как способ отделить неизменяемость самих данных от управляемости доступа к ним: данные остаются физически записанными, но уничтожение ключа лишает их практической ценности.
Событие в append-only потоке может содержать имя, адрес или другой идентификатор пользователя и после публикации попасть в несколько систем. Простая запись нового события об удалении не стирает старое значение: исторические потребители всё ещё могут его прочитать.
Если удалить только запись из основной витрины, персональные данные могут остаться в сыром слое, промежуточных файлах, поисковом индексе, кэше, резервной копии или обучающем наборе. Неверное решение создаёт ложное ощущение удаления и может нарушить требования к срокам хранения и обработке запросов субъектов данных.
Персональные поля шифруют до записи в append-only слой. Для каждого пользователя либо группы данных используют отдельный ключ данных, а сами ключи хранят в защищённом KMS или другом сервисе управления ключами. Доступ к ключу контролируется отдельно от доступа к хранилищу.
При удалении пользователя система:
После уничтожения ключа ciphertext может физически оставаться в потоке, но расшифровать его при надёжном шифровании и недоступности всех копий ключа практически невозможно. При этом не следует считать сам факт наличия ciphertext универсальным доказательством юридического удаления: применимость подхода зависит от требований конкретной юрисдикции, политики организации и возможности доказать необратимость операции.
Гранулярность ключа — главный компромисс. Ключ на весь поток проще обслуживать, но его уничтожение сделает недоступными данные всех пользователей. Индивидуальный ключ обеспечивает точное удаление, однако увеличивает число ключей, операций ротации, метаданных и требований к восстановлению.
Нужно учитывать утечки через открытые поля. Идентификатор пользователя, производные признаки, агрегаты или текстовые логи могут позволить восстановить личность даже после уничтожения зашифрованного поля. Поэтому персональные данные следует минимизировать, отделять от событий, контролировать состав производных наборов и применять политику удаления к каждому слою.
Ключи в резервных копиях требуют отдельного решения. Если старый ключ сохраняется в бэкапе, криптографическое стирание не завершено; если ключ удалён, нужно проверить, что восстановление системы не создаст его заново из другой копии. Для данных, которые должны быть реально удалены из носителей, может потребоваться физическая очистка или истечение установленного срока хранения резервной копии.
Платформа аналитики хранит события покупок в неизменяемом объектном хранилище. В событиях есть идентификатор клиента и зашифрованные контактные данные; из потока строятся витрины заказов и сегментов. Поступил запрос на удаление клиента, а ежедневная полная перезапись многолетнего архива слишком дорога.
Рассматривались три варианта. Простое событие удаления дёшево и сохраняет историю, но не удаляет уже записанные персональные значения. Полная перепись всех слоёв даёт более буквальное удаление, но требует больших вычислительных затрат и сложной координации. Шифрование каждого персонального набора отдельным ключом позволяет быстро сделать значения недоступными, но требует надёжного KMS, учёта всех копий и очистки производных данных.
Выбрали комбинацию: персональные поля шифруются ключом клиента, ключ уничтожается по подтверждённому запросу, а пайплайны удаления находят и очищают записи клиента в оперативных витринах, индексах и кэшах. Неидентифицирующие агрегаты оставляют только после проверки, что по ним нельзя восстановить сведения о конкретном человеке.
Результат — удаление из основного архива выполняется без переписывания всего потока, а производные системы получают отдельный контролируемый процесс очистки. Основной риск перенесли из дорогостоящей массовой перезаписи в управление ключами, инвентаризацию копий и доказуемый аудит удаления.
1. Достаточно ли уничтожить ключ, если персональные данные уже попали в производную витрину?
Нет. Криптографическое стирание действует только на данные, защищённые уничтоженным ключом. Если витрина содержит открытое имя, нормализованный адрес или иной производный персональный атрибут, его нужно удалить или обезличить отдельным процессом. Поэтому архитектура должна поддерживать lineage — связь производных наборов с исходными данными и областью удаления.
2. Можно ли использовать один ключ для всех пользователей, чтобы упростить систему?
Технически можно, но это ухудшает точность удаления. Уничтожение общего ключа сделает недоступным весь набор, а сохранение его ради остальных пользователей оставит данные удаляемого пользователя доступными. Для выборочного удаления нужен ключевой контур с подходящей гранулярностью, например отдельный ключ на пользователя, тенанта или небольшой изолированный домен.
3. Чем криптографическое стирание отличается от записи tombstone-события?
Tombstone сообщает потребителям, что объект больше не следует считать действительным, и помогает остановить его использование в новых вычислениях. Он сам по себе не уничтожает старую запись в append-only хранилище и не удаляет её из уже построенных наборов. Надёжное удаление обычно требует сочетания tombstone для распространения намерения удаления, криптографического стирания или физической очистки исходных данных и проверки всех производных копий.