Planen des Nachweises des Host-Überwachungsdiensts

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 virtualisierungsbasierte Sicherheit (VBS) Enklaven (auch als virtual Secure Mode oder VSM enklaven bezeichnet) – eine softwarebasierte Technologie, die auf 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, indem ein Drittanbieter eingeführt wird, der die Identität (und optional die Konfiguration) des SQL Server-Computers überprüfen kann. Bevor SQL Server eine Enklave zum Ausführen einer Abfrage verwenden kann, muss sie dem Nachweisdienst Informationen über seine Betriebsumgebung bereitstellen, um ein Integritätszertifikat abzurufen. 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 for Always Encrypted with secure enklaves 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 stammen. 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. In einer typischen Bereitstellung gibt es 1-3 HGS-Server, mindestens einen Computer mit SQL Server und einen Computer, auf dem eine Clientanwendung oder -tools ausgeführt wird, 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önnen sie den Nachweisdienst so konfigurieren, dass ein bösartiger Computer SQL Server ausführen kann, sodass sie die VBS-Enklave kompromittieren können.

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 ja, sollte er eine andere Domäne sein als der vom 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 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 Computer, auf dem SQL Server ausgeführt wird, versucht, mit HGS zu bestätigen, fragt er zuerst HGS, wie er nachweist. HGS unterstützt zwei Nachweismodi für die Verwendung mit SQL Server:

Nachweismodus	Erläuterung
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. Für die Computer, auf denen SQL Server ausgeführt wird, muss TPM Version 2.0 installiert sein. 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 für 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 die Verwendung des TPM-Nachweises für die bereitgestellten zusätzlichen Sicherheiten.
• 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 vertrauen kann, dass er mit einer legitimen Instanz von VBS spricht, müssen Sie einen TPM-basierten Nachweis verwenden, der einen Hardwarestamm der Vertrauensstellung auf dem SQL Server-Computer festlegt.

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 diesen Schutzmaßnahmen wird vorausgesetzt, dass der Computer, auf dem SQL Server ausgeführt wird, 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.

Selbst wenn SQL Server virtualisiert wird, ist die Enklave jedoch weiterhin vor Angriffen geschützt, die innerhalb des VM-Betriebssystems stammen. Wenn Sie Ihrem Hypervisor oder Cloudanbieter vertrauen und sich in erster Linie Sorgen um Datenbankadministrator- und Betriebssystemadministratorangriffe auf vertrauliche Daten machen, erfüllt ein virtualisierter SQL Server Möglicherweise Ihre Anforderungen.

Ebenso ist der Hostschlüsselnachweis in Situationen hilfreich, in denen ein TPM 2.0-Modul nicht auf dem Computer installiert ist, auf dem SQL Server ausgeführt wird, oder in Entwicklungs-/Testszenarien, in denen Sicherheit nicht von größter Bedeutung ist. Sie können weiterhin viele der erwähnten Sicherheitsfeatures verwenden, einschließlich sicherem Start und einem TPM 1.2-Modul, 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 Anforderungen 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 Nachweiss 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:

• HGS-Administrator – stellt HGS bereit, registriert SQL Server-Computer mit HGS und gibt die HGS-Nachweis-URL für SQL Server-Computeradministratoren und Clientanwendungsadministratoren frei.
• SQL Server-Computeradministrator – installiert Clientkomponenten für den Nachweis, aktiviert VBS auf SQL Server-Computern, stellt dem HGS-Administrator die erforderlichen Informationen bereit, um die SQL Server-Computer mit HGS zu registrieren, konfiguriert die Nachweis-URL auf SQL Server-Computern und überprüft, ob SQL Server-Computer erfolgreich mit HGS nachweisen können.
• DBA – konfiguriert sichere Enklaven 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 zur Entwicklungs- oder Testumgebung

Wenn Sie Always Encrypted with VBS-Enklaven in einer Entwicklungs- oder Testumgebung verwenden und keine hohe Verfügbarkeit oder einen starken Schutz des Computers erfordern, auf dem SQL Server ausgeführt wird, können Sie eine oder alle folgenden Konzessionen für eine vereinfachte Bereitstellung vornehmen:

• Verwenden Sie Always Encrypted mit sicheren Enklaven ohne Nachweis - siehe Plan for Always Encrypted with secure enclaves in SQL Server without attestation.
• Alternativ:
  • Stellen Sie nur einen HGS-Knoten bereit. Obwohl HGS einen Failovercluster installiert, müssen Sie keine zusätzlichen Knoten hinzufügen, wenn hohe Verfügbarkeit kein Problem darstellt.
  • Verwenden Sie den Hostschlüsselmodus anstelle des TPM-Modus, um die Einrichtung zu vereinfachen.
  • Virtualisieren Sie HGS und/oder sql Server, um physische Ressourcen zu sparen.
  • Führen Sie SSMS oder andere Tools zum Konfigurieren von Always Encrypted mit sicheren Enklaven auf demselben Computer wie SQL Server aus. Dadurch bleiben die Spaltenmasterschlüssel auf demselben Computer wie SQL Server erhalten, sodass dies in einer Produktionsumgebung nicht der Fall ist.

Nächste Schritte

• Bereitstellen des Host Guardian-Diensts für SQL Server