Opérations et gestion → Audit des configurations

Audit des configurations

1) But et valeur

L'audit des configurations garantit une responsabilisation prouvée et la répétabilité des changements : qui, quand et ce qui a changé ; ce qui est justifié ; comment vérifié ; Comment faire tomber. Cela réduit le risque d'incidents, de fuites de secrets, de non-conformité à la conformité et de modifications « cachées » dans la vente.

• Source unique de vérité (SoT) pour les configs.
• Suivi complet des changements (end-to-end).
• Sorties prévisibles et retour rapide.
• Conformité aux exigences réglementaires et aux politiques de sécurité.

2) Portée

Infrastructure : manifestes Terraform/Helm/Ansible/K8s, réseau ACL/WAF/CDN.
Configurations applicatives : fichiers 'yaml/json/properties', drapeaux ficha, limites/quotas.
Secrets et clés : vault/kms, certificats, jetons, mots de passe.
Piplines de données : schémas, transformations, horaires ETL/strim.
Intégrations : PSP/KYC/fournisseurs, webhooks, retry/timeout politiques.
Observabilité : règles des alerts, dashboards, SLO/SLA.

3) Principes

Bou as Data : artefacts déclaratifs, versionnables, testables.
Immutabilité et idempotence : reproductibilité de l'environnement à partir du code.
Schémas et contrats : validation rigoureuse (JSON-Schema/Protobuf), back/forward-interopérabilité.
Minimisation des modifications manuelles : modifications uniquement via MR/PR.
Séparation des tâches (SoD) et 4-yeux : auteur ! = déploeur ; Revue obligatoire.
Attribution et signatures : signatures de commits/communiqués, attestations d'artefacts.

4) Architecture d'audit

1. SCM (Git) comme SoT : tous les configs du référentiel, la branche 'main' est protégée.

• Bou Registry (répertoire configues, possessions, SLA, environnements),
• Schema Registry (versions des schémas configus/events),
• Moteur de politique (OPA/Conftest) : ensemble de contrôles.
• 3. Gates CI/CD : format/schéma → vérification statique → tests de politique → scan secret → dry-run → plan de changement.
• 4. Livraison : GitOps (par exemple ArgoCD/Flux) avec détecteur drift et logs d'audit d'applications.
• 5. Evidence Store : entrepôt d'artefacts d'audit (plan, logs, signatures, bilds, SBOM).
• 6. Journal des activités : Journal invariable des événements 'CREATE/APPROVE/APPLY/ROLLBACK/ACCESS'.

5) Modèle de données d'audit (minimum)

Сущности: `ConfigItem(id, env, service, owner, schema_version, sensitivity)`

События: `change_id, actor, action, ts, diff_hash, reason, approvals[]`

Артефакты: `plan_url, test_report_url, policy_report, signature, release_tag`

Communications : RFC/ticket ↔ PR ↔ deploy (sha) ↔ sortie-enregistrement ↔ surveillance SLO.

6) Processus de changement (de bout en bout)

1. RFC/ticket → but, risque, backout.
2. PR/MR → linting, validation schématique, policy-check, secret-scan.
3. Plan/preview → dry-run/plan, diff des ressources, estimation des coûts/impact.
4. Approve (4-eyes/SoD, l'étiquette de l'ACR à haut risque).
5. Deploy (par fenêtre/calendrier) → GitOps applique ; le drift-alerting est inclus.
6. Vérification → smoke/SLO-gardreilles, confirmation du résultat.
7. Archivage des preuves → evidence store ; mise à jour du dictionnaire des configues.

7) Politiques et règlements (exemples)

SoD : l'auteur du PR n'est pas dans la merde.
Limite de temps : prod-deploy en dehors de « freeze » est interdit.
Scope : changer les clés sensibles nécessite 2x aprovers de Security/Compliance.
Secrets : Il est interdit de garder dans un repeau ; uniquement les liens vers le chemin d'accès vault + rôle d'accès.
Réseaux : ingress avec '0. 0. 0. 0/0 'interdit sans exception temporaire et TTL.
Alert : Il est interdit de réduire la criticité de la P1 sans le BOU.

8) Le contrôle des secrets

Stockage en Vault/KMS, TTL courts, rotation automatique.
Scanning secret dans CI (modèles de clés, haute entropie).
Isolation des secrets par environnement/rôle ; le minimum de privilèges nécessaires.
Chiffrement « sur fil » et « au repos » ; les logs d'accès aux secrets fermés.

9) Instruments (variatifs)

Lint/Schema: `yamllint`, `jsonschema`, `ajv`, `cue`.
Policy: OPA/Conftest, Checkov/tfsec/kube-policies.
GitOps: ArgoCD/Flux (drift detection, audit, RBAC).
Secrets : HashiCorp Vault, cloud KMS, cert manager.
Scanners : trufflehog, gitleaks (secrets) ; OPA/Regula (règles).
Reporting : export des journaux vers DWH/BI, association avec le système incident et changement.

10) Exemples de règles et d'artefacts

JSON-Schema pour la configuration des limites

json
{
"$schema": "http://json-schema. org/draft-07/schema#",
"title": "limits",
"type": "object",
"required": ["service", "region", "rate_limit_qps"],
"properties": {
"service": {"type":"string", "pattern":"^[a-z0-9-]+$"},
"region": {"type":"string", "enum":["eu","us","latam","apac"]},
"rate_limit_qps": {"type":"integer","minimum":1,"maximum":5000},
"timeouts_ms": {"type":"integer","minimum":50,"maximum":10000}
},
"additionalProperties": false
}

Conftest/OPA (rego) - interdiction '0. 0. 0. 0/0` в ingress

rego package policy. network

deny[msg] {
input. kind == "IngressRule"
input. cidr == "0. 0. 0. 0/0"
msg:= "Ingress 0. 0. 0. 0/0 is not allowed. Specify specific CIDRs or throw an exception with TTL"
}

Conftest/OPA - SoD (prod n'est pas l'auteur)

rego package policy. sod

deny[msg] {
input. env == "prod"
input. pr. author == input. pr. merger msg: = "SoD: PR author cannot hold in prod."
}

SQL (DWH) - qui a réduit la criticité des alertes en un mois

sql
SELECT actor, COUNT() AS cnt
FROM audit_events
WHERE action = 'ALERT_SEVERITY_CHANGED'
AND old_value = 'P1' AND new_value IN ('P2','P3')
AND ts >= date_trunc('month', now())
GROUP BY 1
ORDER BY cnt DESC;

Exemple Git commit message (champs obligatoires)

feat(config/payments): raise PSP_B timeout to 800ms in EU

RFC: OPS-3421
Risk: Medium (PSP_B only, EU region)
Backout: revert PR + restore timeout=500ms
Tests: schema ok, conftest ok, e2e ok

11) Surveillance et alerte

Drift-detect : config dans le cluster ≠ Git → P1/P2 signal + auto-remediation (reconcile).
Changement de risque élevé : modification des réseaux/secrets/politiques - notification dans # security-ops.
Missing evidence : sans plan/signature/rapports - bloc ou alert.
Expired assets : durée de validité des certificats/clés → alertes pro-actives.

12) Métriques et KPI

Audit Coverage % est la proportion de configues sous schémas/politiques/scanners.
Drift MTTR est le temps moyen d'élimination de la dérive.
Policy Compliance % - passage des politiques sur PR.
Secret Leak MTTR - de la fuite au rappel/rotation.
Backout Rate est la proportion de retraits de changements config.
Mean Change Size est le diff moyen par ligne/ressource (moins - mieux).

13) Rapports et conformité

Les traces de l'audit : la conservation ≥ de 1-3 ans (selon les exigences), le dépôt invariable.
Réglementation : ISO 27001/27701, SOX comme SoD, GDPR (PII), exigences sectorielles (iGaming : prise en compte de la modification des calculs GGR/NGR, limites, règles de bonus).
Rapports mensuels : changements de haut niveau, violations de règles, dérive, certificats expirés, état des rotations.

14) Pleybooks

A. Dérive détectée dans la vente

1. Bloquer la voiture pour le service affecté.
2. Annuler l'état actuel.
3. Comparer avec Git, initier 'reconcile' ou revenir en arrière.
4. Créer un incident P2, spécifier une source de dérive (kubectl/console manuelle).
5. Inclure la protection : interdire les modifications directes (PSP/ABAC), informer les propriétaires.

B. Certificat PSP périmé

1. Basculez sur le chemin de sauvegarde/PSP, abaissez les délais/retraits.
2. Libérer un nouveau certificat via le processus PKI, mettre à jour le config via Git.
3. Smoke-test, récupérer le trafic, fermer l'incident, faire un post-mortem.

C. Le secret est dans les relations publiques

1. Révoquer la clé/le jeton, activer la rotation.
2. Réécrire l'histoire/supprimer l'artefact des caches, formaliser RCA.
3. Ajouter une règle au scanner secret, former la commande.

15) Anti-modèles

Modifications manuelles « sur la vente » sans trace et sans retour en arrière.
Configurations sans schémas et sans validation.
Secrets dans les variables Git/CI sans KMS/Vault.
Monorepo avec l'équivalent d'un « super-droit mondial ».
GitOps « sourd » sans alertes drift et journaux d'applications.
L'énorme PR « tout et tout à la fois » est une attribution floue et un risque élevé.

16) Chèques-feuilles

Avant merge

• Diagramme et linters passés
• OPA/Conftest politiques « verts »
• Secret-scan - « pur »
• Plan/diff joint, risque évalué, backout prêt
• 2 aprouva (prod) et SoD respectés

Avant deploy

• La fenêtre de publication et le calendrier ont été vérifiés
• Drift-monitoring est actif
• Les gardes SLO sont configurés, les tests smoke sont prêts

Mensuelle

• Rotation des clés/certificats selon le graphe
• Inventaire des propriétaires et des droits
• Revoyez les règles de l'OAR/exceptions (TTL)
• Test d'incident de pleybuck (fire-drill)

17) Conseils de conception

Fractionner les changements en petits diffs ; un PR est un objectif.
Modèles de RP/commits obligatoires avec RFC/risque/retour.
Pour les configues dynamiques, utilisez les « centres configues » avec audit et rollback.
Versez les circuits ; interdire le breaking sans migration.
Visualisez la « carte des confits » : quoi, où, qui est contrôlé.

18) Intégration avec la gestion des changements et des incidents

PR ↔ RFC ↔ calendrier de sortie ↔ incidents/post-mortem.
Mappage automatique des métriques (SLO/Business) pour les versions configues.
Auto-création de tâches pour supprimer les anciens drapeaux/exceptions (TTL).

19) Résultat

L'audit des configurations n'est pas un « rapport papier », mais un mécanisme opérationnel de fiabilité : configi - données, changements - contrôlables et vérifiables, secrets - sous serrure, et toute l'histoire - est transparente et vérifiable. C'est ainsi que se construit une plate-forme durable, compacte et prévisible.