Покриття та точність атрибуції

Інструмент безпеки, який перебільшує те, що він знає, гірший за відсутність інструменту: він дає вам хибне відчуття безпеки. Тому кожне ребро в карті доступу несе дві незалежні мітки точності, і продукт відображає їх чесно — він ніколи не прикрашає ледь відоме ребро під доведене.

Два виміри відповідають на два різних питання:

• Покриття — наскільки добре джерело може довести, чи був цей доступ читанням чи записом.
• Атрибуція — наскільки впевнено доступ прив’язується до одного агента, на відміну від спільної ідентичності.

Вони рухаються незалежно. Сховище даних із нативним аудитом дає чисте покриття; якщо кожен агент використовує один сервісний обліковий запис, атрибуція все одно лише приблизна. Жоден вимір не виводиться з іншого.

Покриття: читання проти запису

Покриття описує, що базове сховище може повідомити нам про характер доступу читання/запису. Це властивість джерела, а не агента.

• 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 — див. довідник модулів та сторінку чесність і обмеження для повної межі між доведеним та виведеним.

Пов’язане

• Карта доступу — що таке ребро та як воно будується.
• Дозволений проти фактичного — відхилення найменших привілеїв, які ці мітки кваліфікують.
• Чесність і обмеження — повний контракт щодо того, що працює, що на етапі проектування, і що продукт навмисно не робить.