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