Single point of failure

Un single point of failure (SPOF) descrive una vul­ne­ra­bi­li­tà del sistema sotto forma di un singolo com­po­nen­te. Se il com­po­nen­te ha un mal­fun­zio­na­men­to, l’intero sistema si guasta. Quali sono i diversi tipi di SPOF e come si può mi­ni­miz­za­re il rischio che si ve­ri­fi­chi­no?

Un single point of failure (SPOF) descrive un tipo di vul­ne­ra­bi­li­tà all’interno di un sistema. Un SPOF esiste quando il mal­fun­zio­na­men­to di un singolo com­po­nen­te causa il guasto dell’intero sistema. Esistono diverse “modalità di guasto”. Queste possono essere distinte in tre categorie:

1. Tallone d’Achille o “anello più debole della catena”: la perdita di un com­po­nen­te porta a un’im­prov­vi­sa perdita di fun­zio­na­li­tà dell’intero sistema.
2. Reazione a catena o “effetto domino”: il guasto di un com­po­nen­te causa il suc­ces­si­vo mal­fun­zio­na­men­to di altri com­po­nen­ti che porta al guasto dell’intero sistema.
3. Collo di bottiglia: un com­po­nen­te agisce come fattore limitante dell’intero sistema. Se il com­po­nen­te limitante è dan­neg­gia­to, le pre­sta­zio­ni del sistema si riducono alla capacità del com­po­nen­te.

I SPOF sono comuni nei sistemi complessi con com­po­nen­ti in­ter­con­nes­si a più livelli. A seconda della struttura del sistema, il mal­fun­zio­na­men­to di un com­po­nen­te critico causa il guasto dell’intero sistema. Il single point of failure assume la forma di un com­po­nen­te critico.

La com­ples­si­tà di un sistema a più livelli può rendere difficile l’in­di­vi­dua­zio­ne di SPOF. Non esiste un modo semplice per iden­ti­fi­ca­re le in­te­ra­zio­ni dei singoli com­po­nen­ti. I guasti o i problemi sono difficili da in­di­vi­dua­re. In linea di massima, ogni com­po­nen­te non ri­don­dan­te critico per il fun­zio­na­men­to deve essere trattato come un single point of failure.

Prendiamo ad esempio il corpo umano. Abbiamo un solo cuore e un solo cervello: gli organi critici non sono pro­get­ta­ti in modo ri­don­dan­te. Se uno di questi organi funziona male, l’intero corpo si guasta. I SPOF fun­zio­na­no come cuore e cervello. Al contrario, occhi, orecchie, polmoni e reni sono duplicati. Se ne­ces­sa­rio, il corpo compensa il guasto di uno di essi e continua a fun­zio­na­re con un’ef­fi­cien­za ridotta.

In un data center, tutti i com­po­nen­ti critici per il fun­zio­na­men­to sono po­ten­zia­li SPOF. Pertanto, i server sono so­li­ta­men­te dotati di con­nes­sio­ni ri­don­dan­ti alla rete elettrica e alla rete. La memoria di massa è fornita in modo ri­don­dan­te tramite RAID o tec­no­lo­gie simili. L’obiettivo è garantire che il sistema continui a fun­zio­na­re in caso di guasto di un singolo com­po­nen­te critico.

Esistono diversi tipi di single point of failure (SPOF). Dopotutto, i SPOF non ri­guar­da­no solo i sistemi in­for­ma­ti­ci. Vediamo alcuni esempi.

Nei famosi film di “Guerre stellari”, un single point of failure porta alla di­stru­zio­ne della temuta “Morte Nera”. Un singolo siluro protonico sparato dal pro­ta­go­ni­sta colpisce un punto critico del reattore. L’esplo­sio­ne provoca una ca­ta­stro­fi­ca reazione a catena che distrugge l’intera Morte Nera.

Nel 2021, la nave container “Ever Given” è rimasta bloccata nel Canale di Suez. La nave si è in­ca­glia­ta in una sezione critica del canale che funge da unica via d’acqua. Il blocco ha pa­ra­liz­za­to il traffico marittimo lungo l’intero canale. In questo caso il single point of failure è stata la via d’acqua non ri­don­dan­te.

Nel 2018 e nel 2019 si sono ve­ri­fi­ca­ti due incidenti di aerei “Boeing 737 MAX” che hanno portato alla perdita di centinaia di vite. La causa degli incidenti è stato un singolo sensore che ha fornito dei dati errati. Sulla base dei dati del sensore, il sistema di controllo au­to­ma­ti­co del volo non ha fun­zio­na­to cor­ret­ta­men­te causando la pre­ci­pi­ta­zio­ne degli aerei. Sebbene in questo caso siano stati commessi diversi errori, il single point of failure è stato il sensore.

Anche i sistemi pro­get­ta­ti per l’alta di­spo­ni­bi­li­tà non sono com­ple­ta­men­te protetti dai SPOF. Negli ultimi anni, i prin­ci­pa­li servizi cloud hanno subito ri­pe­tu­ta­men­te gravi guasti. Nella maggior parte dei casi, il single point of failure è stato umano. I dati di con­fi­gu­ra­zio­ne sbagliati possono pa­ra­liz­za­re ra­pi­da­men­te un intero sistema di pro­du­zio­ne, anche se i suoi com­po­nen­ti sono pro­get­ta­ti in modo ri­don­dan­te.

Im­ma­gi­na­te il seguente esempio: il vostro di­spo­si­ti­vo è connesso al WiFi ma il browser web non funziona. L’orologio inizia quindi a regolare au­to­ma­ti­ca­men­te l’ora. Questo piccolo problema è ab­ba­stan­za da farvi strappare i capelli ma la soluzione è semplice:

La famosa frase “È sempre il DNS” sembra di­ver­ten­te, ma è una de­scri­zio­ne seria del po­ten­zia­le di errore del Domain Name System (DNS). Dopo tutto, quando i server DNS non ri­spon­do­no, i siti web e i servizi possono non fun­zio­na­re in vari modi. L’effetto è simile all’in­ter­ru­zio­ne della con­nes­sio­ne a Internet. Tuttavia, in questo caso il traffico di pacchetti tra indirizzi IP continua a fun­zio­na­re.

Gli errori DNS si ve­ri­fi­ca­no so­li­ta­men­te sul lato utente se i server DNS me­mo­riz­za­ti nel sistema non sono ac­ces­si­bi­li. È quindi buona norma me­mo­riz­za­re due indirizzi di name server. Se il primo server non è di­spo­ni­bi­le, viene uti­liz­za­to il secondo. In questo modo si crea ri­don­dan­za e si risolve il single point of failure.

Spesso, entrambi i server DNS ap­par­ten­go­no alla stessa or­ga­niz­za­zio­ne. Se uno di essi si guasta, vi è un’alta pro­ba­bi­li­tà che anche l’altro venga coinvolto nel mal­fun­zio­na­men­to. Per sicurezza si possono me­mo­riz­za­re gli indirizzi di due name server di or­ga­niz­za­zio­ni diverse. Una com­bi­na­zio­ne molto diffusa è 1.1.1.1 e 9.9.9.9 di Clou­d­fla­re e Quad9 come server DNS primario e se­con­da­rio.

Alla fine del 2021, un gran numero di servizi web basati su Java erano affetti dalla falla di sicurezza Log4Shell. Il single point of failure era una libreria di logging Java chiamata Log4J. Quindi, un attacco di sistema poteva portare nel peggiore dei casi all’ac­qui­si­zio­ne di un intero sistema vul­ne­ra­bi­le.

In generale, la pre­ven­zio­ne è la strategia migliore per evitare i SPOF. Per de­fi­ni­zio­ne, un single point of failure porta alla perdita di fun­zio­na­li­tà dell’intero sistema. Quando ciò accade, spesso è troppo tardi. Limitare i danni può quindi essere l’unica opzione possibile.

Per questi motivi le misure pre­ven­ti­ve e la pia­ni­fi­ca­zio­ne delle emergenze sono una strategia migliore. È possibile simulare scenari di guasto credibili e ana­liz­za­re i rischi e le possibili misure di pro­te­zio­ne. Diversi tipi di single point of failure possono essere prevenuti da alcune ca­rat­te­ri­sti­che del sistema:

I sistemi critici ben preparati sono sot­to­po­sti a un mo­ni­to­rag­gio continuo per rilevare gli errori il prima possibile e cor­reg­ger­li se ne­ces­sa­rio.

Una rac­co­man­da­zio­ne per con­tra­sta­re i SPOF è quella di creare ri­don­dan­ze. Diverse istanze di un com­po­nen­te critico (ad esempio ali­men­ta­zio­ne, con­nes­sio­ne di rete, server DNS) vengono gestite in parallelo. Se uno di essi si guasta, il sistema continua a fun­zio­na­re senza che si ve­ri­fi­chi­no cali delle pre­sta­zio­ni.

La ri­don­dan­za impedisce anche molti SPOF sul lato software. Un esempio sono i famosi mi­cro­ser­vi­zi rispetto ai software monoliti. Un sistema di mi­cro­ser­vi­zi è di­sac­cop­pia­to e meno complesso, il che lo rende più robusto contro i SPOF. Inoltre, poiché i mi­cro­ser­vi­zi vengono avviati come con­te­ni­to­ri, è più facile creare ri­don­dan­ze.

Come fa esat­ta­men­te la ri­don­dan­za a pro­teg­ge­re un sistema? Uti­liz­zia­mo la stima dell’af­fi­da­bi­li­tà di un sistema nota come “legge di Lusser” per il­lu­strar­lo. Di seguito ri­por­tia­mo un esempio:

Sup­po­nia­mo che un sistema abbia due con­nes­sio­ni in­di­pen­den­ti e parallele a un ali­men­ta­to­re. Sup­po­nia­mo inoltre che la pro­ba­bi­li­tà che il col­le­ga­men­to si guasti in un de­ter­mi­na­to periodo sia dell’1%. La pro­ba­bi­li­tà di guasto completo del col­le­ga­men­to di ali­men­ta­zio­ne può essere calcolata come il prodotto delle pro­ba­bi­li­tà:

1. Pro­ba­bi­li­tà di fal­li­men­to di un’istanza:

1% = 1 / 100 = 1 / 10 ^ 2 = 0,01

1. Pro­ba­bi­li­tà di fal­li­men­to di due istanze in suc­ces­sio­ne:

1% * 1% = (1 / 10 ^ 2) ^ 2 = 1 / 10 ^ 4 = 0,0001

Come si può vedere, la pro­ba­bi­li­tà di un SPOF non si dimezza quando si eseguono due istanze, ma si riduce di due di­men­sio­ni. Si tratta di un mi­glio­ra­men­to con­si­de­re­vo­le. Con tre istanze in ese­cu­zio­ne in parallelo, un guasto dell’intero sistema dovrebbe essere quasi im­pos­si­bi­le.

Purtroppo, la ri­don­dan­za non è una panacea. Piuttosto, questo metodo protegge un sistema dai SPOF entro certi limiti. In primo luogo, la pro­ba­bi­li­tà di guasto di un’istanza deve essere in­di­pen­den­te dalla pro­ba­bi­li­tà di guasto dell’istanza o delle istanze ri­don­dan­ti. Questo non è il caso in cui il guasto è causato da un evento esterno. Se un data center va a fuoco, i com­po­nen­ti ri­don­dan­ti si guastano insieme.

Oltre alla ri­don­dan­za dei com­po­nen­ti di­stri­bui­ti, la di­stri­bu­zio­ne di alcuni com­po­nen­ti è fon­da­men­ta­le per mitigare i SPOF. La di­stri­bu­zio­ne geo­gra­fi­ca dell’in­fra­strut­tu­ra di ar­chi­via­zio­ne dati e di calcolo protegge dai disastri am­bien­ta­li. Inoltre, è utile cercare di ottenere una certa ete­ro­ge­nei­tà o diversità dei com­po­nen­ti critici del sistema. La diversità riduce la pro­ba­bi­li­tà che le istanze ri­don­dan­ti si guastino.

Il­lu­stria­mo il vantaggio della diversità usando la ((sicurezza in­for­ma­ti­ca|server/si­che­rheit/was-ist-cy­ber­si­che­rheit/)) come esempio. Im­ma­gi­na­te un data center con load balancer ri­don­dan­ti dello stesso tipo. Una vul­ne­ra­bi­li­tà di sicurezza in uno dei load balancer si presenta anche nelle istanze ri­don­dan­ti. Nel peggiore dei casi, un attacco pa­ra­liz­ze­rà tutte le istanze. Uti­liz­zan­do modelli diversi, l’intero sistema ha maggiori pos­si­bi­li­tà di con­ti­nua­re a fun­zio­na­re a pre­sta­zio­ni ridotte.

La ri­don­dan­za non è sempre suf­fi­cien­te a prevenire i SPOF. Inoltre, alcuni com­po­nen­ti non possono essere pro­get­ta­ti in modo ri­don­dan­te. Quando la ri­don­dan­za non è un’opzione, entrano in gioco altre strategie.

L’approccio della “difesa in pro­fon­di­tà” è ben noto nel campo della sicurezza in­for­ma­ti­ca. Si tratta di erigere più anelli di pro­te­zio­ne in­di­pen­den­ti intorno a un sistema. Questi devono essere violati uno dopo l’altro per provocare un guasto al sistema. La pro­ba­bi­li­tà che l’intero sistema si guasti a causa di un singolo com­po­nen­te è infatti minore.

Per quanto riguarda i sistemi digitali, esistono linguaggi di pro­gram­ma­zio­ne speciali con tol­le­ran­za ai guasti in­cor­po­ra­ta. L’esempio più noto è il lin­guag­gio “Erlang”, svi­lup­pa­to alla fine degli anni Ottanta. Insieme all’ambiente di runtime associato, questo lin­guag­gio è adatto per creare sistemi altamente di­spo­ni­bi­li e tol­le­ran­ti ai guasti.

Il trionfo globale del World Wide Web e la dif­fu­sio­ne dello sviluppo web hanno rap­pre­sen­ta­to una nuova sfida. I pro­gram­ma­to­ri sono stati costretti a svi­lup­pa­re siti web che fun­zio­nas­se­ro su una varietà di di­spo­si­ti­vi. L’approccio di base uti­liz­za­to in questo processo è noto come “graceful de­gra­da­tion” (in italiano: “de­gra­da­zio­ne graduale”). Se un browser o un di­spo­si­ti­vo non supporta una par­ti­co­la­re tec­no­lo­gia in una pagina, questa viene resa nel modo migliore possibile. Si tratta di un approccio “fail-soft”:

Non aspettate che il sistema si guasti per iden­ti­fi­ca­re i single point of failure nel vostro sistema. È meglio procedere in modo proattivo con­si­de­ran­do­li come parte in­te­gran­te di una strategia di gestione del rischio. In questo modo si uti­liz­za­no le analisi dell’in­ge­gne­ria dell’af­fi­da­bi­li­tà, come l’analisi dell’albero dei guasti o dell’albero degli eventi. L’analisi delle modalità e degli effetti dei guasti (FMEA) viene uti­liz­za­ta per iden­ti­fi­ca­re le fonti di guasto più critiche.

L’approccio generale per iden­ti­fi­ca­re i single point of failure nell’IT aziendale consiste nell’eseguire una va­lu­ta­zio­ne del rischio sulle tre di­men­sio­ni prin­ci­pa­li:

• Hardware
• Software/servizi/provider
• Personale

In primo luogo, si crea una lista di controllo dell’analisi SPOF per mostrare le aree generali da ana­liz­za­re ul­te­rior­men­te. Suc­ces­si­va­men­te, viene eseguita un’analisi SPOF det­ta­glia­ta delle singole aree:

• Di­spo­si­ti­vi non mo­ni­to­ra­ti nella rete
• Sistemi software o hardware non ri­don­dan­ti
• Personale e fornitori che non possono essere so­sti­tui­ti in caso di emergenza
• Tutti i dati non inclusi nei backup

Per ogni com­po­nen­te del sistema viene ana­liz­za­to l’effetto negativo di un guasto. Inoltre, viene stimata la pro­ba­bi­li­tà ap­pros­si­ma­ti­va di un guasto ca­ta­stro­fi­co. I risultati sono in­cor­po­ra­ti in un piano generale di “disaster recovery” per garantire la sicurezza nel data center.

Come misura di base per evitare i SPOF, la ri­don­dan­za dell’ar­chi­via­zio­ne dei dati e della potenza di calcolo deve essere garantita a tre livelli:

• A livello di server at­tra­ver­so com­po­nen­ti hardware ri­don­dan­ti
• A livello di sistema at­tra­ver­so il clu­ste­ring, ovvero l’uso di più server
• A livello di data center uti­liz­zan­do più siti di­stri­bui­ti in diversi luoghi geo­gra­fi­ci