Dozwolone vs obserwowane: dryf jako pierwszorzędne odkrycie

W powiązanym poście wprowadzono dryf najmniejszego przywileju jako gap między tym, co agent AI ma pozwolenie robić, a tym, co jest obserwowane, że robi. Ten post omawiał koncepcję: dlaczego gap powstaje, jak obserwacja „czytaj najpierw” produkuje różnicę między dozwolonym a obserwowanym, oraz jak polityka jako kod ją zamyka w momencie dostępu. Ten post idzie o jeden poziom głębiej – w to, jak dryf staje się ustrukturyzowanym, sklasyfikowanym i poddającym się triage odkryciem w module bezpieczeństwa oraz co się z nim dzieje, gdy już istnieje.

Krótko mówiąc: dryf nie jest żadnym wskaźnikiem na pulpicie ani wierszem logu. Jest przetrwałą jednostką z klasyfikacją, poziomem zagrożenia, poziomem pewności i cyklem życia triage. Zasila kolejkę anomalii, wzbogaca harmonogramy śledcze i jest szczery w kwestii tego, co może, a czego nie może udowodnić.

Trzy źródła sygnałów

Każda krawędź w mapie dostępu rejestruje relację dostępu pomiędzy źródłem (agentem, tożsamością, sesją) a zasobem. Każda krawędź niesie ze sobą dwa wskaźniki logiczne: Dozwolone i Zaobserwowane. Interesujące są krawędzie, w których te wskaźniki się nie zgadzają.

Ale wskaźniki nie pojawiają się znikąd. Pochodzą one z różnych źródeł sygnałów, z których każde ma inny profil zaufania:

Polityka (dozwolona). Krawędź z signal_source=policy lub signal_source=scoped_grant reprezentuje zadeklarowany przydział: coś, co poświadczenie, rola IAM lub własna platforma w zakresie źródeł mówi, że agent może to wykonać. Te krawędzie to permitted=true, observed=false, dopóki telemetria ich nie potwierdzi. Są to sufit. Łączniki tożsamości (WIF wystawcy, listy kluczy API, role w miejscu pracy) zasilają tę stronę. Konto usług federacyjnych, które zezwoliło na zakres OAuth swojej reguły w miejscu pracy, jest jedną z takich krawędzi.

Telemetria (obserwowana). Kooperacyjne sygnały z tras OpenTelemetry, logów pgAudit, zapisów CloudTrail, adnotacji MCP, obserwacji protokołu A2A oraz webhooków GitHub/GitLab. Te generują krawędzie tam, gdzie observed=true. Ich pewność zależy od źródła: klasyfikacja pgAudit READ jest attributed (baza danych wie, kto zapytał i czy była to operacja odczytu czy zapisu); MCP readOnlyHint jest approximate zgodnie ze specyfikacją — sama specyfikacja MCP mówi, że adnotacje narzędzi nie są zaufane.

Jądro (prawda podstawowa). Backstop eBPF (signal_source=ebpf) obserwuje na poziomie wywołań systemowych. Jest to sygnał, którego agent nie może obejść. Kiedy warstwa eBPF wykrywa connect() lub write(), którego telemetria współpracująca nie zgłosiła, nie jest to logujący gap — jest to sygnał przeciwko unikania wykrycia. Moduł bezpieczeństwa łączy obserwacje po stronie jądra i strony współpracującej w skorelowaną anomalię, więc agent, który wycisza własną telemetrię, staje się wykryciem, a nie martwym punktem.

Mapa dostępu jest zapytaniem nad tymi krawędziami, a nie osobnym schematem. Dryf najmniejszych uprawnień to podzbiór, w którym dwie flagi się nie zgadzają.

Jak dryf staje się wykryciem

Nieporozumienie między Permitted a Observed jest sygnałem surowym. Silnik klasyfikuje je jako jeden z dwóch rodzajów dryfu, zanim wejdzie do kolejki anomalii:

// DriftKind klasyfikuje dryf najmniejszych uprawnień między dozwolonym a zaobserwowanym.
type DriftKind string

const (
    // DriftUnusedGrant to dozwolony dostęp nigdy nie obserwowany (nadmiernie przyznany).
    DriftUnusedGrant DriftKind = "unused_grant"
    // DriftViolation to zaobserwowany dostęp, który nie jest dozwolony.
    DriftViolation DriftKind = "violation"
)

unused_grant oznacza, że polityka mówi, że agent może coś zrobić, czego nigdy nie widziano. To martwe uprawnienie — ryzyko ponoszone bez żadnej korzyści. Jest to sygnał do oczyszczenia podczas okresowych przeglądów dostępu: odebrać to, co nie jest używane.

violation oznacza, że agent został zaobserwowany wykonujący coś, co nie jest dozwolone przez żadną politykę ani uprawnienie. To jest aktywne stwierdzenie. To jest wiersz w tabeli różnic, który brzmi „nieprzejrzany zapis” — krawędź, która ma znaczenie, ta, którą priorytetowo traktuje kolejka anomalii.

Klasyfikacja nie jest binarna między „w porządku” a „problemem”. Struktura PrivilegeDrift łączy naruszającą krawędź z jej rodzajem:

// PrivilegeDrift to rozbieżność najmniejszych uprawnień: krawędź, której flagi Permitted
// i Observed są niezgodne.
type PrivilegeDrift struct {
    Edge AccessEdge
    Kind DriftKind
}

Sam brzeg niesie pełną proweniencję: pochodzenie (który agent), zasób, tryb dostępu /write, źródło sygnału, które go wygenerowało, pewność przypisania oraz okno obserwacji (FirstSeen, LastSeen, OccurrenceCount). Znalezienie dryfu nigdy nie oznacza „coś jest gdzieś nie tak.” Wskazuje na konkretnego agenta, konkretny zasób, konkretny tryb dostępu, obserwowany przez konkretnego kolektora, w określonym przedziale czasowym.

Kolejka anomaliów: nie tylko „inna”, ale sklasyfikowana

Kiedy moduł bezpieczeństwa buduje widok anomalii (punkt końcowy GET /v1/m/security/anomalies), pobiera dryf ze sklepu dostępu-brzegowego i klasyfikuje każdy violation do priorytetowej anomalie. Klasyfikacja dodaje kontekst, którego surowy brzeg nie niesie:

Dryf dostępu. Podstawa: zaobserwowany, ale nieautoryzowany dostęp. Anomalia nosi tytuł „Nieoczekiwany dostęp: zaobserwowany, ale nieautoryzowany”, ma średnią wagę i oznaczona jest jako confidence=approximate, ponieważ dryf na poziomie sklepu jest sygnałem surowym – jeszcze nie porównanym z pełnym grafem agent-to-identity. Widok po rekonsyliacji znajduje się we własnym punkcie końcowym mapy dostępu /drift; kolejka anomalii przetwarza surowy sygnał i oznacza go uczciwie.

Podejrzenie Egress/exfiltration. Gdy zasób na krawędzi driftu jest punktem końcowym sieci do zewnętrznego, nieprywatnego celu (łącznik eBPF generuje je jako URI tcp://host:port), anomalia jest przeklasyfikowywana na egress_exfil_suspected i podnoszona do wysokiego poziomu zagrożenia. Agent zapisujący do zewnętrznego punktu końcowego, do którego nigdy nie miał dostępu, stanowi inny rodzaj znaleziska niż agent odczytujący tabelę bazy danych, do której nie miał zakresu.

Escalacja wrażliwości. Gdy zasób posiada etykietę wrażliwości (high lub secret), poziom zagrożenia jest podnoszony niezależnie od tego, czy dostęp jest egress. violation w przypadku zasobu o wysokiej wrażliwości wymaga szybszej oceny, nawet jeśli cel jest wewnętrzny.

Każda anomalia zawiera mapę evidence z surowymi szczegółami:

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 jest celowe. Informuje konsumenta, że jest to surowy sygnał na poziomie sklepu, a nie zrekoncyliowany widok mapy dostępu, uwzględniający powiązanie agenta z tożsamością. Kolejka anomalii nie czeka na uzgodnienie, aby ujawnić violation — ale nie udaje, że przypisanie jest pewne, gdy takie nie jest.

Poziomy pewności: co da się udowodnić

Każda krawędź w mapie dostępu ma przypisany poziom pewności. Produkt używa dwóch:

• Przypisany (confidence=attributed): dostęp jest mocno powiązany z pochodzeniem na podstawie własnych dowodów zbieracza. Rekord pgAudit wskazujący rolę bazy danych agenta, zdarzenie CloudTrail powiązane z poświadczeniami IAM agenta, obserwacja eBPF powiązana z identyfikatorem procesu, który środowisko wykonawcze przypisało agentowi. Łańcuch przypisania jest kompleksowy.

• Przybliżone (confidence=approximate): przypisanie jest wnioskowane i może być utracone. Sygnał pochodził z konta usługi współdzielonej, gdzie wielu agentów używa tych samych poświadczeń, z utraconego magazynu (instancja Redis, która nie rejestruje tożsamości połączeń), lub z adnotacji MCP, która według specyfikacji jest niepewna. Krawędź nadal jest sygnałem — ale operator wie, że dowód jest słabszy.

Poziom pewności wpływa na wynik priorytetu anomalii. Funkcja priorytetu (priorityFor) ocenia każdą anomalię od 0 do 100, a przybliżony dryf pewności jest dyskontowany:

if confidence == string(sdkmodel.ConfidenceApproximate) {
    // dyskonto: nieuzgodniony dryf jest hałaśliwy
}

To zapobiega przepychaniu się hałaśliwego sygnału o wspólnej tożsamości na miejsce mocno ustalonego attributed violation. Oba pojawiają się w kolejce; approximate jest na niższym miejscu w rankingu. To ta sama zasada, którą stosuje wzbogacanie kryminalistyczne: gdy zostanie znaleziona wspólna tożsamość (SharedIdentity: true, AgentCount > 1), oś czasu notuje, że „przypisanie według agenta może być niejednoznaczne”, zamiast udawać, że przypisanie jest dokładne.

Produkt nigdy nie udaje pewności. Krawędź tylko z adnotacją MCP nie ma takiej samej wagi jak krawędź potwierdzona przez eBPF. Znalezienie odchylenia z konta wspólnego serwisu nie ma takiej samej wagi jak od agenta o indywidualnej tożsamości. Operator widzi różnicę i rozdziela priorytety odpowiednio.

Odchylenie w kryminalistycznej osi czasu

Znaleziska dryfu nie istnieją tylko w kolejce anomalii. Kiedy sprawa kryminalistyczna zostaje otwarta, a jej oś czasu jest rekonstruowana z audytowego rejestru powiązanego haszami, moduł bezpieczeństwa wzbogaca rekonstrukcję o dryf podmiotu:

out.Drift = subjectDrift(r.Context(), sc, c.SubjectRef)

Funkcja subjectDrift wysyła zapytanie do magazynu access-edge o dryf rodzaju naruszenia, w którym podmiot jest źródłem, i zwraca listę wpisów driftRefDTO — każdy zawierający źródło, zasób, tryb dostępu, źródło sygnału, liczbę wystąpień oraz znacznik czasu ostatniego wystąpienia. Dane te są odczytywane z własnych obliczeń dryfu magazynu, a nie recomputowane przez moduł bezpieczeństwa.

Oś czasu zawiera także przypisanie tożsamości podmiotu oraz pochodzenie danych, dzięki czemu śledczy przeglądający sprawę widzi pełny obraz: kim działa agent (i czy ta tożsamość jest współdzielona), do czego uzyskał dostęp, do czego nie powinien był mieć dostępu, oraz z jakich danych wyprowadził odpowiedzi. Każde z tych uzupełnień jest odporne na brakujące powiązania – jeśli moduł wiedzy nie jest zainstalowany, pochodzenie jest pomijane, a nie fałszowane; jeśli tożsamość nie ma przypisanego agenta, przypisanie mówi „jeszcze nie przypisano”, zamiast wymyślać jedno.

Cykl życia triage

Wynik pochodzący z dryfu trafia do systemu ze statusem open. Stamtąd podąża standardowym cyklem życia triage wyniku:

• otwarte: wynik istnieje, nikt jeszcze nie podjął w nim działań.
• triaged: operator potwierdził to, przypisał do przeglądu.
• resolved: pierwotna przyczyna została naprawiona (przyznanie zostało cofnięte, polityka zaostrzona, agent ponownie określony).
• dismissed: operator przejrzał to i stwierdził, że nie jest to realne ryzyko (znane zachowanie, fałszywy alarm z atrybucji approximate).

Każda zmiana stanu triage jest samodzielnie audytowana wobec prawdziwego podmiotu. Akt odrzucenia ustalenia jest sam w sobie rejestrowany w ledgerze odpornym na manipulacje, dzięki czemu audytor może zobaczyć nie tylko jakie odchylenia wystąpiły, ale kto je przeglądał i jakie podjął decyzje. Dowody dotyczące ustalenia (jego rodzaj, powaga i skrót szczegółów) są niezmienne po stworzeniu; zmiany triage dotyczą wyłącznie stanu przepływu pracy.

Co to oznacza w praktyce

Agent otrzymuje klucz API przypisany do przestrzeni roboczej Claude. Connector tożsamości odczytuje listę uczestników przestrzeni roboczej i generuje krawędź polityki: ten klucz ma pozwolenie na wywoływanie API w tej przestrzeni roboczej. Agent działa przez trzy tygodnie. Telemetria pokazuje, że wywołuje API w tej przestrzeni roboczej — brak odchyleń. Następnie zmiana wdrożenia daje agentowi dostęp do klucza drugiej przestrzeni roboczej. Telemetria obserwuje, że agent wywołuje API w obu przestrzeniach roboczych. Druga przestrzeń robocza nie ma krawędzi polityki. Tworzone jest znalezisko odchyleń violation: zaobserwowano, ale nie dozwolono. Wchodzi ono do kolejki anomalii jako access_drift, o średniej wadze, z pewnością approximate (krawędź nie została jeszcze uzgodniona z grafem tożsamości). Jeśli zasób w drugiej przestrzeni roboczej posiada etykietę wrażliwości high, waga wzrasta. Znalezisko pozostaje w kolejce operatora, dopóki ktoś go nie oceni.

To jest różnica między logowaniem a dryfem strukturalnym: to odkrycie jest sklasyfikowane, attributed (z uczciwą pewnością), priorytetyzowane i możliwe do selekcji. Utrzymuje się, dopóki ktoś go nie rozwiąże lub nie odrzuci. Pojawia się w chronologii kryminalistycznej, jeśli agent później staje się przedmiotem sprawy incydentu. I każda podjęta wobec niego akcja jest rejestrowana w łańcuchu, którego integralność produkt może udowodnić.

Dryf nie jest miarą do minimalizacji. Jest to odkrycie do selekcji. gap między tym, co agentowi wolno robić, a tym, co jest obserwowane, jest powierzchnią o najwyższym sygnale dla egzekwowania zasady najmniejszych uprawnień — ale tylko wtedy, gdy gap jest strukturalny, sklasyfikowany i uczciwy co do tego, co może udowodnić.

Aby zobaczyć mapę dostępu i powierzchnię dryfu na działce w użytkowaniu, odwiedź stronę produktu z mapą dostępu lub przegląd produktu.