Behandeln von häufig auftretenden Problemen bei Always Encrypted mit Secure Enclaves

  • Artikel

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

In diesem Artikel wird beschrieben, wie Sie häufige Probleme identifizieren und beheben, die bei der Ausführung von Transact-SQL-Anweisungen (T-SQL) mit Always Encrypted mit Secure Enclaves auftreten können.

Informationen zum Ausführen von Abfragen mit Secure Enclaves finden Sie unter Ausführen von Transact-SQL-Anweisungen mit Secure Enclaves.

Datenbankverbindungsfehler

Um Anweisungen mit einer sicheren Enklave auszuführen, müssen Sie Always Encrypted aktivieren, ein Nachweisprotokoll angeben und gegebenenfalls eine Nachweis-URL für die Datenbankverbindung angeben, wie in den Voraussetzungen für die Ausführung von Anweisungen mithilfe sicherer Enklaven erläutert. Die Verbindung schlägt jedoch fehl, wenn Sie ein Nachweisprotokoll angeben, ihre Azure SQL-Datenbank oder ihre Ziel-SQL Server-Instanz keine sicheren Enklaven unterstützt oder falsch konfiguriert ist.

Nachweisfehler bei der Verwendung von Microsoft Azure Attestation

Hinweis

Dieser Abschnitt gilt nur für Azure SQL-Datenbank mit Intel SGX-Enklaven.

Bevor ein Clienttreiber eine T-SQL-Anweisung zur Ausführung an den logischen Azure SQL-Server sendet, löst der Treiber mithilfe von Microsoft Azure Attestation den folgenden Enclave-Nachweisworkflow aus.

  1. Der Clienttreiber übergibt die in der Datenbankverbindung angegebene Nachweis-URL an den logischen Azure SQL-Server.
  2. Der logische Azure SQL-Server sammelt die Beweise für die Enclave, die Hostingumgebung und den Code, der innerhalb der Enclave ausgeführt wird. Der Server sendet dann eine Nachweisanforderung an den Nachweisanbieter, auf den in der Nachweis-URL verwiesen wird.
  3. Der Nachweisanbieter überprüft den Beweis anhand der konfigurierten Richtlinie und übergibt ein Nachweistoken an den logischen Azure SQL-Server. Der Nachweisanbieter signiert das Nachweistoken mit seinem privaten Schlüssel.
  4. Der logische Azure SQL-Server sendet das Nachweistoken an den Clienttreiber.
  5. Der Client kontaktiert den Nachweisanbieter an der angegebenen Nachweis-URL, um seinen öffentlichen Schlüssel abzurufen. Dieser überprüft die Signatur im Nachweistoken.

Aufgrund von Fehlkonfigurationen können in verschiedenen Schritten des obigen Workflows Fehler auftreten. Häufige Nachweisfehler, die zugehörigen Grundursachen und die empfohlenen Schritte zur Problembehandlung sind hier aufgeführt:

  • Der logische Azure SQL-Server kann keine Verbindung mit dem Nachweisanbieter in Azure Attestation (Schritt 2 des obigen Workflows) herstellen, der in der Nachweis-URL angegeben ist. Die wahrscheinlichen Ursachen umfassen:
    • Die Nachweis-URL ist falsch oder unvollständig. Weitere Informationen finden Sie unter Ermitteln der Nachweis-URL für die Nachweisrichtlinie.
    • Der Nachweisanbieter wurde versehentlich gelöscht.
    • Die Firewall wurde für den Nachweisanbieter konfiguriert, lässt aber keinen Zugriff auf Microsoft-Dienste zu.
    • Ein zeitweiliger Netzwerkfehler bewirkt, dass der Nachweisanbieter nicht verfügbar ist.
  • Ihr logischer Azure SQL-Server ist nicht berechtigt, Nachweisanforderungen an den Nachweisanbieter zu senden. Stellen Sie sicher, dass der Administrator Ihres Nachweisanbieters den Datenbankserver zur Nachweisrolle „Leser“ hinzugefügt hat.
  • Die Überprüfung der Nachweisrichtlinie schlägt fehl (in Schritt 3 des obigen Workflows).
    • Eine falsche Nachweisrichtlinie ist wahrscheinlich die Grundursache. Stellen Sie sicher, dass Sie die von Microsoft empfohlene Richtlinie verwenden. Weitere Informationen finden Sie unter Erstellen und Konfigurieren eines Nachweisanbieters.
    • Die Überprüfung der Richtlinie kann auch aufgrund einer Sicherheitsverletzung, die die serverseitige Enclave kompromittiert, fehlschlagen.
  • Die Clientanwendung kann sich nicht mit dem Nachweisanbieter verbinden und den öffentlichen Signaturschlüssel abrufen (in Schritt 5). Die wahrscheinlichen Ursachen umfassen:
    • Die Konfiguration von Firewalls zwischen der Anwendung und dem Nachweisanbieter kann die Verbindungen blockieren. Vergewissern Sie sich, dass Sie eine Verbindung mit dem OpenID-Endpunkt Ihres Nachweisanbieters herstellen können, um Probleme mit der blockierten Verbindung zu behandeln. Verwenden Sie beispielsweise einen Webbrowser auf dem Computer, der Ihre Anwendung hostet, um zu überprüfen, ob Sie eine Verbindung mit dem OpenID-Endpunkt herstellen können. Weitere Informationen finden Sie unter Metadatenkonfiguration – Get.

Nachweisfehler bei der Verwendung des Host-Überwachungsdienstes

Hinweis

Dieser Abschnitt gilt nur für SQL Server 2019 (15.x) und höher.

Bevor ein Clienttreiber eine T-SQL-Anweisung zur Ausführung an SQL Server sendet, löst der Treiber den folgenden Enklavennachweisworkflow mithilfe des Host Guardian Service (HGS) aus.

  1. Der Clienttreiber ruft SQL Server auf, um den Nachweis zu initiieren.
  2. SQL Server sammelt die Beweise über seine Enklave, seine Hostingumgebung und den Code, der innerhalb der Enklave ausgeführt wird. SQL Server fordert ein Integritätszertifikat von der HGS-Instanz an, bei dem der Computer, auf dem SQL Server gehostet wird, registriert wurde. Weitere Informationen finden Sie unter Registrieren des Computers beim Host-Überwachungsdienst.
  3. HGS überprüft die Nachweise und gibt das Integritätszertifikat auf SQL Server aus. Der Host-Überwachungsdienst signiert das Integritätszertifikat mit dem privaten Schlüssel.
  4. SQL Server sendet das Integritätszertifikat an den Clienttreiber.
  5. Der Clienttreiber kontaktiert den Host-Überwachungsdienst bei der Nachweis-URL, die für die Datenbankverbindung angegeben ist, um den öffentlichen Schlüssel des Host-Überwachungsdienstes abzurufen. Der Clienttreiber überprüft die Signatur im Integritätszertifikat.

Aufgrund von Fehlkonfigurationen können in verschiedenen Schritten des obigen Workflows Fehler auftreten. Häufige Nachweisfehler, die zugehörigen Grundursachen und die empfohlenen Schritte zur Problembehandlung werden nachfolgend aufgeführt:

  • SQL Server kann aufgrund eines zeitweiligen Netzwerkfehlers keine Verbindung mit HGS (Schritt 2 des obigen Workflows) herstellen. Um das Verbindungsproblem zu beheben, sollte der Administrator des SQL Server-Computers überprüfen, ob der Computer eine Verbindung mit dem HGS-Computer herstellen kann.
  • Die Validierung in Schritt 3 schlägt fehl. So beheben Sie das Überprüfungsproblem:
    • Der SQL Server-Computeradministrator sollte mit dem Clientanwendungsadministrator zusammenarbeiten, um zu überprüfen, ob der SQL Server-Computer mit derselben HGS-Instanz registriert ist wie die Instanz, auf die in der Nachweis-URL auf der Clientseite verwiesen wird.
    • Der SQL Server-Computeradministrator sollte bestätigen, dass der SQL Server-Computer erfolgreich nachweist, indem er den Anweisungen in Schritt 5 folgt: Bestätigen Sie, dass der Host erfolgreich bestätigen kann.
  • Ihre Clientanwendung kann keine Verbindung mit dem Host-Überwachungsdienst herstellen und den öffentlichen Signaturschlüssel nicht abrufen (in Schritt 5). Die wahrscheinliche Ursache ist:
    • Die Konfiguration einer der Firewalls zwischen Ihrer Anwendung und dem Nachweisanbieter kann die Verbindungen blockieren. Vergewissern Sie sich, dass der Computer, der die App hostet, eine Verbindung mit dem Computer des Host-Überwachungsdienstes hat.

Direkte Verschlüsselungsfehler

In diesem Abschnitt werden häufige Fehler aufgeführt, die bei der Verwendung von ALTER TABLE/ALTER COLUMN für die direkte Verschlüsselung auftreten können (zusätzlich zu den in den anderen Abschnitten beschriebenen Nachweisfehlern). Weitere Informationen hierzu finden Sie unter Konfigurieren einer direkten Spaltenverschlüsselung mithilfe von Always Encrypted mit Secure Enclaves.

  • Der Spaltenverschlüsselungsschlüssel, den Sie zum Verschlüsseln, Entschlüsseln oder erneuten Verschlüsseln von Daten verwenden möchten, ist kein Enclave-fähiger Schlüssel. Weitere Informationen zu den Voraussetzungen für die direkte Verschlüsselung finden Sie unter Voraussetzungen. Weitere Informationen zum Bereitstellen von Enclave-fähigen Schlüsseln finden Sie unter Bereitstellen Enclave-fähiger Schlüssel.
  • Sie haben Always Encrypted und Enclave-Berechnungen für die Datenbankverbindung nicht aktiviert. Weitere Informationen finden Sie unter Voraussetzungen für das Ausführen von Anweisungen mit Secure Enclaves
  • Die ALTER TABLE/ALTER COLUMN-Anweisung löst einen kryptographischen Vorgang aus und ändert den Datentyp der Spalte oder legt eine Sortierung mit einer anderen Codepage fest, die von der aktuellen Sortierungscodepage abweicht. Das Kombinieren kryptografischer Vorgänge mit Änderungen des Datentyps oder der Sortierungsseiten ist nicht zulässig. Verwenden Sie separate Anweisungen, um das Problem zu beheben: Eine Anweisung zum Ändern des Datentyps oder der Sortierungscodepage und eine andere Anweisung für die direkte Verschlüsselung.

Fehler beim Ausführen von vertraulichen DML-Abfragen mit Secure Enclaves

In diesem Abschnitt werden häufige Fehler aufgeführt, die auftreten können, wenn Sie vertrauliche DML-Abfragen mit Secure Enclaves ausführen (zusätzlich zu den in den anderen Abschnitten beschriebenen Nachweisfehlern).

Nächste Schritte

Siehe auch