Персональные данные: что считается ПДн, а что нет

MAATRIX

Разработчик садится проектировать базу данных сайта и упирается в простой на вид вопрос: какие поля — это персональные данные, а какие можно хранить как обычную техническую информацию? IP в логах — это ПДн или нет? А идентификатор сессии в cookie? Ответ путают даже опытные инженеры, потому что закон не даёт таблицы «поле — да/нет», а даёт общее определение, которое нужно применять к конкретному случаю. Разберём эту классификацию на технических примерах: что однозначно ПДн, что спорно, что нет, и как с этим жить на уровне схемы базы данных. > Материал носит обзорный, ознакомительный характер и не является юридической консультацией. Правовая классификация конкретных данных зависит от контекста их обработки, целей сбора и вашей юрисдикции — для реального проекта и особенно для спорных полей проконсультируйтесь с юристом, специализирующимся на защите данных.

Что вообще считается персональными данными: ориентир по 152-ФЗ

В российском законодательстве базовое определение даёт 152-ФЗ «О персональных данных»: персональные данные — это любая информация, относящаяся к прямо или косвенно определённому либо определяемому физическому лицу. Ключевое слово здесь — «определяемому»: данные не обязаны содержать имя напрямую, достаточно, чтобы по совокупности признаков человека можно было идентифицировать или хотя бы выделить среди других. Мы уже разбирали, где по закону обязано физически находиться такое хранилище, в статье про локализацию персональных данных по 152-ФЗ — здесь же сосредоточимся именно на классификации: что конкретно подпадает под это определение применительно к обычному сайту или приложению.

Практическая сложность в том, что понятие «определяемости» контекстно. Одно и то же поле в одной системе может однозначно идентифицировать человека, а в другой — нет, если данные надёжно обезличены и никак не связаны с остальной базой. Именно поэтому дальше есть смысл говорить не «список ПДн-полей», а категориями: от бесспорных случаев до пограничных, где решение зависит от того, как именно вы храните и связываете данные.

Однозначные персональные данные в веб-разработке

Эта категория спора почти не вызывает — если такие данные лежат в вашей базе, вы обрабатываете персональные данные, и весь связанный с этим комплаенс (согласия, политика обработки, меры защиты) на вас распространяется. Типичный набор для сайта или приложения:

• ФИО — имя, фамилия, отчество пользователя, указанные при регистрации, оформлении заказа или в профиле;
• Email — даже рабочий адрес вида i.petrov@company.ru в большинстве трактовок идентифицирует конкретного человека;
• Телефон — мобильный номер, привязанный к аккаунту или указанный в форме заказа;
• Физический адрес — адрес доставки, адрес регистрации, геолокация с точностью до дома;
• Паспортные данные — серия, номер, дата выдачи; для сайтов с верификацией личности (финансы, аренда недвижимости, некоторые B2C-сервисы) это обязательное поле;
• Дата рождения — сама по себе редко идентифицирует человека, но в связке с именем или адресом резко сужает круг и обычно считается ПДн.

Для базы данных это значит: если у вас есть таблица users с полями вроде full_name, email, phone, address — вы работаете с ПДн по определению, и вопрос «а надо ли нам вообще думать о защите» не стоит — он уже решён положительно самим фактом наличия этих полей.

Пограничный случай №1: IP-адрес пользователя

IP-адрес — источник постоянной путаницы, потому что интуитивно он воспринимается как «просто техническая метка», а не как данные о человеке. На практике во многих трактовках IP-адрес считается персональными данными, особенно если он статический или закреплён за конкретным абонентом провайдера: по цепочке провайдер-абонент IP можно связать с конкретным человеком, а значит, он попадает под критерий «определяемости» из определения ПДн.

Это напрямую касается стандартных вещей, которые делает почти любой веб-сервер:

# nginx: IP-адрес клиента пишется в лог каждого запроса по умолчанию
log_format main '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent"';
access_log /var/log/nginx/access.log main;

Строка $remote_addr — это и есть IP, который пишется в лог при любой настройке nginx «из коробки». Формально это означает, что стандартные access-логи веб-сервера уже содержат потенциальные персональные данные, даже если вы вообще не собираете имена и почты. Практический вывод не в том, чтобы паниковать и выключать логирование — оно нужно для отладки и безопасности, — а в том, чтобы:

• ограничить срок хранения логов ротацией (logrotate, обычно 14–30 дней достаточно для отладочных целей);
• не давать к логам доступ шире, чем нужно (не «весь бэкенд-чат читает access.log», а конкретные ответственные);
• не сопоставлять IP из логов с именем пользователя без необходимости — само по себе такое сопоставление превращает обезличенный технический факт в прямую идентификацию.

Отдельно: если вы храните IP не только в логах, а в базе — например, поле last_login_ip в таблице пользователей, — это уже осознанное решение хранить потенциальный ПДн рядом с остальным профилем, и относиться к нему стоит соответственно.

Пограничный случай №2: cookies и идентификаторы устройства

Cookies, идентификаторы сессии и устройства — ещё один пограничный случай, аналогичный IP-адресу по логике: сам по себе идентификатор вида session_id=a3f8c9... не содержит имени или почты, но позволяет отслеживать конкретного пользователя между визитами и, если он связан с аккаунтом, однозначно определяет человека.

Разберём типичные виды таких идентификаторов и разницу между ними:

Технически ключевой момент — как только идентификатор перестаёт быть «просто техническим ключом сессии» и начинает использоваться для накопления профиля поведения конкретного посетителя во времени (даже без имени), риск того, что это будет квалифицировано как персональные данные, растёт. Именно поэтому во многих юрисдикциях требования к cookies для аналитики и рекламы строже, чем к строго функциональным cookies, без которых сайт не будет работать технически (например, cookie корзины интернет-магазина).

Данные аналитики и поведенческие метрики

Аналитика — это область, где грань между «просто цифрами» и персональными данными зависит не от самого показателя, а от того, привязан ли он к идентифицируемому человеку.

Возьмём конкретный пример. У вас есть событие в базе аналитики:

CREATE TABLE events (
    id BIGSERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id),   -- привязка к конкретному пользователю
    event_type VARCHAR(50),
    page_url TEXT,
    created_at TIMESTAMPTZ DEFAULT now()
);

Если в таблице есть user_id, который через внешний ключ ведёт к таблице users с email и именем, то вся эта таблица событий фактически становится частью профиля конкретного человека — «зашёл на страницу оплаты в 23:40, ушёл, вернулся через два дня» превращается в данные о поведении конкретного идентифицируемого человека, а не абстрактную статистику. Это касается и метрик вроде истории просмотров, истории покупок, поведенческих сегментов («часто интересуется категорией X») — если они лежат в связке с идентификатором пользователя, это данные о человеке.

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

Что не считается персональными данными

Есть категории, по которым спора обычно нет — это то, что можно проектировать и хранить без всей тяжести требований к защите ПДн:

• Полностью обезличенная агрегированная статистика. «У сайта было 1000 визитов вчера», «конверсия в заказ — 3,2%», «средний чек за месяц — X рублей» — это агрегаты по множеству людей без возможности выделить конкретного человека из общей цифры. Такие метрики можно свободно хранить в дашбордах, логировать, показывать в отчётах без специальных ограничений.
• Технические логи без идентификации человека. Запись вида 2026-08-28 14:02:11 GET /api/health 200 12ms — без IP, без user_id, без cookie — это чисто техническая информация о работе системы, а не о человеке.
• Внутренние технические идентификаторы, не связанные с личностью. Автоинкрементный id строки в таблице заказов сам по себе ничего не говорит о человеке, пока не соединён с таблицей пользователей.
• Данные о самой инфраструктуре. Метрики нагрузки сервера, использование CPU/RAM, количество запросов в секунду — это данные о системе, а не о людях, даже если высокая нагрузка вызвана действиями конкретных пользователей.

Отдельно стоит особая категория — так называемые специальные категории персональных данных, к которым закон предъявляет повышенные требования обработки. Типичный пример для веб-разработки — данные о здоровье на сайте медицинской тематики (записи на приём, результаты анализов, диагнозы в личном кабинете пациента). Такие данные требуют более строгого подхода к защите, чем обычные ФИО и телефон, но точные детали этих требований — предмет отдельной консультации с юристом, а не общего обзора: если ваш проект работает с подобными данными, закладывайте время на профильную юридическую и техническую экспертизу заранее, ещё на этапе проектирования.

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

Самая дешёвая точка для учёта всей этой классификации — не аудит через год после запуска, а проектирование схемы базы данных на старте. Разумный подход:

1. Промаркируйте поля на этапе схемы. Прямо в комментариях к миграции отмечайте, какое поле — явный ПДн, какое пограничное, какое нет:

CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL,        -- ПДн: явный
    full_name VARCHAR(255),             -- ПДн: явный
    phone VARCHAR(20),                  -- ПДн: явный
    last_login_ip INET,                 -- ПДн: пограничный, хранить с ограничением по сроку
    marketing_uid UUID,                 -- ПДн: пограничный (идентификатор аналитики)
    created_at TIMESTAMPTZ DEFAULT now(),  -- не ПДн
    signup_source VARCHAR(50)           -- не ПДн (откуда пришёл трафик, без привязки к человеку)
);

1. Разделяйте явные ПДн и остальное по уровню доступа. Если явные ПДн вынести в отдельную таблицу (или хотя бы явно отметить в правах доступа к столбцам), проще ограничить, кому в команде вообще нужен доступ к email и телефону, а кому достаточно видеть агрегированные метрики без привязки к личности.

1. Заранее продумайте срок хранения для пограничных полей. IP последнего входа, идентификаторы аналитики, необезличенные логи — не обязаны храниться вечно. Разумная политика хранения (retention policy) с фоновой задачей очистки снимает риск накопления лишних данных «на всякий случай».

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

1. Не тащите ПДн туда, где они не нужны. Частая ошибка — писать email или телефон в лог для отладки («залогируем весь payload запроса, потом разберёмся»). Проще с самого начала маскировать такие поля в логах (*@*.ru вместо полного адреса), чем потом чистить архив логов за полгода.

Общая логика простая: чем раньше в проекте появляется явное разделение «это точно ПДн, это спорное, это точно нет», тем дешевле обходится любое последующее требование — будь то ответ на запрос пользователя об удалении данных, подготовка к проверке или банальное расширение функциональности. С организационной стороной такого учёта (сколько это стоит по деньгам и времени) можно свериться со статьёй сколько стоит соответствие 152-ФЗ — а с общим техническим порядком на сервере, куда эти данные ложатся, поможет чек-лист безопасности нового сервера.

Частые вопросы