Guide de migration Always Encrypted avec enclaves Intel SGX

Azure SQL Database

Important

Always Encrypted avec enclaves Intel Software Guard Extensions (Intel SGX) atteindra la fin de la période de support le 31 octobre 2027. Migrez les bases de données concernées avant cette date. Après le 31 octobre 2027, Azure déplacera automatiquement toute base de données restant sur la couche de calcul de la série DC vers une couche de calcul en série standard prise en charge (non DC) et active les enclaves de sécurité basées sur la virtualisation (VBS).

Cet article décrit les alternatives à Always Encrypted avec des enclaves Intel SGX, ainsi que les modifications requises pour chaque alternative. Examinez les considérations de sécurité avant de choisir une alternative. Les enclaves Intel SGX et VBS offrent des protections différentes contre les attaques provenant du système d’exploitation invité et de l’hôte.

Avant de commencer, assurez-vous de pouvoir afficher et modifier les serveurs logiques Azure SQL, les bases de données et les pools élastiques cibles. Avec PowerShell, installez les modules Az PowerShell et connectez-vous à Azure. Pour Azure CLI, installez l’Azure CLI et connectez-vous à Azure. Inventez les applications qui se connectent aux bases de données concernées afin de pouvoir mettre à jour leurs pilotes, chaînes de connexion et paramètres d’attestation lors de la migration.

Identifiez les bases de données qui utilisent la série DC

Identifiez toutes les bases de données autonomes et les pools élastiques qui utilisent la série DC avant de planifier la migration. Chaque base de données d’un pool élastique de la série DC est affectée.

portail Azure

1. Dans le portail Azure, accédez à votre serveur logique Azure SQL Database.
2. Sur la page Aperçu , trouvez les ressources disponibles. Ce tableau liste les bases de données sur le serveur logique.
3. Dans la colonne Niveau tarifaire, sélectionnez le filtre, puis filtrez la liste sur la série DC.
4. Enregistrez chaque base de données dans la liste filtrée. Ces bases de données utilisent des enclaves série DC et Intel SGX.
5. Répétez ces étapes pour chaque serveur logique qui héberge des bases de données SQL Azure dans votre environnement.

Powershell

Définissez $resourceGroupName et $serverName, puis exécutez le script PowerShell suivant. Le script renvoie des bases de données autonomes de la série DC et des bases de données dans des pools élastiques de la série DC sur le serveur logique spécifié.

$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

Exécutez le script sur chaque serveur logique qui héberge des bases de données Azure SQL dans votre environnement. Si le script ne renvoie aucune ligne, le serveur spécifié ne possède aucune base de données utilisant la série DC.

Azure CLI

Définissez le groupe de ressources et le nom du serveur logique.

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

Connectez-vous à Azure :

az login

Listez les bases de données autonomes utilisant la série DC :

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

Obtenez les pools élastiques de la série DC sur le serveur :

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

Pour chaque pool élastique de la série DC retourné par la commande précédente, listez ses bases de données :

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

Exécutez les commandes pour chaque serveur logique qui héberge des bases de données Azure SQL dans votre environnement.

Choisir un chemin de migration

Choisissez le parcours de migration qui répond aux exigences de sécurité et aux exigences applicatives de votre charge de travail. Utilisez la comparaison suivante comme point de départ, et consultez les directives détaillées pour le parcours sélectionné avant d’effectuer des modifications de production.

Chemin de migration	Utilisez cette option lorsque	Attestation
Azure SQL Database avec enclaves VBS	Vous souhaitez rester sur Azure SQL Database et les enclaves VBS répondent à vos exigences de sécurité.	Les enclaves de sécurité basée sur la virtualisation dans Azure SQL Database ne prennent pas en charge l’attestation.
SQL Server sur une VM Azure confidentielle avec des enclaves VBS	Vous avez besoin d’une barrière appliquée par le matériel qui aide à protéger le système d’exploitation invité contre l’accès de l’opérateur hôte.	L’attestation du Host Guardian Service (HGS) est optionnelle.

Migrer une seule base de données vers des enclaves VBS

Utilisez cette méthode pour conserver les capacités compatibles avec les enclaves dans Azure SQL Database.

1. Sélectionnez une configuration matérielle de série standard (non-DC) prise en charge qui répond aux exigences de performance et de disponibilité de votre charge de travail.
2. Déplacez la base de données vers la configuration matérielle sélectionnée.
3. Activez les enclaves VBS pour la base de données. L’activation des enclaves VBS définit la preferredEnclaveType propriété de la base de données à VBS.
4. Examinez les exigences du pilote client pour les enclaves VBS sans attestation, et mettez à jour votre pilote applicatif si nécessaire.
5. Mettez à jour chaque connexion d’application pour utiliser le protocole d’attestation d’enclave None, et supprimez l’URL Microsoft Azure Attestation. Les mots-clés exacts de la chaîne de connexion dépendent du pilote client.
6. Complétez la validation post-migration.

Migrer un pool élastique vers des enclaves VBS

Toutes les bases de données d’un pool élastique héritent de la configuration enclave du pool. Utilisez ce chemin pour conserver les capacités enclaves des bases de données dans un pool élastique Azure SQL.

1. Sélectionnez une configuration de série standard prise en charge (non-DC) qui répond aux exigences de performance et de disponibilité du pool. Pour des informations sur la modification de la configuration du pool, consultez Gérer un pool élastique dans Azure SQL Database.
2. Activez les enclaves VBS pour le pool élastique. Activer les enclaves VBS fixe la preferredEnclaveType propriété du pool à VBS.
3. Examinez les exigences relatives aux pilotes côté client pour les enclaves VBS sans attestation et mettez à jour les pilotes de votre application si nécessaire.
4. Mettez à jour chaque connexion d’application pour utiliser le protocole d’attestation de l’enclave None, et supprimez l’URL Microsoft Azure Attestation. Les mots-clés exacts de la chaîne de connexion dépendent du pilote client.
5. Complétez la validation post-migration pour chaque base de données du pool.

Migration vers SQL Server sur une machine virtuelle confidentielle Azure

Considérez cette voie si vous avez besoin d’une frontière imposée matériellement qui aide à protéger le système d’exploitation invité contre l’accès de l’opérateur hôte. Les machines virtuelles confidentielles Azure chiffrent la mémoire des machines virtuelles et offrent des propriétés de sécurité différentes de celles des enclaves Intel SGX. Évaluez ces différences par rapport à vos exigences de sécurité et de conformité.

1. Déployer SQL Server sur une machine virtuelle confidentielle Azure.
2. Choisissez si vous souhaitez utiliser l’attestation d’enclave :
   • Planification de Always Encrypted avec des enclaves sécurisées dans SQL Server sans attestation.
   • Planifier l’attestation avec le Service Guardian hôte.
3. Configurez Always Encrypted avec des enclaves VBS sur l’instance SQL Server en suivant les instructions correspondant à l’option d’attestation que vous avez sélectionnée.
4. Planifiez la migration de votre base de données, de vos identifiants, de vos clés, de la connectivité des applications et des ressources dépendantes.
5. Choisissez une option de migration de données basée sur la taille de votre base de données, la configuration réseau, les temps d’arrêt et les objets de base de données pris en charge. Les options courantes sont les suivantes :
   • Azure Data Factory : Utilisez une activité de copie avec le connecteur Azure SQL Database comme source et le connecteur SQL Server comme récepteur. ADF traite les colonnes Always Encrypted comme des valeurs binaires ou chiffrées et les déplace sans avoir besoin d’accéder à la Column Master Key.
   • Smart Bulk Copy : Utilisez Smart Bulk Copy pour copier le schéma et les données d’Azure SQL Database vers SQL Server. Passez en revue les prérequis et les limitations de l’outil avant la migration.
   • BACPAC : envisagez un BACPAC pour les petites bases de données dont les objets sont pris en charge par des applications de couche Données. Les données Always Encrypted restent chiffrées lors de l’exportation et de l’importation, et le BACPAC inclut les métadonnées des clés Always Encrypted. Pour plus d’informations, voir Exporter et importer des bases de données en utilisant Always Encrypted, Exporter un fichier BACPAC, et Importer un fichier BACPAC pour créer une nouvelle base de données.
6. Mettre à jour les chaînes de connexion des applications pour l’instance SQL Server et l’option d’attestation sélectionnée.
7. Complétez la validation post-migration.

Valider la migration

Avant de mettre la charge de travail en production :

1. Vérifiez que les applications peuvent se connecter avec Always Encrypted activé.
2. Exécutez des requêtes représentatives utilisant des colonnes chiffrées, y compris celles nécessitant des calculs d’enclave si l’environnement cible utilise des enclaves sécurisées.
3. Vérifiez que les opérations d’insertion, de mise à jour, de suppression et d’indexation sur les colonnes chiffrées se comportent comme prévu.
4. Testez les performances de l’application et ajustez la configuration cible des ressources de calcul si nécessaire.
5. Testez la continuité de votre activité, la reprise après sinistre et les procédures de basculement. Toutes les répliques de base de données doivent prendre en charge des enclaves sécurisées si la charge de travail utilise des opérations activées par l’enclave.
6. Surveillez l’application pour détecter les erreurs d’enclave, d’attestation et de requête avant de finaliser le changement.

Contenu connexe

• Documentation sur la fonctionnalité Always Encrypted avec des enclaves sécurisées
• Didacticiel : bien démarrer en utilisant Always Encrypted avec enclaves sécurisées
• Configurer et utiliser Always Encrypted avec enclaves sécurisées