VPN per un piccolo ufficio: tenetela lontana dal controller di dominio

Tre condizioni decidono se l’unico server Windows dell’ufficio debba anche terminare la VPN: quanto software esposto a internet siete disposti a eseguire sulla directory, se potete autenticare utenti remoti senza quel ruolo e cosa accade al vostro accesso amministrativo quando l’host si riavvia. Se una delle tre ha una cattiva risposta, separate i ruoli. Che l’ufficio sia piccolo cambia il budget, non il rischio.

Ogni macchina del dominio si fida di un controller di dominio; un gateway VPN è raggiungibile da chiunque su internet. Quell’asimmetria è tutto l’argomento.

Due lavori con due profili di esposizione diversi

Il gateway accetta connessioni dall’esterno, quindi il suo listener, il suo stack TLS e la sua superficie di autenticazione sono tutti raggiungibili da reti non fidate. La directory detiene un’autorità di cui si fidano altre macchine, per questo le linee guida di hardening di Microsoft trattano il ruolo di controller di dominio e il suo ambiente di hosting come particolarmente sensibili. Ogni servizio aggiunto a quell’host eredita la posizione di fiducia della directory e aggiunge la propria superficie d’attacco. La comodità dell’installazione non è un confine di fiducia.

Separare i ruoli non elimina le dipendenze. Gli utenti remoti hanno ancora bisogno di autenticazione, rotte, DNS e regole di accesso, e un gateway che le salta non è più sicuro, solo meno utile.

Autenticazione senza il ruolo della directory

Un gateway può convalidare le credenziali tramite un’integrazione esterna supportata senza ospitare la directory stessa. Qualunque sia questa integrazione, datele un account i cui diritti corrispondano allo scopo: leggere gli attributi necessari all’autenticazione, niente di più. Ammettere utenti VPN non richiede mai di rendere i loro account ordinari amministratori di dominio, né richiede che il gateway conservi una copia della directory.

Poi limitate i percorsi di rete di cui il client remoto ha davvero bisogno. L’accesso a un servizio file interno, più i servizi di risoluzione dei nomi e di identità da cui dipende quel flusso di lavoro, è un insieme definito di percorsi. Non è un motivo per consentire ogni porta del controller di dominio o ogni interfaccia amministrativa dal pool VPN.

Un solo host resta un solo dominio di guasto

Due guest su un solo hypervisor separano la loro configurazione del sistema operativo e non separano il loro destino. Gli amministratori dell’hypervisor, lo switching virtuale, l’archiviazione e i backup restano parte del progetto, e un riavvio dell’host rimuove entrambi i servizi insieme. Chiamarla alta disponibilità perché lo schema mostra due VM è un errore comune e costoso. Se l’unica via di ritorno passa per la VPN su quell’host, un guasto porta via la connessione necessaria per ripararla.

Pianificate quindi un percorso di gestione indipendente che non dipenda dal tunnel, e annotate cosa resta disponibile durante la manutenzione. Programmate separatamente gli aggiornamenti del gateway e la manutenzione della directory, notando quali utenti o applicazioni tocca ogni interruzione.

Una finestra di manutenzione che richiede che la VPN sia attiva per riparare la VPN non è una finestra di manutenzione.

Spostatelo senza chiudervi fuori

Se i ruoli condividono già un’installazione, evitate una migrazione remota affrettata. Inventariate ciò che il gateway possiede oggi: indirizzi, regole di inoltro, NAT, impostazioni DNS, configurazione dell’autenticazione e qualsiasi servizio pubblicato. Preparate sia la sostituzione sia una via di ritorno prima di spostare il listener o modificare una rotta predefinita. Poi provate il lavoro reale di un utente remoto ordinario attraverso il nuovo confine, e confermate che l’accesso amministrativo non necessario fallisce ancora.

L’obiettivo non è uno schema più bello. È la capacità di riparare o ricostruire la VPN senza toccare la macchina che ancora la fiducia della directory per tutto l’ufficio. Sono obiettivi diversi, e solo uno di essi richiede un secondo server.

Registrate la decisione in ogni caso, incluse le condizioni che la riaprirebbero. Un piccolo ufficio cresce, e la risposta adatta a un server potrebbe non adattarsi al successivo.