Rays Cloud Blog

User Delegation SAS mit Entra ID-Binding: Schluss mit anonymen Storage-Tokens

Ray Ünal

Die neue Preview für identitätsgebundene SAS-Tokens ändert die Spielregeln bei Azure Blob Storage. Was das Feature kann, warum es überfällig war und wie du es heute schon testest.

User Delegation SAS mit Entra ID-Binding: Schluss mit anonymen Storage-Tokens

Shared Access Signatures gehören seit Jahren zum Standardrepertoire jedes Azure-Architekten. Und seit Jahren sind sie ein Sicherheitskompromiss, den wir in Kauf nehmen, weil die Alternative – Storage Account Keys direkt weitergeben – noch schlimmer wäre.

Das Problem: Wer ein SAS-Token besitzt, hat Zugriff. Egal ob die Person noch im Unternehmen ist, ob sie die Berechtigung noch haben sollte, oder ob das Token vor sechs Monaten für einen einmaligen Datentransfer gedacht war. Ein klassisches Account-Key-basiertes SAS-Token kennt keine Identität. Es kennt nur den Key.

Microsoft hat das jetzt geändert. Die neue Preview für User Delegation SAS mit Entra ID-Binding bindet SAS-Tokens an konkrete Identitäten – und löst damit gleich mehrere Probleme, die uns seit Jahren begleiten.

Kurzer Rückblick: Die drei SAS-Typen

Bevor wir ins Detail gehen, ein schneller Vergleich der drei SAS-Varianten, die Azure Storage kennt:

SAS-TypSigniert mitIdentitätsbezugWiderruf bei Offboarding
Account SASAccount KeyKeinerNur durch Key Rotation (bricht alle Tokens)
Service SASAccount KeyKeinerNur durch Key Rotation oder Stored Access Policy
User Delegation SASEntra ID CredentialsJa, an Security Principal gebundenSofort bei Deaktivierung der Identität

Die ersten beiden Varianten teilen sich dasselbe Grundproblem: Sie hängen am Account Key. Wer den Key rotiert, invalidiert alle existierenden Tokens auf einmal – auch die, die noch gebraucht werden. Wer nicht rotiert, lebt mit dem Risiko.

Was User Delegation SAS anders macht

Der fundamentale Unterschied: Ein User Delegation SAS wird nicht mit dem Storage Account Key signiert, sondern mit einem User Delegation Key, der über Microsoft Entra ID ausgestellt wird. Der Token ist damit an die Identität gebunden, die ihn angefordert hat.

Konkret passiert Folgendes:

  1. Ein Entra ID Security Principal (User, Group, Service Principal oder Managed Identity) authentifiziert sich via OAuth 2.0
  2. Azure Storage stellt einen zeitlich begrenzten User Delegation Key aus
  3. Dieser Key signiert das SAS-Token
  4. Bei jedem Zugriff prüft Azure Storage sowohl die RBAC-Berechtigungen des ursprünglichen Principals als auch die im Token definierten Permissions

Das Ergebnis: Der effektive Zugriff ist immer die Schnittmenge aus RBAC-Rolle und Token-Permissions. Selbst wenn ein Token mit Lese- und Schreibrechten erstellt wurde – verliert der Principal die RBAC-Berechtigung, ist das Token sofort wertlos.

Warum das für Enterprise-Architekten relevant ist

Drei Szenarien, die jeder kennt:

Szenario 1: Offboarding. Ein Mitarbeiter verlässt das Unternehmen. Bisher musste man hoffen, dass keine SAS-Tokens in Skripten, Pipelines oder bei Partnern im Umlauf sind. Mit User Delegation SAS wird die Entra ID-Identität deaktiviert – und alle zugehörigen Tokens sind sofort ungültig. Ohne Key Rotation, ohne Downtime.

Szenario 2: Compliance-Audits. „Wer hat wann auf welche Daten zugegriffen?“ – bei Account-Key-basierten SAS-Tokens ist das faktisch nicht beantwortbar. User Delegation SAS ordnet jeden Zugriff einer konkreten Identität zu. Für ISO 27001, SOC 2 oder BSI-Grundschutz ist das Gold wert.

Szenario 3: Conditional Access. User Delegation SAS lässt sich mit Conditional Access Policies kombinieren. Das heißt: Du kannst erzwingen, dass Storage-Zugriffe nur von compliant Devices, bestimmten Netzwerken oder mit MFA erfolgen – auch über SAS-Tokens.

Hands-on: User Delegation SAS in der Praxis

Voraussetzung: RBAC-Rolle zuweisen

Der Security Principal braucht die Berechtigung Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey. Diese ist in folgenden Built-in Roles enthalten:

  • Storage Blob Data Contributor
  • Storage Blob Data Owner
  • Storage Blob Data Reader
  • Storage Blob Delegator

Für das Least-Privilege-Prinzip empfehle ich die Rolle „Storage Blob Delegator“ in Kombination mit einer Data-Rolle:

bash

# Storage Blob Delegator zuweisen (erlaubt User Delegation Key zu generieren)
az role assignment create \
    --role "Storage Blob Delegator" \
    --assignee "user@contoso.com" \
    --scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>"
# Storage Blob Data Reader für Lesezugriff
az role assignment create \
    --role "Storage Blob Data Reader" \
    --assignee "user@contoso.com" \
    --scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>"

Wichtig: Der User Delegation Key wird auf Storage-Account-Ebene generiert. Die RBAC-Rolle muss daher mindestens auf Account-, Resource-Group- oder Subscription-Level zugewiesen sein – nicht auf Container-Level.

User Delegation SAS per Azure CLI erstellen

bash

# SAS-Token für einen einzelnen Blob generieren
az storage blob generate-sas \
    --account-name <storage-account> \
    --container-name <container> \
    --name <blob> \
    --permissions acdrw \
    --expiry 2026-03-03T18:00:00Z \
    --auth-mode login \
    --as-user \
    --full-uri

Die entscheidenden Flags: --auth-mode login nutzt die Entra ID-Credentials statt des Account Keys, und --as-user erzwingt die User Delegation.

User Delegation SAS per Python SDK

Für Automatisierung in Pipelines ist das Python SDK praxisrelevanter:

python

from datetime import datetime, timedelta, timezone
from azure.identity import DefaultAzureCredential
from azure.storage.blob import (
    BlobServiceClient,
    generate_blob_sas,
    BlobSasPermissions,
)
credential = DefaultAzureCredential()
blob_service = BlobServiceClient(
    account_url="https://<account>.blob.core.windows.net",
    credential=credential
)
# User Delegation Key generieren (max. 7 Tage gültig)
now = datetime.now(timezone.utc)
delegation_key = blob_service.get_user_delegation_key(
    key_start_time=now - timedelta(minutes=5),
    key_expiry_time=now + timedelta(hours=4)
)
# SAS-Token erstellen
sas_token = generate_blob_sas(
    account_name="<account>",
    container_name="<container>",
    blob_name="<blob>",
    user_delegation_key=delegation_key,
    permission=BlobSasPermissions(read=True),
    expiry=now + timedelta(hours=4),
    start=now - timedelta(minutes=5)
)
print(f"https://<account>.blob.core.windows.net/<container>/<blob>?{sas_token}")

Best Practice: Der User Delegation Key ist maximal 7 Tage gültig. Halte die Laufzeiten kurz – 4 bis 24 Stunden sind für die meisten Szenarien ausreichend.

Migrationsstrategie: Von Account-Key-SAS zu User Delegation SAS

Ein Komplettumstieg über Nacht ist unrealistisch. Meine Empfehlung für eine schrittweise Migration:

Phase 1 – Inventur: Identifiziere alle Stellen, an denen Account-Key-basierte SAS-Tokens generiert werden. Typische Fundorte: Azure Functions, Logic Apps, CI/CD-Pipelines, Partner-Integrationen, Backup-Skripte.

Phase 2 – Neue Workloads: Ab sofort für jeden neuen Anwendungsfall User Delegation SAS verwenden. Kein Account Key mehr in neuem Code.

Phase 3 – Bestandsmigration: Die identifizierten Legacy-Stellen schrittweise umstellen. Dabei gleichzeitig von Account Keys auf Managed Identities migrieren – das passt methodisch zusammen.

Phase 4 – Account Keys deaktivieren: Sobald alle SAS-Tokens auf User Delegation umgestellt sind, die Shared Key Authorization auf dem Storage Account deaktivieren:

bash

az storage account update \
    --name <storage-account> \
    --resource-group <rg> \
    --allow-shared-key-access false

Das ist der konsequenteste Schritt – und macht Account-Key-basierte SAS-Tokens für den gesamten Storage Account unmöglich.

Einschränkungen, die du kennen solltest

User Delegation SAS klingt nach der Lösung für alles – aber es gibt ein paar Grenzen:

  • Nur Blob Storage: User Delegation SAS funktioniert ausschließlich für Blob Storage (inkl. Data Lake Storage Gen2). Für Queues, Tables und Files bleibt nur Account-Key-basierte SAS.
  • Max. 7 Tage Gültigkeit: Der User Delegation Key ist auf 7 Tage begrenzt. Für langlebige Tokens musst du die Key-Erstellung automatisieren.
  • Kein Support für Stored Access Policies: Anders als Service SAS unterstützt User Delegation SAS keine Stored Access Policies. Das Token selbst definiert die Permissions.
  • RBAC-Scoping: Der generateUserDelegationKey-Call muss auf Account-Ebene oder höher berechtigt sein. Container-Level-RBAC allein reicht nicht.

Keine dieser Einschränkungen ist ein Showstopper, aber sie beeinflussen das Design. Für Blob-zentrische Workloads – und das sind die meisten – ist User Delegation SAS klar die bessere Wahl.

Was du diese Woche tun kannst

Auch wenn das Feature noch in Preview ist, kannst du heute schon anfangen:

  1. Audit starten: Wo werden in deiner Umgebung Account-Key-basierte SAS-Tokens generiert?
  2. Proof of Concept: Einen nicht-kritischen Workload auf User Delegation SAS umstellen
  3. RBAC prüfen: Sind die richtigen Rollen auf den richtigen Scopes zugewiesen?
  4. Monitoring einrichten: Azure Storage Diagnostic Logs aktivieren, um SAS-Nutzung nachzuvollziehen

Wer heute schon testet, hat einen klaren Vorsprung bei der nächsten Audit-Runde.

Ray Ünal – Azure Cloud Architekt & Teamleiter bei Bechtle.

Dieser Artikel ist Teil von „Last Week in Azure & Tech“. Zur aktuellen Ausgabe

Quellen:

Hinterlasse einen Kommentar