Il guasto non è un’eccezione, ma uno scenario da progettare
La sicurezza informatica non può essere valutata soltanto quando tutto funziona correttamente. Hardware, software, reti e servizi prima o poi possono interrompersi, restituire errori o comportarsi in modo imprevisto.
Il principio del fail secure parte proprio da questa consapevolezza: un sistema ben progettato deve mantenere le proprie proprietà di protezione anche in condizioni anomale, evitando che un guasto si trasformi in una porta aperta per accessi non autorizzati, perdita di dati o escalation di privilegi. In pratica, l’errore deve condurre il sistema verso uno stato prevedibile e controllato.
Questo significa definire in fase di progettazione cosa accade quando un componente non risponde, un servizio di autenticazione è indisponibile o una regola di controllo non può essere verificata. La logica è coerente con concetti come secure by design, least privilege e gestione strutturata delle eccezioni: non si deve improvvisare la risposta al problema quando il problema si presenta, ma stabilirla prima, sulla base del rischio.
Fail secure non significa semplicemente “bloccare tutto”
L’approccio più noto è il fail closed: se il sistema non riesce a verificare che un’operazione sia legittima, la nega. È una scelta tipica per firewall, sistemi di autenticazione e controlli di accesso, perché privilegia la confidenzialità e impedisce che un malfunzionamento abbassi automaticamente il livello di protezione.
Tuttavia, non esiste una regola valida in ogni contesto. In alcuni servizi la disponibilità è essenziale e un blocco totale può generare conseguenze più gravi del rischio che si vuole evitare. Nei sistemi fisici e negli ambienti safety-critical, per esempio, può essere necessario adottare logiche fail safe o fail open per proteggere le persone o garantire funzioni indispensabili.
Il punto quindi non è scegliere sempre la configurazione più restrittiva, ma determinare quale stato residuo sia realmente sicuro rispetto agli asset, agli utenti e al processo interessato. La decisione deve derivare da una valutazione del rischio che consideri impatti sulla sicurezza, sulla continuità del servizio e sulla safety, evitando automatismi che potrebbero spostare il rischio invece di ridurlo.
Dalla progettazione tecnica alla resilienza operativa
Applicare il fail secure richiede misure tecniche e organizzative integrate. Occorre definire comportamenti di default sicuri, gestire correttamente gli errori applicativi, impedire che eccezioni o timeout consentano bypass dei controlli e assicurare che i sistemi di logging registrino gli eventi utili a ricostruire l’anomalia.
Anche ridondanza, segregazione dei componenti critici, backup e procedure di ripristino contribuiscono a evitare che un singolo guasto produca effetti a cascata. Ma la vera efficacia si verifica attraverso test: simulare la perdita di un servizio, l’indisponibilità di un componente o l’interruzione di una connessione permette di osservare se il sistema mantiene davvero le condizioni previste.
In questa prospettiva, il fail secure diventa parte della resilienza e della continuità operativa. Un’organizzazione matura non considera il guasto soltanto come un evento tecnico da correggere, ma come uno scenario da governare.
La qualità della sicurezza emerge quindi non dalla promessa che il sistema non fallirà mai, ma dalla capacità di fallire in modo controllato, limitando l’impatto e rendendo il recupero rapido, verificabile e coerente con gli obiettivi di business.