Qu’est-ce que le policy as code (PaC) ?

Au lieu de compter sur des êtres humains pour vérifier la conformité ou mémoriser les règles de sécurité, ces règles existent sous forme de logique exécutable qui s’applique chaque fois qu’un développeur ou un système propose une modification ou une requête. Si quelqu’un soumet une modification, un moteur de politiques évalue automatiquement cette modification par rapport aux règles codées et l’autorise, la refuse ou la signale.

Ce système remplace les pratiques de gestion des politiques basées sur des documents statiques par une surface de contrôle dynamique, appliquée en continu et intégrée au pipeline de livraison logicielle.

Les règles basées sur du code permettent de garantir que les mêmes politiques sont appliquées partout, de manière reproductible et évolutive. Les moteurs de politiques peuvent effectuer des vérifications automatisées en quelques secondes lors des builds ou des déploiements, ce qui réduit les cycles de retour d’information et évite aux équipes DevOps des surprises de dernière minute en matière de sécurité ou de conformité.

Le PaC permet aux entreprises d’améliorer leur posture de cybersécurité globale et de maintenir leur conformité aux normes sectorielles et réglementaires. De plus, le fait de traiter les politiques comme du code s’inscrit dans une transition plus large vers le modèle « everything as code » (ou tout en tant que code), qui transforme des éléments tels que les demandes d’infrastructure en fichiers de code pouvant être examinés et autour desquels les équipes de développement peuvent collaborer.

Dans le contexte DevOps, une politique est une règle claire et applicable concernant la manière dont l’infrastructure informatique et les applications doivent être configurées, accessibles ou exécutées. Plus précisément, ces politiques dictent quelles actions sont autorisées, requises ou interdites afin que les systèmes continuent de fonctionner dans leur état optimal. 

Par exemple, « tous les compartiments de stockage doivent être chiffrés » ou « aucun service public ne peut ouvrir le port 22 » sont des politiques, car elles spécifient des contraintes concrètes sur le comportement du système.

Avec le PaC, les politiques sont rédigées dans un langage de programmation structuré, ce qui permet aux moteurs de politiques et aux outils d’automatisation de les analyser et de les évaluer de manière déterministe. Ainsi, les politiques deviennent des garde-fous exécutables auxquels les systèmes et les ingénieurs doivent se conformer, plutôt que de simples lignes directrices susceptibles d’être interprétées différemment selon les personnes.

Les outils de policy as code permettent aux développeurs d’intégrer du code exécutable dans les environnements d’exécution et les pipelines CI/CD (intégration continue/livraison continue), de sorte que chaque modification soit automatiquement vérifiée quant à sa conformité.

D’un point de vue technique, la plupart des configurations PaC suivent les mêmes grandes étapes :

• Les développeurs rédigent les politiques sous forme de fichiers de code. Ils peuvent utiliser toute une gamme de langages impératifs et déclaratifs de haut niveau, notamment Python, YAML, JavaScript Object Notation (JSON) ou Rego, qui est généralement utilisé en association avec Open Policy Agent (OPA), un moteur de politiques open source. Chaque fichier de politique déclare les entrées qui l’intéressent (« resource.kind », « metadata.labels » par exemple) et encode des conditions, également appelées « prédicats », ainsi que des résultats (autoriser/refuser, niveau de gravité, messages).

• Le code est soumis à un système de contrôle de version, tel que Git ou GitHub, et suit les mêmes workflows que le code d’application, notamment les pull requests, l’examen du code et des tests syntaxiques rigoureux.

• Un moteur de politiques lit le fichier de code, l’analyse et le transforme en structures de données et en instructions compréhensibles en interne. Ces structures et instructions sont ensuite converties en un format d’instructions compact et de bas niveau (bytecode) afin de permettre une évaluation rapide.

• Un appelant, c’est-à-dire la partie de code qui demande au moteur de politiques de prendre une décision, normalise les données d’entrée. Il traite différents formats d’entrée, notamment les fichiers HCL (HashiCorp Configuration Language) et les modèles JSON provenant d’outils IaC, les manifestes YAML issus de Kubernetes et des plateformes cloud, les requêtes HTTP issues d’appels d’API, ainsi que les données d’application et de télémétrie provenant des environnements d’exécution et de production. Il nettoie et restructure les entrées brutes pour les uniformiser en une structure standard, afin que les politiques puissent les lire de manière cohérente.

• L’appelant renvoie les données normalisées au moteur de politiques, qui commence à exécuter le code de politique sur ces données d’entrée.  

• Le moteur de politiques parcourt les règles et vérifie les prédicats de chacune d’entre elles par rapport aux données d’entrée afin de déterminer quels prédicats s’appliquent. On peut considérer que le moteur de politiques se demande : « Que dit cette règle à propos de cette entrée ? »

• Le moteur de politiques rassemble les résultats de toutes les règles et les combine en une seule décision de politique, un processus appelé « agrégation de décisions », puis crée une liste de messages. Ces messages fournissent davantage de détails (quelle règle a été enfreinte et quel objet l’a enfreinte) concernant le code non conforme et proposent parfois des suggestions pour résoudre le problème.

• Le moteur de politiques renvoie la décision, accompagnée des messages pertinents, des balises et des informations de gravité. Si la décision est « refuser », le moteur de politiques bloque toutes les pull requests et les fusions de code, et suspend le déploiement jusqu’à ce que les développeurs effectuent la résolution de la violation de la politique. Si la décision est « autoriser », le moteur crée un artefact de build (un fichier de code compilé, packagé et testé) et déploie le code. En cas d’avertissements, la validation du code est autorisée, mais le moteur inclut ces avertissements dans les fichiers journaux ou sous forme de commentaires. 

Les vérifications de conformité peuvent avoir lieu à n’importe quelle étape du cycle de développement logiciel (SDLC), de l’intégration du code à la mise en production et à la surveillance.

Les politiques étant du code, elles peuvent également être traitées comme n’importe quel autre artefact logiciel.

Les équipes de développement peuvent écrire des tests automatisés qui fournissent des exemples d’entrées aux politiques et vérifient les décisions qu’elles renvoient, afin d’accélérer les cycles de retour d’information en cas de modification des politiques.

Lorsque les politiques sont codées, les développeurs peuvent extraire la logique commune pour en faire des modules ou des fonctions réutilisables. Plusieurs politiques de niveau supérieur peuvent alors faire appel à des politiques partagées au lieu de dupliquer les conditions partout.

Les développeurs peuvent également renommer, restructurer ou diviser de grandes politiques en politiques plus petites sans modifier leur comportement, tout comme lorsqu’on refactorise une grande fonction d’application en fonctions plus petites.

Grâce à ces capacités, les équipes peuvent appliquer les pratiques existantes d’ingénierie logicielle à la logique de gouvernance, et ainsi respecter les exigences de sécurité et de conformité à mesure que les architectures informatiques évoluent et s’étendent.

Imaginons que l’entreprise X souhaite mettre en œuvre une politique « HTTPS uniquement » selon laquelle chaque service Web doit utiliser le protocole HTTPS, et non le protocole HTTP en clair. Pour codifier cette politique, un ingénieur de plateforme rédige une règle simple qui stipule :

• Si le protocole d’un service est HTTP, la modification doit être rejetée.
• Si le protocole d’un service est HTTPS, la modification est autorisée.

L’ingénieur place ce fichier de politique dans un dossier « policies » (politiques) situé dans le même référentiel de code que l’application, puis ouvre une pull request afin d’ajouter la politique. Cette pull request déclenche une vérification syntaxique automatique du fichier de politique ainsi qu’un examen du code par un autre ingénieur. Ce n’est qu’une fois que la politique a réussi les tests requis qu’elle est fusionnée dans la branche principale.

Dans le pipeline d’intégration continue (CI), tous les fichiers de politique sont chargés dans le moteur de politique à partir du dossier « policies ». Le moteur de politiques lit la politique, la convertit en une représentation interne et la compile sous une forme compacte de bas niveau. Cette dernière permet au moteur de répondre rapidement à la question « autoriser ou refuser ? » pour chaque service vérifié par le pipeline.

Quel que soit le format du fichier, une tâche CI prend le fichier de configuration existant, en extrait les champs importants (nom, protocole, port) et crée une description JSON simple de chaque service.

L’appelant demande une décision au moteur de politiques en envoyant la description standardisée du service en entrée et en indiquant que l’ensemble de politiques « HTTPS uniquement » doit être appliqué.

Le moteur de politiques évalue ensuite l’entrée par rapport aux règles. Il vérifie le champ « protocole » du service. Si le protocole est HTTP, cela signifie que l’entrée correspond à la condition « refuser » de la politique. Le moteur indique que la modification doit être refusée et génère un message informant le développeur que le service doit utiliser HTTPS à la place de HTTP. Si le service utilise HTTPS, aucune des conditions de refus n’est remplie, et le moteur indique que la modification est autorisée.

Ensuite, le moteur de politiques synthétise les évaluations des règles en un seul objet de décision pour le service. Les objets de décision précisent généralement si la décision globale est « autoriser » ou « refuser » et quel est le niveau de gravité du problème (élevé, moyen, faible). Ils comprennent également une liste de messages expliquant pourquoi l’entrée a été refusée, ainsi que les avertissements détectés par le moteur au cours du processus d’évaluation. Si tout est conforme, l’objet de décision indique que la modification est autorisée et ne contient que des notes d’information (voire aucun message).

Enfin, les outils CI appliquent la décision. Si la décision est « refuser », la modification ne parvient pas à être fusionnée dans la branche principale du code. L’ingénieur voit s’afficher un message d’erreur indiquant que le service doit utiliser le protocole HTTPS et subir des modifications spécifiques. Si la décision est « autoriser », l’artefact est packagé et déployé, et le pipeline d’intégration continue se déroule normalement.

Le concept de policy as code est né du mouvement plus large « everything as code » dans le domaine du DevOps moderne et de l’ingénierie cloud.

À l’origine, c’est l’infrastructure as code (infrastructure en tant que code ou IaC) qui a constitué un changement majeur. Au lieu que les administrateurs système cliquent dans des interfaces utilisateur ou suivent des runbooks, (dossiers d’exploitation), les équipes décrivaient les serveurs, les réseaux et autres ressources dans des fichiers de code déclaratifs. Ces fichiers étaient stockés dans des systèmes de contrôle de version et appliqués via des pipelines automatisés.

Lorsque les entreprises en ont constaté les avantages, cette approche s’est étendue à d’autres composants des architectures informatiques. La configuration des applications s’est orientée vers des approches basées sur le code. Les pipelines CI/CD sont devenus des scripts hébergés dans des référentiels de code. Les règles de surveillance et d’alerte ont elles aussi commencé à être définies sous forme de code. Ensemble, ces pratiques ont été baptisées « everything as code ».

L’idée centrale du concept « everything as code » est la suivante : si une partie du système peut être décrite, elle doit l’être sous forme de code et être gérée de la même manière que les applications logicielles.

Le PaC consiste essentiellement à appliquer cette philosophie aux règles, à la gouvernance et à la conformité. Traditionnellement, les politiques étaient consignées dans des fichiers PDF et sur des wikis, ou décidées en comité, et leur application était assurée par des êtres humains. Ce processus fonctionnait lorsque les cycles de mise en production étaient lents et que l’infrastructure était relativement statique.

Avec l’avènement des architectures cloud natives et des microservices, et alors que les équipes commençaient à déployer du code plusieurs fois par jour, les processus manuels ne parvenaient plus à suivre le rythme. Le PaC a relevé ce défi en exprimant les politiques dans des formats lisibles par machine, afin qu’elles puissent être gérées par versions dans Git, examinées comme des fichiers de code, testées en CI et appliquées automatiquement dans les pipelines ou lors de l’exécution.

Le policy as code permet de gérer les politiques informatiques à la manière du code logiciel. L’infrastructure as code (IaC) repose sur un principe similaire, mais avec une orientation différente. Cette approche permet aux équipes d’ingénierie de définir et de gérer l’infrastructure informatique à l’aide de code d’application.

Au lieu de créer et de configurer manuellement des ressources réseau telles que des machines virtuelles (VM) et des équilibreurs de charge, l’IaC permet aux développeurs d’écrire du code pour décrire l’état souhaité de ces ressources. Un outil IaC utilise ensuite ce code pour créer ou modifier les ressources spécifiées.

L’IaC facilite considérablement le dimensionnement et l’automatisation de l’infrastructure. Si une équipe a besoin de plus de serveurs, il lui suffit de modifier un chiffre dans le code (passer de six instances à neuf par exemple). Les outils d’automatisation se chargent des détails liés au provisionnement de ces ressources supplémentaires.

D’un point de vue général, l’IaC définit quelle infrastructure doit exister et comment elle doit être configurée, tandis que le PaC se concentre sur les règles et les contraintes auxquelles cette infrastructure doit se conformer. Le code IaC crée et configure les ressources, tandis que le code PaC permet de s’assurer que ces ressources (et la manière dont elles sont utilisées) respectent les exigences de sécurité, les normes de conformité et les garde-fous opérationnels définis.

Dans de nombreuses architectures informatiques modernes et configurations CI/CD, l’IaC et le PaC présentent des avantages complémentaires. L’IaC automatise le provisionnement, tandis que le PaC y ajoute une gouvernance automatisée.

Lorsqu’un développeur modifie un fichier IaC, un moteur PaC peut inspecter le nouveau plan ou la nouvelle configuration. Si tout est conforme aux politiques établies, la modification est autorisée et l’infrastructure est mise à jour. En cas de violation d’une règle, le pipeline échoue et aucun déploiement n’a lieu tant que le problème n’est pas résolu.

Le DevSecOps consiste à intégrer la sécurité et la conformité au cœur du cycle de vie DevOps, plutôt que de les ajouter en fin de processus. Il s’agit d’une approche de développement dans laquelle les processus de sécurité sont hiérarchisés et exécutés à chaque étape du cycle de développement logiciel.

Le PaC soutient les pratiques DevSecOps en :

Le PaC permet aux équipes d’anticiper la sécurité en déplaçant les contrôles de sécurité vers les premières étapes du processus de développement, plutôt qu’après le déploiement, moment où les problèmes peuvent affecter les utilisateurs. Si un développeur introduit une configuration risquée ou un modèle non sécurisé, le problème sera détecté par des politiques automatisées et la compilation échouera.

Les outils PaC automatisent l’application des politiques en intégrant directement les règles de sécurité dans les pipelines CI/CD et les systèmes d’exécution, de sorte que les contrôles s’effectuent automatiquement à chaque modification du code ou de l’infrastructure. Au lieu de compter sur des intervenants humains pour mémoriser chaque norme de sécurité et examiner manuellement chaque modification, le système évalue systématiquement les changements afin de garantir qu’aucune étape ne soit accidentellement omise.

Le PaC permet aux développeurs de maintenir la vitesse de déploiement sans compromettre la cohérence ni la sécurité. Il applique les mêmes définitions de politiques dans tous les environnements et à chaque étape : développement, tests, préproduction et production. Les équipes peuvent ainsi effectuer des mises en production fréquentes, car elles ont l’assurance que le même ensemble de règles est appliqué partout. Elles évitent également les situations où les différents environnements divergent ou appliquent des interprétations légèrement différentes des règles.

Le PaC traite les politiques de sécurité des applications comme n’importe quel autre artefact de code hébergé dans un système de contrôle de version. Les équipes de développement, d’exploitation et de sécurité peuvent toutes examiner, commenter et mettre à jour les politiques via des workflows familiers (examens de code, stratégies de branchement), ce qui rend les discussions sur les politiques plus transparentes et mieux intégrées au travail quotidien de développement.

Le policy as code offre un large éventail d’applications pour les architectures informatiques d’entreprise.

Les développeurs et les professionnels de la sécurité étudient actuellement le policy as code comme moyen de créer des modèles de garde-fous à plusieurs niveaux couvrant l’ensemble du cycle de vie d’un workflow agentique ou d’IA. Bien que cette pratique soit encore naissante, les premières études ont révélé de nombreuses applications possibles du PaC dans les workflows d’IA.

Le PaC permet d’établir une séparation claire entre le raisonnement de l’IA et le système qui décide des actions qu’elle est réellement autorisée à exécuter. L’outil d’IA peut proposer des actions ou des plans, mais un moteur de politiques évalue ces propositions à l’aune de règles codifiées avant que tout système sous-jacent ne soit sollicité.

Au stade de la saisie, le PaC permet de filtrer ou de transformer les prompts des utilisateurs, de masquer les données sensibles, d’assurer l’isolation des entités et de bloquer les schémas d’attaque connus. Lors de la planification, le PaC peut exiger des agents d’IA qu’ils produisent des plans structurés et valident chaque étape au regard des outils, actions et conditions de risque autorisés avant que l’exécution ne soit autorisée.

Au moment de l’exécution, chaque invocation d’outil ou appel d’API peut être vérifiée par la couche d’application des politiques. Cette couche décide s’il convient d’autoriser, de refuser ou de modifier une action, ou de la transmettre à un intervenant humain. Après l’exécution, les politiques peuvent piloter la journalisation, les pistes d’audit, les règles de conservation et les filtres a posteriori sur les résultats des modèles afin de garantir que les réponses respectent les exigences requises.

• Cohérence. Avec le PaC, les politiques sont appliquées de la même manière dans tous les environnements, car le même code s’exécute partout. Cette cohérence réduit les configurations ponctuelles et atypiques et évite aux équipes d’avoir à mémoriser des processus manuels légèrement différents pour chaque environnement.

• Efficacité. Lorsque les politiques sont codifiées, elles peuvent être appliquées automatiquement dans les pipelines CI/CD ou au moment du déploiement, ce qui évite les vérifications et les validations manuelles.

• Automatisation. Le PaC prend en charge la validation et les tests automatisés des politiques, ce qui aide les équipes à minimiser l’impact des erreurs humaines, à détecter les erreurs de configuration et à corriger les failles de sécurité avant qu’elles n’affectent l’environnement de production.

• Visibilité.Les politiques étant rédigées sous forme de code et stockées de manière centralisée, les parties prenantes peuvent voir exactement quelles règles sont en vigueur, au lieu de se fier à des documents épars et à la mémoire des personnes.

• Évolutivité.L’évaluation des politiques étant automatisée, les entreprises peuvent appliquer ces dernières aux nombreux services, clusters ou comptes sans augmentation proportionnelle des effectifs.

• Collaboration. Le PaC rationalise la collaboration autour du code des politiques. Ces workflows partagés éliminent les silos, alignent la sécurité et la gouvernance sur les pratiques DevOps et rendent les discussions sur les politiques plus concrètes et plus facilement vérifiables.