Teilen über

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

  • Artikel

Anwendbar für: SQL Server 2019 (15.x) und höher – ausschließlich 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

Zum Ausführen von Anweisungen mit Secure Enclaves müssen Sie Always Encrypted aktivieren, ein Bescheinigungsprotokoll angeben und, falls zutreffend, eine Nachweis-URL für die Datenbankverbindung angeben wie unter Voraussetzungen für das Ausführen von Anweisungen mit Secure Enclaves erläutert. Bei der Verbindung tritt jedoch ein Fehler auf, wenn Sie eine Nachweis-Protokoll angeben, aber Ihre Azure SQL-Datenbank oder SQL Server-Zielinstanz unterstützen Secure Enclaves nicht oder ist falsch konfiguriert.

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 sind:
    • 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.
  • Der logische Azure SQL-Server darf keine Nachweisanforderungen an den Nachweisanbieter 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 sind:
    • 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 mithilfe des Host-Überwachungsdienstes den folgenden Enclave-Nachweisworkflow aus.

  1. Der Clienttreiber ruft SQL Server auf, um den Nachweis einzuleiten.
  2. SQL Server sammelt die Beweise für die Enclave, die Hostingumgebung und den Code, der innerhalb der Enclave ausgeführt wird. SQL Server fordert ein Integritätszertifikat von der Host-Überwachungsdienstinstanz an, mit der der Computer, der SQL Server hostet, registriert wurde. Weitere Informationen finden Sie unter Registrieren des Computers beim Host-Überwachungsdienst.
  3. Der Host-Überwachungsdienst überprüft den Beweis und übergibt das Integritätszertifikat an SQL Server. 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 vorübergehenden Netzwerkfehlers nicht mit dem Host-Überwachungsdienst (Schritt 2 des obigen Workflows) verbunden werden. Zum Behandeln des Verbindungsproblems sollte der Administrator des SQL Server-Computers überprüfen, ob der Computer sich mit dem Computer des Host-Überwachungsdiensts verbinden kann.
  • Die Validierung in Schritt 3 schlägt fehl. So behandeln Sie Validierungsprobleme:
    • Der SQL Server-Computeradministrator sollte mit dem Administrator der Clientanwendung zusammenarbeiten, um zu überprüfen, ob der SQL Server-Computer bei derselben Host-Überwachungsdienstinstanz wie die Instanz, auf die in der Nachweis-URL auf der Clientseite verwiesen wird, registriert ist.
    • Der SQL Server-Computeradministrator sollte prüfen, ob der SQL Server-Computer erfolgreich beglaubigen kann, indem er die Anweisungen unter Schritt 5: Bestätigen Sie, dass der Host erfolgreich nachweisen kann.
  • Ihre Clientanwendung kann keine Verbindung mit dem Host-Überwachungsdienst herstellen und den öffentlichen Signaturschlüssel nicht abrufen (in Schritt 5). Die wahrscheinlichste Ursache ist Folgende:
    • 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

Weitere Informationen