Инструмент безопасности, который преувеличивает свои знания, хуже, чем отсутствие инструмента: он даёт ложное чувство защищённости. Поэтому каждое ребро в карте доступа несёт две независимые метки точности, и продукт отображает их честно — он никогда не маскирует едва известное ребро под доказанное.
Две оси отвечают на два разных вопроса:
- Покрытие — насколько хорошо источник может доказать, был ли этот доступ чтением или записью.
- Атрибуция — насколько надёжно доступ привязан к одному агенту, а не к общей идентичности.
Они движутся независимо. Хранилище с нативным аудитом даёт чистое покрытие; если каждый агент использует один сервисный аккаунт для работы с ним, атрибуция всё равно только приблизительная. Ни одна ось не выводится из другой.
Покрытие: чтение vs запись
Покрытие описывает, что базовое хранилище может рассказать нам о характере доступа — чтение или запись. Это свойство источника, а не агента.
clean— хранилище генерирует нативный, авторитетный аудит, поэтому чтение и запись классифицируются дословно. Это Postgres через pgAudit, объектное хранилище через CloudTrail (s3.readOnly), а также хранилища данных и озёра (Snowflake, BigQuery, Redshift, Databricks, MSSQL, Oracle), плюс наземная истина на уровне ядра через eBPF.lossy— хранилище даёт рёбра, но грубые. Документные хранилища (например MongoDB) попадают сюда: ребро существует, но разделение чтения/записи приблизительное.opaque— хранилище вообще не даёт пассивного сигнала чтения/записи. Redis, SQLite и D1 невозможно восстановить путём наблюдения, поэтомуmodeребра помечается какunknown, а не угадывается.
Существует также уровень mixed для кооперативных или инструментальных сигналов — MCP-инструменты, HTTP API, задачи агентов — которые не привязаны к одному классу хранилища.
Основное правило: где хранилище opaque, классификация чтения/записи — unknown, никогда не выдуманная. А отсутствующее ребро на lossy или opaque источнике — не доказательство того, что доступа не было, а лишь то, что источник не смог доказать, что он был. В этом разница между разрешённым и наблюдаемым.
Атрибуция: какой агент
Атрибуция описывает, насколько надёжно наблюдаемый доступ привязан к одному конкретному агенту. Журналы аудита привязывают активность к учётным данным или роли, а не к агенту как таковому — поэтому эта ось строже, чем простое доверие к сигналу, и она работает по принципу запрета по умолчанию: без надёжного сигнала по каждому агенту она остаётся низкой.
firm— доступ однозначно привязан к одному агенту. Для этого требуется реальный сигнал идентификации по агенту: SPIFFE workload SVID, федеративный сервисный аккаунт рабочей нагрузки, выделенная нечеловеческая идентичность, выданная системой управления, или учётные данные, привязанные ровно к одному агенту.approximate— идентичность известна, но конкретного агента определить нельзя. Общий или пулированный сервисный аккаунт за пулом соединений, неоднозначные учётные данные или ожидающая привязка по агенту попадают сюда.unknown— атрибуция по идентичности вообще невозможна. Это нижний уровень дляopaqueхранилища, наблюдаемого некооперативным бэкстопом, или доступа, не привязанного ни к какой идентичности. Никогда — выдуманный агент.
Поскольку атрибуция работает по принципу запрета по умолчанию, более поздний и слабый сигнал никогда не может понизить надёжно атрибутированное ребро — но сильный сигнал может повысить слабое. Две оси также взаимодействуют ровно в одном направлении: на opaque хранилище любая атрибуция ниже firm опускается до unknown, а не выдаётся за предположение об общем аккаунте, замаскированное под approximate.
Идентификация по агенту является, таким образом, жёстким требованием для карты высокой точности. Эффективное управление означает выдачу идентичности каждому агенту — см. Идентичность и модель управления.
Почему это важно
Смысл маркировки обеих осей — в сдержанности. Продукт не будет выносить ребро lossy/approximate в заголовок как нарушение так, как он бы поступил с clean/firm, и он отображает unknown и approximate открыто, а не скрывая их. Находка дрейфа, которую система ещё не может надёжно атрибутировать, помечается как ожидающая сверки, а не отображается как подтверждённая утечка.
Вот почему карте доступа можно доверять как доказательству, а не как догадке: каждое ребро говорит в двух измерениях, ровно сколько оно знает. Там, где оно знает мало, оно об этом сообщает.
Где отображаются эти метки
Обе метки присутствуют на каждом ребре в API графа и наложении UI, вместе с источником сигнала, который создал ребро. Чтение графа доступа — это привилегированное, ограниченное по тенанту и полностью аудируемое действие.
Точные полевые структуры для графа карты доступа и дрейфа находятся в типизированных интерфейсах продукта и намеренно не являются частью публикуемого контракта OpenAPI — см. справочник модулей и страницу честность и ограничения для полного описания того, что доказано, а что выведено.
Связанные материалы
- Карта доступа — что такое ребро и как оно строится.
- Разрешённый и наблюдаемый — дрейф наименьших привилегий, который эти метки квалифицируют.
- Честность и ограничения — полный контракт о том, что работает, что на стадии проектирования и что продукт намеренно не делает.