Il caso
In AWS ti dà 50 modi per isolare. Te ne servono 3. ho parlato di due ambienti AWS per un progetto di ricerca: staging e produzione, sviluppo in locale, budget al minimo; account singolo, VPC e load balancer condivisi, un security group per ambiente. Separati per davvero solo i dati e le credenziali: bucket S3 e secret distinti.
Era un progetto senza dati personali e senza requisiti di compliance, il setup è stato scelto proprio per quel contesto, ma la domanda interessante è un'altra: "Se quel progetto fosse entrato nel perimetro di un sistema di gestione della sicurezza delle informazioni, un setup così leggero avrebbe retto?"
La richiesta
La ISO/IEC 27001:2022 elenca nell'Annex A il controllo 8.31 (separazione degli ambienti di sviluppo, test e produzione): gli ambienti vanno separati e protetti.
Il controllo non dice come. Non chiede account diversi, né reti diverse. Il livello di separazione dipende dalla valutazione del rischio: la clausola 6.1.3 chiede di scegliere i controlli necessari, confrontarli con l'Annex A e motivare le scelte nella dichiarazione di applicabilità.
In pratica: la separazione deve essere proporzionata al rischio, e la proporzione deve essere scritta.
Il perché è l'evidenza
Il setup separa dove il rischio è reale (i dati e le credenziali) e condivide dove non lo è (account, rete, load balancer, registry): per un auditor la domanda non sarebbe "perché non avete due account?", ma "dove avete deciso che uno basta, e in base a che cosa?".
In questo caso la risposta esiste già, ed è un vantaggio raro: un ADR con contesto, opzioni valutate e decisioni, un elenco esplicito delle condizioni in cui il setup smette di funzionare (più team, dati personali su scala, requisiti di compliance, produzione critica), sono esattamente i cambiamenti significativi che, secondo la clausola 8.2, devono far ripetere la valutazione del rischio.
Separare i componenti non basta se gli accessi attraversano i confini tra gli ambienti. Con un account solo, chi può modificare lo staging può, in linea di principio, modificare anche la produzione. Può capitare, ma la scelta deve essere documentata come rischio valutato e accettato.
È lo stesso schema che ritrovo dai clienti, ma al contrario: ambienti separati "perché si fa così", con tre account e nessuno che sappia dire quale rischio stiano riducendo.
Dichiarato vs dimostrato
| Cosa si dichiara | Cosa si dimostra |
|---|---|
| "Staging e produzione sono separati" | Quali componenti sono separati e quali condivisi, con il motivo per ciascuno |
| "I dati di test non toccano la produzione" | Bucket e secret distinti per ambiente, e i permessi che impediscono di incrociarli |
| "Il setup è adeguato al rischio" | La valutazione del rischio che lo giustifica, con la data in cui è stata fatta |
| "Rivedremo la scelta se il progetto cambia" | Le condizioni che fanno scattare la revisione, scritte prima che si verifichino |
| "Solo il team può toccare la produzione" | Chi ha accesso in scrittura a ciascun ambiente, verificato di recente |
A sinistra c'è quello che si scrive nelle policy, a destra c'è quello che un auditor ti chiede di mostrargli.
Da dove partirei
- Una tabella condiviso o separato. Per ogni componente: è condiviso tra gli ambienti o separato? Perché? Se la risposta è "si è sempre fatto così", abbiamo il primo vero problema da sistemare.
- Le condizioni di revisione, scritte. Più team, dati personali, requisiti contrattuali, produzione critica; quando una di queste voci cambia, la scelta si rivaluta.
- Gli accessi alla produzione, almeno quelli. Anche in un account solo, chi può scrivere in produzione deve essere una lista breve e conosciuta.
Per correggere questa lacuna non devi partire da AWS Organizations e Control Tower. Parti da una separazione che sai spiegare, e dal momento in cui smetterà di bastare, scritto prima che arrivi.
Il caso reale da cui nasce, raccontato come appunto di lavoro: il problema, come l'ho affrontato, cosa ho imparato.
AWS ti dà 50 modi per isolare. Te ne servono 3.→Questo caso l'ho documentato in modo più strutturato come Architecture Decision Record, con contesto reale, trade-off valutati e risultati osservati.
ADR260331: Isolamento ambienti tramite condivisione infrastrutturale e separazione dati→
In sintesi (TL;DR)
- Il controllo A.8.31 della ISO 27001 chiede che gli ambienti di sviluppo, test e produzione siano separati e protetti, ma non dice quanto.
- Il livello di separazione dipende dalla valutazione del rischio: anche un setup leggero può essere adeguato, se la scelta è motivata per iscritto.
- Separare i componenti non basta se gli accessi attraversano i confini tra gli ambienti: chi può modificare lo staging può toccare anche la produzione?
- Per partire: cosa è condiviso, cosa separato, il motivo per cui, le condizioni che fanno rivedere la scelta, e una lista breve di chi scrive in produzione.