Удаление конфиденциальных данных

Бывает так, что встречаешь описание интересного подхода или алгоритма, а потом про него забываешь, так как теория не была подкреплена практикой или прошло очень много времени. И вот когда наступает момент, где можно блеснуть своими знаниями, приходится тратить время, чтобы вспомнить детали. В очередной раз, когда я поймал себя на подобной мысли, я решил, что было бы неплохо делиться подобными находками. ;-) #tip

Сегодня расскажу об алгоритме удаления конфиденциальных данных.

Контекст

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

Так или иначе, удаление может стать непростой задачей, особенно если система заранее не была рассчитана на подобные операции. Сложность или невозможность удаления может быть вызвана следующими причинами:

• Удаление запрещено на уровне бизнес-логики. Например, в системе есть журнал событий, который является отражением действий пользователя. При удалении учетной записи пользователя мы должны удалить его персональную информацию, если она содержалась в событиях, но не можем удалить сами события, поскольку это запрещено юридически.

• Архитектурные ограничения. Чаще всего являются прямым следствием бизнес-требований. Например, разработчики решили, что для реализации большей части требований к системе идеально подходит шаблон Event Sourcing.

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

• Сложность физического удаления. Для многих баз данных операции UPDATE и DELETE проблематичны. Например, для MariaDB удаление - это настолько нетривиальная задача, что ее разработчики подготовили целую инструкцию - “Big DELETEs”. Аналогичные проблемы имеются и у MySQL. В PostgreSQL частые удаления могут быть одной из причин раздувания базы. У Cassandra удаление может приводить к большой загрузке узлов во время компоновки. В общем, большинство баз спроектировано, чтобы хранить данные, а не удалять. :)

Проблема

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

Решение

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

Плюсы

Данные “удаляются” моментально, сразу, как только будет удален ключ шифрования. В этом смысле подход напоминает логическое удаление и, кстати, может использоваться с ним совместно.

Минусы

Данные продолжают занимать место на диске. Возникает необходимость в шифровании/дешифровании при каждой записи/чтении.

---

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