32.211 incidenti di sicurezza informatica hanno colpito le agenzie federali statunitensi nell'anno fiscale 2023 e, sebbene il tempo medio di risoluzione fosse di 20 giorni, alcune agenzie hanno impiegato 168 giorni per chiudere gli incidenti, secondo la sintesi di Fortinet delle statistiche sulla cybersecurity federale riportate dal GAO. Questo dovrebbe cambiare il modo in cui un CIO del settore pubblico inquadra il problema. Non si tratta principalmente di rafforzare il perimetro, di esercizi annuali di compliance o di aggiungere un ulteriore prodotto di sicurezza a uno stack già affollato. Si tratta di capire se le agenzie possono ancora fidarsi della posizione, dei movimenti e dell'integrità dei dati che custodiscono.

Il vecchio modello perimetrale presupponeva un mondo più ordinato. Gli utenti lavoravano all'interno di reti gestite, i sistemi cambiavano lentamente e i dati sensibili risiedevano in un numero ridotto di applicazioni ben definite. Quel mondo non esiste più. Oggi le agenzie gestiscono ambienti ibridi, piattaforme ereditate, servizi cloud, percorsi di accesso dei fornitori e flussi di dati tra dipartimenti che non si adattano a un unico confine. Se organizzate ancora la sicurezza secondo la logica “dentro è sicuro, fuori è pericoloso”, la vostra architettura è già in ritardo rispetto al vostro modello di minaccia.

Un approccio più solido parte dai dati stessi. Verificate ogni richiesta. Limitate l'accesso al perimetro più ristretto possibile. Osservate come si comportano i dati là dove risiedono, non solo come il traffico attraversa un gateway. Preservate la sovranità dove la missione lo richiede. E costruite controlli che funzionino con i sistemi legacy, invece di fingere che possano essere tutti sostituiti secondo un calendario ordinato. Conta anche l'aspetto fisico. Le agenzie migliori sanno che serrature fisiche e resilienza informatica concorrono allo stesso risultato: ridurre i percorsi di accesso non autorizzati prima che si trasformino in guasti operativi.

Indice

• La sfida invisibile della sicurezza dei dati nel settore pubblico

  • Perché i presupposti tradizionali falliscono

  • Il reale carico operativo

• Comprendere l'evoluzione del panorama delle minacce

  • Perché la pubblica amministrazione resta un bersaglio privilegiato

  • I vettori di attacco più rilevanti

• Orientarsi tra i principali quadri normativi e di compliance

  • La compliance deve guidare la disciplina operativa

  • Ciò che i team maturi rendono davvero operativo

• Architettura di sicurezza fondamentale per la PA moderna

  • Zero Trust come modello operativo

  • Come far funzionare Zero Trust negli ambienti legacy

• Modelli di deployment sicuri e data governance

  • Scegliere il modello di deployment giusto

  • Regole di governance che prevengono errori costosi

• Ridurre il rischio con la Data Observability in loco

  • Perché gli strumenti perimetrali non vedono il rischio interno sui dati

  • Cosa dovrebbe monitorare l'observability in loco

• Costruire un piano di risposta agli incidenti resiliente

  • Il ciclo in sei fasi che le agenzie dovrebbero esercitare

  • Cosa distingue i piani utilizzabili da quelli che restano nel cassetto

La sfida invisibile della sicurezza dei dati nel settore pubblico

La sicurezza dei dati nel settore pubblico è più difficile rispetto alla maggior parte degli ambienti commerciali per un motivo semplice. I sistemi della pubblica amministrazione raramente proteggono una sola cosa. Proteggono dati dei cittadini, processi di erogazione delle prestazioni, dati fiscali, informazioni sanitarie, sistemi di identità, dati delle forze dell'ordine, documenti sugli appalti e piattaforme operative da cui dipendono altri servizi.

Ne deriva un modello di rischio composto. Una violazione non è solo un problema di riservatezza. Può diventare contemporaneamente un problema di disponibilità del servizio, un problema legale, un problema di fiducia e un problema di resilienza nazionale. Quando le agenzie gestiscono dati sensibili su piattaforme vecchie e nuove, la questione principale non è la mancanza di policy. È il divario tra l'intento delle policy e la realtà tecnica quotidiana.

Perché i presupposti tradizionali falliscono

Le strategie fortemente basate sul perimetro crollano quando l'accesso non è più legato a un unico confine di rete. I fornitori si collegano da ambienti diversi. I dipartimenti condividono dati oltre i confini organizzativi. Gli amministratori gestiscono i sistemi da remoto. I dipendenti usano servizi cloud che il team di sicurezza non ha approvato ma che non riesce a vedere facilmente.

Un firewall conta ancora. La segmentazione della rete conta ancora. Ma nessuno dei due risponde alla domanda centrale che le agenzie moderne devono affrontare: chi accede a quali dati, da quale contesto, per quale scopo, e cosa è cambiato all'interno dei dati una volta concesso l'accesso?

Regola pratica: se un controllo vede solo il confine e non il comportamento dei dati che vi stanno dietro, consideratelo necessario ma insufficiente.

Il reale carico operativo

La maggior parte delle agenzie non può ricostruire da zero. Eredita sistemi gestionali di settore, vincoli negli appalti, oneri di accreditamento e carenze di personale. I responsabili della sicurezza hanno bisogno di modelli che migliorino il controllo senza interrompere i servizi su cui contano i cittadini.

Ciò significa che la sicurezza dei dati nel settore pubblico deve diventare più incentrata sui dati e più realistica. L'architettura giusta non presuppone che ogni applicazione legacy possa supportare agenti moderni, una federazione perfetta o una riprogettazione immediata. Avvolge gli archivi di dati di alto valore con controlli di identità più forti, permessi più ristretti, una segmentazione più rigorosa e un'observability in grado di rilevare modifiche rischiose anche quando l'applicazione stessa non ci riesce.

Comprendere l'evoluzione del panorama delle minacce

Gli ambienti della pubblica amministrazione attirano attaccanti persistenti perché il valore del bersaglio è insolitamente alto. I dati dei cittadini rendono possibili le frodi. L'accesso amministrativo rende possibili le interruzioni. I sistemi operativi danno un vantaggio agli attaccanti. La visibilità pubblica aumenta la pressione sui dirigenti affinché ripristinino rapidamente i servizi, ed è per questo che sia i gruppi ransomware sia gli operatori legati a Stati prestano attenzione al settore.

La tendenza va nella direzione sbagliata. Le violazioni di dati nella pubblica amministrazione statunitense sono passate da 47 incidenti nel 2020 a 128 nel 2024, un aumento del 173%, secondo la raccolta di statistiche sulla cybersecurity dell'Università di San Diego, che rileva anche che il phishing è coinvolto nel 68% delle violazioni con una componente umana.

Un semplice schema aiuta a spiegare la dinamica.

Perché la pubblica amministrazione resta un bersaglio privilegiato

Gli attaccanti non vedono le agenzie come blocchi monolitici. Vedono ambienti difesi in modo disomogeneo, con dati di alto valore e molte vie d'accesso. Un dipartimento può avere controlli di identità maturi mentre un altro dipende ancora da un'autenticazione legacy fragile. Un team può classificare i dati con rigore mentre un altro eredita unità condivise e vecchie integrazioni che nessuno vuole toccare prima di un ciclo di reporting critico.

Le motivazioni rientrano di solito in alcune categorie:

• Spionaggio e accesso strategico: documenti sensibili, informazioni operative e persistenza a lungo termine hanno un valore evidente.

• Estorsione finanziaria: gli operatori ransomware sanno che i servizi pubblici subiscono pressioni per un ripristino rapido.

• Interruzione: bloccare i servizi ai cittadini genera un impatto pubblico sproporzionato rispetto all'intrusione iniziale.

• Facilitazione delle frodi: i dati legati all'identità e i processi amministrativi possono alimentare attività criminali a valle.

In realtà, molti attacchi riusciti non iniziano con tecniche sofisticate. Iniziano con un'azione ordinaria di un utente, un account con permessi eccessivi o un percorso di terze parti trascurato.

I vettori di attacco più rilevanti

La prima priorità resta la compromissione dell'identità. Il phishing funziona perché aggira l'eleganza tecnica e prende di mira le abitudini umane. Gli attaccanti non hanno bisogno di “violare” l'intero ambiente se riescono a convincere una persona a cedere l'accesso o ad approvare l'azione sbagliata.

Un secondo vettore è la catena del software e dei fornitori. Le agenzie dipendono da appaltatori, integratori, servizi gestiti e piattaforme pacchettizzate. Ogni connessione aggiunge valore. Ogni connessione aggiunge però anche presupposti di fiducia che possono essere più ampi del dovuto.

Più avanti nella kill chain, il movimento laterale diventa la questione chiave. Una volta ottenuto un punto d'appoggio, gli attaccanti cercano connettività interna piatta, service account deboli, strumenti amministrativi esposti e repository di dati non segmentati tra loro. È qui che la mentalità perimetrale tradizionale danneggia di più le agenzie. Spesso protegge l'ingresso meglio dei movimenti e degli accessi successivi all'ingresso.

Il video qui sotto offre una panoramica utile, dal punto di vista dei professionisti, di come si sviluppano operativamente le minacce moderne al settore pubblico.

Le agenzie dovrebbero modellare le minacce partendo dai comportamenti di routine, non solo dalle firme di attacco evidenti. La domanda pericolosa non è “Qualcuno può entrare?”. È “Cosa può raggiungere silenziosamente una volta entrato?”

Orientarsi tra i principali quadri normativi e di compliance

I programmi di sicurezza solidi nel settore pubblico trattano la compliance come una soglia minima, non come l'architettura. Questa distinzione è importante. FISMA, le pratiche allineate al NIST, gli obblighi GDPR dove pertinenti e le normative settoriali spingono tutti le agenzie verso le stesse abitudini operative: conoscere i propri dati, controllare gli accessi, documentare le responsabilità, monitorare in modo continuo e reagire rapidamente quando qualcosa va storto.

L'errore è trasformare questi quadri in progetti burocratici. I team annegano in cataloghi di controlli, evidenze di audit e gestione delle eccezioni, mentre l'esposizione reale rimane invariata. I programmi maturi invertono quest'ordine. Prima costruiscono controlli che migliorano l'operatività, poi producono le evidenze di compliance come sottoprodotto di un'esecuzione disciplinata.

La compliance deve guidare la disciplina operativa

Il modo più utile di leggere un quadro normativo è chiedersi quale comportamento cerca di imporre all'interno dell'organizzazione.

Alcuni esempi contano più delle citazioni raccolte in un faldone:

• Gestione del rischio: i dirigenti hanno bisogno di un metodo ripetibile per classificare sistemi e dati in base all'impatto sulla missione, non in base a chi alza di più la voce.

• Controllo degli accessi: ogni autorizzazione dovrebbe avere un responsabile, uno scopo e un percorso di revisione.

• Monitoraggio continuo: una certificazione puntuale non proteggerà un sistema che cambia ogni settimana.

• Preparazione agli incidenti: piani, poteri decisionali e canali di comunicazione devono esistere prima di una crisi.

Accessibilità e sicurezza si intersecano più spesso di quanto i team si aspettino. Le agenzie che modernizzano i servizi digitali non possono separare la protezione dagli obblighi di accesso pubblico. Quando le piattaforme web trattano dati dei cittadini, anche le scelte di design, usabilità e compliance influenzano i risultati di sicurezza. I team che si occupano di servizi rivolti al pubblico dovrebbero conoscere anche questa guida alla conformità all'ADA Title II, perché le lacune di accessibilità emergono spesso negli stessi programmi di modernizzazione che gestiscono dati sensibili.

Ciò che i team maturi rendono davvero operativo

I programmi più efficaci del settore pubblico convergono di solito su un breve elenco di discipline operative:

È questo il valore pratico della compliance. Offre a CIO e CISO un linguaggio comune per imporre decisioni che altrimenti resterebbero ambigue.

Test per la leadership: se un controllo non può essere collegato a un responsabile di sistema, a un dataset o a un processo di business, probabilmente non reggerà sotto pressione.

Architettura di sicurezza fondamentale per la PA moderna

Il cuore della moderna sicurezza dei dati nel settore pubblico è la Zero Trust Architecture. Non come slogan, ma come scelta progettuale. Ogni utente, dispositivo, servizio e workload deve guadagnarsi l'accesso in modo continuo, invece di ereditare fiducia perché si trova sulla rete giusta o proviene da una zona approvata.

Secondo la panoramica di Commvault sulla sicurezza nel settore pubblico, l'implementazione di una Zero Trust Architecture può ridurre la superficie di attacco del 60-70% rispetto ai modelli tradizionali basati sul perimetro. Per questo è diventata il modello di riferimento anziché un'idea di modernizzazione di nicchia.

Zero Trust come modello operativo

Il modo più semplice per spiegare Zero Trust a un dirigente non tecnico è paragonarlo a un archivio documentale.

Nel vecchio modello, una volta superata la porta d'ingresso, ci si poteva muovere all'interno con troppa libertà. Nel modello Zero Trust, ogni stanza, armadio e categoria di fascicoli ha la propria decisione di controllo. Un fornitore dell'area finanziaria non eredita l'accesso ai dati sanitari pubblici. Una sessione dell'help desk non diventa un percorso amministrativo generico. Una credenziale compromessa non concede automaticamente l'accesso ai sistemi adiacenti.

Tre scelte progettuali rendono tutto questo concreto:

• Verifica forte dell'identità: le agenzie hanno bisogno di un'autenticazione affidabile per utenti, servizi e dispositivi.

• Accesso con privilegi minimi: le persone dovrebbero ottenere l'accesso minimo necessario per il proprio ruolo e nulla di più.

• Micro-segmentazione: sistemi e archivi di dati dovrebbero essere isolati, così che la compromissione di una zona non diventi una compromissione ovunque.

Molti programmi finiscono spesso per arenarsi. Adottano il linguaggio Zero Trust ma mantengono sotto la superficie un'ampia fiducia di rete e una proliferazione di ruoli. L'architettura funziona solo quando l'autorizzazione diventa abbastanza granulare da riflettere l'effettiva sensibilità dei dati.

Come far funzionare Zero Trust negli ambienti legacy

I sistemi legacy sono il punto in cui la strategia incontra l'attrito. Le piattaforme più vecchie potrebbero non supportare la federazione moderna, motori di policy dinamici o un'applicazione pulita basata su API. Ciò non significa che le agenzie debbano aspettare. Significa che hanno bisogno di modelli compensativi.

Iniziate dai dati che causerebbero più danni se esposti o alterati. Avvolgete quei sistemi con un identity brokering più forte, flussi di accesso privilegiato e connettività segmentata. Collocate i percorsi amministrativi dietro jump point controllati. Limitate in modo rigoroso i service account. Registrate le decisioni di accesso laddove il sistema non è in grado di esprimere nativamente policy moderne.

Un'introduzione graduale funziona di solito meglio di un obbligo esteso a tutta la piattaforma:

1. Mappate per primi gli archivi di dati di alto valore: non iniziate dalle applicazioni più semplici. Iniziate dai dati con le conseguenze più gravi.

2. Riducete gli accessi privilegiati: la comodità degli amministratori è uno dei maggiori moltiplicatori nascosti della superficie di attacco.

3. Segmentate per missione e sensibilità: non permettete a sistemi non correlati di condividere la fiducia solo perché condividono l'infrastruttura.

4. Aggiungete livelli di verifica attorno alle applicazioni legacy: se l'applicazione non può applicare il contesto, applicatelo a monte e attorno a essa.

Per i team interessati a un rilevamento più precoce vicino al livello dei dati, questo articolo su come digna rileva precocemente gli attacchi informatici nel vostro database è un esempio utile di come il monitoraggio a livello di database si inserisca in un approccio Zero Trust più ampio.

Modelli di deployment sicuri e data governance

Il luogo in cui risiedono i dati cambia immediatamente la discussione sulla sicurezza. Nella pubblica amministrazione, la scelta del deployment non è una semplice preferenza infrastrutturale. Determina sovranità, verificabilità, controllo sui fornitori, contenimento degli incidenti e rischio negli appalti.

Per alcuni workload, il cloud pubblico è una risposta pratica. Per altri, crea complicazioni di governance che le agenzie sottovalutano in fase di acquisto e poi passano anni a gestire tramite eccezioni. La decisione giusta dipende meno dall'ideologia e più dalla sensibilità dei dati, dall'impatto di un'interruzione del servizio sulla missione e dal grado di controllo che l'agenzia deve mantenere.

Scegliere il modello di deployment giusto

Per le informazioni classificate e per alcuni ambienti altamente sensibili, l'analisi di Rocket.Chat sulla cybersecurity nella pubblica amministrazione osserva che molti riferimenti normativi richiedono un deployment on-premise con air-gapping per garantire la sovranità dei dati, e che lo storage air-gapped combinato con backup immutabili è una delle principali misure di mitigazione contro ransomware e accessi remoti non autorizzati. Questo principio dovrebbe guidare non solo i workload classificati. Ricorda alle agenzie che alcuni dati non dovrebbero dipendere da percorsi di gestione raggiungibili dall'esterno.

Un confronto pratico si presenta così:

L'errore è pensare che un solo modello debba dominare l'intero ambiente. La maggior parte delle agenzie ne ha bisogno di più di uno. La sfida è mantenere una governance coerente tra tutti.

Regole di governance che prevengono errori costosi

La sicurezza del deployment fallisce quando la data governance è vaga. I team hanno bisogno di decisioni esplicite su classificazione, responsabilità, conservazione, accesso e ambienti di trattamento consentiti.

I modelli operativi più solidi sono di solito semplici:

• Classificate prima della migrazione: non spostate un dataset finché la sua sensibilità e il modello di hosting consentito non sono documentati.

• Vincolate i fornitori a controlli applicabili: le clausole contrattuali dovrebbero rispecchiare l'architettura di sicurezza, non semplicemente i modelli standard di acquisto.

• Controllate il ciclo di vita dei dati: copie, estrazioni e set di lavoro temporanei diventano spesso l'anello più debole.

• Mantenete responsabili nominativi: ogni dataset ha bisogno di un responsabile di business, non solo di un custode tecnico.

Le agenzie che cercano di rafforzare questa disciplina tra i vari programmi dovrebbero ragionare in termini di policy più implementazione. Un riferimento pratico è questo articolo su qualità dei dati nella pubblica amministrazione e data governance nel settore pubblico, soprattutto per i team che allineano la governance all'uso operativo dei dati invece di trattarla come un flusso burocratico separato.

Ridurre il rischio con la Data Observability in loco

I controlli tradizionali rispondono solo a una parte della questione sicurezza. Vi dicono se una connessione è stata autorizzata, se un dispositivo è stato registrato o se una policy è stata attivata. Spesso non vi dicono se i dati sottostanti hanno iniziato a comportarsi in un modo che segnala un uso improprio, un guasto di processo o un'intrusione che opera sotto i radar.

Questa lacuna è importante negli ambienti del settore pubblico perché il rischio si manifesta spesso per prima cosa come sintomo nei dati. Una tabella cambia struttura inaspettatamente. Un flusso arriva in ritardo. I record iniziano a non superare la validazione. Un utente privilegiato accede ai dati secondo uno schema insolito. Un workload inizia a inviare informazioni a un servizio cloud di cui il team di sicurezza ignorava l'esistenza.

StateTech Magazine evidenzia direttamente questo punto cieco nella sua analisi della sicurezza cloud nel settore pubblico, sottolineando la mancanza di visibilità sullo shadow IT e su dove i dipendenti archiviano i dati nel cloud, e raccomandando un monitoraggio in loco per tracciare quali dispositivi “chiamano verso il cloud”, perché le difese perimetrali non colgono questo comportamento. Consultate le indicazioni di StateTech sulla visibilità del cloud e sul monitoraggio dello shadow IT.

Perché gli strumenti perimetrali non vedono il rischio interno sui dati

Gli strumenti perimetrali sono stati creati per sorvegliare i confini. Il rischio moderno nella pubblica amministrazione si accumula all'interno dei flussi di lavoro.

Un utente può avere credenziali valide e comunque fare un uso improprio dei dati. Una pipeline può autenticarsi correttamente e comunque consegnare record corrotti. Un fornitore può usare un'applicazione approvata e comunque creare un'esposizione esportando dati nel posto sbagliato. Nessuno di questi scenari appare drammatico a livello di firewall.

Ecco perché la sicurezza dei dati nel settore pubblico ha bisogno di observability in loco. Invece di spostare i dati sensibili verso un livello di monitoraggio esterno, le agenzie possono analizzare il comportamento là dove i dati risiedono già, all'interno di database controllati o di ambienti di cloud privato. Questo approccio è particolarmente interessante dove la sovranità e le restrizioni di accesso dei fornitori sono prioritarie.

Cosa dovrebbe monitorare l'observability in loco

I programmi di observability più utili non cercano di duplicare gli strumenti SIEM. Si concentrano sui segnali nativi dei dati che i team di sicurezza e governance altrimenti non vedrebbero.

Una buona copertura comprende di solito:

• Modifiche allo schema: campi aggiunti, rimossi o modificati possono segnalare un malfunzionamento o una modifica non autorizzata.

• Anomalie di tempestività: caricamenti in ritardo o mancanti rivelano spesso guasti operativi prima che i dirigenti vedano report errati.

• Errori di validazione: i record che violano le regole possono rivelare usi impropri, difetti di integrazione o manomissioni.

• Anomalie comportamentali nell'accesso o nell'output dei dati: schemi insoliti di query, esportazione o movimento meritano un'analisi attenta.

Un principio operativo solido è monitorare le deviazioni silenziose, non solo i guasti espliciti.

Se un dataset cambia in modi che nessuno si aspettava, presumete che ci sia una questione di sicurezza o di governance finché un team non dimostra il contrario.

I team che confrontano l'observability con i controlli di qualità tradizionali traggono spesso vantaggio da una distinzione più chiara tra i due. Questa panoramica su Data Observability e Data Quality a confronto è utile perché molte agenzie finanziano ancora queste capacità attraverso gruppi separati, anche se i segnali operativi si sovrappongono.

Costruire un piano di risposta agli incidenti resiliente

Anche i controlli più solidi non impediranno ogni incidente. La questione è se l'agenzia sia in grado di rilevare rapidamente, decidere con chiarezza, contenere efficacemente e ripristinare senza improvvisare sotto pressione. Troppi piani di risposta del settore pubblico sembrano validi in una revisione delle policy e falliscono alla prima vera chiamata di escalation.

La struttura dovrebbe essere abbastanza semplice da poter essere esercitata e abbastanza specifica da poter essere usata. Il ciclo in sei fasi illustrato di seguito resta il formato più affidabile per la maggior parte delle agenzie.

Il ciclo in sei fasi che le agenzie dovrebbero esercitare

1. Preparazione
   Definite la struttura del team, i percorsi di escalation, la prontezza forense, i modelli di comunicazione e i poteri decisionali prima di una crisi. La preparazione include anche assicurarsi che gli stakeholder legali, degli acquisti, operativi e dirigenziali conoscano il proprio ruolo.

2. Identificazione
   Verificate se l'evento è reale, quali sistemi sono coinvolti e se un'esposizione dei dati è plausibile. Il primo compito è ridurre l'incertezza abbastanza in fretta da permettere ai dirigenti di agire.

3. Contenimento
   Fermate la propagazione. Ciò può significare isolare workload, disattivare account, interrompere integrazioni o restringere i percorsi di rete. Le decisioni di contenimento dovrebbero privilegiare la continuità della missione ove possibile, ma non possono preservare la comodità a scapito del controllo.

Cosa distingue i piani utilizzabili da quelli che restano nel cassetto

1. Eradicazione
   Eliminate la causa, non solo il sintomo. Se una credenziale è stata abusata, correggete la condizione di accesso che l'ha resa pericolosa. Se un'integrazione vulnerabile ha reso possibile la violazione, non ricollegatela senza modifiche.

2. Ripristino
   Ripristinate i servizi con attenzione. Verificate l'integrità dei sistemi, monitorate da vicino e comunicate chiaramente con gli stakeholder coinvolti. Un ripristino senza verifica spesso ricrea lo stesso incidente in un'altra forma.

3. Attività post-incidente
   Conducete una seria analisi delle lezioni apprese. Aggiornate playbook, controlli, decisioni architetturali e formazione. Se l'incidente ha messo in luce una lacuna di responsabilità, di visibilità sui dati o di governance dei fornitori, correggetela in modo sistemico.

Un buon piano di risposta agli incidenti risponde anche a tre domande pratiche in linguaggio semplice: chi può dichiarare un incidente, chi può mettere offline i sistemi e chi comunica all'esterno? Se queste decisioni non sono chiare, il team tecnico perderà tempo prezioso in attesa di certezze amministrative.

Consiglio operativo: eseguite esercitazioni su dipendenze legacy, servizi condivisi e integrazioni di terze parti. Sono i punti in cui gli incidenti reali diventano più caotici.

Se la vostra agenzia ha bisogno di una migliore visibilità su anomalie nei dati, modifiche allo schema, problemi di validazione e tempestività delle pipeline senza spostare i dati sensibili al di fuori del vostro ambiente, vale la pena valutare con attenzione digna. Il suo approccio è pensato per deployment controllati dal cliente, inclusi ambienti di cloud privato e on-prem, il che lo rende rilevante per i team del settore pubblico che necessitano di una observability più solida senza concedere ai fornitori l'accesso ai dataset di produzione.

Domande frequenti

Perché il settore pubblico è un bersaglio privilegiato per gli attacchi ai dati?

La pubblica amministrazione custodisce dati anagrafici, previdenziali, sanitari e fiscali preziosi e insostituibili, e spesso gestisce sistemi di lunga durata che non possono essere aggiornati rapidamente. Le agenzie federali statunitensi hanno registrato 32.211 incidenti di sicurezza informatica nell'anno fiscale 2023, con tempi di risoluzione compresi tra 20 e 168 giorni.

Quali sono i principali vettori di attacco contro i dati della pubblica amministrazione?

Compromissione delle credenziali ed escalation dei privilegi, servizi esposti su Internet non aggiornati, accessi di terze parti e fornitori, e storage configurato in modo errato. Il filo conduttore è che il punto d'ingresso è raramente sofisticato: è un account, un servizio o una configurazione di cui nessuno era responsabile.

Quali quadri di compliance si applicano ai dati del settore pubblico?

Gli obblighi specifici variano a seconda della giurisdizione, ma lo schema è coerente: controllo degli accessi, conservazione, verificabilità, notifica delle violazioni e diritti di accesso dei cittadini. La compliance è più utile quando viene trattata come disciplina operativa anziché come esercizio annuale di raccolta di evidenze.

Che cos'è lo zero trust nel contesto della pubblica amministrazione?

Significa che nessun utente, dispositivo o servizio è considerato affidabile per impostazione predefinita in base alla sua posizione nella rete. Ogni richiesta viene autenticata, autorizzata e registrata. Per gli ambienti legacy il percorso pratico è incrementale: partire dall'identità e dagli accessi privilegiati invece di tentare una riprogettazione completa.

Che rapporto c'è tra qualità dei dati e sicurezza nel settore pubblico?

Il controllo degli accessi dipende dal sapere quali dati si possiedono, dove risiedono e quanto sono sensibili. Inventari incompleti, classificazioni obsolete e copie non documentate sono al tempo stesso un difetto di qualità e un'esposizione di sicurezza, perché non si possono proteggere dati che non si sanno descrivere.