Aujourd’hui, le 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 le 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.

Sans plus tarder, découvrons ensemble 9 bonnes pratiques pour renforcer la sécurité au niveau du DevOps, ce critère restant le principal frein à la livraison continue.

1. 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.

2. 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é.

3. 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 vous ajoutez à cela une modélisation des menaces, vous disposez alors de puissants outils pour valider la sécurité de l’infrastructure chaque fois qu’un développeur effectue une modification.

4. 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 temps réel. Si vous faites partie de l’équipe de sécurité, c’est à vous de rechercher des outils de test de sécurité automatisés et de les intégrer au processus de compilation.

5. 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, vous courez le risque 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.

6. 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], gestion 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’autorisations é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).

7. 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 de régulièrement exécuter 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.

8. Intégrer des mises à niveau Phoenix
Vous êtes-vous déjà retrouvé en difficulté en répondant à des menaces de sécurité ? Cela vous est-il déjà arrivé de trop tarder à déployer un correctif d’application ou de logiciel ? Pour accélérer le processus, pensez aux mises à niveau Phoenix. Concrètement, chaque fois que vous déployez une mise à jour, vous créez un nouveau serveur au lieu de l’appliquer sur un serveur existant.
Non seulement vous gagnez en agilité pour les déploiements de nouvelles versions, mais vous améliorez également vos 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 votre environnement cloud, tout en réduisant le risque d’écarts de configuration et de dette technique.

9. Effectuer un audit temps réel de l’environnement de production
Il est extrêmement important d’avoir une visibilité post-déploiement — visibilité 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 différentes 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.

En conclusion

Le DevOps est appelé à durer. Après tout, cette pratique s’est largement imposée comme la nouvelle manière de développer, publier et mettre à jour les produits tout au long de leur cycle de vie. Les professionnels de la sécurité doivent par conséquent abandonner les méthodes de sécurité traditionnelles au profit de solutions compatibles DevOps. Les bonnes pratiques présentées ci-dessus constituent un bon point de départ, mais une meilleure adaptation aux besoins de l’entreprise reste possible.