При утечке персональных данных действуйте как при инциденте ИБ: сначала зафиксируйте симптомы, выполните только read-only проверки, быстро ограничьте доступы и сохраните логи. Затем оцените масштаб (какие данные и системы затронуты), подготовьте уведомления и восстановление. Если риск высокий, подключайте профильных специалистов и юриста.

Признаки утечки и первоочередные шаги

Пользователи жалуются на спам/звонки, подозрительные письма "от вас" или попытки входа в их аккаунты.
Неожиданная активность в логах: массовые выгрузки, всплеск запросов к API, аномальные SELECT/EXPORT.
Новые администраторы/токены/ключи, которых никто не создавал; изменения прав доступа.
Утечки в публичных местах: индексация страниц с данными, открытый бакет/папка, репозиторий с дампом.
Сразу: заморозьте изменения в проде, включите сбор артефактов (логи, снапшоты), ограничьте доступы по минимуму.
Параллельно определите ответственных: ИБ/DevOps, владелец системы, DPO/ответственный за ПДн, юрист.

Как обнаружить утечку: индикаторы и источники риска

Начинайте с наблюдаемых симптомов (что видит бизнес и пользователи), затем переходите к источникам риска. До подтверждения инцидента не "лечите" систему действиями, которые сотрут следы: сначала read-only сбор фактов.

Рост обращений: "оформили кредит", "приходят коды подтверждения", "меня взломали после регистрации у вас".
Скачкообразный рост исходящего трафика, особенно на внешние IP/в ночное время.
Резкие пики запросов к эндпоинтам выгрузки, поиску, админ-панели, GraphQL introspection.
Появление ваших данных в поиске (кэш), на форумах/пастах/телеграм-каналах, "слив базы".
Доступ "из необычных мест": новые ASN/страны, ранее нехарактерные User-Agent.
Типовые источники: утекшие токены (Git, CI), misconfig облачных хранилищ, SQL-инъекция, компрометированный админ, фишинг, подрядчик с широкими правами, некорректные ACL в CRM/Helpdesk.

Быстрая изоляция инцидента: что делать в первые часы

Цель первых часов - остановить дальнейший отток и сохранить доказательства, не ломая прод и не стирая логи. Этот чек-лист отвечает на вопрос "что делать при утечке персональных данных" в практическом порядке: от быстрых и безопасных действий к более вмешательным.

Назначьте инцидент-менеджера и канал связи (закрытый чат), зафиксируйте время начала и что именно замечено.
Включите "заморозку" изменений: временно запретите деплои/миграции, кроме действий по реагированию.
Read-only сбор: снимите копии логов WAF/NGINX/ALB, БД audit/slow/general (если включено), логи приложения, IAM-аудит, события CI/CD.
Снимите "снимок состояния" доступа: список активных токенов, API keys, сессий админов, пользователей с повышенными правами.
Ограничьте очевидные "дырки" с минимальным риском: закрыть публично доступные каталоги/бакеты/эндпоинты выгрузки через правила на уровне WAF/Reverse proxy.
Временно понизьте лимиты и включите rate limiting на критичных эндпоинтах (по IP/учётке), не меняя бизнес-логику.
Отключите или изолируйте подозрительную интеграцию/вебхук/ключ подрядчика, если видно злоупотребление (с сохранением артефактов).
Проверьте, не опубликованы ли секреты: поиск по репозиториям и артефактам сборки (read-only). При подтверждении - готовьте ротацию.
Зафиксируйте перечень систем, где могут быть ПДн: CRM, формы, аналитика, почтовые сервисы, колл-трекинг, Helpdesk.
Определите, какие персональные данные потенциально затронуты (минимальный предварительный список) и кого уведомлять внутри компании.
Если есть признаки активной атаки - подключите провайдера/хостинг/облачную поддержку для блокировок по сети и сохранения логов.

Оценка масштаба: проверка затронутых данных и систем

Задача - ответить на три вопроса: какие именно данные, откуда они утекли и продолжается ли утечка. Сначала проверяйте самые вероятные и быстро проверяемые причины: публичная экспозиция, компрометация ключей, массовые запросы к API/БД, затем более сложные версии (внутренний нарушитель, цепочка компрометации).

Симптом	Возможные причины	Как проверить (read-only где возможно)	Как исправить
Данные индексируются поиском / доступны по прямой ссылке	Публичные страницы/каталоги, неверные ACL, отсутствие авторизации, открытый объект в облаке	Проверка URL и заголовков, проба доступа в инкогнито; просмотр конфигов ACL/политик в консоли (без изменений); логи 200/206 на эти пути	Закрыть доступ на уровне прокси/WAF/ACL; убрать индексацию; провести инвентаризацию публичных маршрутов; задним числом запросить удаление кэша/сниппетов (если применимо)
Массовые выгрузки через API/личный кабинет	Скомпрометированная учётка, слабый rate limiting, отсутствие антибота, утечка токена	Логи API: частота, последовательные страницы, одинаковые паттерны; сопоставить user_id, IP, User-Agent; проверить события входа и смены устройств	Отозвать/перевыпустить токены; включить rate limiting/капчу на экспорт; принудительный выход из сессий; MFA для админов и чувствительных операций
Подозрительные SELECT/EXPORT в БД	SQL-инъекция, украденный пароль БД, широкие права сервисного аккаунта, утечка дампа	DB audit/general log (если есть), метрики длительных запросов, анализ последних подключений; проверка ролей и привилегий; поиск файлов дампов на серверах (read-only)	Сменить пароли/сертификаты, ограничить права (least privilege), закрыть уязвимость (валидировать ввод, параметризованные запросы), вынести экспорт в отдельный сервис с контролем
Новые админы/ключи/интеграции	Компрометация IAM, фишинг, утечка ключей в Git/CI, компрометированный подрядчик	IAM audit trail: кто/когда создал; проверка репозиториев на секреты; логи CI на доступ к переменным окружения; сравнение с заявками/тасками	Отозвать ключи, ротация секретов, принудительный сброс паролей, ревизия прав подрядчиков, включить условный доступ и MFA
Пользователи получают "коды входа" и сбросы пароля без запроса	Credential stuffing, утечка паролей у пользователей, слабая защита аутентификации	Логи auth: много неуспешных попыток, распределённые IP, всплески по конкретным email/телефонам; наличие утечек в ваших логах отправки SMS/email	Rate limit и блокировки по признакам; уведомления пользователям; MFA/2FA; проверка требований к паролям; защита от перебора (WAF/бот-менеджмент)
Появился файл "база клиентов.xlsx/sql" в общедоступном месте	Человеческий фактор, общий диск без прав, публичная ссылка, почтовая пересылка	Журналы файлового хранилища (share/link events), история прав; поиск по DLP/EDR (если есть); опрос владельцев данных	Отозвать ссылки, ограничить доступ, включить срок жизни ссылок и запрет внешнего шаринга, обучение, DLP-политики

Минимальный перечень артефактов, которые стоит собрать

Временная шкала (когда началось, кто заметил, что именно).
Логи доступа: web/API, auth, WAF, VPN, IAM, админ-панель.
Список затронутых сущностей: таблицы/эндпоинты/папки/бакеты.
Снимок прав: роли, группы, сервисные аккаунты, токены/ключи (без раскрытия секретов в тикетах).
Список контрагентов/подрядчиков, у кого был доступ.

Уведомление пострадавших и регуляторов: сроки и содержание

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

Классифицируйте данные: какие категории ПДн могли быть затронуты (контакты, документы, платежные данные, учётные записи) и есть ли специальные категории.
Определите круг субъектов: клиенты, сотрудники, лиды, подрядчики; оцените, продолжается ли утечка.
Подготовьте краткое описание инцидента: что произошло, когда, какой источник, какие меры уже приняты (без технических деталей, которые помогут атакующему).
Согласуйте юридическую позицию: формулировки, каналы уведомлений, перечень рекомендаций пострадавшим, ответственность сторон (особенно при обработке через подрядчиков).
Сформируйте сообщение для пострадавших: что утекло (по возможности конкретно), что не утекло (только при уверенности), что им сделать сейчас (смена пароля, осторожность к фишингу, блокировка карты).
Определите, нужно ли обращаться в профильные органы и по каким каналам; зафиксируйте факт обращения и входящие номера/квитанции.
Уведомите внутренних стейкхолдеров: поддержка, продажи, PR, безопасность, HR (если затронуты сотрудники) - чтобы ответы были единообразны.
Запустите мониторинг вторичных эффектов: фишинговые домены, рассылки от вашего имени, рост обращений в поддержку.

Техническое восстановление и изменения в доступах

Происшествия и безопасность: что делать при утечке персональных данных - иллюстрация

После изоляции и первичной оценки переходите к восстановлению: закрыть уязвимость, ротировать секреты, переточить права, подтвердить отсутствие повторного доступа. Эскалируйте, если затронуты ключевые системы или нет уверенности в точке входа.

Когда лучше не тянуть и подключать специалистов

Есть признаки компрометации IAM/админ-доступа (создание новых ключей, политик, скрытые аккаунты).
Утечка затрагивает платежные данные, документы, учетные данные или большие массивы ПДн.
Не удаётся определить источник за 1 рабочий день, а аномальная активность продолжается.
Логи неполные/отсутствуют, требуется форензика и восстановление цепочки событий.
Инцидент затрагивает подрядчика/облако и нужны совместные действия и юридическая фиксация.

Практические технические действия (в порядке безопасности)

Сохраните и защитите логи: ограничьте доступ к ним, сделайте копии в отдельное хранилище.
Ротация секретов по приоритету: публично скомпрометированные ключи → сервисные токены → пароли БД → ключи подписи.
Принудительная инвалидация сессий и токенов для затронутых пользователей/админов.
Патч уязвимости: исправление авторизации, SQLi, IDOR, ошибок экспорта; добавление серверной валидации.
Усиление контроля на периметре: WAF-правила, ограничение админки по IP/VPN, отключение небезопасных методов/эндпоинтов.
Проверка целостности: сверка хэшей релизов, анализ изменений в конфигурации, поиск веб-шеллов/посторонних cron-задач (с осторожностью к доказательствам).

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

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

Меры на будущее: минимизация риска повторной утечки

Инвентаризация данных: где хранятся ПДн, кто владелец, сроки хранения, основания обработки.
Минимизация: собирайте только необходимое, сокращайте срок хранения, псевдонимизируйте где возможно.
Least privilege: отдельные сервисные аккаунты, минимальные роли, регулярная ревизия доступов и токенов.
Журналирование по умолчанию: auth, доступ к ПДн, экспорт/выгрузки, админ-действия; централизованный сбор логов.
Контроль выгрузок: лимиты, ручное подтверждение для массовых экспортов, watermarking, уведомления о выгрузке.
Защита секретов: secret manager, запрет секретов в Git/CI-логах, автоматическая ротация и сканирование репозиториев.
Тестирование: регулярный pentest/сканирование, проверка IDOR/авторизации на API, безопасные настройки облака.
Учения и плейбуки: готовые шаблоны уведомлений, матрица эскалации, тренировочные инциденты 1-2 раза в год.
Договоры с подрядчиками: ответственность, доступы, требования к логам и уведомлениям об инцидентах.
Регулярный аудит персональных данных для компании как процесс: от карты потоков данных до проверки технических и организационных мер.

Типичные сценарии утечек и конкретные решения

Нашли публичную ссылку на файл с клиентской базой. Что делать сразу?

Немедленно закройте доступ (ACL/ссылка/права), сохраните логи скачиваний и список тех, кто имел доступ на публикацию. Затем оцените, какие поля в файле и кто мог успеть скачать.

Подозрение на SQL-инъекцию, но нет уверенности. Какие первые проверки?

Посмотрите web/API логи на необычные параметры и повторяющиеся шаблоны, сопоставьте со всплеском SELECT/ошибок 5xx. До патча сохраните артефакты и ограничьте подозрительные запросы на уровне WAF.

Скомпрометировали аккаунт администратора. Достаточно сменить пароль?

Нет: нужно отозвать активные сессии/токены, проверить созданные ключи и изменения ролей, затем включить MFA и ограничить админ-доступ по сети. Параллельно проверьте, не менялись интеграции и вебхуки.

Утечка идёт через API, но отключение API "положит" продукт. Что делать?

Включите жёсткий rate limiting и временные блокировки по признакам, ограничьте эндпоинты экспорта, включите дополнительные проверки на чувствительные операции. Это обычно позволяет остановить массовую выгрузку без полного даунтайма.

Утечка персональных данных куда обращаться, если у нас есть подрядчик-обработчик?

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

Можно ли быстро понять, какие именно записи утекли?

Иногда да: по логам выгрузок/запросов, диапазонам ID, фильтрам и объёму ответа. Если логов нет, используйте косвенные признаки (время доступа, размер трафика, список затронутых таблиц/файлов) и закладывайте худший реалистичный сценарий.

Когда уместно покупать услуги по защите ПДн вместо попыток "своими силами"?

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