Verstehen der Risiken von Azure SAS-Tokens

Die Verantwortung für Datenbesitz und -verwaltung ist nicht mehr zentralisiert. Verschiedene Abteilungen, Geschäftsbereiche und Teams arbeiten fortlaufend mit Daten und nutzen sie, um ihre spezifischen Ziele zu erreichen. Ein derart verteilter Ansatz für Datenverantwortung kann Unternehmen jedoch anfällig machen.

Eine sehr wahrscheinliche Ursache für potenzielle Cybersicherheitsprobleme ist, wenn Azure Shared Access Signature (SAS)-Tokens in Code-Repositories und anderen Datenquellen offengelegt oder mit Dritten geteilt werden. Diese können dann von der Öffentlichkeit eingesehen und für böswillige Zwecke missbraucht werden. Dies kann beispielsweise das Leaken vertraulicher Informationen oder den Zugriff auf privilegierte Dateien umfassen. In diesem Blog konzentrieren wir uns auf den beliebtesten Typ – Account SAS-Tokens (Azure).

Was ist ein Azure SAS-Token?

Ein Shared Access Signature (SAS)-Token ist eine eindeutige Zeichenkette aus verschlüsseltem Text, die alle notwendigen Details enthält, um eine geteilte Signatur zur Authentifizierung für den Zugriff auf Azure Storage-Dienste zu ermöglichen. Sie legt außerdem fest, auf welchen Dienst und welche Ressource zugegriffen werden kann, welche Berechtigungen gewährt werden und für welchen Zeitraum die Signatur gültig ist.

Wenn wir uns die Einzelheiten dieser Tokens ansehen, gibt es drei Arten von SAS-Tokens: Account SAS, Service SAS und User Delegation SAS. In diesem Blogbeitrag geht es speziell um Account SAS-Tokens, da dies die Art von Token ist, die für den Zugriff auf Speicher verwendet wird – ein kritischer (wenn nicht sogar der kritischste) Schwachpunkt in der Datensicherheit.

Konto-SAS-Token

SAS-Tokens sind verschlüsselte Codes in Form von URIs (Uniform Resource Identifier), die bestimmte Zugriffsrechte auf eine oder mehrere Azure Storage-Ressourcen gewähren, wie zum Beispiel Azure Blob Storage, Azure File Storage und Azure Queue Storage. Im Vergleich zu anderen Tokens bedeutet dieser umfangreiche Zugriff, dass Account SAS besonders sorgfältig behandelt werden muss, um unbefugten Datenzugriff zu verhindern.

Darüber hinaus liegt die Wirksamkeit eines SAS-Tokens in seiner Signatur, einem speziellen Parameter, der zur URI der Speicherressource hinzugefügt wird. Dieses System gewährleistet einen kontrollierten Zugriff, ohne sensible Zugangsdaten preiszugeben, was besonders wichtig ist, wenn Nutzer Zugriff benötigen, aber keine umfassenden Berechtigungen erhalten sollen. Azure Storage überprüft anschließend diese Signatur, um den Zugriff zu autorisieren, und ermöglicht den Clients den direkten Zugriff auf die angegebenen Ressourcen für einen festgelegten Zeitraum. Nach Ablauf ist ein neues Token erforderlich.

Wie in der Dokumentation von Microsoft zu sehen ist, hier ein Beispiel für ein SAS-Token in einer URI:

Sobald das Token generiert wurde, können den Nutzern Berechtigungen wie Lesen und/oder Schreiben gewährt werden. Es gibt zwei bemerkenswerte Anwendungsfälle:

• Kunden können Daten über einen Frontend-Proxy-Dienst hoch- und herunterladen, der die Signatur authentifiziert.
• Ein bestimmter Dienst authentifiziert den Benutzer und generiert anschließend einen Account SAS-Code, um direkt auf die Ressourcen des Speicherkontos zuzugreifen. 

Was sind die Risiken bei der Verwendung von SAS-Tokens?

Obwohl Account SAS-Tokens äußerst nützlich für den Zugriff auf Speicherressourcen sind, gibt es eine Reihe von Risiken, die Unternehmen berücksichtigen müssen.‍

Verfolgung generierter Tokens. Eine der größten Herausforderungen ist die fehlende Transparenz darüber, wie viele Tokens sich aktuell im Umlauf befinden. Sobald Tokens generiert wurden, können sie von jeder unbefugten Instanz abgerufen und genutzt werden.‍

Länger als beabsichtigte Zeitstempel. Zweitens besteht die Möglichkeit, dass Nutzer beim Erstellen von Tokens extrem lange Ablaufdaten festlegen, wodurch Daten länger als ursprünglich vorgesehen angreifbar bleiben. Es kann auch zu Dienstunterbrechungen kommen, wenn Tokens ablaufen, was sich auf alle davon abhängigen Dienste auswirkt. ‍

Sobald ein SAS-Token generiert wurde, kann es nicht mehr widerrufen werden. Um solche menschlichen Fehler zu vermeiden, ist es eine bewährte Praxis, eine kurze Lebensdauer für das Start- und Ablaufdatum sowie die -uhrzeit des signierten Schlüssels festzulegen. ‍

Falsche Berechtigungen. Um diese Probleme noch zu verschärfen, können SAS-Tokens mehr Zugriff gewähren als ursprünglich beabsichtigt. Beispielsweise könnte ein Benutzer, der Zugriff auf eine bestimmte Datei gewähren möchte, versehentlich ein SAS-Token erstellen, das den Zugriff auf den gesamten zugehörigen Speichercontainer einschließlich aller darin enthaltenen Dateien ermöglicht. Ebenso könnte ein Benutzer, der "Lese"-Zugriff auf Dateien gewähren möchte, versehentlich ein SAS-Token erstellen, das stattdessen "Schreib"- oder "Verwaltungs"-Berechtigungen anstelle von nur "Lesen" erlaubt, sodass jeder, der das Token besitzt, das Speicherkonto schreiben und verwalten kann.

Schauen wir uns einige bewährte Methoden an, um falsche Berechtigungen und die Offenlegung unbefugter Zugriffe zu vermeiden.

Best Practices für die Arbeit mit Azure SAS-Tokens

Wir empfehlen eine Reihe von Best Practices beim Arbeiten mit Azure SAS-Tokens:‍

Prinzip der minimalen Rechtevergabe anwenden:

• Beschränken Sie SAS-Tokens auf die notwendigen Ressourcen (z. B. ein Blob).
• Gewähren Sie nur die notwendigen Berechtigungen (z. B. nur Lesezugriff).
  

Verwenden Sie kurzlebige SAS:

• Verwenden Sie eine kürzere Ablaufzeit für SAS-Tokens und lassen Sie die Clients bei Bedarf neue SAS-Tokens anfordern.
• Aktualisieren Sie die SAS-Tokens gemäß der von Microsoft empfohlenen Zeit: 1 Stunde oder weniger.
  

Gehen Sie mit SAS vorsichtig um:

• Behandle SAS-Tokens als vertraulich.
• Nur mit Kunden teilen, die Zugriff auf ein Speicherkonto benötigen.
  

Widerrufsstrategie:

• Verknüpfen Sie SAS-Token mit einer gespeicherten Zugriffsrichtlinie, um sie leichter widerrufen zu können.
• Seien Sie darauf vorbereitet, die gespeicherte Zugriffsrichtlinie zu löschen oder die Schlüssel des Speicherkontos zu ändern, falls es zu Lecks kommt.
  

Überwachen und prüfen:

• Aktivieren Sie Azure Monitor und Storage-Protokolle, um den Zugriff auf das Speicherkonto zu überwachen.
• Implementieren Sie eine SAS-Ablaufrichtlinie, um die Nutzung von langfristigen SAS zu identifizieren.

Zusätzlich zu all diesen bewährten Standardverfahren hat Cyera spezifische Maßnahmen, die Ihre Organisation noch heute ergreifen kann, um die sichere Nutzung von SAS-Tokens zu gewährleisten.

Wie Cyera helfen kann

Wie bereits zuvor erläutert, birgt die Verwendung von SAS-Tokens zur Gewährung des Zugriffs auf Ihre Daten potenzielle Risiken für Datenverlust. Da das Widerrufen eines bestimmten SAS-Tokens nicht möglich ist, können Organisationen den Zugriffsschlüssel des Speicherkontos rotieren, wodurch alle Tokens ungültig werden – nicht nur die mit dem Speicherkonto verknüpften SAS-Tokens. Leider besteht das Hauptproblem dieser alternativen Lösung in einer Verschlechterung der Servicequalität.

Alternativ bietet Cyera einen vielseitigen Ansatz für Unternehmen, die ihre SAS-Tokens verwalten und absichern möchten, um deren angemessene und sichere Nutzung zu gewährleisten.

Transparenz bei SAS-Tokens. Cyera kann ein breites Spektrum an IaaS-, PaaS- und SaaS-Datenspeichern scannen und erkennt Azure SAS-Tokens sowohl in strukturierten als auch in unstrukturierten Daten, wie z. B. Datenbanken und Dateien innerhalb von Microsoft 365 und verschiedenen Cloud-Speicherdiensten. Dies verschafft Transparenz über das Vorhandensein und den Standort von SAS-Tokens.‍

Überwachen Sie den Zugriff auf SAS-Tokens. Cyera kann Einblicke in die Benutzer, Gruppen und anderen Identitäten geben, die auf Datenspeicher oder Dateien mit SAS-Tokens zugreifen können, sowie den Zweck, warum diese Identitäten Zugriff auf die Daten haben.

‍Fehlerkennung bei der Platzierung. Cyera kann erkennen, wenn Tokens in weniger sicheren Umgebungen gefunden werden. Zum Beispiel können einige Unternehmen festlegen, dass SAS-Tokens nur in bestimmten Produktionsumgebungen vorhanden sein dürfen. Wenn die SAS-Tokens jedoch in einer Entwicklungsumgebung mit offenem Zugang für viele Mitarbeitende landen, kann dies gegen Unternehmensrichtlinien verstoßen und einen Alarm auslösen.  ‍

Erkennung unautorisierter Token-Erstellung. Cyera kann eine Warnung generieren, wenn ein Azure-Speicherkonto über weitreichende Berechtigungen verfügt, die es unbeabsichtigten Nutzern ermöglichen, SAS-Tokens zu erstellen. Sicherheitsteams können Richtlinien festlegen, um diese Berechtigungen zu überwachen und einzuschränken und so eine sicherere Speicherumgebung durchzusetzen.‍

Erkennung ungeschützter Token. Cyera kann eine Warnung generieren, wenn SAS-Tokens in einem Datenspeicher mit öffentlichem Zugriff gefunden werden oder wenn das SAS-Token selbst als Klartext offengelegt wird, sodass jeder mit Zugriff auf den Datenspeicher das Token nutzen kann.‍

Fazit

Das unsachgemäße Erstellen oder Offenlegen von Azure Storage SAS-Tokens kann ein erhebliches Sicherheitsrisiko für Ihre sensiblen Daten darstellen. Cyera hilft, diese Risiken zu minimieren, indem die Sichtbarkeit, Nachvollziehbarkeit und Erkennung von SAS-Token-Exponierungen verbessert wird.‍

Cyera verfolgt einen datenzentrierten Ansatz für Sicherheit, indem es die Gefährdung Ihrer ruhenden und genutzten Daten bewertet und mehrere Verteidigungsschichten anwendet. Da Cyera tiefgehenden Datenkontext ganzheitlich über Ihre gesamte Datenlandschaft hinweg einsetzt, sind wir die einzige Lösung, die Sicherheitsteams in die Lage versetzt, zu wissen, wo sich ihre Daten befinden, was sie Risiken aussetzt, und sofortige Maßnahmen zur Behebung von Schwachstellen und zur Einhaltung von Compliance zu ergreifen – ohne den Geschäftsbetrieb zu stören.

Erfahren Sie mehr darüber, wie Sie Ihre Daten schützen können, und vereinbaren Sie noch heute eine Demo.