Planen des Nachweises des Host-Überwachungsdiensts

  • Artikel

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

Der Nachweis ist ein Workflow, der es einer Clientanwendung ermöglicht, zu überprüfen, ob sie mit einer vertrauenswürdigen Enklave innerhalb des SQL Server-Prozesses spricht, wenn Sie Always Encrypted mit sicheren Enklaven verwenden.

In SQL Server verwendet Always Encrypted mit sicheren Enklaven In SQL Server, Always Encrypted with secure enclaves virtualisierungsbasierte Sicherheits-Enklaven (auch bekannt als Virtual Secure Mode oder VSM-Enklaven) - eine softwarebasierte Technologie, die auf dem Windows-Hypervisor basiert und keine spezielle Hardware erfordert. Das Attestieren einer VBS-Enklave umfasst die Überprüfung, ob der Code innerhalb der Enklave gültig ist und der Computer, auf dem SQL Server gehostet wird, vertrauenswürdig ist. Der Nachweis erreicht dieses Ziel durch die Einführung einer dritten Instanz, die die Identität (und optional die Konfiguration) des SQL Server-Computers überprüfen kann. Bevor SQL Server eine Enklave für eine Abfrage nutzen kann, müssen dem Nachweisdienst Informationen über deren Betriebsumgebung zur Verfügung gestellt werden, um ein Integritätszertifikat zu erhalten. Dieses Integritätszertifikat wird dann an den Client gesendet, der unabhängig davon dessen Authentizität mit dem Nachweisdienst überprüfen kann. Sobald das Integritätszertifikat vom Client als vertrauenswürdig eingestuft wurde, wird auch die VBS-Enclave als vertrauenswürdig erkannt und eine Abfrage ausgegeben, die diese Enclave verwendet.

Der Nachweis ist für die Erkennung einiger Angriffe durch böswillige Betriebssystemadministratoren von entscheidender Bedeutung, z. B. Angriffe, die Manipulationen mit der SQL Server-Bibliothek beinhalten, die innerhalb der Enklave ausgeführt wird. Wenn Sie sich keine Sorgen um solche Angriffe machen (z. B. verwenden Sie Always Encrypted mit sicheren Enklaven in einer Nicht-Produktionsumgebung), lesen Sie Plan für Always Encrypted mit sicheren Enklaven in SQL Server ohne Nachweis.

Die Rolle „Host-Überwachungsdienst“ (Host Guardian Service, HGS) in Windows Server 2019 oder höher bietet für Always Encrypted mit VBS-Enclaves die Möglichkeit, Remotenachweise zu erstellen. Dieser Artikel führt Sie durch die Entscheidungen und Anforderungen bei der Verwendung von Always Encrypted mit VBS-Enclaves und HGS-Nachweis.

Hinweis

Wenn SQL Server in einer VM bereitgestellt wird, schützen VBS-Enklaven Ihre Daten vor Angriffen innerhalb der VM. Sie bieten jedoch keinen Schutz vor Angriffen mit privilegierten Systemkonten, die vom Host ausgehen. Ein Speicherabbild der VM, die auf dem Hostcomputer generiert wurde, kann z. B. den Speicher der Enklave enthalten.

Übersicht über die Architektur

Der Host-Überwachungsdienst ist ein gruppierter Webdienst, der unter Windows Server 2019 oder höher ausgeführt wird. Bei einer typischen Bereitstellung gibt es 1 bis 3 HGS-Server, mindestens einen SQL Server-Computer und einen Computer, auf dem eine Clientanwendung oder Tools ausgeführt werden, z. B. SQL Server Management Studio. Da der HGS dafür verantwortlich ist, zu bestimmen, welche SQL Server-Computer vertrauenswürdig sind, ist sowohl eine physische als auch eine logische Isolation von der SQL Server-Instanz erforderlich, die er schützt. Wenn dieselben Administratoren Zugriff auf HGS und einen SQL Server-Computer haben, könnten sie den Nachweisdienst so konfigurieren, dass ein bösartiger Computer SQL Server ausführen kann, wodurch die VBS-Enklave kompromittiert wird.

HGS-Domäne

Das HGS-Setup erstellt automatisch eine neue Active Directory-Domäne für die HGS-Server, Failoverclusterressourcen und Administratorkonten.

Der Computer, auf dem SQL Server ausgeführt wird, muss sich nicht in einer Domäne befinden, aber wenn dies der Fall ist, sollte es eine andere Domäne sein als die, die der HGS-Server verwendet.

Hochverfügbarkeit

Über die HGS-Funktion wird automatisch ein Failovercluster installiert und konfiguriert. Es wird empfohlen, für Hochverfügbarkeit in einer Produktionsumgebung drei HGS-Server zu verwenden. Weitere Informationen zu der Bestimmung eines Clusterquorums und alternative Konfigurationen, einschließlich zweier Knotencluster mit einem externen Zeugen, finden Sie in der Dokumentation zu Failoverclustern.

Die HGS-Knoten müssen keinen freigegebenen Speicher nutzen. Eine Kopie der Nachweisdatenbank ist auf jedem HGS-Server gespeichert und wird vom Clusterdienst automatisch über das Netzwerk repliziert.

Netzwerkkonnektivität

Sowohl der SQL-Client als auch SQL Server müssen in der Lage sein, mit dem HGS über HTTP zu kommunizieren. Konfigurieren Sie HGS mit einem TLS-Zertifikat, um die gesamte Kommunikation zwischen dem SQL-Client und HGS sowie zwischen SQL Server und HGS zu verschlüsseln. Diese Konfiguration trägt zum Schutz vor Man-in-the-Middle-Angriffen bei und stellt sicher, dass Sie mit dem richtigen HGS-Server kommunizieren.

HGS-Server erfordern Konnektivität zwischen jedem Knoten im Cluster, um sicherzustellen, dass die Nachweisdienstdatenbank synchronisiert bleibt. Es ist eine bewährte Methode für failovercluster, die HGS-Knoten in einem Netzwerk für die Clusterkommunikation zu verbinden und ein separates Netzwerk für andere Clients für die Kommunikation mit HGS zu verwenden.

Nachweismodi

Wenn ein SQL Server-Computer versucht, einen HGS-Nachweis zu erstellen, wird vom HGS zunächst die Information abgerufen, wie der Nachweis erbracht werden soll. HGS unterstützt zwei Nachweismodi für die Verwendung mit SQL Server:

Nachweismodus Erklärung
TPM Der TPM-Nachweis (Trusted Platform Module) bietet die stärkste Sicherheit in Bezug auf die Identität und Integrität der Computer, die einen HGS-Nachweis aufweisen. SQL Server muss auf den Computern ausgeführt werden, damit TPM-Version 2.0 installiert werden kann. Jeder TPM-Chip enthält eine eindeutige und unveränderliche Identität (Endorsement Key), die zum Identifizieren eines bestimmten Computers verwendet werden kann. TPMs messen auch den Startprozess des Computers, wobei Hashes von sicherheitsrelevanten Messungen in Plattformkonfigurationsregistern (PCRs) gespeichert werden, die vom Betriebssystem gelesen, aber nicht geändert werden können. Diese Messungen werden bei der Überprüfung des Nachweises als kryptografischer Beleg verwendet, dass sich ein Computer in der von ihm angegebenen Sicherheitskonfiguration befindet.
Hostschlüssel Ein Hostschlüsselnachweis ist eine einfachere Form des Nachweises, bei der nur die Identität eines Computers mithilfe eines asymmetrischen Schlüsselpaars überprüft wird. Der private Schlüssel wird auf dem Computer gespeichert, auf dem SQL Server ausgeführt wird, und der öffentliche Schlüssel wird dem HGS bereitgestellt. Die Sicherheitskonfiguration des Computers wird nicht erfasst, und ein TPM 2.0-Chip ist auf dem SQL Server-Computer nicht erforderlich. Es ist wichtig, den privaten Schlüssel zu schützen, der auf dem SQL Server-Computer installiert ist. Anderenfalls kann jeder, der diesen Schlüssel erhält, die Identität eines legitimen SQL Server-Computers und der VSB-Enclave annehmen, die in SQL Server ausgeführt wird.

Generell wird Folgendes empfohlen:

  • Für physische Produktionsserver empfehlen wir, den TPM-Nachweis zu verwenden, da dieser zusätzlichen Schutz bietet.
  • Für virtuelle Produktionsserver wird empfohlen, den Hostschlüsselnachweis zu verwenden, da die meisten virtuellen Computer weder über virtuelle TPMs noch über das Feature „Sicherer Start“ verfügen. Wenn Sie einen virtuellen Computer mit erweiterter Sicherheit verwenden, wie z. B. eine lokal abgeschirmte VM, können Sie den TPM-Modus verwenden. Bei allen virtualisierten Bereitstellungen analysiert der Nachweisprozess nur Ihre VM-Umgebung und nicht die Virtualisierungsplattform unter der VM.
  • Für Dev/Test-Szenarien wird empfohlen, den Hostschlüsselnachweis zu verwenden, da dieser einfacher einzurichten ist.

Vertrauenswürdiges Modell

Im vertrauenswürdigen Modell der VBS-Enclave werden verschlüsselte Abfragen und Daten in einer softwarebasierten Enclave bewertet, um diese vom Hostbetriebssystem aus zu schützen. Der Zugriff auf diese Enclave wird durch den Hypervisor auf dieselbe Weise geschützt, wie zwei virtuelle Computer, die auf demselben Computer ausgeführt werden und dabei nicht auf den Arbeitsspeicher des jeweils anderen zugreifen können.

Damit ein Client darauf vertrauen kann, dass er mit einer legitimen Instanz von VBS kommuniziert, müssen Sie einen TPM-basierten Nachweis verwenden, der eine Stammvertrauensstellung mit der Hardware des SQL Server-Computers herstellt.

Die während des Startvorgangs erfassten TPM-Messungen enthalten den eindeutigen Identitätsschlüssel der VSB-Instanz, um sicherzustellen, dass das Integritätszertifikat nur auf genau diesem Computer gültig ist. Wenn ein TPM auf einem Computer verfügbar ist, auf dem VSB ausgeführt wird, wird der private Teil des VSB-Identitätsschlüssels außerdem durch das TPM geschützt, sodass niemand die Identität dieser VSB-Instanz annehmen kann.

Ein sicherer Start mit TPM-Nachweis ist erforderlich, um sicherzustellen, dass UEFI einen legitimen, von Microsoft signierten Bootloader geladen hat und dass keine Rootkits den Startvorgang des Hypervisors abgefangen haben. Außerdem ist ein IOMMU-Gerät standardmäßig erforderlich, um sicherzustellen, dass Enclave-Speicher von Hardwaregeräten mit direktem Speicherzugriff nicht überprüft oder geändert werden können.

Bei allen diesen Schutzmaßnahmen wird davon ausgegangen, dass der SQL Server-Computer ein physischer Computer ist. Wenn Sie den Computer mit SQL Server virtualisieren, können Sie nicht mehr garantieren, dass der Arbeitsspeicher der VM vom Hypervisor- oder Hypervisoradministrator nicht mehr überprüft werden kann. Ein Hypervisoradministrator könnte z. B. den Speicher des virtuellen Computers abbilden und Zugriff auf die Klartextversion der Abfrage und Daten in der Enklave erhalten. Gleichermaßen kann die VM, selbst wenn sie über ein virtuelles TPM verfügt, nur den Zustand und die Integrität des VM-Betriebssystems und der Startumgebung messen. Der Zustand des Hypervisors, der die VM steuert, kann nicht gemessen werden.

Auch wenn SQL Server virtualisiert ist, ist die Enklave weiterhin vor Angriffen geschützt, die innerhalb des VM-Betriebssystems ausgeführt werden. Wenn Sie Ihren Hypervisor oder Cloudanbieter als vertrauenswürdig einstufen und sich in erster Linie über Angriffe auf vertrauliche Daten von Datenbank- und Betriebssystemadministratoren Sorgen machen, kann eine virtualisierte SQL Server-Instanz Ihre Anforderungen erfüllen.

Ebenso ist der Hostschlüsselnachweis in Situationen nützlich, in denen kein TPM 2.0-Modul auf dem SQL Server-Computer installiert ist, oder in Entwicklungs- bzw. Testszenarios, bei denen die Sicherheit nicht ausschlaggebend ist. Viele der genannten Sicherheitsfunktionen, wie ein sicherer Start und ein TPM 1.2-Modul, können Sie weiterhin verwenden, um VBS und das Betriebssystem insgesamt besser zu schützen. Da es für den HGS jedoch keine Möglichkeit gibt, zu überprüfen, ob der Computer diese Einstellungen tatsächlich mit dem Hostschlüsselnachweis aktiviert hat, ist auf Clientseite nicht sichergestellt, dass der Host tatsächlich alle verfügbaren Schutzfunktionen verwendet.

Voraussetzungen

Voraussetzungen für HGS-Server

Die Computer, auf denen die Rolle „Host-Überwachungsdienst“ ausgeführt wird, müssen die folgenden Anforderungen erfüllen:

Komponente Anforderung
Betriebssystem Windows Server 2019 oder höher, Standard oder Datacenter Edition
CPU 2 Kerne (mindestens), 4 Kerne (empfohlen)
RAM 8 GB (mindestens)
NICs 2 NICs mit statischen IP-Adressen empfohlen (1 für Clusterdatenverkehr, 1 für den HGS-Dienst)

Der HGS ist aufgrund der Anzahl von Aktionen, die eine Verschlüsselung und Entschlüsselung erfordern, eine CPU-gebundene Rolle. Durch moderne Prozessoren mit Funktionen für schnellere Kryptografievorgänge, wird die Leistung des HGS erheblich gesteigert. Für Nachweisdaten müssen nur geringe Speicheranforderungen erfüllt werden, die im Bereich von 10 KB bis 1 MB pro einmaligem Computernachweis liegen.

Binden Sie die HGS-Computer nicht in eine Domäne ein, bevor Sie beginnen.

Voraussetzungen für SQL Server-Computer

Die Computer, auf denen SQL Server ausgeführt wird, müssen sowohl die Hardware- und Softwareanforderungen für die Installation von SQL Server als auch die Hyper-V-Hardwareanforderungen erfüllen.

Folgende Anforderungen müssen erfüllt sein:

  • SQL Server 2019 (15.x) oder höher
  • Windows 10, Version 1809 oder höher – Enterprise Edition, Windows 11 oder höher – Enterprise Edition, Windows Server 2019 oder höher – Datacenter Edition. Andere Editionen von Windows 10/11 und Windows Server unterstützen keinen HGS-Nachweis.
  • CPU-Unterstützung für Virtualisierungstechnologien:
    • Intel VT-x mit erweiterten Seitentabellen
    • AMD-V mit schneller Virtualisierungsindizierung
    • Wenn Sie SQL Server in einer VM ausführen:
      • Verwenden Sie in Azure eine VM-Größe der Generation 2 (empfohlen) oder eine VM-Größe der Generation 1 mit aktivierter geschachtelter Virtualisierung. Der Dokumentation zu den einzelnen VM-Größen können Sie entnehmen, welche VM-Größen der Generation 1 die geschachtelte Virtualisierung unterstützen.
      • Stellen Sie bei Hyper-V 2016 oder höher (außerhalb von Azure) sicher, dass es sich bei Ihrer VM um eine VM der Generation 2 (empfohlen) oder um eine VM der Generation 1 mit aktivierter geschachtelter Virtualisierung handelt. Weitere Informationen finden Sie unter Soll ich in Hyper-V einen virtuellen Computer der 1. oder der 2. Generation erstellen? und unter Konfigurieren der geschachtelten Virtualisierung.
      • Aktivieren Sie bei VMware vSphere 6.7 oder höher wie in der VMware-Dokumentation beschrieben die Unterstützung für virtualisierungsbasierte Sicherheit für den virtuellen Computer.
      • Andere Hypervisoren und öffentliche Clouds unterstützen möglicherweise Funktionen für eine geschachtelte Virtualisierung, die auch die Nutzung von Always Encrypted mit VSB-Enclaves ermöglichen. Informationen zur Kompatibilität und Konfigurationsanweisungen finden Sie in der Dokumentation zu Ihrer Virtualisierungslösung.
  • Wenn Sie einen TPM-Nachweis verwenden möchten, benötigen Sie einen TPM 2.0-Chip (Rev 1.16), der auf dem Server verwendet werden kann. Mit TPM 2.0-Chips (Rev 1.38) funktionieren HGS-Nachweise zurzeit nicht. Außerdem muss das TPM über ein gültiges Endorsement Key-Zertifikat verfügen.

Rollen und Verantwortlichkeiten beim Konfigurieren von Nachweisen mit dem HGS

Das Einrichten des Nachweises mit HGS umfasst das Konfigurieren von Komponenten verschiedener Typen: HGS, SQL Server-Computer, SQL Server-Instanzen und Anwendungen, die den Enklavennachweis auslösen. Die Konfiguration von Komponenten der einzelnen Typen wird von Benutzern durchgeführt, die eine der folgenden unterschiedlichen Rollen haben:

  • Der HGS-Administrator stellt den Host-Überwachungsdienst bereit, registriert SQL Server-Computer, mit dem HGS und gibt die HGS-Nachweis-URL für Administratoren von SQL Server-Computern und Clientanwendungen frei.
  • Der Administrator von SQL Server-Computern installiert Nachweisclientkomponenten, aktiviert die virtualisierungsbasierte Sicherheit (VBS) auf SQL Server-Computern, stellt dem HGS-Administrator die zum Registrieren der SQL Server-Computer mit dem HGS erforderlichen Informationen zur Verfügung, konfiguriert die Nachweis-URL auf SQL Server-Computern und überprüft, ob sich SQL Server-Computer erfolgreich beim HGS beglaubigen können.
  • Der Datenbankadministrator (DBA) konfiguriert Secure Enclaves in SQL Server-Instanzen.
  • Der Anwendungsadministrator konfiguriert die Anwendung mit der Nachweis-URL, die er vom HGS-Administrator erhalten hat.

In Produktionsumgebungen, in denen echte vertrauliche Daten verarbeitet werden, ist es wichtig, dass Ihre Organisation beim Konfigurieren des Nachweises die Rollentrennung einhält, wobei jede einzelne Rolle von unterschiedlichen Personen eingenommen wird. SQL Server-Administratoren und Datenbankadministratoren sollten insbesondere dann nicht die HGS-Server steuern, wenn das Ziel der Always Encrypted-Bereitstellung in Ihrer Organisation das Verringern der Angriffsfläche ist, indem sichergestellt wird, dass Administratoren von SQL Server-Computern und Datenbankadministratoren nicht auf vertrauliche Daten zugreifen können.

Überlegungen zu Entwicklungs- oder Testumgebungen

Wenn Sie Always Encrypted mit VBS-Enclaves in einer Entwicklungs- oder Testumgebung verwenden und keine Hochverfügbarkeit bzw. keinen sicheren Schutz des Computers benötigen, auf dem SQL Server ausgeführt wird, können Sie für eine vereinfachte Bereitstellung eines oder mehrere der folgenden Zugeständnisse machen:

  • Verwenden Sie Always Encrypted mit sicheren Enklaven ohne Nachweis - siehe Plan für Always Encrypted mit sicheren Enklaven in SQL Server ohne Nachweis.
  • Alternative Vorgehensweise:
    • Stellen Sie nur einen HGS-Knoten bereit. Auch wenn über den HGS ein Failovercluster installiert wird, müssen Sie keine zusätzlichen Knoten hinzufügen, solange keine Hochverfügbarkeit erforderlich ist.
    • Verwenden Sie den Hostschlüsselmodus anstelle des TPM-Modus, um die Einrichtung zu vereinfachen.
    • Virtualisieren Sie den HGS und/oder die SQL Server-Instanz, um physische Ressourcen zu sparen.
    • Führen Sie SSMS oder andere Tools zum Konfigurieren von Always Encrypted mit Secure Enclaves auf demselben Computer wie SQL Server aus. Dadurch werden die Spaltenhauptschlüssel auf demselben Computer wie SQL Server belassen. In einer Produktionsumgebung sollten Sie diesen Schritt daher nicht ausführen.

Nächste Schritte