Operazioni e Gestione delle → Controllo delle configurazioni

Controllo delle configurazioni

1) Obiettivo e valore

Il controllo delle configurazioni garantisce la responsabilità e la ripetibilità dei cambiamenti: chi, quando e cosa ha cambiato; che è giustificato; come verificato; Come ripiegare. Questo riduce il rischio di incidenti, fughe di segreti, incongruenze con la compliance e modifiche «nascoste» in vendita.

• Un'unica fonte di verità per i confighi.
• Traccia completo delle modifiche (end-to-end).
• Rilasci prevedibili e rimborso rapido.
• Conformità ai requisiti di regolamentazione e di sicurezza.

2) Ambito di copertura

Infrastruttura: Terraform/Helm/Ansible/K8s manifesti di rete ACL/WAF/CDN.
Configi applicativi: file «yaml/json/properties», flag fich, limiti/quote.
Segreti e chiavi: vault/kms, certificati, token, password.
Pipline dati: schemi, trasformazioni, pianificazioni ETL/striam.
Integrazioni: PSP/KYC/provider, webhoop, retry/timeout criteri.
Osservabilità: regole degli alert, dashboard, SLO/SLA.

3) Principi

Config as Data: manufatti dichiarativi, versionabili, testati.
Immutabilità e idimpotenza: riproduzione dell'ambiente dal codice.
Schemi e contratti: validazione rigorosa (JSON-Schema/Protobuf), compatibilità back/forward.
Riduzione delle modifiche manuali: modifiche solo tramite MR/PR.
Separazione dei compiti (SoD) e 4-eyes: autore! = deploeur; La gelosia obbligatoria.
Assegnazioni e firme: firme di commit/release, attrazioni di artefatti.

4) Architettura di verifica

1. SCM (Git) come SoT: tutti i confighi nel repository, il ramo «main» è protetto.

• Config Registry (catalogo di configurazioni, proprietà, SLA, ambiente),
• Schema Registry,
• Policy Engine (OPA/Conftest) è una serie di controlli.
• 3. CI/CD-gate - Formato/schema, controllo statico policy checks, -scan-dry-run-piano di modifica.
• 4. Delivery: GitOps (ad esempio, ArgoCD/Flux) con rilevatore draft e verifiche di applicazione.
• 5. Evidence Store: archivio dei manufatti di verifica (piano, login, firme, bild, SBOM).
• 6. Cronologia attività: Loga invariabile (append-only) eventi «CREATE/APPROVE/APPLY/ROLLBACK/ACCESS».

5) Modello di dati di verifica (minimo)

Сущности: `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`

Connessioni: RFC/Ticket PR con deposito (sha), rilascio-registrazione, monitoraggio SLO.

6) Processo di modifica (passante)

1. RFC/ticket obiettivo, rischio, backout.
2. PR/MR → linting, convalida schematica, controlli policy, segreto-scan.
3. Piano/prevale dry-run/piano, risorse diff, stima del costo/impatto.
4. Approve (4-eyes/SoD, etichetta AB ad alto rischio).
5. Deploy (finestra/calendario) applica il → GitOps; draft-alerting attivato.
6. Verifica → smoke/SLO-Gardreil, conferma del risultato.
7. Archiviazione delle prove di evidence store; aggiornamento del dizionario configure.

7) Regole e regole (esempi)

SoD, l'autore del PR non è un mostro.
Limite di tempo - Il prod-deposito fuori da freeze non è consentito.
Scope - La modifica delle chiavi sensibili richiede 2x apruver da Security/Compliance.
Segreti: vietato conservare in repo; solo riferimenti al percorso vault + ruolo di accesso.
Reti: ingress con '0. 0. 0. 0/0 'vietato senza esclusione temporanea e TTL.
Alert: è vietato ridurre le criticità P1 senza CAV.

8) Controllo dei segreti

Storage in Vault/KMS, TTL brevi, rotazione automatica.
Secret scanning in CI (pattern chiavi, high-entropy).
Isolamento dei segreti per ambienti/ruoli; privilegi minimamente necessari.
Crittografia sul cavo e in pace; Controlli riservati per l'accesso ai segreti.

9) Strumenti (variabile)

Lint/Schema: `yamllint`, `jsonschema`, `ajv`, `cue`.
Policy: OPA/Conftest, Checkov/tfsec/kube-policies.
GitOps: ArgoCD/Flux (drift detection, audit, RBAC).
Secret: HashiCorp Vault, cloud KMS, cert manager.
Scanner: trufflehog, gitleaks (segreti); OPA/Regula (regole).
Report: esport dei registri DWH/BI, collegamento con il sistema di incidenti e change.

10) Esempi di regole e manufatti

JSON-Schema per la configurazione dei limiti

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) - Disabilita '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 (l'autore non è un mostro)

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) - Chi ha ridotto le criticità degli alert in un mese

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;

Git commit messaging (campi obbligatori)

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) Monitoraggio e alerting

Oggetto Draft - Config nel cluster ≠ Git → P1/P2 + Remediazione automatica (recordcile).
High-risk change - Modifica reti/segreti/regole - notifica in # security-ops.
Missing evidence: deposito senza piano/firma/report - blocco o alert.
Espired assets: data di validità dei certificati/chiavi → alert pro-attivi.

12) Metriche e KPI

Audit Coverage% è la percentuale di configurazioni sotto schemi/regole/scanner.
Draft MTTR - Tempo medio per eliminare la deriva.
Policy Compliance% - Passaggio di regole su PR.
Secret Leak MTTR - Da fuoriuscita a ritiro/rotazione.
Backout Rate è la percentuale di rimborsi dei cambiamenti config.
Mean Change Size è un diff medio per righe/risorse (meno - meglio).

13) Reporting e conformità

Tracce di verifica: storage di 1-3 anni (secondo i requisiti), archiviazione invariata.
Regolazione: ISO , SOX-simili, GDPR (PII), requisiti di settore ( : contabilità dei cambiamenti di calcolo GGR/NGR, limiti, bonus-regole).
Report mensili: modifiche top, violazioni di regole, deriva, certificati in scadenza, stato di rotazione.

14) Playbook

A. Trovata deriva in vendita

1. Blocca il deposito auto per il servizio interessato.
2. Rimuovi lo stato corrente.
3. Confronta con Git, avvia «riavcile» o ripristina.
4. Crea un incidente P2, specifica l'origine della deriva (kubectl/console manuale).
5. Attiva protezione: impedisci modifiche dirette (PSP/ABAC), avvisa i proprietari.

B. Certificato PSP scaduto

1. Passa al percorso di riserva/PSP, abbassa timeout/retrai.
2. Rilascia un nuovo certificato attraverso un processo PKI, aggiorna il config tramite Git.
3. Test smoke, ripristinare il traffico, chiudere l'incidente, fare il post mortem.

C. Il segreto è finito in PR

1. Ritira la chiave/token, attiva la rotazione.
2. Riscrivi cronologia/rimuovi artefatto dalla cache, elenca RCA.
3. Aggiungere una regola allo scanner segreto, istruire il comando.

15) Anti-pattern

Modifiche manuali «in vendita» senza traccia né ritocco.
Confighi senza schemi e senza validazioni.
I segreti sono nelle variabili Git/CI senza KMS/Vault.
Un monorepo con l'equivalente del «super diritto globale».
«Sordo» senza drive-alert o registri di applicazioni.
L'enorme «tutto e tutto» è un'attribuzione impreziosita e ad alto rischio.

16) Assegno fogli

Prima di merge

• Schema e lenti completati
• Regole OPA/Conftest «verdi»
• Segreto-scan - «libero»
• Piano/diff applicato, rischio valutato, backout pronto
• 2 apruv (prod) e SoD rispettato

Prima di deploy

• La finestra di rilascio e il calendario sono stati convalidati
• Il monitoraggio Draft è attivo
• I guardrail SLO sono configurati, i test smoke sono pronti

Mensilmente

• Rotazione di chiavi/certificati secondo gli orari
• Inventario dei proprietari e dei diritti
• Ruota le regole ORA/eccezioni (TTL)
• Test playbook (fire-drill)

17) Consigli di progettazione

Ridimensionare le modifiche in piccole diffide; Un PR è un obiettivo.
Modelli di PR/Commit obbligatori con RFC/Rischio/Reimpostazione.
Per configurazioni dinamiche, utilizzare i centri di configurazione con audio e rollback.
Versionare gli schemi; vietare il breaking senza migrazioni.
Rendi visibile la «scheda di configurazione»: cosa, dove, chi controlla.

18) Integrazione con la gestione dei cambiamenti e degli incidenti

PR RFC ha un calendario di comunicati, incidenti/post mortem.
Collegamento automatico delle metriche (SLO/Business) alle release di configure.
Creazione automatica delle operazioni di rimozione dei vecchi flag/eccezioni (TTL).

19) Totale

Il controllo delle configurazioni non è un report cartaceo, ma un meccanismo operativo di affidabilità: i dati confighi, le modifiche sono controllate e verificabili, i segreti sono sotto chiave e la storia è trasparente e verificabile. In questo modo si costruisce una piattaforma sostenibile, complessa e prevedibile.