Politiques hétérogènes
Rego, YAML, IAM, Casbin et SQL décrivent chacun une partie de la même intention. Sans modèle commun, personne ne voit l’autorisation réelle.
PolicyGuardian · policy-as-code
Vérifiez formellement vos politiques de données avant qu’elles ne cassent la prod.
PolicyGuardian traduit vos politiques hétérogènes — Rego, YAML, IAM cloud, Casbin, SQL — vers un modèle logique unifié, l’UPM, puis interroge le solveur SMT Z3 sur leur cohérence, leur complétude et leur conformité.
Pré-industrialisation · validé en environnement représentatif · pas de libre-service
- Rego / OPA
- YAML
- IAM cloud
- Casbin
- SQL
Mesures expérimentales
- Correspondance
- 95,6 %
- Syntaxe et sens, cinq langages testés.
- Contradictions
- 87,2 %
- Détectées sur jeux labellisés.
- Lot d’essai
- 36,8 s
- Pour 10 000 politiques, cluster d’essai.
- RGPD
- 7
- Invariants traduits et vérifiés.
01 — Problème
Les politiques divergent. L’audit arrive trop tard.
Les règles qui protègent les données ne tiennent pas dans un seul fichier. Elles s’accumulent dans des dépôts OPA, des rôles IAM, des vues SQL et des YAML d’équipe. L’écart entre ces textes échappe à une revue manuelle. Il apparaît en production, ou le jour de l’audit.
Conflits invisibles
Deux politiques peuvent se contredire sans qu’un contrôle de syntaxe ne le signale. La contradiction ne se montre qu’à l’exécution.
Audits manuels
Une relecture humaine ne passe pas à l’échelle de plusieurs milliers de règles, et elle ne produit pas de contre-exemple.
Risque RGPD et sécurité
Un principe de minimisation ou d’accès qui reste un paragraphe de politique interne n’est pas encore un contrôle. Il faut un invariant vérifiable.
02 — Solution
Unifier, puis interroger un solveur.
PolicyGuardian ne remplace pas les langages de policy. Il les rassemble dans un modèle sur lequel un solveur peut raisonner, et il renvoie le diagnostic là où les politiques changent : la chaîne DevSecOps.
Modèle logique pivot
Le Unified Policy Model représente des politiques issues de Rego, Casbin, IAM cloud et SQL. La spécification est un schéma JSON, avec un traducteur. L’outillage source reste en place.
Vérification SMT
Le solveur cherche contradictions, trous de couverture et violations d’invariants. Une contradiction vient avec un témoin. Un cas non tranché est signalé, pas converti en succès.
Dans la chaîne
Un plugin GitHub Actions et Jenkins relance la vérification à chaque changement de politique. Les constats sortent au format SARIF. Une API expose vérification, extraction et diagnostic.
03 — Méthode
Quatre temps, du fichier au rapport.
Lire les sources
Collecte des politiques OPA / Rego, YAML, IAM cloud, Casbin et SQL, sans exiger un langage unique en amont.
Traduire vers l’UPM
Chaque source est projetée dans le modèle pivot. La correspondance mesurée sur les langages testés est de 95,6 %, pas une traduction sans reste.
Poser la question à Z3
Cohérence, couverture, invariants de sécurité et de conformité — dont sept invariants RGPD déjà traduits et vérifiés sur un corpus réel.
Rendre le diagnostic exploitable
Rapport, graphe de dépendances, heatmap de conflits, indicateurs de couverture. La CI échoue quand les invariants échouent.
04 — Différence
Au-delà du lint et de la décision.
Un linter vérifie la forme. Un moteur comme OPA évalue une requête et reste le bon outil pour appliquer une décision. PolicyGuardian pose une autre question : l’ensemble des politiques est-il cohérent, couvrant, et compatible avec les invariants écrits ?
Contrôle habituel
- Syntaxe, style, ou décision sur une requête donnée.
- Chaque langage est revu dans son propre dépôt.
- La contradiction entre un rôle IAM et une vue SQL n’a pas de lieu où apparaître.
PolicyGuardian
- Un modèle logique commun, puis une recherche de preuve ou de contre-exemple.
- Le même diagnostic à chaque commit, dans GitHub Actions ou Jenkins.
- Un rapport SARIF, un graphe et une heatmap, plutôt qu’une relecture périodique.
| Indicateur | Mesure | Cadre |
|---|---|---|
| Correspondance syntaxico-sémantique | 95,6 % | Cinq langages testés. Hypothèse de représentation commune confirmée, sans perte majeure — pas sans reste. |
| Détection des contradictions | 87,2 % | Jeux de tests labellisés (contradictoires, incomplets, conformes). |
| Faux positifs | 5,7 % | Même famille de corpus. Réduction identifiée comme suite de travail, pas comme acquis. |
| Temps de vérification | 36,8 s | Moyenne pour 10 000 politiques, cluster Kubernetes d’essai. Maturité partielle sur le temps de réponse. |
| Invariants RGPD | 7 vérifiés | Traduits et vérifiés sur corpus réel. La couverture réglementaire n’est pas complète. |
| Stabilité du solveur | 82 % | Des cas indéterminés, traités ensuite par partitionnement. Un indéterminé n’est pas affiché comme une preuve. |
05 — Pour qui
Les équipes qui répondent de la donnée.
RSSI, DPO, DSI, architectes sécurité, data managers et équipes DevSecOps d’entreprises data-intensive — ETI et grands comptes. Les premiers pilotes visés sont la finance et la santé.
RSSI / CISO
Voir une contradiction entre politiques avant qu’elle ne devienne un incident.
DPO
Faire d’un invariant de conformité une formule que le solveur peut échouer.
DSI
Une gouvernance des données qui suit la chaîne de livraison, pas un tableur d’audit.
Architectes sécurité
Une carte des dépendances et des conflits, à partir des langages déjà en place.
Data managers
Relier rôles IAM, vues SQL et policies OPA dans une seule lecture.
DevSecOps
Le contrôle au commit, avec un rapport SARIF que la revue sait déjà lire.
06 — Société
Bumker.io, R&D sécurité des données, à Paris.
Bumker.io SARL mène le programme « Policy-as-Code vérifiée formellement ». PolicyGuardian en est la valorisation industrielle : un moteur en Python et Go couplé à Z3, une API de vérification et de diagnostic, une interface pour explorer dépendances et contradictions.
Le système a été validé en environnement représentatif (TRL 5 à 6) et exercé sur des chaînes DevSecOps. Il n’est pas industrialisé pour un déploiement client à grande échelle. L’objectif de cette phase est le passage vers un produit pilote, pas une offre générale.
- Siège. 10 rue de Penthièvre, 75008 Paris.
- Gérance. Jean-Emmanuel Orfèvre.
- Moteur. Prototype Python / Go, solveur SMT Z3, parsing multi-langages.
- Chaîne. GitHub Actions, Jenkins, rapports SARIF.
- Lecture. Graphe de dépendances et heatmap de couverture, issus des outils de démonstration du programme.
07 — Contact
Parler d’un pilote, ou d’un point technique.
Pas de grille tarifaire. Pas de souscription en ligne. L’échange se fait directement avec Bumker.io.
Écrivez pour un corpus de politiques réel, un branchement CI, ou une lecture des limites actuelles du moteur. Les chiffres de cette page restent des mesures de R&D.