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

Схемы архитектуры

Эта страница — визуальное дополнение к разделу Архитектура и сценарии. Все схемы здесь нарисованы в Mermaid и рендерятся прямо в документации. Текстовое описание пайплайна, сценарии использования и пояснения — в основной статье об архитектуре.

Если коротко

AppSec.AIGate стоит между клиентом и LLM и проверяет трафик в обе стороны: запрос пользователя — перед отправкой в модель, ответ модели — перед возвратом пользователю. Решение (пропустить / заблокировать / замаскировать) принимает PDP на основе результатов детекторов.

Карта компонентов

Как сервисы продукта связаны между собой. Data plane (зелёное) обрабатывает LLM-трафик в реальном времени; Control plane (синее) — управление профилями и наблюдаемость; ML-детекторы — отдельный слой.

flowchart LR
    client["Клиент<br/>(приложение / чат-UI / LLM Gateway)"]
    llm["LLM backend<br/>(OpenAI / GigaChat / Ollama / …)"]

    subgraph DP["Data plane — обработка трафика"]
        gw["API Gateway"]
        ad["LLM Gateway Adapter<br/>(guardrail-режим)"]
        norm["Request Normalizer<br/>(field mapping, homoglyph)"]
        pdp["PDP / OPA<br/>(Rego-политики)"]
        vault["Tokenization Vault<br/>(токенизация PII)"]
        tr["Translation<br/>(RU→EN, опц., GPU)"]
    end

    subgraph ML["ML-детекторы и правила"]
        threat["Threat Detector<br/>(GPU)"]
        pii["PII Detector"]
        cs["Content Safety<br/>(GPU)"]
        cp["Content Policy Service"]
    end

    subgraph CP["Control plane — управление и события"]
        ui["Admin UI"]
        adm["Admin API"]
        reg["Profiles Registry<br/>(провайдеры, профили)"]
        exp["Event Exporter"]
        siem["SIEM<br/>(Syslog / CEF / Webhook / Kafka)"]
    end

    client -->|"LLM-запрос"| gw
    client -.->|"webhook<br/>(guardrail-режим)"| ad -.-> gw
    gw --> norm
    gw --> tr
    gw --> threat & pii & cp & cs
    gw --> pdp
    gw -->|"маскирование"| vault
    gw -->|"проксирование, если ALLOW/SANITIZE"| llm
    llm -->|"ответ"| gw
    gw -->|"ответ клиенту"| client

    reg -.->|"профиль + провайдер<br/>(кэш в Redis)"| gw
    pdp -.->|"бандл политик<br/>(через MinIO)"| reg
    ui --> adm --> reg
    gw -->|"события безопасности"| exp --> siem

    classDef dp fill:#e6f4ea,stroke:#34a853,color:#111;
    classDef cp fill:#e8f0fe,stroke:#4285f4,color:#111;
    classDef ml fill:#fef7e0,stroke:#f9ab00,color:#111;
    class gw,ad,norm,pdp,vault,tr dp;
    class ui,adm,reg,exp,siem cp;
    class threat,pii,cs,cp ml;

Путь запроса и ответа

Полный путь одного chat-completion запроса через пайплайн. Детекторы на каждом этапе запускаются параллельно — это держит задержку минимальной.

sequenceDiagram
    autonumber
    participant C as Клиент
    participant G as API Gateway
    participant N as Normalizer
    participant D as Детекторы (||)
    participant P as PDP (Rego)
    participant L as LLM backend

    Note over C,L: ВХОД — защита модели и данных
    C->>G: LLM-запрос
    G->>N: нормализация + field mapping + homoglyph
    G->>D: Threat ∥ PII ∥ Content Policy
    D-->>G: риск-скоры, PII, флаги правил
    G->>P: агрегировать + пороги профиля
    P-->>G: ALLOW / BLOCK / SANITIZE / MONITOR_ONLY

    alt BLOCK
        G-->>C: 403 + причина (запрос в модель не уходит)
    else SANITIZE
        G->>G: маскирование PII
        G->>L: запрос с замаскированными данными
    else ALLOW / MONITOR_ONLY
        G->>L: исходный запрос
    end

    Note over C,L: ВЫХОД — защита пользователя и инфраструктуры
    L-->>G: ответ модели
    G->>D: Content Safety ∥ Output PII ∥ Content Policy
    D-->>G: категории, секреты, флаги
    G->>P: оценка ответа
    P-->>G: ALLOW / BLOCK / REDACT
    G-->>C: ответ (или блокировка / с вырезанными секретами)

Двусторонняя инспекция

На входе и на выходе работают разные наборы детекторов — потому что угрозы с двух сторон разные.

flowchart LR
    subgraph IN["ВХОД · запрос пользователя"]
        direction TB
        i1["Threat Detector<br/>jailbreak / prompt injection"]
        i2["PII Detector<br/>персональные данные"]
        i3["Content Policy<br/>кастомные правила"]
    end
    subgraph OUT["ВЫХОД · ответ модели"]
        direction TB
        o1["Content Safety<br/>опасные категории"]
        o2["Output PII Detector<br/>секреты, тех-данные"]
        o3["Content Policy<br/>правила (scope=output)"]
    end
    IN -->|"PDP"| dIn["ALLOW / BLOCK / SANITIZE / MONITOR_ONLY"]
    OUT -->|"PDP"| dOut["ALLOW / BLOCK / REDACT"]

Заголовки результата

К каждому ответу Gateway добавляет служебные заголовки X-LLMFW-* — по ним downstream-системы (WAF, reverse-proxy, мониторинг) принимают решения, не читая тело ответа. Полный список — в справочнике HTTP-заголовки ответа.

Заголовок Значение
X-LLMFW-Action ALLOW / BLOCK / SANITIZE / MONITOR_ONLY
X-LLMFW-Risk-Score риск-скор, напр. 0.847
X-LLMFW-Risk-Severity CRITICAL / HIGH / MEDIUM / LOW
X-LLM-Firewall-Trace-ID идентификатор трассировки запроса

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