Средняя
Разработчик пишет условие:
Если пользователь авторизован
и имеет нужную роль,
то разрешить операцию.
Иначе — отказать.
Сетевой инженер создаёт правило:
Если трафик приходит из нужной сети,
направляется к нужному серверу
и использует разрешённый сервис,
то пропустить его.
Иначе — заблокировать.
Формально это разные задачи. В одном случае выполняется программный код, в другом — политика межсетевого экрана. Но логика у них почти одинаковая.
У правила МЭ есть входные данные, условия, порядок обработки и результат. Оно может быть синтаксически корректным, но логически ошибочным. Может никогда не выполняться, конфликтовать с другими правилами или разрешать больше, чем предполагал автор.
Разница лишь в том, что программу исполняет процессор, а политику безопасности — сеть.
Содержание
- Правило МЭ как условный оператор
- Порядок правил меняет результат
- Взгляд разработчика
- Взгляд сетевого инженера
- Политика как распределённая программа
- NAT как преобразование данных
- Ошибки правил похожи на ошибки кода
- Изменение правила — это релиз в production
- Почему разработчики и сетевые инженеры не всегда понимают друг друга?
- Вместо вывода
Правило МЭ как условный оператор
Большинство правил межсетевого экрана можно представить как конструкцию if:
if source in OFFICE_NET
and destination in CRM_SERVERS
and service == HTTPS:
allow
else:
continue
Поля Source, Destination и Service — это входные параметры. Action — результат выполнения. Сетевые объекты и их группы похожи на переменные и структуры данных. Комментарий к правилу выполняет ту же роль, что и комментарий в коде: объясняет, зачем эта логика появилась.
Даже правило deny any any в конце политики напоминает ветку else, обрабатывающую всё, что не подошло под предыдущие условия.
Политика МЭ — не просто таблица разрешений. Это последовательная программа обработки сетевого трафика.
Порядок правил меняет результат
Во многих межсетевых экранах правила проверяются сверху вниз. Как только найдено первое совпадение, устройство выполняет указанное действие и прекращает поиск.
Для разработчика это знакомая конструкция:
if condition_1:
action_1
elif condition_2:
action_2
Если поменять условия местами, поведение программы изменится.
То же происходит с политикой МЭ. Например:
1. OFFICE_NET → ANY → ANY → ALLOW
2. OFFICE_NET → FINANCE_SERVERS → SSH → DENY
Второе правило должно запрещать административный доступ к финансовым серверам. Но трафик уже был разрешён первым правилом. Запрет существует в конфигурации, однако никогда не срабатывает.
В программировании это назвали бы недостижимым или мёртвым кодом. В сетевой безопасности — затенённым правилом.
Поэтому количество правил само по себе мало говорит о качестве политики. Важнее их порядок, пересечения и фактическая область действия.
Взгляд разработчика
Разработчик обычно воспринимает сетевой доступ как бинарное состояние: соединение либо есть, либо его нет.
Приложение должно обратиться к API по адресу 10.20.30.40 на порт 8443. Ожидаемая логика выглядит просто:
APP_SERVER → CRM_API → TCP/8443 → ALLOW
Если такое правило существует, возникает закономерный вопрос: почему соединение всё равно не работает?
С точки зрения приложения всё сходится. Известны источник, назначение и порт. Но правило, как и фрагмент программного кода, существует не в вакууме.
Приложение может обращаться не с того IP-адреса, который указан в заявке. Адрес может измениться после NAT. Трафик может попасть в другой VRF или виртуальный контекст. Прямой маршрут может существовать, а обратный — отсутствовать. На пути могут находиться несколько межсетевых экранов, и доступ потребуется на каждом.
Для разработчика правило часто выглядит как самостоятельная функция. Для сетевого инженера оно является одной строкой в большой распределённой программе.
Взгляд сетевого инженера
Чтобы ответить, разрешён ли доступ, сетевому инженеру недостаточно найти строку в политике. Ему нужно понять:
- с какого адреса трафик фактически придёт на МЭ;
- через какие устройства он пройдёт;
- в каком VRF, контексте или зоне будет обработан;
- произойдёт ли NAT;
- какое правило сработает первым;
- существует ли обратный маршрут;
- не будет ли трафик заблокирован на следующем участке.
Поэтому вопрос «правило же есть, почему доступ не работает?» звучит примерно как вопрос разработчику: «нужная строка в коде присутствует, почему функция не выполняется?»
Строка может существовать, но до неё не доходит управление. Она может получать другие входные данные. Результат может быть изменён следующим компонентом.
Сеть исполняет политику так же, как приложение исполняет код, — с учётом всего окружения.
Политика как распределённая программа
У приложения обычно есть репозиторий, в котором можно найти нужный модуль и проследить логику выполнения.
С сетевыми доступами сложнее. Полная логика может быть распределена между маршрутизаторами, межсетевыми экранами, виртуальными МЭ, VPN-шлюзами, облачными security groups, балансировщиками и средствами микросегментации.
Каждое устройство исполняет свою часть программы. Кроме того, отдельные части написаны на разных «языках»: Check Point, Cisco, Fortinet, Palo Alto, UserGate, PT NGFW и другие платформы используют собственные форматы правил, объектов и политик.
Получается распределённая система, в которой единая бизнес-логика доступа реализована в конфигурациях разных производителей.
Поэтому изменение одного правила нельзя всегда оценивать изолированно. Оно способно изменить поведение всей цепочки прохождения трафика.
NAT как преобразование данных
Дополнительную сложность создаёт NAT.
Приложение отправляет запрос от одного адреса к другому, но по пути исходный или целевой адрес может измениться:
До NAT:
10.1.1.15 → 172.20.10.50
После NAT:
192.0.2.25 → 10.50.4.10
Какие адреса должны быть указаны в правиле? Это зависит от производителя МЭ, порядка обработки NAT и фильтрации, направления трафика и конкретного участка сети.
В программировании NAT можно сравнить с промежуточной функцией, которая преобразует входные данные перед передачей следующему компоненту.
Если разработчик не знает о таком преобразовании, значения в логах кажутся неожиданными. С сетевыми политиками происходит то же самое: правило может быть правильным относительно исходных данных, но устройство уже работает с изменёнными адресами.
Ошибки правил похожи на ошибки кода
Между качеством программного кода и качеством политики МЭ можно провести прямые параллели.
| Разработка | Политика МЭ |
|---|---|
| Мёртвый код | Неиспользуемое или затенённое правило |
| Дублирование логики | Дублирующие правила и объекты |
| Слишком широкие права | ANY и широкие диапазоны |
| Ошибка порядка условий | Неверная последовательность правил |
| Технический долг | Временные доступы, которые не удалили |
| Отсутствие тестов | Изменение без проверки маршрута |
| Отсутствие наблюдаемости | Правило без логирования |
| Магические значения | IP-адреса без названий и комментариев |
Счётчик срабатываний правила — hit count — можно сравнить с покрытием кода и телеметрией выполнения.
Если правило не использовалось два года, это ещё не значит, что его нужно немедленно удалить. Возможно, оно нужно для резервного ЦОД или аварийной операции. Но отсутствие срабатываний — хороший повод выяснить назначение правила, найти владельца и проверить, не перекрывается ли оно другой логикой.
Метрика не принимает решение за инженера, но помогает определить кандидатов на ревью.
Изменение правила — это релиз в production
Добавление сетевого доступа часто воспринимается как небольшое эксплуатационное действие: создать правило, установить политику и проверить соединение.
Фактически это изменение исполняемой логики в production.
Ошибочное правило может открыть доступ к критичному сегменту, заблокировать бизнес-сервис, нарушить сегментацию или создать путь для бокового перемещения злоумышленника.
Поэтому процесс изменения правил естественно сравнить с поставкой программного кода.
Для кода существуют постановка задачи, review, автоматические проверки, релиз, мониторинг и откат. Для правил МЭ нужны похожие этапы:
- Формализация требуемого доступа.
- Проверка источника, назначения и сервиса.
- Расчёт маршрута.
- Определение затрагиваемых устройств.
- Анализ конфликтов и избыточных разрешений.
- Согласование изменения.
- Применение и проверка результата.
- Возможность отката.
Команда commit на межсетевом экране по смыслу мало отличается от развёртывания новой версии приложения. Только меняется не логика бизнес-функции, а логика движения трафика.
Почему разработчики и сетевые инженеры не всегда понимают друг друга?
Разработчик мыслит сервисами:
Приложению А нужен доступ к API приложения Б. Сетевой инженер мыслит пакетами и точками применения политики:
Трафик из определённого VRF должен пройти через два МЭ, выполнить NAT и получить обратный маршрут.
Они описывают один процесс, но на разных уровнях абстракции.
Проблемы начинаются, когда бизнес-требование слишком рано превращается в набор IP-адресов и портов. Через год уже трудно понять, зачем существует правило:
10.14.8.0/24 → 172.18.5.17 → TCP/9443
Это доступ платёжной системы? Временное правило для миграции? Старый тестовый контур?
Код без понятных названий и комментариев быстро становится нечитаемым. Политика МЭ без связи с сервисами, владельцами и заявками деградирует точно так же.
Вместо вывода
Правила межсетевого экрана — это код не в формальном смысле языка программирования, а по своей природе.
Они описывают условия и действия, исполняются в заданном порядке, используют объекты как структуры данных, зависят от состояния и окружения. В них встречаются мёртвая логика, дублирование, конфликты и технический долг.
Но сетевой код сложнее обычного: он распределён между устройствами и зависит от топологии.
Для разработчика правило МЭ — это условие, разрешающее приложению соединение.
Для сетевого инженера — одна строка большой распределённой программы, определяющей движение трафика по инфраструктуре.
Поэтому политики межсетевых экранов стоит сопровождать как программный код: хранить историю, проводить ревью, выполнять автоматические проверки, связывать изменения с заявками и регулярно удалять устаревшую логику.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
