Speicherkonten und Zuverlässigkeit

Azure Storage-Konten eignen sich ideal für Workloads, die schnelle und konsistente Antwortzeiten erfordern oder eine hohe Anzahl von Ein-/Ausgabevorgängen pro Sekunde (IOPS) aufweisen. Speicherkonten enthalten alle Ihre Azure Storage-Datenobjekte, einschließlich:

• BLOBs
• Dateifreigaben
• Warteschlangen
• Tabellen
• Datenträger

Speicherkonten bieten einen eindeutigen Namespace für Ihre Daten, auf die überall über HTTP oder HTTPS zugegriffen werden kann.

Weitere Informationen zu den verschiedenen Typen von Speicherkonten, die unterschiedliche Features unterstützen, finden Sie unter Speicherkontotypen.

Lesen Sie die folgenden Artikel, um zu verstehen, wie ein Azure Storage-Konto die Resilienz für Ihre Anwendungsworkload unterstützt:

• Azure Storage-Redundanz
• Notfallwiederherstellung und Speicherkontofailover

Die folgenden Abschnitte enthalten Entwurfsüberlegungen, eine Konfigurationsprüfliste und empfohlene Konfigurationsoptionen speziell für Azure Storage-Konten und deren Zuverlässigkeit.

Überlegungen zum Entwurf

Für Azure Storage-Konten gelten die folgenden Entwurfsüberlegungen:

• Speicherkonten vom Typ „Universell v1“ ermöglichen Zugriff auf alle Azure Storage-Dienste, verfügen aber möglicherweise nicht über die neuesten Features oder die niedrigeren Preise pro Gigabyte. In den meisten Fällen ist es ratsam, Speicherkonten vom Typ „Universell v2“ zu verwenden. Gründe für die Verwendung von v1:

  • Für die Anwendungen ist das klassische Bereitstellungsmodell erforderlich.
  • Die Anwendungen verursachen eine hohe Transaktionslast oder nutzen eine erhebliche Bandbreite für die Georeplikation, benötigen aber keine großen Kapazitäten.
  • Die Verwendung einer Storage-Dienste-REST-API von vor dem 14. Februar 2014 oder einer Clientbibliothek mit einer früheren Version als 4.x ist erforderlich. Ein Anwendungsupgrade ist nicht möglich.

Weitere Informationen finden Sie unter Speicherkontoübersicht.

• Speicherkontonamen müssen zwischen 3 und 24 Zeichen lang sein und dürfen nur Zahlen und Kleinbuchstaben enthalten.
• Die aktuellen SLA-Spezifikationen finden Sie unter SLA für Speicherkonten.
• Unter Azure Storage-Redundanz können Sie ermitteln, welche Redundanzoption für ein bestimmtes Szenario am besten geeignet ist.
• Die Namen der Speicherkonten müssen innerhalb von Azure eindeutig sein. Zwei Speicherkonten können nicht denselben Namen haben.

Checkliste

Haben Sie Ihr Azure Storage-Konto mit Blick auf die Zuverlässigkeit konfiguriert?

• Aktivieren des vorläufigen Löschens für Blobdaten
• Verwenden Sie Microsoft Entra-ID, um den Zugriff auf Blobdaten zu autorisieren.
• Berücksichtigen Sie das Prinzip der geringsten Berechtigungen, wenn Sie einem Microsoft Entra Sicherheitsprinzipal über Azure RBAC Berechtigungen zuweisen.
• Verwenden verwalteter Identitäten für den Zugriff auf Blob- und Warteschlangendaten
• Verwenden der Blobversionsverwaltung oder von unveränderlichen Blobs zum Speichern unternehmenskritischer Daten
• Einschränken des Standardinternetzugriffs für Speicherkonten
• Aktivieren Sie Firewallregeln.
• Beschränken Sie den Netzwerkzugriff auf bestimmte Netzwerke.
• Erlauben Sie vertrauenswürdigen Microsoft-Diensten den Zugriff auf das Speicherkonto.
• Aktivieren der Option Sichere Übertragung erforderlich für alle Speicherkonten
• Beschränken von SAS-Token (Shared Access Signature) auf HTTPS-Verbindungen
• Vermeiden und Verhindern der Autorisierung mit gemeinsam verwendeten Schlüsseln für den Zugriff auf Speicherkonten
• Generieren Sie Ihre Kontoschlüssel in regelmäßigen Abständen neu.
• Erstellen und Erzwingen eines Sperrungsplans für alle SAS, die Sie für Clients ausstellen
• Verwenden von Ablaufdaten in naher Zukunft für eine Ad-hoc-, Dienst- oder Konto-SAS

Konfigurationsempfehlungen

Beachten Sie die folgenden Empfehlungen zur Optimierung der Zuverlässigkeit beim Konfigurieren Ihres Azure Storage-Kontos:

Empfehlung	BESCHREIBUNG
Aktivieren des vorläufigen Löschens für Blobdaten	Das vorläufige Löschen für Azure Storage-Blobs ermöglicht es Ihnen, Blobdaten nach dem Löschen wiederherzustellen.
Verwenden Sie Microsoft Entra-ID, um den Zugriff auf Blobdaten zu autorisieren.	Microsoft Entra-ID bietet überlegene Sicherheit und Benutzerfreundlichkeit gegenüber shared key zum Autorisieren von Anforderungen an Blob storage. Es wird empfohlen, nach Möglichkeit Microsoft Entra Autorisierung mit Ihren Blob- und Warteschlangenanwendungen zu verwenden, um potenzielle Sicherheitsrisiken zu minimieren, die mit freigegebenem Schlüssel verbunden sind. Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf Azure-Blobs und -Warteschlangen mithilfe Microsoft Entra-ID.
Berücksichtigen Sie das Prinzip der geringsten Berechtigungen, wenn Sie einem Microsoft Entra Sicherheitsprinzipal über Azure RBAC Berechtigungen zuweisen.	Wenn Sie einem Benutzer, einer Gruppe oder einer Anwendung eine Rolle zuweisen, erteilen Sie diesem Sicherheitsprinzipal nur die Berechtigungen, die zum Durchführen der jeweiligen Aufgaben erforderlich sind. Durch Einschränken des Zugriffs auf Ressourcen kann sowohl ein unbeabsichtigter als auch böswilliger Missbrauch Ihrer Daten verhindert werden.
Verwenden verwalteter Identitäten für den Zugriff auf Blob- und Warteschlangendaten	Azure Blob- und Warteschlangenspeicher unterstützen Microsoft Entra Authentifizierung mit verwalteten Identitäten für Azure-Ressourcen. Verwaltete Identitäten für Azure-Ressourcen können den Zugriff auf Blob- und Warteschlangendaten mithilfe Microsoft Entra Anmeldeinformationen von Anwendungen autorisieren, die auf Azure-VMs(VMs), Funktions-Apps, VM-Skalierungsgruppen und anderen Diensten ausgeführt werden. Wenn Sie verwaltete Identitäten für Azure-Ressourcen zusammen mit Microsoft Entra Authentifizierung verwenden, können Sie das Speichern von Anmeldeinformationen bei Ihren Anwendungen, die in der Cloud ausgeführt werden, und Probleme mit ablaufenden Dienstprinzipalen vermeiden. Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf Blobdaten mit verwalteten Identitäten für Azure-Ressourcen.
Verwenden der Blobversionsverwaltung oder von unveränderlichen Blobs zum Speichern unternehmenskritischer Daten	Erwägen Sie die Verwendung der Blobversionsverwaltung, um frühere Versionen eines Objekts zu verwalten oder gesetzliche und zeitbasierte Aufbewahrungsrichtlinien für die Speicherung von Blobdaten in einem WORM-Zustand (Write Once, Read Many) anzuwenden. Unveränderliche Blobs können während des Aufbewahrungszeitraums zwar gelesen, aber nicht geändert oder gelöscht werden. Weitere Informationen finden Sie unter Speichern unternehmenskritischer Blobdaten mit unveränderlichem Speicher.
Einschränken des Standardinternetzugriffs für Speicherkonten	Standardmäßig ist der Netzwerkzugriff auf Speicherkonten nicht beschränkt und für den gesamten Datenverkehr aus dem Internet offen. Der Zugriff auf Speicherkonten sollte nach Möglichkeit nur bestimmten virtuellen Azure-Netzwerken gewährt werden. Sie können auch private Endpunkte verwenden, um Clients in einem virtuellen Netzwerk (VNET) den sicheren Zugriff auf Daten über Private Link zu ermöglichen. Weitere Informationen finden Sie unter Verwenden privater Endpunkte für Azure Storage. Für Speicherkonten, auf die der Zugriff über das Internet notwendig ist, können Ausnahmen eingerichtet werden.
Aktivieren Sie Firewallregeln.	Konfigurieren Sie Firewallregeln, um den Zugriff auf Ihr Speicherkonto auf Anforderungen zu beschränken, die aus angegebenen IP-Adressen oder -Adressbereichen oder einer Liste von Subnetzen in einem virtuellen Azure-Netzwerk (VNET) stammen. Weitere Informationen zum Konfigurieren von Firewallregeln finden Sie unter Konfigurieren von Azure Storage-Firewalls und virtuellen Netzwerken.
Beschränken Sie den Netzwerkzugriff auf bestimmte Netzwerke.	Das Beschränken des Netzwerkzugriffs auf Netzwerke, in denen Clients gehostet werden, die Zugriff benötigen, verringert die Anfälligkeit Ihrer Ressourcen für Netzwerkangriffe, indem entweder die integrierte Firewall und virtuelle Netzwerke oder private Endpunkte verwendet werden.
Erlauben Sie vertrauenswürdigen Microsoft-Diensten den Zugriff auf das Speicherkonto.	Wenn Sie Firewallregeln für Speicherkonten aktivieren, werden eingehende Datenanforderungen standardmäßig blockiert – es sei denn, die Anforderungen stammen von einem Dienst, der innerhalb eines virtuellen Azure-Netzwerks (VNet) agiert, oder von zulässigen öffentlichen IP-Adressen. Unter anderem werden Anforderungen von anderen Azure-Diensten, aus dem Azure-Portal und von Protokollierungs-/Metrikdiensten blockiert. Sie können Anforderungen von anderen Azure-Diensten zulassen, indem Sie eine Ausnahme hinzufügen, um vertrauenswürdigen Microsoft-Diensten den Zugriff auf das Speicherkonto zu gewähren. Weitere Informationen zum Hinzufügen einer Ausnahme für vertrauenswürdige Microsoft-Dienste finden Sie unter Konfigurieren von Azure Storage-Firewalls und virtuellen Netzwerken.
Aktivieren der Option Sichere Übertragung erforderlich für alle Speicherkonten	Wenn Sie die Option Sichere Übertragung erforderlich aktivieren, müssen alle an das Speicherkonto gerichteten Anforderungen über sichere Verbindungen erfolgen. Bei Anforderungen über HTTP treten Fehler auf. Weitere Informationen finden Sie unter Erzwingen einer sicheren Übertragung für sichere Verbindungen.
Beschränken von SAS-Token (Shared Access Signature) auf HTTPS-Verbindungen	Durch das Erzwingen von HTTPS, wenn ein Client ein SAS-Token für den Zugriff auf Blobdaten nutzt, kann das Risiko eines Lauschangriffs reduziert werden. Weitere Informationen finden Sie unter Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature).
Vermeiden und Verhindern der Autorisierung mit gemeinsam verwendeten Schlüsseln für den Zugriff auf Speicherkonten	Es wird empfohlen, Microsoft Entra-ID zu verwenden, um Anforderungen an Azure Storage zu autorisieren und die Autorisierung gemeinsam genutzter Schlüssel zu verhindern. In Szenarios, die eine Autorisierung mit gemeinsam verwendeten Schlüsseln erfordern, sollten Sie immer SAS-Token gegenüber der Verteilung des gemeinsam verwendeten Schlüssels bevorzugen.
Generieren Sie Ihre Kontoschlüssel in regelmäßigen Abständen neu.	Durch regelmäßiges Rotieren der Kontoschlüssel verringert sich das Risiko, dass Ihre Daten für böswillige Akteure offengelegt werden.
Erstellen und Erzwingen eines Sperrungsplans für alle SAS, die Sie für Clients ausstellen	Wenn eine SAS kompromittiert wurde, sollten Sie diese sofort widerrufen. Zum Widerrufen einer SAS für die Benutzerdelegierung widerrufen Sie den Benutzerdelegierungsschlüssel, um alle diesem Schlüssel zugeordneten Signaturen schnell ungültig zu machen. Zum Widerrufen einer Dienst-SAS, die einer gespeicherten Zugriffsrichtlinie zugeordnet ist, können Sie die gespeicherte Zugriffsrichtlinie löschen, die Richtlinie umbenennen oder die Ablaufzeit in einen Zeitpunkt in der Vergangenheit ändern.
Verwenden von Ablaufdaten in naher Zukunft für eine Ad-hoc-, Dienst- oder Konto-SAS	Wenn eine SAS kompromittiert wurde, ist sie nur für kurze Zeit gültig. Das ist insbesondere 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. Die Clients sollten ihre SAS rechtzeitig vor der Ablaufzeit erneuern, um Zeit für Wiederholungsversuche zuzulassen, falls der entsprechende Dienst nicht verfügbar sein sollte.

Nächster Schritt

Speicherkonten und Sicherheit