Il n’y a pas encore si longtemps, la plupart des entreprises se focalisaient d’abord sur l’intégration, le développement et l’automatisation des tests dès les premières étapes du cycle de vie du produit. Puis, les choses ont évolué et les équipes de livraison agile ont adopté un mode de développement itératif et des pratiques de surveillance pour améliorer la qualité du code.
Aujourd’hui, l’approche DevOps travaille à rapprocher les équipes de développement de logiciels (Dev) et d’exploitation (Ops), pour accélérer le lancement des produits sur le marché, tout en réduisant les interactions humaines. On comprend pourquoi DevOps et l’automatisation revêtent une importance capitale pour l’activité des entreprises.
Utilisation plus productive des ressources, lancements réguliers de nouvelles fonctionnalités, applications plus robustes… : les avantages sont nombreux. Toutefois, la stabilité d’un environnement de production passe par l’intégration de la sécurité dans le pipeline DevOps.
Impossible cependant de s’en remettre aux approches traditionnelles basées sur des modèles et des listes de contrôle qui ne sont pas adaptées. Selon GlobalSign, plusieurs bonnes pratiques permettent de renforcer la sécurité au niveau du DevOps, ce critère restant le principal frein à la livraison continue.
- Impliquer les équipes de sécurité dans la mise en place de l’architecture
Lors de la mise en place de l’architecture, l’équipe DevOps s’attache à répondre à toutes les exigences qu’impose la création de l’infrastructure cloud. Les équipes de sécurité doivent être impliquées dès ce stade, afin de mesurer l’envergure de la tâche, car suivant les éléments du processus d’architecture, les protections seront différentes. Selon le modèle de sécurité choisi, l’entreprise sera face à un paradigme de sécurité unique. Il est alors fortement recommandé d’opter pour la modélisation des menaces, afin d’identifier les éléments qui nécessitent une attention supplémentaire (comme la confidentialité) et les actions à exécuter immédiatement pour garantir une protection optimale. - Utiliser les révisions de code pour renforcer la sécurité
Les révisions de code sont une pratique DevOps courante, mais bien souvent négligée sur le plan de la sécurité. Or, l’absence de révision de code peut avoir plusieurs conséquences : vol du code, incapacité à identifier un code malveillant, « code inerte », etc. L’équipe de sécurité se doit donc de sensibiliser les autres professionnels aux techniques et pratiques de sécurité au niveau du code pour atténuer les risques associés. Pour identifier les vulnérabilités potentielles, cette démarche nécessite de comprendre le processus de révision de code appliqué par le DevOps et de valider différents éléments par une analyse statique du code réalisée dans le cadre du processus de compilation. Cela permettra ainsi aux développeurs de changer leurs techniques de codage pour répondre aux exigences de sécurité. - Réaliser un audit des scripts CloudFormation
Pour améliorer la sécurité, il n’y a pas de secret : il faut se plonger dans l’univers DevOps et notamment dans la notion « d’Infrastructure as Code (IAC) ». Cette méthode permet aux développeurs d’automatiser la mise en place d’infrastructures à l’aide de fichiers de configuration et de scripts. Du point de vue de la sécurité, il est donc possible d’inclure des contrôles automatisés pour chaque script. Par exemple, si un développeur crée un script d’infrastructure pour stocker des fichiers associés à un accès public via Internet, ce script peut immédiatement être identifié comme une erreur. Si l’on ajoute à cela une modélisation des menaces, on dispose alors de puissants outils pour valider la sécurité de l’infrastructure chaque fois qu’un développeur effectue une modification. - Exécuter des tests de sécurité « post-build »
Les tests unitaires et de compilation automatisés sont au cœur du DevOps. Les équipes de sécurité disposent là d’une excellente occasion d’apporter leur précieux éclairage en intégrant des outils de test de sécurité capables d’automatiser le processus de validation et d’améliorer l’efficacité du processus de vérification du code.
Autrefois, l’exécution de tests en fin de projet entraînait des retards importants, ce que résolvent aujourd’hui les processus d’automatisation en temps réel. C’est le rôle de l’équipe de sécurité de rechercher des outils de test de sécurité automatisés et de les intégrer au processus de compilation. - Muscler le système d’exploitation
Si l’on utilise des scripts pour mettre en place des serveurs, il est nécessaire de penser aussi à ajouter des scripts pour isoler le système d’exploitation. Il s’agit effectivement de migrer d’une « Infrastructure as Code » vers une « Secure Infrastructure as Code » afin d’être en mesure d’identifier les failles de manière proactive et intelligente. Mais attention, en attendant la fin de projet pour renforcer le système d’exploitation, le risque est de perturber le fonctionnement de l’application.
En agissant en début de projet, l’entreprise est doublement gagnante. Elle pourra, en effet, identifier les problèmes instantanément tout en favorisant la collaboration entre les équipes de sécurité et de développement. Ces équipes pourront ainsi réfléchir ensemble aux meilleures façons de procéder, si la sécurité doit être assouplie. Or, si cela devait se produire tardivement dans le projet, ce serait à l’équipe de développement de s’imposer pour résoudre le problème. D’ailleurs, il existe des outils tels que le CIS Benchmark ou la liste des contrôles de sécurité critiques du SANS Institute. - Renforcer le déploiement dans le cloud
Lorsque le renforcement est correctement réalisé, les services cloud peuvent fournir des infrastructures extrêmement sécurisées. Mais ils peuvent aussi engendrer de nouveaux problèmes de sécurité. Il est donc primordial d’examiner sa stratégie de déploiement cloud (authentification multifacteur [jetons MFA], management des rôles dans la gestion des accès et des utilisateurs [IAM], groupes de sécurité, AMI standard, etc.) pour définir la façon dont son entreprise utilise le cloud. L’organisation se doit également de faire un point sur la séparation des tâches (ou droits/responsabilités) dans le cadre de la « Segregation of Duties (SoD) ». Ses développeurs ont-ils le droit de modifier l’environnement de production ? Ceux qui exercent une fonction hiérarchique supérieure et qui bénéficient de niveaux d’autorisation élevés doivent pouvoir accéder à la console, via une authentification à deux facteurs et une autorisation filtrée par adresse IP. Les accès doivent pouvoir se faire depuis l’entreprise ou à partir d’un service VPN sécurisé (dans le cas où l’entreprise externalise certains services et qu’elle doit fournir un accès à distance à des utilisateurs tiers). - Rechercher les vulnérabilités dans le système d’exploitation et les applications
La majorité des piratages et des vecteurs d’attaque se concentrent sur l’exploitation de vulnérabilités présentes dans les applications ou les systèmes d’exploitation qui s’exécutent sur les serveurs. Si l’on souhaite renforcer la sécurité, on doit mettre en place une supervision et une analyse rigoureuses de toutes les applications et des outils de test automatisés dans le pipeline DevOps. Il est également nécessaire d’exécuter régulièrement des analyses de détection des vulnérabilités, afin d’éliminer toutes les failles de sécurité dans le système d’exploitation ou les applications. Lorsque l’on choisit un logiciel, on doit identifier les composants présentant des risques connus et collaborer étroitement avec les développeurs pour corriger ces composants. - Intégrer des mises à niveau Phoenix
Pour accélérer le processus de déploiement d’un correctif d’application ou de logiciel, il faut penser aux mises à niveau Phoenix. Concrètement, chaque fois qu’une mise à jour est déployée, un nouveau serveur est créé au lieu de l’appliquer sur un serveur existant. Non seulement on gagne en agilité pour les déploiements de nouvelles versions, mais on améliore également les capacités à résoudre les problèmes de sécurité. Une version corrigée peut être déployée de manière sécurisée sur l’ensemble de l’environnement cloud, tout en réduisant le risque d’écarts de configuration et de dette technique. - Effectuer un audit temps réel de l’environnement de production
Il est extrêmement important d’avoir une visibilité post-déploiement, qui dépend du niveau d’audit réalisé. En règle générale, l’entreprise doit disposer de niveaux d’audit standard sur ses applications et les différents rôles de son serveur. Pour améliorer la sécurité, il lui faut un outil capable de lui fournir les données d’audit nécessaires sans submerger ses serveurs. Une fois tous ces éléments en place, l’entreprise pourra auditer l’environnement de production à tout moment, afin d’identifier les éventuelles divergences par rapport au profil de sécurité défini. Bien entendu, cela nécessite de collaborer étroitement avec l’équipe de développement pour déterminer les niveaux de journalisation et éviter tout écart de configuration.
DevOps : les quatre pièges à éviter
- Maintenir une vision fragmentée : à défaut d’une démarche commune, Top Down et sponsorisée, les initiatives DevOps se heurtent à d’inévitables divergences entre les équipes en charge de l’infrastructure, des tests, de la gestion de projet, du développement et de l’exploitation – qui sont susceptibles de complètement paralyser les processus.
- Sous-estimer l’importance d’une formation transversale : si l’équipe en charge de l’application est bien cross-fonctionnelle, les autres services restent cantonnés à des fonctions encore très limitées et compartimentées.
- Oublier de définir clairement les rôles de chacun : cet oubli est souvent identifié trop tard, une fois que le mal est fait, et que les problèmes sont avérés.
- Conserver une communication cloisonnée : à défaut de communiquer et de mutualiser régulièrement ces efforts, de manière à la fois centralisée, standardisée et cohérente, les contributions individuelles restent… individuelles.