Copertura e fedeltà dell'attribuzione

Uno strumento di sicurezza che esagera ciò che conosce è peggio di nessuno strumento: offre una falsa sensazione di sicurezza. Perciò ogni arco nella mappa degli accessi porta due etichette di fedeltà indipendenti, e il prodotto le presenta onestamente — non maschera mai un arco appena conosciuto come se fosse provato.

I due assi rispondono a due domande diverse:

• Copertura — quanto bene la sorgente può dimostrare se questo accesso è stato una lettura o una scrittura.
• Attribuzione — quanto fermamente l’accesso si lega a un singolo agente, rispetto a un’identità condivisa.

Si muovono in modo indipendente. Un data warehouse con audit nativo offre una copertura clean; se ogni agente condivide un unico account di servizio, l’attribuzione resta comunque solo approximate. Nessun asse viene dedotto dall’altro.

Copertura: lettura vs scrittura

La copertura descrive ciò che il datastore sottostante può dirci sulla natura lettura/scrittura di un accesso. È una proprietà della sorgente, non dell’agente.

• clean — il datastore emette audit nativo è autorevole, quindi lettura vs scrittura è classificata letteralmente. Questo vale per Postgres via pgAudit, object storage via CloudTrail (s3.readOnly), e i data warehouse e data lake (Snowflake, BigQuery, Redshift, Databricks, MSSQL, Oracle), oltre alla ground truth a livello kernel tramite eBPF.
• lossy — il datastore produce archi, ma approssimativi. I document store (ad esempio MongoDB) rientrano qui: un arco esiste, ma la distinzione lettura/scrittura è approssimativa.
• opaque — il datastore non fornisce alcun segnale passivo di lettura/scrittura. Redis, SQLite e D1 non possono essere ricostruiti osservandoli, quindi la mode dell’arco viene marcata unknown anziché indovinata.

Esiste anche un livello mixed per segnali cooperativi o a livello di tool — tool MCP, API HTTP, task degli agenti — che non sono legati a una singola classe di datastore.

La regola cardinale: dove un datastore è opaque, la classificazione lettura/scrittura è unknown, mai inventata. È un arco assente su una sorgente lossy o opaque non è prova che un accesso non sia avvenuto — solo che la sorgente non ha potuto dimostrare che sia avvenuto. Questa è la differenza tra permesso e osservato.

Attribuzione: quale agente

L’attribuzione descrive quanto fermamente un accesso osservato si riconduce a un singolo agente concreto. I log di audit attribuiscono l’attività a una credenziale o a un ruolo, non intrinsecamente a un agente — perciò questo asse è più rigoroso della mera fiducia nel segnale, ed è deny-closed: senza un segnale firm per agente, resta basso.

• firm — l’accesso si risolve inequivocabilmente a un agente. Questo richiede un vero segnale di identità per agente: un SVID SPIFFE per workload, un account di servizio federato con workload-identity, un’identità non umana dedicata emessa dalla governance, o una credenziale legata a esattamente un agente.
• approximate — un’identità è nota, ma non è possibile individuare un singolo agente. Un account di servizio condiviso o in pool dietro un connection pool, una credenziale ambigua, o un collegamento per agente ancora in attesa rientrano tutti qui.
• unknown — nessuna attribuzione per identità è possibile. Questo è il livello minimo per un datastore opaque visto da un backstop non cooperativo, o un accesso che non si lega a nessuna identità. Mai un agente fabbricato.

Poiché l’attribuzione è deny-closed, un segnale successivo più debole non può mai declassare un arco attribuito fermamente — ma un segnale forte può elevarne uno debole. I due assi interagiscono inoltre in esattamente una direzione: su un datastore opaque, qualsiasi attribuzione inferiore a firm viene portata al minimo di unknown, anziché essere spacciata come una stima da account condiviso mascherata da approximate.

L’identità per agente è quindi una dipendenza forte per la mappa ad alta fedeltà. Governare bene significa emettere un’identità per agente — vedi Identità e il modello di governance.

Perché è importante

Il senso dell’etichettatura di entrambi gli assi è la moderazione. Il prodotto non evidenzierà un arco lossy/approximate come una violazione allo stesso modo di un arco clean/firm, e mostra unknown e approximate apertamente anziché nasconderli. Una segnalazione di drift che il sistema non può ancora attribuire fermamente viene marcata come riconciliazione in attesa, non presentata come una violazione confermata.

Ecco perché la mappa degli accessi può essere considerata un’evidenza e non un’ipotesi: ogni arco dichiara, in due dimensioni, esattamente quanto sa. Dove sa poco, lo dice.

Dove compaiono queste etichette

Entrambe le etichette viaggiano su ogni arco nell’API del grafo e nella sovrapposizione UI, insieme alla sorgente del segnale che ha prodotto l’arco. Leggere il grafo degli accessi è un’azione privilegiata, circoscritta al tenant e completamente registrata nell’audit.

Le forme esatte a livello di campo per il grafo della mappa degli accessi e il drift si trovano nelle interfacce tipizzate del prodotto e non fanno intenzionalmente parte del contratto OpenAPI servito — vedi i moduli di riferimento e la pagina trasparenza e limiti per il confine completo tra ciò che è provato e ciò che è dedotto.

Correlati

• La mappa degli accessi — cos’è un arco e come viene costruito.
• Permesso vs osservato — il drift del privilegio minimo che queste etichette qualificano.
• Trasparenza e limiti — il contratto completo su ciò che funziona, ciò che è in fase di progettazione e ciò che il prodotto deliberatamente non fa.