Fidélité de couverture et d'attribution

Un outil de sécurité qui surestime ce qu’il sait est pire que pas d’outil du tout : il vous donne un faux sentiment de sécurité. C’est pourquoi chaque arête de la carte d’accès porte deux étiquettes de fidélité indépendantes, et le produit les affiche honnêtement — il ne déguise jamais une arête à peine connue en arête prouvée.

Les deux axes répondent à deux questions différentes :

• Couverture — dans quelle mesure la source peut prouver si cet accès était une lecture ou une écriture.
• Attribution — avec quelle certitude l’accès est lié à un agent unique, par opposition à une identité partagée.

Ils évoluent indépendamment. Un entrepôt de données avec audit natif donne une couverture clean ; si chaque agent partage un seul compte de service, l’attribution reste seulement approximate. Aucun axe n’est déduit de l’autre.

Couverture : lecture vs écriture

La couverture décrit ce que le store sous-jacent peut nous apprendre sur la nature lecture/écriture d’un accès. C’est une propriété de la source, pas de l’agent.

• clean — le store émet un audit natif faisant autorité, la classification lecture/écriture est donc littérale. C’est le cas de Postgres via pgAudit, de l’object storage via CloudTrail (s3.readOnly), des entrepôts de données et lacs de données (Snowflake, BigQuery, Redshift, Databricks, MSSQL, Oracle), ainsi que de la vérité terrain eBPF au niveau du noyau.
• lossy — le store produit des arêtes, mais grossières. Les document stores (par exemple MongoDB) entrent dans cette catégorie : une arête existe, mais la distinction lecture/écriture est approximative.
• opaque — le store ne donne aucun signal passif lecture/écriture. Redis, SQLite et D1 ne peuvent pas être reconstitués par simple observation, donc le mode de l’arête est marqué unknown plutôt que deviné.

Il existe aussi un niveau mixed pour les signaux coopératifs ou au niveau outil — outils MCP, API HTTP, tâches d’agents — qui ne sont pas liés à une classe de store unique.

La règle cardinale : là où un store est opaque, la classification lecture/écriture est unknown, jamais inventée. Et une arête absente sur une source lossy ou opaque n’est pas la preuve qu’un accès n’a pas eu lieu — seulement que la source n’a pas pu prouver qu’il a eu lieu. C’est la différence entre permis et observé.

Attribution : quel agent

L’attribution décrit avec quelle certitude un accès observé se rattache à un agent concret. Les journaux d’audit attribuent l’activité à un identifiant ou un rôle, pas intrinsèquement à un agent — cet axe est donc plus strict que la simple confiance dans le signal, et il est fermé par défaut : sans signal ferme par agent, il reste bas.

• firm — l’accès se résout sans ambiguïté à un seul agent. Cela nécessite un vrai signal d’identité par agent : un SVID SPIFFE de charge de travail, un compte de service fédéré par identité de charge de travail, une identité non-humaine dédiée émise par la gouvernance, ou un identifiant lié à exactement un agent.
• approximate — une identité est connue, mais un agent unique ne peut pas être identifié. Un compte de service partagé ou mutualisé derrière un pool de connexions, un identifiant ambigu, ou un lien par agent encore en attente atterrissent ici.
• unknown — aucune attribution par identité n’est possible. C’est le plancher pour un store opaque vu par un backstop non coopératif, ou un accès qui ne se rattache à aucune identité. Jamais un agent fabriqué.

Parce que l’attribution est fermée par défaut, un signal ultérieur plus faible ne peut jamais dégrader une arête fermement attribuée — mais un signal fort peut élever une arête faible. Les deux axes interagissent aussi dans exactement une direction : sur un store opaque, toute attribution en dessous de firm est ramenée à unknown, plutôt que d’être présentée comme une supposition de compte partagé déguisée en approximate.

L’identité par agent est donc une dépendance dure pour la carte haute fidélité. Bien gouverner signifie émettre une identité par agent — voir Identité et le modèle de gouvernance.

Pourquoi c’est important

L’intérêt d’étiqueter les deux axes est la retenue. Le produit ne mettra pas en avant une arête lossy/approximate comme une violation de la même manière qu’une arête clean/firm, et il affiche unknown et approximate ouvertement au lieu de les masquer. Une découverte de dérive que le système ne peut pas encore fermement attribuer est marquée en attente de réconciliation, pas rendue comme une brèche confirmée.

C’est pourquoi la carte d’accès peut être utilisée comme preuve plutôt que comme supposition : chaque arête dit, en deux dimensions, exactement combien elle sait. Là où elle sait peu, elle le dit.

Où ces étiquettes apparaissent

Les deux étiquettes accompagnent chaque arête dans l’API du graphe et l’overlay de l’interface, aux côtés de la source de signal qui a produit l’arête. La lecture du graphe d’accès est une action privilégiée, scopée au tenant et entièrement auditée.

Les formes exactes au niveau des champs pour le graphe de la carte d’accès et la dérive se trouvent dans les interfaces typées du produit et ne font délibérément pas partie du contrat OpenAPI servi — voir les modules de référence et la page transparence et limites pour la frontière complète entre ce qui est prouvé et ce qui est déduit.

Voir aussi

• La carte d’accès — ce qu’est une arête et comment elle est construite.
• Permis vs observé — la dérive de moindre privilège que ces étiquettes qualifient.
• Transparence et limites — le contrat complet sur ce qui fonctionne, ce qui est en conception, et ce que le produit ne fait délibérément pas.