Entdecken von Shared Access Signatures
Eine Shared Access Signature (SAS) ist ein signierter URI, der auf mindestens eine Speicherressource verweist und ein Token mit einem speziellen Satz von Abfrageparametern enthält. Das Token gibt an, wie der Client auf die Ressourcen zugreifen kann. Einer der Abfrageparameter ist die Signatur. Sie besteht aus den SAS-Parametern und wird mit dem Schlüssel signiert, der zum Erstellen der SAS verwendet wurde. Diese Signatur wird von Azure Storage verwendet, um den Zugriff auf die Speicherressource zu autorisieren.
Arten von Shared Access Signatures
Azure Storage unterstützt drei Arten von Shared Access Signatures:
Benutzerdelegierungs-SAS: Eine Benutzerdelegierungs-SAS wird durch Microsoft Entra-Anmeldeinformationen sowie die für die SAS angegebenen Berechtigungen gesichert. Eine Benutzerdelegierungs-SAS gilt nur für Blob Storage und Data Lake Storage.
Service SAS: Ein Dienst-SAS wird mit dem Speicherkontoschlüssel gesichert. Eine Dienst-SAS delegiert den Zugriff auf eine Ressource in nur einem der Azure Storage-Dienste: Blob Storage, Queue Storage, Table Storage oder Azure Files.
Konto-SAS: Ein Konto-SAS ist mit dem Speicherkontoschlüssel gesichert. Eine Konto-SAS delegiert den Zugriff auf Ressourcen in einem oder mehreren der Speicherdienste. Alle Vorgänge, die über eine Dienst-SAS oder eine SAS für die Benutzerdelegierung verfügbar sind, sind auch über eine Konto-SAS verfügbar.
Hinweis
Microsoft empfiehlt als bewährte Methode, nach Möglichkeit Microsoft Entra-Anmeldeinformationen anstelle des Kontoschlüssels zu verwenden, der leichter kompromittiert werden kann. Wenn ihr Anwendungsentwurf Shared Access Signatures für den Zugriff auf Blobspeicher erfordert, verwenden Sie Microsoft Entra-Anmeldeinformationen, um nach Möglichkeit eine SAS für die Benutzerdelegierung zu erstellen und damit die Sicherheit zu erhöhen.
Funktionsweise von Shared Access Signatures
Wenn Sie eine SAS für den Zugriff auf Daten verwenden, die in Azure Storage gespeichert sind, benötigen Sie zwei Komponenten. Die erste ist ein URI der Ressource, auf die Sie zugreifen möchten. Die zweite ist ein SAS-Token, das Sie erstellt haben, um den Zugriff auf diese Ressource zu autorisieren.
In einem einzelnen URI (z. B. https://medicalrecords.blob.core.windows.net/patient-images/patient-116139-nq8z7f.jpg?sp=r&st=2020-01-20T11:42:32Z&se=2020-01-20T19:42:32Z&spr=https&sv=2019-02-02&sr=b&sig=SrW1HZ5Nb6MbRzTbXCaPm%2BJiSEn15tC91Y4umMPwVZs%3D) können Sie den URI wie folgt vom SAS-Token trennen:
-
URI:
https://medicalrecords.blob.core.windows.net/patient-images/patient-116139-nq8z7f.jpg? -
SAS-Token:
sp=r&st=2020-01-20T11:42:32Z&se=2020-01-20T19:42:32Z&spr=https&sv=2019-02-02&sr=b&sig=SrW1HZ5Nb6MbRzTbXCaPm%2BJiSEn15tC91Y4umMPwVZs%3D
Das SAS-Token selbst besteht aus mehreren Komponenten.
| Komponente | Beschreibung |
|---|---|
sp=r |
Steuert die Zugriffsrechte. Die Werte können a für „add“ (hinzufügen), c für „create“ (erstellen), d für „delete“ (löschen), l für „list“ (auflisten), r für „read“ (lesen) oder w für „write“ (schreiben) sein. In diesem Beispiel besteht schreibgeschützter Zugriff. Das Beispiel sp=acdlrw gewährt alle verfügbaren Rechte. |
st=2020-01-20T11:42:32Z |
Das Datum und die Uhrzeit, wann der Zugriff beginnt. |
se=2020-01-20T19:42:32Z |
Das Datum und die Uhrzeit, wann der Zugriff endet. Bei diesem Beispiel werden acht Stunden Zugriff gewährt. |
sv=2019-02-02 |
Dies ist die Version der zu verwendenden Speicher-API. |
sr=b |
Dies ist die Art des Speichers, auf den zugegriffen wird. In diesem Beispiel steht „b“ für Blob. |
sig=SrW1HZ5Nb6MbRzTbXCaPm%2BJiSEn15tC91Y4umMPwVZs%3D |
Dies ist die kryptografische Signatur. |
Best Practices
Microsoft bietet einige Best Practices, um die potenziellen Risiken bei der Verwendung einer SAS zu verringern:
- Verwenden Sie immer HTTPS, um eine SAS sicher zu verteilen und Man-in-the-Middle-Angriffe zu verhindern.
- Die sicherste SAS ist eine Benutzerdelegierungs-SAS. Verwenden Sie diese nach Möglichkeit, um den Speicherkontoschlüssel nicht mehr im Code speichern zu müssen. Zum Verwalten von Anmeldeinformationen müssen Sie Microsoft Entra ID verwenden. Diese Option ist möglicherweise für Ihre Lösung nicht verfügbar.
- Versuchen Sie, die Ablaufzeit auf den kleinsten realistischen Wert festzulegen. Wenn ein SAS-Schlüssel dann kompromittiert wird, kann er nur für kurze Zeit ausgenutzt werden.
- Wenden Sie die Regel der minimal erforderlichen Berechtigungen an. Gewähren Sie nur den erforderlichen Zugriff. Beispielsweise ist in Ihrer App der schreibgeschützte Zugriff ausreichend.
- Es gibt einige Situationen, in denen eine SAS nicht die richtige Lösung ist. Wenn ein unzulässiges Risiko für die Verwendung einer SAS vorliegt, müssen Sie einen Dienst der mittleren Ebene erstellen, um Benutzer und deren Zugriff auf den Speicher zu verwalten.