У супровідній публікації було введено поняття дрейфу найменших привілеїв як gap між тим, що агент ШІ може робити, і тим, що він спостерігається робити. У тій публікації розглядалася концепція: чому з’являється gap, як спостереження «спочатку прочитати» створює різницю між дозволеним і фактично спостереженим, і як політика як код усуває її в момент доступу. У цій публікації йдеться глибше — про те, як дрейф стає структурованим, класифікованим, можливим для сортування знайденим елементом у безпековому модулі, і що з ним відбувається після його виникнення.
Коротка версія: дрейф — це не метрика панелі керування і не рядок журналу. Це збережена сутність із класифікацією, рівнем серйозності, рівнем довіри та життєвим циклом сортування. Він наповнює чергу аномалій, збагачує часові лінії судової експертизи та чесно показує, що можна, а що не можна довести.
Три джерела сигналу
Кожна грань у карті доступу фіксує відносини доступу між джерелом (агентом, ідентичністю, сеансом) та ресурсом. Кожна грань має два булеві прапорці: Дозволено та Спостережено. Цікаві грані — це ті, де ці прапорці не співпадають.
Але прапорці не з’являються нізвідки. Вони походять із різних джерел сигналів, кожне з яких має інший профіль довіри:
Політика (дозволено). Ребро з signal_source=policy або signal_source=scoped_grant представляє заявлений грант: щось, що обліковий запис, роль IAM або власна система визначення джерел платформи говорить, що цей агент може робити. Ці ребра є permitted=true, observed=false, доки телеметрія їх не підтвердить. Вони є максимумом. З’єднувачі ідентичності (WIF видавці, списки ключів API, ролі робочого простору) живлять цю сторону. Обліковий запис федеративної служби, якому дозволено область OAuth його правила у робочому просторі, є таким ребром.
Телеметрія (спостережувана). Кооперативні сигнали від OpenTelemetry трас, журналів pgAudit, записів CloudTrail, анотацій MCP, спостережень протоколу A2A та вебхуків GitHub/GitLab. Вони створюють зв’язки там, де observed=true. Їхня надійність залежить від джерела: класифікація pgAudit READ є attributed (база даних знає, хто робив запит і чи це було читання, чи запис); MCP readOnlyHint є approximate за специфікацією — сама специфікація MCP зазначає, що анотації інструментів недостовірні.
Ядро (істинні дані). Резервний механізм eBPF (signal_source=ebpf) спостерігає на рівні системних викликів (syscall). Це сигнал, навколо якого агент не може обійтися. Коли шар eBPF бачить connect() або write(), які спільна телеметрія не зафіксувала, це не журналювальний gap — це сигнал проти ухилень. Модуль безпеки об’єднує спостереження на стороні ядра та спільної сторони в скорельовану аномалію, тому агент, який вимикає власну телеметрію, перетворюється на знахідку, а не на сліпу зону.
Карта доступу є запитом по цих зв’язках, а не окремою схемою. Відхилення принципу найменших привілеїв — це підмножина, де два прапори не збігаються.
Як відхилення перетворюється на знахідку
Суперечка між Permitted і Observed є сирим сигналом. Двигун класифікує його як один із двох видів дрейфу перед тим, як він потрапить у чергу аномалій:
// DriftKind класифікує дрейф на основі мінімальних привілеїв між дозволеним і спостережуваним.
type DriftKind string
const (
// DriftUnusedGrant — це дозволений доступ, який ніколи не спостерігався (надмірно наданий).
DriftUnusedGrant DriftKind = "unused_grant"
// DriftViolation — це спостережуваний доступ, який не дозволений.
DriftViolation DriftKind = "violation"
)
unused_grant означає, що політика дозволяє агенту робити щось, що він ніколи не робив. Це мертвий привілей — ризик без користі. Це сигнал для очищення під час періодичних оглядів доступу: відкликати те, що не використовується.
violation означає, що за агентом спостерігали під час виконання дії, яку не дозволяє жодна політика або грант. Це активне виявлення. Це рядок у таблиці diff, який читається як “unreviewed write” — ключове ребро, яке має значення, те, що черга аномалій пріоритезує.
Класифікація не є бінарною між “добре” та “проблема”. Структура PrivilegeDrift поєднує порушуюче ребро з його типом:
// PrivilegeDrift — це невідповідність принципу найменших привілеїв: ребро, у якого прапори Permitted
// та Observed не збігаються.
type PrivilegeDrift struct {
Edge AccessEdge
Kind DriftKind
}
Самий край містить повну інформацію про походження: джерело (який агент), ресурс, режим read/write, джерело сигналу, яке його створило, ступінь впевненості в атрибуції та спостережуване вікно (FirstSeen, LastSeen, OccurrenceCount). Знахідка дрейфу ніколи не означає «щось не так десь». Вона вказує на конкретного агента, конкретний ресурс, конкретний режим доступу, зафіксовані конкретним колектором, з певним часовим діапазоном.
Черга аномалій: не просто «інше», але класифіковане
Коли модуль безпеки будує уявлення про аномалії (кінцева точка GET /v1/m/security/anomalies), він витягує дрейф із сховища доступу-краю та класифікує кожен violation як пріоритетну аномалію. Класифікація додає контекст, якого сирий край не несе:
Дрейф доступу. Базова лінія: доступ, який було зафіксовано, але не дозволено. Аномалія отримала назву «Несподіваний доступ: зафіксовано, але не дозволено», середню важливість і позначена confidence=approximate, оскільки дрейф на рівні магазину є необробленим сигналом — ще не погодженим з повною картою агент–ідентичність. Узгоджений вигляд знаходиться на власному кінцевому пункті /drift карти доступу; черга аномалій використовує необроблений сигнал і позначає його чесно.
Підозра на Egress/exfiltration. Коли ресурс на краю дрейфу є мережею кінцевої точки до зовнішнього, непривабливого призначення (конектор eBPF видає їх як URI tcp://host:port), аномалія перекваліфікується на egress_exfil_suspected і підвищується до високої серйозності. Аґент, який пише до зовнішньої кінцевої точки, до якої йому ніколи не надавалась доступу, є іншою формою знаходження, ніж аґент, який читає таблицю бази даних, на яку йому не було надано доступ.
Ескалація чутливості. Коли ресурс має мітку чутливості (high або secret), серйозність підвищується незалежно від того, чи доступ є вихідним. violation відносно ресурсу з високою чутливістю потребує швидшої тріажі, навіть якщо призначення внутрішнє.
Кожна аномалія включає evidence карту з сирими деталями:
ev := map[string]any{
"origin_kind": edge.OriginKind,
"origin_id": edge.OriginID.String(),
"resource_id": edge.ResourceID.String(),
"mode": string(edge.Mode),
"signal_source": string(edge.SignalSource),
"occurrence_count": edge.OccurrenceCount,
"reconciled": false,
}
reconciled: false є навмисним. Він повідомляє споживачу, що це сигнал на рівні магазину у сирому вигляді, а не узгоджене подання карти доступу з точки зору агента та ідентичності. Черга аномалій не чекає на узгодження, щоб виявити violation — але вона не вдає, що атрибуція є точною, коли це не так.
Рівні впевненості: що можна довести
Кожне ребро в карті доступу має рівень впевненості. Продукт використовує два:
-
Призначено (
confidence=attributed): доступ міцно пов’язаний з джерелом за власними доказами збирача. Запис pgAudit із зазначенням ролі агента в базі даних, подія CloudTrail, пов’язана з обліковими даними IAM агента, спостереження eBPF, пов’язане з ідентифікатором процесу, який середовище виконання зіставило з агентом. Ланцюг атрибуції є наскрізним. -
Наближенe (
confidence=approximate): атрибуція виведена й може бути неповною. Сигнал надійшов з облікового запису спільного сервісу, де кілька агентів використовують один і той же обліковий запис, з неповного сховища (інстанції Redis, яка не веде журнал для кожного підключення), або від анотації MCP, яку специфікація вважає ненадійною. Край усе одно є сигналом — але оператор знає, що доказ слабший.
Рівень впевненості впливає на пріоритетну оцінку аномалії. Функція пріоритету (priorityFor) оцінює кожну аномалію від 0 до 100, і наближений дрейф впевненості дисконтований:
if confidence == string(sdkmodel.ConfidenceApproximate) {
// дисконт: невирівняний дрейф є шумним
}
Це запобігає тому, щоб гучний сигнал із спільною ідентичністю витісняв стійкий attributed violation. Обидва з’являються в черзі; approximate ранжуються нижче. Це той самий принцип, який застосовується для криміналістичного збагачення: коли виявляється спільна ідентичність (SharedIdentity: true, AgentCount > 1), у хронології зазначається, що «атрибуція за агентом може бути неоднозначною», замість того щоб робити вигляд, що атрибуція точна.
Продукт ніколи не вдає впевненість. Анотаційний MCP край не має такої ж ваги, як підкріплений eBPF. Виявлення зсуву від спільного облікового запису служби не має тієї ж ваги, що й від індивідуальної ідентичності агента. Оператор бачить різницю і відповідно здійснює пріоритезацію.
Зсув у криміналістичній хронології
Висновки дрейфу існують не тільки в черзі аномалій. Коли відкривається криміналістична справа та її хронологія відтворюється з хеш-ланцюгового аудиторського реєстру, модуль безпеки збагачує відтворення дрейфом суб’єкта:
out.Drift = subjectDrift(r.Context(), sc, c.SubjectRef)
. Функція subjectDrift запитує сховище граничного доступу щодо дрейфу типу порушення, де суб’єкт є джерелом, і повертає список записів driftRefDTO — кожен із яких містить джерело, ресурс, режим доступу, джерело сигналу, кількість випадків і мітку часу останнього перегляду. Вони зчитуються з власного обчислення дрейфу сховища, а не переобчислюються модулем безпеки.
Таймлайн також містить атрибуцію особистості суб’єкта та походження даних, тому слідчий, що розглядає справу, бачить повну картину: ким діє агент (і чи ця особистість спільна), до чого він отримав доступ, чого не повинен був, та на основі яких даних він отримав відповіді. Кожне з цих збагачень толерантне до відсутніх сусідів — якщо модуль знань не встановлений, походження опускається, а не вигадується; якщо особистість не має вирішеної прив’язки агента, атрибуція каже “ще не прив’язано”, замість того щоб вигадувати її.
Цикл життя сортування
Знахідка, що виникла через дрейф, потрапляє в систему зі статусом open. Звідти вона слідує стандартному циклу життя сортування знахідок:
- відкрита: знахідка існує, ніхто ще не діяв щодо неї.
- triaged: оператор визнав це, призначив для перегляду.
- resolved: основну причину усунули (грант був відкликаний, політика посилена, агент перебазовано).
- dismissed: оператор переглянув це і вирішив, що це не реальний ризик (відоме поводження, хибнопозитивний результат від approximate).
Кожна зміна стану тріажу самостійно перевіряється щодо реального власника. Дія з відхилення висновку сама записується у журнал з доказами захисту від злому, тож аудитор може бачити не лише те, яка відхилення сталася, але й хто її переглянув і яке ухвалив рішення. Докази висновку (його вид, серйозність та хеш деталей) незмінні після створення; зміни тріажу стосуються лише стану робочого процесу.
Що це означає на практиці
Агенту надається ключ API, обмежений до робочого простору Claude. Конектор ідентичності читає реєстр робочого простору та випускає політичне ребро: цей ключ дозволено використовувати для виклику API в цьому робочому просторі. Агент працює протягом трьох тижнів. Телеметрія показує, що він викликає API в цьому робочому просторі — без відхилень. Потім зміна розгортання надає агенту доступ до ключа другого робочого простору. Телеметрія фіксує, що агент викликає API в обох робочих просторах. Другий робочий простір не має політичного ребра. Створюється виявлення відхилення типу violation: спостережено, але не дозволено. Воно потрапляє в чергу аномалій як access_drift, серйозність середня, впевненість approximate (ребро ще не було звірено з графом ідентичностей). Якщо ресурс у другому робочому просторі має мітку чутливості high, серйозність підвищується. Виявлення перебуває у черзі оператора, доки хтось його не проріже.
Ось різниця між логуванням і структурованим відхиленням: знахідка класифікується, attributed (з чесною впевненістю), пріоритизується та підлягає тріажу. Вона зберігається, доки хтось її не вирішить або не відхилить. Вона з’являється у криміналістичній хронології, якщо агент пізніше стає об’єктом інцидентної справи. І кожна дія щодо неї записується в ланцюжок, цілісність якого продукт може підтвердити.
Відхилення не є метрикою, яку потрібно мінімізувати. Це знахідка для тріажу. gap між тим, що агенту дозволено робити, і тим, що його спостерігають за виконанням, є поверхнею з найвищим сигналом для забезпечення мінімальних привілеїв — але лише тоді, коли gap структурований, класифікований та чесний щодо того, що він може підтвердити.
Щоб переглянути карту доступу та поверхню схилу на працюючому помісті, відвідайте сторінку продукту карти доступу або огляд продукту.