L’Infrastructure as Code, quels risques et quelles opportunités ?

Qu’est-ce que l’Infrastructure as Code ?

L’Infrastructure as Code (IaC) est née du besoin de rendre plus efficientes les tâches de configuration des infrastructures, en les rendant plus rapides, moins coûteuses et plus fiables. En effet, il y a quelques années, il n’était pas rare de prendre quelques jours pour installer un serveur et il était même envisageable d’attendre plusieurs semaines voire plusieurs mois entre la commande d’un serveur et sa livraison ! Ce n’est plus le cas aujourd’hui alors que l’instanciation (création d’une ressource à partir d’un modèle) ne prend plus que quelques instants.

L’Infrastructure as Code s’intègre particulièrement bien dans la mouvance DevOps, pratique apparue en 2007, qui vise à l’unification du développement logiciel (Dev) et de l’administration des infrastructures informatiques (Ops). Aujourd’hui, nous parlons de plus en plus de DevSecOps afin d’intégrer les besoins en sécurité (Sec) pendant tout le cycle de vie des solutions.

L’IaC est un concept qui a pour objectif d’automatiser le déploiement et la configuration de ressources informatiques au sens large en stockant les étapes d’installation et les configurations sous forme de code informatique afin d’en faire un processus :

Robuste : car les nombreuses itérations et la rigueur du code permettent de détecter rapidement la moindre faiblesse.

Répétable : car ce code peut être réutilisé et adapté sur d’autres projets.

Portable : car si l’on souhaite changer notre infrastructure d’environnement (région, réseau ou souscription du CSP), c’est possible.

L’Infrastructure as Code peut correspondre à deux briques fonctionnelles :

• Un Orchestrateur

Il communique avec les fournisseurs de ressources afin de pouvoir déployer les composants décrits dans le code de configuration, il doit notamment être capable d’adapter l’infrastructure existante en cas de changement du code. L’orchestrateur peut dans certains cas déployer des configurations systèmes et logicielles sur les ressources fournies. On pourra citer quelques solutions du marché comme CloudFormation (AWS) ou Terraform.

• Un Gestionnaire de configuration

Le gestionnaire de configuration permet de gérer les configurations des systèmes ainsi que leurs composants pour ensuite les déployer/maintenir sur l’infrastructure provisionnée par l’orchestrateur. Des outils tels que Puppet ou Chef peuvent tenir ce rôle.

Il est par ailleurs possible de faire du provisionning avec certains gestionnaires de configuration et inversement de configurer les infrastructures avec certains orchestrateurs. Cependant l’aspect spécialisé de ces outils nous amène à les utiliser de façon complémentaire pour une plus grande facilité de gestion des ressources.

Il est important de préciser que la coopération entre ces deux solutions n’est pas systématique. Un exemple serait l’utilisation de Docker qui viendrait combler le besoin d’un gestionnaire de configuration.

Plusieurs approches sont possibles avec l’IaC :

• Impérative / Procédurale: les configurations des ressources sont décrites via une liste d’instructions enchaînées permettant d’atteindre l’état voulu de configuration ;
• Déclarative: l’état final est décrit dans un fichier de configuration. L’ordre de déclaration en lui-même n’a pas d’importance majeure ;
• Intelligente: les ressources sont déclarées de manière à ce que leur configuration finale et leur état soit en cohérence avec le reste de l’environnement qui l’entoure. C’est la prochaine génération d’Infrastructure as Code.

Les modèles de communication peuvent être différents :

• Modèles « Agent-Based» vs « Agentless » : installation ou non d’un agent sur les systèmes cibles pour que la solution IAC puisse transmettre ses instructions ;
• Modèle « Push» vs « Pull » : « Push » si la solution IAC envoie les informations aux cibles mais « Pull » si ce sont aux cibles de venir chercher leur configuration sur le serveur.

L’implémentation de l’Infrastructure as Code nécessite un engagement fort des équipes projets

La mise en place d’une solution d’IaC impose un renouvellement complet de la manière de livrer des applications et de mettre en place des infrastructures. Plusieurs prérequis sont donc nécessaires afin que la transition se passe pour le mieux.

Tout d’abord ces solutions sont avant tout des solutions techniques. Des ressources humaines qui maîtrisent ces solutions sont nécessaires afin de mener à bien un projet d’implémentation et pour maintenir ensuite la solution dans le temps. La configuration de serveurs s’effectuant sous forme de code, les administrateurs doivent aussi acquérir de nouvelles compétences orientées vers le développement et donc être formés à ces nouvelles méthodes de déploiement. Ces solutions imposent aussi des changements au niveau du fonctionnement de l’entreprise, qui doit s’adapter à l’accélération des processus permis par l’IaC afin de ne pas créer un environnement à deux vitesses.

Pour cela, une implication forte du management dès le début du projet est primordiale, permettant de mettre en place des processus efficaces et opérationnels et d’apporter le soutien nécessaire au renouvellement des compétences des utilisateurs de la solution.

L’adoption de l’IaC passe également par l’identification des leviers et un changement de paradigme pour les équipes projets

 Des fonctionnements déjà en place peuvent aussi, bien qu’ils ne soient pas nécessaires, devenir des leviers pour la mise en place de solution IaC. Une culture d’entreprise inscrite dans la mouvance DevOps limitera par exemple les modifications à réaliser dans l’organisation afin de s’adapter au fonctionnement de l’IaC. D’autres leviers existent, comme une infrastructure basée sur le cloud et la virtualisation ou l’utilisation de chaines d’intégration et de déploiement continues. Ces leviers et les équipes déjà impliquées seront des points d’appui au sein de l’entreprise afin de s’assurer de l’adoption rapide d’une solution IaC.

Des points peuvent au contraire freiner la mise en place et l’adoption de l’IaC. Une infrastructure non standardisée sera par exemple un frein à un déploiement efficace et automatique. En effet, beaucoup de spécificités devront être paramétrées, faisant perdre une partie de l’intérêt de la centralisation de l’infrastructure. Les campagnes de mises à jour seront ainsi plus fastidieuses.

L’Infrastructure as Code présente des bénéfices évidents dès l’implémentation

L’implémentation d’une solution d’IaC apporte divers bénéfices pour l’entreprise, tant du point de vue opérationnel que sécurité.

En effet, elle permet notamment une administration facilitée des infrastructures, une meilleure fiabilité des processus et une auditabilité accrue grâce à la centralisation des fichiers de configuration.

L’Infrastructure as Code induit de nouveaux risques impératifs à maîtriser

Réplication et introduction d’erreurs systématiques

L’automatisation et l’échelle à laquelle des déploiements peuvent être effectués entraînent des risques de réplication d’erreur. En effet, là où dans un contexte classique une erreur de configuration sur un serveur avait un impact limité, une erreur de configuration dans un contexte IaC peut avoir des impacts sur un nombre important de serveurs. Cela peut donc entrainer le déploiement d’une vulnérabilité sur un nombre important de serveurs d’un seul coup.

Sécurité du référentiel de code

Le code et paramétrage issu des outils « Infrastructure as code » devient également une cible de choix pour un attaquant qui souhaite introduire des erreurs et des vulnérabilités dans le déploiement des infrastructures de l’entreprise : une intégrité sans faille doit ainsi être mise en place sur les différents répertoires de stockage de code source (chiffrement, contrôle d’accès, contrôle d’intégrité, monitoring, versionning, …), et ce au même titre que n’importe quel autre référentiel de données métiers.

Risque de perte de connaissance

Du point de vue ressources humaines, un risque de perte des connaissances autour de la solution et du fonctionnement des configurations est aussi présent, par manque de documentation ou en cas de départ de ressources essentielles.

Il est en ce sens nécessaire de s’assurer que les équipes techniques documentent régulièrement leur code et leur infrastructure. Cette documentation devra également être sécurisée (selon sa criticité).

Perte de maitrise du niveau de sécurité des applications

Une adaptation des outils doit aussi être réalisée, et en particulier des outils de sécurité. Les solutions d’IaC permettent des déploiements d’infrastructure en masse ou encore des déploiements d’applications plus régulières. Si les équipes sécurité ne s’outillent pas correctement, en particulier sur la sécurité des développements et le monitoring, elles ne pourront pas assurer un contrôle efficace des mesures de sécurité liés à ces nouveaux usages. Elles risquent ainsi de compromettre le niveau de sécurité des infrastructures et des applications.

Les équipes de sécurité doivent en ce sens maîtriser les technologies cloud et s’intégrer naturellement aux équipes DevOps grâce, par exemple, à des outils automatisés d’audit et d’auto-remédiation (SDK, API, Infra-as-Code d’outils de sécurité, etc.).

Par son expérience en gestion de risques et en sécurisation des développements, HeadMind Partners peut vous accompagner sur la maîtrise des risques autour de l’implémentation d’une solution IaC.

Si vous souhaitez en savoir plus, nos experts sont mobilisés pour vous accompagner dans la réflexion, l’analyse et l’intégration d’une approche Infrastructure as Code dans vos défis de demain !

Co-écrit par Sofiane Bengaoua, Jean-Baptiste Favrot et Al’hossein Laaguel.