Сегментация раньше экрана: перестройка сети компании под PT NGFW

Эта статья посвящена тому, что происходит на неделю раньше внедрения: когда экран уже куплен, но выясняется, что ставить его пока некуда.

Мы, «МЕРСИС ГРУПП», ИТ‑интегратор, среди прочего занимаемся информационной безопасностью. Когда решили собрать собственный демо‑стенд для показа клиентам живой работы NGFW, быстро выяснилось, что демонстрировать, по сути, нечего. Внутренняя инфраструктура компании – около 20 активов: рабочие станции, пара серверов, тестовые машины – жила одной плоской L2‑сетью без какого-либо деления. Устройство можно подключить физически, но продемонстрировать что-либо, кроме факта включения, сложно: зонной политике не на чем строиться, если у вас одна зона.

Прежде чем разворачивать PT NGFW, мы полностью пересобрали сетевую часть. Дальше – что для этого сделали, в каком порядке и что оказалось сложнее, чем выглядело на этапе планирования.

Почему начали с сегментации

В нашем проекте контроль строился через зоны и политики между ними: учитывались принадлежность источника и назначения, приложение, пользователь. Без внутренних границ управляющий контур, рабочие станции, лаборатория и прод‑сервисы оставались в общем пространстве. Обмен внутри одного L2‑домена проходил напрямую и мог вообще не попадать на экран.

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

С чего начали: инвентаризация и разметка активов

Первым шагом провели полную инвентаризацию с указанием роли каждого узла и требуемого уровня доверия к нему. Для 20 объектов это звучит тривиально, но на практике заняло больше времени, чем ожидалось. Разложили оборудование по группам:

управляющий контур: консоли коммутатора, будущего экрана, доступ администраторов;
серверная часть: внутренние сервисы компании;
лаборатория: оборудование, на котором клиентам показывают атаки и защиту от них;
корпоративные рабочие места;
гостевой Wi‑Fi.

Логика простая: группы с разным уровнем доверия и профилем риска не должны жить в одном broadcast‑домене, даже при небольшом масштабе. Лаборатория – отдельная история: здесь намеренно запускаются вредоносные образцы и симулируются атаки. Её изоляция должна исключать доступ к рабочей инфраструктуре при инциденте на стенде.

Схема VLAN

Под каждую группу выделили VLAN с собственной адресацией и явным описанием разрешённых соединений. По умолчанию обмен запрещён, дальше – только точечные исключения.

На этом этапе пришлось несколько раз пересматривать схему: часть узлов, которые на бумаге казались однозначно «серверными», участвовала в демо‑сценариях. Их перенесли в лабораторию, чтобы отделить защищаемый периметр от полигона для атак.

Почему пришлось менять коммутатор

Старый коммутатор компании был неуправляемым L2‑устройством. С плоской топологией он справлялся, однако для нового проекта не подходил по двум причинам:

отсутствие поддержки 802.1Q trunk и невозможность передать несколько VLAN через один физический порт в сторону будущего шлюза;
недостаточная производительность для сценария, где межсегментный обмен идёт через экран: нагрузка на аплинк ощутимо выросла по сравнению с исходной схемой.

Заменили его на управляемую модель с поддержкой достаточного числа виртуальных сетей и trunk‑портов. Пропускную способность выбрали с запасом под ожидаемую нагрузку.

Место PT NGFW в топологии

PT NGFW встал на границе между VLAN как L3‑шлюз с субинтерфейсами на каждый VLAN ID, получая от коммутатора один trunk‑порт вместо пяти физических линков. Для нашего масштаба это экономичная схема: отдельные кабели не нужны, маршрутизация и политики сосредоточены на одном устройстве.

По зонам развели группы, определённые при инвентаризации, и добавили внешнее интернет‑подключение. Настроили default deny: разрешено только то, что явно прописано правилом. В первую очередь описали, откуда можно инициировать соединение и к каким ресурсам. Например, офисным рабочим местам доступен строго определённый набор внутренних сервисов. Из лаборатории пути к прод‑среде нет.

Модель лицензирования и класс оборудования выбирали под фактическую нагрузку. Для 20 активов рассматривали младшие модели линейки: по опубликованным характеристикам вендора, начальные варианты рассчитаны на пропускную способность порядка 1–4 Gbps в режиме L4 FW с контролем приложений. Для нашего внутреннего обмена этого хватает с запасом.

При этом платформа управления заявлена для организаций другого масштаба – до 100 000 устройств под одной консолью. Для нас это дополнительный аргумент: продукт и логика администрирования могут развиваться вместе с инфраструктурой при переходе от демо‑стенда к enterprise‑периметру.

TLS‑инспекция: что включили не сразу

Полную расшифровку TLS на старте намеренно не включали. Распространение корневого сертификата по всему парку – отдельная задача с проверкой совместимости. Выполнять её одновременно с изменением топологии означало бы совмещать два независимых источника рисков в одном окне.

Сначала ограничились политиками уровня приложений и портов без вскрытия содержимого сессий. Инспекцию включили точечно в лаборатории, где она нужна для показа атак, после проверки стабильности базового разделения и маршрутизации.

Где мы наступили на грабли

Некоторые задачи заняли больше времени, чем закладывали в план:

Окно отключения оказалось длиннее расчётного. Перенос даже 20 узлов на новую адресацию требует подготовки: часть оборудования использовала статические IP без учёта будущей схемы. Настройки пришлось исправлять вручную уже после переключения.
Не вся периферия корректно работала с тегированными кадрами. Нескольким устройствам потребовался отдельный access‑порт либо замена.
Подготовка правил заняла больше времени, чем техническое разделение. Разметить VLAN можно за несколько дней. Выяснить, какие соединения нужны бизнесу и какие сохранились по историческим причинам, сложнее. Для этого потребовалось наблюдать за реальным обменом уже после включения шлюза.
Лицензирование нужно сверять заранее. Расчёт пропускной способности должен учитывать рост стенда и числа демонстрационных сценариев, помимо сегодняшних 20 активов.

Что это дало на практике

Главный результат – лаборатория изолирована от рабочей среды техническими правилами. Теперь можно разворачивать вредоносные образцы и показывать клиентам детекцию в специально выделенном контуре.

Второй эффект – появилась наблюдаемость: межсегментные соединения видны и логируются. В прежнем L2‑домене они проходили напрямую, минуя выбранную точку контроля.

Для нас как белорусского интегратора важен и регуляторный контекст. Осенью 2025 года несколько моделей PT NGFW прошли сертификацию в Республике Беларусь на соответствие ТР 2013/027/BY в Оперативно‑аналитическом центре при Президенте Республики Беларусь. Это позволяет рассматривать решение для заказчиков, которым законодательство предписывает использовать сертифицированные средства межсетевого экранирования.

Что сделали бы иначе, если начинать заново

Если бы запускали проект сейчас, заранее выделили бы больше времени на изучение необходимых соединений. Именно эта работа оказалась узким местом. Техническая настройка интерфейсов потребовала меньше усилий.

Адресный план также заложили бы с резервом под будущие группы. Как только появляются внутренние границы, обнаруживаются ещё два-три типа обмена, которые хочется контролировать отдельно.

Для компании, у которой 20 активов выглядят слишком скромным масштабом для сегментации, наш опыт даёт повод пересмотреть подход. Раннее разделение небольшой инфраструктуры упрощает её дальнейшее расширение. Переносить границы в растущем хозяйстве значительно труднее: приходится согласовывать изменения с большим числом сотрудников и учитывать зависимости между уже работающими сервисами.