Adeguare l'architettura IT per NIS2: priorizzazione dei controlli tecnici e compromessi accettabili

NIS2 non è una questione puramente di policy. Nella pratica, è l’architettura a determinare se le misure di sicurezza funzionano in modo affidabile, se le prove in fase di audit sono solide e se riuscite a rilevare, valutare e segnalare gli incidenti entro i termini richiesti. Chi prende sul serio Adattare l’architettura IT per NIS2 deve quindi dare priorità ai controlli tecnici (controlli di sicurezza): quali controlli riducono il rischio immediatamente? Quali sono una «vetrina per l’audit» senza effetto operativo? E dove sono accettabili compromessi senza causare in seguito costosi redesign?

Questo contributo fornisce una logica di prioritizzazione pratica per IT management, direzione IT, compliance e responsabili security. Al centro ci sono gli impatti su esercizio, amministrazione, flussi di dati, interfacce, manutenzione e processi di segnalazione – con ausili decisionali concreti, checklist e prove valide per evidenze.

Cosa NIS2 significa realmente a livello architetttonico (senza artifizi giuridici)

NIS2 richiede misure tecniche e organizzative “adeguate” per la gestione del rischio e della sicurezza. Tradotto in termini architetturali: la vostra IT deve essere controllabile in base al rischio e dimostrabilmente operativa. È più di qualche nuova direttiva.

Dal punto di vista architetturale emergono quattro requisiti stringenti, quasi sempre sottostimati:

• Rilevabilità: Dovete vedere tempestivamente gli eventi rilevanti per la sicurezza (logging, monitoring, allerta). Senza telemetria, la gestione degli incidenti diventa un esercizio di tentativi.
• Contenibilità: Un incidente non deve propagarsi in modo incontrollato (segmentazione, controlli di identità, principio del minimo privilegio). Reti „piatte“ e diritti amministrativi ampiamente distribuiti sono un moltiplicatore di rischio.
• Ripristinabilità: Dopo un incidente conta la capacità di ripristinare i servizi in modo coerente (backup, RTO/RPO, test di ripristino). La sola esistenza di backup senza prove di RESTore è di scarso valore in audit.
• Gestibilità e evidenza: I controlli devono essere integrati nell’esercizio e nei processi di change (governance, responsabilità, evidenze). Misure ad hoc senza chiara responsabilità falliscono nella pratica quotidiana.

Importante: NIS2 non premia la «più bella architettura target». Conta avere controlli efficaci e operativi e la capacità di motivare le decisioni in base al rischio – inclusi i rischi residui accettati consapevolmente.

Prioritizzare invece di parallelizzare: un modello di controllo NIS2 efficace per l’architettura IT

Molti programmi falliscono perché si avvia tutto contemporaneamente: nuovo SIEM, nuove zone di rete, nuovo IAM, nuova piattaforma di backup, nuove policy. Risultato: costi elevati, molti cantieri aperti, ma poca riduzione del rischio misurabile.

Per la prioritizzazione dei controlli tecnici si è dimostrato efficace un modello semplice: ogni controllo viene valutato in base a leva di efficacia, dipendenze e conseguenze operative.

1) Leva di efficacia: quale controllo riduce immediatamente la portata del danno?

Domande per la valutazione:

• Il controllo impedisce l’accesso iniziale (p. es. MFA, hardening), limita la diffusione (segmentazione) o accelera la risposta (logging / IR)?
• Agisce in modo esteso su molti sistemi (p. es. identità centrale) o solo in modo puntuale?

2) Dipendenze: cosa deve essere stabile prima?

Dipendenze tipiche sono identità, trasparenza degli asset e standardizzazione. Senza inventario (asset, account, flussi di dati) ogni programma RESTa pieno di buchi: proteggete ciò che conoscete – e trascurate shadow IT, interfacce legacy o account amministrativi dimenticati.

3) Conseguenze operative: come modifica il controllo la quotidianità?

Un controllo è compatibile con NIS2 solo se viene accettato in esercizio, è amministrabile e documentabile. Troppo spesso una misura viene introdotta tecnicamente senza chiarire runbooks (istruzioni operative), percorsi di escalation e permessi di ruolo. Nell’audit non si domanda più “Avete X?”, ma “Come garantite che X produca effetto in modo duraturo?”

Le Top-Controls che devono essere collocate prima a livello architetturale

L’ordine seguente non è un’interpretazione legale, ma una logica di implementazione collaudata: prima i controlli ad alto impatto e bassa complessità, poi le modifiche strutturali.

1) Identità come perimetro di sicurezza: MFA, Conditional Access e progettazione pulita degli account

Quando gli aggressori riescono nelle infrastrutture aziendali, lo fanno spesso sfruttando le identità: password rubate, session-token, OAuth-app, account amministrativi non adeguatamente separati o mancanza di distinzione tra diritti utente e di amministrazione. Conseguenza architetturale: Identity & Access Management (IAM) diventa il perimetro.

Decisioni prioritarie:

• MFA (autenticazione multi-fattore) ovunque conti: in particolare per accessi admin, VPN/remote, posta elettronica, portale SSO e applicazioni business critiche.
• Separazione delle identità: gli account utente normali non devono essere anche amministratori. Gli account admin devono avere policy più rigorose (MFA, durate di sessione più stringenti, nessuna casella e-mail, nessuna navigazione).
• Conditional Access / regole contestuali: accesso basato sullo stato del dispositivo, sulla posizione e sui segnali di rischio. Così si riduce il “la password basta” come punto unico di guasto.

Compromesso accettabile: se non tutte le applicazioni supportano immediatamente MFA, iniziate dal punto d’ingresso centrale (SSO, VPN, interfacce admin) e definite per le eccezioni una regola transitoria documentata (es. percorso di accesso isolato, RESTrizioni di rete aggiuntive, data di scadenza). Inaccettabile invece è “MFA più tardi” senza una misura di controllo alternativa.

2) Privileged Access Management (PAM) e “Least Privilege” come standard operativo

PAM significa: gli accessi privilegiati (diritti di amministratore) sono controllati, limitati nel tempo, tracciabili e idealmente protetti con meccanismi separati. “Least Privilege” vuol dire: ogni account dispone solo dei diritti necessari al proprio compito — non di più.

Impatto architetturale: serve un modello chiaro per i percorsi admin (Windows, Linux, rete, Cloud, SaaS) e una strategia per i service account (account tecnici), spesso trascurati.

Un approccio pragmatico per iniziare, se PAM non può essere implementato in modalità “Big Bang”:

• Inventario degli account privilegiati (Domain Admins, amministratori locali, Cloud-Admins, Break-Glass-Accounts).
• Just-in-Time/Just-Enough-Access per i gruppi admin più critici (autorizzazioni temporanee, ruoli invece di permessi individuali).

Prospettiva di audit: i verificatori si concentrano sulla domanda se le azioni privilegiate siano tracciabili e autorizzate. Non si tratta tanto del nome di uno strumento, quanto della prova: processo, modello di ruoli, evidenze di log.

3) Logging, sincronizzazione temporale centrale e rilevamento: senza telemetria nessuna reazione conforme a NIS2

NIS2 riguarda Incident Response e processi di notifica. Indipendentemente da scadenze specifiche vale: dovete essere in grado di rilevare e valutare gli incidenti. Tecnicamente questo significa: gestione centralizzata dei log (spesso SIEM, cioè Security Information and Event Management) più chiare sorgenti di log.

Architettura minima per una detection affidabile:

• Sincronizzazione temporale (NTP): se i sistemi hanno orari diversi, correlazione e ricostruzione forense sono quasi impossibili.
• Pipeline di log: trasmissione sicura, buffering in caso di guasti, conservazione definita (Retention) e protezione degli accessi.
• Sorgenti di log prioritarie: Identity Provider, e-mail, VPN, strumenti di amministrazione, Domain Controller, EDR/AV, applicazioni business centrali, Proxy/DNS, firewall.
• Casi d’uso invece di rumore di dati: pochi ma efficaci allarmi (es. ruoli amministrativi sospetti, luoghi di accesso insoliti, esportazioni massive, disattivazione di agenti di protezione).

Compromesso accettabile: se l’introduzione di un SIEM è complessa, iniziate con inoltro centrale dei log e pochi casi d’uso, ma con responsabilità chiare (chi reagisce a quale allarme, entro quale tempo). Inaccettabile è “registriamo tutto” senza analisi e senza runbook per gli allarmi.

4) Gestione delle vulnerabilità e capacità di patch: trasparenza degli asset batte funzionalità dello strumento

Vulnerability Management non è solo scansione, ma la capacità di chiudere le vulnerabilità. Decisivi per l’architettura sono standardizzazione, finestre di manutenzione, dipendenze e controllo delle modifiche.

Logica di priorità che funzioni in esercizio:

• Inventario degli asset come base: sistemi, sistemi operativi, applicazioni, versioni, responsabili, criticità.
• Classi di patch: aggiornamenti di sicurezza critici (rapidi), aggiornamenti regolari (pianificati), eccezioni legacy (controlli compensativi).
• SLA per criticità: non un gioco di numeri, ma una decisione: quali sistemi devono essere più rapidi, perché l’impatto è maggiore?

Per gli audit conta in particolare la prova: report di scansione, flussi di lavoro dei ticket, elenchi di eccezioni con motivazione e ciclo di revisione.

5) Backup, copie immutabili e test di RESTore: architettura per il ripristino operativo invece che semplice archiviazione

I backup sono rilevanti per NIS2 perché resilienza e recupero sono elementi centrali. In molte realtà esistono backup, ma non test di RESTore affidabili. Questo si paga durante un incidente: non sapete se riuscirete davvero a tornare operativi.

Elementi architetturali da prioritizzare:

• RTO/RPO come leve di controllo: RTO (Recovery Time Objective) = tempo massimo tollerato per il ripristino operativo; RPO (Recovery Point Objective) = perdita massima di dati tollerata. Questi valori devono essere definiti per servizio e supportati tecnicamente.
• Copie immutabili/Write-Once: protezione contro ransomware che cifrano o eliminano i backup.
• Percorsi amministrativi separati: l’amministrazione dei backup deve essere particolarmente protetta (account amministrativi separati, MFA, accessi RESTrittivi).
• Esercitazioni di RESTore regolari: non solo ripristino di file, ma coerenza di applicazioni e database, incluse le dipendenze.

Compromesso accettabile: non tutti i servizi necessitano immediatamente di „nessuna perdita di dati“. Ma ogni servizio critico necessita di un percorso di riavvio testato e di un’operatività minima documentata. Inaccettabile è dichiarare RTO/RPO senza test o senza considerare dipendenze (z. B. DNS, IAM, certificati).

Adattare l’architettura IT per NIS2: segmentazione di rete e pragmatismo Zero Trust

La segmentazione di rete è una delle misure più efficaci per limitare i danni. Allo stesso tempo è tra le più onerose, sia organizzativamente che tecnicamente, perché rende visibili i flussi di dati, genera eccezioni e «smaschera» il paesaggio applicativo.

Un approccio pragmatico è intendere Zero Trust non come un prodotto ma come un principio: „Non fidarti di nessun segmento di rete per impostazione predefinita.“ In concreto significa: identità, stato del dispositivo e privilegi minimi governano l’accesso.

Livelli di segmentazione che si dimostrano efficaci in ambienti reali

• Livello 1 – Isolare gli asset critici: Domain Controller, servizi di identità, sistemi di backup, Admin-Jump-Hosts, cluster di database. Obiettivo: rendere più difficile il movimento laterale.
• Livello 2 – Limitare i flussi server-to-server: solo porte/protocolli necessari, whitelist documentate. Obiettivo: porre fine al „tutto può parlare con tutto“.
• Livello 3 – Segmentazione delle workload: separazione per applicazione/ambiente (Prod/Test), sensibilità e catena di fornitura (z. B. accessi di partner esterni).

Compromesso accettabile: se la microsegmentazione (molto fine) non è realizzabile a breve termine, zone grossolane più percorsi amministrativi rigorosi spesso forniscono il 70–80% dell’effetto. È importante che le eccezioni siano visibili (documentazione, data di scadenza, responsabile del rischio).

Acceptable Compromises: Welche Abkürzungen im NIS2-Programm vertretbar sind – und welche nicht

„Akzeptable Kompromisse“ non significa „facciamo meno sicurezza“. Significa: si scelgono stati intermedi che riducono il rischio e che possono essere ampliati in seguito senza ricostruire da zero. La distinzione è determinante per la pianificazione del budget e dei tempi.

Compromessi accettabili (con condizioni)

• MFA per fasi: prima gli accessi ad alto rischio, poi le altre applicazioni. Condizione: processi di deroga documentati e barriere aggiuntive per le eccezioni.
• SIEM in variante „Minimal-Use-Case“: pochi allarmi critici invece della copertura completa. Condizione: chiara ownership degli allarmi e tempi di risposta definiti.
• Segmentazione in zone invece della microsegmentazione: implementazione più rapida. Condizione: gli asset critici sono separati, i percorsi amministrativi sono induriti.
• Sistemi legacy con controlli compensativi: z. B. segmenti di rete isolati, accessi RESTrittivi, monitoraggio intensificato. Condizione: piano di uscita o accettazione del rischio con responsabilità nominata.

Compromessi non accettabili (trappole tipiche di audit)

• Responsabilità poco chiare: „Lo fa l’IT“ senza responsabile del sistema, responsabile dei dati, responsabile del controllo. Questo viene rilevato quasi sempre durante l’audit.
• „Il backup c’è“ senza evidenze di RESTore: particolarmente critico negli scenari di ransomware.
• Diritti amministrativi ampiamente distribuiti: amministratori locali, account condivisi, assenza di registrazione delle azioni privilegiate.
• Logging senza analisi: raccolta dei log senza correlazione, allarmi, runbook e ticket è operativamente inutile.

Governance e evidenze: come le decisioni architetturali diventano auditabili

NIS2 è vicino al management: contano decisioni, motivazioni dei rischi e prove. A livello tecnico ciò non significa „più carta“, ma evidence-by-design: ogni controllo centrale ha un responsabile, punti di misura e evidenze operative.

Un semplice modello di responsabilità dei controlli

• Responsabile del controllo: è responsabile dell’efficacia, delle policy, delle eccezioni e del reporting.
• Responsabile del sistema: è responsabile dell’implementazione nel sistema, della manutenzione e della documentazione tecnica.
• Responsabile del processo (es. change/incident): garantisce che i processi supportino i controlli.
• Responsabile del rischio (management): decide sui rischi residui e sulle eccezioni accettate.

Questi ruoli possono ricadere sulla stessa persona, ma devono essere nominati. Altrimenti si creano „zone grigie“ che diventano costose in caso di incidente o audit.

Checklist delle evidenze (logica dei modelli) per controlli tecnici

Per ogni controllo prioritario dovete strutturare almeno le seguenti evidenze:

• Ambito: quali sistemi/servizi sono coperti e quali no?
• Policy/Standard: cosa è vincolante (es. obbligo MFA, cicli di patch, retention dei log)?
• Prova di implementazione: estratto di configurazione, elenco sistemi, diagramma architetturale, record di change.
• Prova di efficacia: report/KPI di monitoraggio, campionamenti, statistiche degli allarmi, protocolli delle prove di RESTore.
• Eccezioni: motivazione, controlli compensatori, data di scadenza, approvazione.

Nota pratica: le evidenze non devono essere „belle“, ma coerenti. Meglio poche prove aggiornate regolarmente che un pacchetto di documenti creato una sola volta.

Logica di attuazione come roadmap: 90 giorni, 6 mesi, 12 mesi

Una roadmap aiuta a ordinare i controlli nelle loro dipendenze e a gestire le aspettative verso la direzione e i revisori. È importante che ogni fase produca risultati misurabili.

0–90 giorni: standard minimo stabile e trasparenza

• Inventario base di asset e account (sistemi critici, account admin, accessi esterni)
• MFA per admin, VPN/remote, e-mail/SSO
• Prime fonti di log centrali (identity, VPN, domain, EDR) + controllo NTP
• Mettere in sicurezza i percorsi di amministrazione del backup, prova di RESTore a campione per 1–2 servizi critici
• Avviare il processo di patch/vulnerabilità: priorità, processo di eccezione, prime segnalazioni

3–6 mesi: delimitazione e operatività

• Espansione PAM/Least-Privilege (ruoli, autorizzazioni a tempo limitato, registrazione)
• Segmentazione livello 1–2 (asset critici, admin-jump, flussi server)
• Estensione SIEM/casi d’uso, runbook di allarme e integrazione ticket
• Esercizi regolari di ripristino (incl. consistenza database/applicazioni)

6–12 mesi: indurimento, scalabilità, catena di fornitura

• Segmentazione livello 3 (carichi di lavoro, ambienti, accessi partner)
• Standardizzazione/baseline di hardening (es. linee guida simili a CIS come baseline interna)
• Controlli della catena di fornitura nell’architettura: accessi separati, revisione delle integrazioni di terze parti, registrazione
• Audit-readiness: automazione delle evidenze, report di management regolari

Conseguenze operative e costi: cosa la direzione IT deve pianificare realisticamente prima di prendere decisioni

I controlli tecnici spostano i carichi di lavoro. Una buona architettura riduce il rischio, ma genera anche nuovi compiti operativi. Se questi non vengono pianificati, l’efficacia viene compromessa dopo pochi mesi.

Tipici oneri operativi (spesso dimenticati)

• Gestione delle identità: eccezioni MFA, stati dei dispositivi, temi relativi a token/sessione, on-/offboarding.
• Gestione dei log: volume dei dati, costi di retention, parser/normalizzazione, qualità degli allarmi (false positive).
• Segmentazione: richieste di modifica, regole firewall, documentazione dei flussi dati, troubleshooting.
• Patching: finestre di manutenzione, test di regressione, coordinamento con le unità di business.
• Backup/Ripristino: esercizi regolari, gestione dei media/storage, gestione di chiavi e accessi.

Guida alla decisione: investite prima in misure che riducano il carico, perché portano standardizzazione (es. identity provider centrale, baseline, patching automatizzato). L’introduzione di strumenti senza integrazione nei processi aumenta il carico.

Prospettiva audit: quali domande pone il revisore – e come l’architettura risponde

Anche senza entrare nelle specifiche normative nazionali: nelle verifiche spesso emergono schemi simili. Potete prepararvi architettonicamente rendendo i vostri controlli verificabili in forma di „domanda-risposta“.

Domande tipiche di verifica che dovRESTe poter rispondere con evidenze

• „Come individuate gli incidenti di sicurezza?“ → fonti di log, allarmi, regolamento on-call, runbook per incidenti, esempi di incidenti gestiti.
• „Come limitate gli impatti?“ → segmentazione, PAM, separazione admin/utente, copertura EDR, policy di rete.
• „Come assicurate il ripristino?“ → RTO/RPO per servizio, architettura di backup, copie immutabili, protocolli di test di ripristino.
• „Come gestite eccezioni/legacy?“ → registro delle eccezioni, controlli compensativi, accettazione del rischio con i decisori.

Se desiderate approfondire: un contributo separato sulla audit-readiness può servire come standard interno per strutturare raccolte di evidenze e routine di reporting.

Checklist pratica: priorizzazione dei controlli tecnici per la vostra architettura NIS2

La lista seguente è adatta a un workshop con IT, security, compliance e service owner. L’obiettivo non è „tutto verde“, ma una prioritizzazione tracciabile con dipendenze chiare.

• Scope chiaro? servizi critici, classi di dati, dipendenze, integrazioni esterne
• Identità protetta? MFA per Admin/Remote/SSO, separazione dei ruoli, procedure Break-Glass regolate
• Privilegi controllati? Percorsi admin, registrazione, meccanismi JIT/JEA, account di servizio inventariati
• Telemetria disponibile? NTP, log centrali, casi d’allarme definiti, responsabilità (ownership) e runbook
• Capacità di patching presente? Inventario, classi di patch, processo per le eccezioni, report periodici
• Ripristino testato? RTO/RPO, esercitazioni di ripristino, backup immutabili, amministratore dei backup protetto
• Segmentazione avviata? asset critici isolati, Admin-Jump, flussi dei server documentati
• Processo di evidence stabilito? Control Owner, prove, eccezioni, cadenza di revisione

Template di esempio come blocchi sorgente copiabili (punto di partenza per policy e evidence)

I seguenti modelli sono volutamente tool-neutral. Sono adatti a stabilire uno standard interno e a raccogliere evidence in modo coerente.

TEMPLATE: Scheda del controllo (per NIS2-Evidence)

Control-ID:
Control-Name:
Obiettivo/Rischio che viene ridotto:
Ambito (sistemi/servizi):
Fuori ambito (con motivazione):
Control Owner:
System Owner(s):
Riferimento al processo (Change/Incident/Access):

Policy/Standard (sintesi):
Implementazione (tecnica/architetturale):
Processi operativi (runbook, on-call, escalation):
Punti di misura/KPI (es. copertura, tempo di reazione):
Fonti di evidence (report, log, ticket, protocolli):
Eccezioni (riferimento registro):
Ciclo di revisione (mensile/trimestrale):
Rischio residuo e decisione (Risk Owner, data):

TEMPLATE: Registro delle eccezioni (controlli compensativi)

ID eccezione:
Sistema/servizio interessato:
Owner (sistema) / Risk Owner (management):
Motivo dell'eccezione (tecnico/aziendale):
Impatto del rischio (breve):
Controlli compensativi (es. segmentazione, monitoring, accesso RESTrittivo):
Evidence aggiuntiva (quali prove forniamo):
Data di scadenza / Data di revisione:
Decisione/Approvazione (nome, ruolo, data):
Piano di migrazione/uscita (se presente):

TEMPLATE: Runbook minimale per allarmi di sicurezza (SIEM/gestione log)

Nome allarme/Use-Case:
Trigger/Signalquelle:
Criteri di gravità:
Azioni iniziali (entro 15/30/60 minuti):
- Cosa verificare?
- Quali log/fonti?
- Quali sistemi isolare?
Comunicazione:
- Chi viene informato?
- Quando escalation a management/compliance?
Documentazione:
- Ticket/Incident-ID
- Timestamp (inizio/fine)
- Azioni e risultato
Decisione:
- Falso positivo? Motivazione.
- Incident? Classificazione.
Lezioni apprese:
- Quale controllo/regola adeguare?

Conclusione: L’architettura NIS2 è una sequenza di decisioni – non un carrello della spesa

Quando adattate la vostra architettura IT per NIS2, non si tratta tanto di “più tecnologia di sicurezza”, quanto di punti di controllo efficaci che funzionino nella pratica: identità come perimetro, privilegi controllati, telemetria affidabile, standard patchabili, ripristino testato e una segmentazione che limiti la propagazione. La differenza decisiva tra azione estemporanea e programma è una chiara prioritizzazione – oltre a una gestione delle eccezioni che renda visibili i rischi residui e che sia decisa a livello di management.

Chi applica questa logica in modo coerente ottiene due risultati: un rischio di incidenti misurabilmente ridotto e una storia di audit che non si basa su slide, ma sull’operatività e sulle evidence.

Per questo tema sono altresì importanti le misure tecniche NIS2 e la prioritizzazione dei controlli di sicurezza. Il contributo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.