Chiffrement transparent des données (TDE) géré par le client pour Azure Synapse Analytics

Application : pools SQL dédiés Azure Synapse Analytics (anciennement SQL DW)

Tip

Microsoft Fabric Data Warehouse est un entrepôt relationnel à l’échelle de l’entreprise sur une base de lac de données, avec une architecture future, une IA intégrée et de nouvelles fonctionnalités. Si vous débutez avec l'entreposage de données, commencez par Fabric Data Warehouse. Les charges de travail de pool SQL existantes dédicées peuvent être mises à niveau vers Fabric pour accéder à de nouvelles fonctionnalités dans la science des données, l’analytique en temps réel et la création de rapports.

Le chiffrement transparent des données (TDE) avec clé gérée par le client (CMK) permet un scénario Bring Your Own Key (BYOK) pour la protection des données au repos, et permet aux organisations de mettre en œuvre la séparation des tâches dans la gestion des clés et des données. En utilisant un TDE géré par le client, vous prenez la responsabilité et avez le contrôle total de la gestion du cycle de vie des clés (création, importation, rotation, suppression des clés), des autorisations d’utilisation des clés et de l’audit des opérations sur les clés.

Dans ce scénario, le protecteur Transparent Data Encryption (TDE) est une clé gérée par le client qui sécurise la clé de chiffrement de la base de données (DEK). Vous stockez le protecteur TDE soit dans Azure Key Vault, soit dans Azure Key Vault Managed HSM, qui sont des services sécurisés de gestion de clés basés sur le cloud conçus pour une haute disponibilité et une grande scalabilité. Les deux services prennent en charge les clés cryptographiques protégées par du matériel validé FIPS 140-2 : Azure Key Vault prend en charge FIPS 140-2 Niveau 2, et Azure Key Vault Managed HSM prend en charge FIPS 140-2 Niveau 3. Les deux services prennent également en charge les types de clés asymétriques et symétriques, et les algorithmes et l’utilisation pris en charge dépendent du modèle de déploiement TDE. Vous pouvez générer la clé dans le service, l’importer ou la transférer en toute sécurité depuis des HSM sur site. L’accès direct aux clés est restreint, de sorte que les services autorisés effectuent des opérations cryptographiques sans exposer le matériel de la clé.

Note

Cet article traite des pools SQL dédiés autonomes (anciennement SQL DW).

  • Pour les pools SQL dédiés Azure Synapse Analytics (anciennement SQL DW), définissez le protecteur TDE au niveau du serveur. Toutes les bases de données chiffrées associées à ce serveur héritent du protecteur de TDE.
  • Chiffrez les données dans des pools SQL dédiés et des pools SQL serverless dans un espace de travail Synapse en utilisant la clé gérée par le client configurée au niveau de l’espace de travail. Pour plus d’informations sur le chiffrement transparent des données pour les pools SQL dédiés dans les espaces de travail Synapse, consultez chiffrement Azure Synapse Analytics.

Clé gérée par le client (CMK) et apportez votre propre clé (BYOK)

Dans cet article, les termes clés gérées par le client (CMK) et BYOK (Bring Your Own Key) sont utilisés de manière interchangeable, mais ils représentent certaines différences.

  • Clé gérée par le client (CMK) - Vous gérez le cycle de vie des clés, y compris la création, la rotation et la suppression des clés. Stockez la clé dans Azure Key Vault ou Azure Managed HSM et utilisez-la pour le chiffrement de la clé de chiffrement de la base de données (DEK).

  • Apportez votre propre clé (BYOK) - Vous transférez ou importez en toute sécurité votre propre clé depuis un module de sécurité matérielle (HSM) sur site dans Azure Key Vault. Ces clés importées peuvent être utilisées comme toute autre clé dans Azure Key Vault, notamment en tant que clé gérée par le client pour le chiffrement de la clé DEK. Pour plus d'informations, consultez Importer des clés protégées par HSM vers un HSM managé (BYOK).

Avantages de TDE managé par le client

La TDE gérée par le client offre les avantages suivants :

  • Contrôle complet et précis de l’utilisation et de la gestion du protecteur TDE.

  • Transparence de l’utilisation du protecteur TDE.

  • Possibilité d’implémenter la séparation des tâches dans la gestion des clés et des données au sein de l’organisation.

  • L’administrateur Azure Key Vault peut révoquer les autorisations d’accès aux clés pour rendre la base de données chiffrée inaccessible.

  • Gestion centralisée des clés dans Azure Key Vault.

  • Une plus grande confiance de vos clients finaux, étant donné qu’Azure Key Vault est conçu de telle sorte que Microsoft ne puisse pas voir ni extraire des clés de chiffrement.

Important

Pour ceux qui utilisent un TDE géré par service qui souhaitent commencer à utiliser un TDE géré par le client, les données restent chiffrées pendant le processus de bascule, et il n’y a ni interruption ni re-chiffrement des fichiers de base de données. Le basculement d’une clé managée par le service à une clé managée par le client nécessite uniquement de rechiffrement de la clé de chiffrement (DEK), une opération rapide et en ligne.

Autorisations pour configurer le TDE géré par le client dans Azure Key Vault

Sélectionnez le type d’Azure Key Vault que vous souhaitez utiliser.

Pour que le serveur logique SQL dans Azure utilise le protecteur TDE stocké dans Azure Key Vault afin de chiffrer le DEK, le Key Vault Administrator doit accorder au serveur des droits d’accès à l’aide de son identité Microsoft Entra unique. L’identité du serveur peut être une identité managée affectée par le système ou une identité managée affectée par l’utilisateur attribuée au serveur. Il existe deux modèles d’accès pour accorder au serveur l’accès au coffre de clés :

  • Contrôle d’accès en fonction du rôle Azure (RBAC) - utilisez Azure RBAC pour accorder à un utilisateur, un groupe ou un accès d’application au coffre de clés. Cette méthode est recommandée pour sa flexibilité et sa granularité. L’identité du serveur nécessite le rôle Key Vault Crypto Service Encryption User pour utiliser la clé pour les opérations de chiffrement et de déchiffrement.

  • Stratégie d'accès au coffre de clés : utilisez la stratégie d'accès au coffre de clés pour accorder au serveur l’accès au coffre de clés. Cette méthode est plus simple et plus directe, mais moins flexible. L’identité du serveur nécessite les permissions suivantes sur le coffre à clés :

    • get : pour récupérer la partie publique et les propriétés de la clé dans Azure Key Vault
    • wrapKey : pour pouvoir protéger (chiffrer) la clé de chiffrement
    • unwrapKey : pour pouvoir ôter la protection (déchiffrer) la clé de chiffrement

Dans le menu Configuration de l’accès du portail Azure du coffre de clés, vous avez la possibilité de sélectionner le Contrôle d’accès en fonction du rôle Azure ou la Stratégie d'accès au coffre. Pour des instructions étape par étape sur la configuration d’une configuration d’accès à Azure Key Vault pour TDE, voir Configurer SQL Server TDE Extensible Key Management en utilisant Azure Key Vault. Pour plus d'informations sur les modèles d’accès, consultez Sécurité Azure Key Vault.

Un Administrateur du coffre de clés peut également activer la journalisation des événements d’audit de coffre de clés, afin qu’ils puissent être audités ultérieurement.

Lorsque vous configurez un serveur pour utiliser un protecteur TDE d’Azure Key Vault, le serveur envoie le DEK de chaque base de données activée pour TDE au key vault pour chiffrement. Le coffre-fort de clés renvoie le DEK chiffré, que le serveur stocke dans la base de données utilisateur.

Si nécessaire, le serveur envoie le DEK protégé au coffre de clés pour le déchiffrement.

Les auditeurs peuvent utiliser Azure Monitor pour examiner les journaux d’événements AuditEvent du coffre-fort si la journalisation est activée.

Note

Il peut falloir environ 10 minutes avant que les changements d’autorisation prennent effet pour le coffre de clés. Cette période inclut la révocation des autorisations d’accès au protecteur TDE dans AKV, et les utilisateurs peuvent toujours avoir des permissions d’accès.

Exigences pour configurer le TDE géré par le client dans Azure Key Vault

  • Activez les fonctions de suppression réversible et de protection contre la suppression définitive sur Azure Key Vault. Cette configuration aide à prévenir la suppression accidentelle ou malveillante du coffre de clés ou des clés, ce qui peut faire passer la base de données à l’état Inaccessible. Lorsque vous configurez le protecteur TDE sur un serveur existant ou lors de la création du serveur, Azure SQL valide que le coffre de clés que vous utilisez a activé la protection contre la suppression réversible et la purge. Si la suppression réversible et la protection contre la suppression définitive ne sont pas activées sur le coffre de clés, la configuration du protecteur TDE échoue avec une erreur. Dans ce cas, activez la protection contre la suppression réversible et la purge sur le coffre de clés, puis effectuez la configuration du protecteur TDE.

  • Lorsque vous utilisez un pare-feu avec Azure Key Vault, vous devez activer l’option Autoriser les services Microsoft approuvés à contourner le pare-feu, sauf si vous utilisez des points de terminaison privés pour Azure Key Vault. Pour plus d’informations, consultez Configurer les pare-feux et réseaux virtuels d’Azure Key Vault.

Exigences clés pour la configuration du protecteur TDE

Transparent Data Encryption avec des clés gérées par le client utilise une clé externe, appelée protecteur TDE, stockée dans Azure Key Vault pour protéger la clé de chiffrement de la base de données (DEK).

Les conditions suivantes s’appliquent.

Types et tailles de clés pris en charge

Le protecteur TDE peut utiliser des clés asymétriques stockées dans Azure Key Vault. Les tailles de clés prises en charge sont 2 048 bits et 3 072 bits.

Conditions d’état et de validité des clés

  • Si vous spécifiez une date d’activation de la clé, fixez-la à une date/heure antérieure.
  • Si vous spécifiez une date d’expiration de la clé, fixez-la à une date et une heure futures.
  • La clé doit être dans l’état activé.

Conditions requises pour l’importation de clés

Si vous importez une clé existante dans Azure Key Vault, fournissez la clé dans l’un des formats supportés suivants :

  • .pfx
  • .byok
  • .backup

Recommandations pour configurer le TDE géré par le client dans Azure Key Vault

Pour maintenir la haute disponibilité et éviter les problèmes de limitation, suivez ces instructions par abonnement :

  • Pour garantir des performances et une fiabilité optimales, utilisez un Azure Key Vault dédié pour Azure SQL. Ne partagez pas ce coffre-fort à clés avec d’autres services. Si le coffre-fort de clés est soumis à une charge importante en raison d’une utilisation partagée ou d’opérations excessives de clés, cela peut nuire aux performances de la base de données, notamment lors de l’accès à la clé de chiffrement. Azure Key Vault applique des limites de limitation. Lorsque ces limites sont dépassées, les opérations peuvent être retardées ou défaillantes. Ce risque est maximal lors des basculements de serveur, qui déclenchent des opérations critiques pour chaque base de données sur le serveur.

    Pour plus d’informations sur le comportement de limitation, consultez les directives de limitation d’Azure Key Vault.

    • Le nombre de bases de données Hyperscale que vous pouvez associer à un seul Azure Key Vault dépend du nombre de serveurs de pages. Chaque serveur de pages est lié à un fichier de données logique. Pour trouver le nombre de serveurs de pages, lancez la requête suivante.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      N'associez pas plus de 500 serveurs de pages à un seul Azure Key Vault. À mesure que la base de données augmente, le nombre de serveurs de pages augmente automatiquement. Il est donc important de surveiller régulièrement la taille de la base de données. Si le nombre de serveurs de pages dépasse 500, utilisez un Azure Key Vault dédié pour chaque base de données Hyperscale, et ne partagez pas ce coffre de clés avec d'autres ressources Azure SQL.

    • Surveillez et configurezles alertes Azure Key Vault. Pour plus d’informations sur la surveillance et les alertes, consultez Surveiller Azure Key Vault et Configurer les alertes Azure Key Vault.

  • Définissez un verrou de ressource sur le coffre de clés pour contrôler les utilisateurs pouvant supprimer cette ressource critique et pour empêcher toute suppression accidentelle ou non autorisée. Pour en savoir plus sur les verrous de ressources.

  • Activez l’audit et la création de rapports sur toutes les clés de chiffrement : Azure Key Vault fournit des journaux faciles à injecter dans d’autres outils de gestion des événements et des informations de sécurité. Operations Management Suite Log Analytics est un exemple de service déjà intégré.

  • Utilisez un coffre de clés à partir d’une région Azure qui peut répliquer son contenu vers une région jumelée pour une disponibilité maximale. Pour plus d’informations, consultez Meilleures pratiques pour l’utilisation d’Azure Key Vault et disponibilité et redondance d’Azure Key Vault.

Recommandations pour la configuration du protecteur TDE

  • Gardez une copie du TDE protector dans un endroit sécurisé ou confiez-le à un service d’entiercement.

  • Si vous générez la clé dans le Key Vault, créez une sauvegarde de clé avant de l’utiliser pour la première fois dans Azure Key Vault. Vous pouvez restaurer la sauvegarde uniquement dans un Azure Key Vault. Pour en savoir plus, consultez la commande Backup-AzKeyVaultKey . Azure Managed HSM permet de créer une sauvegarde complète de l’intégralité du contenu du HSM, incluant toutes les clés, versions, attributs, tags et assignations de rôle. Pour plus d’informations, consultez Sauvegarde complète et restauration et restauration de clés sélectives.

  • Créez une nouvelle sauvegarde chaque fois que vous effectuez des modifications à la clé (par exemple, attributs de clé, tags, ACL).

  • Conservez les versions précédentes de la clé dans le coffre de clés ou dans le HSM géré lors de la rotation des clés, afin de pouvoir restaurer les sauvegardes de la base de données plus anciennes. Lorsque le protecteur TDE change pour une base de données, les anciennes sauvegardes de la base ne sont pas mises à jour pour utiliser le dernier protecteur TDE. Lors de la restauration, chaque sauvegarde nécessite le protecteur TDE avec lequel elle a été chiffrée lors de sa création. Pour faire pivoter les clés, suivez les instructions de l’article Faire pivoter le protecteur de chiffrement des données transparentes (TDE).

  • Conservez toutes les clés précédemment utilisées dans Azure Key Vault même après être passé aux clés gérées par service. Il garantit que les sauvegardes de la base de données peuvent être restaurées avec les protecteurs de TDE stockés dans Azure Key Vault. Les protecteurs TDE créés avec Azure Key Vault doivent être maintenus jusqu’à ce que toutes les sauvegardes stockées restantes aient été créées avec des clés gérées par le service. Créez des copies de sauvegarde de ces clés pouvant être restaurées à l’aide de Backup-AzKeyVaultKey.

  • Pour supprimer une clé potentiellement compromise pendant un incident de sécurité sans risque de perte de données, suivez les étapes de l’article Supprimer un protecteur TDE (Transparent Data Encryption) à l’aide de PowerShell. Remplacez toujours par un nouveau protecteur TDE et vérifiez que toutes les bases de données utilisent la nouvelle clé avant de supprimer ou de désactiver la clé compromise. Supprimer ou désactiver la clé sans avoir d’abord effectué sa rotation rend toutes les bases de données chiffrées inaccessibles et n’invalide pas les copies de la clé qui ont été précédemment sauvegardées puis restaurées dans un autre coffre de clés.

Rotation du protecteur TDE

Lorsque vous faites pivoter le protecteur TDE, vous remplacez la clé qui protège la clé de chiffrement de la base de données (DEK). La rotation des clés est une opération en ligne et ne prend que quelques secondes. Cette opération déchiffre et rechiffre uniquement la clé de chiffrement de la base de données, et non l’ensemble de la base de données.

Vous pouvez effectuer la rotation du protecteur TDE en changeant la configuration pour utiliser une nouvelle clé stockée dans Azure Key Vault. Selon l’offre et la configuration prise en charge, cette clé peut être :

  • Passage à une nouvelle version de la même clé
  • Passage à une autre clé

La rotation du protecteur TDE peut être effectuée manuellement ou à l’aide de la fonction de rotation automatique.

Vous pouvez activer la rotation automatique du protecteur TDE lorsque vous configurez le protecteur TDE du serveur. La rotation automatisée est désactivée par défaut. Une fois activé, le serveur vérifie continuellement le coffre de clés pour détecter de nouvelles versions de la clé utilisée comme protecteur TDE. Si le serveur détecte une nouvelle version de la clé, il effectue automatiquement la rotation du protecteur TDE sur le serveur ou la base de données vers la dernière version de la clé dans les 24 heures.

Note

Lorsque vous configurez TDE avec CMK en utilisant une rotation manuelle ou automatisée des clés, vous utilisez toujours la dernière version de la clé prise en charge par le système. La configuration n’autorise pas l’utilisation d’une version antérieure ou inférieure des clés. Toujours utiliser la dernière version de la clé est conforme à la stratégie de sécurité Azure SQL qui interdit les versions précédentes de clés qui peuvent être compromises.

Protecteur TDE inaccessible

Lorsque vous configurez le TDE pour utiliser une clé gérée par le client, la base de données a besoin d’un accès continu au protecteur TDE pour rester en ligne. Si le serveur perd l’accès au protecteur TDE géré par le client dans Azure Key Vault, la base de données commence à refuser toutes les connexions dans les 10 minutes, affiche un message d’erreur et change son état en Inaccessible. La seule action autorisée sur une base de données dans un état inaccessible est de la supprimer.

État Inaccessible

Si la base de données est inaccessible en raison d’une panne réseau intermittente (par exemple, une erreur 5XX), aucune action n’est requise, car les bases de données reviennent automatiquement en ligne. Pour réduire l’impact des erreurs de réseau ou des pannes lors de l’accès au protecteur TDE dans Azure Key Vault, le service prévoit une période tampon de 24 heures avant de tenter de faire passer la base de données à un état inaccessible. Si un basculement se produit avant d’atteindre l’état inaccessible, la base de données devient indisponible en raison de la perte du cache de chiffrement.

Si le serveur perd l’accès au protecteur TDE géré par le client dans Azure Key Vault à cause d’une erreur Azure Key Vault (comme une erreur 4XX), la base de données passe à un état inaccessible après 30 minutes.

Restaurer l’accès à la base de données après une erreur Azure Key Vault

Une fois l’accès à la clé restauré, le retour en ligne de la base de données nécessite un temps et des étapes supplémentaires, qui peuvent varier en fonction de la durée d’indisponibilité de clé et de la taille des données dans la base de données.

Si l’accès à la clé est restauré dans les 30 minutes, la base de données guérit automatiquement au cours de l’heure suivante. Toutefois, si l’accès à la clé est restauré après plus de 30 minutes, la réparation automatique de la base de données n’est pas possible. Dans ce cas, la restauration de la base de données implique des procédures supplémentaires via le portail Azure et peut prendre du temps, en fonction de la taille de la base de données.

Une fois la base de données de nouveau en ligne, les paramètres au niveau du serveur précédemment configurés, y compris les configurations de groupe de basculement, les balises, et les paramètres au niveau de la base de données tels que les configurations de pool élastique, la mise à l'échelle de lecture, la pause automatique, l'historique de restauration à un point dans le temps, la stratégie de rétention à long terme, et d'autres, sont perdus. Par conséquent, il est recommandé aux clients d’implémenter un système de notification pour détecter la perte d’accès à la clé de chiffrement dans les 30 minutes. Une fois la fenêtre de 30 minutes expirée, nous vous conseillons de valider tous les paramètres au niveau du serveur et de la base de données sur la base de données récupérée.

Voici une vue des étapes supplémentaires requises sur le portail pour ramener une base de données inaccessible en ligne.

Révocation accidentelle de l’accès au protecteur TDE

Il peut arriver qu’une personne disposant de droits d’accès suffisants au coffre de clés ou au module HSM géré désactive accidentellement l'accès à la clé via le serveur :

  • révoquant les autorisations get, wrapKey, unwrapKey du coffre de clés ou du HSM managé à partir du serveur

  • Suppression de la clé

  • supprimant le coffre de clés ou le HSM managé

  • modifiant les règles de pare-feu du coffre de clés ou du HSM managé

  • suppression de l’identité managée du serveur dans Microsoft Entra ID

En savoir plus sur les causes courantes pour que la base de données devienne inaccessible.

Connectivité bloquée entre SQL Managed Instance et Azure Key Vault

Le bloc de connectivité réseau entre SQL Managed Instance et coffre de clés ou HSM managé se produit principalement lorsque le coffre de clés ou la ressource HSM managée existe, mais que son point de terminaison ne peut pas être atteint à partir de l’instance managée. Tous les scénarios où le coffre de clés ou le point de terminaison HSM managé sont accessibles, mais la connexion est refusée en raison d'autorisations manquantes, etc., entraînent les bases de données à passer à l'état Inaccessible.

Les causes les plus courantes du manque de connectivité réseau à Azure Key Vault sont :

  • Azure Key Vault est exposé via un point de terminaison privé et l'adresse IP privée du service Azure Key Vault n'est pas autorisée dans les règles sortantes du Network Security Group (NSG) associées au sous-réseau d'instance gérée.

  • La résolution DNS est incorrecte, comme lorsque le nom de domaine complet du coffre de clés ou du HSM managé n'est pas résolu ou aboutit à une adresse IP non valide.

Testez la connectivité de SQL Managed Instance vers le coffre de clés Azure Key Vault hébergeant le protecteur TDE.

  • Le point de terminaison est votre nom de domaine complet de coffre, comme <nom_coffre>.vault.azure.net (sans la mention https://).
  • Le port à tester est le port 443.
  • Le résultat de RemoteAddress devrait exister et être la bonne adresse IP
  • Le résultat du test TCP doit être TcpTestSucceeded: True.

Si le test retourne TcpTestSucceeded: False, vérifiez la configuration réseau :

  • Vérifiez la validité de l’adresse IP résolue. Une valeur manquante est le signe de problèmes de résolution DNS.

    • Vérifiez que le groupe de sécurité réseau sur l’instance managée a une règle de trafic sortant qui couvre l’adresse IP résolue sur le port 443, en particulier lorsque l’adresse résolue appartient au point de terminaison privé du coffre de clés ou du HSM privé managé.

    • Vérifiez les autres configurations réseau telles que la table de routage, l’existence de l’appliance virtuelle et sa configuration, etc.

Surveiller le TDE géré par le client

Pour surveiller l’état de la base de données et activer l’alerte pour la perte d’accès au protecteur TDE, configurez les fonctionnalités Azure suivantes :

  • Azure Resource Health. Une base de données inaccessible qui a perdu l’accès au protecteur TDE apparaît comme « Indisponible » après le refus de la première connexion à la base de données.

  • Journal d’activité : lorsque l’accès au protecteur TDE dans le coffre de clés géré par le client échoue, des entrées sont ajoutées au Journal d’activité. En créant des alertes pour ces événements, vous pouvez rétablir l’accès dès que possible.

  • Des groupes d’action peuvent être définis pour vous envoyer des notifications et des alertes en fonction de vos préférences, par exemple Email, SMS, Push, Voice, Logic App, Webhook, ITSM ou Automation Runbook.

Sauvegarde et restauration de base de données avec TDE géré par le client

Une fois qu’une base de données est chiffrée avec TDE à l’aide d’une clé provenant d’Azure Key Vault, toutes les sauvegardes nouvellement générées sont également chiffrées avec le même protecteur TDE. Quand le protecteur TDE est changé, les anciennes sauvegardes de la base de données ne sont pas mises à jour pour utiliser le protecteur TDE le plus récent.

Pour restaurer une sauvegarde chiffrée avec un protecteur TDE d’Azure Key Vault, assurez-vous que les éléments de clé sont disponibles pour le serveur cible. Par conséquent, conservez toutes les anciennes versions du protecteur TDE dans un coffre-fort de clés ou un HSM géré, afin que les sauvegardes de la base de données puissent être restaurées.

Important

À tout moment, il ne peut pas y avoir plus d’un protecteur TDE défini pour un serveur. La clé marquée avec Faire de la clé le protecteur TDE par défaut dans le volet du portail Microsoft Azure est le protecteur TDE. Toutefois, plusieurs clés peuvent être liées à un serveur sans les marquer comme protecteur TDE. Ces clés ne sont pas utilisées pour protéger le DEK, mais peuvent être utilisées lors de la restauration à partir d’une sauvegarde si le fichier de sauvegarde est chiffré avec la clé portant l’empreinte digitale correspondante.

Si la clé nécessaire pour la restauration d’une sauvegarde n’est plus disponible dans le serveur cible, le message d’erreur suivant est retourné lors de la tentative de restauration : « Le serveur cible <Servername> n’a pas accès à tous les URI AKV créés entre <Timestamp #1> et <Timestamp #2>. Réessayez l’opération après avoir restauré tous les URI AKV. »

Pour l’atténuer, exécutez la cmdlet Get-AzSqlServerKeyVaultKey pour le serveur cible ou Get-AzSqlInstanceKeyVaultKey pour l’instance gérée cible afin de retourner la liste des clés disponibles et d’identifier celles qui sont manquantes. Pour garantir la restauration possible de toutes les sauvegardes, vérifiez que le serveur cible pour la sauvegarde dispose d’un accès à toutes les clés nécessaires. Ces clés n’ont pas besoin d’être marquées comme protecteur TDE.

Pour en savoir plus sur la récupération de sauvegarde pour des pools SQL dédiés dans Azure Synapse Analytics, consultez Récupérer un pool SQL dédié.

Attention particulière pour les fichiers journaux : les fichiers journaux sauvegardés restent chiffrés avec le protecteur TDE d’origine, même en cas de permutation et si la base de données utilise maintenant un nouveau protecteur TDE. Lors d’une restauration, les deux clés sont nécessaires pour restaurer la base de données. Si le fichier journal utilise un protecteur TDE stocké dans Azure Key Vault, cette clé est nécessaire au moment de la restauration, même si la base de données a été modifiée pour utiliser un TDE géré par le service entre-temps.

Haute disponibilité avec TDE managé par le client

En utilisant les multiples couches de redondance d'Azure Key Vault, les TDE qui utilisent une clé gérée par le client peuvent bénéficier de la disponibilité et de la résilience d'Azure Key Vault. Ils peuvent pleinement compter sur la solution de redondance Azure Key Vault.

Les multiples couches de redondance d'Azure Key Vault garantissent l'accès aux clés même si des composants de service individuels échouent ou si les régions ou zones de disponibilité Azure sont hors service. Pour plus d’informations, consultez Disponibilité et redondance d’Azure Key Vault.

Azure Key Vault propose automatiquement les composantes suivantes de disponibilité et de résilience sans intervention de l’utilisateur :

Contenu connexe

  • Dernière mise à jour :