Про GDPR, практика (3): удаление данных, деперс, контент
Мы уже проговорили, чего надо в базовом минимуме, чтобы вообще цепочка регуляции вас, как оператора данных, заработала. А также чего надо сделать внутри, чтобы себе облегчить потенциальные разруливания ситуаций, и где удобно навернуть полиэтилена заранее, чтобы не проебаться в процессе.
Давайте про данные и про механизмы. Самый развесистый из них, который у всех на слуху — это удаление данных по GDPR. Право на забывание. Заодно, за него вроде как больше всего нагибают в 2026 году — очевидно, потому что на нем как раз удобно проверять, что все работает «как надо», затронуты практически все аспекты в регуляции.
Важная оговорка: я пишу про практику реализации.
Здесь нет «чисто юридических» штук, особенно для документов и полисей, внешних, внутренних. Ими все равно занимаются ваши юристы, и неплохо бы им знать, что делают.
Сейчас это уже не так сложно, особенно в той связи, что региональные регуляторы выпускали свои разьяснения, по различным аспектам законов, и практике реализации (и правоприменения).
Ссылки давать смысла нет, вам любая нейросетка найдет быстрее и актуальнее. Их надо читать, там полезное.
Право на удаление у нас Article 17 — Right to erasure («right to be forgotten»). Причем речь именно про удаление, дословно the controller shall have the obligation to erase personal data without undue delay.
Однако сразу первый вопрос, что у нас считается personal data. Потому что не вся data будет personal. В первую очередь мы (и регулятор) смотрим на данные, которые «точно personal» — это анкетные данные, контакты, логины-емейлы-пароли-адреса, документы, фотки напрямую ассоциированные с учетной записью.
Их прибиваем/деперсонализируем в первую очередь. Именно с этими данными и этим действием вы должны уложиться в 30 дней. Длинный хвост и косвенные данные можно чистить дольше, или вообще не чистить, сами протухнут, удалятся автоматически.
Не лайфхак, но весьма полезный ход: когда запрос на удаление получен и верифицирован (читать вот тут про хак с идентификацией), имеет смысл пользователю заблокировать взаимодействие с системой.
Оставить только минимально необходимый набор функций, где собственно будет написано: «чувак, у тебя на аккаунте удаление, это критическое действие с юридическими последствиями, больше ничего нельзя», и доступна только возможность жмакнуть «передумать» за заданное время, чтобы дать пользователю отказаться от этой херни.
Зачем «передумать». Для нас — ходить чистить из системы данные во-первых геморно, во-вторых там много нашего коммерческого интереса. Данные суть бизнесового смысла, терять их и ходить грубо чистить всякие места — достаточно неприятно. Статистика, маркетинг, аналитика, математика точно будут не в восторге.
Для пользователя — зачастую выясняется, что юзер либо тыкает запрос по приколу, либо как я раньше упоминал, просто хочет «начать с чистого листа», ему не надо забывать и блочить всё-всё, он собирается продолжать с нами жить. Это другая операция, он недопонял. Успеет понять и передумать.
Спрашивают по прошлой статье, а зачем блокировать создание нового акка. Для нас — на самом деле, чтобы избежать разночтений (случайных) и тупых провокаций (намеренных).
Если вы такие красивые пошли всё поудаляли, а потом у вас появляется аналогичный пользователь с той же почтой и телефоном (например) — возможны разного рода коллизии. Причем и вас, и в сторонних системах. Хорошо и правильно, когда используется только уникальный ID пользователя, и он однозначно поменяется. Вопрос в том, уверены ли вы в этом, в вашей системе и смежных с ними, на 100%.
Провокации также возможны. Они тупые, типа вот я запросил удаление, потом тут же зарегался снова, и пошел всем рассказывать что оператор свою задачу не выполнил. Учетка и анкета визуально те же. Значит, дальше возможны разруливания на тему «а что же там реально происходило». Например, в связи с contribution+UGC.
Вася накидал говна на форуме, запросил удаление, удаление прошло, зарегал новую учетку с теми же данными, продолжил сраться на форуме, когда ему снова сказали что «ты мудак» — пошел жаловаться регулятору, что его «неправильно забыли».
Оно вам надо? Оно вам не надо.
Для пользователя ограничение «ты не сможешь» тоже достаточно полезно.
Во-первых, прививает некоторую ответственность за собственные действия; типа, у тебя были системные штатные действия — ты ими не захотел воспользоваться — теперь иди, огребайся, потому что надсистемный GDPR и регуляция имеют неприятные последствия.
Во-вторых, GDPR-удаление часто запрашивают в случае конфликтов прав и владения; так мы исключаем ситуацию, когда кто-то злонамеренно может ебнуть аккаунт, потом перезарегаться, и использовать эту возможность для злоупотреблений и всякого шантажа.
Деперсонализация
В вашей системе данных много. Анкета обычно лежит в предсказуемом месте, или нескольких; а вот где там размазаны тонким слоем всякие косвенные данные — контент, логи, история, аналитика, коммерция — это еще надо посмотреть. Поэтому здесь даже не лайфхак, а просто правильная архитектура: всё, что вы можете привязать у себя не к естественным данным пользователя (почта, адреса, счета, итп), а к своему уникальному идентификатору аккаунта — должно быть привязано к нему, и только к нему.
В таком случае, значительная часть действий сводится к отвязке аккаунта от человека и от его данных. Аккаунт на этом этапе уже считаем всё, удаляемым, невосстановимым.
У меня кстати был внятный ответ регулятора о том, что сам по себе айдишник, даже «старый реальный», и даже текущий актуальный, сам по себе персональными данными не считается, если он деперсонализируется, и по нему нельзя сказать, что это за юзер и что за физик. В том числе, на вебе, в логах и где-то в других неподконтрольных нам местах.
Так что подход считаем нормальным. Если юзер когда-то кому-то писал, что «1234567 = Вася», с авторитетными скриншотами, то прямо сейчас 1234567 не значит уже ничего, и не наше дело, кому он там что когда писал.
Общаться с регулятором (дкомом) полезно и правильно, делайте так.
Первый шаг — хранилка identity и юзербаза. Там всё самое важное.
Из аккаунта и его анкетных storages вычищаем нещадно всё, что там есть. Можно переложить критичные части в отдельную структуру хранения, на время, ниже расскажу зачем это надо. Но из основных боевых систем вычищаем.
Хорошая практика, по опыту скажу, на операции создать новый аккаунт — пустой — заведомо сразу нерабочий, залоченный, с новым user ID, и этот новый ID куда-то себе тоже временно запомнить.
Потому что ряд систем крайне негативно относится именно к удалению данных, как физическая операция. Аналитика, big data, бухгалтерия, всякие файлопомойки.
Если у вас есть новый ID, вы оставшиеся данные пере-привязываете уже к нему, это update вместо delete. Аккаунт новый все равно заведомо нерабочий, а лишних данных на нем вовсе нет (никаких нет), он новый безымянный, пустой и сразу отключенный.
Таким образом, вы не огребаетесь с фрагментацией, побитой статистикой, провалами в цепочках операций, и что там еще вам может быть важно в этой связи.
Деперсонализация хороша тем, что это обычно операция быстрая, конкретная. Пользователь (и регулятор) хотел по закону увидеть что всё, «данных нет» — вуаля, доставлено, данных нет. Где они там есть, будете дальше разбираться, закон вам дает на это право и время. А если вы умный и читали первый текст, то еще и проговорили/прописали заранее, что ковыряться можете до 90 дней. Главное что основное действие пошло делаться, этот факт проверяется, ничего нет и ничего не работает.
Удалили, но пока не совсем
Анкетные данные за эти 90 дней вам еще могут понадобиться. Например, вам ащета нужно вычистить руками все неструктурированные данные — например, email-переписку. Как вы ее будете чистить, если сам email только что удалили? То же самое касается бух.счетов, идентификаторов в сторонних системах, телефонов, различной органики.
Потом, в конце, это всё тоже придется поудалять и забыть. Но пока что вам это всё понадобится.
Мы делали как: отдельная подсистема, которая отвечает за GDPR, фиксирует там заявку и ее суть (удаление)
- туда мы кладем копию всех анкетных, которые нам могут понадобиться в процессе. Это именно копия, она умрёт, и у нее цель только одна — обеспечить поиск и удаление
- качественно удаляем/деперсонализируем аккаунт, оригинал данных удаляем, в боевой системе их больше нет
- туда же к заявке пишем подробные логи всех операций, взаимодействие с внешними подсистемами, тайминги, референсы
- там же складируются вспомогательные материалы, типа описанного «нового ID», дополнительных идентификаторов, внешних систем
- там же в привязке к заявке все возможные затыки и ошибки операций, где надо будет идти смотреть руками
- когда весь комплекс действий выполнен, у нас есть полный лог, если попросит регулятор
- после успешной операции, вычищаем оттуда анкетные материалы, которые копия; они свою цель выполнили, больше нам не нужны, и прав у нас на них нет
- основные identity невозвратно хешируем, и оно валяется там еще полгода, как факт операции; потом можно дропнуть
Забудь о том, о чем забыл
Неприятный момент требований, что закон требует забыть вообще всё, всю историю взаимодействия. То есть, о том что ты кого-то забывал, тоже следует забыть. Прикольно.
Поскольку мы хотим ограничить использование этого identity далее, но напрямую его хранить не можем, математика нам дает хеши.
У нас никаких перс.данных более не хранится, получить исходный email из хеша не получится.
Но когда Васян придет, и захочет снова зарегаться на этот email — по совпадению хешей мы ему скажем что нет, «такой email зарегистрировать нельзя», без деталей. Ибо нефиг, проблем больше. И мы в своем праве.
Аналогично если регулятор придет с провокационными вопросами про «длинный хвост». Вот вы там удаляли юзера, 7 месяцев назад, покажите подробно предпринятые меры.
А вы красивые, в таком случае отвечаете: милый человек, мы не храним identity юзера и не сможем сопоставить данные по вашему запросу; но если ВЫ нам дадите identity, потому что у нас его нет, то мы можем попробовать найти тайминги операций и статусы их выполнения, по обезличенному хешу, без каких-либо дополнительных данных. И показать, что закон был успешно выполнен. Не более того, тк мы очень законопослушные.
Как удалять
Во-первых, вам нужен периметр. Идёте и собираете руками все системы и тёмные углы, где могут храниться юзерданные, включая косвенные. Их может быть довольно много.
Чтобы упростить себе жизнь в части совсем глубокого копалова, имеет смысл для технических систем ограничить срок хранения данных до, скажем, 30 дней глубины.
Дальше вайп, безотносительно содержимого — все равно шанс, что вы там что-то будете копать в километрах и петабайтах логов на месяц+ в глубину, крайне исчезающе малый.
Вопрос с недоступными данными, архивами и холодными бекапами замечательно закрывается деперсонализацией. Да, в прошлогодних бекапах будут какие-то айдишники. Но чьи это айдишники и зачем они там, вы сказать уже точно не сможете, исходник удален.
Логично, что бекапы с самой анкетной информацией, в таком случае лучше хранить отдельно, и придумать, как чистить. Если пока не придумывается, убедитесь что они лежат отдельно от основной системы, и никто кроме ограниченного круга лиц не имеет к ним доступа. Хорошая идея — пошифровать, и ввести журнал доступа, через бюрократию.
Ситуация, когда вам действительно понадобились прошлогодные бекапы анкетных данных — существует, но пиздецки редкая. Значит, несложно пойти и получить аппрув + ключи через юротдел. По инструкции. Остальным оно нафиг не надо, и доступно быть не должно.
- есть ряд подсистем, которые у нас внутри что-то делают с данными, любыми
- мы учим эти подсистемы отвечать на GDPR-запросы: удаление, получение — как минимум
- подсистема обязана уметь эти две операции, в противном случае она в продакшн не допускается
- когда в систему прилетает подписанный запрос «на удаление», с указанием учетки, система обязана выполнить то что от нее просят, передать статус операции, тайминги
- в нашем случае был дополнительный асинхронный вариант: подсистема получает GDPR-запрос (с айдишником запроса), складывает в очередь, делает всё что надо когда там ей удобнее, а потом отвечает в GDPR-систему результат, с деталями. Потому что чистить много-гиговые архивы, бекапы, и кеши гео-распределенного CDN та еще работенка, там за минутку не уложишься
- в подсистемы надо передать исходные данные: кого ищем по ID юзера, анкетное всякое, новый пустой айдишник — ну, мы это всё на этапе деперсонализации специально сохранили в отдельную кучку, вот оттуда и берем. В основной боевой системе этих данных уже не существует
- у GDPR-системы есть внутренняя статистика по заявке: сколько операций в каких системах должно быть проведено, и сколько их них реально поставлены на выполнение, чем завершились. Если срок выполнения (90 дней) истекает, а операции проведены не все — это алерт, надо идти смотреть руками
- даже если что-то в конкретной системе пошло не так, выполнение чистки в остальных местах этот факт никак не блокирует
Такая схема возможно избыточная, где-то местами. Но делать пришлось с первого раза, непонятно было чего у нас вообще могут потом попросить, поэтому решили что избыточность не повредит.
Регулятору норм, вполне устраивает. В последующих реализациях у меня было попроще, но суть та же.
Заодно с вторым классом запросов, «на получение», аналогичный механизм сразу дает хорошую базу для старта, общее решение. Подход переиспользуется, удобно.
Так же точно, таким же способом, реализуется взаимодействие со внешними системами, которые работают с данными ваших юзеров. Пишется прокладочка, которая поймает запрос от вашей GDPR-системы заявок, сходит куда там надо наружу, запросит удаление, и сложит знание о результатах к вам в систему.
Есть две (с половиной) категории проблемного контента, для подсистем, с ними связанных.
Неструктурированные данные (и их системы)
Самый простой пример — почтовая система. Юзер запросил удаление, а в залежах почты лежит с ним переписка. Там есть только email, но это уже точно персдата — это раз. Как и суть переписки. Еще внутри переписки может быть какая-то неявная и хрен знает какая другая персдата, например вам юзер слал фотки любимого кота с собой в обнимку.
Снаружи это всё нигде не найдется и не торчит, это ваша внутренняя кухня — с одной стороны, это плюс. С другой стороны, если вы не дай бог попадете на аудит, или у вас сопрут базу переписки — вы в глубокой ароматной жопе, миллионов на 20. Этих рисков хотелось бы избежать.
Здесь хорошо бы вспомнить о полисях о работе с емейлом. Точно так же, ставим кап в 90 дней, и локальными политиками юзерам принудительно чистим всю переписку в почтовой системе.
Своих юзеров обязываем ничего оттуда не доставать, не копировать и на память не оставлять — это ваша внутренняя политика и правила. Хочешь искать переписку с клиентами за 2 года глубины — ищешь ее только на почтовом сервере, не у себя в локальном кеше.
Это полезный смежный вопрос еще и на тот случай, чтобы у вас не спиздили архив собственные сотрудники, и не продали налево; ситуация «у нас менеджер обиделся и продал базу клиентов» в sales традиционный отраслевой заход. Вот, нефиг.
Подобными штуками должен заняться юротдел еще вот почему. Мало того, что вы там реально делаете и удаляете. Важно еще, чтобы процедуры и ответственность были конкретно зафиксированы. Все локально валяющиеся дампы базы у девелоперов и опсов, вся кому-то пересланная переписка, внеплановые архивные копии по истечению 90 дней должны считаться токсичным активом, за который юротдел может (и обязан) прийти и больно уебать. Это системный риск по дата-полиси, ребята «знайте заранее и потом не обижайтесь». Вот подпись каждого конкретного васяна под политикой, с которой он ознакомлен и согласен.
Если у вас где-то отросла система, в которой хрен пойми что происходит — это хороший повод пойти, и на нее пристально посмотреть.
Contribution и user-generated content (UGC)
С контрибом сложно. Это те данные, которые вам юзера сами загружают на площадку. Они могут быть любой степени упоротости, не-структурированности. Вы их по ряду законов и так обязаны мониторить (например, на запрещенку), но ретроспективно пойти и достать все упоминания кого-то там, хрен пойми вообще где, за безлимит времени — that’s tricky, задача нормально не решается.
Представим себе тот же форум, на который Вася выложил свою фотку в обнимку с Петей. Или Петя в обнимку с Васей. Еще и с аккаунта Миши.
Как вы вообще собираетесь это удалять, если Вася вдруг решил, что все ему должны найти и убрать?
Ответ «никак» существует. Потому что технические возможности не безграничны, раз, и за свой UGC юзер должен отвечать сам, два. Юридически такая возможность есть, вопрос что написано в доке про Contrib. Если у вас такой доки нет — рысём-бегом отправляетесь делать. Потому что это ограничение ответственности.
Второй момент, который вам поможет в этой связи — вы обязаны удалять контент, но есть оговорка, что вы не можете такими действиями неоправданно затронуть ключевые интересы других пользователей. Удаление контента вразнобой с форумов, из примера выше, неизбежно затрагивает права и возможности остального community. Потому что им форум с дырками нафиг не нужен, его смысл сильно страдает.
В моей практике, решали деперсонализацией и ограничениями ответственности в полисях. Для примера с форумом, прошел деперс, вот у нас есть сообщения хрен знает от кого, в которых что-то говорится. Мало ли что.
Даже если в сообщениях от анонима будет написано «я Вася, вот мой емейл и мои фотки», это уже никак не связано собственно с аккаунтом Васи — мало ли, кто там что написал.
Для точечного удаления контента есть другие механизмы, например можно пожаловаться на куски контента где, как кажется юзеру, раскрываются какие-то персданные — и их удалят.
Но все эти ситуации обязаны быть прописаны в контрибе. Потому что иначе вы просто всем по-умолчанию должны.
Данные нонеймов (редкий случай)
Бывает ситуация, когда приходит юзер к вам/регулятору, и говорит «удалите про меня всё». Аккаунта нет, авторизации нет, вообще нет такого у нас, и вроде как не было. Поискали, точно не нашли. Но юзер просит вполне осознанно — например, потому что когда-то он переписывался с вашей компанией по почте, и вот там что-то теоретически есть. Или может быть.
Ловить такую заявку, коммуницировать, искать и удалять все равно придется.
Пример — чувак хотел к вам устроиться на работу, переписывался с HR, безуспешно. Где-то в почте и црм валяется его прям анкета целиком.
Аккаунта у него нет, но есть четкие основания полагать, что данные обрабатываются. Он в своем праве.
Такие заявки очень редкие (раз), и по ним обычно понятно, где и чего искать (два). Если непонятно, аккаунта нет — спросите у пользователя напрямую, какой контекст он имеет в виду. Вы этот вопрос и ответ все равно должны будете забыть, в итоге, так почему не облегчить себе жизнь.
Про разные ситуации. Ловите байку, которую я должен был забыть (по закону), но такое не забудешь.
Ранняя пора, первые заявки. Что-то начинает шевелиться. Разумеется, первый вал заявок и запросов — от конкурентов и стратегических друзей, которые ходят к друг другу и тестируют, чо там как. Пошатать конкурента, подсмотреть практики.
Мы по каждой заявке пытаемся выяснить, чего за люди, и прояснить кейсы. Чтобы всю механику отладить, и понять как сделать покачественнее. Данные забудем, выводы останутся.
Прилетает заявка, причем не чисто к нам, а прямо через дкома, официально. То есть, выглядит жестко. Товарищ просит удаление, вот акк, вот идентификация. Есть такой у нас. Но не выглядит как конкурент, и у него аккаунт достаточно развесистый. Старый, использовался активно, данные, стата, аналитика, много лет ему. Есть покупки/затраты на аккаунте, история биллинга, причем давно и немало.
Мы перестраховываемся, выходим на коммуникацию с чуваком. В основном чтобы уточнить дополнительно, нет ли тут какой-то ошибки. Может хакнули его, или не понимал что делал, или хрен знает что. Сами достаточно на расслабоне, все равно удалять, надо так надо, главное дров не наломать, и жопу прикрыть. Ну и интересно же.
В ответ от чувака прилетает кулстори на все 100%. Без имен и деталей сейчас, разумеется.
Что у него было какое-то бодалово юридическое, в его реальной жизни, он там накосячил и всем должен как земля колхозу. И его (!) судом (!) обязали не пользоваться вот такими бизнесовыми сервисами, потому что он на этой почве заехал в дурку, у него диагностировали шизу и невменоз. Справка есть.
Сейчас вот он пишет, типа нормальный и отпустило, но никаких гарантий.
И его lawyer сейчас следит, чтобы он предписания судебные выполнил, а для этого надо удалить аккаунт, вот он запрашивает удаление — через дкома, чтобы было официальное подтверждение.
Ему очень жалко всего что там было, у него громадная история вопроса, но жизнь жестока, судьба разлучает нас.
Мы аж забухали от нахлынувших чувств.
Это не финал, у нас еще минимум один большой вопрос не разобран — про отдачу данных. И несколько маленьких.