Il caso
In Se non è descritto non esiste ho raccontato un'azienda con tre ambienti (sviluppo, staging, produzione) che avrebbero dovuto essere identici ma non lo sono mai stati: due anni di modifiche manuali, ognuna fatta al volo per un'urgenza.
Quando il sistemista di riferimento ha cambiato lavoro, la prima domanda è stata: "Ma tu come facevi a fare il deploy?" Da un altro cliente ho trovato lo stesso problema: sei servizi configurati a colpi di click su Portainer, senza alcuna traccia di chi avesse cambiato cosa.
La domanda: "Se quelle infrastrutture fossero state dentro il perimetro di un sistema di gestione della sicurezza delle informazioni, cosa avrebbe trovato un auditor?"
La richiesta
La ISO/IEC 27001:2022 elenca nell'Annex A il controllo 8.9 (gestione della configurazione): le configurazioni di hardware, software, servizi e reti, comprese quelle di sicurezza, vanno stabilite, documentate, implementate, monitorate e riesaminate.
Come tutti i controlli dell'Annex A, si applica se la valutazione del rischio lo rende necessario. Per chi gestisce un'infrastruttura, è difficile motivarne l'esclusione.
In pratica: devi sapere com'è configurato ogni sistema, averlo scritto, e accorgerti quando la realtà si allontana da quello che hai scritto.
Senza un riferimento non controlli niente
Nel caso dei tre ambienti mancava una configurazione di riferimento. Nessuno aveva stabilito come dovessero essere, quindi non esisteva né una descrizione condivisa né una documentazione di confronto per capire se fossero ancora coerenti.
Se quegli ambienti fossero rientrati nel perimetro del sistema di gestione, sarebbe stato difficile dimostrare l'effettiva applicazione del controllo 8.9. Senza una configurazione di riferimento, non si può verificare se i sistemi siano conformi né documentare l'esito delle verifiche.
Terraform rende concreta la configurazione di riferimento: il codice la definisce, il repository ne conserva la documentazione e terraform apply la applica all'infrastruttura. Non basta, però, a garantire che codice e realtà restino allineati. Se qualcuno modifica a mano una risorsa dalla console, il codice continua a dire una cosa e l'infrastruttura un'altra, finché qualcuno non lancia terraform plan e guarda le differenze.
Monitorare una configurazione significa cercare la deriva di proposito, non scoprirla per caso.
È lo stesso problema che ritrovo dai clienti: regole del firewall aggiunte "temporaneamente" due anni fa nonostante la documentazione iniziale resti invariata, variabili d'ambiente impostate a mano sul server di produzione, un bucket reso pubblico per un test e mai richiuso.
Dichiarato vs dimostrato
| Cosa si dichiara | Cosa si dimostra |
|---|---|
| "L'infrastruttura è documentata" | Il repository con la configurazione, coerente con l'ambiente reale alla data dell'ultima verifica |
| "Gli ambienti sono identici" | L'esito di un confronto tra codice e realtà su ogni ambiente, con data |
| "Le modifiche passano da una review" | Le pull request approvate per le ultime modifiche infrastrutturali |
| "Le regole di rete sono sotto controllo" | Le regole dei security group nel codice, con chi le ha approvate e quando |
| "Nessuno modifica a mano la produzione" | Il controllo periodico delle differenze tra codice e realtà, con gli esiti annotati |
A sinistra c'è quello che si scrive nelle policy, a destra c'è quello che un auditor ti chiede di mostrargli.
Da dove partirei
- Descrivi prima quello che si rompe più spesso. Quel server che ogni tre mesi qualcuno configura a mano, quel bilanciatore con regole che nessuno ricorda, il resto arriva per pezzi.
- Un controllo di deriva programmato.
terraform planin CI a cadenza fissa: se trova differenze, qualcuno viene avvisato e annota le decisioni. - Le configurazioni di sicurezza per prime. Security group, policy IAM, accessi pubblici ai bucket: sono quelle in cui una modifica a mano costa di più.
Per correggere questa lacuna non devi descrivere tutta l'infrastruttura in un mese, e non serve per forza Terraform: se un README aggiornato è sufficiente, basta quello. Serve una configurazione di riferimento scritta, e qualcuno che controlli che la realtà le somigli.
Il caso reale da cui nasce, raccontato come appunto di lavoro: il problema, come l'ho affrontato, cosa ho imparato.
Se non è descritto non esiste→
In sintesi (TL;DR)
- Il controllo A.8.9 della ISO 27001 chiede che le configurazioni di hardware, software, servizi e reti, comprese quelle di sicurezza, siano stabilite, documentate, implementate, monitorate e riesaminate.
- Tre ambienti che dovevano essere identici e non lo erano più: senza una configurazione di riferimento, non c'è niente da monitorare né da riesaminare.
- Terraform aiuta a stabilire, documentare e implementare la configurazione. Per monitorarla e riesaminarla, invece, bisogna cercare attivamente le differenze tra codice e infrastruttura.
- Per partire: descrivere prima quello che rompi più spesso, un controllo di deriva programmato e le configurazioni di sicurezza per prime.