Shared Key in Azure Storage lässt sich sauber durch Entra ID ersetzen

In vielen Tenants, die ich betreue, ist die Shared-Key-Autorisierung für Azure-Storage-Accounts nach wie vor eingeschaltet – meist aus Gewohnheit oder weil es „schon immer so läuft“. In Umgebungen mit Compliance-Vorgaben oder sensiblen Daten ist das allerdings ein ernstes Risiko. Wer den Shared Key in Azure Storage abschalten möchte, sollte die Folgen kennen und vorher genau durchdenken, wie Entra-ID-Rollen, Anwendungen und bestehende Abläufe ineinandergreifen.

Der Account-Schlüssel öffnet praktisch den gesamten Storage-Account

Wer den Account-Schlüssel besitzt, hat praktisch Vollzugriff auf alle Daten und Funktionen des Storage-Accounts. Daraus lassen sich Account-SAS-Tokens erzeugen (was in der Praxis auch passiert), die Zugriff auf sämtliche Container und Blobs gewähren. Häufig sind sie lange gültig und landen in Skripten, Tools oder sogar bei Dritten. Überwachen lassen sich solche Tokens kaum, fein einschränken auch nicht, und in den üblichen Audit-Logs tauchen sie meist gar nicht erst auf. Gerät ein Schlüssel in falsche Hände, bleibt nur die vollständige Key-Rotation – und die kann in großen Organisationen einiges durcheinanderbringen.

RBAC auf Datenebene mit Entra ID erlaubt dagegen eine deutlich feinere und nachvollziehbare Rechtevergabe. Statt den Master-Schlüssel pauschal herauszugeben, weist man Benutzern, Gruppen oder Managed Identities gezielt Rollen wie Storage Blob Data Reader oder Storage Blob Data Contributor zu. Mehr dazu steht etwa in diesem Microsoft-Learn-Artikel.

Praxistipp: Auch während der Übergangsphase sollte man die Account Keys weiterhin regelmäßig rotieren, vor allem wenn sich nicht alle Legacy-Anwendungen oder Skripte sofort umstellen lassen.

Vor dem Abschalten muss klar sein, wer den Schlüssel noch nutzt

Bevor man AllowSharedKeyAccess auf false setzt und die Shared-Key-Authentifizierung damit abschaltet, sollte man wissen, wo der Schlüssel überall verwendet wird. Viele Dienste, Tools und interne Skripte greifen nämlich unbemerkt per Schlüssel zu. Das bekannteste Beispiel ist der Azure Storage Explorer.

Ohne Monitoring tappt man hier im Dunkeln. Azure Monitor liefert die nötigen Metriken und Logs, eine Anleitung dazu gibt es unter Shared-Key-Autorisierung überwachen. Für einen ersten Überblick reicht im Azure-Portal Speicherkonto → Überwachung → Metriken. Dort wählt man die Metrik „Transaktionen“ und schlüsselt sie über „Aufteilung anwenden“ nach der Dimension „Authentifizierung“ auf. Der Wert „AccountKey“ steht für die Zugriffe per Shared Key. Will man genau wissen, wer zugreift, aktiviert man unter Überwachung → Diagnoseeinstellungen für „blob“ die Kategorien StorageRead, StorageWrite und StorageDelete, schickt sie an einen Log-Analytics-Workspace und wertet sie dort unter Protokolle per KQL aus:

StorageBlobLogs
| where AuthenticationType == "AccountKey"
| summarize Anzahl = count() by AccountName, CallerIpAddress, UserAgentHeader

So erkennt man, welche Accounts und Clients den Schlüssel aktuell verwenden, und kann sie gezielt umstellen.

Das folgende Diagramm stellt Shared Key und Entra ID (RBAC) auf der Datenebene einander gegenüber:

flowchart TD
  user["Benutzer/Tool"] --> sharedkeyauth["Shared Key Auth"]
  sharedkeyauth --> allaccess["Vollzugriff auf Storage"]
  user --> entraauth["Entra ID Auth"]
  entraauth --> rbacroles["RBAC-Rollen (z.B. Reader)"]
  rbacroles --> containeraccess["Gezielter Zugriff auf Container/Blob"]

Abbildung: Shared Key und Entra-ID-RBAC beim Zugriff auf Azure Storage im Vergleich.

Nach dem Umstieg regeln RBAC-Rollen und kurzlebige Tokens den Zugriff

Sobald die Authentifizierung über Entra ID läuft, vergibt man Rechte auf Datenebene nur noch über die passenden RBAC-Rollen. Anwendungen erhalten am besten eine Managed Identity. Sie fordert für jeden Zugriff ein temporäres Token an und kommt deshalb ohne dauerhaft gespeicherte Secrets aus. Für Benutzer lassen sich User-Delegation-SAS-Tokens ausstellen. Diese sind kurzlebig, auditierbar und reichen nie weiter als die Rechte des jeweiligen Benutzers. Einen knappen Überblick bietet die Microsoft-Dokumentation zum Erstellen solcher SAS per CLI.

Ein User Delegation SAS lässt sich mit der Azure CLI zum Beispiel so erzeugen:

az storage blob generate-sas \
  --account-name <storageaccount> \
  --container-name <container> \
  --name <blob> \
  --as-user \
  --auth-mode login \
  --permissions r \
  --expiry 2024-06-30T23:59Z

Auf diese Weise delegiert man Zugriff gezielt und befristet, ohne sich die Risiken eines Account-Schlüssels einzuhandeln.

Das Flag AllowSharedKeyAccess hat spürbare Nebenwirkungen

Entscheidend ist das Flag AllowSharedKeyAccess. Steht es auf false, akzeptiert Azure Storage nur noch Anmeldungen über Entra ID (und SAS, die auf User Delegation beruhen). Viele ältere Tools streiken danach, etwa der Azure Storage Explorer in der Standardkonfiguration. Auch manche Microsoft-Dienste wie klassische Backup-Jobs oder Logic Apps können betroffen sein. Ich habe die Erfahrung gemacht, dass man um einen Einzeltest jeder betroffenen Anwendung nicht herumkommt. Wo nötig, stellt man sie auf andere Authentifizierungsmethoden um oder spielt Updates ein. Bis tatsächlich alles umgestellt ist, empfehle ich einen Parallelbetrieb, über den alle Beteiligten klar informiert sind. Wer das Risiko frühzeitig senken will, kann mit Azure Policy bereits jetzt alle Accounts kennzeichnen, die Shared Key noch zulassen, oder für neue Deployments AllowSharedKeyAccess=false von Anfang an vorschreiben.

Sichere Azure-Storage-Accounts sind kein Hexenwerk

Für mich ist das Abschalten von Shared Key keine Kür, sondern mittelfristig Pflicht – ähnlich wie der Wechsel zu RBAC für Azure Key Vault. Mit etwas Vorbereitung, sauberem Monitoring und durchdachtem Change Management gelingt die Migration auch in gewachsenen Umgebungen. Wer jetzt ordentlich umstellt, erspart sich später Kopfzerbrechen, Stress bei Audits und teure Incident-Response-Einsätze.