Запись удалена из основной базы данных. Как спроектировать удаление так, чтобы персональные данные не сохранялись в других копиях системы?
Нужно проектировать жизненный цикл данных, а не ограничиваться удалением строки из основной базы. Операция должна распространяться на реплики, кэши, поисковые индексы, журналы, экспортированные файлы и резервные копии либо обеспечивать контролируемое истечение срока их хранения.
Полностью гарантировать мгновенное физическое удаление из всех резервных копий обычно нельзя. Поэтому архитектура должна сочетать минимизацию данных, ограниченные сроки хранения, отслеживание копий и проверяемую процедуру удаления.
В централизованной базе удаление записи часто действительно означало удаление основного экземпляра данных. Современные системы распределяют данные между репликами, кэшами, аналитическими хранилищами и резервными копиями, поэтому один логический объект может существовать во множестве независимых представлений.
Подход к управлению жизненным циклом данных появился как ответ на две проблемы: рост числа копий и необходимость контролировать срок хранения чувствительной информации. Он рассматривает создание, использование, распространение, архивирование и уничтожение данных как единый процесс.
После удаления записи из основной базы данные могут остаться в реплике, кэше, полнотекстовом индексе, очереди событий, журнале аудита или выгрузке для аналитики. Если эти копии доступны дольше, чем предполагалось, компрометация любого из хранилищ раскрывает уже удалённые сведения.
Особенно сложны резервные копии. Они могут быть неизменяемыми, храниться на внешнем носителе или использоваться для восстановления всей системы. Попытка изменять каждую копию после каждого удаления может нарушить целостность резервирования и увеличить риск операционной ошибки.
Сначала определяется источник истины и каталог производных копий: реплики, кэши, индексы, очереди, аналитические наборы, логи и резервные копии. Для каждого класса данных задаются владелец, срок хранения, допустимый способ удаления и максимальная задержка распространения удаления.
Удаление в источнике истины должно порождать надёжное событие или задание на удаление производных представлений. Обработчики должны быть идемпотентными: повторная доставка задания не должна приводить к ошибке или восстановлению данных. Необработанные задания нужно отслеживать, повторять и направлять в очередь ручного разбора.
В кэшах задают ограниченный срок жизни и механизм явной инвалидации. Для поисковых индексов и аналитических хранилищ нужны отдельные процессы удаления или пересборки. Если журнал обязан сохраняться для аудита, в него не следует помещать исходные персональные данные без необходимости; лучше использовать минимальный набор атрибутов или устойчивый идентификатор.
Для резервных копий обычно выбирают один из вариантов: дождаться естественного истечения срока хранения, исключить данные из последующих копий и контролировать восстановление, либо применять криптографическое стирание — уничтожать ключ, которым зашифрован конкретный набор данных. Последний вариант работает только при корректной изоляции ключей и отсутствии доступных незашифрованных копий; уничтожение общего ключа может сделать недоступными и данные, которые удалять не требовалось.
Нужны доказательства выполнения: журнал запросов на удаление, состояние обработки по каждому хранилищу, контроль просроченных копий и периодическая проверка восстановления. Метрики должны показывать не только факт удаления в основной базе, но и задержку удаления в производных системах.
Компромисс заключается в выборе между скоростью удаления, стоимостью хранения и сложностью восстановления. Чем больше копий и чем дольше срок резервирования, тем труднее обещать немедленное физическое уничтожение. Поэтому безопаснее заранее минимизировать распространение чувствительных данных и отделять их от систем, которым они не нужны.
Сервис удаляет профиль пользователя из основной базы, но профиль также попадает в поисковый индекс, кэш API и ежедневные резервные копии. Команда рассматривала три варианта: удалять только исходную запись, запускать асинхронное удаление во всех системах или полностью пересобирать хранилища после каждого запроса.
Первый вариант прост, но оставляет доступные копии. Полная пересборка даёт сильный контроль, однако слишком дорога и непрактична для частых операций. Выбран асинхронный процесс: удаление в источнике порождает отслеживаемое задание для индекса и кэша, а резервные копии имеют короткий документированный срок хранения и исключаются из последующих копий.
Процесс дополнили мониторингом необработанных заданий и проверкой восстановления резервной копии. В результате удаление стало контролируемым: команда видит остаточные копии, знает максимальную задержку и может доказать прохождение операции по всем заявленным хранилищам.
Нет. Резервная копия остаётся хранилищем данных и должна иметь контролируемый срок хранения, доступ и процедуру удаления или криптографического стирания. Кроме того, восстановление старой копии может вернуть уже удалённые сведения, поэтому после восстановления требуется повторное применение удалений или другой механизм согласования состояния.
Очередь может потерять сообщение, обработчик может быть недоступен, а событие может быть доставлено повторно или вне ожидаемого порядка. Поэтому событие должно иметь устойчивое хранение, идентификатор операции, повторную обработку и контроль завершения по каждому потребителю.
Если производная система не подтверждает обработку в допустимый срок, это должно считаться инцидентом жизненного цикла данных, а не штатным успешным удалением. Идемпотентность позволяет безопасно повторять операцию без создания новых ошибок.
Уничтожение общего ключа действительно может сделать недоступным весь набор, но одновременно затронет записи, которые должны были сохраниться. Кроме того, если часть данных была скопирована без этого шифрования или ключ имел резервную копию, стирание не решит проблему.
Безопаснее применять управляемую изоляцию ключей и выбирать область ключа с учётом требований к удалению и восстановлению. Такой подход повышает стоимость управления ключами, зато позволяет ограничить последствия компрометации или удаления одним логическим набором данных.