Современные решения по трафику больше нельзя принимать только на основе IP и порта.
Классическая логика ACL ADC и брандмауэра долгое время строилась на IP, подсети, порте и протоколе. Эта модель достаточна для простого управления сетевым доступом, но современный веб, API, бот- и WAAP-трафик — не такой простой.
При принятии решения сегодня недостаточно спросить только «каков IP источника?». Из какой страны поступает запрос? Какой ASN? К какому пути он направляется? Какой cookie присутствует? Какая роль записана в JWT? Похож ли набор заголовков на реальный браузер? Подозрителен ли TLS-отпечаток? Сколько очков WAAP-оценки получил этот запрос? Как движок ботов классифицировал этого пользователя?
В большинстве продуктов эти сигналы находятся в разных местах. Правило маршрутизации — в одном месте, WAAP-оценка — в другом, решение по ботам — в третьем, перезапись заголовков — ещё в одном, ограничение скорости — тоже отдельно. Это усложняет эксплуатацию и приводит к непоследовательным решениям.
Большая проблема в том, что сложные условия обычно требуют кода. Написание правила вроде «если этот заголовок присутствует, этот cookie отсутствует, путь начинается с /api/, WAAP-оценка выше 5, но источник не является известным ботом» в большинстве продуктов требует скриптов, проприетарных языков политик или специфичного для вендора программирования.
Уровень условий Smart ACL в TR7 ADC решает эту проблему: решения по трафику определяются из UI с использованием 60+ критериев, цепочек Smart Function и групп AND/OR/NOT. Правило становится не просто IP-списком, а структурой решений, считывающей смысл трафика.
Наш подход
TR7 рассматривает условия ACL как фундаментальную единицу решений приложения и безопасности — а не как фильтр сетевых адресов.
Распознавание трафика по 60+ критериям
Движок Smart ACL выходит далеко за рамки IP и порта. IP источника, страна, город, IP назначения, порт назначения, HTTP-метод, URL, путь, запрос, заголовок, cookie, тело запроса, тело ответа, TLS SNI, шифр TLS, протокол TLS, JA3-отпечаток, ID WAAP-атаки, группа WAAP-атаки, класс бота, категория чёрного списка и состояние кэша — всё это может использоваться как условия. Это позволяет принимать решения по безопасности и маршрутизации в полном контексте приложения.
Группы условий AND / OR / NOT
ACL может использоваться самостоятельно или объединяться с другими ACL в логических группах. Внутренняя группа работает с AND или OR; условие может быть инвертировано для получения поведения NOT. Например: «Путь начинается с /login» AND «Страна источника не в списке разрешённых» AND «Оценка бота высокая» BUT «Не известный бот» — эта структура делает сложные политики безопасности читаемыми.
Цепочки Smart Function
Smart Functions в TR7 превращают сырые значения трафика в применимые вводные данные. Декодирование Base64, запрос JSON path, разбор заголовка/полезной нагрузки JWT, XML-запрос, сопоставление regex, замена строки, нижний/верхний регистр, дайджест, маска IP, преобразование IP в страну и операции поиска по карте/списку — всё это можно объединять в цепочки. ACL больше не просто спрашивает «совпадает ли значение этого заголовка?»; он парсит JSON внутри заголовка, извлекает JWT-клейм или запрашивает поле внутри тела.
Многократно используемые группы ACL
Часто используемые условия определяются один раз и используются повторно в разных правилах. Встроенные или пользовательские ACL вроде «является ли это расширением статического файла?», «присутствует ли cookie аутентификации?», «является ли это попаданием в кэш?» или «было ли заблокировано WAAP?» могут совместно использоваться во многих правилах. Этот шаблон снижает дублирование правил, централизует изменения и снижает риск операционных ошибок.
Возможности
Условия Smart ACL превращают сигналы трафика в читаемые условия и применимые действия по более чем 60 критериям.
Сопоставление HTTP-пути, URL и метода
TR7 может писать условия для пути, пути+запроса, полного URL и HTTP-метода. Типы сопоставления могут быть по префиксу, суффиксу, подстроке или regex. Запросы, начинающиеся с /api/, путь /admin, метод POST или конкретные URL-шаблоны, содержащие строку запроса — всё это выражается в рамках одного определения ACL.
Инспекция заголовков и cookie
Заголовки запросов, заголовки ответов, пользовательские cookie и cookie, приходящие от backend, — всё это может использоваться внутри ACL. Выбор маршрута на основе заголовка X-Tenant-ID, перенаправление на логин при отсутствии cookie session_id, проверка ботов на основе содержимого User-Agent и пользовательское поведение безопасности на основе response-cookie — всё это пишется на этом уровне.
IP источника, страна, город и ASN
Критерии ACL не ограничиваются IP источника или CIDR. Могут также определяться условия на основе страны, города и ASN. Ограничение доступа для определённых стран, пользовательская маршрутизация для пользователей из определённых городов, дополнительная верификация для трафика из определённых ASN или более агрессивная политика в отношении ботов для ASN дата-центров — всё поддерживается.
Условия TLS и отпечатков
TLS SNI, шифр TLS, протокол TLS, наличие SNI и сигналы JA3-отпечатка могут быть включены в условия. Назначение более низкой оценки доверия клиентам, использующим TLS 1.0, отклонение соединений без SNI, отправка трафика, совпадающего со списком известных плохих JA3-отпечатков, в CAPTCHA, или перевод клиентов со слабыми шифрами в режим мониторинга — всё это выражаемо.
Инспекция тела запроса и ответа
ACL может работать с дискретным содержимым тела запроса или ответа. Поддерживается сопоставление строк или regex внутри тела. Проверка транзакций с высокой стоимостью внутри JSON-тела, захват конкретного шаблона в поле формы, добавление заголовка при наличии определённого маркера в теле ответа или применение ограничения скорости на основе содержимого API-полезной нагрузки — всё это возможно.
Запросы JSON / XML / JWT
С помощью Smart Functions содержимое JSON, XML и JWT может быть преобразовано в условия ACL. JWT payload.role == "admin", transaction.amount > 10000 в JSON-теле, проверка существования определённого пути в XML или верификация алгоритма в JWT-заголовке — всё это условия, обеспечивающие значительную гибкость для безопасности API и политики доступа.
Интеграция с WAAP
Движок Smart ACL может также использовать решения WAAP как условия: ID WAAP-атаки, группа WAAP-атаки, WAAP-оценка, была ли заблокирована запросу WAAP, был ли он отмечен как WAAP-атака. Показ CAPTCHA при WAAP-оценке 5+, маршрутизация запросов в группе SQL injection в специальный формат логов или отправка результатов WAAP в режиме мониторинга на отдельный backend — примерные сценарии.
Классификация ботов и клиентов
Классификации браузера, мобильного устройства, бота и user agent могут использоваться внутри ACL. Отправка мобильных пользователей в мобильный backend, применение более низкого лимита скорости для трафика, отмеченного как бот, предоставление исключений известным поисковым системам и применение другого профиля безопасности для небраузерных клиентов — всё это можно определить.
Критерии скорости и размера
Движок ACL может использовать сигналы объёма и размера трафика: размер запроса, размер ответа, количество frontend-соединений, скорость запросов, скорость сессий, время ответа, количество живых серверов backend и HTTP-код статуса. Перемещение нового трафика в запасной пул при падении количества живых backend-серверов до 1, или кэширование конкретного эндпоинта при росте времени ответа — оба случая выражаются через эти критерии.
Использование пользовательских карт и списков
Поддерживается сопоставление на основе карт и списков. Используется для больших списков IP, списков доменов, URL-списков, списков идентификаторов клиентов или пользовательских таблиц «ключ-значение». Различная маршрутизация на основе списка VIP-клиентов, блокировка IP из списка блокировки или применение CORS-политики на основе списка партнёрских доменов — всё управляется с помощью этого шаблона.
Сопоставление IP по категориям чёрного списка
Категории IP-репутации или чёрных списков могут быть включены в условия. Категории ботнетов, прокси, Tor, вредоносных программ или спама можно привязать к различным поведениям. Показ CAPTCHA IP из категории открытого прокси, перевод выходных узлов Tor в режим мониторинга или прямое отклонение IP из категории вредоносных программ — примеры использования.
Встроенные ACL
TR7 предоставляет несколько общих ACL готовых к использованию: является ли это расширением статического файла, присутствует ли cookie аутентификации, является ли это попаданием в кэш, было ли заблокировано WAAP. Эти встроенные ACL предотвращают необходимость операторов перезаписывать свои наиболее часто используемые условия и делают наборы правил более компактными.
Ручное условие — экспертный режим
В граничных случаях, когда стандартных критериев UI недостаточно, опытный пользователь может написать ручное условие. Это сохраняет визуальный движок правил TR7, обеспечивая при этом гибкость аварийного выхода. Этот режим не для ежедневного использования — он предназначен для продвинутых операций и пользовательских интеграций.
Условия ограничения скорости на основе пользователя
Значения скорости запросов, скорости соединений и скорости ошибок на основе пользователя могут использоваться внутри ACL. В сочетании с JWT-клеймом, cookie, заголовком или идентификатором пользователя могут строиться политики ограничения скорости на уровне тенанта или пользователя.
Условия состояния кэша и аутентификации
Различные поведения могут запускаться в зависимости от того, является ли запрос или ответ попаданием в кэш. Наличие cookie аутентификации или значения HTTP-аутентификации также может использоваться в движке ACL. Это объединяет поведение AAM и ADC под одной логикой правил.
Операционная глубина
Условия Smart ACL — это не только синтаксис правил, но и структура групп условий, типы сопоставления, модель обновления и ограничения выборки тела.
Структура группы условий
Условия Smart ACL определяются в группах. Условия внутри группы объединяются с AND или OR. Условие может быть инвертировано для получения поведения NOT. Внешние группы формируют более широкую логическую структуру. Этот подход разбивает сложные политики на маленькие, читаемые части.
Идентификатор ACL и повторное использование
Каждый ACL идентифицируется уникальным ID. Правила ссылаются на этот ID. Один и тот же ACL может использоваться в разных правилах трафика, политиках ограничения скорости, правилах редиректа или действиях безопасности. При изменении ACL обновление автоматически распространяется на все связанные правила.
Типы сопоставления
Для текстовых условий поддерживаются различные типы сопоставления: сопоставление по префиксу, суффиксу, подстроке, regex, а также с учётом или без учёта регистра. Эта гибкость охватывает как простые, так и сложные структуры правил.
Цепочки Smart Function
Smart Functions могут использоваться по отдельности или объединяться в цепочки. Например: разобрать полезную нагрузку JWT, извлечь поле роли, преобразовать в нижний регистр, сравнить с конкретным списком. Это превращает сырые данные трафика в значимые вводные данные для принятия решений.
Ограничение выборки тела
Инспекция тела запроса и ответа работает с дискретным размером содержимого. Это обеспечивает сбалансированную модель между производительностью и осведомлённостью о контенте. Для очень больших тел отдельно используются специализированные возможности модификации или маскирования тела.
Модель обновления L7 и L3
Условия Smart ACL могут использоваться на разных уровнях. Правила на стороне L7 могут требовать мягкой перезагрузки при изменении конфигурации. Правила на стороне брандмауэра L3 применяются через свой собственный цикл синхронизации брандмауэра. Не каждое изменение применяется через один и тот же механизм — применяется модель обновления по уровням.
Встроенный ACL для расширений статических файлов
Общие расширения для обнаружения статического контента предоставляются из коробки: .css, .js, .jpg, .png, .svg, .woff, .pdf, .mp4, .webp, .docx, .xlsx и подобные типы файлов. Часто используется в сценариях кэширования, сокращения логов и исключений из ограничения скорости.
Гибкость Lua-конвертера
Некоторые Smart Functions работают непосредственно со встроенным движком трафика; некоторые специализированные функции выполняются через дополнительный уровень конвертера. Это даёт операциям с JSON, XML, JWT и пользовательскими строками более широкую поверхность выражений.
Когда применять
Ограничение скорости API по JWT-клейму
На уровне API администраторы получают более высокий лимит, а обычные пользователи — более низкий. Smart ACL читает поле роли из полезной нагрузки JWT и выбирает политику ограничения скорости соответственно. JWTPAYLOAD(role) == admin → высокий лимит скорости; иначе → стандартный лимит скорости.
CAPTCHA на основе WAAP-оценки
Запрос отмечается WAAP как подозрительный, но недостаточно явно для прямой блокировки. Smart ACL оценивает WAAP-оценку и класс бота совместно. Когда wafScore >= 5 AND NOT knownBot, отображается CAPTCHA.
Разделение мобильных и десктопных backend-серверов
Мобильные пользователи маршрутизируются к одному backend, а пользователи десктопа — к другому. Smart ACL использует сигнал user agent и классификации мобильных устройств. mobile == true → мобильный backend; mobile == false → десктопный backend.
Обнаружение ботов через JA3-отпечаток
Пользовательская карта известных вредоносных клиентских отпечатков определяется как ACL. Когда входящий TLS-отпечаток совпадает с этим списком, трафик блокируется или отправляется в CAPTCHA. ja3 in bad_fingerprint_list → deny / captcha.
Дополнительный контроль на основе суммы в JSON-теле
В финансовом API сумма транзакции читается изнутри JSON-тела. Когда сумма превышает определённый порог, на стороне AAM запускается дополнительный MFA или транзакция маршрутизируется на отдельный backend. JSONQUERY(transaction.amount) > 10000 → step-up MFA.
Объединение сигналов страны, ASN и WAAP
Трафик из определённых стран обычно разрешён, но когда тот же трафик поступает из хостингового ASN и WAAP-оценка повышена, применяется дополнительная задача. country in allowedCountries AND asn in hostingProviders AND wafScore >= 4 → challenge.
Часто задаваемые вопросы
Сколько различных типов критериев можно использовать со Smart ACL?
Как настраиваются группы условий AND/OR/NOT?
Что делают цепочки Smart Function?
Можно ли использовать один ACL повторно в нескольких правилах?
Как обновления ACL влияют на живой трафик?
Как WAAP-оценка и сигнал ботов используются внутри ACL?
Выведите ваши решения по трафику за рамки IP-адреса
Безопасность, маршрутизация и ограничение скорости в одном движке правил — по 60+ критериям, цепочкам Smart Function и группам AND/OR/NOT. Давайте пройдём через живую настройку в вашей собственной среде.