Перейти к содержимому
Olivares AI docs

Модель угроз (STRIDE / DFD)

Olivares AI — это продукт безопасности, который работает на ваших собственных хостах и строит карту того, до чего может дотянуться каждый агент. Это делает изъян вендора эквивалентным компрометации клиента — поэтому продукт спроектирован так, чтобы проходить корпоративный пентест с первого дня, а модель угроз публикуется, а не скрывается.

Метод

Заголовок раздела «Метод»

Модель использует STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) над диаграммой потока данных (DFD) с её границами доверия. Перечисленные здесь митигации проверены относительно внутренней матрицы упрочнения продукта; эта страница публикует позицию (posture), а не доказательства на уровне кода.

Руководящие принципы

Заголовок раздела «Руководящие принципы»
  • Read-first = низкий асимметричный риск. Движок наблюдает через логи, OpenTelemetry и eBPF. Он не находится в пути данных агента, так что отказ коллектора не может сломать продакшн-трафик.
  • Минимальные данные. Граф хранит отношения — инициатор → ресурс, чтение/запись, источник сигнала, уверенность, временную метку — никогда полезные нагрузки, тела SQL, секреты или PII. Что не хранится, то не утечёт.
  • Self-hosted = поставщика нет на пути данных. Обязательной телеметрии нет, исходящий трафик управляющей плоскости по умолчанию отсутствует, и Olivares AI никогда не находится на пути данных. К поставщику обращаются только тогда, когда вы сами что-то у него запрашиваете — olivares upgrade или загрузка коммерческих надстроек и их обновлений по подписке, — но никогда как побочный эффект работы. И olivares upgrade --endpoint направляет даже это на ваше собственное зеркало. За периметр клиента выходит только то, что сам клиент настроил для передачи наружу: обращения к API его моделей, подключённые им выходы SIEM/webhook и внешний поставщик эмбеддингов, если клиент его настроил. Это выбранные клиентом третьи стороны; утверждение о поставщике относится к Olivares AI, а не к ним.

Активы

Заголовок раздела «Активы»

| Актив | Почему он чувствителен | |---|---| | Граф доступа | Карта того, до чего может дотянуться каждый агент. Самый чувствительный актив — он управляется соответственно (см. митигации). | | Доступ коллектора к хосту | Он читает логи/OTEL/eBPF на продакшн-хостах; компрометация была бы плацдармом для разворота (pivot). | | Журнал доказательств / аудита | Если тихо изменён, продукт стал бы лгать. Целостность — это всё. | | Лицензионные ключи | Подделка обошла бы коммерческий ограничитель. | | Учётные данные панели | Доступ означает видеть всю среду агентов клиента. |

Поскольку граф доступа — самый чувствительный актив, его просмотр — привилегированное действие — предоставляемое с роли editor и выше, никогда низшей роли viewer — ограниченное арендатором (tenant), и каждое чтение аудируется. Защита многослойна: привилегия, изоляция арендаторов и самоаудит.

Границы доверия и поток данных

Заголовок раздела «Границы доверия и поток данных»

Существует четыре границы доверия:

  1. host sources → collector
  2. collector → core (сетевая граница)
  3. user → panel
  4. core → store
  CUSTOMER INFRASTRUCTURE                         CONTROL PLANE (self-hosted or managed)
  ┌─ Collectors (edge) ───────────────┐           ┌─ Engine (Go) ───────────────────────────┐
  │ • OTLP receiver (agents)          │           │ Ingest + event bus                       │
  │ • MCP / skills introspection      │ ──mTLS──▶  │ Connector SDK · Module runtime           │
  │ • Tail audit (pgAudit/CloudTrail) │  gRPC     │ Multi-tenant data model                  │
  │ • eBPF backstop (Tetragon)        │  +bearer  │ REST/gRPC API · AuthN/Z                   │
  └───────────────────────────────────┘           │ Append-only, hash-chained audit          │
        (1) host sources → collector               └──────────────┬───────────────────────────┘
        (2) collector → core (network)                            │ go:embed         (4) core → store
                                                     ┌────────────▼─────────┐   ┌──────────────────┐
                                       (3) user ───▶ │ Web panel (React)    │   │ Access-graph     │
                                           → panel   └──────────────────────┘   │ store + ledger   │
                                                                                 └──────────────────┘

Плоскость данных (коллекторы) всегда работает на инфраструктуре клиента. Коллекторы push’ат в ядро; они не выставляют никакого входящего слушателя.

STRIDE — основная угроза и митигация по каждому компоненту

Заголовок раздела «STRIDE — основная угроза и митигация по каждому компоненту»

Модель фиксирует основную угрозу(-ы) для каждого компонента и митигацию, которая её адресует (не исчерпывающую сетку).

| Компонент | Основная угроза | Митигация | |---|---|---| | Collector | Elevation (eBPF требует возможностей ядра), Tampering бинарника | минимальные возможности (CAP_BPF/CAP_PERFMON, не полный root); подписанный бинарник; нет входящего слушателя (push-модель) | | Collector → core | Information disclosure, Spoofing | TLS ≥ 1.2 по умолчанию, без отката на cleartext (fail-closed) + bearer-токен; AutoMTLS на локальном плагин-канале; опциональный mTLS с проверенным клиентским сертификатом для удалённых коллекторов | | Access-graph store | Information disclosure в покое | шифрование в покое, предоставляемое развёртыванием (LUKS/FS/TDE); маскирование/хеш чувствительных значений, принуждаемое на стороне движка на пути записи | | Evidence ledger | Tampering, Repudiation | append-only + hash-chain (+ контрольные точки, подписанные Ed25519); экспорт во внешнюю копию WORM/SIEM | | Panel | Spoofing, Elevation | нет учётных данных по умолчанию; одноразовый токен настройки при первом запуске; RBAC; защищённые сессии; самоаудит (кто что просматривал/менял) | | License key | Spoofing | подпись Ed25519, офлайн-валидация; отзыв через истечение подписки |

От чего эта модель не защищает

Заголовок раздела «От чего эта модель не защищает»

Честность о краях модели — часть модели:

  • Root хоста / суперпользователь базы данных может изменить локальный журнал на диске. Hash-chain делает переписывания до контрольной точки криптографически обнаружимыми, но реальный контроль защиты от подделки — это экспорт журнала во внешнюю копию WORM/SIEM, до которой локальный оператор не может дотянуться. Включите его.
  • Шифрование хранилища в покое — ответственность оператора — продукт маскирует/хеширует чувствительные значения, но шифрование диска/FS/TDE обеспечивает развёртывание.
  • Покрытие карты доступа многоуровневое (чистое на аудируемых хранилищах, с потерями на некоторых, невозможное для пассивной реконструкции на других). Отсутствующее ребро не является доказательством того, что доступа не было — читайте Честность и пределы.
  • Скомпрометированный хост коллектора — серьёзное событие; коллектор работает только на чтение с минимальными привилегиями и без входящего слушателя, чтобы сжать этот радиус поражения, но компрометация хоста находится вне того, что плоскость управления сама по себе может предотвратить.

Связанное

Заголовок раздела «Связанное»