Утечка базы данных с паролями: пошаговый план реагирования в 2026 году

Первые 60 минут: изоляция скомпрометированного сегмента

Рабочий порядок действий в первый час: зафиксировать состояние систем, изолировать сетевой сегмент с базой, отозвать активные сессии и токены, сменить пароли сервисных учётных записей и ключи API, уведомить команду ИБ и руководство. Выключение сервера и удаление базы в этот список не входят: они уничтожают доказательства, а восстановление после них обходится дороже самого разбора.

Атаки 2026 года всё чаще ведёт автоматика. Регулятор Испании AEPD зафиксировал случай, когда доступ к системе и изменение персональных данных выполнял ИИ-агент на базе крупной языковой модели, работавший автономно. Такие цепочки проходятся быстрее, чем вручную, поэтому задержка с изоляцией измеряется минутами.

Что делать до изоляции: фиксация состояния

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

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

Часть артефактов удобнее снимать средствами платформы. Если база размещена в managed-сервисе, например в Timeweb Cloud, снимок диска и копия журналов делаются из панели или через API, без входа на хост, а изоляция сводится к правке правил firewall и отзыву выданных токенов.

Как изолировать сегмент, не потеряв forensic-данные

Задача изоляции: разорвать все соединения с базой, оставив один канал до хоста, который собирает логи и дампы. На отдельном хосте поднимите приёмник логов и разрешите трафик только с адреса базы.

iptables -N DBISOLATE
iptables -A DBISOLATE -s 10.20.0.5 -j ACCEPT
iptables -A DBISOLATE -j DROP
iptables -I INPUT -p tcp --dport 5432 -j DBISOLATE
iptables -I FORWARD -p tcp --dport 5432 -j DBISOLATE

Адрес 10.20.0.5 здесь принадлежит сборщику логов, он остаётся единственной точкой входа. Проверьте, что не заблокировали исходящий трафик к серверу точного времени и к системе мониторинга: расхождение часов ломает timeline.

В Kubernetes тот же результат даёт политика deny-all с исключением для pod с forensic-инструментами.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-deny-all
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: forensics
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: forensics

NetworkPolicy работает только с CNI, который их поддерживает: Calico, Cilium, Antrea. В managed Kubernetes правило применяется так же, но проверьте, что egress к kube-dns на порт 53 остался открытым, иначе pod потеряет разрешение имён.

Отзыв сессий выполняйте сразу после изоляции. В PostgreSQL активные бэкенды снимаются запросом:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE usename NOT IN ('postgres','monitoring')
  AND pid <> pg_backend_pid();

Для веб-приложения очистите сессии в Redis и ротируйте ключ подписи JWT. Пока действует старый ключ, украденный токен сохраняет доступ даже после смены пароля пользователя.

1. Зафиксировать состояние и снять snapshot.
2. Изолировать сегмент через ACL, сохранив канал до сборщика логов.
3. Отозвать сессии, токены и ключи API, выданные приложению.
4. Сменить пароли сервисных учётных записей и доступы к репликам.
5. Уведомить ИБ, руководство и ответственного за защиту персональных данных.

Оценка масштаба утечки и определение затронутых учётных записей

Масштаб определяется по аудит-логам СУБД и приложения, а не по догадкам. Разница между выгрузкой всей таблицы users и чтением двухсот строк меняет и объём работ, и требования к уведомлению регулятора.

Анализ логов и определение вектора атаки

Включите расширенный аудит, если он ещё не включён: pgAudit для PostgreSQL, audit_log для MySQL и MariaDB, profiler для MongoDB. Ищите в логах:

• полные выгрузки: SELECT * FROM users, COPY ... TO, INTO OUTFILE, mongoexport;
• входы в СУБД с IP вне разрешённого списка и в нетипичные часы;
• всплеск ошибок синтаксиса SQL, типичный след инъекции через веб-форму;
• чтение таблиц с хешами паролей, к которым приложение обычно не обращается напрямую;
• новые учётные записи с правами суперпользователя и изменения в списках администраторов.

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

Когда объём логов измеряется гигабайтами, поиск аномалий ускоряют языковые модели: агрегатор AiTunnel даёт доступ к GPT, Gemini и Claude через единый интерфейс с оплатой в рублях. Хеши паролей и персональные данные перед таким разбором маскируйте: модели не должны получать исходные значения.

Как определить, какие учётные записи скомпрометированы

Границы ущерба задаёт SQL-запрос по журналу и таблице пользователей. Пример для PostgreSQL с pgAudit:

SELECT u.id, u.email, u.last_login, u.password_algo,
       max(a.log_time) AS last_touch
FROM users u
LEFT JOIN pgaudit_log a
  ON a.object_name = 'users' AND a.statement ILIKE '%select%'
GROUP BY u.id, u.email, u.last_login, u.password_algo
ORDER BY last_touch DESC NULLS LAST;

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

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

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

Классификация алгоритмов хеширования и оценка скорости взлома

Приоритет сброса задаётся алгоритмом и его параметрами. Хеш нельзя прочитать, но можно перебрать, и стоимость перебора различается на десять порядков.

Слабые алгоритмы: MD5, SHA-1, SHA-256 без соли

Быстрые хеши создавали для проверки целостности, а не для хранения паролей. GPU перебирает их с огромной скоростью, а отсутствие соли позволяет подставить готовые таблицы.

Сильные алгоритмы: bcrypt, Argon2, PBKDF2 с высокими параметрами

Медленные алгоритмы отличаются вычислительной стоимостью одного хеша. Argon2id добавляет к ней требовательность к памяти, из-за чего GPU теряет преимущество: видеокарта с 24 ГБ памяти держит ограниченное число параллельных потоков.

Ориентир для расчёта: пространство паролей из восьми строчных латинских букв и цифр содержит 2,8 трлн комбинаций, средний перебор проходит половину. Аренда восьми GPU уровня RTX 4090 в публичном облаке стоит единицы долларов за час, поэтому база на MD5 в миллион записей перебирается за сутки и десятки долларов, а та же база на bcrypt с cost 12 упирается в годы и сотни тысяч долларов.

Число в таблице описывает полный перебор. Пароль из словаря, даты рождения или комбинации вроде Qwerty123 падает мгновенно при любом алгоритме, и такие значения составляют заметную долю реальных баз. Вывод для приоритизации: при MD5, SHA-1, SHA-256 и PBKDF2 с числом итераций меньше 10 000 считайте пароли раскрытыми и запускайте сброс немедленно; при bcrypt cost 12 и выше, Argon2id с памятью 64 МиБ и больше сброс всё равно обязателен, но паники и ночных дежурств он не требует.

Принудительный сброс паролей и внедрение MFA

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

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

Linux с PAM: passwd -e user помечает пароль просроченным и требует смены при следующем входе. Массово по списку из выгрузки:

while read -r u; do passwd -e "$u"; done < affected_users.txt

Active Directory и Windows:

Get-Content .\affected_users.txt | ForEach-Object {
  Set-ADUser -Identity $_ -ChangePasswordAtLogon $true
}

Веб-приложение: замените хеш на случайное значение и поднимите флаг обязательной смены. Пока пароль не сменён, вход по нему невозможен.

UPDATE users
SET password_hash = crypt(gen_random_uuid()::text, gen_salt('bf', 12)),
    must_change_password = true,
    sessions_revoked_at = now()
WHERE id = ANY($1);

Инвалидация сессий идёт тем же релизом: удаление ключей из Redis, ротация signing key для JWT, закрытие долгоживущих токенов API. Тем, кто не может войти, выдавайте одноразовые ссылки с коротким сроком жизни, а не временные пароли по почте.

Выбор факторов аутентификации: TOTP, WebAuthn, FIDO2

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

Практичный порядок: WebAuthn или FIDO2 для администраторов, платёжных и биллинговых операций, TOTP для остальных сотрудников. Сравнение методов, интеграция с Active Directory и LDAP, а также расчёт стоимости владения собраны в руководстве по внедрению двухфакторной аутентификации. Заранее продумайте восстановление доступа: протокол при утрате ключа 2FA спасает от блокировки админских учётных записей в разгар инцидента.

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

Юридические требования: уведомление регуляторов и пользователей

Технические шаги не отменяют сроков, которые считаются с момента, когда об инциденте стало известно, а не с момента завершения расследования.

GDPR: сроки и содержание уведомления

Статья 33 GDPR требует направить уведомление надзорному органу в течение 72 часов после того, как стало известно о нарушении, если оно создаёт риск для прав и свобод людей. Если уложиться в срок не удалось, уведомление всё равно подаётся, но с объяснением причины задержки. Порог в 250 пострадавших от подачи не освобождает: критерий один, наличие риска.

Статья 34 GDPR касается уведомления самих субъектов данных. Сообщение уходит без неоправданной задержки, если есть высокий риск для прав и свобод: кража паролей в связке с почтой и другими сервисами почти всегда подпадает под этот критерий. В уведомление включают характер нарушения, категории и примерное число затронутых лиц, контакты ответственного за защиту данных, возможные последствия и принятые меры. Штрафы по статье 83 доходят до 20 млн евро или 4% годового оборота, причём санкции применяют и за просрочку, и за неполное описание.

Локальные законы: 152-ФЗ, AEPD и другие

В России по Федеральному закону № 152-ФЗ уведомление Роскомнадзора об инциденте с персональными данными подаётся в течение 24 часов с момента обнаружения. Затем в течение 72 часов направляются результаты внутреннего расследования: причины, масштаб, сведения о лицах, чьи данные затронуты, и принятые меры. Неуведомление и просрочка ведут к административным штрафам, размер которых для юридических лиц измеряется миллионами рублей.

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

Храните доказательства и переписку по инциденту не дольше, чем нужно для защиты в спорах, и учитывайте требования к срокам хранения логов и персональных данных: избыточное хранение само создаёт риск. Конкретные сроки для ПДн, логов, метрик и резервных копий разобраны в руководстве по срокам хранения данных.

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

Пост-инцидентные меры: как не допустить повторения

Аудит и ротация секретов

После утечки меняется всё, что могло попасть в дампы: пароли сервисных учётных записей, строки подключения в конфигурациях и CI, ключи API, токены вебхуков, TLS-сертификаты, ключи шифрования резервных копий, SSH-ключи администраторов. Храните секреты в менеджере вроде HashiCorp Vault, выдавайте их приложениям по короткоживущим токенам и настройте регулярную ротацию: смена раз в 90 дней дешевле, чем разбор второго инцидента.

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

Мониторинг и сегментация сети

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

Настройте алерты на аномалии: выгрузка большого объёма строк, вход вне рабочего окна, резкий рост ошибок аутентификации, подключение нового клиента к реплике. Базовый набор проверок административной панели и прав доступа описан в чек-листе безопасности админ-панели.

Типичные ошибки при реагировании на утечку

• Удаление базы или перезагрузка сервера, чтобы остановить атаку. Доказательства теряются, а данные всё равно уже выгружены.
• Чистка логов и ротация без сохранения копий. Timeline восстановить нечем, сроки уведомления считаются от факта обнаружения, а не от удобного момента.
• Сброс паролей без инвалидации сессий и токенов. Атакующий остаётся в системе под старым токеном и возвращается после релиза.
• Смена пароля одного пользователя при подозрении на массовую выгрузку таблицы. При MD5 и SHA-1 сбрасывать нужно всем.
• Отсутствие второго фактора у администраторов. Один украденный пароль превращается в полный доступ к инфраструктуре.
• Задержка с уведомлением регулятора до окончания расследования. Сроки стартуют с момента обнаружения инцидента, а не с момента, когда всё стало понятно.
• Хранение паролей в логах, отладочных выгрузках и открытых бакетах с резервными копиями. Утечка приходит оттуда чаще, чем из взлома основной базы.
• Отсутствие плана восстановления. Проверенный регламент и заранее написанные шаблоны уведомлений экономят часы, которых в инциденте нет.