Cloudflare: perché un guasto interno può sembrare un attacco, e come preparare una PMI
Parliamo del tuo progetto →Il 18 novembre 2025, secondo il postmortem Cloudflare, un aggiornamento dei permessi modificò i risultati di una query ClickHouse: righe duplicate fecero crescere il file di feature di Bot Management oltre un limite software, provocando errori 5xx. Cloudflare esclude un attacco: il traffico core era largamente normale alle 14:30 UTC, tutti i sistemi alle 17:06 UTC. Questa retrospettiva distingue quel fatto dalle proposte operative che seguono. (Postmortem Cloudflare)
Perché due fornitori non bastano
Per una PMI, avere due vendor non significa avere davvero ridondanza. Se i fornitori condividono dipendenze invisibili — ad esempio DNS nello stesso ecosistema, autenticazione che passa da un proxy unico, CDN e portale clienti costruiti sullo stesso percorso, oppure monitoraggio che dipende dallo stesso accesso — il punto di fragilità resta comune. Cambia il nome del servizio, ma non cambia il rischio operativo. Questa è una valutazione editoriale generale: la dipendenza comune va verificata sulla propria architettura, non dedotta dal numero o dal nome dei fornitori.
Piano pratico per una PMI
L’obiettivo non è azzerare ogni guasto, ma evitare che un guasto diventi un blocco totale. Il piano minimo si regge su quattro elementi: mappa delle dipendenze, canale di stato indipendente, criteri di fallback e ripristino, prova controllata con responsabilità chiare.
1) Mappa le dipendenze critiche
Parti dai servizi che, se degradano, bloccano clienti o operatività interna. La mappa deve indicare chi li gestisce, quale segnale osserva il team e quale azione è autorizzata subito.
| Dipendenza | Segnale di guasto | Responsabile | Azione immediata |
|---|---|---|---|
| DNS | Il nome non risolve o risolve lentamente | IT / fornitore DNS | Verificare record di emergenza, TTL e health check |
| CDN / reverse proxy | Errori 5xx, timeout, pagine lente o non caricate | IT / vendor cloud | Usare una pagina pubblica di cortesia o un percorso alternativo già collaudato con protezioni equivalenti |
| Autenticazione | Il sito è vivo ma il login fallisce | IT / identity provider | Usare solo un accesso di emergenza preconfigurato e tracciato; altrimenti sospendere l’area riservata |
| Portale clienti | Area riservata non carica, non salva o non conclude operazioni | Product / IT | Passare a modalità consultazione o sospendere le transazioni |
| Monitoraggio / status | Non è chiaro se il problema è interno o esterno | Operations | Pubblicare stato indipendente e usare un canale alternativo |
2) Prepara un canale di stato indipendente
Serve una pagina esterna al dominio principale, ospitata e raggiungibile senza dipendere dalla stessa catena di servizi che vuoi proteggere. Deve contenere solo informazioni essenziali: stato dei servizi, orario dell’ultimo aggiornamento, contatto alternativo e istruzioni per l’accesso degradato. Se il sito principale è coinvolto, il canale di stato deve restare leggibile anche da mobile e senza autenticazione.
3) Definisci i criteri di fallback e di rientro
Prima dell’incidente, decidi chi autorizza il percorso alternativo, come preservare TLS, autenticazione, autorizzazioni e controlli di sicurezza, quali funzioni sospendere e come verificare il rientro. Non disattivare il login o esporre direttamente un origin protetto per aggirare il guasto: senza un’alternativa già collaudata, sospendi l’area riservata. Anche la sola consultazione di documenti richiede identità e permessi verificati. Senza questi criteri il team perde tempo a discutere mentre i clienti vedono solo un disservizio.
4) Fai una prova controllata
La prova non serve a dimostrare che tutto funziona sempre, ma a verificare se il team sa eseguire la procedura. Usa un ambiente di prova con dati fittizi per simulare DNS lento, login indisponibile e 5xx del portale; una prova in produzione richiede un piano autorizzato, criteri di arresto e ripristino. L’output atteso non è un benchmark, ma la conferma che ogni ruolo conosce il proprio compito e che il fallback viene applicato senza ambiguità.
Caso simulato: portale clienti
Scenario simulato: una PMI usa CDN, SSO e API del gestionale per il portale clienti. Il vendor CDN subisce un guasto interno; la pagina pubblica di cortesia resta raggiungibile su un percorso indipendente già collaudato, ma il login si interrompe.
Risposta proposta: il team pubblica lo stato sul canale esterno e sospende l’area riservata. Una modalità di sola consultazione è ammessa solo se autenticazione e permessi funzionano e sono verificati; altrimenti nessun documento cliente viene esposto. Le funzioni di modifica o invio restano sospese fino alla verifica del ripristino. Il punto non è aspettare che “torni tutto”, ma garantire continuità parziale e comunicazione chiara.
Tre verifiche da fare in un’ora
- Il canale di stato è raggiungibile senza passare dal dominio principale.
- Chi controlla: operations o IT.
- Quando: subito, prima di ogni test di fallback.
- Esiste un runbook con decisione di fallback e decisione di rientro.
- Chi controlla: responsabile IT o CTO.
- Quando: durante la revisione del piano, non a incidente in corso.
- Il portale ha almeno una modalità degradata documentata e testata.
- Chi controlla: product owner e team tecnico.
- Quando: dopo la prova controllata, con esito registrato.
Limiti da tenere presenti
La checklist è una proposta editoriale, non un runbook universale né una procedura approvata da Cloudflare. Va adattata e provata sulla propria architettura. L’esempio è simulato e non descrive un cliente Dedaloop. La durata di un’ora riguarda le prime verifiche documentali, non la realizzazione o il collaudo di un sistema di continuità.
Cosa fare adesso
Se la tua organizzazione dipende da DNS, CDN, autenticazione o portali transazionali, il prossimo passo non è acquistare un altro servizio “di riserva” a scatola chiusa. Il passo utile è descrivere il processo che vuoi migliorare: quali dipendenze hai, chi decide il fallback e come verifichi il rientro. Su questo si costruisce un piano serio di continuità operativa, non su una promessa di invulnerabilità.