Verschlüsselung at Rest in Azure (Teil 1)

Speicherst du Daten in Azure, werden diese automatisch verschlüsselt. Das gilt für jeden Dienst, der in irgendeiner Weise Daten speichert, nicht nur für obligatorische Speicherkonten, auch für andere Speicherdienste wie Backup-Tresore, Schlüssel-Tresore, Datenbanken und vor allem für die Datenträger virtueller Maschinen (Managed Disks). Du kannst die Verschlüsslung noch verbessern, z. B. durch Verwenden eigener Schlüssel oder der Azure Disk Encryption. In diesem und zwei weiteren Teilen zeigen wir, wie du deine Verschlüsslungsstrategie optimierst.

Der erste Teil befasst sich mit der Verschlüsselung für Speicherkonten. Der zweite Teil kümmert sich um die Festplatten deiner virtuellen Maschinen. Das umfasst wiederrum, verwaltete Datenträger, die Azure Disk Encryption (ADE) und die Verschlüsselung auf dem Host. Teil drei widmet sich dann der Verschlüsslung im Kontext von SQL-Datenbanken, also Transparent „Data Encryption“ und „Always Encrypted“.
In allen drei Beiträgen werden wir uns soweit erforderlich auch mit Azure-Schlüsseltresoren (Key Vault) befassen. Alle Themen werden vor allem im Azure-Kurs AZ 500, „Azure-Security-Engineer“ benötigt und behandelt.

TLS Verschlüsselung in Azure

Die Verschlüsselung in der Übertragung (SSL / TLS) hingegen ist bei nahezu jedem Azure-Dienst obligatorisch und lässt sich nur in spezifischen Sonderfällen wie z. B. beim Zugriff auf Azure-Dateifreigaben via SMB (nicht REST) aus Kompatibilitätsgründen abschalten. Microsoft stellt dir als Kunde demnach die Möglichkeit zur Verfügung, das Transport Layer Security-Protokoll (TLS) zum Schutz von Daten bei der Übertragung zwischen deinem Standort und den Clouddiensten zu nutzen.

Die Microsoft-Rechenzentren verhandeln jeweils eine TLS-Verbindung mit Clientsystemen, die eine Verbindung mit Azure-Diensten herstellen. TLS bietet strenge Authentifizierung, Datenschutz von Nachrichten und Integrität (ermöglicht die Erkennung von Manipulation, Abfangen und Fälschung von Nachrichten), Interoperabilität, Algorithmus Flexibilität sowie einfache Bereitstellung und Verwendung. Die Verbindungen verwenden zudem RSA-basierte Verschlüsselungsschlüssellängen von 2.048 Bit. Diese Kombination erschwert das Abfangen von Daten während der Übertragung und den Zugriff darauf. Nun aber zur Verschlüsslung at Rest.

Verschlüsselung ruhender Daten

Unter ruhenden Daten versteht man in der IT jegliche Art von Informationen, die in einem beliebigen digitalen Format im dauerhaften Speicher auf physischen Medien gespeichert werden. Das sind etwa Dateien auf Magnet- oder optischen Datenträgern, archivierte Daten oder Datensicherungen. Azure stellt bekanntlich eine ganze Reihe von Datenspeicherlösungen für verschiedene Anforderungen zur Verfügung. Im Kontext eines Speicherkontos sind das z. B.  Datei-, Block-, Nachrichten-, Blob- und Tabellenspeicher. Darüber hinaus stellt Microsoft Verschlüsselungstechnologien zum Schutz von Azure SQL-Datenbank, Azure Cosmos DB und Azure Data Lake zur Verfügung. Diese Verschlüsselung ruhender Daten ist übrigens in allen Cloud-Modellen, also Software-as-a-Service- (SaaS), Platform-as-a-Service- (PaaS) und Infrastructure-as-a-Service-Cloudmodellen (IaaS) verfügbar. Dabei unterstützt Azure verschiedene Verschlüsselungsmodelle, darunter …

1. Clientseitige Verschlüsselung, bei der du Schlüssel lokal oder an einem anderen sicheren Speicherort verwaltest und speicherst.
2. Serverseitige Verschlüsselung unter Verwendung dienstverwalteter Schlüssel (MMK=Microsoft Managend Keys, bzw. PMK=Platform Managed Keys). Dienstverwaltete Schlüssel bieten dir eine gute Kombination aus Kontrolle und Benutzerfreundlichkeit.
3. Serverseitige Verschlüsselung unter Verwendung dienstverwalteter Schlüssel auf vom Kunden gesteuerter Hardware: dieses Verfahren erlaubt es dir Schlüssel in deinem eigenen proprietären Repository zu verwalten, welches sich außerhalb des Einflussbereichs von Microsoft befindet. Das Verfahren wird auch als „Host Your Own Key“ (HYOK) bezeichnet. Die Konfiguration ist jedoch komplex, und die meisten Azure-Dienste unterstützen dieses Modell nicht.
4. Serverseitige Verschlüsselung unter Verwendung kundenverwalteter Schlüssel, die entweder in Azure Key Vault oder einem Azure Managed HSM gespeichert sind, bietet dir die volle Kontrolle über die Schlüssel, einschließlich der Möglichkeit, die Funktion „Bring your Own Key“ (BYOK) zu verwenden oder neue Schlüssel zu generieren.

Die Ausführungen in diesem und im Folgebeitrag drehen sich vorrangig um den Punkt 4, denn Punkt 1 liegt außerhalb der Verantwortung von Azure, Punkt 2 ist trivial, bzw. stellt die Default-Einstellungen bei den meisten Speicherdiensten dar und Punkt 3 ist sehr komplex und kostspielig. Hinzu kommen noch die Azure Disk Encryption (ADE) oder die Verschlüsslung auf dem Host.

Serverseitige Verschlüsslung in Azure bei Speicherkonten

Stellst du ein eigenes Speicherkonto in Azure bereit, kannst du schon bei der Bereitstellung die serverseitige Verschlüsslung konfigurieren. Wie schon erwähnt, kannst du die serverseitige Verschlüsslung zwar nicht umgehen oder abschalten, dich aber zwischen „von Microsoft verwaltete Schlüssel (MMK)“ und „kundenseitig verwaltete Schlüssel (CMK)“ entscheiden. Außerdem kannst du wählen, ob die Verschlüsslung nur für Blobs und Files oder für alle Diensttypen in einem Speicherkonto gilt. Microsoft weist auch darauf hin, dass du beim Verwenden kundenseitig verwalteter Schlüssel zunächst weitere Ressourcen in Azure erstellen musst, nämlich einen Schlüsseltresor und eine benutzerseitig zugewiesene Identität für das Speicherkonto. Diese muss die Berechtigungen „Abrufen“, „Schlüssel packen“ und „Schlüssel entpacken“ für den Schlüsseltresor besitzen. Ferner hast du im Abschnitt „Verschlüsselungsschlüssel“ die Möglichkeit, zwischen „Bring your own key“ (Schlüsseltresor und Schlüssel auswählen) und „Host your own key“ (Schlüssel aus URI angeben) zu wählen. Wir nehmen für die folgende Demonstration ersteres, d. h. du musst über einen Schlüsseltresor in Azure verfügen. Übrigens differenziert Microsoft hier noch einmal bei „Schlüsselspeichertyp“ zwischen „Schlüsseltresor“ (Software Defined) und „Verwaltetes HSM“ (Hardware-Tresor).

Hast du zu diesem Zeitpunkt noch keinen Key Vault, und keine Identität für dein Speicherkonto, erstelle zunächst nur dein Speicherkonto (ohne kundenseitige Verschlüsselung). Danach navigierst du in deinem Speicherkonto im Menüabschnitt „Sicherheit + Netzwerkbetrieb“ und klickst auf „Verschlüsselung“. Hier aktivierst du den „Verschlüsselungstyp“ „Kundenseitig verwaltete Schlüssel“, klickst bei „Schlüsseltresor und Schlüssel“ auf „Schlüsseltresor und Schlüssel auswählen“, wählst dort die Option „Schlüsseltresor“ und wählst dann „Schlüsseltresor neu erstellen“:

Du wirst dann zum Dialog umgeleitet zum Erstellen eines Schlüsseltresors. Dieser bekommt einen Namen, eine Region, einen Tarif (wie nehmen „Standard“) und eine Einstellung für den Löschschutz.

Navigiere mit „Weiter“ zum Tab „Zugriffskonfiguration“ und wähle bei „Berechtigungsmodell“ den Eintrag „Tresorzugriffsrichtlinie“ (statt „RBAC).

Außerdem musst du hier einen Schlüssel auswählen. Da du noch keinen hast, kannst du hier auf „Neu erstellen“ klicken. Hierbei handelt es sich um einen RSA-Key. Wähle hier neben dem gewünschten Namen die Schlüssellänge 2048 Bit und setze den Haken bei „Aktiviert“.

Für die eigentliche operative Verschlüsselung at Rest setzt Microsoft auf einen asymetrischen 256-Bit-AES-Key. Der RSA-Key hingegen verschlüsselt lediglich den Datenverschlüsselungsschlüssel. Schließlich musst du noch einen „Identitätstyp“ auswählen. Da du das Speicherkonto vorab mit serverseitiger Verschlüsselung erstellt und erst jetzt nachträglich die serverseitige Verschlüsselung mit kundenseitig verwalteten Schlüsseln konfigurierst, kannst du bei „Identitätstyp“ zwischen „Systemseitig zugewiesen“ und „Benutzerseitig zugewiesen“ wählen.  

Würdest du hingegen versuchen, den Key Vault direkt bei der Speicherkontoerstellung zu generieren, kämst du über diesen Punkt nicht hinweg, weil dann nur die „Benutzerseitig zugewiesene Identität“ zur Verfügung stünde und diese müsste der Warnung oben zu entnehmen vorher existieren. Die „Systemseitig zugewiesene Identität“ hingegen, kann an dieser Stelle automatisch generiert werden. Sie wird benötigt, um dem Speicherkonto im Key Vault eine Zugriffsrichtlinie passend zum Einsatzzweck zuweisen zu können, was in diesem Fall ebenfalls automatisch passiert. Klicke auf Speichern, um die Konfiguration abzuschließen. Deine Blobs und Files in deinem Speicherkonto sind nun serverseitig at Rest verschlüsselt, allerdings mit einem Schlüssel, dem du in deinem Key Vault selbst generiert hast und der vom Speicherkonto über dessen Identität abgerufen werden kann. Du kannst nun überprüfen, ob in deinem Key Vault unter „Zugriffsrichtlinien“ automatisch eine passende erzeugt wurde mit der Identität deines Speicherkontos als SPN.