1«Мы уже проверялись» — почему это про прошлое
Отчёт об аудите — это фотография: честная, полезная, но датированная. Он фиксирует состояние сайта и окружения на день проверки. Уже через неделю часть фактов устаревает: обновились зависимости, выкатился релиз, сменилась конфигурация сервера. Через полгода отчёт описывает, по сути, другой сайт.
При этом атакующая сторона работает непрерывно: автоматические сканеры перебирают домены круглосуточно, и между публикацией новой уязвимости и её массовой эксплуатацией проходят не месяцы, а часто дни или часы. Разовая проверка против непрерывного процесса — заведомо неравная партия.
2Откуда берутся дыры на сайте, который никто не трогал
Интуиция говорит: «мы ничего не меняли — значит, ничего не сломалось». С безопасностью эта логика не работает, потому что меняется мир вокруг сайта:
- Новые CVE: уязвимости в CMS, плагинах и библиотеках публикуются ежедневно. Версия, которая вчера считалась безопасной, сегодня попадает в бюллетени — а у вас она стоит.
- Тихие изменения инфраструктуры: подрядчик поправил DNS, хостер перенёс сервер, «временное» правило в конфигурации осталось навсегда — и открыло то, что было закрыто.
- Истечение сроков: TLS-сертификаты, домены, ключи интеграций имеют срок жизни. Истёкший сертификат — это и недоверие браузеров, и сигнал всем, что за сайтом не следят.
- Новые поддомены и сервисы: маркетинг поднял лендинг, разработчик — тестовый стенд с копией базы. Периметр вырос, а в последнем аудите этих активов не было.
- Дрейф почтовых записей: подключили новый сервис рассылок — SPF/DKIM/DMARC перестали соответствовать реальности, и письма поехали в спам.
3Как устроен непрерывный мониторинг
Механика проста: те же проверки, что в аудите, выполняются регулярно и автоматически — по расписанию, без участия человека. Сканируется то, что можно проверять безопасно и ненавязчиво: TLS и сроки сертификатов, security-заголовки, флаги cookie, CORS, DNS-записи почты, доступность нежелательных файлов.
Ключевой элемент — не сам скан, а сравнение с прошлым состоянием. Каждый прогон сопоставляется с предыдущим: что появилось нового, что исчезло, что изменилось. Именно дифф превращает поток отчётов в сигнал: «на сайте появилась критичная находка, которой не было вчера» — это событие, требующее внимания. «Всё как вчера» — это тишина, которая не должна дёргать команду.
4Алерты, которые не превращаются в шум
Главный враг любого мониторинга — усталость от уведомлений. Если система пишет по каждому прогону «вот вам 30 находок» (тех же, что вчера), через две недели её сообщения перестают читать — и настоящий инцидент тонет в привычном шуме. Поэтому зрелый мониторинг присылает алерт только о новых находках высокой критичности, а рутинные отчёты складывает туда, где их посмотрят по желанию.
Второй практический момент — канал доставки. Алерт должен приходить туда, где команда живёт: в наш модуль мониторинга мы сделали уведомления в кабинете плюс сообщение в рабочий Telegram-чат — потому что письмо «проверьте панель безопасности» проигрывает мессенджеру по скорости реакции в разы. Критичная находка в пятницу вечером должна догнать ответственного, а не ждать понедельника в непрочитанной почте.
5Мониторинг не заменяет аудит — они работают в паре
Честная граница возможностей: мониторинг отслеживает известные классы проблем на известном периметре. Он не проведёт глубокое исследование логики приложения, не найдёт уязвимость в вашем уникальном коде, не проверит то, о чём не знает. Поэтому стартовая точка — полный аудит: он устанавливает базовую линию и закрывает накопившееся. Мониторинг дальше удерживает это состояние и ловит новое. Что входит в полный аудит, мы разбирали в отдельной статье.
Хорошо ложится в ту же логику и сопровождение по SLA: мониторинг обнаруживает проблему, а договор на поддержку гарантирует, что её кто-то чинит в оговорённый срок. Обнаружение без исправления — это просто более информированное беспокойство; ценность появляется, когда цикл замкнут.