Утечка данных: что обязаны сделать и в какие сроки

MAATRIX

В логах доступа — чужой IP, скачавший всю таблицу пользователей, или письмо от исследователя безопасности с находкой открытой базы. Первая реакция — паника пополам с вопросом «а что нам теперь за это будет и что вообще делать в первую очередь». Разберём по-человечески: какая обычно возникает логика обязательств у бизнеса при утечке персональных данных и, отдельно, конкретный технический чеклист первых действий — что делать руками, пока юридическая часть ещё уточняется. > Важная оговорка. Это обзорный ознакомительный материал, а не юридическая консультация. Мы намеренно не называем точные сроки уведомления в днях и не разбираем закон постатейно — точные сроки, состав уведомления и перечень исключений зависят от актуальной редакции законодательства, юрисдикции и категории данных, и меняются сами по себе. Если у вас произошла реальная утечка — прежде всего проконсультируйтесь с юристом, специализирующимся на персональных данных, и только параллельно с этим используйте технический чеклист ниже.

Что вообще считается утечкой, требующей реакции

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

Ключевой критерий обычно один: произошёл ли неправомерный доступ, раскрытие, уничтожение или изменение персональных данных, и есть ли из-за этого риск для тех людей, чьи данные затронуты. Если утекли обезличенные агрегаты (сумма продаж по региону) — это не утечка ПДн. Если утекла таблица с именами, email и захэшированными паролями — это утечка, и дальше вопрос в масштабе и характере данных, а не в том, была ли она вообще.

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

Какие обязательства обычно возникают у бизнеса

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

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

Второе — собственно уведомление об инциденте: то, что типично требуется именно при утечке. Общая логика, которую в том или ином виде закрепляет законодательство о персональных данных (и российское, и европейское, и большинства других юрисдикций), выглядит так:

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

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

Технический чеклист: что делать в первые часы

Юридическая часть требует времени на консультацию с юристом, а техническая реакция нужна немедленно — и от неё во многом зависит, как будет выглядеть последующее уведомление. Ниже — специфика именно утечки данных, без пересказа общего плана на случай взлома: если у вас произошла компрометация сервера как таковая (руткит, чужой процесс, шифровальщик), общий порядок действий — изоляция, снятие снимка состояния, восстановление из чистого бэкапа — подробно разобран в статье «Incident response plan: что делать при взломе», здесь мы на нём не повторяемся и берём только то, что специфично именно для утечки.

Шаг 1. Зафиксируйте масштаб — какие данные и сколько людей затронуты

Это первое, что нужно сделать, и именно от этого зависит, какого рода уведомление вообще потребуется. Масштаб оценивается по двум осям: какие именно поля данных затронуты и сколько уникальных субъектов данных в них попадает.

# пример: оценка утечки после компрометации таблицы users
psql -d appdb -c "SELECT count(*) FROM users WHERE ...дата последнего изменения... >= 'дата начала инцидента';"

# если есть access-логи веб-сервера — какие эндпоинты реально были запрошены атакующим
grep '"дата инцидента' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

# если есть логи запросов к базе (slow query log, general log) — какие таблицы читались
grep -i 'SELECT' /var/log/mysql/general.log | grep -Ei 'users|customers|orders|payments' | wc -l

Разница между «утекли email 200 пользователей» и «утекли email, хэши паролей и последние 4 цифры карты 200 000 пользователей» — это разница на порядок в требуемой реакции: в первом случае может хватить внутреннего разбора и уведомления регулятора, во втором почти наверняка потребуется уведомление самих пользователей и, возможно, привлечение специалиста по форензике. Не поддавайтесь соблазну занизить масштаб «пока не разберёмся до конца» — предварительная оценка нужна честная и по возможности с запасом, её всегда можно уточнить позже.

Шаг 2. Устраните причину, но сохраните улики

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

Порядок такой: сначала — сохранить состояние, потом — чинить.

# снять копию логов и текущего состояния ДО любых изменений
mkdir -p /root/breach-$(date -u +%F)
cp -a /var/log/nginx /root/breach-$(date -u +%F)/nginx-logs
cp -a /var/log/mysql /root/breach-$(date -u +%F)/mysql-logs 2>/dev/null
pg_dump -d appdb --schema-only > /root/breach-$(date -u +%F)/schema-snapshot.sql
date -u > /root/breach-$(date -u +%F)/timestamp-utc.txt
tar czf breach-evidence.tar.gz /root/breach-$(date -u +%F)
scp breach-evidence.tar.gz вы@другой_хост:/backup/breach/

# и только теперь — устранение причины, пример для открытой наружу базы
sudo ufw deny from any to any port 5432
# или смена скомпрометированных учётных данных приложения

Если утечка произошла из-за компрометации самого сервера (а не, например, ошибки конфигурации или человеческого фактора), дальнейшие шаги по изоляции, сбору снимка памяти и процессов, смене ключей и восстановлению из чистого бэкапа — это уже территория общего incident response plan, а не специфика утечки данных как таковой, и она подробно разобрана в статье, на которую мы уже ссылались выше.

Шаг 3. Подготовьте фактологическую хронологию инцидента

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

Минимальный состав хронологии, который стоит вести с самого начала расследования:

Не пытайтесь сразу писать хронологию в юридически выверенном виде — сначала зафиксируйте факты по-простому, в рабочем документе, с точными таймстампами и ссылками на конкретные логи и коммиты. Юрист или профильный специалист поможет привести это в форму, пригодную для официального уведомления; переписывать факты задним числом, чтобы они «звучали лучше», — плохая идея и с этической, и с юридической точки зрения.

Шаг 4. Если требуется уведомление пользователей — говорите по существу

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

Слабое уведомление выглядит так: «мы обнаружили инцидент безопасности и приняли меры, ваши данные для нас важны». Оно не даёт пользователю ничего, что он мог бы сделать. Полезное уведомление называет вещи своими именами:

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

Если среди утекших данных — пароли (даже хэшированные) или токены сессий, принудительный сброс на стороне сервера полезнее, чем просьба «пожалуйста, смените пароль по желанию»:

# принудительный сброс всех активных сессий приложения (пример логики на уровне БД)
UPDATE users SET password_hash = NULL, must_reset_password = true;
DELETE FROM sessions WHERE created_at < 'дата обнаружения утечки';

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

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