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.
Gilt für:SQL Server
Azure SQL-Datenbank
Azure SQL Managed Instance
SQL-Datenbank in Microsoft Fabric
SQL Server verschlüsselt Daten anhand einer hierarchischen Verschlüsselungs- und Schlüsselverwaltungsinfrastruktur. Jede Ebene verschlüsselt die Ebene darunter, indem eine Kombination aus Zertifikaten, asymmetrischen und symmetrischen Schlüsseln verwendet wird. Asymmetrische Schlüssel und symmetrische Schlüssel können außerhalb von SQL Server in einem EKM-Modul (erweiterbare Schlüsselverwaltung) gespeichert werden.
In der folgenden Abbildung wird dargestellt, wie jede Ebene der Verschlüsselungshierarchie die Ebene darunter verschlüsselt und die häufigsten Verschlüsselungskonfigurationen anzeigt. Der Zugriff auf den Anfang der Hierarchie wird normalerweise durch ein Kennwort geschützt.
Denken Sie an Folgendes:
Verschlüsseln Sie Daten mit symmetrischen Schlüsseln anstatt mit Zertifikaten oder asymmetrischen Schlüsseln, um eine optimale Leistung zu erzielen.
Datenbankmasterschlüssel (DMK) werden durch den Dienstmasterschlüssel (Service Master Key, SMK) geschützt. Der Diensthauptschlüssel wird vom SQL Server-Setup erstellt und mithilfe der Windows-Datenschutz-API (Data Protection API, DPAPI) verschlüsselt.
Andere Verschlüsselungshierarchien mit zusätzlichen Ebenen sind möglich.
Ein EKM-Modul (Extensible Key Management, erweiterbare Schlüsselverwaltung) verfügt außerhalb von SQL Server über symmetrische oder asymmetrische Schlüssel.
Die transparente Datenverschlüsselung (TDE) muss einen symmetrischen Schlüssel verwenden, der als Datenbankverschlüsselungsschlüssel bezeichnet wird, der entweder durch ein zertifikatgeschützt durch das DMK der
master
Datenbank oder durch einen asymmetrischen Schlüssel geschützt ist, der in einem EKM gespeichert ist.Der Diensthauptschlüssel und die Datenbank-Hauptschlüssel sind symmetrische Schlüssel.
Die folgende Abbildung zeigt die gleichen Informationen auf eine andere Weise.
Dieses Diagramm veranschaulicht die folgenden zusätzlichen Konzepte:
In dieser Abbildung geben Pfeile allgemeine Verschlüsselungshierarchien an.
Symmetrische und asymmetrische Schlüssel im EKM können den Zugriff auf die symmetrischen und asymmetrischen Schlüssel schützen, die in SQL Server gespeichert sind. Die gepunktete Linie, die dem EKM zugeordnet ist, gibt an, dass Schlüssel im EKM die symmetrischen und asymmetrischen Schlüssel ersetzen könnten, die in SQL Server gespeichert sind.
Hintergrund
Azure SQL und SQL Server verwenden den RSA-Algorithmus für asymmetrische Verschlüsselung. Der RSA-Algorithmus kann nicht in seiner "reinen" Form verwendet werden, da es an semantischer Sicherheit mangelt und aufgrund seiner deterministischen Natur nicht sicher gegen ausgewählte Klartextangriffe oder Chiffretextangriffe ist. Durch die zweimale Verschlüsselung derselben Nachricht wird derselbe Chiffretext erzeugt.
Um Sicherheit zu gewährleisten, benötigen Nachrichten Auffüllen. Derzeit werden Daten mit RSA mit dem PKCS #1 v1.5-Abstandsschema verschlüsselt. Eine spezifische Schwäche des PKCS#1 v1.5-Abstands besteht darin, dass es nicht sehr redundant ist, wobei die eingebetteten Bytes zufällig sind, ohne dass ein bestimmter erzwungener Wert erforderlich ist. Eine Folge zufälliger Bytes kann mit einer kleinen Wahrscheinlichkeit "ordnungsgemäß aufgefüllt" werden. Ein Angreifer benötigt etwa eine Million abgebrochener Handshakes, um den Klartext durch Brute Force wiederherzustellen.
Neuere Versionen von PKCS#1 v1.5 beschreiben einen neuen Abstandstyp namens Optimal asymmetrischer Verschlüsselungsabstand (OAEP), der eine Hashfunktion verwendet, um eine erhebliche interne Redundanz hinzuzufügen, wodurch eine zufällige Zeichenfolge zum Abgleich mit dem Abstandsformat unwahrscheinlich ist. OAEP führt ein Hashing zwischen der RSA-Verschlüsselung und der Auffüllungsprüfung ein. Das Hashing von OAEP ändert die Fähigkeit des Angreifers, zu verstehen, was er sieht, erheblich.
Ab SQL Server 2025 (17.x) Preview wurde die OAEP-256-Unterstützung für RSA-basierte Verschlüsselung eingeführt. Der Wechsel zum OAEP-Abstandsmodus wird durch die Kompatibilitätsstufe der Datenbank gesteuert. Dieses Feature ist für Datenbanken auf 170 Datenbankkompatibilitätsebene oder höher verfügbar.
Verschlüsselungsmechanismen
SQL Server bietet die folgenden Verschlüsselungsmechanismen:
Transact-SQL-Funktionen
Asymmetrische Schlüssel
Symmetrische Schlüssel
Zertifikate
Transparente Datenverschlüsselung
Transact-SQL-Funktionen
Einzelne Elemente können verschlüsselt werden, während sie eingefügt oder mit Transact-SQL Funktionen aktualisiert werden. Weitere Informationen finden Sie unter ENCRYPTBYPASSPHRASE und DECRYPTBYPASSPHRASE.
Zertifikate
Ein öffentliches Schlüsselzertifikat, das normalerweise nur als Zertifikat bezeichnet wird, ist eine digital signierte Anweisung, die den Wert eines öffentlichen Schlüssels an die Identität der Person, des Geräts oder des Diensts bindet, die den entsprechenden privaten Schlüssel enthält. Zertifikate werden von einer Zertifizierungsstelle ausgegeben und signiert. Die Entität, die ein Zertifikat von einer Zertifizierungsstelle erhält, ist der Antragsteller dieses Zertifikats. In der Regel enthalten die Zertifikate die folgenden Informationen.
Den öffentlichen Schlüssel des Antragstellers.
Die Bezeichnerinformationen des Antragstellers, z. B. Name und E-Mail-Adresse.
Den Gültigkeitszeitraum. Dies ist der Zeitraum, in dem das Zertifikat als gültig betrachtet wird.
Ein Zertifikat ist lediglich für den angegebenen Zeitraum gültig; jedes Zertifikat enthält die Datumsangaben Gültig von und Gültig bis . Diese Datumsangaben legen den Gültigkeitszeitraum fest. Wenn der Gültigkeitszeitraum für ein Zertifikat abgelaufen ist, muss vom Antragsteller des gerade abgelaufenen Zertifikats ein neues Zertifikat angefordert werden.
Aussteller der Bezeichnerinformationen.
Die digitale Signatur des Ausstellers.
Diese Signatur bestätigt die Gültigkeit der Bindung zwischen dem öffentlichen Schlüssel und den Bezeichnerinformationen des Antragstellers. (Zum Vorgang der digitalen Signierung von Informationen gehört die Umwandlung der Informationen sowie einiger geheimer Informationen des Absenders in ein Tag, die so genannten Signatur.)
Ein wichtiger Vorteil von Zertifikaten besteht darin, dass die Hosts keine Kennwörter für einzelne Antragsteller mehr verwalten müssen. Stattdessen richtet der Host lediglich eine Vertrauensstellung in einem Zertifikataussteller ein, was dann eine unbegrenzte Anzahl von Zertifikaten signieren kann.
Wenn ein Host, z. B. ein sicherer Webserver, einen Aussteller als vertrauenswürdige Stammzertifizierungsstelle bezeichnet, vertraut der Host implizit den Richtlinien, die der Aussteller zum Herstellen der Bindungen der ausgestellten Zertifikate verwendet hat. Der Host vertraut sogar darauf, dass der Aussteller die Identität des Zertifikatantragstellers geprüft hat. Ein Host bezeichnet einen Aussteller als vertrauenswürdige Stammzertifizierungsstelle, indem er das selbstsignierte Zertifikat des Ausstellers, das den öffentlichen Schlüssel des Ausstellers enthält, im Zertifikatsspeicher der vertrauenswürdigen Stammzertifizierungsstelle des Hostcomputers ablegt. Den Zwischenzertifizierungsstellen und den untergeordneten Zertifizierungsstellen wird nur vertraut, wenn sie einen gültigen Zertifizierungspfad von einer vertrauenswürdigen Stammzertifizierungsstelle aufweisen.
Der Aussteller kann ein Zertifikat aufheben, bevor es abläuft. Eine Aufhebung unterbricht die Bindung eines öffentlichen Schlüssels mit der im Zertifikat angegebenen Identität. Jeder Aussteller verwaltet eine Zertifikatsperrliste, die von Programmen verwendet werden kann, wenn sie die Gültigkeit eines bestimmten Zertifikats überprüfen.
Die von SQL Server erstellten, selbstsignierten Zertifikate unterliegen dem X.509-Standard und unterstützen die X.509 v1-Felder.
Asymmetrische Schlüssel
Ein asymmetrischer Schlüssel besteht aus einem privaten Schlüssel und dem entsprechenden öffentlichen Schlüssel. Jeder Schlüssel kann die jeweils vom anderen verschlüsselten Daten entschlüsseln. Die asymmetrische Verschlüsselung und Entschlüsselung sind relativ ressourcenintensiv, sie bieten jedoch eine höhere Sicherheit als die symmetrische Verschlüsselung. Ein asymmetrischer Schlüssel kann für die Verschlüsselung eines symmetrischen Schlüssels zum Speichern in einer Datenbank verwendet werden.
Symmetrische Schlüssel
Ein symmetrischer Schlüssel ist ein Schlüssel, der sowohl für die Verschlüsselung als auch die Entschlüsselung verwendet wird. Die Verschlüsselung und Entschlüsselung mithilfe eines symmetrischen Schlüssels ist schnell und für einen routinemäßigen Einsatz mit sensiblen Daten in der Datenbank geeignet. Um das Schlüsselmaterial des symmetrischen Schlüssels zu schützen, speichert SQL Server das Schlüsselmaterial in verschlüsselter Form, das asymmetrische RSA-Verschlüsselung verwendet. In der Vergangenheit verwendete diese Verschlüsselung PKCS#1 v1.5-Abstandsmodus; Ab Datenbankkompatibilitätsebene 170 verwendet die Verschlüsselung den OAEP-256-Abstandsmodus.
Transparente Datenverschlüsselung
Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) ist ein spezieller Fall der Verschlüsselung mithilfe eines symmetrischen Schlüssels. TDE verschlüsselt eine ganze Datenbank mithilfe dieses symmetrischen Schlüssels, der als Verschlüsselungsschlüssel für die Datenbank bezeichnet wird. Der Datenbankverschlüsselungsschlüssel wird durch andere Schlüssel oder Zertifikate geschützt, die entweder durch das DMK oder durch einen asymmetrischen Schlüssel geschützt sind, der in einem EKM-Modul gespeichert ist. Weitere Informationen finden Sie unter Transparent Data Encryption (TDE).
Fabric SQL-Datenbank
In der SQL-Datenbank in Microsoft Fabric werden Always Encrypted, EKM und TDE derzeit nicht unterstützt. In der SQL-Datenbank in Microsoft Fabric ist die Microsoft Entra-ID für Datenbankbenutzer die einzige unterstützte Authentifizierungsmethode. Weitere Informationen finden Sie unter Autorisierung in sql-Datenbank im Vergleich zu Microsoft Fabric und Features.