Взлом сайта: план реагирования на инцидент
Практический порядок действий при подозрении на взлом: оценка ситуации, ограничение ущерба, сохранение доказательств, коммуникации, восстановление и разбор причин.
Признак компрометации — не повод немедленно удалять файлы, переустанавливать сервер или объявлять проблему решённой. Нужны ответственный, журнал решений и согласованный порядок действий: подтвердить событие, остановить развитие инцидента, сохранить данные для анализа и только затем безопасно восстанавливать сервис.
1. Подтвердите признаки и назначьте ответственных
Сначала нужно понять, что именно произошло и кто принимает решения.
- Зафиксируйте время обнаружения, источник сигнала, затронутые адреса, сервисы, учётные записи и заметные симптомы.
- Определите руководителя инцидента и ответственных за анализ, инфраструктуру, коммуникации и принятие решения об остановке.
- Отделите подтверждённые факты от предположений; оцените критичные бизнес-функции и возможность утечки или изменения данных.
- Создайте защищённый журнал решений: когда, кто, что увидел и какое действие разрешил; исключите обсуждение инцидента в потенциально скомпрометированной почте.
2. Ограничьте ущерб и распространение
Действуйте пропорционально риску, сохраняя необходимые следы для анализа.
- По согласованию с ответственным ограничьте подозрительные учётные записи, сетевые соединения и уязвимые операции; при необходимости изолируйте затронутый компонент.
- Зафиксируйте, что должно остаться доступным для сотрудников и клиентов, и когда требуется временная страница обслуживания.
- Не удаляйте поспешно вредоносные файлы, не очищайте журналы и не перезапускайте системы до оценки необходимости сохранения доказательств.
- Если подозреваются скомпрометированные ключи, готовьте их отзыв и замену с доверенного устройства или независимого канала, чтобы не раскрыть новые секреты.
3. Сохраните доказательства и установите границы
Цель — понять причину и масштаб, не уничтожив данные о происшествии.
- Сохраните журналы веб-сервера, приложения, авторизации, CDN/WAF, DNS и облачных действий в защищённом хранилище, где доступ ограничен.
- При необходимости специалист фиксирует состояние дисков и памяти до устранения угрозы; записывает даты, контрольные суммы, владельцев копий и цепочку передачи.
- Проверяйте дополнительные сайты, общие ключи, базы, почтовые ящики, задания автоматизации и подрядные доступы, если они связаны с затронутым контуром.
- Собирайте только данные, необходимые для расследования: не пересылайте пароли, дампы с персональными данными и секреты через открытые чаты.
4. Решите, кого и когда уведомлять
Связь должна быть проверенной, последовательной и не вредить расследованию.
- Определите круг заинтересованных сторон: владелец бизнеса, техкоманда, хостинг, поставщики интеграций, клиенты и партнёры.
- Отдельно оцените, есть ли обязанность уведомлять регулятора, затронутых лиц, контрагентов или правоохранительные органы по применимому праву и договорам; сроки проверяйте индивидуально.
- Подготовьте краткий статус: что подтверждено, какой сервис затронут, что временно недоступно и когда будет следующее обновление — без недоказанных причин и обещаний.
- Для критичных коммуникаций используйте независимый от скомпрометированной системы канал; сохраните хронологию отправленных сообщений.
5. Устраните причину и восстановите сервис
Возвращение сайта возможно после проверки чистоты окружения и контрольных сценариев.
- Установите первопричину настолько, насколько позволяют доказательства, и устраните её: уязвимость, лишний доступ, настройку или компрометированный ключ.
- Если требуется, восстановите из проверенных копий в чистом окружении; не возвращайте подозрительные файлы и секреты из скомпрометированного экземпляра.
- Проверьте авторизацию, целостность страниц и данных, формы и заявки, интеграции, почту, права пользователей и критичные бизнес-операции.
- Контролируйте показатели и журналы после запуска, назначьте ответственного за наблюдение и критерии повторной изоляции при новых признаках атаки.
6. Закройте инцидент и обновите защиту
Инцидент считается разобранным, когда изменения проверены, а не только сайт снова открылся.
- Сведите в единый отчёт хронологию, подтверждённые причины, масштаб, потерянные или изменённые данные, время простоя и стоимость восстановления, если она известна.
- Отделите временные меры от постоянных: исправления конфигураций, MFA, контроль ролей, сегментация, мониторинг, резервные копии и порядок обновлений.
- Назначьте ответственных, сроки, критерии повторной проверки и владельца каждой открытой задачи.
- Проведите короткое учебное упражнение по обновлённому плану, пересмотрите контакты и порядок решений, зафиксируйте следующие улучшения.
- NIST SP 800-61 Rev. 3 — Incident Response Recommendations, 2025
- NCSC — Incident management: plan response processes
- FTC — Cybersecurity for Small Business
Редакционный материал, октябрь 2026 года. Конкретные параметры и применимость рекомендаций определяются риском, договором и требованиями к вашей системе.