Da ieri, 3 febbraio, Azure Storage ha smesso ufficialmente di supportare TLS 1.0 e TLS 1.1, con il requisito minimo che diventa TLS 1.2. In realtà, non è un annuncio improvviso visto che Microsoft aveva comunicato da anni la scadenza e, a più riprese, ha ribadito che questa sarebbe stata la linea rossa oltre la quale i protocolli deprecati non sarebbero più stati accettati.

Il controllo della versione minima di TLS viene applicato a livello di storage account. Significa che non riguarda soltanto Blob Storage, cioè il servizio più noto e utilizzato per archiviare oggetti, ma anche tutte le altre componenti dello stesso account, ovvero Azure Files, Queue Storage e Table Storage. In pratica, se un’applicazione o un dispositivo si collega a uno di questi servizi con TLS inferiore alla versione 1.2, la connessione fallisce e l’accesso ai dati diventa impossibile.

Per capire perché questa decisione sia così importante, serve ricordare cos’è TLS. Transport Layer Security è il protocollo che cifra le comunicazioni tra client e server, tipicamente quando si usa HTTPS. È la tecnologia che impedisce intercettazioni, manipolazioni e attacchi di tipo man-in-the-middle. Quando un’applicazione legge o scrive dati su Azure Storage via HTTPS, l’intero scambio è protetto da TLS. Se TLS è debole, o peggio obsoleto, l’intero modello di sicurezza perde significato.

TLS 1.0 e TLS 1.1 appartengono davvero a un’altra epoca. TLS 1.0 risale addirittura al 1999, un periodo in cui Internet era dominato da architetture e minacce completamente diverse. TLS 1.1 è invece del 2006, prima che il cloud diventasse un’infrastruttura industriale globale e prima che concetti come compliance, zero trust e supply chain security entrassero nel vocabolario quotidiano dell’IT. TLS 1.2 è del 2008 e, nonostante l’età, è ancora oggi lo standard minimo ragionevole in contesti enterprise. TLS 1.3 è stato pubblicato nel 2018 e rappresenta l’evoluzione naturale, con handshake più rapido e un set crittografico più moderno.

La scelta di Microsoft di mantenere TLS 1.0 e 1.1 così a lungo è stata dettata quasi interamente dalla compatibilità retroattiva. In particolare, molte installazioni Windows legacy hanno storicamente avuto TLS 1.0 attivo di default. Windows 7 è l’esempio più citato: TLS 1.2 era supportato, ma spesso non abilitato senza modifiche manuali o aggiornamenti specifici. Per un provider cloud globale, tagliare fuori in modo netto questi client significa accettare che una parte di workload storici smetta di funzionare. È una decisione impopolare, ma inevitabile.

Crediti: Shutterstock

Crediti: Shutterstock

Microsoft, del resto, ha tentato più volte di chiudere questa partita. Inizialmente, la dismissione era stata fissata al 1° novembre 2024. Poi il termine è stato rinviato di un anno, al 1° novembre 2025 e, infine, è stato concesso un ulteriore margine fino al 3 febbraio 2026. Un percorso che somiglia molto a una migrazione forzata, gestita con gradualità per ridurre il rischio di downtime ma con il preciso obiettivo di arrivare a un punto in cui il cloud non debba più accettare protocolli crittografici deprecati.

Le ragioni per passare a TLS 1.2 sono numerose e, in larga parte, incontestabili. Dal punto di vista delle performance, TLS 1.2 è più efficiente dei predecessori, soprattutto in combinazione con suite crittografiche moderne. Dal punto di vista della sicurezza, offre protezioni superiori e una maggiore robustezza contro vulnerabilità note che hanno colpito versioni precedenti. C’è poi l’elemento compliance, per cui continuare a utilizzare protocolli dichiarati obsoleti rende difficile, se non impossibile, giustificare l’aderenza a framework normativi e audit di sicurezza.

Il vero nodo, come quasi sempre, è la coda lunga dei sistemi legacy. Alcune versioni storiche di SQL Server e Windows Server si appoggiavano a stack TLS pre-1.2 o avevano implementazioni che, per configurazione o limiti applicativi, restavano bloccate su protocolli obsoleti. Oggi i sistemi moderni disabilitano questi protocolli di default: Windows 11, ad esempio, sta progressivamente chiudendo ogni spiraglio. Eppure, il problema non è solo nel sistema operativo, visto che esistono applicazioni sviluppate anni fa che hanno TLS 1.0 o 1.1 hardcoded, cioè incorporato direttamente nel codice, senza possibilità di negoziazione o upgrade tramite configurazione.

Azure Storage è soltanto l’ultimo tassello di un processo già avviato da tempo. Microsoft 365, ad esempio, ha disabilitato TLS 1.0 e 1.1 da anni, proprio per ridurre la superficie d’attacco e uniformare i requisiti minimi. Ora la stessa logica arriva sullo storage, che è una componente critica: se lo storage cade, cade l’intera applicazione.

La conseguenza pratica, per chi non ha completato la migrazione, è che qualunque client che tenti di connettersi con TLS inferiore a 1.2 non riuscirà più ad accedere ai servizi di Azure Storage. Un blocco totale della connessione con effetti immediati su applicazioni, pipeline, integrazioni, backup, flussi ETL e qualunque componente che usi Azure Storage come backend.

Per molte organizzazioni questa scadenza significa aggiornare librerie, sostituire componenti legacy, rivedere integrazioni con dispositivi o software datati e, soprattutto, individuare in modo preciso dove, nella catena applicativa, si annida ancora un client che parla TLS 1.0 o 1.1.

(Immagine in apertura: Shutterstock)