Governance и согласование (human-in-the-loop)

Эта страница для оператора, который подключил хотя бы один источник и теперь должен управлять (govern) estate: решать, кто и что может действовать, просматривать то, что выводит платформа, и реагировать на это. Governance живёт в модуле VI (идентичность, разрешения, governance), сидит на том же ядре авторизации, что и остальной API, и полностью аудируется.

Что работает сегодня — это ядро авторизации: RBAC с deny-by-default, шов политики «только ограничивает», доступ с привязкой к арендатору и append-only подписанный журнал аудита, фиксирующий каждое governance-решение и каждое привилегированное чтение, — плюс работающий движок согласований human-in-the-loop: управляемые запросы на согласование, привязанные к хешу плана, открываемые deny-closed и ограниченные по времени, с разделением обязанностей, контролем дублирующего решающего и истечением срока, обеспечиваемыми на стороне сервера, и конечными точками approve/deny в пространстве имён модуля governance. Что ещё созревает — это более богатая поверхность операторского обзора: полноценная консоль очереди согласований и структурированный UI обзора. Эта страница описывает модель, живые конечные точки и гарантию зафиксированных решений; где операторский UI ещё на стадии проектной разработки, об этом сказано.

Модель авторизации, в рамках которой вы управляете

Каждое governance-решение принимается тем же ядром авторизации, что защищает остальной control plane. Поймите три его свойства, прежде чем что-либо менять.

RBAC работает по принципу deny-by-default

Авторизация выполняет сначала RBAC. Принципал без членства в арендаторе получает отказ — неявного гранта нет. Разрешения привязаны к арендатору, и обработчик действует только в единственном арендаторе, к которому разрешился запрос, а не в том, который он перевыводит, что конструктивно закрывает классы confused-deputy и IDOR.

Встроенные роли образуют лестницу нарастающих возможностей:

Роль	Что она может
`viewer`	читать операционные данные и аудиторский след
`editor`	вышеперечисленное плюс запись операционных данных
`admin`	вышеперечисленное плюс арендный IAM — пользователи, членства, токены, настройки
`owner`	все разрешения в пределах арендатора

Модуль объявляет собственные разрешения в своём пространстве имён (<namespace>:<resource>:<verb>), а роли получают эти разрешения по уровням глаголов (viewer отображается на read, editor — на write, admin и owner — на admin). Поэтому новый модуль вводит governance-поверхность без релиза движка.

Карта доступа R/RW модуля III — самый чувствительный актив в продукте: карта того, до чего может дотянуться каждый агент, — это разведывательная дорожная карта для атакующего. Поэтому чтение графа доступа — привилегированное действие, предоставляемое с роли editor и выше — никогда не самой нижней viewer. Оно привязано к арендатору (чтение может видеть граф только одного арендатора), и каждое чтение записывается в журнал аудита — кто смотрел на чей доступ и когда. Привилегия, привязка к арендатору и самоаудит наслоены намеренно; см. модель безопасности.

Шов политики (ABAC/PDP) только ограничивает

Поверх RBAC оператор может подключить внешнюю точку принятия решений политики (policy decision point, PDP) для правил на основе атрибутов. Вы выбираете движок одной переменной окружения:

# Choose one. Cedar is the embedded, pure-Go primary; OPA is an over-HTTP adapter.
OLIVARES_PDP_ENGINE=cedar   # or: opa | none

Оба движка сидят за одним швом, и у этого шва есть один инвариант, определяющий, как вы должны о нём рассуждать:

Два адаптера сохраняют этот инвариант по-разному, и вы соответственно пишете политику:

Cedar (встроенный, основной, на чистом Go). Вы пишете правила forbid. Сработавшее правило — это ограничение; пустой набор правил означает, что решение RBAC остаётся в силе. permit в Cedar никогда не может расширить решение.
OPA (по HTTP). Ваш Rego должен быть permit-by-default (default allow := true, с предложениями allow := false для ваших отказов). Результат true означает отсутствие ограничения; false, отсутствующий результат либо любая транспортная или не-2xx ошибка отказывает закрыто (fails closed) — запрос отклоняется.

Недопустимая конфигурация PDP отключает только внешний PDP и логирует этот факт — нативный ABAC и RBAC продолжают управлять. Неверно сконфигурированный движок политики никогда не оставляет запросы неуправляемыми и никогда не валит control plane. Каждое ограничение, которое применяет PDP, аудируется.

Что выводимое говорит вам, на что реагировать

Governance в режиме human-in-the-loop управляется тем, что платформа наблюдает и представляет. Два потока сообщают оператору, что заслуживает решения:

Поток	Модуль	Что он выводит
Least-privilege drift	III (карта доступа)	дифф permitted-vs-observed — предоставленная возможность, использованная способом, который никто не задумывал, или путь, достижимый, но никогда не задействованный
Находки	IX (безопасность, guardrails, форензика)	находки guardrail и red-team, плюс поток уведомлений, который маршрутизирует платформа

Модуль III, карта доступа, read-first — он наблюдает через логи, OpenTelemetry и (как некооперативный заслон на уровне ядра) eBPF, и никогда не находится в пути данных агента, поэтому отказ коллектора не может сломать продакшен. Он также minimal-data: он хранит отношение agent → resource (read/write), никогда полезные нагрузки, секреты или PII. Сигнал, который он несёт, честен относительно собственной уверенности (attributed против approximate) и собственного охвата.

Точность карты доступа зависит от ресурса. Покрытие многоуровневое: чистое для SQL-баз, объектных хранилищ и хранилищ данных (нативный аудит классифицирует чтение против записи дословно); с потерями для хранилищ вроде документных и векторных баз; и невозможное для пассивного наблюдения для in-memory и встроенных хранилищ. Управляйте с учётом этого: отсутствие наблюдаемого доступа не является доказательством отсутствия доступа там, где покрытие с потерями или отсутствует. Прочитайте модель угроз о том, что каждый уровень может и не может засвидетельствовать.

Один класс сигналов требует явного governance-суждения. Аннотации инструментов MCP (readOnlyHint / destructiveHint) — полезная подсказка read/write, но они недоверенные по спецификации MCP — клиенты должны рассматривать их как недоверенные. Платформа подтверждает (corroborates) их против доверенных сигналов и никогда не доверяет им в одиночку, и вам следует поступать так же, реагируя на элемент дрейфа, опирающийся только на аннотацию.

Постура human-in-the-loop

Задуманный governance-цикл таков: выводимое представляется (дрейф из модуля III, находки из модуля IX) → уполномоченный оператор решает → решение фиксируется в журнале аудита.

Все три части этого цикла работают сегодня. Выводимое реально — модуль III производит дифф permitted-vs-observed, а модуль IX производит находки. Движок согласований реален — управляемый запрос на согласование открывается против модуля governance (deny-closed, привязан к хешу плана, ограничен по времени); уполномоченный оператор одобряет или отклоняет через конечную точку решения, а разделение обязанностей, контроль дублирующего решающего и истечение срока обеспечиваются на стороне сервера, поэтому запрашивающий никогда не может решить собственный запрос, а истёкший никогда не может связать. И фиксация реальна и сильна — см. гарантию ниже. Что ещё на стадии проектной разработки — это развёрнутая операторская консоль обзора — богатый UI очереди согласований; конечные точки и движок поставлены, отполированная поверхность обзора — путь вперёд для модуля VI.

Зависимость, которая делает этот цикл правдоподобным, — это идентичность на каждого агента (per-agent identity). Аудит платформы атрибутирует активность учётным данным или роли, а не агенту по сути; разделяемая сервисная учётная запись с пулом соединений схлопывает атрибуцию. Поэтому хорошее управление означает выпуск и обеспечение идентичности на каждого агента — мост от наблюдения (модуль III) к governance (модуль VI). Идентичная сторона этого построена вокруг непрозрачных, отзываемых first-party учётных данных и реестра нечеловеческих идентичностей; единственный примитив чеканки учётных данных в продукте — opt-in, аттестованный, аудируемый и никогда не сохраняющий отчеканенный токен. См. каталог модулей о том, как идентичность, разрешения и governance композируются по всему estate.

Какова бы ни была глубина рабочего процесса над этим, governance-решение — зафиксированный факт. Мутирующие действия дописываются в журнал аудита с реальным актором в той же транзакции, что и изменение, а чувствительные чтения (граф доступа, сам журнал) самоаудируются в зафиксированной записи. Журнал append-only, hash-chained и защищён подписями Ed25519 — каждая запись несёт seq, prev_hash, hash и sig, поэтому переписывание истории криптографически обнаружимо, и он никогда не содержит PII. Вы не можете сделать неуправляемое изменение, о котором журнал тихо забудет.

Получите запись из коробки

Для внешней, неизменяемой копии — того, что просит корпоративный аудитор и чего нативная телеметрия не предоставляет — журнал выставляется как аутентифицированный pull-экспорт:

# Pull the signed, hash-chained ledger for offline re-verification.
# Requires a token whose role can read the audit trail (viewer and up).
curl -fsS "https://localhost:8443/v1/audit/export?format=cef" \
  -H "Authorization: Bearer $OLVK_TOKEN" \
  -H "X-Olivares-Tenant: $TENANT" >> /var/log/olivares/audit.cef

Поддерживаемые значения format — cef, leef, syslog, otlp, otlp_envelope, otlp_log_record и ocsf: otlp выдаёт полный, готовый к отправке запрос экспорта, otlp_envelope — его точный псевдоним, а otlp_log_record — простая проекция с одним LogRecord на строку. Каждая запись несёт поля целостности цепочки, чтобы ваша SIEM или WORM-хранилище могли переверифицировать цепочку офлайн. Отсоединённая подпись защищает от компрометации только БД (инъекция, украденный бэкап или реплика, обходящая-RLS роль) и от удаления контрольной точки; копия вне коробки — это контроль против полностью скомпрометированного хоста. См. форвардинг аудита в Splunk для полного конвейера чтения хвоста файла.

Least-privilege drift, на который реагируют эти решения, — это результат permitted-vs-observed карты доступа. Туториал «от нуля до графа» проходит достижение его конкретно на демо-estate; поверхность модуля карты доступа подчинена тому же RBAC с deny-by-default, привязке к арендатору и поаудиту каждого чтения, что и всё остальное, поэтому её чтение — действие editor-и-выше.

Куда двигаться дальше

Модель безопасности — привилегия, привязка к арендатору, самоаудит и постура minimal-data в полном объёме.
Модель угроз — активы, границы доверия и то, что может засвидетельствовать каждый уровень покрытия.
Каталог модулей — как идентичность, разрешения и governance (модуль VI) композируются с картой доступа (модуль III) и находками (модуль IX).
Подключите источник — подключите сигналы, из которых строятся дрейф и находки.