Umsetzen bewährter Methoden für die Sicherheit von Azure Storage

  • 8 Minuten

Wir haben uns angesehen, wie Sie eine Shared Access Signature (SAS) erstellen und mit ihr arbeiten und welche Vorteile sie für die Sicherheit Ihrer Speicherlösung haben kann.

Es ist wichtig zu verstehen, dass die Nutzung einer SAS in Ihrer Anwendung potenzielle Risiken bergen kann.

  • Wenn eine SAS kompromittiert wurde, kann sie von jedem verwendet werden, dem sie in die Hände fällt, auch von einem böswilligen Akteur.

  • Wenn eine einer Clientanwendung bereitgestellte SAS abläuft und die Anwendung keine neue SAS von Ihrem Dienst abrufen kann, wird die Funktionsweise der Anwendung möglicherweise eingeschränkt.

Sehen Sie sich dieses Video an, um weitere Informationen zum Sichern Ihres Speichers zu erhalten. Dieses Video basiert auf Tipps und Tricks zu Azure #272: Bewährte Sicherheitsmethoden für Azure.

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. Alle Richtlinien, in denen eine längere Dauer angegeben ist, schlagen fehl.
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.
Grundlegendes zur Kontoabrechnung für die Nutzung, einschließlich einer SAS Wenn Sie Schreibzugriff auf einen Blob gewähren, können Benutzer Blobs mit bis zu 200 GB hochladen. Wenn Sie ihnen auch Lesezugriff gewährt haben, laden sie das Blob ggf. 10 Mal herunter, was Datenausgangskosten für 2 TB nach sich zieht. Vergeben Sie also auch hierbei eingeschränkte Berechtigungen, um die möglichen Aktionen böswilliger Benutzer abzuschwächen. Verwenden Sie eine kurzlebige SAS, um diese Bedrohung zu mindern (beachten Sie jedoch mögliche Uhrabweichungen bei der Ablaufzeit).
Ü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.
Überwachen Ihrer Anwendungen mit Azure Storage Analytics Mithilfe von Protokollen und Metriken können Sie Spitzen bei Authentifizierungsfehlern ermitteln. Es kann sein, dass Sie aufgrund eines Ausfalls Ihres SAS-Anbieterdiensts oder der versehentlichen Entfernung einer gespeicherten Zugriffsrichtlinie Spitzen feststellen.