Средняя
Управление сетевыми доступами давно перестало быть только задачей настройки правил на межсетевом экране. В крупных организациях это отдельный процесс на стыке ИТ, ИБ, compliance и управления изменениями.
В отраслевых обзорах решения класса Network Security Policy Management обычно описываются через несколько ключевых сценариев: управление firewall policy, сложные workflow изменения правил, compliance-аудит и работа с несколькими производителями межсетевых экранов. Такой подход подчёркивает, что речь идёт не просто об интерфейсе для инженера, а о платформе взаимодействия разных ролей вокруг сетевой политики.
G2 также описывает NSPM как класс решений для поддержания compliance и применения сетевых security/firewall management policies в организации. Поэтому вопрос «кто пользуется такой системой?» нельзя свести к одному подразделению. Ею пользуются все участники процесса, но каждый решает свою задачу: ИТ — корректное изменение, ИБ — контроль риска, compliance — доказательность и соответствие требованиям, владельцы систем — подтверждение бизнес-необходимости, Service Desk — фиксацию заявки и согласований, руководители — контроль качества процесса.
Содержание
Почему управление сетевыми доступами — это общий процесс?
Любое правило на межсетевом экране связано сразу с несколькими участниками:
- бизнес инициирует потребность;
- Service Desk фиксирует заявку и согласования;
- ИТ вносит изменение;
- ИБ оценивает риск;
- compliance контролирует соответствие требованиям;
- владелец системы подтверждает необходимость доступа;
- руководители контролируют качество процесса.
Если эти участники работают в разных системах и опираются на разные данные, появляются типовые проблемы: несогласованные правила, потерянные обоснования, избыточные доступы, просроченные временные разрешения и сложности на аудите.
Сетевая эксплуатация
Сетевая команда отвечает за техническую реализацию изменений на МЭ.
Основные задачи:
- определить путь трафика;
- найти целевые МЭ;
- проверить NAT, маршрутизацию, VRF и зоны;
- понять, есть ли уже существующее правило;
- выбрать корректное место в политике;
- применить изменение;
- проверить результат.
Для эксплуатации важны скорость и точность. При большом количестве заявок ручной анализ становится источником ошибок: можно выбрать не то устройство, открыть доступ шире требуемого, не учесть NAT или добавить правило в неверное место политики.
NSPM в этом сценарии помогает инженеру быстрее ответить на практический вопрос: что именно нужно изменить и где.
Информационная безопасность
ИБ отвечает за допустимость доступа с точки зрения политики безопасности.
Основные проверки:
- соответствие матрице сетевого доступа;
- отсутствие лишних связей между сегментами;
- запрет несанкционированных доступов test/dev → production;
- контроль доступов к критичным системам;
- отсутствие any-any и широких разрешений;
- наличие срока действия для временных правил;
- наличие владельца и бизнес-обоснования;
- отсутствие новых путей к уязвимым активам.
Для ИБ важно видеть не только новые заявки, но и фактическое состояние политики МЭ: какие доступы уже открыты, почему они существуют и когда их нужно пересмотреть.
NSPM здесь работает как инструмент контроля сетевой политики: показывает, где фактические правила расходятся с утверждённой моделью безопасности.
Compliance и аудит
Compliance-команды и внутренний аудит смотрят на сетевые доступы через призму доказательности.
Для них важно не только то, что правило технически настроено корректно, а то, что по нему можно восстановить полный контекст:
- зачем доступ был открыт;
- кто его запросил;
- кто согласовал;
- на основании какой заявки он появился;
- соответствует ли доступ внутренней политике;
- не нарушает ли он требования регулятора или стандарта;
- был ли доступ временным;
- пересматривался ли он;
- когда и кем правило изменялось.
В финансовых организациях, промышленности, телекоме и других регулируемых отраслях это особенно важно. На аудите недостаточно сказать: «правило настроено». Нужно показать связку: требование → заявка → согласование → фактическая конфигурация → история изменений → результат проверки.
NSPM помогает compliance не собирать доказательства вручную из Service Desk, конфигураций МЭ, Excel-таблиц и писем, а получать отчёты по фактическому состоянию сетевых политик: нарушения матриц доступа, изменения без заявок, просроченные временные доступы, правила без владельца, широкие разрешения и отклонения от baseline.
Руководители ИБ и ИТ
Руководителям нужны не отдельные правила, а показатели процесса.
Им важны:
- количество изменений за период;
- доля изменений без заявки;
- количество отклонений от политики;
- число просроченных временных доступов;
- количество правил без владельца;
- динамика рисковых правил;
- сегменты с наибольшим числом нарушений;
- нагрузка на команды эксплуатации, ИБ и compliance.
Эти метрики показывают, управляется ли процесс или держится на ручном контроле отдельных сотрудников.
Если растёт число несогласованных изменений, просроченных временных доступов или широких правил, это сигнал не только о технической проблеме, но и о сбое в процессе управления доступами.
Владельцы бизнес-систем
Владельцы систем не настраивают МЭ, но подтверждают бизнес-смысл доступа.
Их основная роль — ответить на вопрос:
Этот доступ всё ещё нужен бизнес-процессу или его можно закрыть?
ИТ видит техническую реализацию. ИБ видит риск. Compliance видит требование к обоснованию и регулярному пересмотру. Но только владелец системы может подтвердить, нужен ли конкретный доступ приложению, используется ли он в текущем бизнес-процессе и что произойдёт, если его закрыть.
Владельцы бизнес-систем участвуют в нескольких сценариях:
- согласование новых доступов;
- подтверждение необходимости существующих правил;
- регулярная ревизия доступов;
- определение критичности системы;
- согласование исключений;
- принятие остаточного риска;
- подтверждение вывода старых доступов из эксплуатации.
Без этой роли сложно качественно проводить recertification и удалять устаревшие правила.
Service Desk
Service Desk фиксирует формальную сторону процесса.
В заявке обычно содержатся:
- инициатор;
- бизнес-обоснование;
- источник и назначение;
- порт и протокол;
- срок действия;
- согласующие;
- исполнитель;
- статус;
- история выполнения.
Но Service Desk сам по себе не подтверждает, что именно было сделано на МЭ. Возможны расхождения:
| Ситуация | Значение |
|---|---|
| Есть заявка, есть совпадающее правило | Изменение подтверждено |
| Есть заявка, но правило шире | Требуется проверка |
| Есть правило, но нет заявки | Возможное несогласованное изменение |
| Заявка закрыта, но правила нет | Изменение не применено или применено неверно |
| Временный доступ не удалён | Риск просроченного доступа |
Поэтому заявки нужно связывать с фактической конфигурацией МЭ. Только так можно доказать, что согласованный доступ и реально внесённое изменение совпадают.
Зачем нужна единая площадка?
Единая площадка связывает несколько уровней данных:
- заявку;
- согласование;
- бизнес-обоснование;
- сетевой маршрут;
- целевые МЭ;
- фактические правила;
- NAT и маршрутизацию;
- матрицу доступа;
- требования compliance;
- срок действия;
- историю изменений;
- результат проверки.
Это позволяет всем участникам работать с одной картиной.
- Сетевая эксплуатация видит, что и где нужно изменить.
- ИБ видит, допустимо ли изменение.
- Compliance видит, есть ли доказательная база и соответствие требованиям.
- Владелец системы подтверждает необходимость доступа.
- Service Desk хранит формальное основание.
- Руководители получают метрики процесса.
Роль NSPM
NSPM выступает связующим слоем между Service Desk, сетевой инфраструктурой и системами ИБ.
Он получает данные из:
- межсетевых экранов;
- маршрутизаторов и L3-инфраструктуры;
- Service Desk;
- IPAM;
- CMDB;
- сканеров уязвимостей;
- SIEM и журналов событий;
- источников compliance-требований и внутренних политик.
На основе этих данных система:
- определяет путь трафика;
- показывает затронутые устройства;
- анализирует правила, NAT и маршруты;
- проверяет соответствие матрицам доступа;
- сопоставляет изменения с заявками;
- выявляет широкие и несогласованные правила;
- учитывает критичность систем;
- хранит историю изменений;
- проверяет результат после применения;
- формирует отчёты для ИБ, эксплуатации, compliance и аудита.
Так NSPM становится общей технической основой процесса: ИТ использует её для изменений, ИБ — для контроля рисков, compliance — для подтверждения соответствия требованиям, Service Desk — для связи заявки с фактическим результатом, руководители — для оценки качества процесса.
Вывод
Управление сетевыми доступами требует участия ИТ, ИБ, compliance, владельцев систем и Service Desk. Если процесс не связан в единую модель, появляются несогласованные правила, избыточные доступы, потерянные обоснования и слабая доказательная база для аудита.
Единая площадка позволяет связать заявку, сетевую конфигурацию, бизнес-смысл, риск и требования compliance. В результате изменения на МЭ становятся управляемым процессом, а не набором ручных действий, зависящих от памяти и опыта отдельных инженеров.
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro











