1. Servizi digitali esposti e fiducia del cittadino
Quando un servizio digitale pubblico non è disponibile, il problema non resta confinato al reparto IT. Può impedire a cittadini e imprese di accedere a informazioni, presentare richieste o completare attività che ormai dipendono dal digitale.
Per questo la cybersecurity nella Pubblica Amministrazione non può essere letta soltanto come protezione delle macchine. Riguarda la continuità dei servizi e, indirettamente, la fiducia nelle istituzioni che li erogano.
La superficie da proteggere è inoltre cresciuta. Portali, applicazioni, identità digitali, servizi cloud, integrazioni e API creano un ecosistema più utile, ma anche più articolato. Ogni componente può dipendere da altre componenti e ogni dipendenza deve essere compresa.
In questo scenario il firewall continua ad avere un ruolo, ma non può essere considerato una barriera sufficiente.
2. Cosa è cambiato
Il modello storico era relativamente semplice: una rete interna, un perimetro da difendere e alcuni servizi pubblicati verso l'esterno. Oggi dati e applicazioni possono essere distribuiti tra infrastrutture diverse, mentre utenti e sistemi accedono attraverso numerosi percorsi.
Il web è diventato applicativo. Le API collegano servizi differenti. Il cloud modifica il modo in cui vengono distribuite risorse e responsabilità. Le identità hanno un peso crescente e molte minacce cercano di sfruttare credenziali, configurazioni o vulnerabilità applicative invece di "sfondare" semplicemente il perimetro.
Anche il quadro normativo europeo, dal GDPR alla NIS2 nei rispettivi ambiti di applicazione, rafforza l'attenzione su gestione del rischio, responsabilità, continuità e capacità di risposta. Non si tratta qui di fornire una lettura legale: gli obblighi specifici vanno valutati con professionisti competenti. Dal punto di vista tecnico-organizzativo, però, la direzione è chiara: la sicurezza deve essere gestita come processo.
3. Protezione a strati
La protezione a strati parte da un principio semplice: nessun controllo è perfetto. Se un meccanismo viene superato o non copre un certo tipo di rischio, devono esistere altri livelli capaci di ridurre l'impatto.
Un livello riguarda l'esposizione dei servizi: filtrare traffico indesiderato, mitigare attacchi volumetrici e proteggere applicazioni web. Un altro riguarda le identità: autenticazione, privilegi e controllo degli accessi. Un altro ancora riguarda sistemi e applicazioni: aggiornamenti, configurazioni, gestione delle vulnerabilità e segmentazione.
Poi vengono osservabilità e risposta. Log, monitoraggio e allarmi servono a capire che cosa sta accadendo. Backup, procedure e piani di continuità servono quando la prevenzione non è bastata.
Il concetto importante è che questi livelli devono collaborare. Aggiungere prodotti senza una visione d'insieme può creare una falsa sensazione di sicurezza e aumentare la complessità operativa.
4. Errori tipici
Uno degli errori più frequenti è non conoscere con precisione ciò che è esposto. Non si può proteggere bene un servizio di cui non si conoscono dipendenze, proprietario, dati trattati e criticità.
Un secondo errore è confondere l'acquisto di tecnologia con la gestione della sicurezza. Gli strumenti sono indispensabili, ma devono essere configurati, monitorati e aggiornati. Una regola obsoleta o un allarme ignorato riducono rapidamente il valore della tecnologia installata.
C'è poi la tendenza a concentrarsi soltanto sulla prevenzione. Bisogna invece assumere che un incidente possa accadere e preparare in anticipo responsabilità, comunicazioni, procedure tecniche e priorità di ripristino.
Infine, è rischioso trattare tutti i sistemi allo stesso modo. Un servizio pubblico essenziale e un ambiente secondario non hanno lo stesso impatto. Le risorse di sicurezza devono seguire una valutazione del rischio.
5. Approccio concreto
Io partirei da una sequenza molto semplice: inventario → rischio → controlli → continuità.
L'inventario serve a sapere quali servizi esistono, dove sono ospitati, da cosa dipendono, chi li gestisce e quali dati utilizzano. È una fase meno visibile di un nuovo prodotto di sicurezza, ma spesso è quella che rende possibili tutte le successive.
La valutazione del rischio permette di stabilire priorità. Non occorre immaginare ogni minaccia possibile: bisogna comprendere quali eventi avrebbero impatto maggiore e quali sono plausibili nel contesto specifico.
A quel punto si scelgono i controlli. Possono riguardare rete, applicazioni, identità, configurazioni, monitoraggio, backup o procedure. L'obiettivo è ridurre probabilità e impatto, evitando sovrapposizioni inutili.
Infine viene la continuità. Per i servizi più importanti bisogna sapere cosa fare se una componente diventa indisponibile, chi decide, quali funzioni ripristinare prima e come verificare che il piano funzioni davvero. Un piano non testato resta un documento.
Questo approccio non promette rischio zero, che non esiste. Costruisce invece una capacità progressiva di prevenire, rilevare, reagire e ripartire.
6. Chiusura
La cybersecurity nella PA non può più essere rappresentata da un'unica barriera sul perimetro. Servizi digitali, cloud, API e identità richiedono una protezione a strati e una gestione continua del rischio.
Su cybersecurity e servizi digitali pubblici scrivo con taglio operativo su arduinoleone.it. Per un confronto professionale: a.l@d-serviceitalia.it.