Wer regelmäßig in Azure-Umgebungen arbeitet, kennt das Thema: Azure Storage TLS 1.2 gilt längst als Best Practice, trotzdem halten sich manche Altlasten hartnäckig. Übergangsfristen gibt es jetzt keine mehr. Nach der aktuellen Ankündigung nimmt Azure Storage ab dem 3. Februar 2026 keine Verbindungen über TLS 1.0 und 1.1 mehr an. In vielen Tenants, die ich betreue, finde ich nach wie vor ältere Storage Accounts mit einer niedrigeren Mindest-TLS-Version, und immer wieder hängen Anwendungen überraschend an den alten Protokollen. Auf dem Papier ist die Umstellung eine Kleinigkeit. In der Praxis stößt man dagegen oft auf einen Flickenteppich aus alten .NET-Anwendungen, betagten Java-Stacks und Drittanbieter-Tools, an die sich keiner mehr erinnert.

Die Mindest-TLS-Version steht in der Konfiguration des Storage Accounts

Für den ersten Überblick genügt das Azure-Portal. Im Storage Account liegt unter Einstellungen → Konfiguration die Option „Mindest-TLS-Version“. Steht dort noch TLS 1.0 oder 1.1, besteht Handlungsbedarf. Auf TLS 1.2 umgestellt ist schnell, dafür reichen ein paar Klicks. Danach blockiert der Storage Account allerdings sofort alle Clients und Dienste, die noch mit den älteren Versionen arbeiten. Gerade bei alten Backup-Lösungen oder selbst gebauten Tools in Produktionsumgebungen begegnen mir regelmäßig uralte .NET-Framework-Versionen, die von Haus aus keine modernen Cipher Suites beherrschen.

Eine Azure Policy setzt TLS 1.2 im ganzen Unternehmen durch

Damit einzelne Storage Accounts schwache Protokolle gar nicht erst zulassen, lohnt sich eine Azure Policy. Microsoft bringt dafür eine passende Built-in-Policy mit: „Configure minimum TLS version for Storage Accounts“. Mit ihr legt man auf Subscription- oder Managementgruppenebene zentral fest, dass nur noch TLS 1.2 erlaubt ist. Das gilt für bestehende Accounts ebenso wie für neu angelegte. Meist richte ich die Policy so ein, dass sie Verstöße zunächst nur meldet und sie erst in einem zweiten Schritt automatisch behebt. Eine Übersicht über alle Storage Accounts und ihre TLS-Einstellungen bietet das Azure-Policy-Portal unter „Compliance“.

Praxis-Tipp: In größeren Mandanten dokumentiere ich Ausnahmen von der Policy sehr genau. Eine Whitelist der Altanwendungen, die noch migriert werden müssen, erleichtert die Projektsteuerung und bewahrt vor unangenehmen Überraschungen, wenn die älteren TLS-Versionen endgültig wegfallen.

Log Analytics und StorageBlobLogs verraten die alten Clients

Interessant wird es bei der Frage, welche Systeme überhaupt noch TLS 1.0 oder 1.1 verwenden. Hier helfen die Diagnoseeinstellungen des Storage Accounts weiter. Wer die StorageBlobLogs in einen Log Analytics Workspace schreibt, kann die Spalte TlsVersion auswerten. Dafür müssen die Diagnoseeinstellungen des Storage Accounts passend konfiguriert sein, also mindestens „Blob“- und „Lesen“-Events mit einem Log Analytics Workspace als Ziel.

Mit dieser KQL-Abfrage (Log Analytics Workspace → Logs) suche ich alle Verbindungen der letzten 30 Tage heraus, die mit alten TLS-Versionen aufgebaut wurden:

StorageBlobLogs
| where TlsVersion in ('TLS1_0', 'TLS1_1')
| summarize Anzahl=count() by AccountName, ClientIP, TlsVersion, bin(TimeGenerated, 1d)
| sort by Anzahl desc

Im Ergebnis sieht man, welche Client-IP oder Anwendung sich mit welchem Storage Account über welche veraltete TLS-Version verbunden hat. Taucht hier etwas auf, sollte man die betroffenen Systeme möglichst schnell ausfindig machen oder sie wenigstens dokumentieren.

Wie man die Diagnoseeinstellungen im Detail konfiguriert, beschreibt Microsoft hier: Transport Layer Security (TLS) für Azure Storage konfigurieren.

Das eigentliche Risiko steckt in vergessenen Altlasten

Nach meiner Erfahrung lauern die größten Risiken an diesen Stellen:

  • Ältere .NET-Framework-Anwendungen (vor 4.6), in denen starke Verschlüsselung nicht ausdrücklich aktiviert ist
  • Java-Clients mit veralteter JVM (TLS 1.2 ist erst ab Java 7u131 Standard)
  • Backup- und Migrationstools, für die der Hersteller keine Updates mehr liefert
  • Selbst geschriebene Skripte oder kleine Automatisierungen, die noch uralte REST-APIs ansprechen
  • IoT-Geräte oder Embedded-Lösungen mit fest eingebauter TLS-Implementierung

Vor allem bei Backup und Archivierung stoße ich immer wieder auf Schatten-IT, die anfangs niemand auf dem Schirm hat. Erzwingt man dann TLS 1.2 im Storage Account, drohen dem Team auf einmal Datenverlust oder Stillstand. Deshalb empfehle ich, das Thema jetzt anzupacken.

Ein Diagramm zeigt den Weg vom abgelehnten Client ins Log

Damit der Ablauf der TLS-Erkennung im Monitoring greifbarer wird, habe ich ein Diagramm erstellt. Es zeigt, wie Azure Storage einen Client mit veralteter TLS-Version abweist und wie dieser Vorgang anschließend im Log Analytics Workspace auftaucht:

sequenceDiagram
    participant Client as "[Client mit TLS1.0/1.1]"
    participant AzureStorage as "[Azure Storage Account]"
    participant LogAnalytics as "[Log Analytics Workspace]"
    Client->>AzureStorage: "[Verbindungsversuch mit TLS1.0]"
    AzureStorage-->>Client: "[Verbindung abgelehnt]"
    AzureStorage->>LogAnalytics: "[Event mit TlsVersion]"

Abbildung: Azure Storage lehnt eine alte TLS-Verbindung ab und protokolliert sie im Log Analytics Workspace.

Eine frühe Bestandsaufnahme erspart den Stress kurz vor der Abschaltung

Die Umstellung auf Azure Storage TLS 1.2 trifft so gut wie jede Azure-Umgebung, die schon länger besteht oder Drittanbieter einbindet. Mein Rat: Prüfen Sie jetzt die TLS-Konfiguration aller Storage Accounts, regeln Sie die Durchsetzung über Azure Policy und werten Sie die StorageBlobLogs gezielt nach alten TLS-Versionen aus. Erst dann zeigt sich, wie viele Altsysteme tatsächlich betroffen sind, und man kann gemeinsam mit Entwicklern, Admins oder Dienstleistern belastbare Migrationspläne erstellen. Die Frist steht fest, daher gehört das Thema auf die Projektliste 2025 und nicht in den Januar 2026, wenn nur noch hektisches Reagieren bleibt. Wer sich bei der Kompatibilität einzelner Clients nicht sicher ist, findet Hilfe in Microsofts Monitoring-Dokumentation für Blob Storage. Im Zweifel fahre ich lieber vorher einen Testlauf, denn Überraschungen kommen erfahrungsgemäß immer dann, wenn man sie am wenigsten brauchen kann.