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

Модуль III — карта доступа чтения/записи

Модуль III — это карта доступа чтения/записи: какой инициатор (агент, идентичность, сессия) обращается к какому ресурсу, классифицировано как чтение или чтение-запись, и diff Permitted-vs-Observed, который выявляет дрейф наименьших привилегий. Это одна из самых полезных и дифференцирующих возможностей продукта — один из 30 модулей, а не весь продукт. Эта страница — справочник по тому, что представляет собой карта и как читать её честно.

Ребро

Заголовок раздела «Ребро»

Карта — это граф рёбер. Каждое ребро — это нормализованный факт с минимальными данными инициатор → ресурс, несущий:

ПолеЗначенияСмысл
moderead | write | readwrite | unknownклассификация чтения/записи (unknown, когда её невозможно определить — никогда не угадывается)
sourceotel | mcp_annotation | pg_audit | cloudtrail | ebpf | policy | a2aкакой сигнал породил ребро
confidenceattributed | approximateнасколько твёрдо доступ привязан к инициатору

Рёбра приходят на шину событий как события edge.observed, и движок сливает их в сохраняемую сущность AccessEdge — которая сама несёт обе стороны, permitted и observed, поэтому карта доступа является представлением поверх общей модели данных, а не отдельным хранилищем.

Как строятся рёбра

Заголовок раздела «Как строятся рёбра»

Модуль III пересекает два пути:

  • Совместный путь — агенты, испускающие OpenTelemetry (otel) и предоставляющие серверы MCP. В сочетании с аудитом нативного хранилища это высокоточно: Postgres pgAudit (pg_audit) классифицирует READ/WRITE дословно; AWS CloudTrail (cloudtrail) даёт readOnly для S3; хранилища данных — аналогично.
  • Несовместный путь — резервный механизм на уровне ядра eBPF/Tetragon (ebpf) фиксирует MAY_READ/MAY_WRITE на уровне системных вызовов, вне контроля агента (анти-уклонение), будучи слеп к зашифрованному телу.

Аннотации инструментов MCP (readOnlyHint/destructiveHint, источник mcp_annotation) — полезный сигнал, но они не вызывают доверия согласно спецификации MCP — продукт их подтверждает (corroborates) и никогда не доверяет им в одиночку.

Сторона permitted (источник policy) исходит из объявленных грантов; сторона observed исходит из сигналов выше.

Permitted против Observed (дрейф наименьших привилегий)

Заголовок раздела «Permitted против Observed (дрейф наименьших привилегий)»

Определяющее представление — это diff между тем, к чему инициатору разрешено обращаться, и тем, к чему он наблюдаемо обращается. Оно выявляет:

  • неожиданные доступы — инициатор использовал ресурс, который ему никогда не был предоставлен;
  • неиспользованные гранты — разрешение, которое ни один инициатор никогда не применял;
  • ожидающие сверки — доступ, который система пока не может твёрдо приписать.

Туториал «от нуля до графа» доходит до заполненного результата дрейфа на демонстрационном estate.

Чтение карты

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

Результаты карты доступа — включая дрейф Permitted-vs-Observed — обслуживаются маршрутами модуля, опубликованными в отдельном beta справочнике маршрутов модулей (а не в стабильном контракте ядра); их формы на уровне полей описаны в типизированных интерфейсах Go/TypeScript продукта, а веб-UI отрисовывает граф и наложение дрейфа поверх них. Чтение графа доступа — это привилегированное, ограниченное областью арендатора, полностью проходящее аудит действие (роль editor и выше, никогда не низший viewer) — см. модель безопасности и модель угроз.

Связанное

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