Возможность

Правила с учётом контента

Выйдите за линию заголовка — позвольте содержимому JSON, XML, multipart и GraphQL формировать каждое решение по трафику.

TR7 Content-Aware Rules признают, что решающий сигнал в современном трафике приложений — уже не просто URL, заголовок или IP источника. В современных API-нагрузках критическое значение обычно находится внутри тела: роль пользователя в JSON, имя сервиса в XML-конверте, поле тенанта в multipart-форме или имя операции в GraphQL-запросе. TR7 делает эти полезные нагрузки читаемыми, сопоставимыми и применимыми через единый FX-язык выражений. JSONPath, XPath, параметры форм, JWT-клеймы, операции с картами и списками, а также проверки regex сосуществуют в одной модели правил, и одно и то же выражение может управлять как маршрутизацией трафика, так и WAAP-скорингом. В режиме ADC содержимое тела может инспектироваться и, в выбранных случаях, переписываться на стороне ответа. В режиме WAAP целостность тела сохраняется — содержимое читается и оценивается, а запрос блокируется при превышении порога. Результат: в API-ландшафте, где решений только на основе заголовков недостаточно, TR7 превращает данные внутри тела в первоклассный ввод для маршрутизации, защиты и политики.

Типа парсеров тела: JSON, XML, multipart, form-url-encoded

10+

Вариантов поиска по картам и спискам

Общий FX-язык для трафика ADC и WAAP-скоринга

В современном API-трафике реальные данные для принятия решений находятся в теле — а не в заголовках.

Традиционное управление трафиком на уровне Layer 7 обычно принимает решения на основе URL, метода, заголовков и адреса источника. Эта модель зачастую достаточна для классических веб-приложений, но в современных API-архитектурах критическое различие обычно находится в полях внутри тела запроса. Идентификатор тенанта, роль пользователя, тип транзакции, имя сервиса или метаданные загрузки файла — всё это не в заголовках, а в JSON, XML, форм- или multipart-полезных нагрузках.

Без такой видимости операторы оказываются перед плохими вариантами. Либо перед управлением трафиком размещается дополнительный API-шлюз — добавляя новый hop, новую лицензию и новую операционную нагрузку, — либо само приложение изменяется, чтобы поднять значение для принятия решений в заголовки. Для устаревших и бизнес-критических backend-сервисов это изменение зачастую нецелесообразно.

Ограничение инспекции тела только целями безопасности тоже не решает проблему. Если WAAP может читать контент, но движок маршрутизации не может использовать то же значение, политика безопасности и политика трафика оказываются в двух отдельных мирах. Результатом становится дублирование логики, несоответствующие правила и повышенная вероятность ошибок.

Правильная модель — сделать возможности парсера тела нативной частью языка правил. JSONPath, XPath, параметры форм, JWT-клеймы, regex и проверки карт/списков должны жить в одном дереве выражений, и одно выражение должно управлять как действием трафика, так и WAAP-оценкой.

TR7 Content-Aware Rules закрывают этот разрыв: поля внутри тела перестают быть просто инспектируемыми данными и становятся сигналами, которые напрямую управляют решением.

Наш подход

TR7 не рассматривает осведомлённость о контенте как отдельную надстройку. Это нативная часть языка правил трафика и безопасности.

Функции парсера тела встроены непосредственно в FX-язык выражений

JSONQUERY, XMLQUERY, XMLPATHEXISTS, PARAM, JWTHEADER и JWTPAYLOAD — функции первого класса в языке правил. Операторы превращают содержимое тела в условия без написания кастомного кода и привязывают эти условия напрямую к действиям трафика или безопасности.

Парсеры JSON, XML и multipart работают внутри среды выполнения

JSON, XML и multipart-полезные нагрузки парсятся во время выполнения и предоставляются движку правил как читаемые значения. Операторы принимают решения на основе значимых полей вместо применения грубого regex ко всем байтам запроса.

Один и тот же DSL управляет управлением трафиком и WAAP-скорингом

В TR7 выражение, написанное для поля тела, может управлять как маршрутизацией, манипуляцией заголовками, так и оценкой WAAP-сигнатур. Эта общая модель снижает дублирование логики между правилами трафика и правилами безопасности.

Режимы ADC и WAAP следуют различным правилам целостности

В режиме ADC тело может быть прочитано и, в подходящих сценариях, переписано на стороне ответа. В режиме WAAP тело никогда не модифицируется — оно читается, оценивается и блокируется при превышении порога политики.

Возможности

Правила с учётом контента превращают структурированные данные полезной нагрузки в читаемые условия и применимые действия.

JSONPath-запросы пишут правила непосредственно для полей тела API

Функция JSONQUERY вычисляет поля JSON-тела с использованием стандартной семантики JSONPath. Операторы могут использовать значения такие как `$.user.role`, `$.items[0].sku` или `$.tenant_id` как условия и привязывать их к маршрутизации vService, манипуляции заголовками или WAAP-скорингу. Трафик API больше не управляется только по эндпоинту — он управляется по фактическому бизнес-смыслу запроса.

XML XPath-проверки делают трафик SOAP и корпоративных сервисов прозрачным

XMLQUERY, XMLPATHTYPE и XMLPATHEXISTS выполняют XPath-запросы к XML-телам. Имя сервиса, узел действия или поле операции внутри SOAP-конверта могут управлять решениями маршрутизации и безопасности. Это особенно ценно для применения диспетчеризации и политики на уровне сервиса без модификации устаревших backend-сервисов. XML-полезные нагрузки становятся структурированными данными внутри движка правил, снижая зависимость от хрупкого regex.

Тип FIX-сообщения и топик MQTT как условия правила

Правило не обязано заканчиваться на HTTP. Тип и тег FIX-сообщения, топик MQTT и структура пакета доступны как условия в том же конструкторе правил, поэтому некорректное заявочное сообщение или неожиданный топик перехватываются на уровне доставки — до матчинг-движка или брокера. Биржевой и IoT-трафик обычно просто переносят как непрозрачный TCP и надеются на лучшее; здесь его читают, и читающее правило выглядит ровно так же, как правила, которые ваша команда пишет каждый день.

Поля форм и multipart привязывают решения о тенанте, файлах и транзакциях

Функция PARAM превращает строки запроса, тела с form-кодированием и поля форм в условия правил. Парсер multipart предоставляет метаданные загрузки файла — имя поля, тип контента и размер — для политики. Этот шаблон полезен для SaaS-порталов, потоков загрузки документов и пользовательской логики транзакций. Трафик может маршрутизироваться или блокироваться на основе бизнес-контекста, который несёт форма.

Значения заголовка и полезной нагрузки JWT запрашиваются одной функцией

JWTHEADER и JWTPAYLOAD предоставляют поля заголовка и полезной нагрузки токена как JSONPath-запрашиваемые значения. Роль пользователя, тенант, уровень авторизации или пользовательские клеймы становятся вводными данными для решений по трафику и безопасности. Обязательный клейм может быть применён на границе, отсутствующие клеймы могут приводить к отказу запроса, а трафик на основе ролей может направляться к выделенным группам backend — всё без встраивания логики доступа в код приложения.

Операции с картами и списками масштабируют правила на большие наборы данных

MAP_STR, MAP_REG, MAP_SUB, MAP_IP, MAP_BEG и MAP_END обеспечивают быстрые поиски по большим наборам значений. LIST_STR, LIST_REG, LIST_SUB, LIST_IP, LIST_BEG и LIST_END предлагают ту же модель для проверок на основе списков. Реестры тенантов, разрешённые имена сервисов, диапазоны IP и группы шаблонов могут управляться централизованно вместо разовых условий, сохраняя большие наборы правил управляемыми.

Ограничения размера тела, глубины и количества полей ограничивают парсинг до его начала

BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT и XML_NODE_COUNT определяют защитные ограничения до включения парсера. Слишком большие, глубоко вложенные или раздутые полезные нагрузки отклоняются до достижения backend-сервиса. JSON_DEPTH по умолчанию равен 32 и настраивается на уровне политики. Тот же контроль управляет как потреблением ресурсов, так и злоупотреблениями на уровне парсера.

Allowed и Must Args строят позитивную модель безопасности

JSON_MUST_ARGS, JSON_ALLOWED_ARGS, FORM_MUST_ARGS и FORM_ALLOWED_ARGS проверяют наличие ожидаемых полей и отсутствие неожиданных. Вместо поиска только плохих шаблонов модель декларирует форму допустимого запроса. Отсутствующие обязательные поля или неожиданные параметры могут отклоняться в соответствии с политикой. Этот подход, осведомлённый о контракте, особенно ценен на критических транзакционных эндпоинтах.

Перезапись тела ответа обеспечивает маскирование и трансформацию в режиме ADC

В режиме ADC действие modifyResponse применяет замену на основе regex к телам ответов. Используется для маскирования персональных данных, перезаписи ссылок или адаптации внутренних адресов для внешних потребителей. Режим WAAP никогда не модифицирует тело — он только читает и оценивает. Это разделение балансирует гибкость трафика с целостностью безопасности на одной платформе.

Операционная глубина

Осведомлённость о контенте — это не только синтаксис правил, но и управление буфером, кэширование результатов разбора, видимость аудита и поведение в граничных случаях.

Управление буфером тела

Содержимое тела буферизуется перед парсингом, после чего соответствующий парсер JSON, XML или multipart работает с этим буфером. Буфер тела по умолчанию — 16 КБ; системные параметры могут быть увеличены для больших JSON- или XML-полезных нагрузок. При превышении лимита запрос отклоняется с кодом 413, чтобы backend не нагружался чрезмерно большими полезными нагрузками.

Кэширование результатов разбора

Результаты JSONPath и XPath, прочитанные в рамках одного запроса, кэшируются в пространстве переменных в области транзакции. После того как правило прочитало поле тела, последующие правила не перезапускают парсер для того же поля. Это снижает задержку и стоимость обработки в длинных цепочках правил.

Модель целостности WAAP

В режиме WAAP тело читается, но никогда не модифицируется. Содержимое передаётся в сигнатуры, скоринг и логику порога; после превышения порога запрос блокируется. Уровень безопасности может действовать на сигналы с учётом контента, сохраняя целостность запроса от начала до конца.

Поведение при чанковых запросах

Парсинг чанковых POST-запросов начинается после завершения переборки чанков, поэтому поля тела оцениваются как полная, связная полезная нагрузка. Чанковый трафик может вызвать небольшую дополнительную задержку, но backend защищён от частичных и неконтролируемых потоков полезной нагрузки.

Видимость GraphQL

GraphQL в настоящее время обрабатывается через JSONPath: поля, такие как имя операции и список полей внутри тела, могут использоваться в условиях правил. Это позволяет принимать практические решения на границе, такие как разделение мутаций и запросов. Глубокая валидация схемы выходит за рамки этой возможности.

След аудита и SIEM

Какое правило прочитало какое поле тела — записывается в журнал аудита. Операционные команды могут отследить, почему конкретный запрос был маршрутизирован, отклонён или оценён в их SIEM. Эта отслеживаемость не позволяет правилам с учётом контента вести себя как чёрный ящик.

Когда применять

Маршрутизация по значению тенанта внутри JSON

SaaS-команды могут направлять трафик к отдельным пулам backend на основе поля tenant_id внутри JSON-тела. Разделение тенантов происходит без изменения кода приложения, а политика трафика управляется на границе.

Диспетчеризация корпоративных сервисов по действию SOAP

В банковских и государственных системах узел действия внутри XML-конверта может управлять диспетчеризацией к различным группам сервисов. Устаревший контракт сервиса остаётся нетронутым, а решения по трафику становятся осведомлёнными о контенте.

Разделение GraphQL-трафика по типу операции

Инженерные команды могут направлять запросы и мутации к отдельным источникам на основе поля operationName. Операции с большим количеством чтений и операции с большим количеством записей попадают к выделенным группам backend.

Применение решений доступа на основе JWT-клеймов

Для критических приложений клеймы роли и тенанта внутри полезной нагрузки JWT могут применяться на границе. Запросы с отсутствующими обязательными клеймами никогда не достигают backend; запросы с действительными клеймами помещаются под соответствующую политику трафика.

Часто задаваемые вопросы

Какие типы контента поддерживают парсеры тела?

JSON, XML, multipart и form-url-encoded полезные нагрузки парсятся во время выполнения. JSONPath управляет доступом к JSON, XPath — доступом к XML, а функция PARAM охватывает поля форм и multipart непосредственно как FX-выражения. GraphQL в настоящее время обрабатывается через JSONPath — имя операции и список полей внутри тела доступны как условия правил.

Может ли одно правило управлять как трафиком ADC, так и политикой WAAP?

Да. Выражение, написанное для поля тела, может управлять маршрутизацией или манипуляцией заголовками, а также логикой WAAP-сигнатур и скоринга. Поскольку один и тот же DSL применяется на обоих уровнях, дублирование логики между правилами трафика и правилами безопасности значительно снижается.

В чём разница целостности между режимом ADC и режимом WAAP?

В режиме ADC тело читаемо и, при необходимости, тело ответа может быть переписано. В режиме WAAP тело никогда не модифицируется — оно читается, передаётся в сигнатуры и скоринг, и запрос блокируется после превышения порога политики. Это разделение балансирует гибкость трафика с целостностью безопасности на одной платформе.

Как содержимое JWT используется в выражениях правил?

JWTHEADER и JWTPAYLOAD предоставляют заголовок и полезную нагрузку токена как JSONPath-запрашиваемые значения. Роль пользователя, тенант, уровень авторизации или пользовательские клеймы могут управлять как решениями по трафику, так и решениями по безопасности. Запросы с отсутствующими или неожиданными клеймами могут быть отклонены до достижения backend.

Как система обрабатывает очень большие или глубоко вложенные тела?

BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT и XML_NODE_COUNT применяют защитные ограничения до начала парсинга. JSON_DEPTH по умолчанию равен 32; слишком большие или раздутые полезные нагрузки отклоняются до достижения backend. Буфер тела по умолчанию — 16 КБ и может быть увеличен через системные параметры.

Если несколько правил читают одно поле тела, будет ли парсинг выполняться несколько раз?

Нет. Результаты JSONPath и XPath, прочитанные в рамках одного запроса, кэшируются в пространстве переменных в области транзакции. После того как правило прочитало поле тела, последующие правила используют кэшированное значение вместо повторного запуска парсера. Это сохраняет задержку и стоимость обработки на низком уровне в длинных цепочках правил.

Принимайте API-решения на основе тела — а не заголовка

Маршрутизация и безопасность с учётом контента по полям JSON, XML, multipart и JWT. Давайте пройдём через живую настройку на ваших собственных сервисах.