Produit · Carte des accès
Voyez ce que chaque agent peut atteindre — lecture face à écriture
Pour chaque agent, session et identité, la carte des accès montre les ressources touchées, sépare les lectures des écritures et signale l’instant où l’accès observé s’écarte de ce que vous avez autorisé. Découvert passivement à partir de signaux que vous possédez déjà — sans proxy dans le chemin des données.
Dans le produit
La carte, depuis la console réelle
Une véritable capture de la console Olivares, renseignée avec des données d’exemple. Les origines à gauche, les ressources qu’elles touchent à droite, colorées selon lecture, écriture/RW, inconnu et approximatif. Ouvrir la carte est une action privilégiée et auditée — elle montre des relations, jamais de SQL, de charges utiles ni de secrets.
Le modèle
Lecture, écriture, et l’inconnu honnête
Olivares classe chaque accès au niveau du connecteur, à partir de l’instruction ou du verbe lui-même — le type de SQL, la méthode HTTP, la sémantique de l’outil MCP, le mode d’ouverture du fichier. Il enregistre la relation, jamais l’instruction : aucun texte SQL, aucun paramètre, aucun payload, aucun secret.
Lecture
Un agent qui se contente de lire une ressource — un SELECT, un GET, un appel d’outil en lecture seule. Représenté avec sobriété, dans une teinte neutre.
Lecture / Écriture
Un agent qui peut modifier une ressource — un INSERT ou un UPDATE, un outil d’écriture, un appel mutant. Les arêtes qui déterminent votre rayon d’impact.
Inconnu / approximatif
Lorsqu’un stockage n’offre aucun audit par identité, ou que le signal est faible, Olivares le dit — une arête pointillée et atténuée — au lieu d’inventer une certitude.
Dérive du moindre privilège
Autorisé face à observé — la découverte qui compte
La dérive est l’écart entre l’accès que vous avez accordé et l’accès qui a réellement lieu. Olivares réconcilie une observation attribuée à un agent avec l’identité que cet agent utilise vraiment, et expose trois états honnêtes.
- Accès inattendu
Observé, mais jamais autorisé. La découverte la plus prioritaire — un accès qui a lieu sans aucune autorisation derrière.
- Réconciliation en attente
Observé sans autorisation correspondante, mais le lien agent-identité n’est pas encore résolu. Présenté comme en attente, et non comme une violation avérée — une incertitude honnête, pas une alarme fabriquée.
- Autorisations inutilisées
Autorisé, mais jamais observé. Un surprovisionnement à resserrer — le moindre privilège, dans l’autre sens.
Comment ça marche
Des autorisations et observations à un verdict unique
Olivares prend ce que vous avez autorisé et ce qu’il a observé, les réconcilie entre les origines et restitue le résultat : une concordance, une dérive, ou une relation qu’il peut seulement déclarer — jamais une qu’il prétendrait avoir vue.
Couverture énoncée honnêtement
Deux axes de fidélité — et nous n’en falsifions aucun
La qualité de l’audit possible d’une ressource et la fermeté du rattachement d’un accès à un agent précis sont deux choses distinctes. Olivares montre les deux, par nœud, et se dégrade avec élégance au lieu de deviner.
Couverture de la ressource
À quel point la ressource elle-même peut être auditée.
- Propre
- Audit natif — pgAudit de Postgres, AWS CloudTrail et similaires. Fidélité complète par accès.
- Avec pertes
- Magasins documentaires et vectoriels : signal partiel, montré comme partiel — sans arrondir à la hausse.
- Opaque
- Redis, SQLite, D1 et leurs semblables n’offrent aucun audit par identité. Marqué opaque, jamais rehaussé en silence.
Attribution de l’origine
À quel point un accès se rattache fermement à un agent précis.
- Ferme
- Une identité non humaine dédiée — un identifiant SPIFFE/WIF émis par agent. Dessiné plein.
- Approximatif
- Un compte partagé ou mutualisé : l’accès est réel, l’agent est ambigu. Dessiné en pointillé, étiqueté approximatif.
- Inconnu
- Aucun signal d’identité. Atténué — et jamais promu au rang d’agent nommé.
Les deux axes sont indépendants : un accès à un stockage opaque peut tout de même être attribué avec fermeté si un signal coopérant a nommé l’agent. Ce qu’Olivares ne fera pas, c’est présenter l’approximatif ou l’inconnu comme s’il était ferme.
Ce qui est réel
Construit et vérifié — et honnête sur ses limites
La carte des accès a franchi son jalon de preuve de concept technique et c’est elle qui écrit le graphe. Deux précisions honnêtes :
- Ouvrir la carte est une action privilégiée et auditée : chaque requête scelle une entrée dans le registre append-only. Elle sert à la revue défensive — des relations, non des contenus.
- La fidélité dépend de vos sources. Branchez l’audit natif (pgAudit, CloudTrail) et des identités par agent, et la carte atteint sa plus grande netteté ; sans eux, Olivares affiche le palier de moindre fidélité plutôt qu’une fiction présentée comme sûre.
Carte des accès — questions
A-t-elle besoin d’un proxy ou d’un agent en ligne ?
Non. Olivares découvre les accès passivement à partir de signaux que vous possédez déjà — audit natif de base de données, journaux d’audit du cloud, OpenTelemetry, eBPF et introspection MCP. Aucun proxy obligatoire dans le chemin des données, rien à surveiller en permanence.
La carte stocke-t-elle mon SQL, mes charges utiles ou mes secrets ?
Non. Chaque accès est classé à partir du verbe — le type de SQL, la méthode HTTP, la sémantique de l’outil — et enregistré comme une relation : origine, ressource, lecture ou écriture. Le texte de l’instruction, les paramètres, les charges utiles et les secrets ne sont jamais capturés.
Et les stockages sans audit par identité, comme Redis ?
Ils sont marqués comme couverture opaque. Olivares montre la relation à la fidélité qu’il peut réellement prouver et signale la limite, au lieu d’inventer une attribution par identité que le stockage ne peut pas soutenir.
Comment distingue-t-elle lecture et lecture/écriture ?
À partir de l’instruction ou du verbe lui-même, classé au niveau du connecteur — un SELECT face à un INSERT ou un UPDATE, un GET face à une méthode mutante, un appel d’outil en lecture seule face à un appel d’écriture. La couleur de l’arête suit : lecture, écriture/RW, ou inconnu quand le signal est faible.
Découvrez votre propre carte des accès
Déployez Olivares sur votre propre infrastructure, pointez-le vers vos sources d’audit et obtenez la carte lecture/écriture que vos équipes plateforme et sécurité réclament depuis longtemps.