Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Configuration Drift Security

devsecops

Définition

La Configuration Drift Security (sécurité par rapport à la dérive de configuration) traite spécifiquement les implications de sécurité du Configuration Drift — la dégradation progressive de l'état de sécurité d'un système à mesure que sa configuration diverge des standards et politiques de sécurité établis. Dans les environnements gérés manuellement ou sans contrôle strict IaC/GitOps, la dérive de configuration est inévitable et peut conduire à l'affaiblissement progressif de la posture de sécurité. La dérive de configuration de sécurité se manifeste de nombreuses façons. Des règles de firewall "temporairement" ouvertes lors d'un dépannage et jamais fermées. Des configurations TLS affaiblies (TLS 1.0 réactivé pour un client legacy, jamais désactivé ensuite). Des permissions IAM élargies en urgence et jamais réduites. Des paramètres de logging de sécurité modifiés pour des tests de performance et jamais restaurés. Des patches de sécurité non appliqués sur des systèmes "stables". Chacune de ces dérives, prise individuellement, peut sembler mineure, mais leur accumulation crée progressivement des brèches de sécurité significatives. La gestion de la Configuration Drift Security nécessite une combinaison d'approches préventives et détectives. Côté prévention : l'Infrastructure as Code (IaC) avec GitOps empêche les modifications manuelles en dehors du flux Git, le Immutable Infrastructure (remplacement plutôt que modification) élimine structurellement la dérive, et les pipelines CI/CD appliquant la configuration de sécurité à chaque déploiement assurent la convergence vers l'état désiré. Côté détection : les CSPM (Cloud Security Posture Management) comme Wiz, Prisma Cloud, ou AWS Security Hub scannent continuellement la configuration des ressources cloud et alertent sur les dérives par rapport aux benchmarks CIS, les scans de conformité réguliers (CIS Benchmarks, DISA STIG), et les outils de drift detection IaC (Terraform Drift Detection, Driftctl) mesurent et alertent sur les écarts. La gouvernance de la Configuration Drift Security inclut la définition d'une "baseline de sécurité" (configuration minimale de sécurité acceptable pour chaque type de ressource), l'audit régulier des dérives par rapport à cette baseline, et un processus d'exception documenté pour les dérogations légitimes.

Sources et accumulation de la dérive de configuration

La dérive de configuration de sécurité s'accumule via : les modifications d'urgence non documentées ("on corrigera plus tard"), l'auto-scaling cloud qui peut modifier des paramètres de sécurité lors du provisionnement d'instances, les mises à jour de composants automatiques modifiant des configurations de sécurité par défaut, et les interventions humaines lors d'incidents. Sans mécanisme de détection, ces dérives s'accumulent silencieusement jusqu'à constituer une exposition significative.

CSPM pour la détection de dérive en temps réel

Les Cloud Security Posture Management (CSPM) surveillent continuellement la configuration des ressources cloud et alertent sur les dérives de sécurité : buckets S3 devenus publics, règles de Security Group trop permissives, chiffrement désactivé, MFA désactivé pour un utilisateur IAM. AWS Security Hub (agrégateur natif), Wiz, Prisma Cloud, et Lacework proposent des intégrations avec les principaux clouds et des benchmarks CIS/NIST préconfigurés pour la détection automatique de dérive de configuration.

Remédiation automatique vs manuelle

La remédiation des dérives de configuration peut être automatique (AWS Config Remediation Actions, GCP Security Command Center Automations) ou manuelle selon la criticité. Les dérives critiques (bucket S3 public, Security Group 0.0.0.0/0) méritent une remédiation automatique immédiate avec notification post-action. Les dérives moyennes (absence d'un tag de sécurité, version de TLS suboptimale) peuvent être remontées dans un backlog de sécurité avec SLA de remédiation de 7 à 30 jours selon la sévérité. La documentation de chaque remédiation automatique dans un log d'audit est essentielle pour la conformité.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis