Plutôt que de déléguer la mise en application des règles de sécurité, ou pire de les remettre à plus tard, et si nous les automatisions pour en tirer les bénéfices d’une approche « as code » ? C’est l’objet du « Policy as Code », et dans cet article nous allons voir ce que recouvre ce concept et comment le mettre en oeuvre avec Open Policy Agent.

Comment sont gérées les Policies

Appelons « Polices » l’ensemble des règles et processus qui permettent d’encadrer la façon dont un système fonctionne. Il peut s’agir d’impératifs de sécurité, de règles de conformité ou de bonnes pratiques identifiées au cours du temps.

Citons quelques exemples, comme une convention de nommage permettant d’homogénéiser les ressources et faciliter le maintien en condition opérationnelle, la présence de tag obligatoires pour permettre une identification précise des coûts par projets, ou encore l’interdiction d’exposer des données publiquement.

Le traitement de ces polices peut prendre plusieurs formes. Parfois on fait simplement confiance aux intervenants (Devs, Ops, PO, …) pour gérer les aspects sécurité par eux mêmes. Parfois un référent de sécurité est dédié à la surveillance de ces points. Dans les plus grosses structures des équipes complètes peuvent être responsable de la rédaction de documents de références et de la surveillance de leur application.

Souvent les aspects sécurités sont gérés ponctuellement à certaines étapes clef du cycle de vie du projet : validation avant une mise en production, audit de sécurité ponctuels ou réguliers, correctifs suite à un incident…

Mais ces méthodes amènent leurs lots de problèmes. La gestion de la sécurité est décorrélée du cycle de vie du projet et elle ralenti souvent ce dernier. La charge de travail est difficile à estimer et à intégrer dans un planning. On prend de mauvaises décisions car on s’intéresse à la problématique trop tard, ou dans l’urgence…

Parfois on délaisse simplement le sujet, car après tout « jusqu’à présent on a jamais eu de soucis ».

Automatiser la gestion des règles de sécurité

A l’heure ou l’automatisation prend de plus en plus d’ampleur au sein des projets, pourquoi ne pas l’utiliser pour gérer également nos règles de sécurités ?

Similairement à ce que des outils comme Terraform apportent à la gestion de l’infrastructure (#InfrastructureAsCode), il existe des outils permettant de traduire des Polices en code et d’en tirer tout les bénéfices du « As Code » :

• Automatiser. Qu’il y ai un ou cent projets le passage à l’échelle peut se faire. Les retours sont plus fréquents, plus rapides et plus fiables. On s’affranchit des goulots d’étranglements induits par des vérifications manuelles et on limite les risques d’erreurs humaines.
• Versionner. Le code de nos Polices est à jour et il fait foi. Tout les changements y sont tracés et historisés. Le code peut évoluer, être commenté pour expliquer un contexte particulier mais il n’y a plus de place pour l’interprétation.
• Tester. On s’assure que nos Polices remplissent bien leur rôles. Que les changements qu’on y apporte n’ont pas d’effet de bord ou qu’ils ne paralyseront pas le système.

C’est l’idée derrière le « Policy As Code » qui permet de traduire des processus et règles de sécurité en code pour systématiser, fiabiliser et simplifier la gestion de la sécurité.

Open Policy Agent

Si cela vous intéresse je me suis essayé à l’exercice et je vous renvoie vers mon article : Assurer la conformité de son code Terraform avec Open Policy Agent.

Le but est d’utiliser Open Policy Agent pour vérifier les changements prévus par Terraform avant qu’ils ne soient appliqués à l’infrastructure. Cette solution nous permet notamment de :

• Décorréler les règles d’implémentations et les manifestes Terraform pour garder le contrôle de l’infrastructure.
• Rendre les utilisateurs autonomes et leur apporter des retours clairs sur les points à améliorer en cas de non conformité.
• Optimiser la chaîne d’intégration continue pour que les vérifications de conformité soient automatisées et les retours rapides.

Bonne lecture !