RECOVERED и VERIFIED
Разграничение, при котором сервис, снова отвечающий на запросы после инцидента, считается только "восстановленным", тогда как статус "проверено" требует дополнительно независимых проверок файлов, служб и сети, подтверждающих, что причина инцидента реально устранена.
Почему это различие пропускают под давлением
Как только сервис снова начинает отвечать нормально, немедленное давление восстановить бизнес-процессы обычно перевешивает более медленную, тщательную работу по подтверждению того, что реальная первопричина найдена и устранена, а не просто что симптом исчез.
Что на самом деле включает проверка
Проверка целостности файлов относительно известного исходного состояния, подтверждение отсутствия оставленных неавторизованных учётных записей или запланированных задач, и анализ логов на конкретный механизм, позволивший инциденту произойти, а не предположение, что перезапуск или восстановление из бэкапа всё исправили.
Часто задаваемые вопросы
Сколько обычно занимает переход от recovered к verified?
Значительно зависит от сложности инцидента, но спешка на этом шаге лишает его смысла; проверка должна занимать столько времени, сколько реально требует нормальное расследование первопричины.
Может ли сервис быть verified без того, чтобы быть полностью recovered?
Не по существу, так как проверка подтверждает исправление за работающим, восстановленным состоянием; должно быть что-то функционирующее, чтобы это проверять.
Почему это различие важно именно для владельца бизнеса, а не только для технической команды?
Потому что "сайт снова работает" и "мы знаем, почему это произошло, и это не повторится тем же способом" — это очень разные уровни уверенности, и только второй реально предотвращает повторный инцидент.
Хотите увидеть, в каком состоянии ваш сервер?
Запустите бесплатную read-only проверку сервера или откройте Security Lab и посмотрите цикл обнаружение, сдерживание, восстановление, проверка в действии.
Получить бесплатную проверку сервераОткрыть Security Lab