Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Clients, die Anfragen an den Azure Blob-Speicher senden, können einen AES-256-Verschlüsselungsschlüssel bereitstellen, um diesen Blob bei einem Schreibvorgang zu verschlüsseln. Nachfolgende Anfragen zum Lesen oder Schreiben in das Blob müssen denselben Schlüssel enthalten. Die Einbeziehung des Verschlüsselungsschlüssels in die Anfrage ermöglicht eine präzise Steuerung der Verschlüsselungseinstellungen für Blob-Speichervorgänge. Vom Kunden bereitgestellte Schlüssel können in Azure Key Vault oder einem anderen Schlüsselspeicher gespeichert werden.
Verschlüsseln von Lese-und Schreibvorgängen
Wenn eine Clientanwendung mit der Anforderung einen Verschlüsselungsschlüssel bereitstellt, führt Azure Storage die Verschlüsselung und Entschlüsselung beim Lesen und Schreiben von Blobdaten transparent aus. In Azure Storage wird neben den Inhalten des Blobs ein SHA-256-Hash des Verschlüsselungsschlüssels geschrieben. Der Hash wird verwendet, um zu überprüfen, ob alle nachfolgenden Vorgänge für das Blob denselben Verschlüsselungsschlüssel verwenden.
Azure Storage speichert oder verwaltet nicht den Verschlüsselungsschlüssel, den der Client mit der Anforderung sendet. Nach Abschluss des Verschlüsselungs- oder Entschlüsselungsprozesses wird der Schlüssel sicher verworfen.
Wenn ein Client ein Blob erstellt oder aktualisiert und dazu für die Anforderung einen kundenseitig bereitgestellten Schlüssel verwendet, müssen nachfolgende Lese- und Schreibanforderungen für dieses Blob den Schlüssel ebenfalls bereitstellen. Wenn der Schlüssel bei einer Anforderung für ein Blob, das mit einem vom Kunden bereitgestellten Schlüssel bereits verschlüsselt wurde, nicht bereitgestellt wird, schlägt die Anforderung mit dem Fehlercode 409 (Konflikt) fehl.
Wenn die Clientanwendung bei der Anforderung einen Verschlüsselungsschlüssel sendet und das Speicherkonto mit einem von Microsoft oder vom Kunden verwalteten Schlüssel ebenfalls verschlüsselt wurde, verwendet Azure Storage den bei der Anforderung bereitgestellten Schlüssel zur Verschlüsselung und Entschlüsselung.
Zum Senden des Verschlüsselungsschlüssels als Teil der Anforderung muss ein Client über HTTPS eine sichere Verbindung zu Azure Storage herstellen.
Jede Blobmomentaufnahme oder Blobversion kann einen eigenen Verschlüsselungsschlüssel haben.
Die Objektreplikation wird für Blobs im Quellkonto, die mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt sind, nicht unterstützt.
Anforderungsheader zur Angabe von vom Kunden bereitgestellten Schlüsseln
Für REST-Aufrufe können Clients mithilfe der folgenden Header Informationen zum Verschlüsselungsschlüssel bei einer Anforderung an den Blobspeicher sicher übergeben:
| Request-Header | BESCHREIBUNG |
|---|---|
x-ms-encryption-key |
Sowohl für Schreib- als auch für Leseanforderungen erforderlich. Ein Base64-codierter AES-256-Verschlüsselungsschlüsselwert. |
x-ms-encryption-key-sha256 |
Erforderlich sowohl bei Schreib- als auch bei Leseanforderungen. Der Base64-kodierte SHA-256-Hash des Verschlüsselungsschlüssels. |
x-ms-encryption-algorithm |
Erforderlich bei Schreibanforderungen, optional bei Leseanforderungen. Gibt den Algorithmus an, der beim Verschlüsseln von Daten mit dem angegebenen Schlüssel verwendet werden soll. Der Wert dieses Headers muss auf AES256 festgelegt sein. |
Die Angabe von Verschlüsselungsschlüsseln bei der Anforderung ist optional. Wenn Sie aber einen der oben aufgeführten Header für einen Schreibvorgang angeben, müssen Sie alle Header angeben.
Wenn Sie ein Benutzerdelegations-SAS verwenden und das signedVersion (sv) auf 2026-04-06 oder später gesetzt ist, können Sie die Abfrageparameter srh und srq verwenden, um spezifische Header und Abfrageparameter für jede Anforderung mit der SAS zu verlangen, wobei Azure Storage deren Werte anhand kanonisierter Zeichenfolgen im String-to-Sign validiert. Weitere Informationen finden Sie unter Erstellen einer SAS für die Benutzerdelegierung.
Blob-Speichervorgänge, die vom Kunden bereitgestellte Schlüssel unterstützen
Die folgenden Blob-Speichervorgänge unterstützen das Senden von vom Kunden bereitgestellten Verschlüsselungsschlüsseln bei einer Anforderung:
- Blob einfügen
- Blockliste setzen
- Block setzen
- Block aus URL einfügen
- Seite platzieren
- Seite aus URL einfügen
- Block anhängen
- Festlegen von Blob-Metadaten
- Blob abrufen
- Blob-Eigenschaften abrufen
- Abrufen von BLOB-Metadaten
- Snapshotblob
Vom Kunden bereitgestellte kryptografische Schlüssel rotieren
Um einen Verschlüsselungsschlüssel, der zur Verschlüsselung eines Blobs verwendet wurde, zu rotieren, laden Sie das Blob herunter und laden Sie es dann mit dem neuen Verschlüsselungsschlüssel erneut hoch.
Wichtig
Das Azure-Portal kann nicht zum Lesen aus oder Schreiben in einen Container oder ein Blob verwendet werden, der bzw. das mit einem Schlüssel verschlüsselt wird, der mit der Anforderung bereitgestellt wird.
Schützen Sie unbedingt den Verschlüsselungsschlüssel, den Sie bei einer Anforderung an Blob Storage bereitstellen, in einem sicheren Schlüsselspeicher wie Azure Key Vault. Wenn Sie versuchen, einen Schreibvorgang für einen Container oder ein Blob ohne den Verschlüsselungsschlüssel auszuführen, schlägt der Vorgang fehl, und Sie verlieren Ihren Zugriff auf das Objekt.
Unterstützte Funktionen
Die Unterstützung für dieses Features kann durch die Aktivierung von Data Lake Storage Gen2, dem Network File System (NFS) 3.0-Protokoll oder dem SSH File Transfer Protocol (SFTP) beeinträchtigt werden. Wenn Sie eine dieser Funktionen aktiviert haben, siehe Unterstützung von Blob Storage-Features in Azure Storage-Konten, um die Unterstützung für dieses Feature zu bewerten.