Архитектура Шины Событий

Шина Событий — центральная нервная система Sentinel AI SOC: 10-шаговый pipeline, обрабатывающий каждое ИБ-событие от приёма до реагирования.

Философия проектирования

Почему HTTP/2 JSON, а не gRPC?

Sentinel использует HTTP/2 JSON для всего межкомпонентного взаимодействия. Это осознанное архитектурное решение:

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

Валидация Red Team: В ходе боевых red team учений разница в ~5% пропускной способности оказалась несущественной для SOC-нагрузок (цель: ≥500 событий/сек). Инвариант Zero CGO устраняет целые классы проблем сборки и деплоя.

Архитектура Pipeline

┌─────────────┐
│   Сенсор    │  (sentinel-core, Shield, immune, custom)
└──────┬──────┘
       │ HTTP POST /api/v1/soc/events
       ▼
┌──────────────────────────────────────────────────────┐
│                    ШИНА СОБЫТИЙ                       │
│                                                      │
│  Шаг 0: Секретный Сканер (ИНВАРИАНТ — нельзя откл.) │
│       ↓                                              │
│  Шаг 1: Аутентификация сенсора (PSK / mTLS)         │
│       ↓                                              │
│  Шаг 2: Rate Limiter (≤100/сек на сенсор)            │
│       ↓                                              │
│  Шаг 3: Дедупликация (скользящее окно 10с)           │
│       ↓                                              │
│  Шаг 4: Валидация схемы (AlertEvent JSON Schema)     │
│       ↓                                              │
│  Шаг 5: Decision Logger (SHA-256 хэш-цепочка)       │
│       ↓                                              │
│  Шаг 6: Персистентность (SQLite WAL)                 │
│       ↓                                              │
│  Шаг 7: Движок корреляции (15 правил)                │
│       ↓                                              │
│  Шаг 8: Триггер Playbook (авто-ответ ≤ MEDIUM)      │
│       ↓                                              │
│  Шаг 9: Webhook / SSE Push (дашборд + внешние)       │
│                                                      │
└──────────────────────────────────────────────────────┘

Детали шагов

Шаг 0: Секретный Сканер

Тип: ИНВАРИАНТ — не может быть отключён никакой конфигурацией.

Сканирует каждый входящий payload на предмет утёкших секретов:

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

При обнаружении секрета событие:

1. Редактируется — секрет заменяется на [REDACTED:key_type]
2. Помечается — добавляются метаданные secret_detected: true
3. Пересылается — обработка продолжается с очищенным payload

// pipeline.go — Секретный Сканер всегда первый
func (p *Pipeline) Process(event *AlertEvent) error {
    // Шаг 0: Secret Scanner (ИНВАРИАНТ — никогда не пропускать)
    event.Payload = p.secretScanner.Scan(event.Payload)
    
    // Все последующие шаги...
}

Шаг 1: Аутентификация сенсора

Каждый сенсор должен аутентифицироваться перед приёмом событий:

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

# spectorn.yaml
sensors:
  - type: sentinel-core
    auth:
      type: "psk"
      key: "${SENSOR_CORE_PSK}"

Шаг 2: Rate Limiter

Алгоритм Token Bucket для каждого sensor_id:

• По умолчанию: 100 событий/сек на сенсор
• Burst: 150 событий (1.5x bucket)
• Переполнение: События в очередь, затем сброс с предупреждением

Сенсор → [Token Bucket: 100/сек] → Принять или Очередь

При превышении лимита:

1. SOC генерирует алерт rate_limit_exceeded
2. События ставятся в очередь (до ёмкости буфера)
3. При переполнении очереди — сброс с инкрементом метрики dropped_events

Шаг 3: Дедупликация

Дедупликация по скользящему окну с использованием отпечатков:

Fingerprint = SHA256(source + category + description + severity)

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

Дубликаты отбрасываются тихо. Метрика dedup_count отслеживает отфильтрованные.

Шаг 4: Валидация схемы

Каждое событие должно соответствовать описанной ниже схеме AlertEvent:

{
  "source": "sentinel-core",    // Обязательно: идентификатор сенсора
  "severity": "HIGH",           // Обязательно: INFO|LOW|MEDIUM|HIGH|CRITICAL
  "category": "jailbreak",      // Обязательно: категория атаки
  "description": "...",         // Обязательно: описание
  "confidence": 0.95,           // Опционально: 0.0-1.0
  "payload": {},                // Опционально: доп. данные
  "timestamp": "2026-03-13T..." // Авто-заполнение если не указан
}

Невалидные события отклоняются с HTTP 400 и логируются.

Шаг 5: Decision Logger

Неизменяемый аудиторский след на основе SHA-256 хэш-цепочек:

Запись N:
  event_id: EVT-1710295200-042
  action: "accepted"
  timestamp: 2026-03-13T01:00:00Z
  prev_hash: "a3b8c1d2e5f6..."
  hash: SHA256(entry_data + prev_hash) = "7f8e9d0c..."

Каждая запись криптографически связана с предыдущей. Любая модификация разрывает цепочку и обнаруживается через gomcp doctor.

Хранение: Append-only JSONL файл с флагом O_APPEND (атомарность на уровне ядра).

Опционально: TPM 2.0 sealing для аппаратной привязки целостности (SEC-006).

Шаг 6: Персистентность

События сохраняются в SQLite в режиме WAL (Write-Ahead Logging):

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

Шаг 7: Корреляция

События сверяются с 15 правилами корреляции. Подробности — Движок Корреляции.

Шаг 8: Триггер Playbook

При совпадении правила корреляции и наличии настроенного playbook:

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

Шаг 9: Webhook / SSE Push

После обработки события и инциденты отправляются:

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

Кольцевой буфер

Шина событий использует lock-free кольцевой буфер для приёма:

┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ 0 │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ 9 │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
  ↑                           ↑
  Указатель чтения            Указатель записи

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

Метрики

Шина событий экспортирует метрики Prometheus:

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

Обработка ошибок

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

Дальнейшие шаги

• Движок Корреляции — Правила и кластеризация
• Схема AlertEvent — Контракт валидации
• Метрики — Опубликованные метрики Prometheus