1 22/05/2026 8 min

Remote Desktop con Google Authenticator: il punto non è “mettere la seconda password”, ma non rompere il controllo degli accessi

Se devi proteggere l’accesso a Remote Desktop, Google Authenticator può essere una componente utile, ma non va trattato come una soluzione magica. Il problema reale non è generare un codice OTP: è farlo entrare in un flusso di accesso che resti robusto anche quando un utente perde il telefono, un server viene compromesso o un gruppo di AD viene modificato male.

Su RDP la domanda corretta è: in quale punto del percorso di autenticazione inserisco la MFA? Se la risposta è “dentro una GUI installata a caso sul server”, stai costruendo un collo di bottiglia operativo. Se la risposta è “a monte del servizio RDP”, di solito sei su una strada più sana: gateway, VPN, bastion o NPS con estensione MFA. Google Authenticator entra bene come secondo fattore, ma il disegno conta più dell’app.

Il modello giusto: MFA prima di esporre la sessione RDP

La scelta più solida è non esporre mai l’RDP diretto su Internet. Il flusso corretto è: utente → controllo identità → secondo fattore → accesso al gateway o al tunnel → sessione RDP verso il server interno. In questo schema Google Authenticator può essere usato per generare il TOTP, ma il server da proteggere non deve diventare il punto dove avviene tutta la logica di autenticazione.

Questo approccio riduce la superficie d’attacco in modo netto. Se un host Windows è raggiungibile pubblicamente sulla 3389, ogni bug di RDP, ogni tentativo di password spraying e ogni problema di account lockout diventa un tema di produzione. Se invece l’accesso passa da un gateway o da una VPN, la MFA protegge il punto giusto: l’ingresso nel perimetro, non solo la singola sessione.

Dove funziona davvero Google Authenticator con RDP

Google Authenticator non “si collega a Remote Desktop” da solo. Genera codici TOTP basati su una chiave segreta condivisa. Per usarlo con RDP serve un componente intermedio che verifichi quel codice e poi conceda l’accesso. In pratica hai tre scenari sensati:

  • autenticazione su RDP Gateway con MFA;
  • accesso via VPN protetta da TOTP e poi RDP interno;
  • uso di un bastion host con MFA e jump verso le macchine target.

Il caso meno elegante è installare plugin o estensioni direttamente sul server RDP senza una governance chiara. Non è sempre sbagliato, ma aumenta il rischio operativo: aggiornamenti, compatibilità con patch Windows, gestione dei gruppi locali, recovery se il modulo MFA si rompe. Se devi proteggere più server, centralizzare il controllo è quasi sempre più pulito.

Perché il TOTP è utile, ma non basta da solo

Il TOTP di Google Authenticator è comodo perché non richiede rete al momento della generazione del codice. Questo è un vantaggio operativo, ma porta con sé un limite: se la chiave segreta viene copiata, il secondo fattore è compromesso. Quindi il TOTP non va pensato come sostituto della password, ma come un controllo aggiuntivo che alza il costo dell’attacco.

In ambienti RDP la combinazione tipica resta: password forte o, meglio, autenticazione integrata con directory, più TOTP, più restrizioni di rete. Se togli le restrizioni di rete e lasci solo il codice OTP, stai ancora offrendo un bersaglio raggiungibile da Internet. Se invece limiti gli IP, usi un gateway e applichi MFA, hai un assetto più difendibile anche sotto attacco di brute force o credential stuffing.

Architettura consigliata: RDP dietro gateway o VPN

La soluzione più pratica in molti contesti Windows è usare Remote Desktop Gateway o una VPN aziendale, e applicare MFA nel punto di accesso. Se l’infrastruttura è già su Active Directory, il passaggio pulito è integrare il gateway con NPS e un’estensione MFA supportata dal tuo stack. Google Authenticator può essere il generatore TOTP lato utente, mentre il server verifica il secondo fattore prima di autorizzare la sessione.

Questo disegno ha un vantaggio importante: puoi mantenere separati i ruoli. Il server RDP rimane un server applicativo o di lavoro remoto, il gateway gestisce la policy di accesso, e la MFA vive in un layer dedicato. Quando qualcosa va male, sai dove guardare: log del gateway, eventi NPS, stato del servizio VPN, non un insieme di plugin installati direttamente sui desktop remoti.

Hardening minimo che ha senso davvero

Se usi Google Authenticator con Remote Desktop, la parte più importante non è il QR code iniziale ma il contorno. Ci sono alcune misure che cambiano davvero il profilo di rischio:

  • non esporre RDP su Internet se puoi evitarlo;
  • limita i gruppi abilitati all’accesso remoto a un insieme esplicito e piccolo;
  • usa account nominativi, niente account condivisi;
  • abilita lockout e monitoraggio sugli eventi di autenticazione fallita;
  • segrega il piano di gestione da quello utente, soprattutto su server critici;
  • documenta il recovery per chi perde il secondo fattore.

Il recovery è spesso trascurato. Se un tecnico perde il telefono e l’unico modo per sbloccarlo è fermare metà produzione, la MFA è stata implementata male. Serve una procedura di reset controllata, con verifica dell’identità del richiedente, log dell’operazione e revoca/ricreazione del segreto TOTP. Meglio ancora se la procedura richiede approvazione da un secondo amministratore.

Un altro punto pratico: i codici di Google Authenticator dipendono dall’orario. Se l’orologio del server o del sistema che verifica il TOTP è fuori sync, gli utenti vedranno fallimenti apparentemente casuali. Quindi la sincronizzazione NTP non è un dettaglio: è parte della sicurezza operativa.

Il rischio più comune: credere che la MFA compensi una rete aperta male

Succede spesso: si aggiunge il secondo fattore e si lascia intatta una configurazione debole. RDP resta pubblicato, i tentativi di login esplodono, il sistema si riempie di eventi di fallimento, e il team conclude che “la MFA funziona perché blocca gli attacchi”. In realtà stai solo assorbendo rumore e rischio operativo. La MFA riduce il rischio di compromissione dell’account, ma non elimina la pressione sul servizio esposto.

Se il tuo obiettivo è proteggere l’accesso remoto, la gerarchia corretta è: chiudi l’esposizione diretta, metti un punto di ingresso controllato, abilita MFA, poi monitora. Se invece parti dalla sola applicazione del TOTP, stai curando il sintomo e non il vettore principale.

Gestione delle chiavi e dei segreti: il lato che viene ignorato troppo spesso

Ogni account protetto con TOTP ha un segreto condiviso. Quel segreto va trattato come materiale sensibile. Non va salvato in chiaro in note condivise, ticket, screenshot o mail. Se usi una piattaforma che esporta backup del profilo MFA, devi sapere dove finiscono quei backup, chi li legge e con quali permessi. La sicurezza della MFA crolla se il segreto è recuperabile da chiunque abbia accesso al repository sbagliato.

Un buon criterio operativo è semplice: il segreto esiste solo nel sistema di enrollment e nel dispositivo dell’utente. Se serve una copia di emergenza, deve essere cifrata, tracciata e ruotata quando viene usata. Se non hai un flusso di rotazione, la copia di backup diventa solo una seconda vulnerabilità.

Controlli da fare prima di mettere in produzione

Prima di considerare il setup pronto, verifica almeno questi punti con evidenza concreta:

  • dal client, il flusso di accesso richiede effettivamente il secondo fattore;
  • nei log del gateway, della VPN o del modulo MFA compare un evento di successo e di fallimento distinguibile;
  • l’accesso RDP diretto è disabilitato o limitato alle sole sorgenti autorizzate;
  • la procedura di reset MFA è documentata e testata su un account non critico;
  • l’orario di server e client è allineato via NTP;
  • i gruppi autorizzati sono rivisti periodicamente.

Se uno di questi punti manca, non hai ancora una protezione completa: hai solo un controllo parziale. La verifica più utile, in pratica, è tentare un accesso con password corretta ma senza secondo fattore, e controllare che il sistema lo rifiuti in modo esplicito nei log. Se non trovi quel tracciamento, stai lavorando al buio.

Quando Google Authenticator non è la scelta migliore

Ci sono casi in cui TOTP va bene, ma non è la scelta più solida. Se hai utenti con privilegi elevati, ambienti regolamentati o bisogno di revoca centralizzata forte, spesso è meglio puntare su metodi più integrati con il provider identità: app push con policy, FIDO2, smart card, certificati o soluzioni MFA native del tuo IdP. Google Authenticator resta utile, ma perde terreno quando ti servono controlli più granulari su device compliance, rischio sessione e policy adattive.

Detto in modo diretto: se il tuo obiettivo è solo “aggiungere un secondo fattore” in un piccolo ambiente, Google Authenticator è spesso sufficiente. Se invece devi costruire un accesso remoto serio per un parco server o per utenti privilegiati, il livello di maturità richiesto è superiore al solo TOTP. In quel caso conviene valutare una soluzione che si integri nativamente con directory, logging centralizzato e revoca immediata.

Scelta pratica: semplice da usare, difficile da abusare

La regola buona, qui, è tenere separati tre piani: identità, secondo fattore e accesso alla macchina. Google Authenticator può coprire bene il secondo fattore, ma la sicurezza complessiva dipende da come incastri il resto. Se l’utente entra in un tunnel o in un gateway ben controllato, il TOTP aggiunge un salto di qualità reale. Se invece lasci RDP esposto e speri che il codice di sei cifre basti da solo, stai facendo affidamento su un presidio che non regge il peso del problema.

In sintesi operativa: usa Google Authenticator come tassello di una catena, non come catena intera. Proteggi il punto di ingresso, registra gli eventi, prepara il recovery e limita l’esposizione. È questo che rende l’accesso remoto difendibile nel tempo, non il semplice fatto di avere un codice che cambia ogni trenta secondi.