Les bonnes pratiques en matière de sécurité DevOps
Introduction
La sécurité en DevOps, ce n'est pas un sujet optionnel qu'on traite en fin de projet. C'est une conviction que j'ai forgée mission après mission, particulièrement dans des secteurs réglementés comme la Défense et la santé. Voici les pratiques que j'applique concrètement sur le terrain.
Intégrer la sécurité dès le Day 1
Sur une mission récente dans le secteur de la Défense, la sécurité n'était pas négociable. Dès le premier jour, j'ai mis en place : des profils seccomp sur tous les pods, l'obligation de conteneurs non-root, du RBAC granulaire et des NetworkPolicies qui bloquent par défaut tout trafic non explicitement autorisé. Ce niveau de durcissement est devenu mon standard, même sur des projets moins sensibles.
Chez un client e-santé certifié HDS, le cloud souverain S3NS (Thales x Google) impose des contraintes spécifiques. J'ai configuré Workload Identity pour que les pods accèdent aux ressources GCP sans clé de service, éliminant un vecteur d'attaque courant.
La gestion des secrets : un point critique
J'ai vu trop de projets avec des secrets en clair dans des fichiers de configuration, voire dans des variables d'environnement non chiffrées. Ma stack standard : HashiCorp Vault pour le stockage, External Secrets Operator pour la synchronisation vers Kubernetes, et une rotation automatique des secrets.
Chez Bloomflow, la certification ISO 27001 imposait une gestion rigoureuse des secrets. Vault couplé à ArgoCD permet d'avoir des secrets qui ne transitent jamais en clair dans Git. Sur l'infra Défense, j'utilise OKMS (OVH Key Management Service) pour le chiffrement au repos.
Sécurisez votre pipeline CI/CD
Le pipeline CI/CD est un vecteur d'attaque souvent négligé. Sur GitHub Actions, j'intègre systématiquement : un scan de vulnérabilités des images Docker (Trivy), une analyse des dépendances (Dependabot/Renovate), et un scan des secrets accidentellement commités. Un secret qui fuite dans Git, c'est un secret compromis -- même si on le supprime ensuite.
Le monitoring sécurité en production
Chez un éditeur de logiciels sur AWS, j'ai activé GuardDuty et WAF dans le cadre d'une architecture multi-comptes. GuardDuty a détecté des tentatives de brute-force sur des instances EC2 en moins de 24h après son activation. Sans cet outil, ces tentatives seraient passées inaperçues.
Sur Kubernetes, j'utilise Falco pour la détection d'anomalies runtime : exécution de shells dans des conteneurs, accès à des fichiers sensibles, escalade de privilèges. C'est une couche de défense indispensable.
Conclusion
La sécurité DevOps repose sur trois piliers : durcir dès le départ (pas en retrofit), automatiser les contrôles dans le pipeline CI/CD, et monitorer en continu la production. C'est un investissement qui paraît lourd au début, mais qui évite des incidents dont le coût est incomparablement plus élevé.