NIS2 e integrazione di sistemi: l'importanza della governance

La NIS2 amplia significativamente il perimetro della precedente direttiva NIS. La distinzione fondamentale è tra soggetti essenziali e soggetti importanti, con obblighi e regime sanzionatorio differenziati, ma entrambe le categorie sono tenute ad adottare misure concrete di gestione del rischio di cybersicurezza.

Il perimetro è ampio e trasversale. La direttiva copre esplicitamente, tra gli altri: energia, trasporti e logistica, settore bancario e finanziario, sanità, infrastrutture digitali, pubblica amministrazione, ma anche servizi postali e di corriere, gestione dei rifiuti, agroalimentare, fabbricazione di dispositivi medici, produzione di macchinari, autoveicoli e altri prodotti manifatturieri, servizi digitali e ricerca.

La soglia dimensionale rilevante è quella della media impresa: 50 o più dipendenti oppure un fatturato annuo superiore a 10 milioni di euro sono sufficienti per rientrare nel perimetro, se si opera in uno dei settori coperti. Fanno eccezione alcune categorie per le quali la dimensione non è un criterio discriminante.

Il punto che molte organizzazioni sottovalutano: attraverso i requisiti sulla sicurezza della supply chain ICT (Art. 21), chi è in perimetro è tenuto a valutare e gestire i rischi legati alle proprie dipendenze tecnologiche verso terze parti. L’intera catena di integrazioni verso sistemi e fornitori esterni diventa oggetto di scrutinio, incluse quelle che spesso nessuno ha mai mappato in modo sistematico.

Cosa chiede NIS2 alle architetture di integrazione

L’Art. 21 della Direttiva NIS2 definisce le misure minime di gestione del rischio di cybersicurezza che i soggetti in perimetro devono adottare. Alcune di queste hanno implicazioni dirette e concrete sulle architetture di integrazione:

• Sicurezza della supply chain ICT: le organizzazioni devono valutare e gestire i rischi di sicurezza associati ai propri fornitori di servizi ICT e alle dipendenze tecnologiche verso terze parti. In pratica: ogni connessione verso un sistema esterno è un potenziale vettore di rischio che deve essere identificato, valutato e monitorato. Un’architettura di integrazione con decine di connessioni point-to-point non documentate non è auditabile  e quindi non è conforme.
• Continuità operativa e gestione degli incidenti: NIS2 impone requisiti stringenti sulla capacità di rilevare, contenere e notificare gli incidenti di sicurezza. Sul piano dell’integrazione, questo richiede che i flussi tra sistemi siano monitorati in tempo reale, che le anomalie siano rilevabili e che sia possibile isolare rapidamente una connessione compromessa senza propagare l’impatto agli altri sistemi. In un’architettura a spaghetti, l’isolamento selettivo è spesso impossibile.
• Controllo degli accessi e autenticazione: le identità che accedono ai sistemi (incluse le identità macchina delle API e dei sistemi integrati) devono essere gestite, tracciate e sottoposte a policy di autorizzazione granulare. API esposte senza governance degli accessi (con chiavi statiche condivise tra più sistemi) rappresentano un rischio difficile da gestire in modo conforme.
• Tracciabilità e auditabilità: gli accessi ai sistemi e i flussi di dati devono essere tracciati con log strutturati, conservati per i periodi previsti e disponibili per analisi forensi in caso di incidente. In assenza di un layer di API management centralizzato, ricostruire cosa è successo in un’architettura distribuita diventa un esercizio manuale e inaffidabile.

Detto in poche parole: un’architettura di integrazione non governata non è auditabile, non è monitorabile e non permette l’isolamento selettivo delle connessioni compromesse. NIS2 rende questi limiti architetturali un problema di compliance, non solo un debito tecnico.

Il problema architetturale sottostante

La maggior parte delle organizzazioni di medie e grandi dimensioni gestisce un ecosistema applicativo cresciuto per accrezione: ogni integrazione è stata costruita quando serviva, con le tecnologie disponibili in quel momento, da team che spesso non esistono più. Il risultato tipico è un’architettura che gli architetti di sistema conoscono bene:

• Connessioni dirette punto-punto tra sistemi, spesso non documentate e non monitorate.
• Chiavi API statiche condivise tra più sistemi, senza scadenza e senza rotazione periodica.
• Assenza di un registro centralizzato delle integrazioni attive e delle dipendenze verso fornitori esterni.
• Log di accesso frammentati tra sistemi diversi, impossibili da correlare in modo affidabile.
• Nessuna capacità di isolare selettivamente una connessione senza interrompere l’intera catena di flussi dipendenti.

Questo modello presenta problemi tecnici indipendentemente da NIS2: fragilità, scarsa manutenibilità, costi di onboarding elevati per ogni nuovo sistema o partner. NIS2 aggiunge un vincolo normativo ad un problema architetturale già esistente: le connessioni verso terze parti devono essere documentate, monitorate e controllabili, e un’architettura a spaghetti non è in grado di garantirlo.

La compliance NIS2 è un percorso più ampio, che include vulnerability management, incident response, identity governance e molto altro. Sul piano specifico della governance delle integrazioni verso terze parti (uno degli ambiti più trascurati) esistono però componenti architetturali precise che rendono quell’ambito auditabile e controllabile:

Le componenti architetturali rilevanti per la governance delle integrazioni

• API Gateway con policy di sicurezza centralizzate: punto di ingresso unico per tutte le richieste in entrata e in uscita verso sistemi terzi. Gestisce autenticazione (OAuth2, mTLS), autorizzazione granulare per identità, rate limiting e routing. Senza un gateway, non è possibile applicare policy di sicurezza uniformi né revocare rapidamente l’accesso ad una connessione compromessa.
• API Management con inventario delle dipendenze: Governo del ciclo di vita delle API e delle integrazioni attive: versionamento, documentazione, monitoraggio dell’utilizzo, gestione delle chiavi di accesso con rotazione automatica. Fornisce l’inventario completo delle connessioni verso sistemi terzi, il prerequisito tecnico per qualsiasi valutazione del rischio della supply chain ICT.
• Middleware con monitoraggio e alerting sui flussi: Strato di orchestrazione per i flussi di integrazione tra sistemi interni ed esterni. Oltre alla gestione delle trasformazioni e del routing, un layer di integrazione enterprise espone metriche in tempo reale sui flussi attivi, anomalie di volume o latenza, errori ricorrenti, segnali che possono indicare una compromissione in atto su una connessione verso un fornitore esterno.
• Log strutturati e correlazione degli eventi: Log centralizzati e strutturati degli accessi API, dei flussi tra sistemi e degli errori, correlabili con i sistemi SIEM aziendali. Componente essenziale per la rilevazione degli incidenti, per la notifica alle autorità entro i tempi previsti da NIS2 e per l’analisi forense post-incidente.
• Segmentazione e isolamento delle connessioni: Capacità di sospendere o revocare selettivamente una connessione verso un fornitore esterno senza propagare l’impatto agli altri flussi dipendenti. In un’architettura con API gateway e middleware centralizzati, questa operazione è spesso una policy di configurazione. In un’architettura point-to-point, è impossibile senza interruzione di servizio.

Queste componenti non esauriscono i requisiti NIS2 (che abbraccia anche vulnerability management, incident response e identity governance) ma affrontano specificatamente il tema della governance delle integrazioni verso terze parti: uno degli ambiti più trascurati e più difficili da rendere auditabile senza un’architettura strutturata.