Azure Storage-Verschlüsselung für ruhende Daten

Azure Storage verwendet dienstseitige Verschlüsselung (Server Side Encryption, SSE), um Ihre Daten beim Speichern in der Cloud automatisch zu verschlüsseln. Durch die Azure Storage-Verschlüsselung werden Ihre Daten ausreichend geschützt, um den Sicherheits- und Complianceanforderungen Ihrer Organisation gerecht zu werden.

Microsoft empfiehlt die Verwendung dienstseitiger Verschlüsselung, um Ihre Daten für die meisten Szenarien zu schützen. Die Azure Storage-Clientbibliotheken für Blob Storage und Queue Storage bieten jedoch auch clientseitige Verschlüsselung für Kunden, die Daten auf dem Client verschlüsseln müssen. Weitere Informationen finden Sie unter Clientseitige Verschlüsselung für Blobs und Warteschlangen.

Informationen zur dienstseitigen Azure Storage-Verschlüsselung

Daten in Azure Storage werden auf transparente Weise mit der AES-256-Verschlüsselung ver- und entschlüsselt, einer der stärksten verfügbaren Blockchiffren, und sind mit dem FIPS 140-2-Standard konform. Die Azure Storage-Verschlüsselung ähnelt der BitLocker-Verschlüsselung unter Windows.

Die Azure Storage-Verschlüsselung ist für alle Speicherkonten aktiviert, einschließlich Resource Manager-Speicherkonten und klassischer Speicherkonten. Die Azure Storage-Verschlüsselung kann nicht deaktiviert werden. Da Ihre Daten standardmäßig geschützt werden, müssen Sie weder Code noch Anwendungen ändern, um die Azure Storage-Verschlüsselung nutzen zu können.

Daten in einem Speicherkonto werden unabhängig von der Leistungsstufe (Standard oder Premium), der Zugriffsebene (heiß oder kalt) und dem Bereitstellungsmodell (Azure Resource Manager oder klassisch) verschlüsselt. Außerdem werden auch alle Blobs auf der Archivebene verschlüsselt. Die Verschlüsselung wird von allen Azure Storage-Redundanzoptionen unterstützt, und bei aktivierter Georeplikation werden alle Daten in der primären und sekundären Region verschlüsselt. Alle Azure Storage-Ressourcen werden verschlüsselt, z. B. Blobs, Datenträger, Dateien, Warteschlangen und Tabellen. Objektmetadaten werden ebenfalls verschlüsselt. Es fallen keine zusätzlichen Kosten für die Azure Storage-Verschlüsselung an.

Alle Blockblobs, Anfügeblobs und Seitenblobs, die nach dem 20. Oktober 2017 in Azure Storage geschrieben wurden, sind verschlüsselt. Blobs, die vor diesem Datum erstellt wurden, werden weiterhin durch einen Hintergrundprozess verschlüsselt. Um die Verschlüsselung eines Blobs zu erzwingen, das vor dem 20. Oktober 2017 erstellt wurde, können Sie das Blob neu schreiben. Informationen zum Überprüfen des Verschlüsselungsstatus eines Blobs finden Sie unter Überprüfen des Verschlüsselungsstatus eines Blobs.

Weitere Informationen zu den kryptografischen Modulen, die der Azure Storage-Verschlüsselung zugrunde liegen, finden Sie unter Kryptografie-API: Die nächste Generation.

Weitere Informationen zur Verschlüsselung und Schlüsselverwaltung für verwaltete Azure-Datenträger finden Sie unter Serverseitige Verschlüsselung von verwalteten Azure-Datenträgern.

Informationen zur Verwaltung von Verschlüsselungsschlüsseln

Daten in einem neuen Speicherkonto werden standardmäßig mit von Microsoft verwalteten Schlüsseln verschlüsselt. Sie können von Microsoft verwaltete Schlüssel für die Verschlüsselung Ihrer Daten weiterhin nutzen oder die Verschlüsselung mit Ihren eigenen Schlüsseln verwalten. Wenn Sie die Verschlüsselungsverwaltung mit Ihren eigenen Schlüsseln wählen, haben Sie zwei Optionen. Sie können eine der beiden Arten der Schlüsselverwaltung oder beide verwenden:

  • Sie können einen kundenseitig verwalteten Schlüssel angeben, der zum Verschlüsseln und Entschlüsseln von Daten in Blob Storage und in Azure Files verwendet werden soll.1,2 Kundenseitig verwaltete Schlüssel müssen in Azure Key Vault oder Azure Key Vault Managed Hardware Security Model (HSM) gespeichert werden. Weitere Informationen zu kundenseitig verwalteten Schlüsseln finden Sie unter Verwenden kundenseitig verwalteter Schlüssel für die Azure Storage-Verschlüsselung.
  • Sie können einen vom Kunden bereitgestellten Schlüssel für Blob Storage-Vorgänge angeben. Ein Client, der eine Lese- oder Schreibanforderung für Blob Storage sendet, kann einen Verschlüsselungsschlüssel für die Anforderung enthalten, um genau steuern zu können, wie Blobdaten verschlüsselt und entschlüsselt werden. Weitere Informationen zu vom Kunden bereitgestellten Schlüsseln finden Sie unter Angeben eines Verschlüsselungsschlüssels bei Stellen einer Anforderung für Blob Storage.

Standardmäßig wird ein Speicherkonto mit einem Schlüssel verschlüsselt, der für das gesamte Speicherkonto gilt. Verschlüsselungsbereiche ermöglichen Ihnen die Verwaltung der Verschlüsselung mit einem Schlüssel, der auf einen Container oder ein einzelnes Blob beschränkt ist. Sie können Verschlüsselungsbereiche verwenden, um sichere Grenzen zwischen Daten zu erstellen, die sich im selben Speicherkonto befinden, aber zu unterschiedlichen Kunden gehören. Für Verschlüsselungsbereiche können entweder von Microsoft verwaltete Schlüssel oder kundenseitig verwaltete Schlüssel verwendet werden. Weitere Informationen zu Verschlüsselungsbereichen finden Sie unter Verschlüsselungsbereiche für Blobspeicher.

In der folgenden Tabelle werden die Schlüsselverwaltungsoptionen für Azure Storage-Verschlüsselung verglichen.

Schlüsselverwaltungsparameter Von Microsoft verwaltete Schlüssel Vom Kunden verwaltete Schlüssel Vom Kunden bereitgestellte Schlüssel
Verschlüsselungs-/Entschlüsselungsvorgänge Azure Azure Azure
Unterstützte Azure Storage-Dienste All Blob Storage, Azure Files1,2 Blob Storage
Schlüsselspeicher Microsoft-Schlüsselspeicher Azure Key Vault oder Key Vault HSM Eigener Schlüsselspeicher des Kunden
Verantwortlich für die Schlüsselrotation Microsoft Kunde Kunde
Schlüsselkontrolle Microsoft Kunde Kunde
Schlüsselbereich Konto (Standard), Container oder Blob Konto (Standard), Container oder Blob

1 Informationen zum Erstellen eines Kontos, das die Verwendung von kundenseitig verwalteten Schlüsseln mit Queue Storage unterstützt, finden Sie unter Erstellen eines Kontos, das kundenseitig verwaltete Schlüssel für Warteschlangen unterstützt.
2 Informationen zum Erstellen eines Kontos, das die Verwendung von kundenseitig verwalteten Schlüsseln mit Table Storage unterstützt, finden Sie unter Erstellen eines Kontos, das kundenseitig verwaltete Schlüssel für Tabellen unterstützt.

Hinweis

Von Microsoft verwaltete Schlüssel werden entsprechend den Complianceanforderungen gedreht. Wenn Sie bestimmte Anforderungen an die Schlüsselrotation haben, empfiehlt Microsoft, dass Sie zu kundenseitig verwalteten Schlüsseln wechseln, sodass Sie die Rotation selbst verwalten und überprüfen können.

Doppelte Verschlüsselung von Daten mit Infrastrukturverschlüsselung

Kunden, die hohe Anforderungen an den Schutz ihrer Daten stellen, können auch die 256-Bit-AES-Verschlüsselung auf Azure Storage-Infrastrukturebene aktivieren. Wenn die Infrastrukturverschlüsselung aktiviert ist, werden Daten in einem Speicherkonto zweimal — einmal auf dem Servicelevel und einmal auf der Infrastrukturebene — mit zwei unterschiedlichen Verschlüsselungsalgorithmen und zwei verschiedenen Schlüsseln verschlüsselt. Die doppelte Verschlüsselung von Azure Storage-Daten schützt vor dem Szenario, dass einer der Verschlüsselungsalgorithmen oder Schlüssel kompromittiert wurde. In diesem Szenario werden die Daten weiterhin durch die zusätzliche Verschlüsselungsebene geschützt.

Die Verschlüsselung auf dem Servicelevel unterstützt die Verwendung von Microsoft verwalteter Schlüssel oder vom Kunden verwalteter Schlüssel mit Azure Key Vault. Die Verschlüsselung auf Infrastrukturebene basiert auf von Microsoft verwalteten Schlüsseln und verwendet immer einen separaten Schlüssel.

Weitere Informationen zum Erstellen eines Speicherkontos, das die Infrastrukturverschlüsselung ermöglicht, finden Sie unter Erstellen eines Speicherkontos mit aktivierter Infrastrukturverschlüsselung für die doppelte Datenverschlüsselung.

Clientseitige Verschlüsselung für Blobs und Warteschlangen

Die Azure Blob Storage-Clientbibliotheken für .NET, Java und Python unterstützen die Verschlüsselung von Daten innerhalb von Clientanwendungen vor dem Hochladen der Daten nach Azure Storage sowie die Entschlüsselung von Daten während des Herunterladens auf den Client. Die Queue Storage-Clientbibliotheken für .NET und Python unterstützen auch die clientseitige Verschlüsselung.

Hinweis

Verwenden Sie die von Azure Storage bereitgestellten dienstseitigen Verschlüsselungsfeatures, um Ihre Daten zu schützen, anstatt clientseitige Verschlüsselung zu verwenden.

Die Blob Storage- und Queue Storage-Clientbibliotheken verwenden AES, um Benutzerdaten zu verschlüsseln. Es gibt zwei Versionen der clientseitigen Verschlüsselung in den Clientbibliotheken:

  • Version 2 verwendet den GCM-Modus (Galois/Counter Mode) mit AES. Die Blob Storage und Queue Storage SDKs unterstützen clientseitige Verschlüsselung mit v2.
  • Version 1 verwendet den CBC-Modus (Cipher Block Chaining, Blockchiffreverkettung) mit AES. Die Blob Storage, Queue Storage und Table Storage SDKs unterstützen clientseitige Verschlüsselung mit v1.

Warnung

Die Verwendung von Version 1 der clientseitigen Verschlüsselung wird aufgrund einer Sicherheitslücke in der Implementierung des CBC-Modus der Clientbibliothek nicht mehr empfohlen. Weitere Informationen zu dieser Sicherheitslücke finden Sie unter Azure Storage updating client-side encryption in SDK to address security vulnerability (Azure Storage aktualisiert clientseitige Verschlüsselung im SDK, um Sicherheitsrisiken zu beheben). Wenn Sie derzeit Version 1 verwenden, sollten Sie Ihre Anwendung auf die Verwendung von Version 2 der clientseitigen Verschlüsselung aktualisieren und Ihre Daten migrieren.

Das Azure Table Storage SDK unterstützt nur Version 1 der clientseitigen Verschlüsselung. Die Verwendung clientseitiger Verschlüsselung mit Table Storage wird nicht empfohlen.

In der folgenden Tabelle wird gezeigt, welche Clientbibliotheken welche Versionen der clientseitigen Verschlüsselung unterstützen, und sie enthält Richtlinien für die Migration zur clientseitigen Verschlüsselung v2.

Clientbibliothek Unterstützte Version der clientseitigen Verschlüsselung Empfohlene Migration Zusätzliche Anleitungen
Blob Storage-Clientbibliotheken für .NET (Version 12.13.0 und höher), Java (Version 12.18.0 und höher) und Python (Version 12.13.0 und höher) 2.0

1.0 (nur aus Gründen der Abwärtskompatibilität beibehalten)
Aktualisieren Sie Ihren Code zur Verwendung von clientseitiger Verschlüsselung v2.

Laden Sie alle verschlüsselten Daten herunter, um sie zu entschlüsseln und dann mit clientseitiger Verschlüsselung v2 erneut zu verschlüsseln.
Clientseitige Verschlüsselung für Blobs
Blob Storage-Clientbibliothek für .NET (Version 12.12.0 und niedriger), Java (Version 12.17.0 und niedriger) und Python (Version 12.12.0 und niedriger) 1.0 (nicht empfohlen) Aktualisieren Sie Ihre Anwendung, um eine Version des Blob Storage-SDK zu verwenden, die clientseitige Verschlüsselung v2 unterstützt. Details siehe SDK-Unterstützungsmatrix für clientseitige Verschlüsselung.

Aktualisieren Sie Ihren Code zur Verwendung von clientseitiger Verschlüsselung v2.

Laden Sie alle verschlüsselten Daten herunter, um sie zu entschlüsseln und dann mit clientseitiger Verschlüsselung v2 erneut zu verschlüsseln.
Clientseitige Verschlüsselung für Blobs
Queue Storage-Clientbibliothek für .NET (Version 12.11.0 und höher) und Python (Version 12.4 und höher) 2.0

1.0 (nur aus Gründen der Abwärtskompatibilität beibehalten)
Aktualisieren Sie Ihren Code zur Verwendung von clientseitiger Verschlüsselung v2. Clientseitige Verschlüsselung für Warteschlangen
Queue Storage-Clientbibliothek für .NET (Version 12.10.0 und niedriger) und Python (Version 12.3.0 und niedriger) 1.0 (nicht empfohlen) Aktualisieren Sie Ihre Anwendung, um eine Version des Queue Storage-SDK zu verwenden, die clientseitige Verschlüsselung v2 unterstützt. Siehe SDK-Unterstützungsmatrix für clientseitige Verschlüsselung.

Aktualisieren Sie Ihren Code zur Verwendung von clientseitiger Verschlüsselung v2.
Clientseitige Verschlüsselung für Warteschlangen
Table Storage-Clientbibliothek für .NET, Java und Python 1.0 (nicht empfohlen) Nicht verfügbar.

Nächste Schritte