Перейти к содержанию

Интеграция с WAF и SIEM

AppSec.AIGate выставляет служебные HTTP-заголовки X-LLMFW-* на каждый ответ Gateway, что позволяет downstream-системам (WAF, reverse-proxy, SIEM) принимать решения по результату работы AppSec.AIGate без разбора тела ответа. В этом разделе — практические примеры для популярных платформ.

Полный список заголовков и их семантика — см. HTTP-заголовки ответа Gateway.

Ключевые заголовки для интеграции

Заголовок Использование во внешней системе
X-LLMFW-Action Финальное решение AppSec.AIGate — ALLOW / BLOCK / SANITIZE / MONITOR_ONLY
X-LLMFW-Risk-Score Числовая оценка 0.000–1.000 — для пороговой логики (например, >0.8)
X-LLMFW-Risk-Severity Категория CRITICAL / HIGH / MEDIUM / LOW — для правил без явных числовых порогов
X-LLM-Firewall-Trace-ID Идентификатор для сквозной корреляции и поиска в SIEM
X-LLMFW-Would-Block true в режиме мониторинга — для оценки готовности к переводу в enforce

Примеры для WAF

Cloudflare Workers / Response Header Rules — логирование запросов высокого риска:

expression: http.response.headers["x-llmfw-risk-severity"][0] in {"CRITICAL" "HIGH"}
action:     log

Для блокировки клиентского ответа на стороне CDN при критическом риске:

expression: http.response.headers["x-llmfw-risk-score"][0] ge "0.800"
action:     block

Kong post-function plugin (log phase) — алерт в логи Kong при высоком риске:

local score_header = kong.response.get_header("x-llmfw-risk-score")
if score_header and tonumber(score_header) and tonumber(score_header) > 0.8 then
  kong.log.warn(
    "high-risk LLM request, trace=",
    kong.response.get_header("x-llm-firewall-trace-id"),
    " severity=",
    kong.response.get_header("x-llmfw-risk-severity")
  )
end

Envoy lua-фильтр в HTTP connection manager — добавление response-метаданных для журналирования:

http_filters:
  - name: envoy.filters.http.lua
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
      inline_code: |
        function envoy_on_response(handle)
          local severity = handle:headers():get("x-llmfw-risk-severity")
          if severity == "CRITICAL" or severity == "HIGH" then
            handle:streamInfo():dynamicMetadata():set(
              "llmfw", "risk", severity
            )
          end
        end

NGINX map + переменная для условного логирования:

map $upstream_http_x_llmfw_risk_severity $llmfw_high {
    CRITICAL 1;
    HIGH     1;
    default  0;
}

log_format llmfw_high '$remote_addr "$request" '
                     'risk=$upstream_http_x_llmfw_risk_score '
                     'severity=$upstream_http_x_llmfw_risk_severity '
                     'trace=$upstream_http_x_llm_firewall_trace_id';

access_log /var/log/nginx/llmfw_high.log llmfw_high if=$llmfw_high;

Интеграция с SIEM

Поля risk_score, risk_severity, would_block, would_action экспортируются в SIEM-форматах через Event Exporter AppSec.AIGate. Концептуальная настройка экспортеров — см. Экспорт событий (SIEM).

152-ФЗ: предупреждение о ПДн в событиях

События безопасности могут содержать персональные данные — например, сущности PII, обнаруженные детектором (email, телефон, ФИО, паспорт, СНИЛС, ИНН). При выгрузке событий во внешние системы (SIEM, Webhook, Kafka, файлы) вы выступаете оператором ПДн в смысле 152-ФЗ «О персональных данных» и обязаны:

  • обеспечить правовое основание обработки;
  • использовать защищённые каналы передачи (TLS, SASL/PLAIN over TLS, защищённый syslog);
  • применять адекватные меры защиты на стороне приёмника;
  • вести учёт операций обработки.

Если внешняя система не относится к контуру обработки ПДн — настройте фильтры экспортера, чтобы исключить события категории PII_DETECTED или включить маскирование PII-полей в маппинге.

CEF (ArcSight, MaxPatrol SIEM, QRadar)

Поля Risk Score маппятся в стандартные CEF-слоты:

CEF-слот Поле события Пример
cn4 + cn4Label=RiskScore risk_score cn4=0.847 cn4Label=RiskScore
cs10 + cs10Label=RiskSeverity risk_severity cs10=HIGH cs10Label=RiskSeverity
cn5 + cn5Label=WouldBlock would_block (0 / 1) cn5=1 cn5Label=WouldBlock

Раскладка CEF-слотов

AppSec.AIGate использует именно cn4 / cs10 / cn5 под Risk Score. Слоты cs5 и cs6 уже заняты другими полями события (PIIDetected, ModelName) — не перекрывайте их в кастомных маппингах.

Пример CEF-сообщения:

CEF:0|AppSec|AIGate|2.8|REQUEST_BLOCKED|Request blocked by policy|7|
src=10.0.0.42 suser=user42 act=BLOCK
cn4=0.847 cn4Label=RiskScore
cs10=HIGH cs10Label=RiskSeverity
cn5=0 cn5Label=WouldBlock

Syslog (RFC 5424)

В сообщениях RFC 5424 используется отдельный structured data element с PEN (Private Enterprise Number) AppSec:

[risk@12345 score="0.847" severity="HIGH" would_block="false"]

Пример полного syslog-сообщения:

<134>1 2026-05-28T10:23:45.123Z aigate AIGate 12345 REQUEST_BLOCKED
  [meta@12345 trace_id="7f3a4b2c"]
  [risk@12345 score="0.847" severity="HIGH" would_block="false"]
  Request blocked by security policy

Webhook / Kafka (JSON)

В Webhook и Kafka-экспортерах поля передаются в JSON-теле события напрямую:

{
  "event_type": "REQUEST_BLOCKED",
  "trace_id": "7f3a4b2c-9d1e-4f0a-b8c5-1234567890ab",
  "tenant_id": "default",
  "action": "BLOCK",
  "risk_score": 0.847,
  "risk_severity": "HIGH",
  "risk_breakdown": {
    "threat_detector": 0.428,
    "content_safety": 0.238,
    "pii": 0.105,
    "custom_policy": 0.050,
    "obfuscation": 0.026
  },
  "would_block": false,
  "would_action": null,
  "policy_version": "v2.4.0-dynamic"
}

В таком виде событие удобно индексировать в Elasticsearch / OpenSearch и далее анализировать в Kibana / Grafana.

Compliance-отчётность: запросы к API событий

Risk Score и severity доступны как фильтры в API security-событий. Это позволяет строить отчёты для службы безопасности и регулятора без выгрузки полного журнала:

# Все события с высоким и критическим риском за период
GET /api/v1/security-events?risk_severity=CRITICAL&start_time=2026-05-01T00:00:00Z&end_time=2026-05-31T23:59:59Z

# Все события с числовым риском выше порога
GET /api/v1/security-events?min_risk_score=0.8&start_time=2026-05-01T00:00:00Z

# Только события, которые были бы заблокированы в режиме enforce (актуально для оценки готовности профилей в Режиме мониторинга)
GET /api/v1/security-events?would_block=true&start_time=2026-05-01T00:00:00Z

Те же фильтры доступны на странице События безопасности в Admin UI.

Дополнительная информация