“Ты думаешь, что просто хранишь данные пользователей для удобства. На деле ты годами копишь бомбу замедленного действия, даже не подозревая о её размерах. Закон не прощает незнания.”
Как тихий сбор данных превращается в грубое нарушение
В российском IT принято считать, что персональные данные, это явно указанные ФИО, паспортные данные или номер телефона. Поэтому многие разработчики и администраторы спокойно хранят логи веб-серверов, IP-адреса, cookie-файлы, историю действий в интерфейсе, технические метаданные файлов. Кажется, что это просто «техническая информация», служебные данные для отладки и аналитики.
ФСТЭК и Роскомнадзор придерживаются иной позиции, основанной на законе. Согласно 152-ФЗ, персональные данные, это любая информация, относящаяся к прямо или косвенно определённому физическому лицу. Косвенное определение — ключевое. Комбинация из IP-адреса, временных меток и последовательности просмотренных страниц зачастую позволяет однозначно идентифицировать человека, особенно в связке с другими системами. То же самое с устойчивыми cookie-идентификаторами. Хранение этой информации без законных оснований и надлежащего оформления — прямое нарушение.
Типичный сценарий: приложение для внутреннего документооборота логирует, кто, когда и какой документ открыл. Цель — отследить активность. Но в логах остаётся связка «учётная запись (ФИО сотрудника) + действие + время». Это уже обработка персональных данных в целях мониторинга, которая требует отдельного основания — согласия сотрудника или прямого указания в локальном акте работодателя, если это необходимо для выполнения трудовой функции. Часто такого акта просто нет.
Незаметные хранилища, о которых все забывают
Проблема не только в осознанно собранных данных. Она в системных артефактах, которые копятся годами автоматически.
- Резервные копии (backup). Полные дампы баз данных, включая таблицы с устаревшими, но не удалёнными пользовательскими профилями, историей заказов, перепиской. Эти копии лежат на отдельных серверах, в облачных хранилищах, на лентах. Срок их хранения часто определяется не политикой обработки ПДн, а общей политикой резервного копирования компании («храним 7 лет»). Таким образом, данные, которые должны были быть удалены из основной системы, продолжают жить в десятках копий.
- Логи промежуточных систем. Elasticsearch, Splunk или Grafana Loki, куда стекаются логи со всех сервисов для поиска и визуализации. Данные в них могут храниться в неструктурированном виде, но содержать те же идентификаторы. Очистка часто настроена менее строго, чем в основной transactional-базе.
- Кэши высокого уровня. Redis или Memcached, где для производительности могут подолгу храниться сессионные данные, профили пользователей, корзины покупок с идентифицирующей информацией. Инвалидация кэша по времени (TTL) не всегда совпадает с требованиями к сроку хранения ПДн.
- Файловые хранилища и объектные базы. Загруженные пользователями документы, сканы, аватары. Метаданные этих файлов (имя загрузившего, дата, оригинальное имя файла с компьютера пользователя) — тоже персональные данные. Их редко чистят синхронно с удалением учётной записи.
Почему «просто удалить» уже недостаточно
Когда факт избыточного хранения обнаружен, первая реакция — пойти в базу данных и выполнить DELETE. Но с точки зрения регулятора, нарушения уже произошли: обработка велась без оснований, возможно, не в тех объёмах, не с теми целями и дольше необходимого срока. Удаление, это лишь мера по исправлению, но не отменяет самого факта нарушения.
Более того, простое удаление записей из основной базы не решает проблему. Данные должны быть удалены (или обезличены) во всех местах хранения: в логах, кэше, резервных копиях, аналитических системах. Для резервных копий это создаёт парадоксальную ситуацию: чтобы удалить данные из старой резервной копии, её нужно восстановить, очистить и создать новую копию. На практике это почти никогда не делается, что создаёт постоянный риск.
Самое сложное — доказать регулятору, что удаление было полным и окончательным. Требуется не только технический акт, но и обновлённая документация: перечень мест хранения ПДн, политика удаления, процедуры очистки всех систем. Без этого проверка выявит формальный подход.
Что делать, если перебор обнаружен
Паника — плохой советчик. Нужен системный подход, который минимизирует риски и выведет обработку в правовое поле.
- Инвентаризация и картирование. Составьте полную карту движения данных в вашей системе: от точки входа (форма регистрации, загрузка файла) до всех мест хранения (основная БД, кэш, логи, бэкапы, CDN). Зафиксируйте, какие именно данные, в каком виде и с какой целью хранятся в каждом компоненте. Это основа для всех дальнейших действий.
- Аудит юридических оснований. Для каждой цели обработки, выявленной на карте, должно быть законное основание: согласие субъекта ПДн, договор, исполнение закона, трудовой договор. Если для каких-то данных (например, детальных логов поведения) основания нет, это кандидаты на немедленное обезличивание или удаление.
- Пересмотр и настройка политик хранения. Установите и технически реализуйте чёткие сроки хранения для каждого типа данных. Настройте автоматическую очистку логов, инвалидацию кэша, ротацию и уничтожение резервных копий по истечении срока. Для старых бэкапов, которые нельзя очистить, рассмотрите возможность их криптографического уничтожения (удаление ключей шифрования).
- Документирование. Внесите все изменения в внутренние документы: политику обработки ПДн, перечень информационных систем, должностные инструкции. Факт обнаружения и меры по исправлению также стоит зафиксировать внутренним актом, это демонстрирует регулятору добросовестность.
- Проактивный мониторинг. Внедрите регулярные (ежеквартальные) проверки на предмет появления новых неучтённых хранилищ или изменения потоков данных. Особенно это важно после запуска новых функций или интеграций.
Как не попадать в такую ситуацию снова
Главный принцип — data minimization (минимизация данных), закреплённый в 152-ФЗ. Нужно внедрить его на уровне архитектуры и культуры разработки.
- Privacy by Design. На этапе проектирования новой функции или сервиса сразу определяйте, какие минимальные данные необходимы для её работы, где они будут храниться, как долго и как будут удаляться. Отказывайтесь от сбора данных «на будущее» или «для аналитики, которая maybe потом понадобится».
- Шаблоны и стандарты для разработчиков. Создайте внутренние гайдлайны по работе с ПДн: какие типы данных можно логировать (только обезличенные события), как правильно кэшировать, как оформлять запросы на создание новых таблиц в БД. Автоматизируйте проверки в CI/CD-пайплайнах на предмет случайной записи чувствительных данных в логи.
- Отдельное хранение для технических и идентифицирующих данных. Разделяйте базы или хотя бы таблицы. Технические логи должны идти в систему, где изначально нет прямой привязки к пользовательскому ID, а есть только session ID, который сам по себе не является ПДн, если не может быть связан с личностью вне системы.
- Регулярный аудит сторонних сервисов. Многие используют внешние сервисы аналитики, рассылок, поддержки. Важно регулярно запрашивать у них информацию о том, какие данные вы передаёте, где они хранятся и как удаляются. Часто оказывается, что передаётся больше, чем предполагалось.
Обнаружить, что ты хранишь лишнее, — не конец, а возможность навести порядок. В российских реалиях, где внимание регуляторов к IT-сектору только растёт, такой порядок из конкурентного преимущества быстро превращается в необходимость для выживания бизнеса. Системный подход к данным с самого начала избавляет от мучительных и дорогостоящих «разборов завалов» в будущем.