Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Eine Freigegebene Zugriffssignatur (SHARED Access Signature, SAS) bietet eine Möglichkeit, eingeschränkten Zugriff auf Ressourcen in Ihrem Event Hubs-Namespace zu gewähren. SAS schützt den Zugriff auf Event Hubs-Ressourcen mit Autorisierungsregeln. Sie konfigurieren diese Regeln entweder für einen Namespace oder einen Event Hub. Dieser Artikel enthält eine Übersicht über das SAS-Modell und überprüft die bewährten SAS-Methoden.
Hinweis
In diesem Artikel wird die Autorisierung des Zugriffs auf Event Hubs-Ressourcen mit SAS behandelt. Informationen zum Authentifizieren des Zugriffs auf Event Hubs-Ressourcen mit SAS finden Sie unter Authentifizieren mit SAS.
Was sind Shared Access Signatures?
Eine Shared Access Signature (SAS) ermöglicht basierend auf Autorisierungsregeln den delegierten Zugriff auf Event Hubs-Ressourcen. Eine Autorisierungsregel hat einen Namen, ist mit bestimmten Rechten verknüpft und enthält ein Paar kryptografischer Schlüssel. Verwenden Sie den Namen und schlüssel der Regel über die Event Hubs-Clients oder in Ihrem eigenen Code, um SAS-Token zu generieren. Ein Client kann das Token dann an Event Hubs übergeben, um die Autorisierung für den angeforderten Vorgang zu bestätigen.
SAS ist ein anspruchsbasierter Autorisierungsmechanismus, der einfache Token verwendet. Wenn Sie SAS verwenden, übergeben Sie niemals Schlüssel im Netzwerkverkehr. Stattdessen verwenden Sie Schlüssel zum kryptografischen Signieren von Informationen, die der Dienst später überprüfen kann. Sie können SAS ähnlich wie ein Benutzernamen- und Kennwortschema verwenden, bei dem der Client unmittelbar im Besitz eines Autorisierungsregelnamens und eines übereinstimmenden Schlüssels ist. Sie können SAS auch ähnlich wie ein Verbundsicherheitsmodell verwenden, bei dem der Client ein zeitlich begrenztes und signiertes Zugriffstoken von einem Sicherheitstokendienst erhält, ohne jemals in den Besitz des Signaturschlüssels zu gelangen.
Hinweis
Azure Event Hubs unterstützt auch die Autorisierung von Event Hubs-Ressourcen mithilfe von Microsoft Entra ID. Das Autorisieren von Benutzern oder Anwendungen mithilfe von OAuth 2.0-Token, das von Microsoft Entra ID zurückgegeben wird, bietet eine höhere Sicherheit und Benutzerfreundlichkeit gegenüber freigegebenen Zugriffssignaturen (SAS). Wenn Sie Microsoft Entra ID verwenden, müssen Sie die Token nicht in Ihrem Code speichern und potenzielle Sicherheitsrisiken riskieren.
Microsoft empfiehlt die Verwendung von Microsoft Entra ID für Ihre Azure Event Hubs-Anwendungen, wenn dies möglich ist. Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf Event Hubs-Ressourcen mit Microsoft Entra ID.
Wichtig
SAS-Token sind für den Schutz Ihrer Ressourcen von entscheidender Bedeutung. SAS sorgt für Granularität und gewährt Clients Zugriff auf Ihre Event Hubs-Ressourcen. Teilen Sie sie nicht öffentlich. Wenn die Freigabe aus Problembehandlungsgründen erforderlich ist, sollten Sie eine reduzierte Version der Protokolldateien verwenden oder die SAS-Token (sofern vorhanden) aus den Protokolldateien löschen. Stellen Sie sicher, dass die Screenshots auch keine SAS-Informationen enthalten.
Autorisierungsrichtlinien für freigegebenen Zugriff
Jeder Event Hubs-Namespace und jede Event Hubs-Entität (ein Event Hub oder ein Kafka-Thema) verfügt über eine gemeinsame Zugriffsrichtlinie, die aus Regeln besteht. Die Richtlinie auf Namespaceebene gilt für alle Entitäten innerhalb des Namespace, unabhängig von ihrer jeweiligen Richtlinienkonfiguration.
Für jede Regel einer Autorisierungsrichtlinie entscheiden Sie sich für drei Angaben: Name, Bereich und Rechte. Der Name ist im angegebenen Bereich eindeutig. Der Bereich ist der URI der fraglichen Ressource. Für einen Event Hubs-Namespace wird als Bereich der vollqualifizierte Domänenname (Fully Qualified Domain Name, FQDN) angegeben, z. B. https://<yournamespace>.servicebus.windows.net/.
Die durch die Richtlinienregel gewährten Rechte können eine Kombination aus Folgendem sein:
- Senden: Gewährt das Recht zum Senden von Nachrichten an die Entität.
- Lauschen – Gewährt das Recht, für die Entität Nachrichten zu lauschen oder zu empfangen.
- Verwalten: Gewährt das Recht zum Verwalten der Topologie des Namespace, einschließlich Erstellung und Löschung von Entitäten. Das Recht Verwalten umfasst auch die Rechte Senden und Lauschen.
Eine Namespace- oder Entitätenrichtlinie kann bis zu 12 gemeinsame Zugriffsautorisierungsregeln enthalten, was Platz für die drei Regelsätze bietet, die jeweils die grundlegenden Rechte sowie die Kombination aus Senden und Lauschen abdecken. Mit dieser Einschränkung wird verdeutlicht, dass der SAS-Richtlinienspeicher nicht als Benutzer- oder Dienstkontospeicher vorgesehen ist. Wenn Ihre Anwendung Zugriff auf Event Hubs-Ressourcen basierend auf Benutzer- oder Dienstidentitäten gewähren muss, sollte ein Sicherheitstokendienst implementiert werden, der nach einer Authentifizierungs- und Zugriffsprüfung SAS-Token ausstellt.
Einer Autorisierungsregel wird ein Primärschlüssel und ein Sekundärschlüssel zugewiesen. Hierbei handelt es sich um sichere Kryptografieschlüssel. Verlieren Sie sie nicht und geben Sie sie nicht preis. Sie sind immer im Azure Portal verfügbar. Sie können einen beliebigen der generierten Schlüssel verwenden und die Schlüssel jederzeit erneut generieren. Wenn Sie einen Schlüssel in der Richtlinie neu erstellen oder ändern, sind alle zuvor basierend auf diesem Schlüssel ausgestellten Token sofort ungültig. Ausgehende Verbindungen, die basierend auf solchen Token erstellt wurden, funktionieren allerdings weiterhin, bis das Token abgelaufen ist.
Wenn Sie einen Event Hubs-Namespace erstellen, wird für den Namespace automatisch eine Richtlinie mit dem Namen RootManageSharedAccessKey erstellt. Diese Richtlinie verfügt über die Berechtigung Verwalten für den gesamten Namespace. Behandeln Sie diese Regel wie ein Administratorstammkonto, und verwenden Sie sie nicht in Ihrer Anwendung. Sie können weitere Richtlinienregeln auf der Registerkarte Configure für den Namespace im Portal, über PowerShell oder Azure CLI erstellen.
Bewährte Methoden bei Verwendung von SAS
Wenn Sie freigegebene Zugriffssignaturen in Ihren Anwendungen verwenden, beachten Sie zwei potenzielle Risiken:
- Wenn ein SAS-Speicherleck abläuft, kann jeder, der es erhält, es verwenden, wodurch ihre Event Hubs-Ressourcen potenziell kompromittiert werden können.
- Wenn eine SAS, die einer Clientanwendung bereitgestellt wird, abläuft und die Anwendung keine neue SAS von Ihrem Dienst abrufen kann, kann die Funktionalität der Anwendung beeinträchtigt werden.
Mit den folgenden Empfehlungen für die Verwendung von Shared Access Signatures können Sie diese Risiken verringern:
- Lassen Sie Clients die SAS bei Bedarf automatisch verlängern: Clients sollten die SAS rechtzeitig vor Ablauf verlängern, um Zeit für erneute Versuche zu haben, falls der Dienst, der die SAS bereitstellt, nicht verfügbar ist. Wenn Ihre SAS für eine kleine Anzahl von unmittelbaren, kurzlebigen Vorgängen vorgesehen ist, die innerhalb des Ablaufzeitraums abgeschlossen werden sollen, kann die Verlängerung unnötig sein. Wenn Sie jedoch einen Client haben, der routinemäßig Anforderungen über SAS sendet, tritt die Möglichkeit einer Ablaufwarnung auf. Die Hauptüberlegung besteht darin, das Erfordernis abzuwägen, dass SAS kurzlebig sein soll (wie bereits erwähnt), mit der Notwendigkeit sicherzustellen, dass der Client die Erneuerung früh genug anfordert, um Unterbrechungen zu vermeiden, die aufgrund des Ablaufs der SAS vor einer erfolgreichen Erneuerung entstehen könnten.
- Achten Sie bei der SAS-Startzeit darauf: Wenn Sie die Startzeit für SAS auf "jetzt" festlegen, kann es aufgrund von Uhrverschiebungen (Unterschiede in der aktuellen Zeit nach verschiedenen Computern) zu unterbrechungsbedingten Fehlern in den ersten Minuten kommen. Üblicherweise sollten Sie als Startzeit eine Uhrzeit angeben, die mindestens 15 Minuten in der Vergangenheit liegt. Oder legen Sie sie überhaupt nicht fest, wodurch sie sofort in allen Fällen gültig ist. Dasselbe gilt auch für die Ablaufzeit. Beachten Sie, dass es bei jeder Anfrage in beide Richtungen zu einer Zeitabweichung von bis zu 15 Minuten kommen kann.
- Seien Sie spezifisch für die Ressource, auf die zugegriffen werden soll: Eine bewährte Methode für die Sicherheit besteht darin, Benutzern die erforderlichen Mindestberechtigungen bereitzustellen. Wenn ein Benutzer nur Lesezugriff auf eine einzelne Entität benötigt, gewähren Sie ihm Lesezugriff auf diese einzelne Entität, und keinen Lese-, Schreib- oder Löschzugriff auf alle Entitäten. Dieser Ansatz trägt auch dazu bei, den Schaden zu reduzieren, wenn eine SAS kompromittiert wird, da die SAS weniger Leistung in den Händen eines Angreifers hat.
- Verwenden Sie nicht immer SAS: Manchmal überwiegen die Risiken, die mit einem bestimmten Vorgang in Bezug auf Ihre Event Hubs verbunden sind, die Vorteile von SAS. Erstellen Sie für Vorgänge dieser Art einen Dienst auf der mittleren Ebene, der in Ihre Event Hubs schreibt, nachdem die Überprüfung der Geschäftsregeln sowie die Authentifizierung und die Überwachung durchgeführt wurden.
- Verwenden Sie immer HTTPS: Verwenden Sie immer HTTPS, um eine SAS zu erstellen oder zu verteilen. Wenn ein SAS über HTTP übergeben und abgefangen wird, kann ein Angreifer, der einen Man-in-the-Middle-Angriff durchführt, das SAS lesen und dann genauso wie der beabsichtigte Benutzer verwenden, potenziell vertrauliche Daten kompromittieren oder datenbeschädigung durch den böswilligen Benutzer zulassen.
Zusammenfassung
Freigegebene Zugriffssignaturen sind nützlich für die Bereitstellung eingeschränkter Berechtigungen für Event Hubs-Ressourcen für Ihre Clients. Sie sind ein wichtiger Bestandteil des Sicherheitsmodells für jede Anwendung, die Azure Event Hubs verwendet. Wenn Sie sich an die in diesem Artikel beschriebenen bewährten Methoden halten, können Sie mit SAS eine größere Flexibilität für den Zugriff auf Ihre Ressourcen erzielen, ohne die Sicherheit Ihrer Anwendung zu gefährden.
Zugehöriger Inhalt
Weitere Informationen finden Sie in den folgenden verwandten Artikeln:
- Authentifizieren von Anforderungen an Azure Event Hubs mithilfe von Shared Access Signature
- Authentifizieren von Anforderungen an Azure Event Hubs über eine Anwendung mithilfe von Microsoft Entra ID
- Authentifizieren einer verwalteten Identität mit Microsoft Entra ID für den Zugriff auf Event Hubs-Ressourcen