GDPR и 152-ФЗ: требования к системам глазами разработчика

Прямой ответ

GDPR (Регламент ЕС 2016/679) и 152-ФЗ «О персональных данных» регулируют обработку персональных данных. Разработчику не нужно быть юристом, но нужно понимать, какие технические решения являются требованиями, а не опциями.

Что считается персональными данными: любые сведения, позволяющие определить человека прямо или косвенно — имя, e-mail, телефон, идентификаторы, IP-адрес, данные о местоположении, а также комбинации полей, которые в совокупности выделяют человека из группы.

Базовые принципы обработки (статья 5 GDPR):

1. Законность и прозрачность. Обработка идёт по одному из оснований: согласие, договор, законный интерес, правовая обязанность.
2. Ограничение цели. Данные собираются для конкретных, заявленных целей; использование «на будущее» недопустимо.
3. Минимизация. Собирается минимум, необходимый для цели.
4. Точность. Неточные данные исправляются или удаляются.
5. Ограничение хранения. Данные не хранятся дольше, чем нужно для цели.
6. Целостность и конфиденциальность. Технические и организационные меры защиты.
7. Подотчётность. Организация должна уметь доказать соблюдение.

Что это означает в коде:

• Формы собирают минимум полей. Поле «как вы о нас узнали» может быть полезно маркетингу, но требует отдельного обоснования и не должно быть обязательным.
• Срок хранения задаётся явно. У каждой категории данных — свой срок, по истечении которого выполняется удаление или анонимизация.
• Согласие фиксируется. Хранится не только факт, но и версия политики, время и способ получения; для чувствительных категорий — явное согласие.
• Субъект может реализовать права. Доступ, исправление, удаление, ограничение обработки, переносимость, возражение. Система должна технически это поддерживать — см. право на забвение.
• Privacy by Design. Защита встраивается в архитектуру, а не добавляется после: маскирование, минимальные права доступа, шифрование, журналирование.

Различия, которые важно учитывать при работе с обоими режимами: требования к локализации хранения, порядок уведомления регулятора и субъектов, основания обработки и состав обязательных документов различаются. Конкретные обязательства по юрисдикции и актуальные размеры ответственности определяет юрист; задача разработчика — обеспечить техническую возможность выполнить требование.

Практика: техническая реализация требований

1. Реестр обработки как данные. Для каждой категории данных фиксируйте: цель, основание, срок хранения, ответственного, получателей. Удобно держать это рядом с кодом — в конфигурации или в описании моделей.

data_inventory:
  customers:
    fields: [full_name, email, phone, address]
    purpose: "исполнение договора"
    basis: contract
    retention: "5 лет после завершения договора"
    recipients: [billing_provider]
  support_messages:
    fields: [body, attachments]
    purpose: "обработка обращений"
    basis: legitimate_interest
    retention: "1 год"

2. Сроки хранения как код. Задача по расписанию находит записи с истёкшим сроком и удаляет или анонимизирует их. Без автоматизации «хранить не дольше» не выполняется никогда.

DELETE FROM support_messages WHERE created_at < now() - INTERVAL '1 year';

3. Разграничение доступа. Доступ к персональным данным — по ролям и с журналированием, см. RBAC и audit log.

4. Защита данных. Шифрование при хранении и передаче, маскирование в непроизводственных окружениях, управление секретами — см. шифрование в покое и маскирование PII.

5. Реакция на инцидент. Процедура обнаружения и уведомления должна существовать до инцидента: кто оценивает, кто уведомляет, в какие сроки. Технические предпосылки — журнал доступа и возможность выгрузить, какие данные были затронуты.

Рекомендации:

1. Не собирайте «про запас». Каждое лишнее поле — обязательство по защите и удалению.
2. Проверяйте, куда данные уходят. Аналитика, почтовые сервисы, платёжные провайдеры — получатели данных, их нужно учитывать и контролировать договорами.
3. Тестируйте удаление. Запрос на удаление должен проходить по всем системам, включая резервные копии, кэши и хранилища аналитики.
4. Разделяйте данные и их копии. Копия БД для разработки с персональными данными — типичное и частое нарушение; решение в статье про маскирование.
5. Фиксируйте решения. Почему выбрано основание «законный интерес», как оценивался баланс интересов — эти записи и есть «подотчётность».

Практический сценарий: запрос на удаление вскрыл проблему архитектуры

Контекст: пользователь запросил удаление данных. Выяснилось, что его e-mail и телефон хранятся в семи местах, часть — в денормализованных полях отчётов и в аналитическом хранилище.

1. Инвентаризация. По реестру обработки нашли только четыре источника. Реальный поиск по схемам БД и коду дал семь, включая архивные таблицы и экспортированные отчёты.
2. Проблема. В денормализованных витринах данные были продублированы как обычный текст, без идентификатора субъекта, поэтому точечное удаление было невозможно.
3. Решение. (а) Выполнили запрос вручную по найденным местам с фиксацией в журнале; (б) в витринах заменили идентифицирующие поля на псевдонимы; (в) добавили обязательное поле идентификатора субъекта во все таблицы с персональными данными; (г) реестр обработки дополнили результатом фактического поиска.
4. Проверка. Прогнали тестовый запрос на удаление для фиктивного пользователя и проверили, что во всех системах запись исчезает или анонимизируется.
5. Профилактика. Ввели правило код-ревью: новая таблица с персональными данными требует записи в реестре и поддержки удаления по идентификатору.

Вывод: соответствие требованиям упирается не в тексты политик, а в способность системы найти и удалить данные. Архитектура, в которой персональные данные расплываются по денормализованным копиям, делает выполнение запросов практически невозможным.

FAQ

Нужно ли согласие на обработку cookie аналитики? Как правило, да, если cookie не являются строго необходимыми для работы сервиса. Технически это означает загрузку сторонних скриптов только после получения согласия и возможность отозвать его так же просто, как дать.

Считается ли IP-адрес персональными данными? В большинстве трактовок да, поскольку он позволяет идентифицировать устройство и, косвенно, человека. Практика: не хранить IP дольше, чем нужно для безопасности, и маскировать его в аналитике.

Можно ли использовать продакшен-данные в тестовом окружении? Только после маскирования или псевдонимизации, и с тем же уровнем защиты. Передача немаскированных данных в менее защищённое окружение — типичное нарушение.

Что делать при утечке? Действовать по заранее подготовленной процедуре: зафиксировать факт и масштаб, ограничить дальнейшую утечку, оценить риски для субъектов, уведомить ответственных и, при необходимости, регулятора в установленный срок. Технические предпосылки — журнал доступа и возможность быстро определить затронутые данные.

Источники: GDPR (обзор, статья 5, статья 17) — ссылки в шапке. По 152-ФЗ и актуальным требованиям конкретной юрисдикции необходима консультация юриста.