Comprendere i casi limite dei protocolli legacy nell'ecosistema Microsoft

By Mirko Peters · 2026-04-26

I protocolli di autenticazione legacy (pensa a NTLM, SMTP AUTH o persino al vecchio FTP) possono sembrare problemi di un'altra epoca, ma continuano a resistere ostinatamente nel mondo enterprise centrato su Microsoft. Le organizzazioni moderne passano a Microsoft 365 e Azure, eppure i casi limite legati a questi protocolli minano silenziosamente le strategie di zero trust e di sicurezza. Puoi blin

Automatically translated with AI from the original post. Read the English original

Cover: Detect Microsoft 365 Attack Chains with Entra and Sentinel

Perché questi casi limite continuano a creare grattacapi? La realtà è che modernizzare l'IT non può sempre avvenire dall'oggi al domani. Molti sistemi aziendali critici, integrazioni di terze parti e persino dispositivi di tecnologia operativa sono progettati per usare protocolli più vecchi. Gli attaccanti lo sanno, quindi prendono di mira tutto ciò che è ancora in funzione, aggirando i controlli moderni e aprendo varchi dove i team di sicurezza meno se lo aspettano.

Questo articolo analizza come e perché i rischi dei protocolli legacy persistono mentre le aziende evolvono i loro ambienti Microsoft. Definiremo gli elementi tecnici, esploreremo i pericoli critici per il business e illustreremo cosa puoi fare, dal rilevamento alla governance, per chiudere definitivamente queste lacune ostinate. Iniziamo a capire da dove nascono davvero i rischi e come chiudere per sempre quelle porte di servizio.

Vulnerabilità dei protocolli legacy e sfruttamento nel mondo reale

Anche con le difese cloud-native e l'MFA, gli attaccanti continuano a sfruttare gli anelli deboli rimasti dai decenni passati. I protocolli legacy, come NTLM per l'autenticazione, SMTP AUTH per la posta e FTP o POP3 di base per lo spostamento dei dati, restano in uso perché i sistemi reali devono continuare a funzionare mentre le aziende si modernizzano. Gli attaccanti ne approfittano, perché spesso significa poter aggirare indisturbati i sistemi più protetti di un'azienda.

Negli ambienti ibridi odierni, questi vecchi protocolli non esistono soltanto su un singolo server nascosto nel data center: sono intrecciati con le piattaforme di identità cloud, con le app line-of-business e persino con dispositivi OT e IoT che non sanno proprio usare l'autenticazione moderna. Eliminarli è difficile, perché bloccarli del tutto può interrompere processi critici, e il rilevamento in tutte queste aree non è sempre uniforme.

Il risultato? Incidenti come le violazioni di Vercel e Orange España dimostrano che basta un solo protocollo trascurato per aprire la porta al furto di dati o alla compromissione della rete. Gli attaccanti usano questi percorsi legacy per aggirare l'MFA, inoltrare le credenziali o escalare i privilegi sia nei carichi di lavoro cloud sia in quelli on-premises. Analizzeremo nel dettaglio come funzionano questi attacchi, perché i protocolli stessi sono difettosi per progettazione e dove si nascondono i rischi di business più ostinati.

Parleremo anche delle abitudini operative che mantengono vivi questi rischi, come affidarsi a una gestione lassista dei criteri o ereditare anni di debito tecnico da integrazioni nate con la logica del "basta che funzioni". Le sottosezioni seguenti approfondiranno come vengono sfruttate le vulnerabilità legacy, i difetti sistemici dei protocolli e i punti in cui le difese moderne si scontrano con vicoli ciechi. Se stai cercando un ambiente Microsoft davvero sicuro, devi sapere esattamente dove si nascondono queste vecchie minacce e come riescono ancora a entrare quando i tuoi log dicono che tutto è «sicuro». Per approfondire come questi attacchi si concatenano nel mondo reale, dai un'occhiata a questa analisi dettagliata sulle catene di attacco di Microsoft 365.

Come le violazioni di Vercel e Orange España hanno esposto i rischi dei protocolli legacy

Le violazioni di Vercel e Orange España hanno messo in luce quanto i rischi dei protocolli legacy siano tutt'altro che un'ipotesi teorica. In entrambi i casi, metodi di autenticazione obsoleti hanno giocato un ruolo chiave, consegnando agli attaccanti le chiavi per avanzare più in profondità nelle reti aziendali. Nel caso di Vercel, gli attaccanti sono riusciti a estrarre variabili d'ambiente e segreti di centinaia di clienti di alto profilo, perché le credenziali legate ai flussi di autenticazione legacy erano ancora in uso dietro le quinte.

Il caso di Orange España ha mostrato uno schema simile. Qui gli attaccanti hanno superato le difese di primo livello usando credenziali valide rubate, molte delle quali non avrebbero funzionato se per la posta elettronica non fossero stati abilitati protocolli legacy come POP3/IMAP o SMTP AUTH non protetto. Il rapporto annuale sulle minacce di IBM evidenzia che il furto di credenziali resta il principale vettore di accesso iniziale nelle violazioni aziendali, soprattutto quando le organizzazioni non disattivano proattivamente i metodi di autenticazione obsoleti.

Gli esperti che hanno analizzato questi casi sottolineano un punto chiave: le vulnerabilità dei protocolli legacy non sono semplici residui tecnici. Spesso sono integrate in profondità negli script di automazione, negli strumenti di backup o persino nei dispositivi embedded che usano silenziosamente metodi di autenticazione obsoleti ogni giorno. Ad esempio, nella catena di attacco di Vercel, protocolli come l'autenticazione di base e token di accesso gestiti male hanno permesso agli attaccanti di aggirare i controlli moderni dei criteri e di spostarsi lateralmente una volta entrati nella rete.

Cosa possono imparare le organizzazioni? Le violazioni di alto profilo continuano a dimostrare che proteggere i punti di accesso cloud più recenti non basta. Una vera resilienza richiede di individuare e eliminare questi percorsi legacy nascosti. Finché non succede, gli attaccanti continueranno a puntare sulle vie di accesso più facili e meno protette, spesso in esecuzione silenziosa in background negli ambienti ibridi e multi-cloud.

Attacchi NTLM Relay e il problema dell'autenticazione di base: come aggirare i controlli di sicurezza moderni

I protocolli legacy come NTLM e l'autenticazione di base creano parecchi grattacapi ai team di sicurezza, perché non rispettano le regole moderne di MFA. Ecco come i malintenzionati sfruttano queste debolezze per aggirare le difese:

Attacchi NTLM Relay:
Gli attaccanti catturano gli hash NTLM su un dispositivo compromesso e li « inoltrano » (relay) ad altri servizi a cui la vittima ha accesso. Poiché NTLM non richiede di conoscere la password originale, l'attaccante può impersonare gli utenti senza mai craccare una password. Questi inoltri spesso vanno dall'AD locale al cloud, soprattutto in configurazioni di identità ibride poco segmentate.
Aggirare l'MFA:
Protocolli come SMTP AUTH e IMAP non supportano affatto l'MFA. Se un attaccante ottiene credenziali valide, può accedere tramite questi protocolli anche quando l'MFA è comunque applicata agli account utente. Ciò significa che password deboli e riutilizzate diventano un singolo punto di fallimento in ambienti che si credono sicuri.
Movimento laterale ed escalation dei privilegi:
Una volta dentro, gli attaccanti usano i protocolli legacy per spostarsi. Ad esempio, sfruttando l'autenticazione di base su un'applicazione trascurata, possono muoversi lateralmente verso sistemi con privilegi più elevati. L'accesso a un solo servizio SMB o Exchange non protetto porta spesso a una compromissione dell'intera rete.
Aggiramento dell'accesso condizionale:
Molti criteri di Accesso condizionale in Azure AD si applicano solo ai client di autenticazione moderna. I protocolli legacy possono eludere queste regole, lasciando liste di autorizzazione pericolose o lacune nei criteri che gli attaccanti cercano attivamente. Vuoi un approfondimento sui cicli di sicurezza dell'identità e su come sistemare la proliferazione dell'Accesso condizionale? Dai un'occhiata a questo episodio del podcast sulla riduzione scalabile del rischio negli ambienti Microsoft.

In breve, puoi configurare e aggiornare tutti i controlli moderni che vuoi, ma se i protocolli legacy sono ancora attivi, quasi sempre gli attaccanti troveranno il modo di aggirare le tue nuove difese.

Difetti sistemici: dalle vulnerabilità di MCP ai rischi di LLMNR e NetBIOS

I protocolli Microsoft legacy sono afflitti da difetti che non sono semplici bug, ma sono integrati nella loro progettazione. Ecco perché queste debolezze rappresentano un rischio persistente:

Difetti di MCP (Microsoft Connector Platform):
Alcune piattaforme e connettori usati da agenti di terze parti e script di automazione si basano ancora sul passaggio di credenziali legacy, senza un adeguato token binding né un controllo granulare degli accessi. Gli attaccanti li sfruttano per ottenere privilegi più elevati, soprattutto quando i criteri degli agenti non sono governati con rigore.
Debolezze di LLMNR (Link-Local Multicast Name Resolution):
LLMNR è stato progettato per semplificare la risoluzione dei nomi di rete, ma viene facilmente abusato per rubare credenziali. Gli attaccanti inviano in broadcast risposte false, ingannando i sistemi vicini perché consegnino hash NetNTLM, che poi possono essere craccati o inoltrati.
Rischi di denominazione NetBIOS:
Le vecchie reti Windows usano ancora NetBIOS per la risoluzione dei nomi: un altro protocollo mai progettato pensando alla sicurezza. Gli attaccanti possono intercettare e manipolare il traffico per impersonare servizi o raccogliere dettagli sensibili sulla rete, preparando così ulteriori attacchi.
Lacune nella firma SMB:
La firma SMB è stata introdotta per proteggere le condivisioni di file, ma la sua applicazione è discontinua, soprattutto nelle reti ibride e negli ambienti OT. Gli attaccanti ne approfittano inoltrando le credenziali o falsificando le risposte tra i sistemi, spesso sfruttando il salto dall'infrastruttura OT legacy a quella IT moderna.

Disabilitare protocolli come LLMNR e imporre la firma SMB sono passaggi imprescindibili per un vero approccio Zero Trust. Per capire come il controllo coordinato e la sicurezza adattiva possano aiutare a chiudere queste lacune nei protocolli, ascolta l'episodio del podcast Zero Trust by Design: è un approfondimento pratico sull'identità unificata e sui controlli di sessione.

Autenticazione moderna contro legacy: sfide della transizione e casi limite

Passare dall'autenticazione legacy a quella moderna è un percorso, non un cambio rapido. Man mano che colmi il divario, incontrerai ogni sorta di caso limite. Protocolli come OAuth 2 e MFA alzano l'asticella della sicurezza, ma la necessità di mantenere la compatibilità con le versioni precedenti lascia spesso una porta sul retro socchiusa. I flussi di autenticazione "semi-moderna", come i modelli ibridi o i protocolli che fingono di essere moderni, spuntano ovunque e confondono le acque sia per la conformità sia per la protezione.

Perché le organizzazioni finiscono per avere queste configurazioni ibride? La risposta è semplice: le applicazioni critiche, i servizi e le integrazioni di terze parti non sono sempre pronti a disattivare l'autenticazione legacy dall'oggi al domani. A volte un semplice processo aziendale o un flusso di automazione ereditato dipende da metodi di autenticazione che risalgono a decenni fa. Affrettarsi a disattivarli può interrompere l'attività o compromettere la conformità, quindi si concedono eccezioni, ed è proprio lì che gli attaccanti si inseriscono.

Un vero approccio Zero Trust significa chiudere ogni falla, non solo aggiungere nuovi livelli scintillanti. La difficoltà è che, mentre cerchi di modernizzare l'autenticazione, alcuni "aggiornamenti" avvolgono semplicemente vecchie vulnerabilità in un involucro più recente, come BAV2ROPC o altri flussi di password del proprietario della risorsa. Anche le lacune nei criteri e le esclusioni non verificate in Accesso condizionale possono far sembrare moderna la tua sicurezza solo sulla carta, lasciando però spalancati i percorsi legacy.

Le prossime sezioni approfondiscono gli aspetti tecnici di queste configurazioni semi-moderne e illustrano dove anche i migliori piani di miglioramento incontrano ostacoli concreti. Se stai pianificando una vera trasformazione, o cerchi semplicemente di tenere lontani gli attaccanti, conviene capire perché il supporto legacy è duro a morire e dove la tua strategia potrebbe lasciarti ancora esposto. Per consigli sulla creazione di linee di base affidabili per i criteri di Accesso condizionale, leggi questo articolo sui problemi di fiducia nei criteri.

Il mistero di BAV2ROPC e le insidie dell'autenticazione semi-moderna

BAV2ROPC sta per "Basic Authentication Version 2 Resource Owner Password Credential". Sembra moderno, ma in realtà è una nuova veste per un vecchio problema. Questo protocollo, spesso presente negli ambienti cloud Microsoft, colma il divario tra autenticazione legacy e moderna consentendo alle applicazioni di passare programmaticamente un nome utente e una password per ottenere un token di risorsa, senza browser né un flusso di consenso moderno.

Questo approccio "semi-moderno" inganna molte organizzazioni. In superficie, BAV2ROPC usa endpoint moderni e flussi OAuth 2. Ma sotto, si basa sullo stesso scambio di nome utente e password che usano i protocolli legacy come POP3, IMAP o SMTP AUTH, e raramente supporta MFA o Accesso condizionale. Questo lascia la porta aperta agli attaccanti per eseguire password stuffing, replay delle credenziali o attacchi di relay dall'on-premises al cloud.

Il rilevamento è difficile. Nei log, il traffico BAV2ROPC è difficile da distinguere dalla vera autenticazione moderna. Gli attaccanti lo sanno e prendono di mira deliberatamente applicazioni o account di servizio che usano questi flussi, perché i tentativi di violazione non fanno scattare gli stessi allarmi della vecchia Basic Auth. Nella pratica, le organizzazioni trovano difficile abbandonare BAV2ROPC, soprattutto per i processi di automazione senza interfaccia e per gli script di integrazione ancora usati nelle operazioni quotidiane.

Per i team di sicurezza, l'errore più grave è dare per scontato che tutto ciò che è etichettato come «OAuth 2» o «resource owner» sia sicuro per impostazione predefinita. BAV2ROPC e protocolli simili mettono in luce la dura realtà: anche le API moderne e curate possono esporti alle stesse debolezze dei protocolli che avrebbero dovuto sostituire. Finché non verifichi e non migri a fondo ogni caso limite, queste falle semi-moderne restano bersagli aperti.

Quando i miglioramenti nell'autenticazione non bastano: la strategia di sicurezza uccisa dal supporto ai sistemi legacy

Passare a OAuth 2 e attivare l'MFA su tutta l'organizzazione sembra la soluzione perfetta, finché il supporto ai sistemi legacy non introduce una falla fatale. Le ricerche indicano che più del 60% delle compromissioni di account cloud nell'ultimo anno ha coinvolto credenziali valide usate tramite protocolli legacy. Anche i criteri di accesso condizionale più avanzati crollano se c'è un'esclusione dimenticata o una vecchia app che usa l'autenticazione di base dietro le quinte.

Gli esperti avvertono che modernizzare lo stack di autenticazione non significa semplicemente spuntare una checklist di funzionalità. Il supporto persistente ai sistemi legacy, i criteri configurati in modo errato o gli account di servizio non gestiti permettono agli attaccanti di aggirare difese altrimenti solide. Un piano di transizione completo, che dismetta attivamente i vecchi percorsi, verifichi le esclusioni dei criteri e governi ogni endpoint, è l'unico modo per stare al passo. Per capire da vicino come gli attaccanti sfruttano il consenso OAuth e i percorsi legacy, leggi questo approfondimento sugli attacchi di consenso in Entra ID e scopri perché una buona governance non è automatica consultando questo podcast sull'illusione della governance in Microsoft 365.

Rilevare e monitorare l'uso dei protocolli legacy negli ambienti aziendali

Trovare e monitorare l'uso dell'autenticazione legacy è come cercare perdite nascoste in un vasto sistema idraulico. È facile perdere di vista i protocolli residui, perché queste connessioni non sono sempre in primo piano nelle dashboard moderne. Eppure, ogni istanza non individuata, che sia un vecchio script di backup, una stampante o un sensore IoT, offre agli attaccanti un'altra occasione per entrare.

Per affrontare il problema, gli ambienti Microsoft 365 e Azure offrono una serie di log e strumenti analitici pensati per una visibilità approfondita. Ma bisogna sapere dove guardare e come interpretare risultati che non sempre segnalano esplicitamente «autenticazione legacy qui». Combinando i log di accesso, le tracce di audit e la telemetria personalizzata di strumenti come PowerShell e Python, si ottiene un quadro più completo di dove i vecchi protocolli sfuggono ai controlli. Incrociare i dati di risorse cloud e on-premises è fondamentale, perché le configurazioni ibride spesso hanno report incoerenti.

Cosa rende la sfida ancora più complessa? Alcuni dispositivi di terze parti e OT continuano a usare protocolli legacy in modo silenzioso e raramente vengono inclusi nelle scansioni di sicurezza o nei report analitici standard. I team di sicurezza devono stratificare più tecniche di monitoraggio, dalle cartelle di lavoro di accesso di Azure all'estrazione dal Registro di controllo unificato, per individuare ogni traccia residua di utilizzo dei protocolli. Per un'analisi pratica su come verificare l'attività nel tuo tenant e perché segnali più ricchi contano per conformità e sicurezza, consulta questa guida a Microsoft Purview Audit.

Le sottosezioni seguenti ti guideranno passo dopo passo nell'individuare e analizzare le tracce di autenticazione legacy nel tuo ambiente, con suggerimenti pratici per generare telemetria utilizzabile, così che queste vulnerabilità nascoste non restino nascoste a lungo.

Individuare l'autenticazione legacy nei log di accesso di Azure e nelle cartelle di lavoro analitiche

Individuare l'autenticazione legacy nei log di accesso di Azure e nelle analisi di Entra ID richiede un approccio proattivo. Ecco una checklist pratica per riconoscere questi protocolli rischiosi in azione:

Filtra per tipo di app client:
Inizia dai log di accesso di Azure AD nel portale di Azure. Filtra le voci per «Client App» per mostrare le connessioni effettuate con protocolli legacy come IMAP, POP3, SMTP e «Altri client». Queste voci di solito si distinguono perché non usano flussi di autenticazione basati su browser o moderni.
Cerca i metodi di autenticazione:
Approfondisci gli eventi di accesso con «Authentication Method» impostato su «Password» ma senza «MFA» o «Modern Auth». Questo spesso indica protocolli che aggirano l'accesso condizionale, soprattutto da dispositivi meno recenti o script di automazione.
Configura le cartelle di lavoro analitiche:
Usa Azure Monitor o le cartelle di lavoro di Entra ID Analytics per visualizzare le tendenze nel tempo. Crea una cartella di lavoro personalizzata per rappresentare graficamente l'utilizzo dei protocolli, evidenziare i picchi di autenticazione legacy e segnalare le connessioni client non conformi.
Correla con i dati di dispositivo e posizione:
Incrocia gli eventi di autenticazione legacy con le informazioni sul dispositivo e la geolocalizzazione dell'accesso. Combinazioni inattese, come un accesso con un protocollo legacy da un Paese in cui la tua azienda non opera, meritano un'attenta verifica.
Suggerimenti per la risoluzione dei problemi:
Se i risultati sembrano scarsi, verifica la presenza di lacune nei criteri o nella conservazione dei log. Alcuni eventi potrebbero essere filtrati o non registrati se le impostazioni di controllo non sono complete oppure se hai esclusioni nei criteri di accesso condizionale.

Ripetendo questi passaggi, otterrai una visibilità affidabile. Ricorda che anche solo qualche voce di protocollo legacy nei log può segnalare rischi maggiori altrove: scava in profondità e segui i dati dovunque ti portino.

Generare telemetria con PowerShell, Python e i log di controllo unificati: esempi e buone pratiche

Per individuare ogni traccia di attività con protocolli legacy, nulla batte la telemetria personalizzata. Ecco come configurarla con PowerShell, Python e il registro di controllo unificato di Microsoft:

Query PowerShell per i protocolli legacy:
Usa i cmdlet Get-Mailbox e Get-CASMailbox in Exchange Online per elencare gli utenti con IMAP, POP3 o SMTP AUTH abilitati. Incapsulali in script per generare report giornalieri o settimanali, da incrociare con le informazioni dei log di accesso.
Automazione con Python per la correlazione dei log:
Usa script Python per connetterti all'API di Microsoft Graph e recuperare i record di accesso e di controllo delle caselle di posta. Analizza i tipi di app client e i flag del protocollo di autenticazione, quindi restituisci le anomalie, come gli account di servizio senza interfaccia che usano l'autenticazione legacy.
Registro di controllo unificato per il monitoraggio centralizzato:
Abilita Microsoft Purview Audit (in precedenza Unified Audit Log) per aggregare le attività di Exchange, SharePoint, Teams e altri servizi. Interroga i campi Operation relativi alle connessioni client legacy o ai tentativi di autenticazione legacy non riusciti, per una pipeline di rilevamento consolidata.
Implementa visualizzazioni interattive e avvisi:
Esporta o trasmetti la telemetria verso Microsoft Sentinel o Power BI. Crea dashboard con regole di avviso che si attivano al rilevamento di nuovo utilizzo di protocolli legacy o quando vengono individuate esposizioni di credenziali.
Attenzione ai problemi:
Diffida dei dati incompleti dovuti a conservazione limitata dei log, lacune nella configurazione predefinita o eventi non registrati per impostazione predefinita. Verifica sempre la copertura con accessi di prova tramite protocolli legacy prima di dichiarare il lavoro concluso.

Per approfondire come integrare la telemetria nella governance e nell'automazione (quando il contenuto sarà di nuovo disponibile), tieni d'occhio gli aggiornamenti su questa pagina mancante sull'automazione con PowerShell oppure consulta i recenti episodi del podcast sull'architettura aziendale per scoprire le prossime novità sulle strategie di telemetria.

Strategie di mitigazione: blocco e disattivazione dei protocolli legacy

Sapere di utilizzare protocolli legacy è solo la prima battaglia; vincerla significa chiudere questi canali senza compromettere l'operatività aziendale. L'approccio giusto consiste nel bilanciare riduzione del rischio e continuità operativa. Microsoft 365 e Azure AD offrono strumenti potenti, come i criteri di accesso condizionale e le impostazioni di amministrazione, per bloccare i metodi di autenticazione obsoleti su scala aziendale, ma vanno implementati con attenzione.

Le due tattiche principali sono: usare i criteri di accesso condizionale per bloccare in modo generalizzato l'autenticazione legacy e disattivare protocolli come SMTP AUTH, IMAP e POP3 per l'accesso alla posta e ai dispositivi. Il punto chiave è individuare ogni eccezione e ogni flusso di lavoro interessato prima di interrompere il servizio, soprattutto per gli account di servizio, i sistemi di posta locali in ambienti ibridi o le integrazioni di terze parti che non possono essere facilmente modernizzate. Le implementazioni graduali e gli aggiornamenti mirati dei criteri aiutano a non compromettere i processi critici, riducendo al contempo l'esposizione al furto di credenziali e agli abusi di spam.

È altrettanto importante combinare le modifiche ai criteri con la consapevolezza del business. Coinvolgi gli stakeholder, testa le modifiche su gruppi più piccoli e usa le analisi per dimostrare che il cambiamento non bloccherà le attività. Nelle sezioni seguenti troverai istruzioni passo passo e considerazioni sia per l'applicazione dei criteri di accesso condizionale sia per la disattivazione dei protocolli nell'interfaccia di amministrazione di Microsoft 365. Ti chiedi quali rischi nascosti emergano quando le abitudini di lavoro non vengono misurate? Dai un'occhiata a questo podcast sulla deriva della conformità e sull'applicazione dei criteri per approfondire.

Con il piano giusto, bloccare i protocolli legacy non si limiterà a spuntare le caselle di conformità: renderai molto più difficile agli attaccanti trovare quella porta dimenticata aperta.

Come bloccare l'autenticazione legacy con l'accesso condizionale

Bloccare l'autenticazione legacy con i criteri di accesso condizionale di Azure AD è potente e preciso, se fatto nel modo giusto. Ecco cosa devi sapere:

I criteri di accesso condizionale consentono alle organizzazioni di bloccare esplicitamente i tentativi di autenticazione dai protocolli più datati, come SMTP AUTH, IMAP, POP3 e i client di autenticazione di base. Puoi limitare questi criteri a utenti, gruppi o dispositivi e monitorare il potenziale impatto sul business in modalità «solo report» prima di attivarli. Questo approccio graduale ti dà la possibilità di individuare eventuali dipendenze che potrebbero interrompersi se il blocco fosse applicato di colpo.

Microsoft consiglia di creare almeno due criteri fondamentali: uno che blocchi l'autenticazione legacy per tutti gli utenti e un secondo con esclusioni a tempo per gli account di servizio o per eccezioni note. I test sono essenziali: inizia con la modalità di monitoraggio per osservare quali account e app tentano l'accesso con protocolli legacy, poi passa all'applicazione quando sei sicuro che verranno interrotti solo flussi non essenziali.

Non dimenticare di rivedere e ridurre al minimo gli elenchi di elementi consentiti e le eccezioni ereditate: creano falle di sicurezza invisibili. Il monitoraggio continuo e gli avvisi sui tentativi di autenticazione legacy aiuteranno a individuare nuovi rischi man mano che l'ambiente IT cambia. Per altre best practice e una base solida di criteri inclusivi, leggi il parere di questo esperto sulla messa a punto dell'accesso condizionale per una gestione degli accessi prevedibile e sicura.

In sintesi: rafforzare l'accesso condizionale è la tua prima linea di difesa. Assicurati però di applicare le modifiche in modo metodico, bilanciando sempre le esigenze del business e gli obiettivi di sicurezza.

Disattivare SMTP AUTH e i protocolli di posta legacy nell'interfaccia di amministrazione di Microsoft 365

Disattivare SMTP AUTH e gli altri protocolli di posta legacy è uno dei modi più rapidi per ridurre il furto di credenziali e impedire agli attaccanti di inviare spam attraverso il tuo tenant. Ecco come procedere passo passo:

Verifica l'utilizzo attuale:
Inizia con Exchange Online PowerShell (Get-TransportConfig e Get-Mailbox). Individua le cassette postali con SMTP AUTH abilitato e i protocolli IMAP/POP3 ancora attivi per utenti o account di servizio.
Disattiva a livello di tenant:
L'interfaccia di amministrazione di Microsoft 365 ora consente di disattivare SMTP AUTH per l'intero tenant con una sola impostazione. Questo blocca tutti i nuovi tentativi di autenticazione, a meno che non vengano previste eccezioni per specifiche cassette postali.
Pulizia mirata dei criteri:
Per gli utenti o le app che necessitano davvero di SMTP AUTH, limita esplicitamente l'accesso e monitora attentamente. Rimuovi le autorizzazioni IMAP/POP3 a tutti tranne agli account più essenziali, idealmente a nessuno.
Testa e comunica:
Prima di disattivare su larga scala, esegui casi di test e informa utenti o responsabili dei sistemi. Tieni d'occhio i ticket dell'help desk legati a automazioni interrotte, quindi lavora con questi team per aggiornare i loro processi o passare all'autenticazione moderna.
Monitora dopo il rollout:
Controlla i log di controllo per individuare i tentativi falliti con protocolli legacy. Errori persistenti possono indicare tentativi di attacco o dipendenze aziendali non individuate che dovrai gestire.

Questo approccio blocca sul nascere la maggior parte degli attacchi alle credenziali via email più comuni e rende molto più serena la squadra di conformità. Controlli solidi fin dall'inizio significano interventi di pulizia più ridotti in seguito.

Governance della sicurezza e supervisione strategica del rischio dei protocolli legacy

Bloccare i protocolli legacy non significa solo modificare impostazioni tecniche. La vera gestione del rischio avviene ai vertici, dove leadership esecutiva, team delle operazioni di sicurezza e architetti IT lavorano insieme per governare il ciclo di vita sia della tecnologia sia dei criteri. Il problema è che la maggior parte delle grandi organizzazioni si affida a un insieme eterogeneo di controlli, criteri e fornitori terze parti, e questo rende difficile far rispettare una supervisione coerente su larga scala.

Una strategia di governance efficace affronta domande importanti: come gestisci il rischio quando integrazioni di terze parti, strumenti agentici e shadow IT seguono tutti regole diverse? Come applichi controlli uniformi quando metà dei partner o dei dispositivi IoT "fidati" non riescono nemmeno a utilizzare l'autenticazione moderna? E come monitori in modo continuo la deriva dei criteri mentre cambiano l'azienda, la forza lavoro e il panorama della sicurezza?

È qui che entrano in gioco i framework di governance virtuali, la disciplina nella gestione dei criteri e l'intelligenza avanzata. La leadership non deve solo dare il tono dall'alto, ma anche implementare verifiche concrete: dalla valutazione dei fornitori di servizi più rischiosi all'esecuzione di audit e all'adozione dell'automazione per rilevare e correggere i problemi. Con l'IA e l'automazione che avanzano più velocemente che mai, l'obiettivo è allineare strumenti, criteri e persone.

Nelle sezioni seguenti vedremo come CISO e decisori possono costruire modelli di governance "remote-first", gestire i rischi più imprevedibili legati a terze parti e agenti, e sfruttare l'intelligenza moderna per chiudere una volta per tutte le lacune dei protocolli. Per approfondire come bilanciare innovazione e supervisione, consulta questi suggerimenti sulla governance di Power Platform e scopri come tenere il passo quando automazioni e agenti si muovono più velocemente dei tuoi criteri in questo episodio con un framework pratico di governance.

Come i leader della sicurezza proteggono l'organizzazione dai fornitori terze parti più rischiosi in un framework di governance virtuale

Le organizzazioni più avanzate adottano un approccio stratificato e proattivo per governare il rischio dei protocolli legacy, in particolare quello legato alle terze parti. Ecco quattro strategie pratiche:

Implementa la supervisione degli agenti: monitora e controlla tutti gli account di servizio, gli agenti e le integrazioni di terze parti che interagiscono con il tuo ambiente. Usa identità univoche (come gli Entra Agent ID) per gli agenti e applica contratti rigorosi tramite piattaforme come Microsoft Connector Platform (MCP). Questo aiuta a prevenire la deriva delle identità e la perdita di responsabilità, soprattutto con le integrazioni basate sull'IA (approfondimenti sulla governance degli agenti qui).
Applica criteri di autenticazione sicura: richiedi a tutti i fornitori e i partner di usare l'autenticazione moderna, senza eccezioni per la "compatibilità con i sistemi legacy" se non sono previsti controlli compensativi approvati. Verifica con regolarità le esclusioni di Accesso condizionale per i dispositivi di terze parti e per i flussi basati su connettori.
Separa e monitora i dispositivi OT/IoT e quelli non aggiornabili: quando hai dispositivi di tecnologia operativa o IoT vincolati a protocolli legacy, segmentali su reti isolate. Applica controlli compensativi come il monitoraggio di rete e la lista di accesso consentito per ridurre l'esposizione alle minacce di movimento laterale.
Esegui revisioni di governance remote e virtuali: adotta framework di governance virtuali per monitorare, correggere e governare da qualsiasi luogo. Questi framework si basano su revisioni periodiche, audit automatizzati e una comunicazione chiara tra gli stakeholder, elementi essenziali man mano che sempre più operazioni diventano ibride o remote.

Concentrandosi su una supervisione stratificata e non solo su controlli tecnici, CISO e responsabili IT possono mitigare i rischi provenienti dalle parti più difficili da raggiungere del loro ecosistema.

Sfruttare l'intelligenza avanzata per potenziare le operazioni di sicurezza contro le minacce legacy

Gli strumenti di intelligenza basati sull'IA e l'analisi avanzata delle minacce offrono alle organizzazioni un vantaggio nel rilevare, indagare e rispondere agli abusi dei protocolli legacy su larga scala. Queste piattaforme usano il machine learning per individuare comportamenti di autenticazione anomali, filtrare rapidamente gli utilizzi sospetti dei protocolli legacy e correggere automaticamente le minacce senza ritardi dovuti all'intervento umano.

I moderni team di operazioni di sicurezza integrano i dati di Microsoft Sentinel, Purview Audit e analisi comportamentali basate sull'AI per costruire una visione centralizzata dell'attività di autenticazione, sia moderna sia legacy. I playbook automatizzati possono attivare risposte per eccezioni ai criteri, account di servizio ad alto rischio o eventi di relay delle credenziali, chiudendo le falle prima che un attaccante possa sfruttarle.

Integrare automazione e analisi non è un'opzione: è una necessità. Le piattaforme di orchestrazione aiutano a unificare i dati di ambienti cloud, on-premises e ibridi, assicurando che anche i flussi di autenticazione legacy meno noti non sfuggano all'attenzione. Questo è ancora più critico man mano che si diffondono agenti AI e automazioni su larga scala, aumentando sia i benefici sia i rischi operativi.

Infine, applicare l'accesso con privilegi minimi, etichettare i contenuti sensibili ed estendere il monitoraggio di audit aiuta a tenere sotto controllo sia gli utenti umani sia quelli automatizzati. Per un modello pratico su come usare analisi avanzata e AI per tenere a bada le minacce legacy negli ambienti Microsoft, inclusi Copilot e bot di terze parti, consulta questa guida dettagliata su AI governata e conformità.