Сегментация сети часто выглядит убедительно на архитектурной схеме. Есть пользовательская сеть, серверный сегмент, DMZ, технологический контур, отдельные VLAN, межсетевые экраны и правила доступа.
Формально инфраструктура разделена.
Но в момент инцидента выясняется неприятное: злоумышленник или вредоносный процесс всё равно может пройти дальше. Из одной зоны в другую. Из тестового сегмента к продуктивному. Из пользовательской сети к серверу. Из подрядного доступа к внутреннему ресурсу.
Проблема не всегда в том, что сегментации нет. Чаще она есть — но только в проектной логике. На практике правила межсетевого экрана устарели, временные исключения не закрыты, сервисные порты открыты шире необходимого, административные доступы выданы слишком крупными мазками, а реальные маршруты трафика давно не сверялись с моделью угроз.
О том, почему сегментацию нужно проверять не по схеме, а по фактическим проходам между зонами, рассказывает Андрей Зюбровский, руководитель департамента технической поддержки Компании ВИЗАРД.
Почему сеть может быть разделена, но инцидент всё равно проходит дальше
На схеме всё может выглядеть корректно: контуры выделены, VLAN настроены, DMZ вынесена отдельно, критичные системы отделены от пользовательского сегмента. Но сегментация работает не на схеме. Она работает в правилах доступа, маршрутизации, сервисных портах, учётных записях и реальных сценариях эксплуатации.
«Основной риск формальной сегментации в том, что организация уверена: зоны разделены. Но фактически между ними могут оставаться разрешённые проходы, которые когда-то были нужны для проекта, миграции, настройки подрядчика или временного теста. Если эти исключения не пересматриваются, они становятся постоянной частью контура риска»,
Типовая ситуация: для внедрения системы открыли доступ из одной зоны в другую. Например, разрешили соединение к базе данных, сервисному API, административному интерфейсу или файловому ресурсу. Работы завершились, но правило осталось. Через год никто уже не помнит, зачем оно было создано, кто согласовал доступ и можно ли его закрыть.
В итоге сегментация существует, но не ограничивает распространение инцидента так, как ожидалось.
Где чаще всего ломается реальная сегментация
Одна из распространённых проблем — устаревшие правила межсетевых экранов. Правило когда-то было корректным, но система изменилась: сервер переехал, сервис закрыли, подрядчик завершил работы, бизнес-процесс перестроили. А правило осталось.
Вторая проблема — слишком широкие разрешения. Вместо точечного доступа между конкретными источниками и назначениями появляются правила уровня «сегмент к сегменту» или слишком широкие диапазоны адресов. В спокойной эксплуатации это удобно. В инциденте это превращается в коридор для lateral movement — перемещения внутри инфраструктуры.
Третья проблема — временные исключения без срока жизни. В ИТ нет ничего более постоянного, чем временное правило, если у него нет владельца, даты пересмотра и процедуры закрытия.
Четвёртая проблема — административные доступы. Если администрирование разрешено из слишком большого числа зон, а доступы подрядчиков не пересматриваются, сегментация теряет смысл. Особенно если используются общие учётные записи, старые VPN-доступы или постоянные права вместо временных.
Пятая проблема — открытые сервисные порты. RDP, SSH, SMB, базы данных, веб-интерфейсы, API и служебные протоколы часто остаются доступными шире, чем нужно для работы системы. Формально это может не выглядеть как авария. Но с точки зрения ИБ это увеличивает поверхность атаки. но административные порты могут оставаться открытыми из пользовательской сети.
Поэтому вопрос «есть ли у нас сегментация?» недостаточен.
Правильнее спрашивать так: какие соединения реально разрешены между зонами, зачем они нужны, кто их владелец, когда они пересматривались и что произойдёт, если одна из зон будет скомпрометирована?
Как проверить, что сегментация действительно работает
Проверка сегментации должна начинаться с ревизии правил межсетевых экранов и списков контроля доступа. Важно понять, какие правила активны, какие из них используются, какие устарели, где есть широкие разрешения и какие исключения не имеют владельца.
Следующий шаг — тестовые проходы между зонами. Недостаточно посмотреть настройки. Нужно проверить фактическую доступность: какие порты открыты, какие сервисы отвечают, откуда возможен административный доступ, какие маршруты проходят через межсетевые экраны.
Отдельно нужно проверять сервисные порты. Особенно RDP, SSH, SMB, базы данных, веб-панели управления, API и служебные интерфейсы. В идеале каждый открытый порт должен иметь понятное назначение, владельца и обоснование.
Важный блок — контроль административных доступов. Нужно оценить, кто и откуда может администрировать оборудование, серверы, виртуализацию, СХД, сетевые устройства и системы безопасности. Административный доступ должен быть ограничен, журналироваться и пересматриваться.
Также нужна проверка доступов подрядчиков. Внешние подключения, VPN, временные учётные записи и сервисные права должны иметь срок действия и понятный порядок отключения после завершения работ.
Не менее важны журналы событий. Если между зонами происходит подозрительная активность, её нужно видеть. Сегментация без журналирования затрудняет расследование: доступ может быть разрешён, но никто не понимает, кто, когда и зачем им пользовался.
И обязательно должны быть правила жизненного цикла исключений. Любое исключение должно иметь владельца, срок действия, причину, дату пересмотра и понятную процедуру закрытия. Иначе исключения постепенно превращаются в постоянные дыры в архитектуре.
Что важно зафиксировать
Сегментация сети — один из ключевых инструментов снижения рисков. Но она работает только тогда, когда соответствует реальной инфраструктуре.
Если зоны существуют только на схеме, а фактические правила доступа устарели, временные исключения живут годами, административные права слишком широкие, сервисные порты открыты без необходимости, инцидент может пройти между сегментами почти так же, как в неразделённой сети.
Проверять сегментацию нужно не по презентации и не по архитектурной схеме, а по фактическим маршрутам, правилам межсетевых экранов, доступным портам, административным правам, журналам событий и жизненному циклу исключений.
Сильная сегментация — это не просто VLAN, DMZ и красивые контуры на схеме. Это дисциплина управления доступами между зонами, регулярная ревизия и понимание, какие связи действительно нужны бизнесу, а какие давно пора закрыть.
