App benötigt sicheren Cloud-Dateispeicher? Blob Storage und widerrufbaren SAS-Zugriff erstellen

Veröffentlicht am:
#azure-storage#blob-storage#sas#stored-access-policy

CloudTrips benötigt Objektspeicher für eine Anwendungsdatei. Die Datei soll privat bleiben, aber ein externer Client benötigt vorübergehenden Lesezugriff, den CloudTrips vor dem geplanten Ablauf widerrufen kann.

Storage Account → Azure-Speichernamespace und Sicherheitsgrenze
Blob-Container  → gruppiert zusammengehörige Objekte im Account
Blob            → hochgeladenes Objekt wie Dokument, Bild oder Backup
SAS             → signierte URL mit begrenztem Zugriff ohne Freigabe eines Account Keys

Storage Account erstellen

Suche nach Storage accounts, wähle Create und trage ein:

Subscription: CloudTrips TEST
Resource group: Create new → rg-cloudtrips-storage-test-weu
Storage account name: stctblobdmytrotestweu
Region: West Europe
Performance: Standard
Redundancy: Locally-redundant storage (LRS)

Der Storage-Account-Name muss global eindeutig, 3–24 Zeichen lang sein und darf nur Kleinbuchstaben und Zahlen verwenden. Ist dieser Name vergeben, ändere nur den eindeutigen Teil dmytro und verwende den neuen Namen im gesamten Trip.

Lasse Secure Transfer erforderlich und öffentlichen Blobzugriff deaktiviert. Lasse Allow storage account key access aktiviert, weil eine Stored Access Policy nur einen Service SAS steuern kann und dieser mit einem Account Key signiert wird. Wähle Review + create > Create.

Storage-Account-Übersicht mit Accountname, Region West Europe, Standard-Performance und LRS-Redundanz

Privaten Blob-Container erstellen

Öffne den Storage Account und wähle Data storage > Containers > + Container:

Name: app-files
Anonymous access level: Private (no anonymous access)

Ein Container ist kein klassischer Dateisystemordner. Er ist der oberste Bereich, der Blobs enthält und Zugriffsrichtlinien tragen kann. Erstelle den Container.

Blob hochladen

Erstelle eine kleine lokale Testdatei:

printf 'CloudTrips private blob\n' > cloudtrips-storage-test.txt

Öffne app-files, wähle Upload, dann cloudtrips-storage-test.txt und Upload. Behalte den Standardtyp Block Blob; Block Blobs eignen sich für gewöhnliche Dateien, die als Objekte hoch- und heruntergeladen werden.

Privater app-files-Container mit hochgeladenem Blob cloudtrips-storage-test.txt

Kopiere die URL des Blobs und teste sie ohne Anmeldedaten:

curl --include '<BLOB_URL>'

Die Anfrage darf den Dateiinhalt nicht liefern. Eine Antwort 401, 403 oder bewusst undurchsichtige 404 bestätigt, dass die normale URL allein keinen Zugriff gewährt.

Temporären Ad-hoc-SAS-Zugriff erzeugen

Aktiviere in der Containerliste das Kontrollkästchen neben app-files, öffne … > Generate SAS und konfiguriere:

Signing method: Account key
Stored access policy: None
Permissions: Read
Start: fünf Minuten vor der aktuellen Zeit
Expiry: eine Stunde ab jetzt
Allowed protocols: HTTPS only

Ein leicht zurückgesetzter Start verhindert vorübergehende Fehler bei abweichenden Uhren von Client und Azure. Wähle Generate SAS token and URL und kopiere die erzeugte SAS-URL oder hänge den angezeigten Token an die Blob-URL. Der Token wird nur einmal angezeigt und muss wie ein Kennwort geschützt werden.

curl --include '<BLOB_SAS_URL>'

Erwarteter Inhalt:

CloudTrips private blob

Terminal mit verweigertem anonymem Zugriff auf den privaten Blob

Terminal mit erfolgreichem Abruf der privaten Datei über die temporäre SAS-URL

Dies ist ein Ad-hoc Service SAS: Berechtigungen und Gültigkeitszeitraum sind im Token eingebettet. Azure Storage führt keine Liste ausgegebener SAS-Token, daher kann dieser einzelne Token nicht direkt widerrufen werden. Ablauf oder Rotation des signierenden Account Keys machen ihn ungültig, doch die Schlüsselrotation betrifft auch andere damit signierte SAS-Token.

Stored Access Policy erstellen

Kehre zu Data storage > Containers zurück. Markiere app-files, öffne … > Access policy und wähle unter Stored access policies + Add policy:

Identifier: read-files
Permissions: Read
Start time: fünf Minuten vor der aktuellen Zeit
Expiry time: eine Stunde ab jetzt

Wähle OK und danach im Access-policy-Bereich Save. Das zweite Speichern ist wesentlich: Wird der Bereich nach OK geschlossen, geht die noch nicht angewendete Policy verloren.

Access-policy-Bereich von app-files mit gespeicherter Stored Access Policy read-files

Eine Stored Access Policy ist serverseitiger Zustand am Container. Mehrere Service-SAS-Token können ihren Identifier referenzieren und Berechtigungen sowie Zeitfenster erben. Änderung oder Löschen der Policy wirkt deshalb auf alle verknüpften Token.

Policygebundenen SAS erzeugen

Markiere app-files, öffne … > Generate SAS und konfiguriere:

Signing method: Account key
Stored access policy: read-files
Allowed protocols: HTTPS only

Die Policy liefert Leseberechtigung und Gültigkeitszeitraum. Erzeuge den SAS und kopiere den Token sicher. Liefert das Portal eine URL auf Containerebene, baue die Blob-URL so zusammen:

https://stctblobdmytrotestweu.blob.core.windows.net/app-files/cloudtrips-storage-test.txt?<POLICY_SAS_TOKEN>

Füge kein zweites ? ein, wenn der kopierte Token oder die URL bereits eines enthält. Teste:

curl --include '<POLICY_LINKED_BLOB_SAS_URL>'

Erwarteter Inhalt: CloudTrips private blob.

Generate-SAS-Bereich mit Account-key-Signierung und ausgewählter Stored Access Policy read-files

Stored Access Policies funktionieren nur mit einem Service SAS. Sie können nicht mit User Delegation SAS oder Account SAS verbunden werden. Microsoft empfiehlt grundsätzlich User Delegation SAS, da er mit Microsoft-Entra- Anmeldedaten geschützt ist; hier wird Service SAS gezielt für den policybasierten Widerruf verwendet.

Die drei SAS-Typen unterscheiden sich durch Signatur und möglichen Umfang:

Service SAS
Signiert durch: Storage Account Key
Umfang: ein Azure-Storage-Dienst, zum Beispiel Blob Storage
Stored Access Policy: unterstützt

Account SAS
Signiert durch: Storage Account Key
Umfang: mehrere Storage-Dienste und Vorgänge auf Dienstebene
Stored Access Policy: nicht unterstützt

User Delegation SAS
Signiert durch: temporärer User-Delegation-Key aus Microsoft-Entra-Anmeldedaten
Umfang: Blob Storage und Data Lake Storage
Stored Access Policy: nicht unterstützt

Ein User Delegation SAS vermeidet den langlebigen Storage Account Key und ist für Blobzugriff normalerweise die bevorzugte Wahl. Ein Account SAS besitzt den größten möglichen Umfang. Ein Service SAS ist enger begrenzt und erhält durch die Verknüpfung mit einer Stored Access Policy den hier demonstrierten serverseitigen Widerrufsmechanismus.

Policygebundenen SAS widerrufen

Kehre zum Access policy-Bereich des Containers zurück, lösche read-files und wähle Save. Warte kurz auf die Verteilung der Berechtigungsänderung und rufe danach exakt dieselbe policygebundene URL erneut auf:

curl --include '<POLICY_LINKED_BLOB_SAS_URL>'

Erwartetes Ergebnis: 403 mit Authentifizierungs- oder Autorisierungsfehler. URL, Token, Account Key und Blob blieben unverändert; der Zugriff endet, weil Azure den Stored-Policy-Identifier des Tokens nicht mehr auflösen kann.

Der frühere Ad-hoc-SAS bleibt bis zu seinem eigenen Ablauf gültig, weil er read-files nie referenziert hat.

Terminal mit erfolgreichem Abruf der privaten Datei über den policygebundenen SAS vor dem Widerruf

Terminal mit Antwort 403 für dieselbe policygebundene SAS-URL nach dem Löschen der Stored Access Policy

Bereinigen

Lösche die eigenständige Ressourcengruppe:

az group delete \
  --name rg-cloudtrips-storage-test-weu \
  --yes

Prüfe, ob sie entfernt wurde:

az group exists --name rg-cloudtrips-storage-test-weu

Erwartetes Ergebnis: false.