Dekking & attributie-betrouwbaarheid

Een beveiligingstool dat overdrijft wat het weet is erger dan geen tool: het geeft je een vals gevoel van veiligheid. Daarom draagt elke verbinding in de toegangskaart twee onafhankelijke betrouwbaarheidslabels, en het product toont ze eerlijk — het kleedt een nauwelijks bekende verbinding nooit aan als een bewezen verbinding.

De twee assen beantwoorden twee verschillende vragen:

• Dekking — hoe goed de bron kan bewijzen of deze toegang een lezing of een schrijfactie was.
• Attributie — hoe stevig de toegang te koppelen is aan een enkele agent, versus een gedeelde identiteit.

Ze bewegen onafhankelijk. Een datawarehouse met native audit geeft schone dekking; als elke agent één serviceaccount deelt, is de attributie nog steeds slechts approximate. Geen van beide assen wordt afgeleid van de ander.

Dekking: lezen versus schrijven

Dekking beschrijft wat de onderliggende opslagplaats ons kan vertellen over het lees/schrijf-karakter van een toegang. Het is een eigenschap van de bron, niet van de agent.

• clean — de opslagplaats stuurt native, gezaghebbende audit uit, dus lezen versus schrijven wordt letterlijk geclassificeerd. Dit geldt voor Postgres via pgAudit, objectopslag via CloudTrail (s3.readOnly), en de datawarehouses en datalakes (Snowflake, BigQuery, Redshift, Databricks, MSSQL, Oracle), plus de kernel-level eBPF ground truth.
• lossy — de opslagplaats levert verbindingen op, maar grove. Documentopslagplaatsen (bijvoorbeeld MongoDB) vallen hier: een verbinding bestaat, maar de lees/schrijf-splitsing is benaderend.
• opaque — de opslagplaats geeft helemaal geen passief lees/schrijf-signaal. Redis, SQLite en D1 kunnen niet worden gereconstrueerd door ze te observeren, dus de mode van de verbinding wordt gemarkeerd als unknown in plaats van geraden.

Er is ook een mixed laag voor coöperatieve of toolniveau-signalen — MCP-tools, HTTP API’s, agenttaken — die niet aan één opslagklasse gebonden zijn.

De kardinale regel: waar een opslagplaats opaque is, is de lees/schrijf-classificatie unknown, nooit verzonnen. En een afwezige verbinding op een lossy of opaque bron is geen bewijs dat een toegang niet heeft plaatsgevonden — alleen dat de bron het niet kon bewijzen. Dat is het verschil tussen toegestaan en waargenomen.

Attributie: welke agent

Attributie beschrijft hoe stevig een waargenomen toegang terug te voeren is op één concrete agent. Auditlogs schrijven activiteit toe aan een credential of een rol, niet inherent aan een agent — dus deze as is strenger dan louter signaalvertrouwen, en is deny-closed: zonder een stevig per-agent-signaal blijft deze laag.

• firm — de toegang is ondubbelzinnig te herleiden tot één agent. Dit vereist een echt per-agent-identiteitssignaal: een SPIFFE-workload-SVID, een workload-identity-federated serviceaccount, een door governance uitgegeven dedicated non-human identity, of een credential gebonden aan precies één agent.
• approximate — een identiteit is bekend, maar een enkele agent kan niet worden aangewezen. Een gedeeld of gepoold serviceaccount achter een connection pool, een ambigue credential, of een per-agent-koppeling die nog in afwachting is, vallen hier.
• unknown — er is helemaal geen per-identiteit-attributie mogelijk. Dit is de ondergrens voor een opaque opslagplaats gezien door een niet-coöperatieve backstop, of een toegang die aan geen identiteit te koppelen is. Nooit een verzonnen agent.

Omdat attributie deny-closed is, kan een later, zwakker signaal een stevig geattribueerde verbinding nooit degraderen — maar een sterk signaal kan een zwak signaal verhogen. De twee assen interageren ook in precies één richting: op een opaque opslagplaats wordt elke attributie onder firm afgekapt naar unknown, in plaats van gepresenteerd als een gedeeld-account-schatting vermomd als approximate.

Per-agent-identiteit is daarom een harde afhankelijkheid voor de high-fidelity kaart. Goed besturen betekent identiteit per agent uitgeven — zie Identiteit en het bestuursmodel.

Waarom dit ertoe doet

Het doel van het labelen van beide assen is terughoudendheid. Het product zal een lossy/approximate verbinding niet als een overtreding koppen zoals het zou doen met een clean/firm verbinding, en het toont unknown en approximate openlijk in plaats van ze te verbergen. Een driftbevinding die het systeem nog niet stevig kan attribueren wordt gemarkeerd als reconciliation-pending, niet weergegeven als een bevestigde inbreuk.

Daarom kan de toegangskaart worden vertrouwd als bewijs in plaats van als een gok: elke verbinding zegt, in twee dimensies, precies hoeveel het weet. Waar het weinig weet, zegt het dat.

Waar deze labels verschijnen

Beide labels reizen mee op elke verbinding in de grafiek-API en de UI-overlay, samen met de signaalbron die de verbinding produceerde. Het lezen van de toegangsgrafiek is een geprivilegieerde, tenant-afgebakende, volledig geauditeerde actie.

De exacte veldniveau-structuren voor de toegangskaart-grafiek en drift staan in de getypeerde interfaces van het product en maken bewust geen deel uit van het geserveerde OpenAPI-contract — zie de referentiemodules en de pagina eerlijkheid en beperkingen voor de volledige grens van wat bewezen versus afgeleid is.

Gerelateerd

• De toegangskaart — wat een verbinding is en hoe deze wordt opgebouwd.
• Toegestaan versus waargenomen — de least-privilege-drift die deze labels kwalificeren.
• Eerlijkheid en beperkingen — het volledige contract over wat draait, wat design-fase is, en wat het product bewust niet doet.