Когда Хеш Является Персональными Данными? Решение Суда ЕС по Делу SRB и Идентичность в Аналитике

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

Что на самом деле решило дело EDPS против SRB

Дело — EDPS против SRB, C-413/23 P — возникло из урегулирования Banco Popular. Единый совет по урегулированию (SRB) собрал комментарии акционеров, заменил личность каждого автора буквенно-цифровым кодом и передал закодированные комментарии Deloitte как независимому оценщику. У Deloitte не было ключа для обращения кодов и никакого иного пути к авторам.

Суд ЕС постановил, что псевдонимизированные данные не являются автоматически персональными данными для каждой стороны, которая их касается. Является ли набор данных персональным, оценивается относительно владельца — с позиции конкретного получателя, с учётом технических, организационных и правовых средств, реально ему доступных.

Это тест относительной (или контекстной) идентифицируемости, и он представляет собой действующее прочтение «средств, которые с разумной вероятностью могут быть использованы» из Соображения 26. Данные, персональные в руках контролёра, могут быть неперсональными в руках получателя, который действительно не может никого повторно идентифицировать.

Напряжение с EDPB

Суд не выдал поставщикам индульгенцию. Руководящие принципы EDPB 01/2025 по псевдонимизации придерживаются намеренно более строгой линии: псевдонимизированные данные остаются персональными, пока кто-либо — контролёр или некая третья сторона — сохраняет средства повторной идентификации. Отчёт EDPB от февраля 2026 года по анонимизации и псевдонимизации — это работа совета именно над этим разрывом между его позицией и позицией суда.

Для разработчиков практическое прочтение консервативно. Не считайте, что хешированное значение выходит за рамки GDPR лишь потому, что ваш сервис не может его обратить. Правильный вопрос — является ли повторная идентификация разумно вероятной для любого, кто владеет дополнительной информацией, и существует ли эта дополнительная информация вообще.

Почему большинство аналитических хешей не проходят тест

Хеширование идентификатора — это не анонимизация. SHA-256 от адреса электронной почты детерминирован: один и тот же адрес всегда даёт один и тот же дайджест. Любой, у кого есть список адресов-кандидатов, может их захешировать и сопоставить. Хеш — стабильный, связываемый ключ: в лучшем случае псевдонимизация и персональные данные при обеих трактовках, потому что средства повторной идентификации тривиально доступны.

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

Что делает хеш по-настоящему защитимым

Два свойства переводят хеш из «псевдонимизированных персональных данных» в «разумно не поддающийся повторной идентификации»: секретная соль, которая никогда не хранится рядом с данными, и вход, который нельзя исчерпывающе угадать и который не сохраняется во времени. Модель идентичности Monoid построена именно на этом:

SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

Сырые IP и User-Agent живут в памяти Worker лишь столько, сколько нужно для вычисления дайджеста; D1 хранит хеш, а не входные данные. SALT_SECRET хранится на стороне сервера и никогда не записывается рядом с данными, поэтому атака по радужным таблицам или перебором против сохранённых хешей лишена опоры. А поскольку дата — это вход, дайджест одного и того же посетителя сменяется каждую полночь UTC. Нет стабильного межсуточного ключа для корреляции.

Прогоните эту конструкцию через оба теста. По относительному стандарту Суда ЕС ни один получатель сохранённых хешей — включая сам Monoid, запрашивающий собственную D1, — не располагает средствами, с разумной вероятностью пригодными для повторной идентификации, потому что соль изолирована, а вход неперечислим. По более строгому стандарту EDPB «кто угодно» необходимая дополнительная информация (сырой IP плюс UA плюс секретная соль для конкретной даты) нигде не сохраняется после завершения запроса. Средства повторной идентификации не просто ограничены — они перестают существовать.

Как проверить собственный стек

Решение даёт конкретный чек-лист, применимый к любой аналитике, на которую вы полагаетесь:

• Перечислим ли хешируемый вход? Email, телефон или сырой IP можно захешировать и сопоставить со списком кандидатов. Если пространство входа мало, хеш на практике обратим.
• Отделена ли секретная соль от сохранённых данных? Хеш без соли или с солью в том же хранилище не даёт реального барьера повторной идентификации.
• Сохраняется ли идентификатор между сессиями? Стабильный ключ, связывающий активность человека на протяжении недель, — персональные данные при любой трактовке. Ключ, сменяемый ежедневно, не может накопить профиль.

Суд ЕС не объявил псевдонимизацию безопасной гаванью, а EDPB следит, чтобы её никто так не читал. Устойчива та позиция, которой не нужна никакая интерпретация, чтобы победить: хеш с солью, сменяемый ежедневно, над неперечислимым входом разумно не поддаётся повторной идентификации никем, потому что материал, нужный для его обращения, никогда не сохранялся.

Источники

• Решение Суда ЕС по делу C-413/23 P, EDPS против SRB (4 сентября 2025 года)
• Руководство EDPB 01/2025 по псевдонимизации
• Отчёт EDPB о мероприятии с заинтересованными сторонами по анонимизации и псевдонимизации от 12 декабря 2025 года
• Пункт 26 преамбулы GDPR — Не применяется к анонимным данным