GDPR для разработчика

Как только в системе появляются пользователи из Европы, всплывает аббревиатура GDPR — и обычно в связке со словами «штраф» и «удаление данных». Разберём регламент глазами разработчика: что считается персональными данными, когда он вас касается, что реально требует от кода и почему главный приём тот же, что и с картами, — хранить как можно меньше.

Что это и когда касается вас

GDPR (General Data Protection Regulation) — регламент Европейского союза о защите персональных данных. Он касается вас, если вы обрабатываете данные людей, находящихся в ЕС, — независимо от того, где расположена компания и серверы. Это не отраслевой стандарт, как PCI DSS, а закон с ощутимыми штрафами: до 20 млн евро или 4% годового оборота.

Ключевые понятия:

• Персональные данные — любая информация, по которой можно опознать человека: имя, email, телефон, IP-адрес, идентификатор устройства, геолокация. Отдельно выделяют особые категории (здоровье, биометрия, взгляды) — с ними требования строже.
• Субъект данных — сам человек, чьи данные обрабатываются.
• Контролёр и процессор — кто определяет, зачем обрабатывать данные (контролёр), и кто обрабатывает по его поручению (процессор, например облачный провайдер).
• Законное основание — у обработки должна быть причина из списка: согласие, исполнение договора, законное обязательство и другие. Нет основания — нельзя обрабатывать.

Главная стратегия: хранить как можно меньше

GDPR строится на минимизации: собирайте только те данные, которые действительно нужны для задачи, и держите их только столько, сколько нужно. Это же снимает большинство рисков — данных, которых у вас нет, не украдут и не придётся удалять.

• Не собирайте про запас. Каждое поле анкеты должно отвечать на вопрос «зачем оно этой функции». Дата рождения нужна для проверки возраста — храните флаг «18+», а не саму дату.
• Псевдонимизация. Замените прямые идентификаторы суррогатом: аналитика работает с user_hash, а связь user_hash → email лежит отдельно, под строгим доступом. Утечка таблицы событий тогда не раскрывает личности — это тот же ход, что токенизация карт в PCI DSS.
• Срок хранения (retention). У каждого набора данных — свой срок жизни, после которого он удаляется или обезличивается автоматически, а не «лежит вечно на всякий случай».

Права субъекта и что они значат для кода

GDPR даёт человеку набор прав, и почти каждое превращается в конкретную задачу в коде. Заложите их в модель заранее — дописывать «право на удаление» в систему, где данные размазаны по десяти таблицам и логам, дорого.

«Право быть забытым» — самое коварное для архитектуры. Удалить строку в таблице users мало: данные человека осели в заказах, логах, аналитике, бэкапах, у процессоров. Реалистичный подход — обезличивание вместо удаления там, где запись нельзя убрать: заказ остаётся для бухгалтерии, но имя и контакты в нём заменяются на «удалённый пользователь».

// Удаление по GDPR: где можно — удаляем, где нельзя (нужно для учёта) — обезличиваем.
void forget(long userId) {
    profileRepo.deleteByUserId(userId);          // профиль и контакты — под удаление
    orderRepo.anonymizeCustomer(userId);         // заказы остаются, но без ПД
    auditLog.record("gdpr_erasure", userId);     // сам факт удаления фиксируем
}

Выгрузка данных (право на доступ и портируемость) — это обход тех же мест, но на чтение: собрать всё, что связано с пользователем, в один экспорт.

Что это значит для кода

Практически GDPR сводится к нескольким привычкам, знакомым по безопасной разработке:

• Минимум данных в модели. Нет поля — нет проблемы. Особые категории (здоровье, биометрия) не заводят без явной необходимости и отдельного основания.
• Чистые логи. Персональные данные в логе запроса или в стектрейсе — типичное нарушение. Тот же принцип, что и с PII и секретами в логах: в лог идут идентификаторы, а не email и имена.
• Срок хранения в схеме. Поле created_at плюс фоновая задача, которая удаляет или обезличивает записи старше срока, — а не ручная чистка «когда-нибудь».
• Шифрование и доступ. Персональные данные шифруются при хранении и передаче, доступ — по принципу наименьших привилегий, обращения к ним — под аудитом.
• Согласие как данные. Если основание обработки — согласие, храните, на что и когда человек согласился, чтобы это можно было показать и отозвать.

Резидентность данных

Отдельное требование — где физически лежат данные. Для пользователей из ЕС данные часто должны храниться и обрабатываться в регионе ЕС. На практике это выбор региона у облачного провайдера (например, европейский регион AWS или GCP) и запрет на «случайный» вывоз данных в другие регионы через бэкапы или аналитику. Это архитектурное решение — принимайте его до, а не после запуска.

Коротко

• GDPR — закон ЕС о персональных данных; касается всех, кто обрабатывает данные людей из ЕС, со штрафами до 4% оборота.
• Персональные данные — всё, по чему можно опознать человека (имя, email, IP); у обработки должно быть законное основание.
• Главный приём — минимизация: собирать только нужное и хранить ограниченный срок; данных, которых нет, не украдут.
• Права субъекта (доступ, удаление, портируемость) — это конкретные задачи в коде; закладывайте их в модель заранее.
• «Право быть забытым» часто реализуется обезличиванием там, где запись нельзя удалить (заказы, учёт).
• Для кода это: минимум полей, чистые логи, срок хранения в схеме, шифрование, аудит доступа, хранение данных в нужном регионе.

Что почитать дальше

• PCI DSS для разработчика — родственный стандарт про карточные данные; тот же принцип «хранить меньше».
• PII и секреты — как не размазывать персональные данные по логам и конфигам.
• Аудит действий администраторов — журналирование доступа к чувствительным данным.