Security-мониторинг доступа к изолированному сегменту: единый лог-коллектор, анализатор без зависимостей и алерты в мессенджер

Клиент работал на легаси-системе, развёрнутой на облачной площадке заказчика. Сменился подрядчик — и появилась задача, которой раньше никто не закрывал: видеть попытки несанкционированного доступа к чувствительному сегменту и разделить зоны ответственности, чтобы новый подрядчик не имел доступа к изолированным данным. Мы собрали единый лог-коллектор, лёгкий анализатор на стандартной библиотеке (ноль внешних зависимостей), классификацию событий по категориям угроз и двухуровневые алерты в мессенджер. Калибровкой белого списка убрали порядка 99% шума и получили боевой детектор, который показывает реальный сигнал, а не фон.

Что было «до»

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

Боли, которые проявились после смены подрядчика:

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

Архитектура решения

Целевая схема — пассивный сбор логов в единую точку, анализ и доставка алертов:

Ключевые решения:

• Единый коллектор. События со всех прод-хостов уносятся в одну точку по стандартному протоколу логирования. Это убирает «обход по хостам руками» — вся картина в одном месте.
• Анализатор без внешних зависимостей. Парсер и классификатор написаны на стандартной библиотеке языка. Ноль сторонних пакетов = ноль рисков цепочки поставок для инструмента, который обрабатывает самые чувствительные данные инфраструктуры. Бонус — тривиальный аудит и развёртывание без менеджера пакетов.
• Классификация по категориям угроз. Каждое событие маппится в одну из категорий (см. ниже). Это превращает поток сырых строк в осмысленную картину: «что именно происходит с периметром».
• Два уровня алертов. Критичное — немедленно, фон — в дайджест. Разделение спасает канал от превращения в шум.

Категории угроз

Анализатор раскладывает события по классам — каждый со своей сигнатурой в логах:

Категоризация — ядро ценности. Сырой лог — это шум; категория — это ответ на вопрос «нас сейчас ломают или просто фоновый интернет-шум стучится в закрытую дверь».

Два уровня алертов: критичное немедленно, фон — в дайджест

Главная ошибка наивного мониторинга — слать в мессенджер каждое подозрительное событие. Через день канал превращается в нечитаемую ленту, и команда его мьютит. Это худший возможный исход: система формально работает, фактически — слепа.

Мы разделили поток на два уровня:

• Немедленные алерты — события, требующие реакции здесь и сейчас: активная атака на шлюз, признаки нарушения изоляции сегмента, всплеск подбора с одного источника. Уходят в канал моментально.
• Агрегированный дайджест — массовый фон: одиночные сканы, отбитые файрволом одиночные попытки, известный интернет-шум. Собирается и отправляется периодически одним сообщением.

Эвристика приоритизации звука: критичное должно будить, фон — информировать. Если перепутать — либо проспишь атаку в потоке шума, либо выгоришь от ложных тревог.

Принципы внедрения

Это работа на живом проде клиента — поэтому дисциплина важнее скорости.

1. Лог-тейлинг с правильной семантикой (seek-to-end)

Анализатор читает логи в режиме «хвоста» — обрабатывает только новые события с момента старта (seek-to-end), а не перечитывает весь исторический файл. Без этого первый запуск выгрузил бы в канал всю историю накопленных событий разом — мгновенный шторм алертов. Семантика «с этого момента вперёд» — обязательное условие.

2. Калибровка белого списка — чтобы не тонуть в ложных

Изначально детектор реагирует на всё подозрительное. Но львиная доля потока — легитимный фон: служебные проверки, известные сканеры поисковых систем, внутренние health-check’и. Мы итеративно вносили такие паттерны в whitelist и наблюдали, как падает поток ложных срабатываний.

Результат калибровки — порядка 99% событий отфильтровано. То, что осталось, — это реальный сигнал. Без этого шага детектор технически работает, но практически бесполезен: настоящая атака тонет в фоне.

3. Полная обратимость изменений

• Бэкап конфигураций до любых правок. Откат — это вернуть файл из бэкапа, а не «вспоминать, как было».
• Поэтапный rollout. Сначала коллектор, потом анализатор, потом — боевые алерты. Каждый этап проверяется отдельно.
• Dry-run перед боевыми алертами. Сначала детектируем и логируем, но не шлём в канал. Смотрим, что детектор ловит и не сыпет ли ложными. Только убедившись — включаем доставку.

4. Прод-периметр трогаем минимально

Сбор логов пассивен — он не меняет правила файрвола, не вмешивается в трафик, не добавляет точек отказа на пути прод-запросов. Мониторинг наблюдает, но не управляет. Это принципиально: система безопасности не должна сама становиться риском для доступности прода.

Что получилось

• Боевой детектор несанкционированного доступа. Попытки подбора, сканы, веб-атаки и нарушения изоляции сегмента видны в реальном времени.
• Видимость периметра. Вся картина — в одном канале, без обхода хостов руками.
• Отфильтрованный сигнал. Калибровка убрала порядка 99% шума — в канале остаётся то, что важно.
• Разделение ответственности доказуемо. Нарушение границы изолированного сегмента детектируется как отдельная категория — граница между контурами подрядчиков перестала быть «на честном слове».
• Доказательная база. События классифицированы и сохранены — есть с чем работать при разборе инцидента.

Похожая задача с видимостью периметра? Мы делаем аудит безопасности инфраструктуры и внедрение мониторинга доступа — от разбора текущих логов до боевого детектора с алертами. Обсудить.

Границы применимости

Честно о том, чем это решение не является:

• Это не полноценный SIEM. Лёгкий анализатор покрывает конкретные категории угроз для конкретного периметра. Если нужна корреляция событий из десятков источников, ретеншн на месяцы и ролевой доступ аналитиков — смотрите в сторону полноценных SIEM-платформ.
• Это не замена harden’ингу. Мониторинг показывает попытки, но не закрывает дыры. Он дополняет правильную конфигурацию файрвола, fail2ban и сетевой изоляции, а не заменяет их.
• Качество детекта = качество калибровки. Без вложения времени в whitelist детектор либо шумит, либо пропускает. Это не «поставил и забыл», а инструмент, который живёт вместе с периметром.

FAQ

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

Базовый рабочий контур: централизованный сбор логов со всех прод-хостов (события файрвола, SSH, веб-сервера), анализатор который классифицирует события по категориям угроз, и доставка алертов в канал, который команда реально читает. Анализатор лучше строить на стандартной библиотеке языка без внешних зависимостей — это снижает риски цепочки поставок и упрощает аудит. Критичные события идут немедленно, фоновый шум — в агрегированный дайджест.

Как обнаружить несанкционированный доступ к данным?

Нужно видеть характерные паттерны: подбор паролей по SSH (множество отказов аутентификации с одного источника), сканирование периметра (последовательные обращения к закрытым портам), веб-атаки (SQL-инъекции и XSS в параметрах запросов), попытки обойти изоляцию сетевого сегмента (трафик между хостами, которые по политике не должны общаться). Каждый класс детектируется по своей сигнатуре в логах файрвола, SSH и веб-сервера. Главное — централизовать сбор, иначе картина собирается вручную по разным хостам.

Зачем разделять алерты на два уровня?

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

Почему анализатор без внешних зависимостей безопаснее?

Каждая внешняя библиотека — это потенциальный вектор атаки через цепочку поставок: скомпрометированный пакет или транзитивная зависимость может утечь логи или открыть доступ. Инструмент мониторинга безопасности обрабатывает самые чувствительные данные инфраструктуры, поэтому для него мы выбрали ноль внешних зависимостей — только стандартная библиотека. Это упрощает аудит кода и убирает целый класс рисков.

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

Калибровкой белого списка. Изначально детектор реагирует на всё подозрительное, но львиная доля — это легитимный фон: служебные проверки, известные сканеры поисковиков, внутренние health-check’и. Мы итеративно вносим такие паттерны в whitelist и наблюдаем, как падает поток. На нашем внедрении калибровка убрала порядка 99% событий, оставив реальный сигнал.

Можно ли внедрить такой мониторинг без риска для работающего прода?

Да, при условии полной обратимости. Мы делаем бэкап конфигураций до изменений, разворачиваем коллектор и анализатор поэтапно, прогоняем алерты в режиме dry-run (детектируем и логируем, но не шлём) до боевого включения, и минимально трогаем прод-периметр — сбор логов пассивен и не влияет на трафик. Любой шаг можно откатить.