Архитектура и сценарии¶
Типовые сценарии использования¶
Сценарий 1: Защита корпоративного чат-бота¶
Компания развернула внутренний чат-бот на базе LLM для сотрудников. AppSec.AIGate устанавливается между фронтендом чат-бота и LLM API. Настраиваются:
- Threat Detection — для блокировки jailbreak-попыток сотрудников.
- PII Detection в режиме
mask— чтобы сотрудники не отправляли клиентские данные в LLM, при этом запрос всё равно доходит до модели (с замаскированными данными). - Content Safety — для блокировки неуместных ответов модели.
- Content Policy типа
blocklist— для запрета обсуждения конфиденциальных проектов по названию.
Сценарий 2: API-шлюз для внешних LLM-провайдеров¶
Компания использует несколько LLM-провайдеров (OpenAI для английского, GigaChat для русского). AppSec.AIGate работает как единая точка входа:
- Настроены два провайдера с разными mapping presets.
- Роутинг по заголовку
X-LLM-Providerнаправляет запросы к нужному backend. - Единый профиль безопасности применяется ко всем провайдерам.
- SIEM-экспорт отправляет все события в корпоративный Splunk.
Сценарий 3: Соответствие 152-ФЗ¶
Организация обязана защищать персональные данные по 152-ФЗ. AppSec.AIGate обеспечивает:
- PII Detection в режиме
block— запросы с персональными данными блокируются полностью. - Output PII Detection — перехватывает случаи, когда LLM возвращает ПДн в ответе.
- Data Retention с
pii_scrub— автоматическое удаление ПДн из логов по истечении срока хранения. - Compliance Reports типа
pii_dlp— регулярные отчёты для предоставления регулятору.
Сценарий 4: Режим наблюдения при пилотном запуске¶
Перед включением блокировки в продакшене организация хочет оценить, как система будет работать. AppSec.AIGate запускается в Monitor Mode:
- Все детекторы работают и генерируют события.
- Ни один запрос не блокируется — пользователи не затронуты.
- Команда безопасности анализирует события и тюнит пороговые значения.
- После калибровки Monitor Mode отключается и система начинает блокировать реальные угрозы.
Архитектура обработки запроса¶
Схема ниже показывает путь запроса и ответа через все компоненты AppSec.AIGate:
ЗАПРОС (INPUT) ОТВЕТ (OUTPUT)
Клиент ──▶ Nginx ──▶ API Gateway ──▶ LLM Backend LLM Backend ──▶ API Gateway ──▶ Клиент
│ │
┌─────┴─────┐ ┌──────┴──────┐
▼ ▼ ▼ ▼
┌───────────┐ ┌──────────┐ ┌───────────┐ ┌──────────┐
│ Homoglyph │ │ Field │ │ Field │ │ │
│ Normalize │ │ Mapping │ │ Mapping │ │ │
└─────┬─────┘ └────┬─────┘ └─────┬─────┘ │ │
└──────┬─────┘ │ │ │
▼ ▼ │ │
┌────────┼────────┐ ┌──────────┼────────┤ │
▼ ▼ ▼ ▼ ▼ ▼ │
┌─────────┐┌──────┐┌──────────┐ ┌──────────┐┌─────────┐┌──────────┐ │
│ Threat ││ PII ││ Content │ │ Content ││ Output ││ Content │ │
│Detector ││Detect││ Policy │ │ Safety ││ PII ││ Policy │ │
│ ││ ││ Service │ │ ││Detector ││ Service │ │
└────┬────┘└──┬───┘└────┬─────┘ └────┬─────┘└────┬────┘└────┬─────┘ │
└────────┼─────────┘ └───────────┼─────────┘ │
▼ ▼ │
┌─────────────┐ ┌─────────────┐ │
│ PDP │ │ PDP │ │
│ (Rego) │ │ (response) │ │
└──────┬──────┘ └──────┬──────┘ │
▼ ▼ │
ALLOW / BLOCK / SANITIZE ALLOW / BLOCK / REDACT │
│ │ │
└─────────── Security Event ──────────────┘ │
▼ │
┌─────────────┐ │
│ Event Bus │◄───────────────────────────────────┘
│ (export) │
└──────┬──────┘
┌──────┬──────┼──────┬──────┐
▼ ▼ ▼ ▼ ▼
Syslog CEF Webhook Kafka File
Пояснение к схеме:
-
Nginx — точка входа. Перенаправляет трафик к API Gateway на основе конфигурации маршрутов (см. Настройка Nginx).
-
Field Mapping — API Gateway определяет, какому провайдеру принадлежит запрос (по URL, хосту или заголовку), и через mapping preset извлекает пользовательский промпт из структуры запроса.
-
Homoglyph Normalize — нормализация текста для защиты от unicode-обфускации. Применяется до всех детекторов.
-
Параллельная детекция (Input) — три детектора работают одновременно:
- Threat Detector — ML-классификация safe/unsafe.
- PII Detector — обнаружение персональных данных.
- Content Policy Service — проверка по кастомным правилам.
-
PDP (Policy Decision Point) — движок принятия решений на базе Rego. Собирает результаты всех детекторов и принимает финальное решение:
- ALLOW — запрос безопасен, передать к LLM.
- BLOCK — запрос опасен, вернуть ошибку клиенту.
- SANITIZE — PII обнаружены, замаскировать и передать к LLM.
- MONITOR — угроза обнаружена, но система в режиме наблюдения — пропустить, создать событие.
-
Параллельная детекция (Output) — три детектора для ответа LLM:
- Content Safety — ML-классификация по 9 категориям.
- Output PII Detector — поиск секретов и технических данных.
- Content Policy Service — проверка ответа по правилам (если scope =
outputилиboth).
-
Event Bus — все события безопасности отправляются во внешние системы через настроенные экспортеры.
Двусторонняя инспекция¶
AppSec.AIGate проверяет трафик в обоих направлениях. Это принципиально важно, потому что угрозы существуют с обеих сторон: пользователь может отправить опасный запрос, а LLM может вернуть опасный ответ.
Входящий запрос (Input) — защита LLM от пользователя¶
| Шаг | Действие | Цель |
|---|---|---|
| 1 | Определение провайдера по маршруту | Понять, к какому LLM направлен запрос |
| 2 | Извлечение user prompt через field mapping | Получить текст промпта из структуры API-запроса |
| 3 | Homoglyph-нормализация текста | Нейтрализовать unicode-обфускацию |
| 4 | Перевод RU→EN (если нужно для ML-детекторов) | ML-модели обучены на английском, перевод повышает точность |
| 5 | Параллельная детекция: Threat + PII + Content Policy | Три проверки одновременно для минимальной задержки |
| 6 | Решение PDP: ALLOW / BLOCK / SANITIZE / MONITOR | Финальное решение на основе всех детекторов |
Исходящий ответ (Output) — защита пользователя от LLM¶
| Шаг | Действие | Цель |
|---|---|---|
| 1 | Извлечение текста ответа через field mapping | Получить сгенерированный текст из структуры ответа LLM |
| 2 | Параллельная детекция: Content Safety + Output PII + Content Policy | Три проверки одновременно |
| 3 | Решение PDP: ALLOW / BLOCK / REDACT | Финальное решение: пропустить, заблокировать или вырезать секреты |
Важно
Детекторы на входе и выходе — разные. На входе работают Threat Detection и PII Detection (защита модели и данных), на выходе — Content Safety и Output PII Detection (защита пользователя и инфраструктуры). Content Policy может работать в обоих направлениях.