Always Encrypted mit Secure Enclaves

  • Artikel

Gilt für: SQL Server 2019 (15.x) und höher – nur Windows Azure SQL-Datenbank

Always Encrypted mit Secure Enclaves erweitert die Computingfunktionen von Always Encrypted, indem die direkte Verschlüsselung und umfangreichere vertrauliche Abfragen ermöglicht werden. Always Encrypted mit Secure Enclaves ist in SQL Server 2019 (15.x) und höher sowie in Azure SQL-Datenbank verfügbar.

Always Encrypted wurde 2015 in Azure SQL-Datenbank und in SQL Server 2016 (13.x) eingeführt und schützt vertrauliche Daten vor Schadsoftware und nicht autorisierten Benutzern mit hohen Berechtigungen: Datenbankadministratoren (DBAs), Computeradministratoren, Cloudadministratoren oder allen anderen Personen, die legitimen Zugriff auf Serverinstanzen, Hardware usw. haben, aber keinen Zugriff auf einige oder alle der eigentlichen Daten haben sollten.

Ohne die in diesem Artikel erläuterten Erweiterungen schützt Always Encrypted die Daten, indem das Feature die Daten auf Clientseite verschlüsselt und niemals zulässt, dass die Daten oder die zugehörigen kryptografischen Schlüssel als Klartext in der Datenbank-Engine angezeigt werden. Daher ist die Funktionalität von verschlüsselten Spalten innerhalb der Daten stark eingeschränkt. Die einzigen Vorgänge, die die Datenbank-Engine für verschlüsselte Daten ausführen kann, sind Gleichheitsvergleiche (nur bei deterministischer Verschlüsselung verfügbar). Alle anderen Vorgänge, beispielweise kryptografische Vorgänge (anfängliche Datenverschlüsselung oder Schlüsselrotation) sowie umfangreichere Abfragen (z. B. Musterabgleich) werden innerhalb der Datenbank nicht unterstützt. Benutzer müssen ihre Daten aus der Datenbank verschieben, um diese Vorgänge auf Clientseite auszuführen.

Always Encrypted mit Secure Enclaves beseitigt diese Einschränkungen, indem einige Berechnungen für Klartextdaten innerhalb einer Secure Enclave auf Serverseite zugelassen werden. Eine Secure Enclave ist ein geschützter Speicherbereich innerhalb des Datenbank-Engine-Prozesses. Die Secure Enclave wird dem Rest der Datenbank-Engine und anderen Prozessen auf dem Hostcomputer als undurchsichtiger Behälter angezeigt. Es gibt keine Möglichkeit, Daten oder Code innerhalb der Enclave von außen anzuzeigen, auch nicht mit einem Debugger. Diese Eigenschaften machen die Secure Enclave zu einem Trusted Execution Environment, das sicher auf kryptografische Schlüssel und vertrauliche Daten in Klartextform zugreifen kann, ohne die Vertraulichkeit der Daten zu gefährden.

Always Encrypted verwendet Secure Enclaves wie im folgenden Diagramm veranschaulicht:

Datenfluss

Beim Analysieren einer Transact-SQL-Anweisung, die von einer Anwendung gesendet wird, ermittelt die Datenbank-Engine, ob die Anweisung Vorgänge für verschlüsselte Daten enthält, für die die Verwendung der Secure Enclave erforderlich ist. Für diese Anweisungen gilt:

  • Der Clienttreiber sendet die für die Vorgänge erforderlichen Spaltenverschlüsselungsschlüssel an die Secure Enclave (über einen sicheren Kanal) und übermittelt die Anweisung, die ausgeführt werden soll.

  • Bei der Verarbeitung der Anweisung delegiert die Datenbank-Engine Kryptografievorgänge oder Berechnungen für verschlüsselte Spalten an die Secure Enclave. Bei Bedarf entschlüsselt die Enclave die Daten und führt Berechnungen in Klartextform aus.

Während der Verarbeitung der Anweisung werden weder die Daten noch die Spaltenverschlüsselungsschlüssel außerhalb der Secure Enclave in Klartextform in der Datenbank-Engine verfügbar gemacht.

Unterstützte Clienttreiber

Um Always Encrypted mit Secure Enclaves verwenden zu können, muss eine Anwendung einen Clienttreiber nutzen, der dieses Feature unterstützt. Konfigurieren Sie die Anwendung und den Client-Treiber so, dass Enclave-Berechnungen und Enclave-Attestierung möglich sind (siehe den Abschnitt Sichere Enclave-Attestierung weiter unten). Weitere Informationen, einschließlich der Liste der unterstützten Clienttreiber, finden Sie unter Entwickeln von Anwendungen mithilfe von Always Encrypted.

Unterstützte Enclavetechnologien

Always Encrypted unterstützt die folgenden Enklaventechnologien (oder Enklaventypen):

Die Art der Enklave, die für Ihre Datenbank verfügbar ist, hängt von dem SQL-Produkt ab, das sie hostet (Azure SQL-Datenbank vs. SQL Server) und (im Falle von Azure SQL-Datenbank) von der Konfiguration Ihrer Datenbank.

  • In SQL Server 2019 (15.x) und höher unterstützt Always Encrypted VBS Enklaven. (Intel SGX-Enklaven werden nicht unterstützt.)

  • In Azure SQL Database kann eine Datenbank entweder eine Intel SGX-Enklave oder eine VBS-Enklave verwenden, je nach der Hardware, für die die Datenbank konfiguriert ist:

    • Datenbanken, die die Hardwarekonfiguration der DC-Serie verwenden (verfügbar mit dem Kaufmodell mit virtuellem Kern), nutzen Intel SGX-Enklaven.
    • Datenbanken, die eine andere Konfiguration als DC-Serie mit dem Kaufmodell mit virtuellem Kern verwenden, und Datenbanken, die das DTU-Kaufmodell verwenden, können für die Verwendung von VBS-Enklaven konfiguriert werden.

    Hinweis

    VBS-Enclaves sind derzeit in allen Azure SQL Database-Regionen verfügbar, außer: Jio Indien, Mitte.

Im Abschnitt Sicherheitserwägungen finden Sie wichtige Informationen über das Schutzniveau, das die einzelnen Enklaventypen bieten.

Nachweis von Secure Enclaves

Der Enklaven-Nachweis ist ein Defense-in-Depth-Mechanismus, der helfen kann, Angriffe zu erkennen, bei denen der Enklaven-Code oder seine Umgebung von böswilligen Administratoren manipuliert wird.

Der Enklaven-Nachweis ermöglicht es einer Client-Anwendung, Vertrauen in die sichere Enklave für die Datenbank, mit der die Anwendung verbunden ist, aufzubauen, bevor die Anwendung die Enklave für die Verarbeitung sensibler Daten nutzt. Der Bestätigungsworkflow verifiziert, dass es sich bei der Enklave um eine echte VBS- oder Intel SGX-Enklave handelt und dass der darin ausgeführte Code die echte, von Microsoft signierte Enklavenbibliothek für Always Encrypted ist. Während des Nachweises kommunizieren sowohl der Client-Treiber innerhalb der Anwendung als auch die Datenbank-Engine mit einem externen Bescheinigungsdienst über einen vom Kunden festgelegten Endpunkt.

Always Encrypted kann einen der beiden Nachweisdienste verwenden:

Um Always Encrypted mit sicheren Enklaven für Ihre Anwendung zu aktivieren, müssen Sie in der Konfiguration des Client-Treibers in Ihrer Anwendung ein Nachweisprotokoll festlegen. Ein Nachweisprotokollwert bestimmt, ob 1) die Client-App den Nachweis verwendet, und wenn ja, gibt 2) den Typ des Nachweisdiensts an, der verwendet wird. In der folgenden Tabelle werden die unterstützten Nachweisprotokolle für die gültigen SQL-Produkt- und Enklaventypkombinationen erfasst:

Hostingprodukt Enklaventyp Unterstützte Nachweisprotokolle
SQL Server 2019 (15.x) und höher VBS-Enclaves HGS, kein Nachweis
Azure SQL-Datenbank SGX-Enklaven (DC-Reihendatenbanken) Microsoft Azure Attestation
Azure SQL-Datenbank VBS-Enclaves Kein Nachweis

Ein paar wichtige Punkte, die Sie beachten sollten:

  • Das Attestieren von VBS-Enklaven in SQL Server 2019 (15.x) und höher erfordert HGS. Sie können auch VBS-Enklaven ohne Nachweis verwenden (dazu sind wenngleich die neuesten Client-Treiber erforderlich).
  • Bei Intel SGX-Enclaves (in Datenbanken der DC-Serie) in Azure SQL Database ist ein Nachweis obligatorisch und erfordert Microsoft Azure Attestation.
  • VBS-Enclaven in Azure SQL-Datenbank unterstützen derzeit den Nachweis nicht.

Weitere Informationen finden Sie unter:

Terminologie

Enclave-fähige Schlüssel

Always Encrypted mit Secure Enclave führt das Konzept der Enclave-fähigen Schlüssel ein:

  • Enclave-fähiger Spaltenhauptschlüssel: Ein Spaltenhauptschlüssel, der mit der im Metadatenobjekt des Spaltenhauptschlüssels in der Datenbank angegebenen Eigenschaft ENCLAVE_COMPUTATIONS erstellt wird. Das Spaltenhauptschlüssel-Metadatenobjekt muss auch eine gültige Signatur der Metadateneigenschaften enthalten. Weitere Informationen finden Sie unter CREATE COLUMN MASTER KEY (Transact-SQL).
  • Enclave-fähiger Spaltenverschlüsselungsschlüssel: Ein Spaltenverschlüsselungsschlüssel, der mit einem Enclave-fähigen Spaltenhauptschlüssel verschlüsselt ist. Nur Enclave-fähige Spaltenverschlüsselungsschlüssel können für Berechnungen innerhalb der Secure Enclave verwendet werden.

Weitere Informationen finden Sie unter Verwalten von Schlüsseln für Always Encrypted mit Secure Enclaves.

Enclave-fähige Spalten

Eine Enclave-fähige Spalte ist eine Datenbankspalte, die mit einem Enclave-fähigen Spaltenverschlüsselungsschlüssel verschlüsselt ist.

Funktionen für vertrauliches Computing für Enclave-fähige Spalten

Die zwei wichtigsten Vorteile von Always Encrypted mit Secure Enclaves sind die direkte Verschlüsselung und die umfassenden vertraulichen Abfragen.

Direkte Verschlüsselung

Die direkte Verschlüsselung ermöglicht kryptografische Vorgänge für Datenbankspalten innerhalb der Secure Enclave, ohne die Daten aus der Datenbank zu verschieben. Die direkte Verschlüsselung verbessert die Leistung und die Zuverlässigkeit von kryptografischen Operationen. Sie können eine direkte Verschlüsselung mithilfe der Anweisung ALTER TABLE (Transact-SQL) durchführen.

Die unterstützten Kryptografievorgänge lauten:

  • Verschlüsseln einer Klartextspalte mit einem Enclave-fähigen Spaltenverschlüsselungsschlüssel
  • Erneutes Verschlüsseln einer verschlüsselten Enclave-fähigen Spalte, um:
    • einen Spaltenverschlüsselungsschlüssel zu rotieren: Hierbei wird die Spalte mit einem Enclave-fähigen Spaltenverschlüsselungsschlüssel erneut verschlüsselt.
    • den Verschlüsselungstyp einer Enclave-fähigen Spalte zu ändern, z. B. von deterministisch zu zufällig
  • Entschlüsseln von Daten, die in einer Enclave-fähigen Spalte gespeichert sind (Konvertieren der Spalte in eine Klartextspalte)

Eine direkte Verschlüsselung ist sowohl bei der deterministischen als auch bei der zufälligen Verschlüsselung zulässig, solange die an einem Kryptografievorgang beteiligten Spaltenverschlüsselungsschlüssel Enclave-fähig sind.

Vertrauliche Abfragen

Hinweis

SQL Server 2022 (16.x) fügt zusätzliche Unterstützung für vertrauliche Abfragen mit JOIN-, GROUP BY- und ORDER BY-Vorgängen in verschlüsselten Spalten hinzu.

Vertrauliche Abfragen sind DML-Abfragen, die Vorgänge für Enclave-fähige Spalten umfassen, die in der Secure Enclave ausgeführt werden.

In Secure Enclaves werden folgende Vorgänge unterstützt:

Vorgang Azure SQL-Datenbank SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Comparison Operators (Vergleichsoperatoren) Unterstützt Unterstützt Unterstützt
BETWEEN (Transact-SQL) Unterstützt Unterstützt Unterstützt
IN (Transact-SQL) Unterstützt Unterstützt Unterstützt
LIKE (Transact-SQL) Unterstützt Unterstützt Unterstützt
DISTINCT Unterstützt Unterstützt Unterstützt
Joins Unterstützt Unterstützt Unterstützt nur Joins geschachtelter Schleifen
SELECT - ORDER BY-Klausel (Transact-SQL) Unterstützt Unterstützt Nicht unterstützt
SELECT – GROUP BY – Transact-SQL Unterstützt Unterstützt Nicht unterstützt

Hinweis

Die oben genannten Vorgänge in sicheren Enklaven erfordern eine zufällige Verschlüsselung. Die deterministische Verschlüsselung wird nicht unterstützt. Der Gleichheitsvergleich bleibt die verfügbare Vorgänge für Spalten mit deterministischer Verschlüsselung.

Der Kompatibilitätsgrad der Datenbank sollte auf SQL Server 2022 (160) oder höher eingestellt sein.

In Azure SQL Database und in SQL Server 2022 (16.x) erfordern vertrauliche Abfragen, die Enklaven für eine Zeichenkettenspalte (char, nchar) verwenden, dass die Spalte eine Sortierreihenfolge mit binärem Codepunkt (_BIN2) oder eine Sortierreihenfolge mit UTF-8 verwendet. In SQL Server 2019 (15.x) ist eine a_BIN2 Sortierung erforderlich.

Weitere Informationen finden Sie unter Ausführen von Transact-SQL-Anweisungen mit sicheren Enklaven.

Indizes in Enclave-fähigen Spalten

Mithilfe der zufälligen Verschlüsselung können Sie nicht gruppierte Indizes für Enclave-fähige Spalten erstellen, um vertrauliche DML-Abfragen mithilfe der Secure Enclave schneller auszuführen.

Damit sichergestellt wird, dass eine mit zufälliger Verschlüsselung verschlüsselte Spalte keine vertraulichen Daten offenlegt, müssen die Schlüsselwerte in der Indexdatenstruktur (B-Struktur) basierend auf ihren Klartextwerten verschlüsselt und sortiert werden. Das Sortieren nach dem Klartextwert ist ebenfalls nützlich, um Abfragen innerhalb der Enclave zu verarbeiten. Wenn der Abfrageexecutor in der Datenbank-Engine einen Index auf einer verschlüsselten Spalte für Berechnungen innerhalb der Enclave verwendet, durchsucht er den Index nach bestimmten, in der Spalte gespeicherten Werten. Bei jeder Suche werden möglicherweise mehrere Vergleiche ausgeführt. Der Abfrageexecutor delegiert jeden Vergleich an die Enclave, die einen in der Spalte gespeicherten Wert und den zu vergleichenden verschlüsselten Indexschlüsselwert entschlüsselt, den Vergleich im Klartext durchführt und das Ergebnis des Vergleichs an den Executor zurückgibt.

Das Erstellen von Indizes für Spalten, die die zufällige Verschlüsselung verwenden und nicht Enclave-fähig sind, wird weiterhin nicht unterstützt.

Ein Index für eine Spalte mit deterministischer Verschlüsselung wird basierend auf Chiffretext (nicht Klartext) sortiert, unabhängig davon, ob die Spalte Enclave-fähig ist oder nicht.

Weitere Informationen finden Sie unter Erstellen und Verwenden von Indizes in Spalten mithilfe von Always Encrypted mit Secure Enclaves. Allgemeine Informationen zur Funktionsweise der Indizierung in der Datenbank-Engine finden Sie im Artikel Beschreibung von gruppierten und nicht gruppierten Indizes.

Datenbankwiederherstellung

Wenn eine SQL Server-Instanz ausfällt, könnten ihre Datenbanken in einem Zustand verbleiben, in dem die Datendateien einige Änderungen durch unvollständige Transaktionen enthalten könnten. Wenn die Instanz gestartet wird, führt sie einen Prozess namens Datenbankwiederherstellung aus, bei dem jede im Transaktionsprotokoll gefundene unvollständige Transaktion zurückgesetzt wird, um sicherzustellen, dass die Integrität der Datenbank erhalten bleibt. Wenn eine unvollständige Transaktion Änderungen an einem Index vorgenommen hat, müssen diese ebenfalls rückgängig gemacht werden. Beispielsweise müssten einige Schlüsselwerte im Index entfernt oder neu eingefügt werden.

Wichtig

Microsoft empfiehlt dringend, die Schnellere Datenbankwiederherstellung (ADR) für Ihre Datenbank zu aktivieren, bevor Sie den ersten Index auf einer Enclave-fähigen Spalte verwenden, die mit zufälliger Verschlüsselung verschlüsselt wurde. ADR ist standardmäßig in Azure SQL-Datenbank aktiviert, aber nicht in SQL Server 2019 (15.x) und höher.

Beim herkömmlichen Datenbankwiederherstellungsprozess (gemäß dem ARIES-Wiederherstellungsmodell) muss SQL Server zum Rückgängigmachen einer Änderung an einem Index warten, bis eine Anwendung den Spaltenverschlüsselungsschlüssel für die Spalte an die Enclave übermittelt. Dies kann sehr lange dauern. Die beschleunigte Datenbankwiederherstellung führt zu einer erheblichen Reduzierung der Anzahl der Rollbackvorgänge, die aufgeschoben werden müssen, weil ein Spaltenverschlüsselungsschlüssel im Cache innerhalb der Enclave nicht verfügbar ist. Infolgedessen wird die Verfügbarkeit der Datenbank erheblich erhöht, indem die Wahrscheinlichkeit, dass eine neue Transaktion blockiert wird, minimiert wird. Wenn die beschleunigte Datenbankwiederherstellung aktiviert ist, benötigt SQL Server möglicherweise immer noch einen Spaltenverschlüsselungsschlüssel, um die Bereinigung alter Datenversionen abzuschließen. Dies wird in SQL Server jedoch als Hintergrundtask erledigt, der sich nicht auf die Verfügbarkeit der Datenbank oder Benutzertransaktionen auswirkt. Unter Umständen könnte es jedoch zu Fehlermeldungen im Fehlerprotokoll kommen, die auf fehlgeschlagene Bereinigungsvorgänge aufgrund eines fehlenden Spaltenverschlüsselungsschlüssels hinweisen.

Sicherheitshinweise

Die folgenden Sicherheitsaspekte sind für Always Encrypted mit Secure Enclaves zu beachten.

  • VBS-Enklaven schützen Ihre Daten vor Angriffen innerhalb der VM. Sie bieten jedoch keinen Schutz vor Angriffen mit privilegierten Systemkonten, die vom Host ausgehen. Intel SGX-Enklaven schützen Daten vor Angriffen, die sowohl vom Gast-BS als auch vom Host-BS stammen.
  • Die Verwendung des Enklavennachweises wird empfohlen, wenn sie für Ihre Umgebung verfügbar ist und wenn Sie besorgt sind, dass Ihre Daten von Benutzern mit Administratorzugriff auf Betriebssystemebene auf den Computer geschützt werden, auf dem Ihre Datenbank gehostet wird. Wenn Sie den Nachweis verwenden, müssen Sie sicherstellen, dass der Nachweisdienst und seine Konfiguration von einem vertrauenswürdigen Administrator verwaltet werden. Darüber hinaus unterstützen die Nachweisdienste in der Regel verschiedene Richtlinien und Nachweismodi, von denen einige eine minimale Überprüfung der Enclave und ihrer Umgebung durchführen und für Test- und Entwicklungszwecke konzipiert sind. Halten Sie sich genau an die für Ihren Nachweisdienst spezifischen Richtlinien, um sicherzustellen, dass Sie die empfohlenen Konfigurationen und Richtlinien für Ihre Produktionsbereitstellungen verwenden.
  • Die Verschlüsselung einer Spalte unter Verwendung von zufälliger Verschlüsselung mit einem Enclave-fähigen Spaltenverschlüsselungsschlüssel könnte dazu führen, dass die Reihenfolge der in der Spalte gespeicherten Daten verloren geht, da solche Spalten Bereichsvergleiche unterstützen. Beispiel: Wenn eine verschlüsselte Spalte die Gehälter von Mitarbeitern enthält und einen Index aufweist, könnte ein böswilliger DBA den Index auf den höchsten verschlüsselten Gehaltswert überprüfen und so eine Person finden, die das maximale Gehalt erhält (vorausgesetzt, der Name der Person ist nicht verschlüsselt).
  • Wenn Sie vertrauliche Daten mit Always Encrypted vor unbefugtem Zugriff durch DBAs schützen, sollten Sie die Spaltenhauptschlüssel oder Spaltenverschlüsselungsschlüssel nicht an die DBAs weitergeben. Ein DBA kann Indizes für verschlüsselte Spalten ohne Direktzugriff auf die Schlüssel verwalten, indem er den Cache der Spaltenverschlüsselungsschlüssel innerhalb der Enclave nutzt.

Überlegungen zu Geschäftskontinuität, Notfallwiederherstellung und Datenmigration

Stellen Sie beim Konfigurieren einer Lösung für Hochverfügbarkeit oder Notfallwiederherstellung für eine Datenbank, die Always Encrypted mit Secure Enclaves verwendet, sicher, dass alle Datenbankreplikate eine Secure Enclave verwenden können. Wenn eine Enclave für das primäre, aber nicht für das sekundäre Replikat verfügbar ist, löst jede Anweisung, die versucht, die Funktionen von Always Encrypted mit Secure Enclaves zu verwenden, nach dem Failover einen Fehler aus.

Wenn Sie eine Datenbank mithilfe von Always Encrypted mit Secure Enclaves kopieren oder migrieren, achten Sie darauf, dass die Zielumgebung Enclaves immer unterstützt. Andernfalls funktionieren Anweisungen mit Enclaves nicht für Kopien oder migrierte Instanzen der Datenbank.

Folgendes sollten Sie berücksichtigen:

  • SQL Server

    • Stellen Sie beim Konfigurieren von Always On-Verfügbarkeitsgruppen sicher, dass jede SQL Server-Instanz, die eine Datenbank in der Verfügbarkeitsgruppe hostet, Always Encrypted mit Secure Enclaves unterstützt und sowohl eine Enclave als auch ein Nachweis für diese konfiguriert ist.
    • Wenn Sie eine Sicherungsdatei einer Datenbank wiederherstellen, die die Funktionen von Always Encrypted mit Secure Enclaves auf einer SQL Server-Instanz verwendet, für die die Enclave nicht konfiguriert ist, wird der Wiederherstellungsvorgang erfolgreich durchgeführt, und alle Funktionen, die nicht auf die Enclave angewiesen sind, sind verfügbar. Alle nachfolgenden Anweisungen, die die Enclave-Funktionen verwenden, schlagen jedoch fehl, und Indizes für Enclave-fähige Spalten mit zufälliger Verschlüsselung werden ungültig. Dasselbe gilt, wenn Sie eine Datenbank mit Always Encrypted mit Secure Enclaves an die Instanz anfügen, für die die Enclave nicht konfiguriert ist.
    • Wenn Ihre Datenbank Indizes für Enclave-fähige Spalten mit zufälliger Verschlüsselung enthält, stellen Sie sicher, dass Sie die ADR in der Datenbank aktivieren, bevor Sie eine Datenbanksicherung erstellen. Mit ADR wird sichergestellt, dass die Datenbank, einschließlich der Indizes, sofort nach der Wiederherstellung der Datenbank verfügbar ist. Weitere Informationen finden Sie unter Datenbankwiederherstellung.

  • Azure SQL-Datenbank

    • Wenn Sie die aktive Georeplikation konfigurieren, stellen Sie sicher, dass die sekundäre Datenbank Secure Enclaves unterstützt, wenn auch die primäre Datenbank dies tut.

Wenn Sie in SQL Server oder Azure SQL-Datenbank Ihre Datenbank mithilfe einer BACPAC-Datei migrieren, müssen Sie sicherstellen, dass Sie alle Indizes für Enclave-fähige Spalten mit zufälliger Verschlüsselung löschen, bevor Sie die BACPAC-Datei erstellen.

Bekannte Einschränkungen

Mit Always Encrypted mit Secure Enclaves werden einige Einschränkungen von Always Encrypted behoben, da die direkte Verschlüsselung und umfangreichere vertrauliche Abfragen mit Indizes wie im Abschnitt Funktionen für vertrauliches Computing für Enclave-fähige Spalten beschrieben unterstützt werden.

Alle anderen Beschränkungen für Always Encrypted, die unter den Limits aufgeführt sind, gelten auch für Always Encrypted mit Secure Enclaves.

Die folgenden Einschränkungen sind für Always Encrypted mit Secure Enclaves zu beachten:

  • Gruppierte Indizes können nicht auf Enclave-fähigen Spalten mit zufälliger Verschlüsselung erstellt werden.
  • Enclave-fähige Spalten mit zufälliger Verschlüsselung können keine Primärschlüsselspalten sein und können nicht durch Fremdschlüsselbeschränkungen oder eindeutige Schlüsselbeschränkungen referenziert werden.
  • In SQL Server 2019 (15.x) (diese Einschränkung gilt nicht für Azure SQL-Datenbank oder SQL Server 2022 (16.x)) werden nur Joins geschachtelter Schleifen (mit Indizes, falls verfügbar) für Enclave-fähige Spalten mit zufälliger Verschlüsselung unterstützt. Informationen zu anderen Unterschieden zwischen den verschiedenen Produkten finden Sie unter Vertrauliche Abfragen.
  • Direkte Verschlüsselungsvorgänge können nicht mit anderen Änderungen an Spaltenmetadaten kombiniert werden. Ausgenommen hiervon sind Änderungen einer Sortierung innerhalb derselben Codeseite und der NULL-Zulässigkeit. Beispiel: Sie können nicht in einer einzigen ALTER TABLE/ALTER COLUMN-Transact-SQL-Anweisung eine Spalte verschlüsseln, erneut verschlüsseln oder entschlüsseln UND den Datentyp der Spalte ändern. Sie müssen zwei separate Anweisungen verwenden.
  • Die Verwendung von Enclave-fähigen Schlüsseln für Spalten in In-Memory-Tabellen wird nicht unterstützt.
  • Ausdrücke, die berechnete Spalten definieren, können keine Berechnungen für Enclave-fähige Spalten mit zufälliger Verschlüsselung durchführen – selbst dann nicht, wenn die Berechnungen zu den unter Vertrauliche Abfragen aufgeführten unterstützen Vorgängen gehören.
  • Escapezeichen werden in Parametern des LIKE-Operators in Enclave-fähigen Spalten, die die zufällige Verschlüsselung verwenden, nicht unterstützt.
  • Abfragen mit dem LIKE-Operator oder einem Vergleichsoperator, der einen Abfrageparameter mit einem der folgenden Datentypen hat (die nach der Verschlüsselung zu großen Objekten werden), ignorieren Indizes und führen Tabellenscans durch.
    • nchar[n] und nvarchar[n], wenn n größer als 3967 ist.
    • char[n], varchar[n], binary[n], varbinary[n], wenn n größer als 7935 ist.
  • Tooleinschränkungen:
    • Die einzigen unterstützten Schlüsselspeicher für Enclave-fähige Spaltenhauptschlüssel sind Windows Certificate Store und Azure Key Vault.
    • Um einen direkten kryptografischen Vorgang über eine ALTER TABLE/ALTER COLUMN-Anweisung auszulösen, müssen Sie die Anweisung über ein Abfragefenster in SSMS oder Azure Data Studio ausgeben. Alternativ dazu können Sie selbst ein Programm schreiben, das die Anweisung ausgibt. Derzeit unterstützen das Set-SqlColumnEncryption Cmdlet im SqlServer PowerShell-Modul und der Assistent Immer verschlüsselt in SQL Server Management Studio keine direkte Verschlüsselung. Verschieben Sie die Daten aus der Datenbank für kryptografische Vorgänge, auch wenn die für die Vorgänge verwendeten Spaltenverschlüsselungs-Schlüssel enklavenfähig sind.
  • Wenn Sie eine VBS-Enklaven-fähigen Datenbank wiederherstellen, ist es wichtig, die VBS-Enklaveneinstellung erneut zu konfigurieren.

Nächste Schritte

Weitere Informationen