Безопасность и соответствие

AIDA работает on-premise, в вашем контуре. Доступ — ролевой, аутентификация — Keycloak, аудит — append-only. Изоляция тенантов — на уровне отдельных баз.

Ниже — без общих слов: какие роли, какими правами, где именно это проверяется.

Доступ — RBAC

Восемь ролей. Под капотом роль разворачивается в набор scope'ов — именно по scope'ам проверяется доступ, не по «названию должности».

УровеньРольScope'ыЧто может
Пользовательviewerseer:readсмотреть граф (Loom, Knot, Anvil)
Пользовательeditorseer:read, seer:write+ сохранять виды, аннотации, полный доступ к Mimir
Пользовательoperatorseer:read, aida:harvest+ запускать парсинг, видеть поток событий Dali
Тенантauditorseer:read, aida:audit+ просмотр и экспорт журнала аудита
Тенантlocal-admin+ aida:tenant:adminуправление пользователями и квотами тенанта
Тенантtenant-owner+ aida:tenant:ownerнастройки тенанта, биллинг, назначение local-admin
Платформаadminaida:admin (+ harvest/audit/tenant:admin)весь Heimdallr: метрики, снепшоты, кросс-тенантное управление
Платформаsuper-admin+ aida:superadminплатформа целиком: realm Keycloak, кросс-тенантные настройки

Один человек может иметь разные роли в разных тенантах — editor в одном, viewer в другом. Привязка хранится в JWT.

Где проверяется доступ (слои enforcement)

Не на клиенте «для красоты», а на сервере, по слоям:

  1. Chur (шлюз). Middleware requireScope / requireAnyScope проверяет наличие нужных scope'ов в сессии до проксирования. Любая запись (INSERT/UPDATE/DELETE/CREATE/DROP) требует ранга роли не ниже admin.
  2. Передача в бэкенд. Chur форвардит на SHUTTLE/Anvil заголовки X-Seer-Role, X-Seer-User, X-Seer-Tenant-Alias.
  3. Бэкенд (JAX-RS фильтр). На каждом запросе проверяется: заголовок тенанта валиден по формату и совпадает с привязкой тенанта в JWT (organization.alias). Несовпадение → запрос отклоняется (403), а не деградирует молча.

Аутентификация

  • Keycloak — единый источник истины. Realm seer, клиенты aida-bff и aida-bff-heimdall.
  • Протокол OAuth2 Authorization Code + PKCE (S256).
  • JWT несёт привязку пользователя к тенанту (организации Keycloak) и группы доступа. Поддерживается мульти-тенантный формат (роли по каждому тенанту) и одно-тенантный fallback.

Изоляция тенантов

Каждый тенант — в своей базе (hound_<тенант> для графа). Нет общей мультитенантной таблицы с фильтром по колонке — есть физически разные базы. Запрос без валидного тенанта до данных не доходит (см. слой enforcement выше). Память ассистента и кэш impact-анализа тоже изолированы по тенанту.

Аудит

  • Поток событий — append-only ControlEvent в Ygg.db: записи не изменяются и не удаляются.
  • Каждое событие идемпотентно (UUID) и упорядочено (fence-token).
  • Фиксируются операции с тенантами, участниками, действия управления.

Экспорт в SIEM (Splunk/ELK) — roadmap, пока не реализован. Не заявляем как готовое.

Суверенность ИИ — честно про два режима

  • Локальная или открытая модель: ассистент Mimir работает на локальной/открытой модели (через Ollama) в вашем контуре. Данные о схеме не покидают периметр — режим под требования 152-ФЗ к обработке в контуре организации.
  • Облачная модель: опция для команд, которым важнее скорость и не критичен выход за периметр.

Режим — это конфигурация, а не разные продукты. Выбирается под требования организации.

Соответствие — честный статус

АспектСтатус
On-premise, данные в контуре✅ есть
Локальная модель ИИ (on-prem поставка, без облака)✅ есть как режим
Спроектировано под 152-ФЗ✅ архитектурно
Формальная матрица соответствия 152-ФЗ⚪ в проработке
Сертификация ФСТЭК⚪ нет
SOC 2 / ISO 27001⚪ нет

Мы не заявляем сертификаций, которых нет. Архитектура построена под требования регуляторов — данные в контуре, локальный ИИ как режим, изоляция, аудит. Формальная сертификация — отдельный процесс; под требования вашей организации обсудим на техническом разборе.

Связанное