Средняя
Единая система управления сетевой безопасностью даёт организации общую картину: сетевые устройства, правила межсетевых экранов, маршруты, NAT, зоны, матрицы доступа, изменения и риски. Это удобно для ИТ, ИБ, compliance и руководителей.
Но у такой единой картины есть обратная сторона. Разные подразделения начинают работать с одними и теми же данными, но с разными целями. Одни отвечают за стабильность сети, другие — за поиск рисков и построение векторов атак. Одни вносят изменения, другие могут с ними не согласиться. Одни считают правило необходимым для работы сервиса, другие видят в нём путь для lateral movement.
Поэтому при внедрении NSPM-системы важно заранее определить не только роли в интерфейсе, но и организационную модель: кто за что отвечает, кто что может менять, кто согласует спорные решения и где проходит граница между эксплуатацией и аналитикой.
Содержание
- Где возникает конфликт интересов?
- Сначала организация, потом роли
- Операционное и аналитическое владение
- Разделить право видеть, анализировать и изменять
- Разделить фактическую модель и аналитические гипотезы
- Разделить справочники и политики
- Как разрешать спорные ситуации?
- Как это реализовать программно?
- Какой вариант выбрать?
- Вывод
Где возникает конфликт интересов?
Рассмотрим типовой пример.
Сетевая команда отвечает за работоспособность инфраструктуры. Для неё важны доступность сервисов, корректная маршрутизация, правильные правила МЭ, отсутствие простоев и управляемый процесс изменений.
Команда, которая занимается анализом векторов атак, смотрит на ту же сеть иначе. Для неё важны достижимость критичных активов, опасные связи между сегментами, избыточные доступы, возможность перемещения атакующего и несоответствие матрицам доступа.
Обе команды работают с одними и теми же данными, но делают разные выводы.
- Сетевики могут считать правило нормальным, потому что оно обеспечивает работу сервиса.
- ИБ-аналитики могут считать его опасным, потому что оно открывает путь к критичной системе.
- Владелец сервиса может настаивать, что доступ нужен бизнес-процессу.
- Compliance может спросить, почему у правила нет срока действия или согласованного исключения.
Если заранее не разделить полномочия, единая система быстро превращается в источник конфликтов: кто‑то изменил модель сети, другие не согласны; кто‑то нашёл риск, но эксплуатация не признаёт его критичным; кто‑то хочет закрыть доступ, но бизнес боится остановки сервиса.
Сначала организация, потом роли
Частая ошибка — начинать с технического разграничения: «дадим одним read-only, другим admin». Но роли в системе должны отражать уже согласованную организационную модель.
Сначала нужно ответить на несколько вопросов:
- кто владеет фактической моделью сети;
- кто отвечает за актуальность конфигураций;
- кто может подключать устройства;
- кто может менять зоны и матрицы доступа;
- кто может запускать анализ рисков;
- кто может создавать рекомендации;
- кто может вносить изменения на МЭ;
- кто подтверждает бизнес-необходимость доступа;
- кто принимает риск, если доступ нельзя закрыть.
Только после этого можно настраивать роли, tenant’ы, рабочие области или отдельные инсталляции.
Операционное и аналитическое владение
Первый принцип разделения — различать операционное и аналитическое владение.
Операционное владение
Это зона ответственности сетевой эксплуатации.
Сетевая команда отвечает за:
- подключение МЭ и сетевых устройств;
- сбор и актуальность конфигураций;
- корректность маршрутов, NAT и зон;
- внесение изменений;
- применение правил;
- доступность сервисов;
- rollback;
- разбор сетевых инцидентов;
- соответствие фактической модели реальной инфраструктуре.
Иными словами, всё, что влияет на production-конфигурацию и работоспособность сети, должно оставаться под контролем эксплуатации.
Аналитическое владение
Это зона ответственности ИБ-аналитики, команды attack path или подразделения, отвечающего за оценку рисков.
Они отвечают за:
- анализ достижимости критичных активов;
- построение векторов атак;
- выявление опасных связей между сегментами;
- проверку соответствия матрицам доступа;
- приоритизацию рисков;
- формирование рекомендаций;
- постановку задач на устранение отклонений;
- контроль статуса рисков.
Такая команда должна иметь доступ к сетевой модели и результатам анализа, но не должна напрямую менять production-политику без согласованного процесса.
Ключевой принцип можно сформулировать так:
Сетевая эксплуатация управляет изменениями. ИБ-аналитика управляет интерпретацией риска.
Это не исключает совместной работы. Наоборот, оно делает её более понятной: одна команда отвечает за техническую корректность и стабильность, другая — за оценку допустимости и рисков.
Разделить право видеть, анализировать и изменять
Доступ к системе не должен быть бинарным: «может всё» или «ничего не может». Лучше разделять три уровня полномочий.
Право видеть
Пользователь может просматривать устройства, правила, объекты, маршруты, топологию, зоны, результаты анализа и отчёты.
Право анализировать
Пользователь может запускать проверки, моделировать трафик, строить векторы атак, создавать отчёты, анализировать нарушения матриц доступа и формировать рекомендации.
Право изменять
Пользователь может менять данные, которые влияют на production или общую модель: подключать устройства, менять зоны, редактировать матрицы доступа, создавать заявки на изменение МЭ, применять правила.
Для команды attack path обычно достаточно прав «видеть» и «анализировать», а также возможности создавать рекомендации или задачи на устранение. Для сетевой эксплуатации нужны права «изменять», но в рамках своей зоны ответственности.
Такое разделение снижает риск, что аналитическая гипотеза случайно повлияет на production-модель.
Разделить фактическую модель и аналитические гипотезы
Один из самых важных принципов — не смешивать фактическое состояние сети и аналитические сценарии.
Сетевая команда обычно хочет видеть одну достоверную production-модель: реальные устройства, реальные конфигурации, реальные маршруты, реальные правила.
Команде attack path часто нужны гипотезы:
- что будет, если считать этот сегмент критичным;
- что будет, если атакующий получил доступ к конкретному хосту;
- какие пути появятся при изменении веса риска;
- как выглядит сеть с точки зрения внешнего атакующего;
- какие маршруты ведут к критичным активам через промежуточные сегменты.
Если разрешить аналитикам менять общую модель, это быстро приведёт к конфликту. Сетевики будут считать, что модель искажена. Аналитики будут считать, что им мешают исследовать риски.
Решение — разделить два слоя:
Production-модель — фактическое состояние сети. За неё отвечает сетевая эксплуатация.
Аналитические сценарии — отдельные рабочие области, песочницы или слои анализа. В них ИБ может строить гипотезы, не влияя на production-модель.
Такая модель позволяет использовать единую базу фактических данных, но не смешивать эксплуатационную ответственность и риск-аналитику.
Разделить справочники и политики
Некоторые сущности влияют сразу на несколько подразделений. Их нельзя отдавать одной команде без процедуры согласования.
К таким сущностям относятся:
- зоны безопасности;
- матрицы сетевого доступа;
- критичность активов;
- группы сегментов;
- бизнес-сервисы;
- профили риска;
- правила compliance;
- asset ownership;
- исключения из политик.
Для них стоит определить владельцев и согласующих.
| Объект | Основной владелец | Согласующие |
|---|---|---|
| Устройства, конфигурации, маршруты | Сетевая эксплуатация | ИБ при необходимости |
| Зоны безопасности | ИБ-архитектура | Сетевая эксплуатация |
| Матрицы доступа | ИБ | Владельцы систем, ИТ |
| Критичность активов | Владельцы систем / ИБ | ИТ |
| Векторы атак | ИБ / attack path | Сетевая эксплуатация как консультант |
| Изменения МЭ | Сетевая эксплуатация | ИБ / Service Desk |
| Рекомендации по снижению риска | ИБ | Сетевая эксплуатация, владельцы систем |
| Исключения из политик | Владелец риска / ИБ | Бизнес-владелец, ИТ |
Такое разделение показывает, что в единой системе нет одного абсолютного владельца всех данных. Есть разные зоны ответственности.
Как разрешать спорные ситуации?
Конфликты всё равно будут. Например, ИБ считает доступ между сегментами опасным, а сетевая команда говорит, что он нужен для работы сервиса.
Для таких случаев нужен понятный процесс.
Возможная схема:
- ИБ фиксирует риск в системе.
- Сетевая эксплуатация подтверждает фактическую реализацию доступа.
- Владелец системы подтверждает или опровергает бизнес-необходимость.
- Если доступ нужен, оформляется исключение с владельцем, сроком и обоснованием.
- Если доступ не нужен, создаётся заявка на закрытие.
- Если стороны не согласны, вопрос передаётся на уровень владельца риска, CISO или профильного комитета.
Важно, чтобы система хранила статус решения:
- новый риск;
- подтверждён;
- ложное срабатывание;
- принят в риск;
- требуется изменение;
- заявка создана;
- исправлено;
- исключение действует до указанной даты.
Такой процесс переводит спор из режима личных договорённостей в управляемый жизненный цикл риска.
Как это реализовать программно?
После определения организационной модели можно выбирать технический вариант разделения.
Вариант 1. Разделение ролями в одной инсталляции
Это самый простой вариант.
В системе остаётся одна модель сети и одна база данных, но пользователи получают разные роли и права.
Сетевая эксплуатация может подключать устройства, собирать конфигурации, анализировать маршруты, создавать и применять изменения.
Команда attack path может просматривать топологию, запускать анализ достижимости, строить векторы атак, создавать рекомендации и отчёты, но не может менять production-конфигурации.
Руководители и аудиторы получают доступ к отчётам и метрикам.
Плюсы:
- быстро внедряется;
- сохраняется единая модель данных;
- нет дублирования инфраструктуры;
- все участники работают с одной картиной.
Минусы:
- изоляция ограничена ролевой моделью;
- сложнее разделить спорные справочники;
- ошибки в правах могут дать лишний доступ;
- подразделения могут психологически воспринимать систему как «общую территорию».
Такой процесс переводит спор из режима личных договорённостей в управляемый жизненный цикл риска.
Вариант 2. Одна инсталляция с аналитическими рабочими областями
Это более зрелый вариант.
Фактическая production-модель остаётся единой, но поверх неё создаются отдельные аналитические пространства.
Сетевая эксплуатация работает с реальными устройствами, конфигурациями и изменениями.
Команда attack path работает в своём аналитическом контуре: строит сценарии, задаёт entry points, меняет веса рисков, моделирует компрометацию активов, формирует отчёты.
При этом аналитические сценарии не изменяют фактическую модель сети.
Плюсы:
- сохраняется единая база достоверных данных;
- ИБ может свободно анализировать риски;
- сетевая эксплуатация сохраняет контроль над production;
- меньше дублирования данных;
- проще сравнивать выводы разных команд.
Минусы:
- сложнее реализовать;
- нужна поддержка сценариев, версий или слоёв анализа;
- нужно чётко определить, какие сущности общие, а какие локальные.
Для разделения сетевой эксплуатации и команды attack path это наиболее сбалансированный целевой вариант.
Вариант 3. Мультитенантность внутри одной инсталляции
В этом варианте внутри одной системы создаются логически изолированные организации или tenant“ы.
Например:
- tenant для сетевой эксплуатации;
- tenant для команды attack path;
- tenant для отдельного департамента или дочерней организации.
Здесь возможны два подхода.
Первый — полная изоляция данных. Каждый tenant видит только свои устройства и результаты. Это хорошо для безопасности, но может ухудшить анализ, если команде attack path нужна общая картина сети.
Второй — общий read-only слой инфраструктуры и отдельные tenant“ы для аналитики, отчётов и настроек. Фактические данные собираются один раз, но результаты анализа и рабочие процессы разделяются.
Плюсы:
- сильнее административная изоляция;
- можно независимо настраивать процессы;
- проще показать заказчику разделение между департаментами;
- меньше конфликтов за роли и интерфейсы.
Минусы:
- сложнее архитектура;
- нужно проектировать общие и локальные справочники;
- возможны дублирование и расхождение данных;
- сложнее строить единую отчётность.
Мультитенантность подходит, если заказчику важно формально разделить подразделения, но при этом сохранить одну платформу.
Вариант 4. Две независимые инсталляции
Самый жёсткий вариант — развернуть две независимые системы.
Сетевая эксплуатация работает в своей инсталляции. Команда attack path — в своей. Данные либо собираются независимо, либо передаются из одной системы в другую.
Плюсы:
- максимальная изоляция;
- минимальный риск пересечения прав;
- проще организационно объяснить разделение;
- каждое подразделение управляет своим контуром.
Минусы:
- дублирование данных и интеграций;
- выше стоимость владения;
- риск расхождения моделей;
- сложнее синхронизировать изменения;
- теряется единая картина сети;
- интеграционные споры не исчезают, а переходят на уровень обмена данными.
Этот вариант стоит рассматривать только при жёстких требованиях к независимости подразделений или при невозможности договориться о совместной модели работы.
Какой вариант выбрать?
На практике удобно предлагать заказчику несколько уровней зрелости.
Стартовый уровень — разделение ролями.
Подходит для быстрого запуска. Одна система, одна модель сети, разные права для сетевой эксплуатации, ИБ-аналитики, руководителей и аудиторов.
Целевой уровень — аналитические рабочие области.
Фактическая модель сети остаётся единой, но команда attack path получает отдельное пространство для гипотез, сценариев и отчётов. Это снижает конфликт и сохраняет общую картину.
Усиленная изоляция — мультитенантность.
Подходит, если нужно формально разделить департаменты, но сохранить единую платформу и контролируемый общий слой данных.
Полная изоляция — независимые инсталляции.
Подходит только для случаев, когда подразделения не могут работать в общей системе или требования безопасности прямо запрещают совместную инсталляцию.
Вывод
Единая система управления сетевой безопасностью повышает прозрачность, но одновременно создаёт организационные конфликты. Разные подразделения работают с одними и теми же данными, но отвечают за разные результаты: сетевая эксплуатация — за стабильность и изменения, ИБ — за риски и векторы атак, владельцы систем — за бизнес-необходимость, compliance — за доказательность контроля.
Решать такие конфликты нужно не только ролями в интерфейсе. Сначала требуется договориться о модели ответственности: кто владеет фактической сетью, кто анализирует риски, кто может менять production, кто согласует исключения и кто принимает остаточный риск.
Программно это можно реализовывать поэтапно: от ролевой модели до аналитических рабочих областей, мультитенантности или независимых инсталляций.
Оптимальная целевая модель для большинства случаев — единая фактическая модель сети, контроль изменений у сетевой эксплуатации и отдельное аналитическое пространство для ИБ. Так организация сохраняет общую картину инфраструктуры, но снижает риск конфликтов между подразделениями.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
