Verschlüsselung at Rest in Azure SQL (Teil 3)

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, für die Datenträger virtuellen Maschinen (Managed Disks) und auch für Datenbanken. Du kannst aber die Verschlüsslung in Azure noch verbessern, z. B. durch Verwenden von Transparent Data Encryption oder Always Encrypted bei Azure SQL Databases. Mehr zu Security-Aspekten erfährst du in unseren Microsoft Azure-Schulungen.

Passende Schulungen

AZ-500 – Microsoft Azure Security Technologies (AZ-500T00)

AZ-500 – Microsoft Azure Security Technologies (AZ-500T00): Kenntnisse zur Sicherung von Microsoft Azure-Umgebungen

AZ-104 Microsoft Azure Administrator (AZ-104T00)

AZ-104 Microsoft Azure Administrator (AZ-104T00): Azure Administration für Profis

Der erste Teil (Link) befasste sich mit der Verschlüsselung in Ruhe für Speicherkonten, für verwaltete Datenträger, der Azure Disk Encryption (ADE) und der Verschlüsselung auf dem Host (für VM Datenträger). Dieser Teil kümmert sich um die Verschlüsslung im Kontext von MS-SQL-Datenbanken und wirft einen Blick auf Transparent „Data Encryption“ und „Always Encrypted“.

Sicherheit & Verschlüsselung bei Azure SQL Databases

Microsoft stellt die eigene SQL-Server-Engine selbstverständlich auch in diversen auf Azure host-baren Varianten zur Verfügung. Zwei davon sind Platform-Services (PaaS), nämlich „SQL-Datenbanken“ und „Verwaltete SQL-Instanzen“, „Virtuelle SQL-Computer“ hingegen sind Infrastructure-as-a-Service (IaaS). Suchst du im Azure-Portal nach „Azure SQL“ und klickst dann auf „Neu Erstellen“ ist das eine Art übergeordnete SQL-on-Azure-Einstiegsebene von der aus du mit „Neu erstellen“ eine Übersicht der genannten „SQL-Bereitstellungsoptionen“ angezeigt bekommst, mit den jeweiligen Detail-Informationen, wenn du auf „Details anzeigen“ klickst.

Jede der drei Optionen findest du direkt, indem du im Azure Portal z. B. nach „SQL Datenbanken“, „Verwaltete SQL-Instanzen“ oder “Virtuelle SQL-Computer“ suchst. Dieser Artikel hat jedoch nicht die Grundlagen der SQL-Bereitstellung zum Ziel, daher hier in Kürze nur soviel:

Mit „Virtuelle SQL-Computer“ hast du die Möglichkeit, gezielt nach einem passend vorbereiteten Maschine-Image mit einer bestimmten unterstützen Kombination aus Windows Server oder Linux und SQL Server (Free, Enterprise, Standard, Web) zu suchen, die den Anforderungen deiner Anwendung im Rahmen eines Migrations-Szenarios genügt. Die Bandbreite reicht von „SQL Server 2022 on Windows Server 2022“ bis hinunter zu „SQL Server 2012 SP4 auf Windows Server 2012R2“. 

Selbstverständlich könntest du auch ein gewöhnliches Windows-Server- oder Linux-Image verwenden und dann anschließend die passende MS-SQL-Version darauf installieren. Dann müsstest du aber exakt wissen, welche OS-Version mit welcher SQL-Server-Version harmoniert. Daher bevorzuge in Falle IaaS das Bereitstellungsmodell „Virtuelle SQL-Computer“. Du kannst alternativ auch im Marktplatz nach „SQL Server“ suchen. Alle Angebote von Microsoft auf Basis virtueller Maschinen entsprechen diesem Bereitstellungsmodell:

Die Infrastruktur-Variante nimmst du nur dann, wenn du einen SQL-Workload mit hundertprozentiger Feature-Kompatibilität zu Azure migrieren musst und dein Workload Features nutzt, die Zugriff/Sichtbarkeit auf den unterliegenden SQL-Server benötigen, wie z. B. Server-gespeicherte Prozeduren. Auch wenn dein Workload eine ganze bestimmte SQL-Server-Version zwingend benötigt, musst du diesen Weg gehen, musst dann aber neben der vollen Kontrolle über den Server als Vorteil auch Nachteile in Kauf nehmen, die Infrastruktur eben mit sich bringt, d. h. du musst dich um OS-Patches, SQL-Patches, Backups, Verfügbarkeit und Verschlüsslung selbst kümmern.

Dem ist nicht so bei den beiden anderen Varianten. Wählt du z. B. SQL-Server, hast du nicht nur stets die aktuellste SQL-Server-Engine-Version, Microsoft kümmert sich auch um Hochverfügbarkeit, Sicherungen, Patchmanagement und sogar um Skalierung von Compute und Storage, wenn du dich wie in der Abbildung für die serverlose Variante entscheidest. Du hast nur keine direkte Kontrolle (RDP / SSH– Zugang) zum unterliegenden Server und dein Workload kann demzufolge auch keine Funktionen nutzen, die eine solche Kontrolle benötigen.

Auch die andere PaaS-SQL-Datenbank-Bereitstellungsvariante „Verwaltete SQL-Instanzen“ (Azure SQL Managed Instance) bietet keinen Zugriff auf den unterliegenden Server, allerdings gibt es hier eine direkte 1:1-Beziehung zwischen der Ressource SQL-Datenbank und SQL-Server im Gegensatz zur Azure SQL Database“, bei der ein sogenannter „logischer“ SQL-Server von der Azure Service Fabrique verwaltet wird.

Die verwaltete SQL-Instanz hat im Gegensatz zur Azure SQL Datenbank genau wie der virtuelle SQL-Computer in erste Linie Migrations-Szenarien im Fokus, dient also vorrangig dem Modernisieren vorhandener SQL-Server-Anwendungen mit einer intelligenten, vollständig verwalteten Instanz als Service. Diese bietet anstelle hundertprozentiger Feature-Parität mit der SQL-Server-Datenbank-Engine (wie der virtuelle SQL-Computer), nur „nahezu“ hundertprozentige Feature-Parität, ist dafür aber ein Plattform-Service, d. h. Microsoft kümmert sich auch hier im Patching, Sicherungen und hohe Verfügbarkeit. Die folgende Abbildung zeigt die Unterschiede der drei beschriebenen Bereitstellungsmodelle im Kontext des jeweiligen Einsatzzwecks.

Eine eindeutige Bewertung hinsichtlich besser/schlechter ist hier schlichtweg nicht möglich. Bist du im Rahmen eines Migrationsszenarios nicht zwingend auf Infrastructure-as-a-Service angewiesen, weil z. B. deine Datenbank-basierte Anwendung eine spezifische SQL-Server-Version zwingend benötigt, solltest du eine der beiden PaaS-Varianten bevorzugen.  

Auch hier musst du es von den Anforderungen deine Workloads abhängig machen, für welche Version du dich entscheidest. Einen ziemlich detaillierten Feature-Vergleich liefert dir Microsoft hier https://learn.microsoft.com/azure/azure-sql/database/features-comparison?view=azuresql.

Verschlüsselung Azure SQL: Die Authentifizierung

Zur den zahleichen unterstützten Sicherheitsfeatures gehört neben der Verschlüsselung auch die Authentifizierung. Eine Besonderheit bei einer unter Azure gehosteten SQL-Datenbank – hier zahlt sich aus, das Microsoft gleichermaßen Hersteller des Serverbetriebssystems sowie der SQL-Engine und gleichermaßen Betreiber der Cloud-Infrastruktur ist – dass du in puncto Sicherheit nicht über die Verschlüsselung bestimmen kannst, sondern dir bei den PaaS-Varianten auch verschiedene Optionen der Authentifizierung zur Verfügung stehen. Dazu gehören die SQL-Server-Authentifizierung, die Entra-ID-Authentifizierung oder beide in Kombination.

Diese wählst du beim Erstellen des „logischen SQL-Servers“. Dessen Name muss übrigens weltweltweit eindeutig sein, da der Name des Servers immer Bestandsteil des Namens des Endpunktes mit dem Suffix „……database.windows.net“ ist, mit dessen Hilfe du bei einem PaaS-Service ausschließlich auf die Datenbank zugreifen kannst (egal, ob du über einen öffentlichen oder internen Pfad kommst), denn etwaige IP-Adressen werden bei einem Plattformdienst wie diesem vor dir verborgen, bzw. intern über den Azure Service Fabrique Controller gesteuert. Bei „Authentifizierung“ wählst du die gewünschte „Authentifizierungsmethode“. Im Falle von „SQL-Authentifizierung verwenden“ musst du noch einen administrativen Datenbankbenutzer bestimmen.

Die SQL-Authentifizierung nutzt wie zu erwarten einen Benutzernamen und ein Kennwort. Diese Anmeldeinformationen kannst du für die Authentifizierung bei jeder Datenbank auf genau diesem (logischen) Server als Datenbankbesitzer einsetzen. Unabhängig von der Authentifizierungsmethode kannst du stets zwei Arten von Datenbankbenutzern erstellen. Du kannst z. B. Benutzerkonten in der Masterdatenbank erstellen und Berechtigungen für alle Datenbanken auf dem Server erteilen oder du kannst sie in der Datenbank selbst erstellen. Letztere bezeichnet man auch als eigenständige Datenbankbenutzer. Das Verwenden eigenständiger Datenbankbenutzer verbessert die Portabilität der Datenbank. 

Die Microsoft Entra ID-Authentifizierungsmethode nutzt hingegen von Microsoft Entra ID verwaltete Identitäten und wird für verwaltete und integrierte Domänen unterstützt. Möchtest du die Microsoft Entra ID-Authentifizierung verwenden, musst du bei „Microsoft Entra ID-Administrator festlegen“ ein passendes Konto aus deinem Entra ID auswählen.  

Dieser Administrator ist dann berechtigt, Microsoft Entra ID-Benutzer und -Gruppen zu verwalten und zusätzlich alle Vorgänge durchzuführen, die reguläre Serveradministratoren ausführen können. 

Verschlüsselung Azure SQL: Transparent Data Encryption (TDE)

Nun aber zur Verschlüsselung, neben der Authentifizierung, dem Datenbank-Audit, dem Defender for SQL, der dynamischen Datenmaskierung und der Datenermittlung/Klassifizierung, dem mit Abstand wichtigsten Sicherheits-Feature. Zur diskutieren sind hier die Verschlüsselung der Übertragung, die Verschlüsslung in Ruhe („Transparent Data Encryption“) auf der Server-Seite und das von einem Treiber auf Client-Seite initiierte Feature „Always Encrypted“, bei dem Daten auf den Datenspeichern des Servers, bei Übertragung UND „in Benutzung“, d. h. im Arbeitsspeicher des Servers Ende-zu-Ende verschlüsselt werden/bleiben. Um die Verschlüsselung der Übertragung musst du dich übrigens nicht selbst kümmern, da sie im Gegensatz zu einem Storage Account obligatorisch ist.

Doch zunächst kurz zu „von Transparent Data Encryption (TDE). Das Feature ist bei MS SQL-Server (egal ob on Premise oder in der Cloud) seit vielen Jahren Standard und trägt durch das Verschlüsseln ruhender Daten erheblich zum Schutz von „Azure SQL-Datenbank“ oder „Verwaltete SWQL-Instanz“ (Azure SQL Managed Instance) bei. TDE ver- und entschlüsselt die Datenbank, die zugehörigen Sicherungen und die Transaktionsprotokolldateien im Ruhezustand in Echtzeit, ohne dass Änderungen an der Anwendung erforderlich sind. TDE ist standardmäßig für alle neu bereitgestellten Azure SQL-Datenbanken aktiviert. Du kannst lediglich entscheiden, um die verwendeten Schlüssel vom Dienst selbst bereitgestellt und verwaltet werden, oder ob du mit kundenseitig verwalteten Schlüsseln arbeiten möchtest, die z. B. in einem Azure Key Vault abgelegt sind:

Du kannst TDE allerdings nicht zum Verschlüsseln der Masterdatenbank in SQL-Datenbank verwenden, denn die Masterdatenbank enthält Objekte, die zum Ausführen der TDE-Vorgänge für die Benutzerdatenbanken notwendig sind.

Always Encrypted

Always Encrypted hingegen ist ein Feature zum Ende-zu-Ende-Schutz sensibler Daten wie Kreditkartennummern oder nationaler Identifikationsnummern wie z. B. Sozialversicherungsnummern, wenn solche Informationen in einer Azure SQL-Datenbank, Azure SQL Managed Instance und lokalen SQL Server-Datenbanken gespeichert sind. Always Encrypted erlaubt den Clients, sensible Daten direkt in der Client-Datenbankanwendungen zu verschlüsseln und damit dafür zu sorgen, dass die Verschlüsselungsschlüssel niemals an das Datenbankmodul weitergeben werden.

Das sorgt für eine eindeutige Trennung zwischen „Besitzern“ und „Verwaltern“ der Daten (Datenbankadministratoren, Clouddatenbankoperatoren oder andere nicht autorisierte Benutzer mit hoher Berechtigung), welche keinen Zugriff haben sollen.

Always Encrypted ermöglicht es Kunden somit, ihre vertraulichen Daten in der Cloud sicher zu speichern und die Wahrscheinlichkeit des Datendiebstahls durch „böswillige Insider“ zu verringern. Always Encrypted macht die Verschlüsselung somit gegenüber den Anwendungen gegenüber transparent.

Dies ermöglich ein auf dem für Always Encrypted aktivierten Client-PC installierter Treiber durch die automatische Ver- und Entschlüsselung von sensiblen Daten in der Client-Anwendung. Der Treiber verschlüsselt die Daten in vertraulichen Spalten, bevor er sie an Datenbank-Engine weitergibt, und schreibt Abfragen automatisch neu, damit die Semantik der Anwendung beibehalten werden kann. Bei Abfragen werden die in verschlüsselten Datenbankspalten gespeicherte Daten aus Abfrageergebnissen durch den Treiber transparent entschlüsselt. Du kannst Always Encrypted  z. B. auch so konfigurieren, dass eingeschränkte vertrauliche Abfragen für verschlüsselte Daten unterstützt werden. Derartige Abfragen nutzen deterministische Verschlüsselung.

Zum Einrichten von Always Encrypted in deiner Datenbank musst du zuerst die kryptografischen Schlüssel bereitstellen. Always Encrypted verwendet zwei Arten von Schlüsseln, nämlich „Spaltenverschlüsselungsschlüssel“ und „Spaltenhauptschlüssel“. Der Spaltenverschlüsselungsschlüssel wird genutzt, um Daten in einer verschlüsselten Spalte zu verschlüsseln. Der Spaltenhauptschlüssel hingegen ist der Schlüssel zum Schutz von Schlüsseln, der einen oder mehrere Spaltenverschlüsselungsschlüssel verschlüsselt. Du speicherst den Spaltenhauptschlüssel in einem vertrauenswürdigen Schlüsselspeicher außerhalb des Datenbanksystems, z. B. Azure Key Vault, Windows-Zertifikatspeicher oder einem Hardwaresicherheitsmodul.

Anschließend musst du Spaltenverschlüsselungsschlüssel bereitstellen und jeden mit einem Spaltenhauptschlüssel verschlüsseln. Danach musst du die Metadaten zu den Schlüsseln in deiner Datenbank speichern. Die Metadaten des Spaltenhauptschlüssels erfassen den Speicherort des Spaltenhauptschlüssels. Die Metadaten des Spaltenverschlüsselungsschlüssels enthalten den verschlüsselten Wert des Spaltenverschlüsselungsschlüssels. Beachte, dass die Datenbank-Engine die genannten Schlüsselarten niemals im Klartext speichert oder verwendet.

Schauen wir nun auf das Konfigurieren der Verschlüsselung für ausgewählte Datenbankspalten mit vertraulichen Daten, die geschützt werden sollen. Dies beinhaltet das Erstellen neuer Tabellen mit verschlüsselten Spalten oder das Verschlüsseln vorhandener Datenbankspalten und vorhandenen Daten. Beim Einrichten der Verschlüsselung für eine Spalte gibst du die erforderlichen Informationen an, nämlich einen Verschlüsselungsalgorithmus, einen Spaltenverschlüsselungsschlüssel zum Schutz der Daten in der Spalte und einen Verschlüsselungstyp. Always Encrypted unterstützt zwei Verschlüsselungstypen:

• Die deterministische Verschlüsselung generiert für jeden Wert in Klartext stets den selben verschlüsselten Wert. Sie ermöglicht die Punktsuche, Gleichheitsverknüpfung, Gruppierung und Indizierung in verschlüsselten Spalten. Sie erlaubt aber auch, dass nicht autorisierte Benutzer Informationen zu verschlüsselten Werten erraten könnten, wenn sie nach Mustern in der verschlüsselten Spalte suchen, vor allem wenn es nur eine kleine Anzahl von möglichen verschlüsselten Werten wie z. B. TRUE/FALSE gibt.
• Die zufällige Verschlüsselung verschlüsselt die Daten in einer weniger vorhersagbaren Weise. Die zufällige Verschlüsselung ist sicherer, verhindert aber die Suche, Gruppierung, Indizierung und Verknüpfung für verschlüsselte Spalten.

In der folgenden Abbildung habe ich in einer Medizin-Datenbank, die Patienten-Tabelle im Management Studio geöffnet und nach Spalten mit potenziell sensiblen Informationen gesucht. Hier wählst du z. B. in der Spalte „SSN“ im Kontextmenü den Eintrag „Encrypt Column“.

Dadurch öffnet sich der Client-Treiber von Always Encrypted mit einem leicht zu bedienenden Assistenten.

Im nächsten Schritt „Enable Secure Enclaves“ kannst du dich mit einem passenden Entra-ID-Konto anmelden, indem du auf „Sign In..“ klickst, sofern deine Datenbank das Feature „Secure Enclaves“ aktiviert hat. Das ist hier nicht der Fall. Du kannst dich aber trotzdem bereits hier mit deinem Azure-Account anmelden, da du im Verlauf des Assistenten Zugriff auf einen Azure Key Vault benötigst.

Setzte dann im Schritt „Column Selection“ den Haken bei deiner ausgewählten Spalte und wähle einen „Encryption Type“, z. B. „Deterministic“. Der Name des neu zu erstellenden Keys ist dann „CEK_Auto1“.

Mit „Next“ geht es weiter zu „Master Key Configuration“. Hier wählst du „Azure Key Vault“ als „Storage Provider“, was voraussetzt, dass du zuvor einen Key Vault mit einer passenden Zugriffsrichtlinie erstellt hast, d. h. der Entra-ID-Benutzer, mit dem du hier arbeitest, benötigt Berechtigungen für sämtliche Schlüsselverwaltungsvorgänge und das Recht zum „Signieren“ bei den Kyptografischen Vorgängen.

Die weiteren Schritte bis „Summary“ überspringst du, bzw. akzeptierst die Defaults und klickst auf „Finish“.

Der Client-Treiber beginnt danach mit der Generierung der Schlüssel.

Du kannst den Prozess mit weiteren sensiblen Spalten wiederholen, wenn du möchtest.