Средняя
В крупной организации система защиты информации обычно состоит из набора взаимосвязанных решений: межсетевых экранов, SIEM, сканеров уязвимостей, Service Desk, CMDB, IPAM, NAC, PAM, EDR, средств управления конфигурациями, DLP, SOAR и других систем.
Каждая из них отвечает за свой слой. SIEM собирает события безопасности. Сканер уязвимостей выявляет слабые места на хостах и приложениях. Service Desk управляет заявками. CMDB хранит сведения об активах. IPAM содержит данные об адресном пространстве. Межсетевые экраны применяют политики доступа.
При этом между этими слоями часто остаётся разрыв: как фактическая сетевая связность соотносится с политикой безопасности, заявками, активами, уязвимостями и изменениями?
NSPM, Network Security Policy Management, закрывает этот разрыв. Его задача — не заменить существующие системы, а связать между собой сетевую топологию, правила доступа, конфигурации, изменения и требования безопасности.
Содержание
Роль NSPM в архитектуре ИБ
NSPM можно рассматривать как слой контроля сетевых политик. Он находится между системами, которые создают контекст, и системами, которые используют результат анализа. С одной стороны, NSPM получает данные из инфраструктуры и смежных систем:
- межсетевых экранов;
- маршрутизаторов и L3-коммутаторов;
- систем управления МЭ;
- IPAM;
- CMDB;
- Service Desk;
- сканеров уязвимостей;
- SIEM;
- каталогов пользователей;
- систем инвентаризации;
- источников бизнес-контекста.
С другой стороны, NSPM передаёт результаты анализа:
- командам ИБ;
- сетевой эксплуатации;
- Service Desk;
- SIEM/SOAR;
- аудиторам;
- владельцам систем;
- командам compliance;
- средствам отчётности.
Основная ценность NSPM — преобразование разрозненных технических данных в единую картину сетевого доступа: кто, куда, по каким правилам, через какие устройства и насколько это соответствует требованиям безопасности.
Источники данных для NSPM
Межсетевые экраны и системы управления МЭ
Основной источник данных для NSPM — межсетевые экраны и системы управления ими.
NSPM получает:
- правила фильтрации;
- NAT-правила;
- объекты и группы объектов;
- зоны безопасности;
- интерфейсы;
- маршруты;
- VPN-настройки;
- версии конфигураций;
- журналы изменений;
- hit count по правилам, если доступен;
- информацию о кластерах и виртуальных контекстах.
Эти данные позволяют понять не только, какие правила заданы в политике, но и как они влияют на прохождение трафика.
В корпоративной инфраструктуре часто используются решения нескольких производителей: Check Point, Palo Alto, Fortinet, Cisco, UserGate, Континент, PT NGFW и другие. NSPM приводит политики разных производителей к единой модели, чтобы ИБ и эксплуатация могли работать с общим представлением сетевого доступа.
Маршрутизаторы и L3-инфраструктура
Правила МЭ не дают полной картины без данных о маршрутизации. Чтобы понять, пройдёт ли трафик от источника к назначению, нужно учитывать сетевой путь.
NSPM получает с маршрутизаторов и L3-коммутаторов:
- таблицы маршрутизации;
- VRF;
- интерфейсы;
- подсети;
- статические и динамические маршруты;
- сведения о соседних устройствах;
- policy-based routing;
- данные о связях между устройствами.
На основе этих данных система строит модель сети и проверяет прохождение трафика от источника до назначения. Это особенно важно в распределённых инфраструктурах с несколькими ЦОДами, VRF, NAT, межсетевыми экранами и маршрутизаторами.
IPAM
IPAM помогает NSPM определить, что стоит за IP-адресами и подсетями.
Из IPAM можно получать:
- назначение подсети;
- владельца адресного пространства;
- принадлежность к площадке;
- тип сегмента;
- сведения о зарезервированных адресах;
- связь IP-адресов с хостами;
- DNS-имена;
- жизненный цикл адресов.
Без IPAM правило вида 10.45.16.0/24 → 10.80.20.15 tcp/443 остаётся набором технических параметров. С данными IPAM оно получает контекст: например, какой сегмент обращается к какому сервису и кому принадлежит адресное пространство.
Это важно для анализа рисков, аудита и согласования изменений.
CMDB
CMDB добавляет бизнес-контекст.
Из CMDB NSPM может получать:
- владельца системы;
- критичность актива;
- принадлежность к бизнес-сервису;
- среду эксплуатации: dev, test, stage, production;
- класс системы;
- регуляторный контур;
- связь с бизнес-процессами;
- статус эксплуатации.
Такой контекст помогает отличать стандартный технический доступ от доступа к критичному активу. Например, одно и то же правило может иметь разный уровень риска в зависимости от того, ведёт оно к тестовому серверу или к production-системе платёжного контура.
Service Desk
Service Desk является источником информации о том, какие изменения были запрошены и согласованы.
NSPM может получать из Service Desk:
- номер заявки;
- инициатора;
- согласующих;
- источник и назначение доступа;
- порт и протокол;
- срок действия;
- бизнес-обоснование;
- статус заявки;
- планируемое окно изменений;
- связанный инцидент или проект.
Это позволяет сопоставлять фактические изменения на МЭ с согласованными заявками. Если правило появилось без заявки, это повод для проверки. Если заявка требовала точечного доступа, а на МЭ открыли широкую подсеть, система может выявить расхождение.
В более зрелой модели Service Desk становится не только источником данных, но и каналом запуска процесса: заявка поступает в NSPM, система анализирует маршрут, оценивает риски, формирует изменение и возвращает результат выполнения.
Сканеры уязвимостей
Сканеры уязвимостей показывают, какие активы имеют технические слабые места. Но сами по себе они не всегда отвечают на вопрос, насколько уязвимость достижима по сети.
NSPM дополняет данные сканера сетевым контекстом:
- доступен ли уязвимый хост из недоверенных сегментов;
- есть ли путь из интернета;
- открыт ли нужный порт;
- через какие МЭ проходит доступ;
- есть ли компенсирующие ограничения;
- какие правила разрешают обращение к уязвимому сервису.
Так уязвимости можно приоритизировать не только по формальной критичности, но и по реальной сетевой экспозиции.
SIEM
SIEM собирает события безопасности, а NSPM может использовать их для обогащения модели.
Из SIEM или журналов МЭ можно получать:
- события изменений конфигураций;
- события администрирования;
- срабатывания правил;
- информацию о фактическом трафике;
- данные о подозрительных соединениях;
- подтверждение использования правил;
- события от сетевых устройств.
Где NSPM дополняет данные?
Ценность NSPM не ограничивается сбором конфигураций. Система связывает данные из разных источников и дополняет их сетевым контекстом.
Связывает IP-адреса с бизнес-смыслом
NSPM может связать IP-адрес с данными из IPAM, CMDB и Service Desk: к какому сегменту он относится, какая система за ним стоит, кто владелец, насколько она критична и есть ли согласованная заявка на доступ.
Преобразует правила в маршруты
Правило МЭ показывает только один участок пути. NSPM строит end-to-end картину: откуда идёт трафик, через какие устройства проходит, где разрешается, где блокируется и где применяется NAT.
Сопоставляет плановое и фактическое состояние
В заявке может быть указано одно, а в конфигурации реализовано другое. В матрице доступа может быть задан запрет test → production, а фактическая сеть может разрешать такой путь. NSPM помогает выявлять такие расхождения.
Сохраняет историю изменений
Для аудита и расследований важно не только текущее состояние, но и история: когда правило появилось, кто его изменил, по какой заявке, какие версии конфигурации были раньше и когда доступ перестал соответствовать политике.
Оценивает риск в контексте
Широкое правило на изолированном тестовом стенде и аналогичное правило на периметре банка имеют разный риск. NSPM учитывает положение правила в топологии, критичность сегментов, наличие уязвимостей и требования политик безопасности.
Куда NSPM передаёт данные?
В Service Desk
NSPM может возвращать в заявку:
- результат анализа;
- список затронутых МЭ;
- найденные риски;
- рекомендации по изменению;
- подтверждение применения;
- фактическое правило;
- результат проверки доступности;
- причину отказа или невозможности выполнения.
Это превращает заявку из текстового запроса в управляемый процесс изменения сетевого доступа.
В SIEM и SOAR
NSPM может передавать события:
- появилось правило без заявки;
- открыт доступ между запрещёнными сегментами;
- изменилось правило на критичном МЭ;
- обнаружено нарушение матрицы доступа;
- найдено правило any-any;
- просроченный временный доступ не закрыт;
- уязвимый актив доступен из недоверенной зоны.
SIEM получает не просто технический лог, а событие с контекстом: какие сегменты затронуты, какой риск, какое правило, какое устройство и какой бизнес-сервис связан с событием.
В отчётность и compliance
NSPM формирует отчёты для ИБ, эксплуатации и аудита:
- соответствие матрицам доступа;
- изменения за период;
- правила без заявок;
- рисковые правила;
- просроченные доступы;
- нарушения сегментации;
- доступы к критичным системам;
- состояние политик МЭ;
- соответствие внутренним стандартам.
Для организации это особенно важно: аудиторы обычно спрашивают не только о наличии политики, но и о том, как подтверждается её выполнение.
Владельцам систем
NSPM может помогать владельцам бизнес-сервисов понимать, какие сетевые доступы открыты к их системам.
Это полезно для регулярного пересмотра доступов: владелец подтверждает, какие доступы нужны, а какие можно закрыть.
Пример целевого процесса
Рассмотрим заявку на новый сетевой доступ.
1. Пользователь создаёт заявку в Service Desk.
2. Service Desk передаёт параметры в NSPM.
3. NSPM обогащает заявку данными из IPAM и CMDB.
4. Система определяет путь трафика и целевые МЭ.
5. Проверяет доступ по матрице безопасности.
6. Проверяет наличие уязвимостей у целевого актива.
7. Ищет существующие правила, которые уже покрывают запрос.
8. Формирует рекомендуемое изменение.
9. После согласования применяет изменение или передаёт команды инженеру.
10. Собирает конфигурацию после изменения.
11. Проверяет, что доступ открыт в согласованном объёме.
12. Возвращает результат в Service Desk и передаёт события в SIEM.
В этом сценарии NSPM не заменяет Service Desk, SIEM, IPAM или CMDB. Он связывает их данные вокруг конкретной задачи: безопасно изменить сетевой доступ.
Вывод
В корпоративном ландшафте информационной безопасности NSPM выполняет роль связующего слоя между сетевой инфраструктурой, системами ИБ и процессами эксплуатации.
Он получает данные от МЭ, маршрутизаторов, IPAM, CMDB, Service Desk, SIEM и сканеров уязвимостей. Затем обогащает их: строит модель сети, сопоставляет правила с заявками, связывает IP-адреса с бизнес-системами, проверяет матрицы доступа и оценивает риски в контексте.
На выходе NSPM передаёт результат в Service Desk, SIEM, SOAR, отчётность, аудит и команды эксплуатации.
Основная роль NSPM — показать, как сеть работает фактически: какие доступы разрешены, почему они существуют, кто их согласовал, где они нарушают политику и что нужно изменить. Для организации это превращает управление сетевой безопасностью из набора ручных проверок в системный и доказуемый процесс.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
