NGFW: Переход от портов и подсетей к политикам по приложениям — как навести порядок в исключениях

Автор: Алексей Громов, технический директор ООО «КорБит» (в составе холдинга «Цикада»)

Статья подготовлена на основе практического опыта внедрений.

В современном мире сетевой безопасности традиционные подходы к настройке межсетевых экранов часто приводят к хаосу. Если ваша политика безопасности выглядит как набор случайных исключений — «разрешим 443-й порт наружу всем, иначе бизнес встанет», или «вот исключение для бухгалтерии», — то вы уже в ловушке бесконечного ремонта. В этой статье мы разберём, почему модель на основе портов и подсетей устарела, как перейти к политикам по приложениям и как дисциплинировать исключения, особенно в контексте TLS-инспекции. На примерах из CoreBit.NGFW покажем практический путь миграции без остановки бизнеса.

Почему «порт 443» больше не политика, а фарс

В эпоху облачных сервисов и мобильных устройств TCP/443 стал универсальным каналом для всего: от CRM-систем и мессенджеров до обновлений ПО и даже туннелей для эксфильтрации данных. Проблема кроется в близорукости традиционных подходов:

— слепота к приложениям: трафик на порт 80/443 может быть HTTP/HTTPS, но также и туннелированным вредоносом (например, C&C-каналом). Без инспекции L7 невозможно отличить легитимный веб-доступ от атаки.

— рост исключений: исключения для «спецслучаев» (например, доступ к облаку) накапливаются, создавая хаос, при этом приоритет правил не учитывается, что приводит к конфликтам и дырам в безопасности.

— несоответствие регуляторам: ФСТЭК требует анализа трафика на уровне приложений (включая TLS-инспекцию), а традиционные правила не обеспечивают этого.

По данным наших исследований в CoreBit, до 70% угроз (DDoS, malware) маскируются под легитимный трафик на стандартных портах. Переход к политикам по приложениям — не опция, а необходимость.

Политика по приложениям: практика реализации

Политика по приложениям фокусируется на вопросах «кто, зачем, к чему, как и когда», а не только «откуда-куда». В CoreBit.NGFW это достигается через объекты: пользователи/группы (интеграция с AD/LDAP), зоны, приложения (L7-анализ), URL-категории и расписания. Мы уходим от протоколов как основы — приложение автоматически включает необходимые сетевые механики, без ручного перечисления используемых им протоколов.

Структура правила в целом представляет собой:

1. База: источник (пользователь/группа), назначение (IP/FQDN/URL), приложение.
2. Контроль: TLS-инспекция (для HTTPS-анализа), политики безопасности (антивирус, IPS, морфологический и контекстный поиск), расписание и логирование.
3. Порядок: правила обрабатываются сверху вниз, срабатывает первое совпадение, политики отрабатываются в правиле последовательно. Исключения размещаются выше общих правил.

На практике это выглядит следующим образом: «Группе HR разрешить приложение «XX» в рабочее время с антивирусной проверкой и логированием, при этом все остальное запретить».

Переход без остановки бизнеса: шаги миграции

CoreBit.NGFW поддерживает Default Allow (разрешено всё, кроме…) иDefault Deny (запрещено всё, кроме…). Default Allow нормально на старте, если вы честно ведёте логи и планируете переход. Плохо не Default Allow, плохо «Default Allow навсегда».

Реалистичный путь: начать с мягкого подхода и ужесточать на основе логов.

Предлагаемые шаги:

1. Аудит: в режиме Default Allow с последовательным добавлением ограничений и выявлением топ приложений, FQDN, стран, CDN, частых блокировок и «дорогих» исключений.
2. Классификация: разделить правила на бизнес-критичные, допустимые и рискованный мусор.
3. Словарь объектов: создать группы пользователей, наборы приложений, FQDN и TLS-исключений.
4. Структура правил: блоки для инфраструктуры, исключений, разрешений и запретов по приложениям.
5. Мягкий запуск: наблюдать, оптимизировать, вычищать исключения, переходить к Default Deny.

Исключения: от «дырок» к управляемым отклонениям

Исключения — слабое звено: они размывают политики. В CoreBit.NGFW мы реализовали следующий функционал, позволяющий снизить ложные срабатывания до 40 %:

1. Иерархия правил: глобальные — строгие, локальные — для исключений. Пример: глобальное «блокировать соцсети», локальное «разрешить для маркетинга по расписанию».

2. Группировка и инверсия: используйте инверсию (например, запрещающие правило, но не для группы администраторов). Это позволяет минимизировать дубликаты и сделать политику фильтрации более гибкой.

3. Очистка и аудит: проверяйте срабатывания и объемы передаваемых данных по каждому правилу через счётчики состояния и подписку на события срабатывания, а также генерируйте сетевые дампы (PCAP) по триггерам в редакторе правил.

Пример из практики перехода компании с традиционного межсетевого экрана на CoreBit.NGFW: старые правила (порты 80/443) заменены на «l7_proto = ‘Web’ с url_cat != ‘Malware'». Исключения для VIP-пользователей — через user_grp_src. Результат: снижение инцидентов на 30%, упрощение администрирования за счёт сокращения порядка 500 правил до нескольких десятков.

TLS-инспекция: от хаоса к порядку

Частая ошибка: включить инспекцию «везде», получить жалобы, добавлять исключения точечно — в итоге трафик частично «слепой», поведение правил становится непредсказуемым.

Правильная схема:

1. Сверху — правила «не инспектировать» для конкретных назначений/категорий.
2. Ниже — общее «инспектировать остальное».

Контроль качества политик

Ежеквартально проверяйте:

— топ-правил по сработкам;

— исключения (со сроками пересмотра);

— мёртвые/дублирующие правила;

— долю трафика без инспекции.

Важно понять, что порядок — это процесс, а не разовая акция.

Переход к политикам по приложениям в NGFW — это не только compliance с ФСТЭК, но и реальная защита от APT и zero-day. CoreBit.NGFW, как отечественное решение, упрощает миграцию: централизованное управление парком из 100+ узлов, наборы объектов для атрибутов, инверсия значений в условиях, а также продуманные инструменты аудита — реал-тайм дашборды мониторинга (с утилизацией ресурсов, счётчиками и метриками), детальные журналы событий с экспортом в SIEM (Syslog/CEF), счётчики срабатываний правил для анализа эффективности и гибкие уведомления о событиях для оперативного реагирования. Начните с аудита — и увидите разницу.