Datenverschlüsselung in Azure Storage

Azure Storage ist das Rückgrat unzähliger Cloud-nativer Anwendungen, Data Lakes, Backup-Lösungen und Enterprise-Workloads. Mit dieser zentralen Rolle kommt eine unbestreitbare Verantwortung: Daten zu schützen, wo immer sie sich befinden. Verschlüsselung ist die Grundlage dieses Schutzes, um sicherzustellen, dass sensible Informationen vertraulich bleiben, auch wenn Angreifer Netzwerkkontrollen oder physische Sicherheit umgehen. Microsoft Azure bietet ein mehrschichtiges Verschlüsselungs-Framework, das Daten sowohl im Ruhezustand als auch auf der Durchreise abdeckt, mit Optionen, die von vollständig verwalteter, plattformgestützter Verschlüsselung bis hin zu kundengesteuerten Schlüsselhierarchien reichen.

Dieser Artikel erweitert die Kernfunktionen der Verschlüsselung in Azure Storage, einschließlich Azure Blob Storage, Azure Files, Queue Storage und Table Storage.Wir gehen durch jede Verschlüsselungsebene, wie sie konfiguriert werden soll, und die Entscheidungen, die für Compliance, Leistung und Betriebskontrolle von Bedeutung sind.

Verschlüsselung im Ruhezustand

Verschlüsselung im Ruhezustand schützt Daten, wenn sie auf physische Medien in Azure-Rechenzentren geschrieben werden. Dies umfasst alles von den von virtuellen Maschinen verwendeten Rohdatenträgerblöcken bis hin zu den Objektspeicherebenen in Blob Storage. Azure implementiert Verschlüsselung im Ruhezustand mit einer Kombination aus transparenter speicherseitiger Verschlüsselung, Verschlüsselung auf Infrastrukturebene und optionaler clientseitiger Verschlüsselung. Die Standardschicht - Azure Storage Service Encryption (SSE) - funktioniert automatisch, aber die Flexibilität, eigene Schlüssel mitzubringen oder Host-Level-Verschlüsselung zu implementieren, gibt Architekten die Kontrolle, die sie für regulatorische Umgebungen benötigen.

Azure Storage Service Encryption (SSE)

SSE ist der Standardverschlüsselungsmechanismus für alle neuen und vorhandenen Azure Storage-Konten. Er verschlüsselt Daten auf der Storage Service-Schicht, bevor er auf die Festplatte geschrieben wird, und entschlüsselt sie beim Lesen. Dieser Prozess ist für Anwendungen vollständig transparent; keine Codeänderungen, keine Konfigurationskennzeichen und keine Leistungsanpassung sind erforderlich. SSE verwendet 256-Bit Advanced Encryption Standard (AES-256), einen der stärksten verfügbaren symmetrischen Verschlüsselungsalgorithmen. Die Verschlüsselungsschlüssel werden von Microsoft verwaltet und regelmäßig intern gedreht. Da SSE standardmäßig aktiviert ist, schützt jedes Speicherkonto - einschließlich derjenigen, die über das Azure-Portal, CLI oder ARM-Vorlagen erstellt wurden - bereits Daten im Ruhezustand, es sei denn, dies ist für neue Konten nicht möglich.

SSE umfasst alle Azure Storage-Dienste: Blob Storage (Block Blobs, Append Blobs und Page Blobs), Azure Files (einschließlich File Shares), Queue Storage und Table Storage. Für Azure Managed Disks, die den Speicher virtueller Maschinen unterstützen, wird die Verschlüsselung separat von Azure Disk Encryption oder serverseitiger Verschlüsselung (SSE + Platform-Managed Keys) gehandhabt. Der kritische Takeaway: SSE ist ein Sicherheitsnetz ohne Konfiguration, das eine grundlegende Verschlüsselung in Ruhe über die gesamte Storage Service-Familie gewährleistet.

Infrastrukturverschlüsselung

Über SSE hinaus bietet Azure Storage infrastructure encryption an, die eine zweite Verschlüsselungsebene auf der Speicherinfrastrukturebene hinzufügt. Während SSE Daten auf den physischen Festplatten schützt, verschlüsselt die Infrastrukturverschlüsselung Daten erneut, bevor sie in das interne Netzwerk und die Caching-Schichten des Speicherclusters geschrieben werden. Dies ist besonders relevant für Kunden, die strengen Compliance-Regelungen unterliegen, die eine doppelte Verschlüsselung auf allen Speichermedien erfordern.

Infrastrukturverschlüsselung ist auf der Ebene des Speicherkontos aktiviert und verwendet plattformverwaltete Schlüssel. Es erfordert keine Änderungen an Anwendungen oder Clientcode. Der Kompromiss ist ein kleiner Schreibdurchsatz-Overhead (normalerweise für die meisten Workloads vernachlässigbar) und kann nach der Aktivierung nicht deaktiviert werden. Ihre Organisation sollte bewerten, ob eine zweite Verschlüsselungsschicht basierend auf internen Richtlinien, regulatorischen Richtlinien oder vertraglichen Anforderungen erforderlich ist.

Kundengeführte Schlüssel (CMK)

Für Organisationen, die ihre eigenen Verschlüsselungsschlüssel kontrollieren müssen – entweder um Compliance-Mandate zu erfüllen, Schlüsselrotationspläne zu implementieren oder mit vorhandenen Schlüsselverwaltungssystemen zu integrieren – unterstützt Azuré Storage Customer-Managed Keys (CMK), die in Azure Key Vault gespeichert sind. Wenn CMK aktiviert ist, wird der Root-Schlüssel, der zum Einwickeln der Datenverschlüsselungsschlüssel verwendet wird, in Ihrer eigenen Key Vault-Instanz gespeichert. Das bedeutet, dass Microsoft die Daten nicht ohne Zugriff auf Ihren Schlüssel entschlüsseln kann und Sie können den Zugriff jederzeit durch Deaktivieren oder Löschen des Schlüssels widerrufen.

CMK arbeitet auf SSE. Der Speicherdienst verschlüsselt weiterhin Daten mit AES-256, aber der Schlüsselverschlüsselungsschlüssel (KEK), der die Datenverschlüsselungsschlüssel (DEKs) schützt, wird von Ihnen verwaltet. Sie können zwischen einem Key Vault-verwalteten Schlüssel (softwaregeschützt oder HSM-gestützt) oder einem Key Vault Managed HSM-Schlüssel für die Einhaltung von FIPS 140-2 Level 3 wählen. Schlüsselrotation kann manuell oder automatisiert mithilfe der Schlüsselrotationsrichtlinie von Key Vault erfolgen.

Wichtige Überlegungen für CMK:

  • Wenn Sie den Schlüssel in Key Vault deaktivieren oder löschen, kann Azure Storage nicht auf die Daten zugreifen, was das Speicherkonto effektiv unzugänglich macht und zu dauerhaftem Datenverlust führen kann, wenn es nicht sorgfältig verwaltet wird.
  • CMK ist für Blob Storage, Azure Files, Queue Storage, Table Storage und Azure Data Lake Storage Gen2 verfügbar.
  • CMK unterstützt Azure Managed Disks nicht direkt; in diesem Szenario wird eine serverseitige Verschlüsselung mit kundenverwalteten Schlüsseln (SSE + CMK) verwendet.
  • Die Überwachung von Schlüsseloperationen über Key Vault-Auditprotokolle und Azure Monitor ist unerlässlich, um unbefugte Zugriffsversuche oder den Ablauf von Schlüsseln zu erkennen.

Kunden bereitgestellte Schlüssel (CPK)

Für Blob Storage gibt es eine dritte Schlüsseloption namens Customer-Provided Keys (CPK). CPK ermöglicht es einem Client, einen Verschlüsselungsschlüssel zum Zeitpunkt jeder Anforderung bereitzustellen, anstatt den Schlüssel in Key Vault zu speichern. Der Schlüssel wird für diesen einzelnen Lese- oder Schreibvorgang verwendet und wird von Azure nicht beibehalten. Dies ist nützlich für Szenarien, in denen Sie die Schlüsselverwaltung vollständig auf Plattformebene vermeiden möchten, beispielsweise bei der Verarbeitung hochsensibler Daten, die einen Schlüssel-Tresor nicht mit anderen Workloads teilen können. CPK wird sowohl für Block-Blobs als auch für Seiten-Blobs unterstützt und funktioniert mit Azure PowerShell, .NET SDK, Java SDK und REST API-Aufrufen.

Verschlüsselung im Transit

Verschlüsselungs-Intransit sichert Daten, wenn sie sich über Netzwerke hinweg bewegen, schützt sie vor Abhören, Man-in-the-Middle-Angriffen und Abhören. Azure Storage bietet mehrere Mechanismen – von der obligatorischen HTTPS-Durchsetzung bis hin zur SMB-Verschlüsselung für Dateifreigaben – um sicherzustellen, dass Daten niemals im Klartext übertragen werden.

HTTPS-Durchsetzung

Alle Azure Storage-Endpunkte unterstützen HTTPS (HTTP over TLS 1.2 oder höher). Standardmäßig werden sowohl HTTP als auch HTTPS akzeptiert, aber Best Practice ist es, auf der Speicherkontoebene eine sichere Übertragung zu erzwingen. Diese Einstellung lehnt jede über HTTP gestellte Anforderung ab und blockiert Verbindungen von falsch konfigurierten Clients oder Legacy-Anwendungen, die TLS nicht unterstützen. Die Aktivierung einer sicheren Übertragung ist eine Änderung mit einem Klick im Azure-Portal oder kann über Azure Policy so eingestellt werden, dass sie über alle Abonnements erzwungen wird.

Beim Erstellen von Anwendungen, die Azure Storage verbrauchen, verwenden Sie immer das URI-Schema in Verbindungszeichenfolgen. Stellen Sie für die Entwicklung und das Testen sicher, dass keine HTTP-Endpunkte in Produktionspipelines verwendet werden. Die Azure SDKs setzen HTTPS standardmäßig durch, wenn Verbindungszeichenfolgen verwendet werden, die das Standard-Endpunktsuffix enthalten.

TLS Versionsanforderungen

Azure Storage unterstützt TLS 1.0, 1.1 und 1.2 von der Clientseite. Microsoft empfiehlt jedoch dringend, TLS 1.0 und 1.1 zu deaktivieren, um moderne Sicherheitsstandards zu erfüllen. Beginnend mit der Azure Storage REST API Version 2021-06-08 können Sie eine minimale TLS Version Anforderung auf der Speicherkontoebene festlegen. Dies wird serverseitig durchgesetzt: Jeder Client, der versucht, eine Verbindung mit einer älteren TLS Version herzustellen, erhält eine 403 Forbidden Antwort.

So konfigurieren Sie die minimale TLS-Version:

  • Gehen Sie zum Speicherkonto im Azure-Portal.
  • Wählen Sie Konfiguration unter dem Abschnitt Sicherheit + Netzwerk.
  • Stellen Sie die Minimum TLS Version auf 1.2.

Diese Einstellung gilt für alle Endpunkte, einschließlich Blob-, Datei-, Warteschlangen- und Tabellenspeicher.Audit für alle älteren Anwendungen, die möglicherweise auf TLS 1.0 oder 1.1 angewiesen sind, bevor Sie das Upgrade durchsetzen.

SMB Encryption für Azure-Dateien

Azure Files verwendet das Server Message Block (SMB) Protokoll für den Dateifreigabezugriff. SMB 3.0 und höher enthalten eine integrierte Verschlüsselung, die den Datentransfer zwischen dem Client und der Dateifreigabe schützt. Wenn Sie von einem unterstützten Client auf eine Azure-Dateifreigabe zugreifen (Windows 8/Server 2012 oder höher, Linux mit CIFS-Kernel-Client 4.0+), wird die Verbindung automatisch über das Netzwerk verschlüsselt. Azure Files erfordert SMB 3.0 oder höher mit Verschlüsselung für alle externen Verbindungen; frühere SMB-Versionen sind blockiert.

Für lokale Clients, die sich über VPN oder ExpressRoute verbinden, stellt die SMB-Verschlüsselung sicher, dass Daten, die das öffentliche Internet durchqueren (falls zutreffend), vertraulich bleiben. In internen Azure-Netzwerken wird die Verschlüsselung weiterhin empfohlen, um vor möglichen Angriffen auf laterale Bewegungen innerhalb des Rechenzentrums zu schützen.

Private Endpoints und Service Endpoints

Während die Verschlüsselung den Datentransfer schützt, reduzieren die Kontrollen auf Netzwerkebene die Exposition weiter. Azure Private Endpoints weisen dem Speicherkonto aus Ihrem virtuellen Netzwerk eine private IP-Adresse zu, wodurch der Speicherdienst effektiv in Ihr VNet gebracht wird. Der Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Speicherkonto reist über das Microsoft-Backbone-Netzwerk, nicht über das öffentliche Internet. Selbst bei privaten Endpunkten bleibt die HTTPS-Verschlüsselung aktiv und bietet eine umfassende Verteidigung.

Service-Endpunkte bieten einen ähnlichen Vorteil auf Subnetzebene, aber ohne private IP. Beide Optionen integrieren sich nahtlos in SSE- und Verschlüsselungs-in-Transit-Einstellungen.

Key Management und Rotation

Selbst wenn SSE plattformverwaltete Schlüssel verwendet, behält Ihr Unternehmen das Eigentum an den Daten und die rechtliche Verantwortung für ihren Schutz. Schlüssel sollten regelmäßig gedreht werden, um die Auswirkungen eines potenziellen Schlüsselkompromisses zu begrenzen oder Compliance-Anforderungen wie PCI DSS, HIPAA oder SOC 2 zu erfüllen.

Bei Speicherkonten mit CMK wird die Rotation über Azure Key Vault verwaltet. Sie können die automatische Rotation konfigurieren, indem Sie beispielsweise alle 90 Tage eine Rotationsrichtlinie für den Schlüssel festlegen. Azure Storage nimmt die neue Schlüsselversion auf und verschlüsselt die Datenverschlüsselungsschlüssel mit dem neuesten Schlüssel neu. Es sind keine Ausfallzeiten oder manuelle Eingriffe erforderlich. Bei plattformverwalteten Schlüsseln (Standard-SSE) dreht Microsoft die Schlüssel intern ohne Kundensichtbarkeit.

Die Überprüfung der Schlüsselnutzung ist mit Key Vault Diagnoseprotokollen unkompliziert. Exportieren Sie Protokolle in einen Log Analytics-Arbeitsbereich oder Azure Storage und richten Sie Benachrichtigungen für Operationen wie , oder ein. Jedes unerwartete Schlüsselzugriffsmuster könnte auf eine versuchte unautorisierte Entschlüsselung hinweisen.

Bring Your Own Key (BYOK) mit HSM

Für Unternehmen in stark regulierten Branchen bietet Azure Key Vault Managed HSM ein FIPS 140-2 Level 3 validiertes Hardware-Sicherheitsmodul (HSM) zum Speichern von Verschlüsselungsschlüsseln. Sie können den Schlüssel lokal generieren und sicher mit einem Prozess namens Bring Your Own Key (BYOK)) an das HSM übertragen. Dies stellt sicher, dass Microsoft niemals Zugriff auf das Rohschlüsselmaterial hat. BYOK wird sowohl für CMK- als auch für CPK-Szenarien unterstützt.

Compliance und regulatorische Ausrichtung

Die Verschlüsselung in Azure Storage bildet die Compliance-Anforderungen in wichtigen Frameworks direkt ab. SSE erfüllt die Verschlüsselungs-at-rest-Mandate in ISO 27001, SOC 2 und FedRAMP Moderate. Die Verschlüsselung der Infrastruktur entspricht den Anforderungen für die Dual-Layer-Verschlüsselung, die in spezifischen Bundesnormen zu sehen sind. CMK bietet die Schlüsseltrennung, die für CJIS-Daten (Criminal Justice Information Services) und IRS 1075 erforderlich ist, wobei der CSP keinen unabhängigen Zugriff auf Entschlüsselungsschlüssel haben darf.

Es liegt in Ihrer Verantwortung, zu überprüfen, ob Ihre gewählte Verschlüsselungskonfiguration die spezifischen Kontrollen in Ihrem Compliance-Bereich erfüllt. Azure stellt Compliance-Dokumentation und Auditberichte über die Microsoft Compliance Offerings Seite bereit. Verwenden Sie Azure Policy, um Verschlüsselungseinstellungen in Ihrem Unternehmen durchzusetzen, wie z. B. die Anforderung von CMK für alle Speicherkonten, die Produktionsdaten enthalten, oder die Anforderung einer TLS-Mindestversion von 1.2.

Leistungsbetrachtungen

Die Verschlüsselung in Azure Storage führt zu minimalem Overhead. SSE arbeitet auf der Ebene des Speicherknotens und ist für den Durchsatz optimiert. In den meisten Benchmarks liegen die CPU-Kosten der AES-256-Verschlüsselung weit unter der Latenz des Netzwerk-I/O. Die Infrastruktur-Verschlüsselung fügt geringe Schreibverstärkungskosten hinzu, aber für typische Workloads (GPv2-Speicherkonten, Allzweck-Block-Blobs) liegt der Einfluss bei sequenziellen Workloads deutlich unter 5%. Für zufällige I/O- oder Workloads mit sehr kleinen Objekten (unter 4 KB) kann der Overhead etwas höher sein, aber immer noch akzeptabel für den Produktionsgebrauch.

CMK fügt Netzwerklatenz für Schlüsselentpackungsoperationen hinzu, da der Speicherdienst Key Vault aufrufen muss, um den DEK auf jedem Mount oder Fetch zu entschlüsseln. Diese Latenz liegt typischerweise unter 10 ms pro Anruf, und das Ergebnis wird zwischengespeichert, so dass nachfolgende Anfragen innerhalb derselben Sitzung nicht den Overhead verursachen. Für die meisten Anwendungen ist dies nicht wahrnehmbar.

Zusammenfassung der Best Practices

Die Implementierung von Verschlüsselung in Azure Storage erfordert Planung, aber keine Komplexität.

  • SSE ist aktiviert. Es ist standardmäßig aktiviert, aber auditiere vorhandene Konten, die mit älteren Azure Storage API-Versionen oder Verwaltungstools erstellt wurden, um sicherzustellen, dass kein Konto die Verschlüsselung deaktiviert hat.
  • Aktivieren Sie die sichere Übertragung auf jedem Speicherkonto, um eine HTTPS-basierte Kommunikation zu gewährleisten.
  • Setzen Sie die minimale TLS-Version auf 1.2 über alle Produktionsspeicherkonten hinweg.
  • Verwenden Sie kundengeführte Schlüssel für Workloads, die Compliance-Anforderungen unterliegen, die eine Schlüsselkontrolle oder Aufgabentrennung vorschreiben.
  • Implementieren Sie die Infrastrukturverschlüsselung, wenn Ihr Compliance-Framework ausdrücklich eine Dual-Layer-Verschlüsselung erfordert.
  • Rotate Keys regular-automatisieren die Rotation mit Key Vault-Richtlinien, um manuelle Fehler zu vermeiden.
  • Überwachen Sie Verschlüsselungsvorgänge über Azure Monitor und Key Vault Diagnose. Legen Sie Benachrichtigungen für Schlüssellöschungen, Deaktivierung oder versuchte Zugriffsfehler fest.
  • Verwenden Sie Azure Policy, um Verschlüsselungsanforderungen durchzusetzen, wie z. B. die Anforderung von CMK für bestimmte Ressourcengruppen oder das Blockieren des HTTP-Zugriffs.
  • Betrachten Sie die clientseitige Verschlüsselung für ultrasensible Daten, die verschlüsselt werden müssen, bevor sie Azure Storage erreichen. Die Azure Storage-Clientbibliotheken unterstützen dies, erhöhen jedoch die Komplexität und sollten für außergewöhnliche Szenarien reserviert werden.
  • Testen Sie Ihren Disaster Recovery Plan mit CMK-Schlüsseln. Wenn sich Ihr Key Vault in einer anderen Region befindet und fehlschlägt, kann auf Ihr Speicherkonto weiterhin zugegriffen werden? Verwenden Sie eine Multi-Region-Schlüsselreplikation oder einen Backup-Schlüssel-Vault.

Durch die Schichtung von Verschlüsselung im Ruhezustand, Verschlüsselungsintransit und starkem Schlüsselmanagement können Sie eine Sicherheitsposition erreichen, die den Anforderungen moderner Unternehmens-Compliance entspricht, ohne die Leistung oder die betriebliche Einfachheit zu beeinträchtigen. Weitere Details finden Sie in der Dokumentation zum Azure Storage Service Encryption und dem Secure Transfer Guide auf Microsoft Learn.