Средняя
Содержание
Недавно мы прочитали статью Ideco об использовании ИИ-агента для анализа межсетевого экрана.
Тема для нас не абстрактная. Мы занимаемся системой управления сетевыми политиками и сами постоянно думаем, где искусственный интеллект действительно может помочь инженеру, а где за красивым диалоговым интерфейсом всё равно должен находиться обычный, довольно сложный расчёт.
Авторы собрали полноценный стенд: агент получил доступ к API тестового шлюза, специализированные навыки для анализа и возможность самостоятельно запрашивать необходимые данные.
Проверяли два сценария.
В первом агент разбирал события безопасности: IPS, DNS, DPI, активные сессии. Он группировал события, выделял подозрительные хосты, проверял первоначальные гипотезы и формировал план расследования.
Во втором анализировал правила межсетевого экрана. Нашёл отсутствие явного запрещающего правила, проблемы с логированием, дублирующиеся и перекрываемые правила. При этом в одном случае неправильно понял взаимодействие глобальных и локальных настроек логирования.
Последнее, кстати, не обесценивает эксперимент. Наоборот, хорошо показывает реальное состояние технологии: агент уже способен провести полезный аудит, но его выводы пока нельзя без проверки превращать в изменения на боевом устройстве.
После прочтения у нас возник простой вопрос: где заканчивается такой ИИ-помощник и начинается NSPM?
Что агент действительно умеет?
Начнём с того, что анализ одной конфигурации — вполне рабочий сценарий для ИИ.
Межсетевые экраны за годы эксплуатации обрастают правилами, объектами и исключениями. Комментарии заполнены не везде. Названия групп не всегда помогают понять их содержимое. Причину появления старого правила иногда никто уже не помнит.
Здесь агент может быть полезен почти сразу.
Например, инженер задаёт вопрос:
Почему это правило считается опасным?
Агент раскрывает группы, смотрит источники, назначения и сервисы, проверяет соседние правила и объясняет:
Правило разрешает доступ из пользовательской сети ко всему серверному сегменту по любым TCP-портам. При этом за последние 90 дней фактически использовались только TCP/443 и TCP/8443 к четырём адресам.
Даже если итоговое решение всё равно принимает человек, такой ответ сильно экономит время.
То же самое относится к поиску очевидных проблем:
- правил any — any;
- правил без логирования;
- дублей;
- затенённых правил;
- широких диапазонов адресов;
- разрешений на административные сервисы из недоверенных зон;
- правил, которые давно не срабатывали.
Традиционный анализатор обычно показывает факт нарушения. ИИ может добавить объяснение: почему это важно, что стоит проверить и как примерно может выглядеть исправление.
На наш взгляд, именно здесь находится одна из сильнейших сторон ИИ. Не в том, что он заменяет существующие алгоритмы анализа, а в том, что он делает их результат понятнее.
Но правило — это ещё не доступ
На пилотах нас редко спрашивают:
Есть ли на этом межсетевом экране широкое правило?
Обычно вопрос звучит иначе:
Можно ли его удалить и что после этого сломается?
И вот здесь анализ одной конфигурации заканчивается.
Представим, что агент нашёл правило:
Source: 10.0.0.0/8
Destination: 172.16.0.0/12
Service: Any
Action: Allow
Оно выглядит плохо. Широкий источник, широкое назначение, любые сервисы.
Но какой реальный доступ создаёт это правило?
Через межсетевой экран может проходить только небольшая часть указанных сетей. До него трафик может быть уже ограничен другим устройством. После него может стоять ещё один МЭ. Между устройствами может использоваться NAT. Источник и назначение могут находиться в разных VRF. Обратный трафик может идти по другому маршруту.
Без этого контекста можно уверенно сказать только одно: правило выглядит широким.
Нельзя уверенно сказать, какой трафик действительно способен по нему пройти.
Для этого нужно собрать конфигурации всех устройств на пути, разобрать таблицы маршрутизации, зоны, NAT, виртуальные контексты, группы объектов и правила. Затем построить маршрут от источника к назначению и отдельно проверить обратный путь.
Это уже не задача языковой модели. Это задача сетевого движка.
ИИ может прочитать готовый маршрут и объяснить его. Но кто‑то должен сначала правильно этот маршрут вычислить.
Почему нельзя просто отдать модели все конфигурации?
На небольшом стенде это вполне можно сделать.
Берём два межсетевых экрана, маршрутизатор, несколько таблиц маршрутизации и просим модель определить, пройдёт ли трафик.
С высокой вероятностью она справится. Особенно если схема простая, а конфигурации короткие.
Но в промышленной сети речь может идти о сотнях устройств, тысячах виртуальных контекстов и сотнях тысяч правил. При этом рядом существуют разные вендоры, разные версии ПО и разные способы описания одних и тех же сущностей.
Для одного производителя объект может быть обычной группой адресов. Для другого — динамической группой. Для третьего правило зависит от зоны, пользователя или приложения. NAT тоже применяется по‑разному.
Языковая модель может рассуждать обо всём этом. Проблема в другом: результат должен быть воспроизводимым.
При проверке доступа недостаточно ответа: «Вероятно, трафик будет разрешён».
Нужно показать:
- через какие устройства он пройдёт;
- какой маршрут будет выбран;
- какие правила сработают;
- как изменятся адреса после NAT;
- где именно трафик будет заблокирован;
- существует ли обратный маршрут.
И при повторном запуске система должна дать тот же результат.
Поэтому парсинг конфигураций, расчёт маршрута, раскрытие групп, обработка NAT и выбор правил должны оставаться детерминированными. ИИ здесь лучше использовать не как калькулятор, а как интерфейс к результату расчёта.
Неиспользуемое правило — не обязательно ненужное
Возьмём ещё один понятный сценарий.
Агент видит, что правило не срабатывало 180 дней, и предлагает его удалить.
На первый взгляд всё логично. Но правило может использоваться только при аварийном переключении на резервный ЦОД. Или во время квартальных процедур. Или при подключении подрядчика несколько раз в год.
Даже если правило действительно не нужно, остаётся вопрос: что произойдёт после удаления?
Возможно, трафик начнёт попадать под другое, более широкое правило. Возможно, перестанет работать резервный сервис. Возможно, удаление не повлияет вообще ни на что.
Чтобы это проверить, нужно взять модель сети, исключить правило и повторно рассчитать доступы.
Агент способен сказать:
Правило похоже на кандидата на удаление.
NSPM должна ответить:
После его удаления исчезнут два доступа. Один из них используется только при переключении на резервный ЦОД.
Разница небольшая по форме, но огромная по ответственности.
Где ИИ особенно полезен внутри NSPM?
После эксперимента Ideco у нас не возникло ощущения, что ИИ конкурирует с NSPM. Скорее стало понятнее, как должен выглядеть следующий интерфейс таких систем.
Сегодня инженер обычно работает с таблицами, фильтрами, картой сети и результатами проверок. Это нормально, но требует понимания внутренней модели продукта.
ИИ позволяет задавать системе вопросы ближе к тому, как они возникают в реальной работе.
Например:
Почему доступ не работает?
NSPM рассчитывает маршрут и находит точку блокировки.
ИИ отвечает:
Прямой маршрут существует, но на втором межсетевом экране TCP/8443 блокируется правилом 186. Обратный маршрут корректен. Для открытия доступа нужно изменить правило 179 либо создать отдельное разрешающее правило перед блокирующим.
Другой вопрос:
Что изменилось за выходные?
NSPM сравнивает конфигурации и пересчитывает доступы.
ИИ собирает результат:
В трёх группах изменился состав объектов. В результате пять серверов получили новый доступ из сети подрядчиков. Два изменения связаны с заявками, одно было внесено напрямую на устройстве.
Или:
Можно ли удалить это правило?
NSPM выполняет моделирование.
ИИ формирует заключение:
Правило не использовалось 240 дней, перекрывается двумя другими правилами и не связано с активной заявкой. Моделирование не выявило потери известных доступов. Перед удалением его стоит отключить на контрольный период.
Здесь ИИ выполняет именно ту работу, в которой он силён: собирает контекст, объясняет результат и помогает человеку принять решение.
Но факты для такого ответа даёт NSPM.
Так агент или NSPM?
Если сильно упростить, разница получается такой.
ИИ-агент:
- Анализирует те данные, которые ему передали.
- Хорошо объясняет конфигурацию отдельного устройства.
- Находит подозрительные правила и события.
- Формирует гипотезы и рекомендации.
- Зависит от качества навыка и понимания конкретного вендора.
- Может ошибиться в интерпретации настроек.
- Не должен самостоятельно менять боевую политику.
NSPM:
- Собирает данные со множества устройств.
- Приводит конфигурации разных производителей к общей модели.
- Строит топологию сети.
- Рассчитывает прямой и обратный маршрут.
- Учитывает правила, NAT, VRF и виртуальные контексты.
- Хранит историю конфигураций и изменений.
- Моделирует последствия добавления, изменения или удаления правил.
- Даёт воспроизводимый результат, который можно проверить.
Поэтому ИИ-агент вряд ли заменит NSPM. Зато он вполне может заменить часть сложного интерфейса, часть ручного анализа и несколько часов работы инженера. И это, пожалуй, уже достаточно серьёзный результат.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
