Plan for Always Encrypted with secure enclaves in SQL Server without attestation

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

Das Einrichten von Always Encrypted mit sicheren Enklaven in SQL Server ohne Nachweis bietet eine einfache Möglichkeit, mit dem Feature zu beginnen. Wenn Sie jedoch sichere Enklaven in einer Produktionsumgebung verwenden, sollten Sie bedenken, dass der Schutz vor Betriebssystemadministratoren ohne Nachweis reduziert wird. Wenn beispielsweise ein böswilliger Betriebssystemadministrator die SQL Server-Bibliothek manipuliert hat, die innerhalb der Enklave ausgeführt wird, kann eine Clientanwendung sie nicht erkennen. Wenn Sie sich Gedanken über solche Angriffe machen, sollten Sie den Nachweis mit dem Host Guardian Service einrichten. Weitere Informationen finden Sie unter Plan for Host Guardian Service attestation.

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.

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.

Voraussetzungen

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 oder höher oder Windows Server 2019 oder höher.

  • 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 auf Hyper-V 2016 oder höher (außerhalb von Azure) sicher, dass Ihre VM eine VM der Generation 2 ist (empfohlen) oder dass es sich um eine VM der Generation 1 handelt, auf der geschachtelte Virtualisierung aktiviert ist. 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.
  • Virtualisierungsbasierte Sicherheit (VBS) muss aktiviert und ausgeführt werden.

Toolanforderungen

Clienttreiberanforderungen

Informationen zu Clienttreiberversionen, die die Verwendung sicherer Enklaven ohne Nachweis unterstützen, finden Sie unter Entwickeln von Anwendungen mit Always Encrypted with secure enclaves.

Überprüfen, ob VBS ausgeführt wird

Hinweis

Dieser Schritt sollte vom SQL Server-Computeradministrator ausgeführt werden.

Um zu überprüfen, ob VBS ausgeführt wird, öffnen Sie das Tool Systeminformationen, indem Sie msinfo32.exe ausführen und die Virtualization-based security-Elemente gegen Ende der Systemzusammenfassung suchen.

Screenshot of System Information showing virtualization-based security status and configuration.

Das erste zu prüfende Element ist Virtualization-based security, das die folgenden drei Werte aufweisen kann:

  • Running bedeutet, dass VBS ordnungsgemäß konfiguriert ist und erfolgreich gestartet werden konnte.
  • Enabled but not running bedeutet, dass VBS für die Ausführung konfiguriert ist, die Hardware jedoch nicht den Mindestanforderungen an die Sicherheit genügt, die für die Ausführung von VBS gelten. Möglicherweise müssen Sie die Konfiguration der Hardware in BIOS oder UEFI ändern, um optionale Prozessorfeatures wie ein IOMMU zu aktivieren. Wenn die Hardware die erforderlichen Features tatsächlich nicht unterstützt, müssen Sie möglicherweise die VBS-Sicherheitsanforderungen herabsetzen. Setzen Sie das Lesen dieses Abschnitts fort, um mehr zu erfahren.
  • Not enabled bedeutet, dass VBS nicht für die Ausführung konfiguriert ist.

Aktivieren von VBS

Wenn VBS nicht aktiviert ist, führen Sie den folgenden Befehl in einer PowerShell-Konsole mit erhöhten Rechten aus, um ihn zu aktivieren.

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard -Name EnableVirtualizationBasedSecurity -Value 1

Starten Sie nach dem Ändern der Registrierung den SQL Server-Computer neu, und überprüfen Sie, ob VBS erneut ausgeführt wird.

Weitere Möglichkeiten zum Aktivieren von VBS finden Sie unter Aktivieren des virtualisierungsbasierten Schutzes der Codeintegrität.

Ausführen von VBS, wenn sie nicht ausgeführt wird

Wenn VBS nicht auf dem Computer ausgeführt wird, überprüfen Sie Virtualization-based security die Eigenschaften. Vergleichen Sie die Werte im Element Required Security Properties mit den Werten im Element Available Security Properties. Die erforderlichen Eigenschaften müssen sich mit den verfügbaren Sicherheitseigenschaften für VSB decken oder eine Teilmenge von ihnen darstellen, damit VBS ausgeführt werden kann. Die Sicherheitseigenschaften haben die folgende Bedeutung:

  • Base virtualization support ist immer erforderlich, da es die Mindestanforderungen an die Hardwarefeatures darstellt, die zum Ausführen eines Hypervisors erforderlich sind.
  • Secure Boot wird empfohlen, aber nicht erforderlich. Secure Boot schützt vor Rootkits, da es einen von Microsoft signierten Bootloader vorschreibt, der unmittelbar nach der UEFI-Initialisierung ausgeführt werden muss.
  • DMA Protection wird empfohlen, aber nicht erforderlich. Der DMA-Schutz verwendet IOMMU, um VBS und Enklavenspeicher vor Angriffen über direkten Speicherzugriff zu schützen. In einer Produktionsumgebung sollten Sie stets Computer mit DMA-Schutz verwenden. In einer Entwicklungs- oder Testumgebung ist es in Ordnung, die Anforderung für den DMA-Schutz zu entfernen. Wenn die SQL Server-Instanz virtualisiert ist, stehen Ihnen wahrscheinlich kein DMA-Schutz zur Verfügung und müssen die Anforderung für die Ausführung von VBS entfernen.

Bevor Sie die erforderlichen Sicherheitsfeatures für VBS herabsetzen, wenden Sie sich an Ihren OEM oder Clouddienstanbieter, um zu überprüfen, ob es eine Möglichkeit gibt, die fehlenden Plattformanforderungen in UEFI oder BIOS zu aktivieren (z. B. durch Aktivieren von „Sicherer Start“, Intel VT-d oder AMD IOV).

Führen Sie den folgenden Befehl in einer PowerShell-Konsole mit erhöhten Rechten aus, um die erforderlichen Plattformsicherheitsfeatures für VBS zu ändern:

# Value 1 = Only Secure Boot is required
# Value 2 = Only DMA protection is required (default configuration)
# Value 3 = Both Secure Boot and DMA protection are required
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard -Name RequirePlatformSecurityFeatures -Value 1

Starten Sie nach dem Ändern der Registrierung den SQL Server-Computer neu, und überprüfen Sie, ob VBS erneut ausgeführt wird.

Wenn der Computer von Ihrem Unternehmen verwaltet wird, können Gruppenrichtlinien oder Microsoft Endpoint Manager alle Änderungen außer Kraft setzen, die Sie nach dem Neustart an diesen Registrierungsschlüsseln vornehmen. Wenden Sie sich an Ihren IT-Helpdesk, um zu erfahren, ob sie Richtlinien zur Verwaltung Ihrer VBS-Konfiguration bereitstellen.

Nächste Schritte