1. Un servizio pubblico offline è un problema di cittadini
Un attacco informatico contro un servizio pubblico digitale non riguarda soltanto server e reti. Se un portale o un'applicazione diventa irraggiungibile, l'effetto si trasferisce sulle persone che devono utilizzare quel servizio.
La disponibilità è quindi una componente concreta della fiducia. Il cittadino non distingue necessariamente tra un guasto, un errore di configurazione e un attacco. Vede un servizio che non funziona nel momento in cui gli serve.
Per le infrastrutture esposte su Internet questo cambia il modo di pensare la protezione. Non basta chiedersi come impedire un'intrusione. Bisogna chiedersi anche come mantenere il servizio raggiungibile quando qualcuno prova deliberatamente a saturarne le risorse.
Gli attacchi DDoS rientrano precisamente in questo problema.
2. Cos'è un DDoS
Un DDoS, Distributed Denial of Service, cerca di rendere un servizio indisponibile generando un volume di traffico o di richieste tale da consumarne le risorse o saturare i collegamenti.
La caratteristica "distributed" indica che il traffico può provenire contemporaneamente da molte sorgenti, rendendo insufficiente il semplice blocco di un singolo indirizzo.
La spiegazione tecnica può diventare molto più complessa, ma dal punto di vista operativo il concetto essenziale è questo: il servizio deve riuscire a distinguere e assorbire, deviare o filtrare il traffico ostile senza penalizzare quello legittimo.
3. Perché colpisce contesti pubblici/esposti
I servizi pubblici sono, per definizione, accessibili. Un portale destinato ai cittadini non può proteggersi semplicemente restringendo l'accesso a pochi indirizzi conosciuti.
Questa esposizione crea una sfida particolare. Durante un attacco, un aumento improvviso del traffico può assomigliare in parte a un picco legittimo. Le contromisure devono quindi evitare che la protezione stessa blocchi gli utenti reali.
Inoltre un servizio può dipendere da diversi componenti: connettività, DNS, sistemi applicativi, database, API e fornitori esterni. Proteggere soltanto il server visibile non è sufficiente se esistono altri punti che possono diventare colli di bottiglia.
Il rischio non è uguale per tutti i servizi. Cambiano criticità, visibilità, pubblico e conseguenze dell'indisponibilità. Per questo la preparazione deve partire dalla conoscenza dell'architettura e delle priorità.
4. Come cambia la protezione
La prima componente è la capacità di mitigazione. Il traffico anomalo deve poter essere identificato e filtrato prima che raggiunga risorse troppo limitate per sostenerlo. La capacità necessaria dipende dal servizio e dal profilo di rischio.
La seconda è l'architettura. Distribuzione delle risorse, eliminazione dei punti singoli di guasto, protezione delle origini e corretta gestione delle dipendenze rendono il sistema più resistente. La mitigazione non può compensare indefinitamente un'architettura fragile.
La terza è il monitoring. Durante un DDoS servono dati per capire cosa sta succedendo: variazioni di traffico, errori, latenza, saturazione e comportamento delle applicazioni. Senza osservabilità si rischia di reagire in ritardo o di applicare misure troppo aggressive.
La quarta è il runbook, cioè una procedura operativa preparata prima dell'incidente. Deve chiarire chi viene coinvolto, quali controlli effettuare, quali azioni sono autorizzate e come comunicare lo stato del servizio.
La tecnologia conta, ma durante un attacco conta altrettanto sapere chi decide e in quale ordine si agisce.
5. Preparazione pre / durante / dopo
Prima dell'attacco bisogna conoscere i servizi esposti, identificare quelli più critici e verificare le dipendenze. È il momento di definire soglie, contatti, escalation e procedure. Anche i test sono importanti: una protezione mai verificata sotto condizioni realistiche può riservare sorprese nel momento peggiore.
Durante l'attacco l'obiettivo è mantenere o ripristinare la disponibilità limitando gli effetti collaterali. Bisogna osservare il traffico, verificare che la mitigazione stia funzionando e distinguere i problemi causati dall'attacco da quelli introdotti dalle contromisure. La comunicazione interna deve essere sintetica e basata su responsabilità già definite.
Dopo l'attacco non basta tornare online. Occorre ricostruire la sequenza degli eventi, capire quali controlli hanno funzionato, dove si sono verificati ritardi e quali dipendenze hanno mostrato fragilità.
Il post-incidente dovrebbe produrre azioni concrete: aggiornamento delle regole, revisione delle soglie, modifiche architetturali, miglioramento del runbook o nuovi test. In questo modo ogni evento diventa anche un'occasione per aumentare la resilienza.
Questa logica vale oltre il DDoS. La continuità digitale si costruisce prima dell'emergenza e migliora attraverso cicli di verifica e correzione.
6. Chiusura
La protezione dagli attacchi DDoS non può essere ridotta a un singolo apparato o servizio. Richiede mitigazione, architettura resiliente, monitoraggio e procedure operative coordinate.
Per un'infrastruttura pubblica, disponibilità significa possibilità concreta di accedere a un servizio. E la capacità di mantenere quella disponibilità contribuisce direttamente alla fiducia nel digitale.
Su disponibilità dei servizi digitali e protezione da attacchi volumetrici trovi analisi operative su arduinoleone.it. Per un confronto professionale: a.l@d-serviceitalia.it.