Pokrycie i wierność atrybucji

Narzędzie bezpieczeństwa, które wyolbrzymia to, co wie, jest gorsze niż brak narzędzia: daje fałszywe poczucie bezpieczeństwa. Dlatego każda krawędź w mapie dostępu niesie dwie niezależne etykiety wierności, a produkt renderuje je uczciwie — nigdy nie ubiera ledwo znanej krawędzi w udowodnioną.

Dwie osie odpowiadają na dwa różne pytania:

• Pokrycie — jak dobrze źródło może udowodnić, czy dany dostęp był odczytem czy zapisem.
• Atrybucja — jak pewnie dostęp wiąże się z pojedynczym agentem, a nie współdzieloną tożsamością.

Poruszają się niezależnie. Hurtownia z natywnym audytem daje czyste pokrycie; jeśli każdy agent używa jednego konta serwisowego, atrybucja nadal jest tylko przybliżna. Żadna oś nie jest wnioskowana z drugiej.

Pokrycie: odczyt vs zapis

Pokrycie opisuje, co bazowy magazyn może nam powiedzieć o charakterze odczyt/zapis dostępu. To właściwość źródła, nie agenta.

• clean — magazyn emituje natywny, autorytatywny audyt, więc odczyt vs zapis jest klasyfikowany dosłownie. To Postgres przez pgAudit, magazyny obiektów przez CloudTrail (s3.readOnly), hurtownie i jeziora danych (Snowflake, BigQuery, Redshift, Databricks, MSSQL, Oracle), plus prawda bazowa z poziomu jądra eBPF.
• lossy — magazyn daje krawędzie, ale zgrubne. Magazyny dokumentów (na przykład MongoDB) należą do tej kategorii: krawędź istnieje, ale podział odczyt/zapis jest przybliżony.
• opaque — magazyn nie daje żadnego pasywnego sygnału odczyt/zapis. Redis, SQLite i D1 nie mogą być zrekonstruowane przez obserwację, więc mode krawędzi jest oznaczany jako unknown zamiast być zgadywany.

Istnieje także warstwa mixed dla sygnałów kooperacyjnych lub na poziomie narzędzi — narzędzia MCP, API HTTP, zadania agentów — które nie są związane z jedną klasą magazynów.

Zasada kardynalna: tam, gdzie magazyn jest opaque, klasyfikacja odczyt/zapis to unknown, nigdy wymyślona. A brak krawędzi na źródle lossy lub opaque nie jest dowodem, że dostęp nie nastąpił — jedynie że źródło nie mogło udowodnić, że nastąpił. To różnica między dozwolonymi a obserwowanymi.

Atrybucja: który agent

Atrybucja opisuje, jak pewnie obserwowany dostęp wiąże się z jednym konkretnym agentem. Logi audytu przypisują aktywność do poświadczenia lub roli, nie z natury do agenta — więc ta oś jest bardziej rygorystyczna niż samo zaufanie do sygnału i jest domyślnie odrzucająca: bez pewnego sygnału per-agent pozostaje niska.

• firm — dostęp jednoznacznie rozwiązuje się do jednego agenta. Wymaga to prawdziwego sygnału tożsamości per-agent: SPIFFE workload SVID, sfederowanego konta serwisowego workload-identity, dedykowanej tożsamości nie-ludzkiej wystawionej przez zarządzanie, lub poświadczenia związanego z dokładnie jednym agentem.
• approximate — tożsamość jest znana, ale pojedynczy agent nie może być wskazany. Współdzielone lub pułowane konto serwisowe za pulą połączeń, niejednoznaczne poświadczenie lub oczekujące powiązanie per-agent lądują tutaj.
• unknown — żadna atrybucja per-tożsamość nie jest możliwa. To poziom bazowy dla magazynu opaque widzianego przez niekooperacyjny backstop, lub dostępu bez powiązanej tożsamości. Nigdy sfabrykowany agent.

Ponieważ atrybucja jest domyślnie odrzucająca, późniejszy, słabszy sygnał nigdy nie może obniżać pewnie przypisanej krawędzi — ale silny sygnał może podnieść słabą. Dwie osie również oddziałują w dokładnie jednym kierunku: na magazynie opaque każda atrybucja poniżej firm jest sprowadzana do unknown, zamiast być przedstawiana jako przybliżony domysł udający approximate.

Tożsamość per-agent jest zatem twardym wymogiem dla mapy o wysokiej wierności. Dobre zarządzanie oznacza wydawanie tożsamości per agent — zobacz Tożsamość i model zarządzania.

Dlaczego to ma znaczenie

Sens etykietowania obu osi to powściągliwość. Produkt nie będzie nagłówkował krawędzi lossy/approximate jako naruszenia w sposób, w jaki zrobiłby to z clean/firm, i ujawnia unknown i approximate otwarcie, zamiast je ukrywać. Odkrycie dryfu, którego system nie może jeszcze pewnie przypisać, jest oznaczone jako oczekujące na uzgodnienie, a nie renderowane jako potwierdzony incydent.

Dlatego mapa dostępu może być traktowana jako dowód, a nie domysł: każda krawędź mówi, w dwóch wymiarach, dokładnie ile wie. Tam, gdzie wie mało, mówi o tym.

Gdzie te etykiety się pojawiają

Obie etykiety podróżują na każdej krawędzi w API grafu i nakładce UI, obok źródła sygnału, które wygenerowało krawędź. Odczytywanie grafu dostępu jest uprzywilejowaną, ograniczoną do dzierżawcy, w pełni audytowaną akcją.

Dokładne kształty na poziomie pól dla grafu mapy dostępu i dryfu znajdują się w typowanych interfejsach produktu i celowo nie są częścią serwowanego kontraktu OpenAPI — zobacz moduły referencyjne i stronę uczciwości i ograniczeń dla pełnej granicy między tym, co jest udowodnione, a tym, co jest wnioskowane.

Powiązane

• Mapa dostępu — czym jest krawędź i jak jest budowana.
• Dozwolone vs obserwowane — dryf najniższych uprawnień, który te etykiety kwalifikują.
• Uczciwości i ograniczenia — pełny kontrakt dotyczący tego, co działa, co jest na etapie projektowania i czego produkt celowo nie robi.