Средняя
Когда NSPM-система начинает не только анализировать политики межсетевых экранов, но и вносить изменения, возникает неприятный практический вопрос: а сам МЭ вообще готов к многопользовательской работе?
На первый взгляд кажется, что да. У большинства NGFW есть роли, администраторы, API, журналы аудита, иногда даже workflow и согласование изменений. Но если смотреть глубже, межсетевой экран — это не классическая многопользовательская бизнес-система, где сотни пользователей параллельно меняют разные сущности без влияния друг на друга.
Правила МЭ — это упорядоченная политика. Положение правила в списке, объекты, NAT, зоны, маршрутизация и порядок применения могут влиять на итоговый доступ. Поэтому параллельное внесение правил — это не просто «добавить строку в таблицу». Это операция над общей критичной конфигурацией.
Содержание
Проблема: сотни заявок в день
Представим крупную инфраструктуру: в день приходит 100–300 заявок на изменение сетевого доступа. Каждая заявка может требовать одного или нескольких правил, создания объектов, изменения групп, NAT, проверки маршрута и установки политики на одно или несколько устройств.
Для NSPM это выглядит как очередь задач:
- разобрать заявку;
- понять путь трафика;
- определить целевые МЭ;
- сгенерировать изменения;
- внести правила;
- применить конфигурацию;
- собрать конфиг обратно;
- убедиться, что изменение действительно применилось;
- проверить доступность;
- зафиксировать результат.
Главный риск здесь — не время создания одного правила. Само добавление через API часто занимает секунды. Узким местом становится применение изменений и последующая верификация.
Что значит «многопользовательский» для МЭ?
Для нас важны четыре признака.
Первый — поддержка параллельных административных сессий. Несколько пользователей или систем могут одновременно подключаться к платформе управления.
Второй — изоляция изменений. Один администратор может подготовить изменение, не смешивая его с изменениями другого.
Третий — безопасная публикация. Изменения проходят стадию проверки, затем атомарно применяются или отклоняются.
Четвёртый — понятная верификация. После применения можно быстро получить актуальную конфигурацию и доказать, что нужные правила появились именно там, где должны были появиться.
По этим признакам разные вендоры ведут себя по‑разному.
Palo Alto Networks
У Palo Alto сильная модель candidate configuration. Изменения сначала попадают в candidate config и начинают работать только после commit. При commit выполняется синтаксическая и семантическая проверка, а сами commit-операции ставятся в очередь и выполняются последовательно. Это хорошо для управляемости, но плохо для полностью параллельной записи: параллельные изменения всё равно сходятся в одну точку применения. Palo Alto прямо описывает, что изменения сначала записываются в candidate configuration, а активируются только после commit; также firewall и Panorama ставят commit-операции в очередь.
Практически это означает: добавить правило через API можно быстро, условно за секунды. Но commit может занять от десятков секунд до нескольких минут, особенно на крупных политиках или при использовании Panorama. Сбор конфигурации удобен: PAN-OS XML API позволяет получать конкретные части конфигурации по XPath, например rulebase security, а также экспортировать running config или версии конфигурации.
Вывод: Palo Alto хорошо подходит для пакетной модели — накопили изменения, провалидировали, сделали commit, затем собрали конфиг и проверили. Но сотни независимых commit в день лучше агрегировать, иначе очередь commit станет бутылочным горлышком.
Check Point
Check Point ближе всех к настоящей многопользовательской модели управления политиками. В R80+ есть сессии администратора: изменения можно подготовить, затем publish или discard. После публикации выполняется verify и install policy на выбранные gateway. Официальная документация описывает последовательность: publish session, verify access control policy, затем install policy.
Плюс у Check Point есть история установок политики: можно посмотреть, какие ревизии были установлены на gateway, кто их установил, какие изменения вошли, и при необходимости откатиться на «хорошую» версию.
Для NSPM это удобная модель: можно вести отдельную сессию на пакет изменений, публиковать её и устанавливать политику. Но install policy — всё равно тяжёлая операция. Она зависит от размера rulebase, количества gateway, management server и включённых blade“ов.
Ориентир такой: создание объектов и правил через API — секунды; publish — секунды или десятки секунд; install policy — от десятков секунд до нескольких минут. Сбор политики через API может быть дольше, потому что нужно выгружать rulebase, объекты, группы и связи между ними. В больших инсталляциях лучше использовать инкрементальную сверку и историю ревизий, а не каждый раз полностью пересобирать всю модель.
Вывод: Check Point хорошо готов к многопользовательскому управлению, но параллельность должна заканчиваться до стадии install policy.
Fortinet FortiGate / FortiManager
У Fortinet важно разделять прямое управление FortiGate и управление через FortiManager.
При прямом управлении FortiGate REST API позволяет настраивать систему, получать информацию и статистику; документация Fortinet делит REST API на Configuration API, Log API и Monitor API. Но прямой FortiGate хуже подходит для большого количества параллельных изменений: изменения политики могут сразу влиять на устройство, а при высокой нагрузке изменение firewall policy или маршрутизации может заметно повлиять на established sessions и CPU. Fortinet отдельно рекомендует планировать такие изменения на периоды низкой нагрузки.
FortiManager добавляет более взрослую модель. В workspace mode можно блокировать ADOM, device или policy package; при включённом workspace перед изменениями требуется lock. Установка policy package затем отправляет различия на FortiGate.
Ориентир: прямое добавление правила на FortiGate — секунды; backup config через REST API возможен, Fortinet описывает получение backup configuration file через HTTPS REST API. Но для промышленного потока заявок лучше работать через FortiManager: пакетировать изменения, использовать lock/workspace и устанавливать policy package пачками.
Вывод: FortiGate сам по себе не стоит воспринимать как удобную многопользовательскую систему изменений. FortiManager — да, но с блокировками и очередью установок.
PT NGFW, UserGate, Ideco
По российским NGFW публичной технической информации о транзакционности изменений и производительности API меньше, поэтому здесь важно не делать вид, что есть универсальная цифра.
PT NGFW имеет API: в документации Positive Technologies указано, что список доступных запросов можно смотреть на management system, а управление правилами выполняется на странице Policies. Для NSPM критично проверить в лаборатории: есть ли отдельная стадия publish/apply, как ведут себя параллельные API-запросы, можно ли получить job status и быстро выгрузить актуальную политику после изменения.
UserGate поддерживает ролевой доступ администраторов, а также имеет change tracker в общих настройках. Документация описывает, что change tracker можно включать и настраивать типы изменений. Это полезно для аудита, но не отвечает полностью на вопрос транзакционности. Нужно отдельно тестировать параллельное внесение правил через Management Center или API.
Ideco выглядит наиболее открыто с точки зрения API-документации: в документации есть API для управления правилами межсетевого экрана, включая добавление правила перед или после существующего. Поиск показывает отдельные разделы API по firewall rules и добавлению правил. Для NSPM это хороший признак: можно точно позиционировать правило относительно anchor rule. Но всё равно нужно проверить, как система ведёт себя при одновременных изменениях и сколько занимает применение на data plane.
Ориентир для PT NGFW, UserGate и Ideco лучше формировать только по стенду: 1 правило, 10 правил, 100 правил, параллельные заявки, HA, полный сбор конфига, инкрементальный сбор.
Практический вывод для NSPM
МЭ лучше считать не многопользовательской системой, а системой с единой критичной конфигурацией и ограниченной параллельностью.
Правильная архитектура для NSPM — не отправлять сотни изменений напрямую и параллельно. Лучше строить очередь:
- группировать заявки по устройству или policy package;
- проверять конфликты до внесения;
- использовать lock или session там, где они есть;
- применять изменения пакетами;
- после применения собирать конфиг или diff;
- сверять результат с ожидаемой моделью;
- хранить job id, ревизию и доказательство применения.
Время «внесения правила» обычно измеряется секундами. Время «сделать изменение безопасно» — это уже десятки секунд или минуты: commit, install policy, синхронизация HA, сбор конфигурации, пересчёт модели и проверка доступа.
Именно это нужно учитывать при проектировании NSPM. Масштабирование здесь достигается не за счёт бесконечной параллельной записи в МЭ, а за счёт умной очереди, пакетирования изменений и быстрой верификации результата.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
