Как я выстраиваю первую реакцию на утечку ПДн

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

Почему ручная реакция теряет время

Когда сотрудник замечает необычную выгрузку, вход администратора или жалобу клиента, это ещё не доказывает, что данные уже утекли. Но и объявлять сигнал «ложным» до проверки нельзя. Я начинаю с короткой записи: кто и когда заметил событие, в какой системе, что именно выглядит необычно и кто уже что сделал. Затем определяю координатора, чтобы техническая проверка, работа с персональными данными и разговор с руководителем шли по одному плану. Если такой порядок надо поставить с нуля, мы в «АйТи-Фреш» занимаемся подготовкой плана реагирования. В тревоге хочется сразу выбрать одну причину, но у инцидента их может быть несколько. Поэтому я отделяю наблюдение от вывода: «было много чтений» — наблюдение, «база украдена» — пока гипотеза.

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

• Записать время обнаружения и наблюдаемые признаки
• Назначить координатора и ответственного за журнал
• Сохранить относящиеся к событию записи

Какие действия готовить заранее

Я не начинаю план безопасности со сложной системы оповещений. Сначала определяю, кто вправе принимать решения и у кого есть нужные данные. В небольшом бизнесе в рабочую группу обычно входят руководитель, IT-специалист, ответственный за организацию обработки персональных данных и юрист; при необходимости подключается специалист по коммуникациям. Роль важнее должности: один человек координирует шаги и журнал, технический специалист проверяет системы и сохраняет данные, ответственный за персональные данные оценивает затронутые наборы, юрист сверяет требования и формулировки. Руководитель решает, допустима ли остановка сервиса и кто согласует внешние сообщения. Такой состав не делает группу непогрешимой, зато убирает опасный режим, когда каждый действует отдельно и никто не знает, кто уже менял настройки.

После распределения ролей автоматизирую то, что безопасно автоматизировать: сбор сигналов, уведомление дежурных, создание карточки инцидента, сохранение записей в хранилище с ограниченным доступом и напоминание о сроках. В карточке отмечаются время, источник, ответственный, предпринятое действие и результат. Система может обнаружить нетипичную активность или сообщить о ней, но сама по себе она не знает, нарушены ли права субъектов, какие данные затронуты и можно ли отключить конкретный сервис без остановки бизнеса. Поэтому массовую блокировку, отзыв активных сессий и смену паролей я привязываю к заранее одобренным условиям и проверке человеком. Для отдельного сценария компрометации почты пригодится разбор взломанного почтового ящика. Автоматическая кнопка «отключить всё» работает быстро; объяснять потом, почему остановились продажи, приходится людям.

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

• Сигнал и карточка инцидента
• Копия журналов с ограниченным доступом
• Решение об изоляции с ответственным

Как выглядит разбор на условном примере

ООО «Жасмин-Логистик» указано в задании как условный пример, поэтому я не выдаю его за реального клиента или завершённый проект. Представим учебную ситуацию: мониторинг отмечает нетипичное чтение записей в прикладной системе, а сотрудник сообщает о подозрительном письме с вложением. Это два сигнала, но пока неизвестны ни причина, ни число затронутых людей. Координатор открывает запись об инциденте, указывает время обнаружения и источники информации, назначает технического исполнителя и связывает его с руководителем, ответственным за персональные данные и юристом. В журнале остаются не только действия, но и решения, включая объяснение, почему ограничили доступ именно к одной учётной записи, а не остановили всю работу.

Технический специалист сохраняет доступные журналы и проверяет связанные входы, операции и изменения прав, не очищая систему ради быстрого отчёта. Команда оценивает, продолжается ли подозрительная активность, какие сервисы связаны с ней и есть ли риск для других учётных записей. Если нужно ограничить доступ, руководитель или назначенный заместитель принимает решение с учётом ущерба от простоя; администратор выполняет его и записывает результат. Затем ответственный за персональные данные и юрист проверяют, подпадает ли событие под обязанность уведомить Роскомнадзор и что уже можно сообщить без догадок. Если при проверке обнаружен вымогатель или шифрование, отдельно пригодится порядок действий при шифровальщике в офисе. В этом примере я не обещаю заранее, когда завершится расследование: срок зависит от объёма данных и доступности журналов.

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

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

• Разделить наблюдения и предположения
• Зафиксировать решения, исполнителей и результат
• Проверить масштаб до широких уведомлений

Какие сроки уведомления нужно знать

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

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

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

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

• 24 часа — первичное уведомление
• 72 часа — результаты расследования
• Основание — условие части 3.1 статьи 21

Что делать, если автоматизации нет

Полная автоматизация не обязательна, чтобы перестать действовать наугад. Подготовьте одностраничный регламент и держите его в месте, доступном ответственным при отказе основной системы. В нём укажите координатора и заместителя, контакты тех, кто вправе ограничить доступ, перечень источников журналов, порядок сохранения копий, место для журнала действий и канал связи. Добавьте отдельную строку: кто оценивает, затронуты ли персональные данные, кто проверяет обязанность уведомления и кто подаёт его через портал. Пароли и секреты в этот документ не вписывайте; укажите, где их получить штатным способом. Такой минимум не заменяет расследование, но помогает не начинать с вопроса «а кто вообще за это отвечает?». План надо проверять после смены администратора, почтовой системы, базы или подрядчика: старый контакт на бумаге — это тоже вид отказа.

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

Внутреннее обсуждение после события — не поиск виноватого. Я разбираю, какой сигнал заметили, чего не хватило для проверки, где команда потеряла время и кто имел полномочия принять решение. Если причина была в настройке доступа, меняем доступ; если журнал не сохранился, исправляем хранение; если люди не знали роли, репетируем сценарий. В отчёт включаю факты, выводы, выполненные меры и действия с владельцами и сроками. Так организация получает конкретные улучшения, а не очередной документ с лозунгом «усилить безопасность». Личная ответственность важна, но обвинения без доказательств мешают понять системную причину и повышают шанс повторить тот же сбой.

Я и команда «АйТи-Фреш» поможем описать порядок реагирования, проверить доступность журналов, настроить уведомления и распределить роли, а затем разобрать сценарий с вашей командой. Если нужна постоянная техническая поддержка инфраструктуры, обслуживание сервера стоит от 7 000 ₽/мес.

• Регламент и резервные контакты
• Доступ к журналам и копиям
• Проверка плана после изменений

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