Sicurezza di Outlook Web App: proteggere Exchange con l'autenticazione a più fattori (MFA)

Introduzione

La maggior parte delle discussioni sulla sicurezza dell’accesso remoto parte dalla VPN. Quasi nessuna parte da Outlook Web App, e questa è una strana lacuna considerando cosa sia effettivamente OWA: un modulo di accesso per la posta elettronica aziendale, ospitato su Internet, raggiungibile da qualsiasi browser su qualsiasi dispositivo, ovunque. Non c’è nessun client VPN da configurare, nessuna regola del firewall da aggirare, nessun segmento di rete da attraversare: solo un campo per il nome utente, uno per la password e qualsiasi cosa il server Exchange decida di accettare.

Per un aggressore, questo è praticamente il percorso più diretto possibile per accedere a una casella di posta. Un accesso a OWA compromesso non richiede movimenti laterali per diventare pericoloso: lo è già, immediatamente, perché la casella di posta stessa è l’obiettivo. Il Business Email Compromise non ha bisogno di malware, non ha bisogno di un exploit e non fa scattare la maggior parte degli strumenti di rilevamento creati per le intrusioni di rete. Ha bisogno solo di un set di credenziali valide e di una pagina di accesso che non richieda nient’altro.

Perché Exchange on-premise e ibrido non dispongono gratuitamente dell’autenticazione a più fattori (MFA)

La confusione in questo caso è comprensibile, perché i tenant di Microsoft 365 che utilizzano Exchange Online ottengono effettivamente un’autenticazione forte quasi automaticamente: le politiche di accesso condizionale di Entra ID possono richiedere l’autenticazione a più fattori (MFA) a livello di identità prima ancora che venga emesso un token di sessione, e tale protezione si estende a Outlook sul Web senza alcuna configurazione specifica per Exchange. I team di sicurezza che hanno sempre lavorato solo in un ambiente puramente cloud presumono ragionevolmente che l’autenticazione a più fattori (MFA) per la webmail sia semplicemente il modo in cui funziona Exchange.

Exchange on-premise e ibrido non ereditano tale comportamento. Lo stack di autenticazione proprio di Exchange Server — il ruolo dei servizi di accesso client che gestisce OWA e l’Exchange Admin Center — convalida nome utente e password rispetto ad Active Directory e, in assenza di configurazioni aggiuntive, questa è l’intera decisione di autenticazione. Non esiste un secondo fattore nativo integrato nell’accesso a OWA on-premise. Le distribuzioni ibride complicano ulteriormente la situazione: alcune caselle di posta potrebbero essere già state spostate su Exchange Online ed essere coperte dall’accesso condizionale, mentre altre rimangono on-premise e potrebbero ancora fare affidamento sul percorso di autenticazione proprio di Exchange Server, a meno che non sia stata esplicitamente configurata l’autenticazione ibrida moderna o un’altra soluzione MFA. È del tutto possibile che un’organizzazione ritenga che la propria posta elettronica sia “protetta dall’autenticazione a più fattori” poiché ciò è vero per il tenant, mentre una parte significativa delle caselle di posta si trova ancora dietro l’accesso OWA on-premise basato esclusivamente sulla password.

Questa è la lacuna che conta dal punto di vista operativo, non perché Exchange on-premise sia intrinsecamente meno sicuro per come è progettato, ma perché attribuisce la responsabilità di aggiungere un secondo fattore di autenticazione esclusivamente all’amministratore di Exchange, senza alcuna impostazione predefinita su cui fare affidamento.

Cosa offre effettivamente a un aggressore un account OWA o EAC compromesso

È facile sottovalutare il valore di una singola credenziale OWA se la si considera “solo posta elettronica”. In pratica, un account di casella di posta compromesso rappresenta un punto d’appoggio da cui si diramano diversi percorsi di attacco distinti.

Il Business Email Compromise (BEC) è quello con le conseguenze finanziarie più dirette.

Il Business Email Compromise (BEC) è quello con le conseguenze finanziarie più immediate. L’Internet Crime Complaint Center dell’FBI ha registrato nel 2025 negli Stati Uniti perdite segnalate per BEC pari a 3,046 miliardi di dollari, la seconda categoria di perdite più elevata dopo le frodi sugli investimenti, distribuite su circa 24.768 denunce — con una perdita media superiore a 120.000 dollari per ogni incidente confermato. Gli attacchi BEC sono caratterizzati dall’assenza di malware e di link dannosi che un filtro di sicurezza possa intercettare; l’autore dell’attacco si trova all’interno di una casella di posta legittima, invia messaggi da un indirizzo legittimo e spesso risponde all’interno di una conversazione esistente modificando il codice di identificazione bancaria o reindirizzando una fattura. Le regole di flusso della posta rendono questa tecnica più difficile da individuare a posteriori: un aggressore con accesso alla casella di posta può creare una regola nella posta in arrivo che inoltra o elimina silenziosamente i messaggi contenenti parole come “fattura”, “bonifico” o “pagamento”, mantenendo la compromissione invisibile al titolare dell’account mentre la conversazione fraudolenta prosegue in parallelo.

L’accesso delegato aggrava l’esposizione.

L’accesso delegato aggrava l’esposizione. Gli assistenti esecutivi e i membri del team finanziario dispongono spesso di autorizzazioni di delega o “invia come” sulle caselle di posta dei dirigenti come parte del normale flusso di lavoro; ciò significa che un singolo account di assistente compromesso può essere utilizzato per inviare comunicazioni che sembrano provenire direttamente da un CFO o da un CEO senza mai toccare le credenziali del dirigente stesso.

L’esposizione dei dati è il rischio più silenzioso

L’esposizione dei dati è il rischio più silenzioso e spesso quello con conseguenze più gravi per le organizzazioni soggette a regolamentazione. Una casella di posta accumula anni di allegati, promemoria interni, corrispondenza delle risorse umane e comunicazioni con i clienti, tutti accessibili tramite l’interfaccia di OWA una volta che l’autore dell’attacco si è autenticato — non sono necessari strumenti di esfiltrazione separati, poiché l’autore dell’attacco può accedere e scaricare il contenuto della casella di posta utilizzando le funzionalità legittime di OWA.

Approccio 1: MFA applicata direttamente all’accesso a OWA e all’EAC

La soluzione più mirata affronta la superficie specifica a rischio senza intervenire su nessun altro elemento collegato ad Active Directory. L’autenticazione a più fattori (MFA) per Outlook Web App e l’Exchange Admin Center viene installata come componente del ruolo dei servizi di accesso client di Exchange, posizionandosi davanti alle pagine di accesso esistenti di OWA ed EAC anziché sostituire completamente il meccanismo di autenticazione di Exchange. Una volta installato, gli utenti effettuano prima l’autenticazione con il loro normale nome utente e password di AD, quindi completano una seconda fase di autenticazione — ad esempio, inserendo un OTP da un’app di autenticazione o da un token hardware, oppure approvando una notifica push — prima che la sessione venga concessa.

L’ambito di applicazione viene definito tramite l’appartenenza a gruppi di Active Directory al momento dell’installazione: un amministratore può richiedere immediatamente l’autenticazione a più fattori (MFA) per l’intera popolazione di utenti, oppure abilitarla inizialmente per un singolo gruppo AD — un gruppo pilota, o nello specifico il gruppo che detiene l’accesso a Exchange Admin Center — mentre si pianifica l’implementazione su più ampia scala. Questa distinzione è importante nella pratica, poiché gli account EAC comportano un rischio organizzativo notevolmente maggiore rispetto a una singola casella di posta; un account amministratore con accesso all’EAC può creare regole di flusso della posta, modificare le autorizzazioni o esportare dati nell’intero ambiente Exchange, ed è proprio per questo che la protezione degli accessi all’EAC tende ad essere la priorità anche quando l’implementazione completa per tutti gli utenti richiede più tempo.

Il comportamento della sessione è configurabile anziché fisso. Gli amministratori stabiliscono con quale frequenza agli utenti venga richiesto un nuovo OTP — ad esempio, una volta ogni 12 ore di utilizzo continuativo di OWA — bilanciando l’attrito causato dalle ripetute autenticazioni con il rischio di una sessione di lunga durata e incustodita su un dispositivo condiviso o non gestito. Il componente supporta HOTP, TOTP e OCRA (challenge-response), offrendo flessibilità alle organizzazioni che utilizzano diversi tipi di token OTP.

Approccio 2: MFA a livello di Active Directory, che copre OWA insieme a tutto il resto

Una domanda più specifica che vale la pena porsi prima di implementare il componente specifico per OWA: OWA è davvero l’unico servizio collegato ad AD che si autentica ancora solo tramite password? Per la maggior parte degli ambienti on-premise, la risposta onesta è no: Winlogon, RDP e spesso le applicazioni interne legate a LDAP si trovano nella stessa situazione, protette solo dalla politica delle password imposta da AD.

L’autenticazione a più fattori a livello di directory affronta questa esposizione più ampia integrandosi direttamente in Active Directory piuttosto che nella pagina di accesso di ogni singolo servizio. Invece di una serie di implementazioni MFA separate — un componente per OWA, un agente diverso per RDP, un proxy RADIUS per la VPN, ciascuno installato, configurato e gestito in modo indipendente — un’integrazione a livello di directory modifica il funzionamento delle credenziali utente in Active Directory sostituendo le password statiche con password dinamiche basate sul tempo, in modo che i servizi collegati ad AD possano utilizzare le stesse credenziali dinamiche senza richiedere componenti MFA separati per ciascun servizio. OWA viene incluso non perché fosse specificamente preso di mira, ma perché, come tutto il resto collegato ad AD, ora deve soddisfare lo stesso controllo delle credenziali dinamiche.

Il compromesso va nella direzione opposta rispetto all’Approccio 1: una copertura più ampia in cambio di una modifica di più ampia portata al comportamento dell’autenticazione AD in tutto l’ambiente, il che in genere richiede test più accurati e un’implementazione graduale rispetto a quanto richiesto da un singolo componente OWA. La scelta giusta tra i due dipende effettivamente dall’ambito: un’organizzazione la cui unica superficie non protetta collegata ad AD sia OWA non ha bisogno di intervenire sulla directory per risolvere il problema; un’organizzazione che scopra che OWA, RDP e Winlogon utilizzano tutti un’autenticazione basata esclusivamente su password ha un problema più ampio che una correzione a livello di singolo servizio non risolverà.

Come funziona il meccanismo a livello di directory senza agenti sugli endpoint

Vale la pena comprendere il meccanismo alla base dell’autenticazione a più fattori (MFA) a livello di directory nei suoi termini specifici, poiché spiega perché raggiunga ogni servizio connesso ad AD senza installare nulla sulle singole workstation o sui server.

L’autenticazione dinamica con password forte funziona modificando la password memorizzata in Active Directory stesso, anziché intercettare il traffico di autenticazione su ciascun endpoint. La password statica di un utente viene sostituita con una password dinamica a rotazione basata su TOTP che cambia automaticamente a un intervallo configurato dall’amministratore — un valore che deve essere un multiplo di 30 secondi. La password dinamica corrente viene generata utilizzando l’algoritmo TOTP ed è disponibile per l’utente tramite l’app Protectimus SMART o un chatbot supportato. Poiché la modifica avviene direttamente nella directory, qualsiasi client o servizio che effettui l’autenticazione su AD — Winlogon, RDP, OWA, applicazioni basate su LDAP — utilizza automaticamente la password dinamica corrente, senza che quel servizio debba essere a conoscenza di alcuna modifica.

Questo è ciò che rende l’approccio “senza agente” nel senso che conta: non c’è alcun software in esecuzione sul portatile, sull’host RDP o sul server di accesso client di Exchange che verifichi la presenza di un secondo fattore. La directory stessa è il punto di applicazione. Il compromesso corrispondente è che questo componente viene eseguito come parte di una distribuzione on-premise anziché come servizio esclusivamente cloud, poiché richiede l’integrazione diretta con il controller di dominio.

Scelta dell’ambito: solo webmail o l’intero ambiente AD

Entrambi gli approcci risolvono il problema di fondo — la password da sola non è più sufficiente per l’autenticazione — ma lo risolvono in punti diversi dello stack, e la scelta giusta dipende da un’analisi onesta della situazione piuttosto che da una preferenza predefinita.

Se OWA ed EAC sono effettivamente gli unici servizi che ancora effettuano l’autenticazione su AD utilizzando nient’altro che una password — la VPN è già coperta tramite RADIUS, l’RDP è già bloccato, non ci sono altre applicazioni legacy che si affidano silenziosamente alle credenziali di AD — il componente OWA mirato colma quella specifica lacuna con un’interruzione minima per qualsiasi altro servizio in esecuzione sulla directory. Se l’inventario rivela più di un servizio esposto — cosa che si verifica più spesso una volta che i team IT iniziano effettivamente a cercare — l’autenticazione a più fattori (MFA) a livello di directory li chiude tutti da un unico punto di integrazione, invece di accumulare un prodotto MFA separato per ciascuno di essi.

In entrambi i casi, i dati dell’FBI sulle perdite dovute al BEC indicano lo stesso fatto di fondo: un accesso basato esclusivamente sulla password a una casella di posta aziendale, esposta su Internet, non è più una posizione difendibile per nessuna organizzazione che utilizzi Exchange — on-premise, ibrido o di altro tipo.