Immer verschlüsselt mit Intel SGX Enklaven-Migrationsleitfaden

Azure SQL-Datenbank

Dieser Artikel beschreibt die Alternativen zu Always Encrypted with Intel SGX Enklaven und die für jede Alternative erforderlichen Änderungen. Überprüfen Sie die Sicherheitsaspekte , bevor Sie eine Alternative wählen. Intel-SGX- und VBS-Enklaven bieten unterschiedliche Schutzmaßnahmen gegen Angriffe, die vom Gastbetriebssystem und dem Host ausgehen.

Bevor Sie beginnen, bestätigen Sie, dass Sie die Ziel-Azure SQL-Logikserver, Datenbanken und Elastic Pools ansehen und anpassen können. Für PowerShell installieren Sie die Az PowerShell-Module und melden Sie sich bei Azure an. Für die Azure CLI installieren Sie die Azure CLI und melden Sie sich bei Azure an. Inventarisieren Sie die Anwendungen, die sich mit betroffenen Datenbanken verbinden, damit Sie deren Treiber, Verbindungsstrings und Attestationseinstellungen während der Migration aktualisieren können.

Datenbanken identifizieren, die DC-Serien verwenden

Identifizieren Sie alle eigenständigen Datenbanken und elastischen Pools, die DC-Series verwenden, bevor Sie die Migration planen. Jede Datenbank in einem elastischen Pool der DC-Serie ist betroffen.

$resourceGroupName = "<resource-group-name>"
$serverName = "<server-name>"

$databases = Get-AzSqlDatabase `
	-ResourceGroupName $resourceGroupName `
	-ServerName $serverName

$standaloneDatabases = $databases | Where-Object {
	-not $_.ElasticPoolName -and
	$_.CurrentServiceObjectiveName -match '(^|_)DC(_|$)'
}

$dcPoolNames = Get-AzSqlElasticPool `
	-ResourceGroupName $resourceGroupName `
	-ServerName $serverName | ForEach-Object {
		$poolResource = Get-AzResource -ResourceId $_.ResourceId -ExpandProperties
		if ($poolResource.Sku.Family -eq 'DC') {
			$_.ElasticPoolName
		}
	}

$pooledDatabases = $databases | Where-Object {
	$_.ElasticPoolName -in $dcPoolNames
}

@($standaloneDatabases) + @($pooledDatabases) |
	Select-Object DatabaseName, ElasticPoolName, Edition, CurrentServiceObjectiveName

resourceGroupName="<resource-group-name>"
serverName="<server-name>"

az login

az sql db list \
    --resource-group $resourceGroupName \
    --server $serverName \
    --query "[?elasticPoolName == null && currentSku.family == 'DC'].{Database:name, ServiceObjective:currentServiceObjectiveName}" \
    --output table

dcPoolNames=$(az sql elastic-pool list \
    --resource-group $resourceGroupName \
    --server $serverName \
    --query "[?sku.family == 'DC'].name" \
    --output tsv)

for poolName in $dcPoolNames; do
    az sql elastic-pool list-dbs \
        --resource-group $resourceGroupName \
        --server $serverName \
        --name $poolName \
        --query "[].{PoolName:elasticPoolName, Database:name}" \
        --output table
done

Auswählen eines Migrationspfads

Wählen Sie den Migrationsweg, der den Sicherheits- und Anwendungsanforderungen Ihrer Arbeitslast entspricht. Verwenden Sie den folgenden Vergleich als Ausgangspunkt und prüfen Sie die detaillierten Richtlinien für den ausgewählten Pfad, bevor Sie Produktionsänderungen vornehmen.

Migrieren einer einzelnen Datenbank in VBS-Enklaven

Verwenden Sie diesen Pfad, um enklavenfähige Funktionen in Azure SQL-Datenbank beizubehalten.

1. Wählen Sie eine Hardwarekonfiguration einer unterstützten Standardserie (nicht DC), die die Leistungs- und Verfügbarkeitsanforderungen Ihrer Workload erfüllt.
2. Verschieben Sie die Datenbank auf die ausgewählte Hardwarekonfiguration.
3. Aktivieren Sie VBS-Enklaven für die Datenbank. Das Aktivieren von VBS enclaves setzt die Datenbankeigenschaft preferredEnclaveType auf VBS.
4. Überprüfen Sie die Clienttreiberanforderungen für VBS-Enklaven ohne Nachweis und aktualisieren Sie gegebenenfalls Ihren Anwendungstreiber.
5. Aktualisieren Sie jede Anwendungsverbindung so, dass sie das None Attestierungsprotokoll für Enklaven verwendet, und entfernen Sie die Microsoft Azure Attestation-URL. Die genauen Verbindungsstring-Schlüsselwörter hängen vom Client-Treiber ab.
6. Schließen Sie die Validierung nach der Migration ab.

Migriere einen elastischen Pool zu VBS-Enklaven

Alle Datenbanken in einem elastischen Pool übernehmen die Enklavenkonfiguration des Pools. Nutzen Sie diesen Weg, um enklavenfähige Funktionen für Datenbanken in einem elastischen Azure SQL-Pool zu erhalten.

1. Wählen Sie eine unterstützte Standardserienkonfiguration (nicht DC), die den Leistungs- und Verfügbarkeitsanforderungen des Pools entspricht. Informationen zum Ändern der Poolkonfiguration finden Sie unter Verwalten eines elastischen Pools in Azure SQL-Datenbank.
2. VBS-Enklaven für den elastischen Pool aktivieren. Das Aktivieren von VBS-Enklaven setzt die preferredEnclaveType Pool-Eigenschaft auf VBS.
3. Überprüfen Sie die Client-Treiberanforderungen für VBS-Enklaven ohne Bestätigung und aktualisieren Sie gegebenenfalls Ihre Anwendungstreiber.
4. Aktualisieren Sie jede Anwendungsverbindung, um das None Enclave-Attestationsprotokoll zu verwenden, und entfernen Sie die Microsoft Azure Attestation URL. Die genauen Verbindungsstring-Schlüsselwörter hängen vom Client-Treiber ab.
5. Führen Sie die Validierung nach der Migration für jede Datenbank im Pool durch.

Migration zu SQL Server auf einer Azure Confidential VM

Wählen Sie diese Option, wenn Sie eine hardwaregestützte Isolationsgrenze benötigen, die zum Schutz des Gastbetriebssystems vor Zugriffen durch den Hostbetreiber beiträgt. Azure Confidential VMs verschlüsseln VM-Speicher und bieten andere Sicherheitseigenschaften als Intel SGX-Enklaven. Vergleichen Sie diese Unterschiede mit Ihren Sicherheits- und Compliance-Anforderungen.

1. Deploye SQL Server auf eine Azure Confidential VM.
2. Entscheiden Sie, ob Sie Enklave-Attestation verwenden:
   • Plane für Always Encrypted mit sicheren Enklaven in SQL Server ohne Attestation.
   • Planung der Bestätigung für den Host Guardian Service
3. Konfigurieren Sie Always Encrypted mit VBS-Enklaven auf der SQL Server-Instanz, indem Sie den Anweisungen für die von Ihnen gewählte Attestationsoption folgen.
4. Planen Sie die Migration Ihrer Datenbank, Ihrer Logins, Schlüssel, der Anwendungskonnektivität und der abhängigen Ressourcen.
5. Wählen Sie eine Option zur Datenmigration basierend auf Ihrer Datenbankgröße, Netzwerkkonfiguration, Ausfallzeitanforderungen und unterstützten Datenbankobjekten. Gängige Optionen sind:
   • Azure Data Factory: Verwenden Sie eine Kopieraktivität mit dem Azure SQL-Datenbank Connector als Quelle und dem SQL Server Connector als Sink. Die ADF behandelt die Always Encrypted Columns als Binär- oder Chiffretextwerte und verschoben sie, ohne Zugriff auf den Column Master Key zu benötigen.
   • Smart Bulk Copy: Verwenden Sie Smart Bulk Copy, um Schemata und Daten von der Azure SQL-Datenbank auf den SQL Server zu kopieren. Überprüfen Sie vor der Migration die Voraussetzungen und Einschränkungen des Tools.
   • BACPAC: Ziehen Sie für kleinere Datenbanken, deren Objekte von Datenschichtanwendungen unterstützt werden, ein BACPAC in Betracht. Always Encryption-Daten bleiben während des Exports und Imports verschlüsselt, und das BACPAC enthält die Always Encrypted Key-Metadaten. Weitere Informationen finden Sie unter Datenbanken exportieren und importieren mit Always Encrypted, eine BACPAC-Datei exportieren und eine BACPAC-Datei importieren, um eine neue Datenbank zu erstellen.
6. Aktualisieren Sie die Anwendungsverbindungsstrings für die SQL Server-Instanz und die ausgewählte Attestationsoption.
7. Schließen Sie die Validierung nach der Migration durch.

Überprüfen der Migration

Bevor du den Workload in die Produktion verlagerst:

1. Überprüfen Sie, ob Anwendungen sich mit aktiviertem Always Encrypted verbinden können.
2. Führen Sie repräsentative Abfragen aus, die verschlüsselte Spalten verwenden, einschließlich Abfragen, die Enklavenberechnungen erfordern, wenn die Zielumgebung sichere Enklaven verwendet.
3. Überprüfen Sie, ob Einfüge, Aktualisierungen, Löschungen und Indexoperationen auf verschlüsselten Spalten wie erwartet funktionieren.
4. Teste die Anwendungsleistung und passe die Zielrechenkonfiguration bei Bedarf an.
5. Testen Sie Ihre Geschäftskontinuität, Katastrophenwiederherstellung und Failover-Verfahren. Alle Datenbank-Replikate müssen sichere Enklaven unterstützen, wenn die Arbeitslast enklaven-aktivierte Operationen verwendet.
6. Überwachen Sie die Anwendung auf Enklaven-, Attestations- und Abfragefehler, bevor Sie das Cutover abschließen.

Verwandte Inhalte

• Dokumentation zu Always Encrypted mit Secure Enclaves
• Tutorial: Erste Schritte mit Always Encrypted unter Verwendung von Secure Enclaves
• Konfigurieren und Verwenden von Always Encrypted mit Secure Enclaves