Clientseitige Verschlüsselung für Blobs

  • Artikel

Die Azure Blob Storage-Clientbibliothek für .NET unterstützt 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. Um die Schlüsselverwaltung für Speicherkonten zu ermöglichen, unterstützt die Bibliothek zudem die Integration in Azure Key Vault.

Wichtig

Blob Storage unterstützt sowohl dienstseitige als auch clientseitige Verschlüsselung. In den meisten Szenarien empfiehlt Microsoft die Verwendung von dienstseitigen Verschlüsselungsfeatures zum benutzerfreundlichen Schutz Ihrer Daten. Weitere Informationen zur dienstseitigen Verschlüsselung finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.

Ein ausführliches Tutorial, das Sie Schritt für Schritt durch die Verschlüsselung von Blobs mittels clientseitiger Verschlüsselung und Azure Key Vault führt, finden Sie unter Verschlüsseln und Entschlüsseln von Blobs in Microsoft Azure Storage per Azure-Schlüsseltresor.

Informationen zur clientseitigen Verschlüsselung

Die Azure Blob Storage-Clientbibliothek verwendet AES, um Benutzerdaten zu verschlüsseln. Es gibt zwei Versionen der clientseitigen Verschlüsselung in der Clientbibliothek:

  • Version 2 verwendet den GCM-Modus (Galois/Counter Mode) mit AES.
  • Version 1 verwendet den CBC-Modus (Cipher Block Chaining, Blockchiffreverkettung) mit AES.

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 aktualisieren und Ihre Daten migrieren. Weitere Anleitungen finden Sie im folgenden Abschnitt, Verringern der Sicherheitsrisiken in Ihren Anwendungen.

Verringern der Sicherheitsrisiken in Ihren Anwendungen

Aufgrund eines in der Implementierung des CBC-Modus der Blob Storage-Clientbibliothek entdeckten Sicherheitsrisikos empfiehlt Microsoft, eine oder mehrere der folgenden Aktionen sofort auszuführen:

  • Erwägen Sie die Verwendung von dienstseitigen Verschlüsselungsfeatures anstelle der clientseitigen Verschlüsselung. Weitere Informationen zu dienstseitigen Verschlüsselungsfeatures finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.

  • Wenn Sie clientseitige Verschlüsselung verwenden müssen, migrieren Sie Ihre Anwendungen von Version 1 der clientseitigen Verschlüsselung zu Version 2 der clientseitigen Verschlüsselung.

In der folgenden Tabelle werden die Schritte zusammengefasst, die Sie ausführen müssen, wenn Sie Ihre Anwendungen zu Version 2 der clientseitigen Verschlüsselung migrieren möchten:

Status der clientseitigen Verschlüsselung Empfohlene Aktionen
Die Anwendung verwendet die clientseitige Verschlüsselung mit einer Version der Clientbibliothek, die nur die clientseitige Verschlüsselung v1 unterstützt. Aktualisieren Sie Ihre Anwendung, um eine Version der Clientbibliothek zu verwenden, die die clientseitige Verschlüsselung v2 unterstützt. Eine Liste der unterstützten Versionen finden Sie unter SDK-Unterstützungsmatrix für clientseitige Verschlüsselung. Weitere Informationen

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

Laden Sie alle verschlüsselten Daten herunter, um sie zu entschlüsseln und dann mit clientseitiger Verschlüsselung v2 erneut zu verschlüsseln. Weitere Informationen
Die Anwendung verwendet clientseitige Verschlüsselung mit einer Version der Clientbibliothek, die clientseitige Verschlüsselung v2 unterstützt. Aktualisieren Sie Ihren Code zur Verwendung von clientseitiger Verschlüsselung v2. Weitere Informationen

Laden Sie alle verschlüsselten Daten herunter, um sie zu entschlüsseln und dann mit clientseitiger Verschlüsselung v2 erneut zu verschlüsseln. Weitere Informationen

Darüber hinaus empfiehlt Microsoft, die folgenden Schritte auszuführen, um Ihre Daten zu sichern:

  • Konfigurieren Sie Ihre Speicherkonten so, dass private Endpunkte verwendet werden, um den gesamten Datenverkehr zwischen Ihrem virtuellen Netzwerk (VNet) und Ihrem Speicherkonto über einen privaten Link zu sichern. Weitere Informationen finden Sie unter Verwenden privater Endpunkte für Azure Storage.
  • Schränken Sie den Netzwerkzugriff auf bestimmte Netzwerke ein.

SDK-Unterstützungsmatrix für clientseitige Verschlüsselung

Die folgende Tabelle zeigt, welche Versionen der Clientbibliotheken für .NET, Java und Python welche Versionen der clientseitigen Verschlüsselung unterstützen:

.NET Java Python
Clientseitige Verschlüsselung v2 und v1 Versionen 12.13.0 und höher Versionen 12.18.0 und höher Versionen 12.13.0 und höher
Nur clientseitige Verschlüsselung v1 Versionen 12.12.0 und früher Versionen 12.17.0 und früher Versionen 12.12.0 und früher

Wenn Ihre Anwendung clientseitige Verschlüsselung mit einer früheren Version der .NET-, Java- oder Python-Clientbibliothek verwendet, müssen Sie zuerst Ihren Code auf eine Version aktualisieren, die clientseitige Verschlüsselung v2 unterstützt. Als Nächstes müssen Sie Ihre Daten mit clientseitiger Verschlüsselung v2 entschlüsseln und erneut verschlüsseln. Bei Bedarf können Sie eine Version der Clientbibliothek verwenden, die clientseitige Verschlüsselung v2 parallel zu einer früheren Version der Clientbibliothek unterstützt, während Sie Ihren Code migrieren. Codebeispiele finden Sie unter Beispiel: Verschlüsseln und Entschlüsseln eines Blobs mit clientseitiger Verschlüsselung v2.

Funktionsweise der clientseitigen Verschlüsselung

Die Azure Blob Storage-Clientbibliotheken verwenden die Umschlagverschlüsselung, um Ihre Daten auf der Clientseite zu verschlüsseln und zu entschlüsseln. Die Umschlagverschlüsselung verschlüsselt einen Schlüssel mit einem oder mehreren zusätzlichen Schlüsseln.

Die Blob Storage-Clientbibliotheken basieren auf Azure Key Vault, um die Schlüssel zu schützen, die für die clientseitige Verschlüsselung verwendet werden. Weitere Informationen zum Azure Key Vault finden Sie unter What is Azure Key Vault? (Was ist der Azure Key Vault?).

Verschlüsselung und Entschlüsselung über das Umschlagverfahren

Die Verschlüsselung über das Umschlagverfahren funktioniert wie folgt:

  1. Die Azure Storage-Clientbibliothek generiert einen Inhaltsverschlüsselungsschlüssel (Content Encryption Key, CEK), bei dem es sich um einen einmalig verwendeten symmetrischen Schlüssel handelt.

  2. Benutzerdaten werden mit diesem CEK verschlüsselt.

  3. Der CEK wird dann mit dem Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) umschlossen (verschlüsselt). Der KEK wird anhand einer Schlüsselkennung identifiziert und kann ein asymmetrisches Schlüsselpaar oder ein symmetrischer Schlüssel sein. Sie können den KEK lokal verwalten oder in Azure Key Vault speichern.

    Die Azure Storage-Clientbibliothek hat selbst nie Zugriff auf den KEK. Die Bibliothek ruft lediglich den Algorithmus für das Umschließen des Schlüssels aus, der vom Schlüsseltresor bereitgestellt wird. Benutzer können bei Bedarf benutzerdefinierte Anbieter für das Umschließen von Schlüsseln bzw. das Aufheben dieses Zustands verwenden.

  4. Die verschlüsselten Daten werden dann in Azure Blob Storage hochgeladen. Der umbrochene Schlüssel wird zusammen mit einigen zusätzlichen Verschlüsselungsmetadaten als Metadaten im Blob gespeichert.

Die Entschlüsselung über das Umschlagverfahren funktioniert wie folgt:

  1. Die Azure Storage-Clientbibliothek geht davon aus, dass der Benutzer den KEK entweder lokal oder in einer Azure Key Vault-Instanz verwaltet. Der Benutzer muss den spezifischen Schlüssel, der für die Verschlüsselung verwendet wurde, nicht kennen. Stattdessen kann ein Schlüsselresolver eingerichtet und verwendet werden, der verschiedene Schlüsselkennungen in Schlüssel auflöst.
  2. Die Clientbibliothek lädt die verschlüsselten Daten zusammen mit sämtlichem Verschlüsselungsmaterial herunter, das in Azure Storage gespeichert ist.
  3. Der umschlossene CEK wird dann mit dem KEK entpackt (entschlüsselt). Die Clientbibliothek hat während dieses Prozesses keinen Zugriff auf den KEK, sondern ruft nur den Entpackungsalgorithmus der Azure Key Vault-Instanz oder eines anderen Schlüsselspeichers auf.
  4. Die Clientbibliothek verwendet den CEK, um die verschlüsselten Benutzerdaten zu entschlüsseln.

Verschlüsselung/Entschlüsselung im Upload/Download des Blobs

Die Blob Storage-Clientbibliothek unterstützt die Verschlüsselung ganzer Blobs nur im Upload. Es werden sowohl vollständige Downloads als auch Downloads von Bereichen unterstützt.

Bei der Verschlüsselung generiert die Clientbibliothek einen zufälligen Initialisierungsvektor (IV) mit einer Größe von 16 Byte zusammen mit einem zufälligen CEK mit einer Größe von 32 Byte. Mithilfe dieser Informationen wird die Umschlagverschlüsselung der Blobdaten dieser Informationen durchgeführt. Der umschlossene CEK und einige zusätzliche Verschlüsselungsmetadaten werden dann als Blobmetadaten zusammen mit dem verschlüsselten Blob gespeichert.

Wenn ein Client ein gesamtes Blob herunterlädt, wird die Umschließung des umschlossenen CEK aufgehoben und er zusammen mit dem IV verwendet, um die entschlüsselten Daten an den Client zurückzugeben.

Beim Herunterladen eines beliebigen Bereichs im verschlüsselten Blob wird der von den Benutzern angegebene Bereich angepasst, um eine kleine Menge zusätzlicher Daten abzurufen, die verwendet werden können, um den angeforderten Bereich erfolgreich zu entschlüsseln.

Alle Blobtypen (Blockblobs, Seitenblobs und Anfügeblobs) können mit diesem Schema verschlüsselt/entschlüsselt werden.

Warnung

Wenn Sie eigene Metadaten für den Blob bearbeiten oder hochladen, müssen Sie sicherstellen, dass die Verschlüsselungsmetadaten beibehalten werden. Wenn Sie neue Metadaten hochladen, ohne auch die Verschlüsselungsmetadaten beizubehalten, gehen der umschlossene CEK, IV und andere Metadaten verloren, und Sie können den Inhalt des Blobs nicht mehr abrufen. Beim Aufrufen des Vorgangs Blobmetadaten festlegen werden immer alle Blobmetadaten ersetzt.

Verwenden Sie beim Lesen aus einem verschlüsselten Blob oder beim Hineinschreiben Befehle zum Hochladen des vollständigen Blobs wie Put Blob und Befehle zum Herunterladen eines Bereichs des Blobs oder des vollständigen Blobs wie „Get Blob“. Vermeiden Sie das Schreiben in einen verschlüsselten Blob mit Protokollvorgängen wie Put Block, Put Block List, Put Page oder Append Block. Das Aufrufen dieser Vorgänge für einen verschlüsselten Blob kann diesen beschädigen und unlesbar machen.

Beispiel: Verschlüsseln und Entschlüsseln eines Blobs mit clientseitiger Verschlüsselung v2

Das Codebeispiel in diesem Abschnitt zeigt, wie Sie mit clientseitiger Verschlüsselung v2 einen Blob verschlüsseln und entschlüsseln.

Wichtig

Wenn Ihre Daten zuvor mit clientseitiger Verschlüsselung v1 verschlüsselt wurden, müssen Sie diese Daten entschlüsseln und mit clientseitiger Verschlüsselung v2 erneut verschlüsseln. Sehen Sie sich die Anleitung und das Beispiel für Ihre Clientbibliothek im Folgenden an.

Um clientseitige Verschlüsselung aus Ihrem .NET-Code zu verwenden, verweisen Sie auf die Blob Storage-Clientbibliothek. Stellen Sie sicher, dass Sie Version 12.13.0 oder höher verwenden. Wenn Sie von Version 11.x zu Version 12.13.0 migrieren müssen, finden Sie weitere Informationen im Migrationsleitfaden.

Zwei zusätzliche Pakete sind für die Integration von Azure Key Vault für clientseitige Verschlüsselung erforderlich:

  • Das Azure.Core-Paket bietet die IKeyEncryptionKey- und IKeyEncryptionKeyResolver-Schnittstelle. Die Blob Storage-Clientbibliothek für .NET definiert diese Assembly als Abhängigkeit.

  • Das Azure.Security.KeyVault.Keys-Paket (Version 4.x und höher) stellt den Key Vault-REST-Client und die kryptografischen Clients bereit, die mit clientseitiger Verschlüsselung verwendet werden. Sie müssen sicherstellen, dass in Ihrem Projekt auf dieses Paket verwiesen wird, wenn Sie Azure Key Vault als Schlüsselspeicher verwenden.

    Azure Key Vault ist für hochwertige Hauptschlüssel ausgelegt, und die Drosselungsgrenzwerte pro Schlüsseltresor spiegeln dieses Konzept wider. Ab Version 4.1.0 von Azure.Security.KeyVault.Keys unterstützt die IKeyEncryptionKeyResolver-Schnittstelle keine Zwischenspeicherung von Schlüsseln. Sollte das Zwischenspeichern aufgrund der Drosselung notwendig sein, können Sie mit dem Ansatz in diesem Beispiel eine Zwischenspeicherungsebene in eine Azure.Security.KeyVault.Keys.Cryptography.KeyResolver-Instanz einfügen.

Entwickler können einen Schlüssel, einen Schlüsselresolver oder einen Schlüssel und einen Schlüsselresolver bereitstellen. Schlüssel sind mit einer Schlüsselkennung gekennzeichnet, die die Logik für das Umschließen und Aufheben des Umschließens des CEK bereitstellt. Mit einem Schlüsselresolver wird ein Schlüssel während des Entschlüsselungsvorgangs aufgelöst. Der Schlüsselresolver definiert eine Auflösungsmethode, die bei einer angegebenen Schlüsselkennung einen Schlüssel zurückgibt. Der Resolver ermöglicht den Benutzern die Auswahl zwischen mehreren Schlüsseln, die an mehreren Speicherorten verwaltet werden.

Für die Verschlüsselung wird immer der Schlüssel verwendet. Ein fehlender Schlüssel führt zu einem Fehler.

Wenn der Schlüssel bei der Entschlüsselung angegeben wird und seine Kennung mit der geforderten Schlüsselkennung übereinstimmt, wird dieser Schlüssel zur Entschlüsselung verwendet. Andernfalls versucht die Clientbibliothek, den Resolver aufzurufen. Wenn kein Resolver angegeben ist, löst die Clientbibliothek einen Fehler aus. Wenn ein Resolver angegeben wird, wird der Schlüsselresolver aufgerufen, um den Schlüssel abzurufen. Wenn der Resolver angegeben wird, jedoch nicht über eine Zuordnung für die Schlüsselkennung verfügt, löst die Clientbibliothek einen Fehler aus.

Um die clientseitige Verschlüsselung zu verwenden, erstellen Sie ein ClientSideEncryptionOptions-Objekt und legen es bei der Clienterstellung mit SpecializedBlobClientOptions fest. Verschlüsselungsoptionen können nicht pro API festgelegt werden. Alles Weitere wird intern von der Clientbibliothek behandelt.

// Your key and key resolver instances, either through Azure Key Vault SDK or an external implementation.
IKeyEncryptionKey key;
IKeyEncryptionKeyResolver keyResolver;

// Create the encryption options to be used for upload and download.
ClientSideEncryptionOptions encryptionOptions = new ClientSideEncryptionOptions(ClientSideEncryptionVersion.V2_0)
{
   KeyEncryptionKey = key,
   KeyResolver = keyResolver,
   // String value that the client library will use when calling IKeyEncryptionKey.WrapKey()
   KeyWrapAlgorithm = "some algorithm name"
};

// Set the encryption options on the client options.
BlobClientOptions options = new SpecializedBlobClientOptions() { ClientSideEncryption = encryptionOptions };

// Create blob client with client-side encryption enabled.
// Client-side encryption options are passed from service clients to container clients, 
// and from container clients to blob clients.
// Attempting to construct a BlockBlobClient, PageBlobClient, or AppendBlobClient from a BlobContainerClient
// with client-side encryption options present will throw, as this functionality is only supported with BlobClient.
BlobClient blob = new BlobServiceClient(connectionString, options).GetBlobContainerClient("my-container").GetBlobClient("myBlob");

// Upload the encrypted contents to the blob.
blob.Upload(stream);

// Download and decrypt the encrypted contents from the blob.
MemoryStream outputStream = new MemoryStream();
blob.DownloadTo(outputStream);

Sie können Verschlüsselungsoptionen auf BlobServiceClient-, BlobContainerClient- oder BlobClient-Konstruktoren anwenden, die BlobClientOptions-Objekte akzeptieren.

Wenn ein BlobClient-Objekt bereits in Ihrem Code vorhanden ist, aber keine clientseitigen Verschlüsselungsoptionen aufweist, können Sie eine Erweiterungsmethode verwenden, um eine Kopie dieses Objekts mit den angegebenen ClientSideEncryptionOptions zu erstellen. Diese Erweiterungsmethode vermeidet den Mehraufwand, ein neues BlobClient-Objekt von Grund auf neu zu erstellen.

using Azure.Storage.Blobs.Specialized;

// An existing BlobClient instance and encryption options.
BlobClient plaintextBlob;
ClientSideEncryptionOptions encryptionOptions;

// Get a copy of the blob that uses client-side encryption.
BlobClient clientSideEncryptionBlob = plaintextBlob.WithClientSideEncryptionOptions(encryptionOptions);

Nachdem Sie den Code zur Verwendung clientseitiger Verschlüsselung v2 aktualisiert haben, stellen Sie sicher, dass Sie vorhandene verschlüsselte Daten entschlüsseln und erneut verschlüsseln, wie in Erneutes Verschlüsseln zuvor verschlüsselter Daten mit clientseitiger Verschlüsselung v2 beschrieben.

Erneutes Verschlüsseln zuvor verschlüsselter Daten mit clientseitiger Verschlüsselung v2

Alle Daten, die zuvor mit clientseitiger Verschlüsselung v1 verschlüsselt wurden, müssen entschlüsselt und dann mit clientseitiger Verschlüsselung v2 erneut verschlüsselt werden, um die Sicherheitsrisiken zu verringern. Die Entschlüsselung erfordert das Herunterladen der Daten, und die erneute Verschlüsselung erfordert erneutes Hochladen auf Blob Storage.

Ein Beispielprojekt, das zeigt, wie Daten von clientseitiger Verschlüsselung v1 zu v2 migriert werden, und wie Daten mit clientseitiger Verschlüsselung v2 in .NET verschlüsselt werden, finden Sie im Verschlüsselungsmigration-Beispielprojekt.

Clientseitige Verschlüsselung und Leistung

Beachten Sie, dass die Verschlüsselung Ihrer Speicherdaten zusätzlichen Leistungsaufwand verursacht. Wenn Sie die clientseitige Verschlüsselung in Ihrer Anwendung verwenden, muss die Clientbibliothek den CEK und IV sicher generieren, den Inhalt selbst verschlüsseln, mit Ihrem ausgewählten Keystore bezüglich der Umschlagverschlüsselung kommunizieren und zusätzliche Metadaten formatieren und hochladen. Dieser Aufwand variiert abhängig von der Menge der zu verschlüsselnden Daten. Es empfiehlt sich, dass Kunden ihre Anwendungen während der Entwicklung immer hinsichtlich der Leistung testen.

Nächste Schritte