Construire un audit reproductible
Une preuve peut être un résultat de scan, une configuration versionnée ou un test d’accès. Elle doit permettre à une autre personne de reproduire la conclusion. Les exceptions restent visibles dans le rapport et sont revues à leur échéance.
Fermer un écart
La fermeture exige une nouvelle mesure et une validation du propriétaire. Conservez la preuve du changement, la date et le résultat. Si l’écart reste nécessaire, documentez la raison, le risque accepté et la date de réexamen.
Relier les résultats aux actions
Un écart doit citer la ressource, la règle, la preuve, le risque et la correction. Après changement, relancez le contrôle et vérifiez un parcours applicatif. Une revue trimestrielle suit âge, gravité et délai de correction.
Vérifier les changements
Reliez les écarts aux déploiements, importations et interventions récentes. Un audit peut alors distinguer une modification attendue d’une dérive. Lorsque la configuration est corrigée, relancez le test et contrôlez l’application avec un parcours simple.
Une revue trimestrielle peut mesurer nombre d’écarts, âge, niveau de risque et délai de correction. Présentez les résultats aux propriétaires de service afin qu’ils puissent arbitrer les exceptions et planifier les travaux.
L’audit doit utiliser le même périmètre et les mêmes règles à chaque exécution. Notez comptes, régions, date, outil et version des contrôles. Une comparaison entre deux audits n’a de sens que si les sources sont compatibles.
Examinez les identités humaines, les comptes de service et les accès temporaires. Vérifiez la lecture des sauvegardes, logs et buckets, car une permission de lecture peut exposer des données sensibles. Une clé ancienne doit avoir un propriétaire et une date de rotation.
Contrôlez réseau, stockage, chiffrement, certificats et journaux. Les règles publiques doivent être reliées à une raison métier. Une exception sans propriétaire est un écart à corriger, même si le service fonctionne.
Le rapport doit montrer ressource, règle, preuve, risque et action. Conservez les résultats sans secrets. Après correction, relancez le contrôle et vérifiez le parcours applicatif. Une équipe peut alors distinguer une correction réelle d’un simple déplacement de configuration.
Un audit de configuration compare les ressources réelles à des règles attendues. Il peut repérer stockage public, ports ouverts, chiffrement absent, droits trop larges et sauvegardes incomplètes avant qu’un incident ne les révèle.
Définir les règles
Commencez par les configurations qui touchent données, accès et disponibilité. Chaque règle doit préciser ressource, valeur attendue, exception possible et responsable. Évitez un catalogue de contrôles que personne ne peut corriger.
Observer avant de bloquer
Lancez les contrôles en lecture seule et classez les écarts. Un blocage automatique peut interrompre une migration ou un service critique. Un écart temporaire doit avoir une date d’expiration et un propriétaire.
Corriger avec preuve
Reliez chaque correction à un changement versionné. Vérifiez les logs, les accès et le fonctionnement après action. L’infrastructure as code permet de conserver la règle et la configuration attendue.
Répéter
Planifiez une revue après déploiement et après un incident. Les contrôles doivent aussi couvrir les comptes secondaires, les régions et les environnements de test. Sources : CIS Benchmarks, AWS Config.
Organiser l’inventaire
L’audit commence par une liste fiable des comptes, régions et types de ressources. Comparez l’inventaire du fournisseur avec celui du pipeline. Une ressource visible dans un compte secondaire peut échapper aux contrôles habituels. Ajoutez propriétaire, environnement, application et date de revue.
Les ressources éphémères doivent avoir une durée de vie attendue. Un environnement de test créé pour une journée ne devrait pas rester sans alerte pendant un mois. Les tags ne sont utiles que si le pipeline les applique et si un rapport montre les valeurs manquantes.
Prioriser les écarts
Commencez par accès publics, clés exposées, sauvegardes absentes, chiffrement manquant et règles réseau trop larges. Examinez ensuite quotas, versions, logs et coûts. Un écart critique doit avoir une action immédiate ; une préférence de configuration peut entrer dans une file de maintenance.
Un contrôle peut produire un faux positif lorsque la règle ignore le rôle du service. Documentez l’exception avec preuve, propriétaire et date d’expiration. Ne désactivez pas toute la règle pour éviter un seul cas particulier.
Automatiser la correction avec prudence
Les corrections simples peuvent être proposées sous forme de changement relu. Une suppression, une modification de réseau ou une révocation de permission demande une validation humaine. Conservez la configuration précédente et testez le service après action.
Comparez les écarts avant et après déploiement. Le plan d’infrastructure doit montrer la modification et le pipeline doit conserver le résultat du contrôle. L’article sur la gestion des changements complète cette procédure.
Présenter les résultats
Un rapport utile indique ressource, règle, preuve, risque, propriétaire et échéance. Regroupez les écarts qui partagent une cause. Une revue mensuelle peut suivre le nombre d’écarts critiques, leur âge et le temps moyen de correction.