Clientseitige Verschlüsselung für Warteschlangen

  • Artikel

Die Azure Queue Storage-Clientbibliotheken für .NET 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 Clientbibliotheken unterstützen zudem die Integration in Azure Key Vault zur Schlüsselverwaltung für Speicherkonten.

Wichtig

Azure Storage unterstützt sowohl die dienstseitige als auch die 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.

Informationen zur clientseitigen Verschlüsselung

Die Azure Queue 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 Queue 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.

Aktualisieren Sie Ihren Code, sodass er die clientseitige Verschlüsselung v2 verwendet.
Die Anwendung verwendet die clientseitige Verschlüsselung mit einer Version der Clientbibliothek, die die clientseitige Verschlüsselung v2 unterstützt. Aktualisieren Sie Ihren Code, sodass er die clientseitige Verschlüsselung v2 verwendet.

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 und Python welche Versionen der clientseitigen Verschlüsselung unterstützen:

.NET Python
Clientseitige Verschlüsselung v2 und v1 Version 12.11.0 und höher Version 12.4.0 und höher
Nur clientseitige Verschlüsselung v1 Version 12.10.0 und früher Version 12.3.0 und früher

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

Funktionsweise der clientseitigen Verschlüsselung

Die Azure Queue 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 Queue Storage-Clientbibliotheken nutzen 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 Queue Storage hochgeladen. Der umschlossene Schlüssel wird zusammen mit einigen zusätzlichen Verschlüsselungsmetadaten mit den verschlüsselten Daten interpoliert.

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 von Nachrichten

Da Warteschlangenmeldungen ein beliebiges Format aufweisen können, definiert die Clientbibliothek ein benutzerdefiniertes Format, das den Initialisierungsvektor (IV) und den verschlüsselten Inhaltsverschlüsselungsschlüssel (CEK) im Meldungstext enthält.

Bei der Verschlüsselung generiert die Clientbibliothek einen zufälligen 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 des Texts der Warteschlangenmeldung durchgeführt. Der umschlossene CEK und einige zusätzliche Verschlüsselungsmetadaten werden der verschlüsselten Warteschlangenmeldung dann hinzugefügt. Diese geänderte Meldung (siehe unten) wird für den Dienst gespeichert.

<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>

Bei der Entschlüsselung wird der umschlossene Schlüssel aus der Warteschlangenmeldung extrahiert und entpackt. Der Initialisierungsvektor wird ebenfalls aus der Warteschlangenmeldung extrahiert und zusammen mit dem entpackten Schlüssel verwendet, um die Daten der Warteschlangenmeldung zu entschlüsseln. Verschlüsselungsmetadaten weisen eine geringe Größe auf (weniger als 500 Byte). Sie werden zwar auf die 64-KB-Begrenzung für Warteschlangenmeldungen angerechnet, die Auswirkungen sollten jedoch vertretbar sein. Die verschlüsselte Nachricht ist Base64-codiert, wie im obigen Schnipsel gezeigt, wodurch sich auch die gesendete Nachricht vergrößert.

Aufgrund der Kurzlebigkeit von Nachrichten in der Warteschlange sollte eine Entschlüsselung und erneute Verschlüsselung von Warteschlangennachrichten nach der Aktualisierung auf die clientseitige Verschlüsselung v2 nicht notwendig sein. Weniger sichere Nachrichten werden im Rahmen der normalen Warteschlangennutzung rotiert.

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