Межсетевой экран — священная корова корпоративной безопасности. Многие до сих пор уверены: поставил файрвол — и можно спать спокойно. На практике же даже самый современный NGFW с полным набором «умных» функций — это лишь первая, но далеко не решающая линия обороны. С подробностями — Никита Новиков, эксперт по кибербезопасности Angara Security.
Файрвол контролирует границу сети: фильтрует трафик, скрывает внутренние сервисы, блокирует несанкционированный доступ извне. Это критически важный щит, но он оставляет без ответа главный вопрос, который встаёт сразу после первичной компрометации: что злоумышленник сможет сделать уже внутри?
Получив доступ, атака перетекает во внутреннюю среду. Злоумышленник начинает исследовать инфраструктуру и готовиться к дальнейшему продвижению: собирает учётные данные, сканирует узлы, изучает структуру домена, ищет системы резервного копирования, средства администрирования и общие сетевые ресурсы. Полученная информация позволяет выполнять латеральное перемещение между системами, используя внутренние сетевые протоколы и сервисы (SMB, RDP, WinRM, WMI, SSH и другие). Именно этот горизонтальный (East-West) трафик становится основным каналом развития атаки.
И вот здесь-то у большинства компаний зияет слепая зона.
Периметр и граница доверия: архитектура, которая не работает
Классическая модель безопасности строилась на жёстком разделении:
-
внешняя сеть - недоверенная;
-
внутренняя — условно доверенная.
На стыке ставили файрвол, дополняли его VPN, IDS/IPS, WAF, прокси и почтовыми шлюзами.
Проблема в том, что эта модель безнадёжно устарела. Сегодня внутри «доверенной» инфраструктуры соседствуют рабочие станции, физические и виртуальные серверы, облачные сегменты, технологические сети, системы резервирования, инструменты администрирования, подрядчики, удалёнщики, сервисные аккаунты и устаревшие приложения.
Часть систем живёт в локальном ЦОД, часть — в облаке, часть завязана на внешние интеграции. При этом внутренние связности зачастую избыточны: рабочие станции видят друг друга, серверные сегменты открыты шире необходимого, административные протоколы доступны из посторонних VLAN, сервисные учётные записи используются вне своих систем, а контроллеры домена и бэкапы можно достать из сегментов, в которых им делать нечего.
В такой архитектуре компрометация даже одного узла с высокой вероятностью выльется в инцидент доменного уровня.
Внутренняя сеть — это не подсети, а граф достижимости
Для сетевого инженера инфраструктура — это маршруты, VLAN и ACL. Для атакующего — это граф.
Вершины графа: хосты, серверы, DC, базы, файловые ресурсы, гипервизоры, системы бэкапа, средства управления и учётные записи.
Рёбра: сетевые соединения, доступные порты, права администрирования, доверительные отношения, сервисные аккаунты, расшаренные папки, векторы удалённого выполнения команд, сохранённые пароли и межсервисные зависимости.
Чем больше лишних рёбер, тем больше путей для латерального перемещения.
Если рабочая станция может стучаться по SMB, RDP или WinRM к другим рабочим станциям — это готовый маршрут для распространения. Если пользовательский сегмент имеет доступ к админ-протоколам серверов — это дорога к критичным системам. Если сервер приложения видит больше баз данных, чем требуется для его работы, — это избыточная связность. Если бэкапная система доступна из широкого набора сегментов, она автоматически попадает в зону риска при атаке с шифрованием.
Парадокс в том, что многие организации даже не представляют, какие из существующих связей действительно нужны, а какие смертельный балласт.
VLAN не решает проблему сегментации
Есть заблуждение: инфраструктура сегментирована с точки зрения безопасности, если создана виртуальная локальная сеть и организована маршрутизация между подсетями. Часто это только техническое разделение адресного пространства.
Настоящая сегментация должна строиться на принципе минимально необходимой связности, а не на грубом разделении «серверы отдельно, пользователи отдельно». Система должна иметь доступ ровно к тем ресурсам, которые требуются для её бизнес-функции.
Сервер приложения должен ходить только к своей базе на строго определённый порт. Остальные БД в том же сегменте не должны быть для него видны. Рабочая станция администратора должна подключаться через выделенный узел управления, а прямой RDP рядовых сотрудников в серверный сегмент — быть закрыт наглухо. Бэкапная система — забирать данные с защищаемых хостов, но управление ею со стороны этих хостов должно быть запрещено.
Широкие правила типа «сеть А ходит в сеть Б» создают избыточный доступ. Для эксплуатации это удобно. Для безопасности это будущий маршрут атаки.
Что остаётся за кадром
Межсетевой экран на периметре фиксирует входящий и исходящий трафики. Но он не даёт целостной картины того, что творится между внутренними узлами.
Для контроля горизонтальных перемещений требуются совсем другие данные: сетевые потоки, логи внутренних файрволов, DNS, DHCP, события Active Directory, телеметрия EDR, точная инвентаризация активов, данные о сервисных учётных записях, владельцах систем и уязвимостях.
Сам по себе сетевой поток лишь факт соединения. Событие домена говорит об учётной записи. EDR описывает процесс, инвентаризация — роль хоста и его критичность, сканер уязвимостей — степень опасности источника.
Разрозненно эти сведения мало что дают. Но в связке они позволяют ответить на главный вопрос: является ли конкретное внутреннее соединение штатным поведением или это отклонение от нормы?
Например, RDP-подключение к серверу само по себе может быть легальным действием. Но если рабочая станция пользователя впервые за 60 дней подключается по RDP к серверу бухгалтерии, источник находится вне административной зоны, а учётная запись никогда не использовалась для управления этим сервером, это уже серьёзный повод для расследования.
SIEM видит события, но теряет контекст нарушения
SIEM-системы тоннами обрабатывают события. Но в чистом виде лента событий лишена смыслового контекста. Отдельный логин, сетевое соединение или запуск процесса почти никогда не дают достаточной информации.
Возьмём событие Windows 4624. Само по себе оно фиксирует лишь факт входа. Но если скрестить его с данными о сетевом потоке, процессе, типе учётной записи и разрешённой модели взаимодействий, всплывёт совсем другая картина: сервисный аккаунт зашёл на неразрешённый узел, после чего этот узел дёрнул файловый сервер. Единичное событие входа превращается в индикатор горизонтального перемещения.
Именно поэтому для мониторинга внутренних атак решающую роль играют не только корреляционные правила, но и полноценный контекст: какие хосты могут взаимодействовать, какие протоколы разрешены, где и какие учётные записи легитимны, какие системы критичны и появилась ли та или иная связь впервые.
Микросегментация: начинать надо не с блокировок, а с карты
Микросегментация выглядит идеальным лекарством от избыточной связности. Но начинать внедрение стоит не с запрещающих правил, а с глубокого анализа существующих взаимодействий.
Сначала нужно восстановить фактическую карту трафика. Проектная схема сети почти всегда расходится с реальностью. В инфраструктуре неизбежно остаются старые интеграции, временные маршруты, регламентные задания, открытые порты, ручные админ-процедуры и мониторинговые исключения.
Если попытаться включить блокировки без этого анализа, можно с высокой вероятностью уронить бизнес-сервисы.
Правильная последовательность выглядит так: собрать реальные внутренние потоки, обогатить их данными о хостах, учётных записях, процессах и владельцах, определить критичные зоны, построить карту связей, отрепетировать политики в режиме наблюдения и только затем переходить к режиму блокировки. Иначе микросегментация превращается в ручное управление исключениями, а не в архитектуру безопасности.
Что такое контроль горизонтального трафика на практике
Контроль горизонтального трафика (East-West visibility & control) — это системный подход к управлению внутренними сетевыми связями, объединяющий данные, политики, мониторинг и процессы реагирования. Его цель — жёстко ограничить зону поражения при компрометации любого отдельного узла.
Этот контроль должен давать ответы на конкретные вопросы:
-
Какие узлы с кем и как взаимодействуют внутри сети?
-
Какие соединения действительно нужны бизнес-сервисам, а какие бесхозные?
-
Какие протоколы используются для администрирования и кем?
-
Есть ли у рядовых рабочих станций доступ в серверные сегменты?
-
Кто вообще может подключаться к контроллерам домена и бэкапным системам?
-
Какие новые связи появились за последнюю неделю или месяц?
-
Сколько маршрутов ведёт из пользовательской сети к критичным активам?
В идеале каждая значимая внутренняя связь должна быть описана через источник, назначение, протокол, учётную запись, владельца и бизнес-назначение.
Недостаточно знать:
10.10.24.15 -> 10.10.70.8:445
Нужно понимать:
Источник: сервер CRM
Назначение: файловый сервер CRM
Протокол: SMB
Учётная запись: svc_crm_files
Смысл: выгрузка отчётов
Владелец: команда CRM
Контроль: журналирование, запрет интерактивного логина для сервисной учётной записи.
Если связь невозможно описать подобным образом, она автоматически уходит в разряд «подозрительных». Это может быть легитимная зависимость, технический долг, пережиток старой интеграции или прямой признак атаки.
С чего начать прямо сейчас
Начинать надо с зон, компрометация которых гарантированно приведёт к катастрофическим последствиям: контроллеры домена, узлы администрирования, PAM-системы, jump-серверы, бэкапные хранилища, гипервизоры, базы данных, файловые серверы, средства ИБ, репозитории кода, хранилища секретов, платёжные и учётные системы.
Для каждой такой зоны нужно выяснить, кто к ней подключается, откуда, по каким протоколам, под какими учётками и через какие точки контроля.
Быстрый выигрыш дают несколько жёстких, но очевидных ограничений:
-
Запретить SMB/RDP/WinRM между рабочими станциями.
-
Административный доступ к серверам — только через выделенные хосты управления.
-
Доступ к контроллерам домена максимально сузить.
-
Бэкапные системы изолировать на уровне сетевых политик.
-
Сервисные учётные записи строго привязать к конкретным задачам и запретить им интерактивный вход.
Эти меры не заменяют полноценную микросегментацию, но они моментально перекрывают большинство «туристических» маршрутов для злоумышленника.
Вместо заключения
Межсетевой экран на периметре остаётся критически важным элементом. Но он бессилен против того, что происходит после первого взлома. Внутри инфраструктуры судьбу безопасности решают внутренние маршруты: к учётным данным, контроллерам домена, файловым ресурсам, бэкапам, системам виртуализации, инструментам управления и ключевым приложениям.
Чтобы управлять этим риском, необходимо видеть не просто факт сетевого соединения, а его полный контекст: источник, назначение, протокол, учётную запись, процесс, владельца, критичность и историю.
Контроль горизонтального трафика закрывает пропасть между защитой периметра и реальной картиной внутренней связности. Он показывает, куда именно может пойти злоумышленник после закрепления на границе, какие пути для него уже открыты и что следует ограничить в первую очередь.
Без карты связей микросегментация превращается в хаос ручных правил, а с ней становится точным инструментом снижения зоны поражения и реального ограничения латерального перемещения.
Если у вас остаются вопросы, обратитесь к нам, разберем конкретные ситуации.
21.07.2026
