Governance dell’accesso remoto sicuro e delle VPN per NIS2 e DORA
Alle 07:42 di un lunedì mattina, Maria, Responsabile della sicurezza delle informazioni di un fornitore SaaS FinTech in rapida crescita, riceve tre messaggi prima del caffè.
Il primo arriva dal SOC: un account VPN appartenente a un ingegnere del supporto si è autenticato da un Paese in cui l’azienda non ha personale. Il secondo arriva dalle vendite: un cliente del settore finanziario chiede evidenze che tutti gli accessi remoti privilegiati siano protetti da MFA, registrati, segmentati e riesaminati nell’ambito di controlli del rischio ICT allineati a DORA. Il terzo arriva dall’ufficio legale: lo stesso evento potrebbe riguardare l’accesso a dati personali, quindi il DPO vuole capire se le evidenze per GDPR Article 32 siano sufficientemente complete da dimostrare misure tecniche e organizzative adeguate.
Non è ancora esploso nulla. Nessuna nota di ransomware. Nessuna esfiltrazione confermata. Nessuna indisponibilità per i clienti.
Ma Maria conosce la verità scomoda. Se la governance dell’accesso remoto è debole, ogni conversazione sulla conformità diventa difensiva. Un accesso VPN diventa una questione di igiene informatica ai fini NIS2. Un account di un collaboratore esterno diventa una questione di rischio ICT di terze parti ai fini DORA. Una sessione di desktop remoto in un ambiente cliente diventa una questione di sicurezza del trattamento ai fini GDPR. Un log mancante diventa una risultanza di audit.
Il rapporto di audit esterno già sulla sua scrivania peggiora la situazione. Gli auditor non hanno individuato un attacco zero-day sofisticato. Hanno trovato account condivisi di collaboratori esterni, autenticazione a più fattori applicata in modo incoerente, gruppi VPN legacy, eccezioni non gestite e gigabyte di log troppo rumorosi per supportare un’indagine. Era debito tecnico trasformato in esposizione regolatoria.
Nel 2026, la governance dell’accesso remoto sicuro e delle VPN non è un tema circoscritto di sicurezza della rete. È un sistema di controllo a livello di organo di gestione che collega identità, sicurezza degli endpoint, accesso dei fornitori, gestione delle vulnerabilità, logging, risposta agli incidenti, responsabilizzazione in materia di privacy e resilienza operativa.
Il problema dell’accesso remoto è cambiato
Alcuni anni fa, la governance dell’accesso remoto spesso si riduceva a una risposta semplice: “abbiamo una VPN”. Questa risposta non regge più a un esame serio.
Un ambiente moderno di accesso remoto può includere concentratori VPN aziendali, gateway Zero Trust Network Access, jump host per la gestione degli accessi privilegiati (PAM), host bastion per l’amministrazione cloud, infrastrutture desktop remote, tunnel di manutenzione dei fornitori, accesso di fornitori di servizi gestiti, account di emergenza, portali amministrativi SaaS, accesso degli sviluppatori all’ambiente di produzione, dispositivi mobili, reti domestiche, Wi‑Fi pubblico ed eccezioni BYOD.
Ogni percorso può diventare un punto di evidenza regolatoria.
NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate. Queste includono analisi dei rischi e politiche di sicurezza dei sistemi informativi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e manutenzione sicure, gestione delle vulnerabilità, politiche per valutare l’efficacia della cibersicurezza, igiene informatica, formazione in materia di cibersicurezza, crittografia e cifratura ove pertinenti, sicurezza delle risorse umane, politiche di controllo degli accessi, gestione degli asset, autenticazione a più fattori o autenticazione continua ove appropriato, comunicazioni protette e comunicazioni di emergenza protette.
DORA richiede agli enti finanziari di mantenere quadri documentati di gestione del rischio ICT, processi per gli incidenti ICT, test di resilienza operativa digitale e governance del rischio ICT di terze parti. DORA Article 5 attribuisce all’organo di gestione la responsabilità di definire, approvare, sovrintendere e mantenere la responsabilità della gestione del rischio ICT. Article 28 richiede che il rischio ICT di terze parti sia gestito come parte integrante di tale quadro.
GDPR Article 32 richiede misure tecniche e organizzative adeguate per la sicurezza del trattamento, incluse riservatezza, integrità, disponibilità, resilienza, capacità di ripristino, test e capacità di dimostrare che i dati personali sono protetti da accesso non autorizzato, perdita, alterazione o divulgazione.
Il problema del CISO non è stabilire se la VPN funzioni. La vera domanda è se l’organizzazione possa dimostrare che l’accesso remoto è governato, valutato in base al rischio, approvato, configurato in modo sicuro, monitorato, riesaminato, testato e integrato nella risposta agli incidenti.
È qui che ISO/IEC 27001:2022 diventa utile. Non tratta la VPN come un apparato isolato. Colloca l’accesso remoto all’interno del SGSI: campo di applicazione, parti interessate, valutazione del rischio, selezione dei controlli, pianificazione operativa, gestione dei fornitori, audit interno, riesame della direzione e miglioramento continuo.
Parti dal campo di applicazione del SGSI, non dalla regola del firewall
Quando Clarysec riesamina la governance dell’accesso remoto, non inizia chiedendo uno screenshot della configurazione VPN. Parte dal perimetro del SGSI.
ISO/IEC 27001:2022 richiede all’organizzazione di definire il proprio contesto, le parti interessate, i requisiti e il campo di applicazione del SGSI, incluse interfacce e dipendenze con altre organizzazioni. Per l’accesso remoto, il campo di applicazione deve includere esplicitamente persone, sistemi, fornitori e servizi di rete che rendono possibile il lavoro da remoto.
Un’organizzazione SaaS o FinTech dovrebbe identificare:
- Dipendenti che accedono da remoto ai sistemi di produzione
- Collaboratori esterni e sviluppatori con privilegi di amministrazione remota
- MSP, MSSP e altri fornitori con accesso operativo
- Personale di supporto clienti che accede ai dati dei tenant
- Utenti delle funzioni finanza, HR e legale che accedono da remoto a dati personali
- Console cloud e API di gestione remota
- Piattaforme VPN, ZTNA, provider di identità e gestione degli endpoint
- Log, integrazioni SIEM e ubicazioni di conservazione
- Eccezioni di accesso remoto e procedure di accesso di emergenza
- Dispositivi edge gestiti dai fornitori e strumenti di supporto remoto
È più di un semplice esercizio documentale. Il campo di applicazione NIS2 può includere provider cloud, data center, MSP, MSSP, fornitori di comunicazioni elettroniche, fornitori di infrastrutture digitali e fornitori di gestione dei servizi ICT, a seconda di dimensione, settore e designazione. DORA si applica agli enti finanziari e opera come regime settoriale specifico per il rischio ICT di tali enti. GDPR può applicarsi a organizzazioni UE e non UE quando il trattamento riguarda persone nell’UE, stabilimenti nell’UE, servizi offerti a persone nell’Unione o monitoraggio del comportamento.
Se il campo di applicazione del tuo SGSI ignora l’accesso remoto di terze parti, l’amministrazione remota, l’infrastruttura VPN o la connettività gestita dai fornitori, il set di controlli potrebbe essere incompleto prima ancora che l’auditor inizi il campionamento.
Costruisci uno stack di controlli per l’accesso remoto
Un programma solido di accesso remoto deve essere costruito come uno stack di controlli, non come una singola politica. Nei progetti di implementazione Clarysec, i controlli principali ISO/IEC 27002:2022 includono in genere:
- 6.7 Lavoro da remoto
- 5.15 Controllo degli accessi
- 5.16 Gestione delle identità
- 5.17 Informazioni di autenticazione
- 5.18 Diritti di accesso
- 8.5 Autenticazione sicura
- 8.1 Dispositivi endpoint degli utenti
- 8.8 Gestione delle vulnerabilità tecniche
- 8.9 Gestione della configurazione
- 8.15 Logging
- 8.16 Attività di monitoraggio
- 8.20 Sicurezza della rete
- 8.22 Segregazione delle reti
- 5.19 Sicurezza delle informazioni nei rapporti con i fornitori
- 5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitori
- 5.21 Gestione della sicurezza delle informazioni nella catena di fornitura ICT
- 5.22 Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori
- 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud
- 5.24 Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni
- 5.26 Risposta agli incidenti di sicurezza delle informazioni
- 5.28 Raccolta delle evidenze
- 5.30 Prontezza ICT per la continuità operativa
Zenith Controls: la guida alla conformità trasversale mappa Lavoro da remoto 6.7 come controllo preventivo a supporto di riservatezza, integrità e disponibilità, con collegamenti operativi alla gestione degli asset, alla protezione delle informazioni, alla sicurezza fisica e alla sicurezza dei sistemi e della rete. Collega inoltre Lavoro da remoto a Sicurezza degli asset fuori sede 7.9, Dispositivi endpoint degli utenti 8.1, Sensibilizzazione, istruzione e formazione sulla sicurezza delle informazioni 6.3, Trasferimento delle informazioni 5.14, Sicurezza della rete 8.20, Segregazione delle reti 8.22, Scrivania pulita e schermo bloccato 7.7 e Prontezza ICT per la continuità operativa 5.30.
Questa relazione è importante. Un requisito VPN senza gestione degli endpoint non protegge da un laptop rubato. MFA senza logging non supporta l’indagine. L’accesso dei fornitori senza segmentazione aumenta il raggio d’impatto. Il lavoro da remoto senza segnalazione degli incidenti ritarda il contenimento.
| Rischio di accesso remoto | Focus dei controlli ISO/IEC 27002:2022 | Evidenze attese dagli auditor |
|---|---|---|
| Credenziali rubate utilizzate tramite VPN | 8.5 Autenticazione sicura, 5.15 Controllo degli accessi, 5.17 Informazioni di autenticazione | Configurazione MFA, regole di accesso condizionale, avvisi su accessi non riusciti, log di autenticazione |
| Ex collaboratore esterno che mantiene l’accesso | 5.18 Diritti di accesso, 5.16 Gestione delle identità, controlli sui fornitori da 5.19 a 5.23 | Registrazioni del processo di ingresso, cambio ruolo e uscita, ticket di offboarding dei fornitori, evidenze del riesame degli accessi |
| Laptop compromesso che si connette da remoto | 8.1 Dispositivi endpoint degli utenti, 6.7 Lavoro da remoto, 8.8 Gestione delle vulnerabilità tecniche | Conformità MDM, stato EDR, evidenze di cifratura, report di patching |
| Dispositivo edge VPN non aggiornato | 8.8 Gestione delle vulnerabilità tecniche, 8.9 Gestione della configurazione, 8.20 Sicurezza della rete | Registrazione dell’asset, risultati delle scansioni, SLA di patching, approvazione dell’eccezione |
| Fornitore che usa un account remoto condiviso | 5.15 Controllo degli accessi, 5.16 Gestione delle identità, 8.5 Autenticazione sicura | ID utente univoci, account nominativi dei fornitori, log MFA, requisiti contrattuali |
| Sessione remota sospetta non ricostruibile | 8.15 Logging, 8.16 Attività di monitoraggio, 5.24 Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni | Log VPN, IP sorgente, durata della sessione, avvisi SIEM, cronologia dell’incidente |
Lo stack di controlli cambia la conversazione. Invece di discutere se “la VPN è conforme”, l’organizzazione crea un modello tracciabile: rischio di accesso remoto, controllo ISO, requisito della politica, implementazione tecnica, proprietario delle evidenze e cadenza di riesame.
Trasforma l’intento della politica in evidenze di audit
Gli auditor raramente accettano “di solito usiamo MFA” come evidenza. Cercano requisiti formalmente approvati, controlli implementati e registrazioni che provino l’operatività.
Il toolkit di politiche Clarysec fornisce ai team un linguaggio preciso da adottare e adattare. La Politica di sicurezza della rete - PMI stabilisce nella clausola 5.5.1:
“L’accesso VPN deve richiedere l’autenticazione a più fattori (MFA) ed essere limitato al personale designato”
La stessa politica per PMI trasforma il logging in un requisito di conservazione nella clausola 6.3.3:
“L’accesso tramite VPN deve essere registrato, conservando la durata delle sessioni e gli indirizzi IP sorgente per un minimo di 6 mesi”
Per il comportamento nel lavoro da remoto, la Politica di lavoro da remoto - PMI stabilisce nella clausola 5.2.3:
“Il Wi‑Fi pubblico può essere utilizzato solo quando è attivo un tunnel sicuro (VPN).”
Per gli ambienti enterprise, la Politica di lavoro da remoto è ancora più diretta. La clausola 5.2.1.1 richiede al personale di:
“Utilizzare la VPN approvata dall’azienda o l’infrastruttura desktop remota”
La clausola 5.2.1.2 richiede alle organizzazioni di:
“Richiedere l’autenticazione a più fattori (MFA) per tutti i tentativi di accesso”
La Politica di sicurezza della rete allinea la baseline tecnica con la clausola 6.3.1:
“Tutti gli accessi remoti devono essere cifrati, ad esempio tramite IPsec o SSL VPN, e richiedere l’autenticazione a più fattori (MFA).”
La Politica di controllo degli accessi stabilisce nella clausola 5.6.1:
“Gli eventi di accesso devono essere registrati e conservati in conformità alla Politica di registrazione e monitoraggio.”
Per i fornitori, la Politica di sicurezza di terze parti e fornitori richiede nella clausola 6.3.2:
“Tutti gli accessi di terze parti devono essere registrati e monitorati e, ove fattibile, segmentati tramite host bastion, VPN o gateway Zero Trust.”
La Politica di gestione delle vulnerabilità e delle patch - PMI stabilisce nella clausola 6.5.1:
“I sistemi che trattano dati personali, forniscono accesso remoto o sono esposti esternamente devono avere priorità per scansioni e aggiornamenti”
Queste clausole diventano efficaci quando sono collegate alle evidenze operative. La politica dice che MFA è obbligatoria. Il provider di identità prova l’applicazione. Il log VPN prova l’utilizzo. L’avviso SIEM prova il monitoraggio. Il riesame degli accessi prova la permanenza dell’esigenza aziendale. Il report sulle vulnerabilità prova che il servizio di accesso remoto è prioritario. Il playbook dell’incidente prova la prontezza della risposta.
Questa è la differenza tra possedere una politica e far funzionare un controllo.
Le cinque domande a cui ogni CISO dovrebbe rispondere
Il modello Clarysec per la governance dell’accesso remoto è costruito attorno a cinque domande valide per gli audit ISO 27001, la preparazione a NIS2, i riesami del rischio ICT DORA e i pacchetti di evidenze per GDPR Article 32.
1. Chi è autorizzato a connettersi da remoto?
L’accesso remoto deve essere limitato a utenti, ruoli e fornitori autorizzati. ISO/IEC 27002:2022 Controllo degli accessi 5.15, Gestione delle identità 5.16 e Diritti di accesso 5.18 definiscono la base di governance.
Zenith Controls mappa Controllo degli accessi 5.15 come controllo preventivo focalizzato sulla gestione delle identità e degli accessi (IAM). Collega il controllo a Gestione delle identità, Diritti di accesso, Informazioni di autenticazione, Dispositivi endpoint degli utenti, Autenticazione sicura e conformità alle politiche. In pratica, una politica di accesso è credibile solo se le identità sono univoche, gestite lungo il ciclo di vita, autenticate e riesaminate.
Una buona registrazione dell’accesso remoto dovrebbe rispondere a queste domande:
- Quale persona o fornitore ha accesso?
- Quali sistemi può raggiungere?
- Quale ruolo o contratto giustifica l’accesso?
- Chi lo ha approvato?
- MFA è applicata?
- Quando è stato riesaminato l’accesso per l’ultima volta?
- Quando scade l’accesso temporaneo?
- Quale fonte di log prova l’utilizzo?
Questo supporta anche gli esiti PR.AA del NIST Cybersecurity Framework 2.0 per gestione delle identità, autenticazione, autorizzazione, principio del privilegio minimo e separazione dei compiti.
2. Quale postura di sicurezza del dispositivo e della rete è richiesta?
L’accesso remoto dovrebbe dipendere dall’affidabilità del dispositivo, non solo dalle credenziali dell’utente. Una password valida e un’approvazione MFA da un dispositivo non gestito, infetto o non aggiornato rimangono un rischio elevato.
Zenith Blueprint: la roadmap in 30 passi per l’auditor lo spiega nella fase Controls in Action, Step 16, People Controls II:
“Ai lavoratori da remoto dovrebbe essere richiesto di usare solo dispositivi approvati dall’azienda, configurati dall’IT con cifratura completa del disco, protezione degli endpoint attiva, applicazione automatica delle patch e timeout di blocco dello schermo obbligatori.”
Lo stesso step sottolinea che l’accesso remoto dovrebbe passare attraverso la VPN aziendale, idealmente protetta da MFA, e che il BYOD dovrebbe essere vietato o consentito solo a condizioni rigorose, come registrazione MDM, containerizzazione e cancellazione remota.
È qui che convergono Dispositivi endpoint degli utenti 8.1, Lavoro da remoto 6.7, Gestione delle vulnerabilità tecniche 8.8, Gestione della configurazione 8.9 e Sicurezza della rete 8.20.
Per GDPR Article 32, la postura di sicurezza del dispositivo è rilevante perché gli endpoint remoti fanno parte delle misure tecniche e organizzative che proteggono i dati personali. Per DORA, la postura di sicurezza degli endpoint supporta la gestione del rischio ICT e la resilienza operativa. Per NIS2, supporta igiene informatica, controllo degli accessi, gestione degli asset e gestione delle vulnerabilità.
3. Come viene protetta la sessione?
Una sessione di accesso remoto sicura dovrebbe usare trasporto cifrato, autenticazione forte, segmentazione e percorsi amministrativi controllati.
Zenith Blueprint, fase di Gestione del rischio, Step 14, Politiche di trattamento del rischio e riferimenti regolatori incrociati, definisce l’aspettativa per l’accesso remoto:
“Tutti gli accessi remoti ai sistemi interni devono usare una VPN sicura o una connessione cifrata equivalente. L’autenticazione a più fattori (MFA) è richiesta per l’accesso remoto alle reti aziendali.”
Lo Step 20, Controlli da 8.18 a 8.26, indica alle organizzazioni di convalidare la sicurezza dei servizi di rete elencando tutti i servizi di rete interni ed esterni, come DNS, VPN, SMTP, DHCP e gateway API, confermando i protocolli sicuri, riesaminando i controlli di accesso e verificando le clausole di sicurezza di terze parti quando i servizi sono gestiti esternamente.
Una VPN non è solo un dispositivo. È un servizio di rete con scelte di protocollo, restrizioni di accesso, certificati, percorsi firewall, dipendenze da terze parti, requisiti di patching e log.
4. Come viene monitorato e investigato l’accesso?
La governance dell’accesso remoto deve includere logging e monitoraggio. NIS2 Article 23 stabilisce aspettative di segnalazione per fasi per gli incidenti significativi, inclusi preallarme entro 24 ore, notifica dell’incidente entro 72 ore e rapporto finale entro un mese. DORA richiede agli enti finanziari di rilevare, gestire, classificare, segnalare tramite escalation e notificare gli incidenti ICT rilevanti, includendo analisi della causa radice e comunicazioni quando sono coinvolti gli interessi finanziari dei clienti. L’analisi delle violazioni ai fini GDPR dipende dalla comprensione del fatto che dati personali siano stati accessibili, alterati, divulgati, persi o altrimenti compromessi.
Senza log di accesso remoto, l’organizzazione non può rispondere con sicurezza alla prima domanda del regolatore: che cosa è successo?
Un logging solido dovrebbe acquisire identità dell’utente, esito dell’autenticazione, IP sorgente, geolocalizzazione ove appropriato, identità del dispositivo, servizio di destinazione, azione privilegiata, durata della sessione, tentativi non riusciti, modifiche amministrative e correlazione con eventi degli endpoint e delle identità.
5. Come vengono gestite eccezioni e vulnerabilità?
L’infrastruttura di accesso remoto è ad alto valore. Gateway VPN, apparati ZTNA, provider di identità, host bastion e servizi desktop remoti dovrebbero rientrare tra gli asset gestiti con maggiore priorità nel programma di gestione delle vulnerabilità.
Un processo maturo di gestione delle eccezioni dovrebbe includere proprietario dell’asset, servizio di accesso remoto interessato, gravità della vulnerabilità, sfruttabilità, esposizione dei dati, controlli compensativi temporanei, approvazione del Proprietario del rischio, data di scadenza, evidenze di nuovo test e collegamento al Registro dei rischi e al Piano di trattamento del rischio.
Per ISO/IEC 27001:2022, ciò supporta trattamento del rischio, controllo operativo e miglioramento continuo. Per DORA, supporta gestione del rischio ICT, test e azioni correttive. Per NIS2, supporta gestione delle vulnerabilità e azione correttiva senza indebito ritardo. Per GDPR, aiuta a dimostrare che la sicurezza del trattamento era basata sul rischio e non gestita ad hoc.
L’accesso remoto dei fornitori è la trappola nascosta degli audit
Molti fallimenti dell’accesso remoto non sono fallimenti dei dipendenti. Sono fallimenti della governance dei fornitori.
Un MSP ha un vecchio account VPN. Un fornitore software usa una credenziale condivisa. Un partner di supporto si connette tramite desktop remoto per risolvere un problema con impatto sul cliente. Un provider cloud gestisce il gateway di accesso remoto. Un collaboratore esterno conserva l’accesso dopo la chiusura del progetto.
DORA è particolarmente severo su questo punto. Article 28 richiede agli enti finanziari di gestire il rischio ICT di terze parti come parte del quadro di gestione del rischio ICT e di restare pienamente responsabili anche quando i servizi ICT sono esternalizzati. Si aspetta registri degli accordi contrattuali ICT, due diligence, standard di sicurezza delle informazioni, diritti di audit e ispezione, diritti di risoluzione, analisi del rischio di concentrazione e strategie di uscita per funzioni critiche o importanti. Article 30 specifica disposizioni contrattuali quali protezione dei dati, livelli di servizio, luoghi del trattamento, accesso e ripristino dei dati, assistenza durante gli incidenti, cooperazione con le autorità, misure di sicurezza, diritti di audit e supporto all’uscita.
NIS2 Article 21 include anche sicurezza della catena di fornitura e rapporti con fornitori e prestatori di servizi, con attenzione alle vulnerabilità specifiche dei fornitori e alle pratiche di cibersicurezza dei fornitori.
NIST CSF 2.0 GV.SC fornisce un modello operativo pratico: strategia per il rischio della catena di fornitura, ruoli, criticità dei fornitori, requisiti contrattuali, due diligence, monitoraggio, partecipazione agli incidenti e attività post-rapporto.
Per i clienti Clarysec, la regola pratica è semplice: l’accesso remoto di terze parti deve essere trattato come accesso privilegiato salvo prova contraria. Deve essere nominativo, approvato, limitato nel tempo, protetto da MFA, registrato, monitorato e segmentato.
Mappatura di conformità trasversale: un solo sistema di controllo, molti obblighi
La governance dell’accesso remoto è uno degli esempi più forti di conformità trasversale. Le stesse evidenze possono soddisfare più obblighi se progettate correttamente.
| Driver di conformità | Aspettativa sull’accesso remoto | Evidenze da mantenere |
|---|---|---|
| ISO/IEC 27001:2022 | Selezione dei controlli basata sul rischio, governance degli accessi, controllo dei fornitori, evidenze operative e miglioramento continuo | Valutazione del rischio, Dichiarazione di Applicabilità, politiche, riesame degli accessi, log, risultanze dell’audit interno |
| NIS2 | Igiene informatica, controllo degli accessi, gestione degli asset, MFA ove appropriato, gestione degli incidenti, continuità operativa e sicurezza della catena di fornitura | Registrazioni MFA, formazione sull’igiene informatica, controlli sugli accessi dei fornitori, rapporti sugli incidenti, azioni correttive |
| DORA | Governance del rischio ICT, autenticazione forte, ciclo di vita dell’incidente, test di resilienza, rischio ICT di terze parti e responsabilità dell’organo di gestione | Registro dei rischi ICT, test dell’accesso remoto, classificazioni degli incidenti, registri dei fornitori, piani di uscita, diritti di audit |
| GDPR Article 32 | Sicurezza del trattamento adeguata, riservatezza, integrità, disponibilità, resilienza, test e responsabilizzazione | Log degli accessi, evidenze di cifratura, applicazione MFA, registrazioni della valutazione della violazione, risultati dei test |
| NIST CSF 2.0 | Esiti Govern, Identify, Protect, Detect, Respond e Recover | Profili Current e Target, inventario degli asset, controlli di identità PR.AA, monitoraggio DE.CM, analisi RS.AN |
| COBIT 2019 e assurance ISACA | Obiettivi di governance, pratiche di gestione, progettazione dei controlli ed efficacia operativa | RACI, titolarità del processo, metriche di prestazione dei controlli, traccia di audit, tracciamento delle azioni correttive |
Una mappatura più dettagliata dei controlli ISO mostra perché la governance dell’accesso remoto produce così tanto valore di conformità.
| Controllo ISO/IEC 27002:2022 | Allineamento NIS2 | Allineamento DORA | Evidenze per GDPR Article 32 |
|---|---|---|---|
| 6.7 Lavoro da remoto | Supporta Article 21 su igiene informatica, controllo degli accessi e pratiche di lavoro sicure | Supporta politiche e procedure ICT per il lavoro da remoto e la resilienza operativa | Dimostra misure organizzative per il personale che tratta dati personali fuori dall’ufficio |
| 8.5 Autenticazione sicura | Supporta Article 21(2)(j) sull’autenticazione a più fattori o continua ove appropriato | Supporta le aspettative di autenticazione forte nell’ambito delle misure di protezione e prevenzione ICT | Dimostra una misura tecnica per ridurre l’accesso non autorizzato ai dati personali |
| 8.20 Sicurezza della rete | Supporta comunicazioni sicure, cifratura e protezione dei servizi di rete | Supporta la protezione da intrusioni, uso improprio e accesso ICT non autorizzato | Dimostra la protezione dei dati in transito e percorsi di rete controllati |
| 8.22 Segregazione delle reti | Supporta la limitazione dell’impatto e l’applicazione dei confini del controllo degli accessi | Supporta resilienza e contenimento per funzioni critiche o importanti | Riduce l’esposizione dei dati personali limitando i sistemi raggiungibili |
| Controlli sui fornitori da 5.19 a 5.23 | Supporta Article 21(2)(d) sulla sicurezza della catena di fornitura | Supporta Articles 28 e 30 sul rischio ICT di terze parti e sulla governance contrattuale | Supporta la responsabilizzazione di responsabili del trattamento e fornitori per l’accesso sicuro |
| 8.15 Logging e 8.16 Attività di monitoraggio | Supporta gestione degli incidenti e valutazione dell’efficacia | Supporta rilevazione, classificazione, escalation e segnalazione degli incidenti ICT | Supporta valutazione della violazione ed evidenza forense |
| 8.8 Gestione delle vulnerabilità tecniche | Supporta manutenzione sicura e gestione delle vulnerabilità | Supporta riduzione del rischio ICT, test e azioni correttive | Dimostra la protezione basata sul rischio dei sistemi che trattano dati personali |
NIS2 introduce anche una responsabilità esplicita della direzione. Article 20 richiede agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di gestione del rischio di cibersicurezza, sovrintenderne l’attuazione e seguire formazione. DORA Article 5 richiede analogamente all’organo di gestione degli enti finanziari di definire, approvare, sovrintendere e restare responsabile degli assetti di gestione del rischio ICT.
Il consiglio di amministrazione non deve approvare ogni regola del firewall. Deve però approvare la postura di rischio dell’accesso remoto: MFA obbligatoria, accesso dei fornitori registrato, accesso privilegiato segmentato, infrastruttura di accesso remoto aggiornata entro tempistiche definite, eccezioni limitate nel tempo e incidenti cyber segnalati tramite canali concordati.
Uno sprint di 90 minuti sulle evidenze dell’accesso remoto
Un modo pratico per far emergere le lacune è costruire un mini pacchetto di evidenze attorno a un percorso di accesso. Scegli un esempio, come “accesso VPN per gli ingegneri di supporto alla produzione”, quindi completa lo sprint seguente.
| Minuto | Attività | Output |
|---|---|---|
| 0-10 | Definire il percorso di accesso | Una frase che descrive chi si connette, da dove, a cosa e perché |
| 10-25 | Mappare le politiche applicabili | Clausole della Politica di lavoro da remoto, della Politica di sicurezza della rete, della Politica di controllo degli accessi e, se pertinente, della Politica di sicurezza dei fornitori |
| 25-40 | Acquisire l’applicazione tecnica | Screenshot o esportazioni che provano MFA, cifratura, appartenenza ai gruppi e accesso condizionale |
| 40-55 | Acquisire i log | Accesso riuscito recente, accesso non riuscito, IP sorgente, durata della sessione ed esempio di avviso SIEM |
| 55-70 | Riesaminare vulnerabilità e postura di sicurezza del dispositivo | Stato delle patch dell’asset VPN, report di conformità degli endpoint ed eccezioni aperte |
| 70-80 | Verificare le evidenze del riesame degli accessi | Ultimo riesame degli accessi, utenti rimossi, eccezioni approvate e approvazione formale del proprietario |
| 80-90 | Creare la narrativa di audit | Spiegazione di una pagina che mappa rischio, controllo, politica, implementazione ed evidenze |
L’obiettivo non è produrre carta. L’obiettivo è collegare la politica alla prova. Se il pacchetto di evidenze non può essere completato per un percorso di accesso, l’organizzazione ha individuato una reale lacuna di governance prima che la trovi l’auditor o il regolatore.
Questo esercizio si adatta anche al metodo dei Profili del NIST CSF 2.0: definire l’ambito del profilo, raccogliere politiche e requisiti, documentare esiti attuali e target, analizzare le lacune, creare un piano d’azione prioritizzato e implementare i miglioramenti.
Come gli auditor testeranno l’accesso remoto
Un audit dell’accesso remoto può apparire diverso a seconda del background dell’auditor. Zenith Controls aiuta le organizzazioni a prepararsi perché mappa le relazioni tra i controlli ISO/IEC 27002:2022 in una vista di conformità trasversale, invece che in una singola checklist.
| Prospettiva dell’auditor | Domanda probabile | Risposta solida |
|---|---|---|
| ISO 27001 | Perché avete selezionato questi controlli di accesso remoto? | Valutazione del rischio, giustificazione nella SoA, piano di trattamento e mappatura delle politiche |
| NIST CSF 2.0 | Qual è il vostro stato attuale e target? | Profilo, analisi delle lacune, piano d’azione prioritizzato e miglioramenti implementati |
| COBIT 2019 | Chi è responsabile della governance dell’accesso remoto? | RACI, proprietario del processo, riesame della direzione e metriche dei controlli |
| DORA | Come gestite l’accesso remoto ICT di terze parti? | Registro dei fornitori, due diligence, clausole contrattuali, diritti di audit e piano di uscita |
| GDPR | Potete provare che l’accesso ai dati personali era controllato? | MFA, principio del privilegio minimo, log, riesame degli accessi e registrazioni della valutazione della violazione |
Un’organizzazione pronta per l’audit non si affanna a raccogliere screenshot. Mantiene un sistema vivo di evidenze.
Risultanze comuni nel 2026
Nelle valutazioni, Clarysec osserva ripetutamente gli stessi problemi di accesso remoto:
- MFA è abilitata per i dipendenti ma non per fornitori, account di emergenza o profili VPN legacy
- I log di accesso remoto esistono ma non sono conservati abbastanza a lungo, centralizzati o collegati alle identità
- La conformità degli endpoint è gestita separatamente dall’accesso VPN, quindi dispositivi non gestiti possono ancora connettersi
- Il riesame degli accessi si concentra sulle applicazioni aziendali ma ignora gruppi VPN, autorizzazioni su host bastion e ruoli amministrativi cloud
- L’infrastruttura di accesso remoto manca dall’elenco di priorità delle vulnerabilità
- L’accesso dei fornitori è approvato informalmente e non riflesso nei contratti
- Le eccezioni non hanno data di scadenza, controllo compensativo o approvazione del Proprietario del rischio
- Gli account di emergenza non sono testati, monitorati o riesaminati
- Le sessioni privilegiate non sono segmentate dal traffico generale di accesso remoto
- I playbook di risposta agli incidenti non includono la raccolta delle evidenze di accesso remoto
Queste risultanze sono prevenibili. Di solito derivano da titolarità frammentata. I team di rete gestiscono la VPN. IAM gestisce MFA. IT gestisce i dispositivi. Procurement gestisce i contratti con i fornitori. La funzione legale gestisce le condizioni di trattamento dei dati. Il SOC gestisce gli avvisi. La conformità gestisce le evidenze di audit.
Il SGSI deve collegarli.
Il modello operativo target per l’accesso remoto sicuro
Un modello maturo di governance dell’accesso remoto sicuro e delle VPN dovrebbe includere le seguenti pratiche operative:
- Mantenere un inventario di tutti i metodi di accesso remoto, inclusi VPN, ZTNA, RDP, host bastion, portali amministrativi SaaS e tunnel dei fornitori
- Richiedere MFA per tutti gli accessi remoti, inclusi fornitori, amministratori e account di emergenza
- Applicare la conformità del dispositivo prima dell’accesso, ove tecnicamente fattibile
- Usare segmentazione, host bastion o gateway Zero Trust per l’accesso privilegiato e di terze parti
- Registrare IP sorgente, identità dell’utente, esito dell’autenticazione, sistema di destinazione e durata della sessione
- Conservare i log secondo le esigenze di politica, regolamentazione e indagine
- Dare priorità ai sistemi di accesso remoto per scansioni di vulnerabilità e patching
- Riesaminare periodicamente i diritti di accesso e in caso di cambio ruolo, cessazione o modifica del contratto con il fornitore
- Limitare nel tempo l’accesso di emergenza, temporaneo e dei fornitori
- Includere l’accesso remoto nella risposta agli incidenti, nella valutazione delle violazioni e nelle esercitazioni di crisi
- Testare la resilienza dell’accesso remoto e i percorsi di accesso di backup ove richiesto per la continuità
- Integrare l’accesso remoto dei fornitori in contratti, due diligence, monitoraggio e pianificazione dell’uscita
- Riportare alla direzione metriche di rischio sull’accesso remoto
Per Maria, questo diventa un piano d’azione pratico. Nelle prime due settimane usa Zenith Blueprint per aggiornare i documenti di governance, allineare le politiche agli obblighi NIS2 e DORA e ottenere l’approvazione della direzione. Nel mese successivo, i suoi team IT e di sicurezza applicano MFA a tutti i profili di accesso remoto, segmentano l’accesso dei collaboratori esterni, ottimizzano il logging e danno priorità ai sistemi VPN e ZTNA per la correzione delle vulnerabilità. Su base continuativa, esegue riesami trimestrali degli accessi, testa la raccolta delle evidenze di incidente e riporta al consiglio metriche di rischio.
Il risultato non è solo una configurazione VPN più pulita. È un sistema di controllo dell’accesso remoto che può reggere un audit, supportare la risposta agli incidenti e ridurre il rischio operativo reale.
Costruisci il tuo pacchetto di evidenze sull’accesso remoto prima del prossimo incidente
L’avviso VPN del lunedì mattina non deve necessariamente diventare una crisi. Ma dovrebbe diventare un test di governance.
Puoi identificare l’utente? Puoi provare MFA? Puoi confermare la postura di sicurezza del dispositivo? Puoi ricostruire la sessione? Puoi determinare se i dati personali erano accessibili? Puoi dimostrare che l’account era approvato e riesaminato? Puoi provare che il dispositivo VPN era aggiornato? Puoi dimostrare che l’accesso dei fornitori è registrato e segmentato? La direzione può vedere il rischio?
Se la risposta è “non ancora”, Clarysec può aiutarti.
Inizia con Zenith Blueprint: la roadmap in 30 passi per l’auditor per strutturare la tua roadmap di implementazione ISO/IEC 27001:2022, in particolare lo Step 14 per le politiche di trattamento del rischio, lo Step 16 per i controlli sul lavoro da remoto, lo Step 19 per l’autenticazione sicura e lo Step 20 per la sicurezza dei servizi di rete. Usa Zenith Controls: la guida alla conformità trasversale per mappare Lavoro da remoto, Controllo degli accessi, Autenticazione sicura, controlli sui fornitori, logging e sicurezza della rete ai relativi controlli ISO/IEC 27002:2022 e alle evidenze di conformità trasversale.
Poi rendi operativi i requisiti con le politiche Clarysec, come la Politica di lavoro da remoto, la Politica di sicurezza della rete, la Politica di controllo degli accessi, la Politica di sicurezza di terze parti e fornitori e gli equivalenti pronti per le PMI.
Il tuo prossimo audit non dovrebbe essere la prima occasione in cui le evidenze sull’accesso remoto vengono assemblate. Costruiscile ora, testale ora e rendi la governance dell’accesso remoto sicuro una delle parti più solide del tuo programma di conformità. Contatta Clarysec per una valutazione della governance dell’accesso remoto, scarica i template di politiche o prenota una demo per vedere come i tuoi controlli attuali si mappano a ISO 27001, NIS2, DORA e GDPR Article 32.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
