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.

GitOps Audit Trail

devsecops

Définition

Un GitOps Audit Trail (piste d'audit GitOps) est un mécanisme de traçabilité des changements d'infrastructure et d'application basé sur l'historique Git des dépôts de configuration. Dans une architecture GitOps (où Git est la source of truth pour l'état désiré de l'infrastructure et des applications), le commit history Git naturellement constitue un audit trail complet et immuable de qui a fait quel changement, quand, et pourquoi — une propriété précieuse pour la conformité, la forensique et la gouvernance de sécurité. Dans un flux GitOps typique (avec ArgoCD, Flux, ou Crossplane), tout changement d'infrastructure ou d'application passe obligatoirement par une Pull Request Git : modification d'un manifeste Kubernetes, mise à jour d'une configuration Terraform, changement d'une règle de sécurité. Chaque PR capture automatiquement : l'auteur du changement (identité Git vérifiée), la date et l'heure, le diff précis des modifications, les reviewers et approbateurs (avec leur identité), et le lien vers le pipeline CI qui a validé le changement. Cette traçabilité est intrinsèque à GitOps, pas une couche ajoutée séparément. L'immuabilité du journal Git est un atout pour la conformité : les commits Git (avec une configuration appropriée de protection des branches et de signatures) ne peuvent pas être modifiés sans laisser de trace. Des configurations comme le "require signed commits" (GPG ou SSH) ajoutent une vérification cryptographique de l'identité de l'auteur, rendant le journal d'audit non-répudiable. La protection des branches bloque la réécriture de l'historique sur les branches principales. Pour les exigences de conformité (SOC 2, ISO 27001 A.12.4 Logging and monitoring, PCI-DSS 10.2), le GitOps Audit Trail fournit naturellement les preuves d'audit requises : qui a approuvé quel changement de configuration, quand, et pour quelle raison (commit message). Des intégrations avec des outils d'audit management (Drata, Vanta) exploitent l'API GitHub/GitLab pour extraire automatiquement ces preuves. La complémentarité GitOps Audit Trail / SIEM est importante : le GitOps trace les changements intentionnels (opérations légitimes), le SIEM détecte les comportements anormaux en runtime (opérations potentiellement malveillantes). Ensemble, ils couvrent toute la traçabilité nécessaire pour la détection et la forensique d'incidents.

Immuabilité et intégrité de l'historique Git

L'historique Git est conçu pour être immuable : un commit modifié change son SHA-256, rendant la manipulation détectable par quiconque a une copie du dépôt. La configuration "require signed commits" ajoute une signature cryptographique GPG/SSH à chaque commit, prouvant l'identité de l'auteur (au-delà du simple nom d'utilisateur). Les Branch Protection Rules (no force push, no deletion) empêchent la réécriture de l'historique sur les branches protégées, garantissant l'intégrité de l'audit trail.

GitOps Audit Trail pour la conformité

Le GitOps Audit Trail répond aux exigences de traçabilité de nombreux frameworks : ISO 27001 A.12.4.1 (event logging), SOC 2 CC7 (system monitoring — qui a fait quoi dans l'infrastructure), PCI-DSS 10.3 (protect audit logs). Les preuves d'audit sont exportables depuis GitHub/GitLab via API : PR history avec reviewers, merge timestamps, commits signés. Des outils de compliance automation (Drata, Vanta, Sprinto) extraient automatiquement ces preuves et les lient aux contrôles de conformité correspondants.

Corrélation GitOps / SIEM pour la forensique

En cas d'incident, la corrélation entre le GitOps Audit Trail et les logs SIEM/runtime permet de distinguer les changements intentionnels des changements malveillants : un nouveau NetworkPolicy Kubernetes apparu sans PR correspondante dans le dépôt Git est un signal fort de compromission (quelqu'un a directement modifié le cluster sans passer par GitOps). Les alertes de "drift detection" (ArgoCD OutOfSync) signalent automatiquement ces modifications non-GitOps qui méritent investigation immédiate.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis