Erstellen von Shared Access Signatures

  • 5 Minuten

Eine Shared Access Signature (SAS) ist ein Uniform Resource Identifier (URI), der eingeschränkte Zugriffsrechte für Azure-Storage-Ressourcen gewährt. SAS stellt eine sichere Methode zur Freigabe Ihrer Speicherressourcen dar, ohne dass Sie Kompromisse bei der Sicherheit der Kontoschlüssel eingehen müssen.

Sie können Clients, die keinen Zugriff auf Ihren Speicherkontoschlüssel haben sollen, eine SAS bereitstellen. Durch Bereitstellen eines SAS-URI für diese Clients wird ihnen für einen bestimmten Zeitraum Zugriff auf eine Ressource gewährt. SAS sind für einen Dienst ideal, bei dem Benutzer ihre Daten in Ihr Speicherkonto schreiben und dort lesen.

  • Eine SAS für die Benutzerdelegierung wird mit Microsoft Entra-Anmeldeinformationen und auch durch die Berechtigungen geschützt, die für sie angegeben wurden. Eine Benutzerdelegierungs-SAS wird für Blob Storage und Data Lake Storage unterstützt,

  • Eine Kontoebene SAS, die den Zugriff auf alles ermöglicht, was eine Serviceebene SAS erlaubt, sowie auf zusätzliche Ressourcen und Fähigkeiten. Sie können eine SAS auf Kontoebene z. B. verwenden, um zuzulassen, dass Dateisysteme erstellt werden können.

  • Eine SAS auf Dienstebene , um den Zugriff auf bestimmte Ressourcen in einem Speicherkonto zu ermöglichen. Diese Art SAS können Sie z. B. verwenden, um zuzulassen, dass eine App eine Liste von Dateien in einem Dateisystem abrufen oder eine Datei herunterladen kann.

  • Eine gespeicherte Zugriffsrichtlinie kann eine weitere Steuerungsebene bereitstellen, wenn Sie eine SAS auf Dienstebene auf der Serverseite verwenden. Sie können Shared Access Signatures gruppieren und andere Einschränkungen mithilfe einer gespeicherten Zugriffsrichtlinie einrichten.

Empfehlungen für den Umgang mit Risiken

Sehen wir uns einige Empfehlungen an, die dazu beitragen können, die Risiken bei der Arbeit mit einer SAS zu minimieren.

Empfehlung BESCHREIBUNG
Verwenden Sie für Erstellungs- und Verteilungsaufgaben stets HTTPS Wenn eine SAS über HTTP übergeben und abgefangen wird, kann ein Angreifer die SAS abfangen und verwenden. Solche Man-in-the-Middle-Angriffe können sensible Daten möglicherweise gefährden oder eine Datenbeschädigung durch den böswilligen Akteur ermöglichen.
Verweisen Sie nach Möglichkeit auf gespeicherte Zugriffsrichtlinien Gespeicherte Zugriffsrichtlinien bieten Ihnen die Möglichkeit, Berechtigungen zu widerrufen, ohne dafür die Azure Storage-Kontoschlüssel erneut generieren zu müssen. Legen Sie das Ablaufdatum des Speicherkontoschlüssels auf einen Zeitpunkt in ferner Zukunft fest.
Festlegen kurzfristiger Ablaufzeiten für eine ungeplante SAS Wenn eine SAS kompromittiert wurde, können Sie Angriffe dadurch entschärfen, dass Sie die Gültigkeit der SAS auf einen kurzen Zeitraum beschränken. Dies ist dann wichtig, wenn Sie nicht auf eine gespeicherte Zugriffsrichtlinie verweisen können. Kurzfristige Ablaufzeiten beschränken auch die Datenmenge, die in einen Blob geschrieben werden kann, indem sie die Zeit verkürzen, die ein Blob für Uploads verfügbar ist.
Anfordern, dass Clients die SAS automatisch verlängern Fordern Sie Ihre Clients auf, die SAS weit vor dem Ablaufdatum zu verlängern. Durch eine frühzeitige Verlängerung erhalten Sie Zeit für Wiederholungsversuche, falls der Dienst, der die SAS bereitstellt, nicht verfügbar ist.
Sorgfältiges Planen der SAS-Startzeit Wenn Sie die Startzeit für eine SAS auf „Jetzt“ festlegen, können aufgrund von Uhrabweichungen (Unterschieden bei der aktuellen Zeit auf verschiedenen Computern) in den ersten Minuten gelegentlich Ausfälle beobachtet werden. Generell sollten Sie als Startzeit eine Uhrzeit angeben, die mindestens 15 Minuten in der Vergangenheit liegt. Oder legen Sie keine bestimmte Startzeit fest, sodass die SAS in jedem Fall sofort gültig ist. Die gleichen Bedingungen gelten im Allgemeinen für die Ablaufzeit. Es kann bei allen Anforderungen in beiden Richtungen zu Uhrabweichungen von bis zu 15 Minuten kommen. Für Clients, die eine REST-API-Version vor 2012-02-12 verwenden, beträgt die maximale Dauer einer SAS, die nicht auf eine gespeicherte Zugriffsrichtlinie verweist, 1 Stunde. Bei allen Richtlinien, in denen eine längere Dauer angegeben ist, treten Fehler auf.
Definieren von Mindestzugriffsberechtigungen für Ressourcen Aus Sicherheitsgründen sollten Benutzer nur die minimal erforderlichen Berechtigungen erhalten. Wenn ein Benutzer nur Lesezugriff auf eine einzige Entität benötigt, dann geben Sie auch nur Lesezugriff auf diese Entität, und nicht Lese-/Schreib-/Löschzugriff auf alle Entitäten. Dadurch lässt sich auch der Schaden verringern, wenn eine SAS kompromittiert wurde, da die SAS in den Händen des Angreifers weniger Wirkungspotenzial hat.
Überprüfen von mithilfe einer SAS geschriebenen Daten Wenn Clientanwendungen Daten in Ihr Azure Storage-Konto schreiben, beachten Sie, dass diese Daten problembehaftet sein können. Wenn Ihre Anwendung überprüfte oder autorisierte Daten benötigt, überprüfen Sie die Daten nach dem Schreibvorgang, aber vor der Nutzung. Auf diese Weise schützen Sie Ihr Konto auch vor beschädigten oder bösartigen Daten, sowohl von tatsächlich berechtigten SAS-Benutzern als auch von Angreifern, die eine abgefangene SAS verwenden.
Gehen Sie nicht davon aus, dass eine SAS immer die richtige Wahl ist In einigen Szenarien überwiegen die Risiken eines bestimmten Vorgangs für Ihr Azure Storage-Konto gegenüber den Vorzügen der Nutzung einer SAS. Für solche Operation sollten Sie einen Dienst auf der mittleren Ebene erstellen, der zunächst Geschäftsregeln validiert sowie Authentifizierung und Überwachung durchführt und die Daten anschließend in Ihr Speicherkonto schreibt. Mitunter gibt es auch einfachere Möglichkeiten der Zugriffsverwaltung. Wenn Sie alle Blobs in einem Container öffentlich lesbar machen möchten, können Sie auch den Container öffentlich machen, anstatt jedem Client für den Zugriff eine SAS bereitzustellen.