VPN e accesso remoto aziendale: rischi di sicurezza e controlli da applicare

Una VPN può essere ancora una componente valida dell’accesso remoto aziendale, ma il tunnel cifrato non risolve da solo il problema della sicurezza. Il rischio nasce soprattutto da chi può entrare, da quale dispositivo, verso quali risorse e con quali controlli. Credenziali compromesse, appliance non aggiornate, accessi troppo estesi e dispositivi non conformi possono trasformare una VPN in un punto di ingresso privilegiato verso la rete interna.

Questa pagina analizza il rischio specifico dell’accesso remoto VPN in azienda e i controlli da applicare per ridurlo. Per una spiegazione introduttiva di tunneling, cifratura, tipologie e protocolli, consulta la guida VPN: cos’è, come funziona e quali rischi generali comporta.

Perché l’accesso remoto VPN è un punto critico

Una VPN remote access estende verso l’esterno una parte del perimetro aziendale. Quando la sessione viene autorizzata, il dispositivo remoto ottiene una connettività che può raggiungere risorse interne in base alle regole definite su firewall, concentratore VPN e segmentazione di rete. La cifratura protegge il traffico in transito, ma non dimostra che l’utente sia legittimo, che l’endpoint sia sicuro o che l’accesso concesso sia realmente necessario.

Per questo il controllo non deve fermarsi alla domanda “la VPN è cifrata?”, ma deve verificare almeno quattro condizioni: identità affidabile, dispositivo conforme, accesso minimo necessario e capacità di rilevare comportamenti anomali durante la sessione.

I principali rischi di una VPN per l’accesso remoto aziendale

1. Credenziali rubate e autenticazione insufficiente

Una password valida non è una prova sufficiente dell’identità. Phishing, password reuse, infostealer e credential stuffing possono fornire a un attaccante credenziali utilizzabili sul gateway VPN. Per questo l’accesso remoto deve richiedere Multi-Factor Authentication (MFA), preferibilmente con metodi resistenti al phishing per gli account privilegiati e per gli accessi ad alto impatto.

L’MFA riduce drasticamente il rischio legato alla sola password, ma non sostituisce le altre verifiche: un account legittimo può essere abusato, un endpoint può essere compromesso e una sessione già autenticata può diventare pericolosa.

2. Gateway e appliance esposti su Internet

Firewall, concentratori VPN e portali SSL VPN sono componenti direttamente esposti. Una vulnerabilità critica non corretta può consentire bypass dell’autenticazione, esecuzione di codice o compromissione dell’appliance prima ancora che l’utente effettui il login. Il patching di questi sistemi deve quindi avere priorità superiore rispetto a dispositivi non esposti e deve essere collegato a un processo di vulnerability management con SLA definiti.

Le interfacce amministrative non devono essere pubblicate indiscriminatamente su Internet; l’accesso di management va ristretto, separato e monitorato.

3. Dispositivi remoti non conformi o compromessi

Il tunnel VPN protegge il percorso di rete, non l’endpoint. Un notebook senza patch, privo di EDR, con disco non cifrato o già compromesso può utilizzare la VPN come percorso verso file server, applicazioni e servizi interni. Il rischio aumenta con BYOD e dispositivi di fornitori, sui quali l’azienda ha meno controllo.

Un accesso remoto moderno dovrebbe valutare lo stato del dispositivo prima o durante la connessione: gestione MDM/UEM, EDR attivo, versione del sistema operativo, cifratura, certificato del device, stato di compliance e altri segnali di postura.

4. Accesso troppo esteso e movimento laterale

Il problema più rilevante del modello VPN tradizionale è spesso la reachability: una volta connesso, l’utente può vedere più rete di quanto richieda il suo ruolo. Se un account o un endpoint viene compromesso, questa connettività aumenta le possibilità di discovery, scansione, accesso a servizi interni e movimento laterale. La remediation passa da segmentazione, ACL e policy per ruolo, integrate in una strategia di Network Security.

Il principio operativo è semplice: una sessione remota non dovrebbe ottenere “accesso alla rete”, ma soltanto accesso alle risorse strettamente necessarie.

5. Accessi di fornitori e terze parti

Fornitori, manutentori e consulenti hanno spesso necessità di accesso temporaneo a server, applicazioni o dispositivi specifici. Una VPN condivisa o un profilo troppo ampio crea un rischio sproporzionato: credenziali meno governate, dispositivi fuori controllo e accessi che rimangono attivi oltre il periodo necessario.

Per le terze parti servono account nominativi, MFA, scadenza automatica, accesso per applicazione o segmento, registrazione degli eventi e revisione periodica. Gli account generici o condivisi eliminano la responsabilità individuale e riducono il valore dei log.

6. Split tunneling e controllo del traffico

Con lo split tunneling una parte del traffico passa nel tunnel aziendale e una parte esce direttamente verso Internet. La scelta può migliorare prestazioni e ridurre il carico sul concentratore, ma modifica il modello di sicurezza: il dispositivo comunica contemporaneamente con risorse interne e destinazioni Internet senza attraversare necessariamente gli stessi controlli di sicurezza.

Lo split tunneling non va considerato automaticamente insicuro: deve essere una decisione architetturale esplicita, supportata da EDR, DNS/Web Security, policy endpoint, routing selettivo e monitoraggio coerente con il profilo di rischio.

7. Visibilità insufficiente e rilevamento tardivo

Autenticare una sessione non significa poterla considerare affidabile fino alla disconnessione. I log VPN devono permettere di identificare anomalie come accessi da geografie inattese, orari inconsueti, tentativi ripetuti, variazioni improvvise del volume di traffico e connessioni verso risorse anomale per quel profilo utente.

I log di autenticazione e accesso remoto dovrebbero confluire nel sistema di monitoraggio o SIEM insieme ai segnali di identity provider, firewall, endpoint ed EDR/XDR. È la correlazione tra fonti che consente di distinguere un accesso legittimo da una sessione potenzialmente compromessa.

Come rendere più sicuro l’accesso remoto VPN

La sicurezza non richiede necessariamente di eliminare subito ogni VPN. In molti ambienti il primo passo corretto è ridurre la fiducia implicita e rendere l’accesso più granulare. La baseline minima dovrebbe includere i controlli seguenti.

• MFA obbligatoria per tutti gli utenti remoti, con autenticazione più forte per amministratori e profili privilegiati.
• Account nominativi e separazione degli account amministrativi; nessun account VPN condiviso.
• Patching prioritario di firewall, gateway e concentratori esposti, con inventario delle versioni e SLA per le vulnerabilità critiche.
• Policy di accesso per ruolo e segmentazione: l’utente deve raggiungere solo subnet, porte e applicazioni necessarie.
• Controllo della postura del dispositivo: device gestito, EDR attivo, patch, cifratura e stato di compliance.
• Accessi di terze parti temporanei, a scadenza e circoscritti alla risorsa necessaria.
• Logging centralizzato di autenticazioni, sessioni e traffico rilevante, con alert su comportamenti anomali.
• Revisione dello split tunneling e dei percorsi Internet in funzione dei controlli endpoint, DNS e Web Security disponibili.
• Protezione e segregazione delle interfacce di management; accesso amministrativo limitato a reti o jump host autorizzati.
• Test periodici delle policy e verifica del rischio residuo dopo modifiche a rete, identità, applicazioni o modalità di lavoro.

Quando il problema principale è la protezione dell’identità su protocolli o sistemi legacy, il percorso va coordinato anche con una strategia di Identity Security, così da estendere MFA e policy contestuali oltre le sole applicazioni cloud moderne.

VPN e RDP non sono lo stesso problema

Una VPN può essere usata come percorso per raggiungere un servizio RDP, ma i due rischi non vanno confusi. La VPN governa la connettività remota verso la rete; RDP è un servizio applicativo/di amministrazione con proprie superfici di attacco, policy e requisiti di hardening.

Se l’obiettivo è proteggere specificamente Remote Desktop da brute force, credenziali compromesse e ransomware, usa la guida dedicata: come proteggere l’accesso RDP da remoto. Questa separazione evita che le due pagine competano per lo stesso intento.

VPN, ZTNA e SASE: quando cambia il modello di accesso

La VPN rimane adatta in diversi scenari, soprattutto per collegamenti site-to-site, amministrazione di rete, protocolli legacy o casi in cui serve reale connettività IP. Il limite emerge quando l’azienda utilizza la VPN come meccanismo generalizzato per dare a utenti e fornitori accesso a molte applicazioni distribuite tra data center e cloud.

ZTNA cambia il principio: l’utente viene autorizzato verso una specifica applicazione o risorsa in base a identità, contesto e policy, senza ottenere automaticamente visibilità sulla rete più ampia. SASE estende questo modello integrando accesso, sicurezza web, firewall-as-a-service, controllo delle applicazioni cloud e networking in un’architettura cloud-delivered.