Chiffrement des données au repos dans Azure Database pour PostgreSQL

Toutes les données gérées par une instance de serveur flexible Azure Database pour PostgreSQL sont toujours chiffrées au repos. Ces données incluent toutes les bases de données système et utilisateur(-trice), les journaux du serveur, les segments de journaux d’écriture avant et les sauvegardes. Le chiffrement est géré par le stockage sous-jacent via le chiffrement côté serveur du stockage disque Azure.

Chiffrement au repos avec le service (SMK) ou des clés gérées par le client (CMK)

Azure Database pour PostgreSQL prend en charge deux modes de chiffrement des données au repos : les clés gérées par le service (SMK) et les clés gérées par le client (CMK). Le chiffrement des données à l’aide de clés gérées par le service est le mode par défaut pour Azure Database pour PostgreSQL flexible server. Dans ce mode, le service gère automatiquement les clés de chiffrement utilisées pour chiffrer vos données. Vous n’avez pas besoin d’effectuer d’action pour activer ou gérer le chiffrement dans ce mode.

En mode clés gérées par le client, vous pouvez apporter votre propre clé de chiffrement pour chiffrer vos données. Ce mode vous donne plus de contrôle sur le processus de chiffrement, mais il vous oblige également à gérer vous-même les clés de chiffrement. Vous devez déployer votre propre Azure Key Vault ou Module de Sécurité Matérielle Géré Azure Key Vault (HSM) et le configurer pour stocker les clés de chiffrement utilisées par votre instance de serveur flexible Azure Database pour PostgreSQL.

Le mode ne peut être sélectionné qu’au moment de la création du serveur. Il ne peut être changé d’un mode à l’autre pendant toute la durée de vie du serveur.

Pour obtenir le chiffrement de vos données, Azure Database pour PostgreSQL utilise le chiffrement stockage Azure pour les données au repos. Lors de l’utilisation de CMK, le client est chargé de fournir des clés pour chiffrer et déchiffrer des données dans les services Stockage Blob et Azure Files. Ces clés doivent être stockées dans Azure Key Vault ou dans un module de sécurité matériel (HSM) géré par Azure Key Vault. Pour plus d’informations, consultez Clés gérées par le client pour le chiffrement Stockage Azure.

Avantages fournis par chaque mode (SMK ou CMK)

Le chiffrement des données avec des clés gérées par le service pour Azure Database pour PostgreSQL offre les avantages suivants :

• Le service contrôle automatiquement et entièrement l’accès aux données.
• Le service contrôle automatiquement et entièrement le cycle de vie de votre clé, y compris la rotation de la clé.
• Vous n’avez pas besoin de vous soucier de la gestion des clés de chiffrement de données.
• Le chiffrement de données basé sur des clés gérées par le service n’a pas d’effet négatif sur les performances de vos charges de travail.
• Il simplifie la gestion des clés de chiffrement (y compris leur rotation régulière) et la gestion des identités utilisées pour accéder à ces clés.

Le chiffrement des données avec des clés gérées par le client pour Azure Database pour PostgreSQL offre les avantages suivants :

• Vous contrôlez entièrement l’accès aux données. Vous pouvez supprimer une clé pour rendre une base de données inaccessible.
• Vous contrôlez entièrement le cycle de vie d’une clé, y compris la rotation de la clé, pour vous aligner sur les stratégies de l’entreprise.
• Vous pouvez gérer et organiser de façon centralisée toutes vos clés de chiffrement dans vos propres instances d’Azure Key Vault.
• Le chiffrement de données basé sur des clés gérées par le client n’a pas d’effet négatif sur les performances de vos charges de travail.
• Vous pouvez implémenter une séparation des tâches entre les responsables sécurité, les administrateurs de base de données et les administrateurs système.

Conditions requises concernant les clés gérées par le client

Avec la clé de chiffrement gérée par le client , vous assumez la responsabilité. Par conséquent, vous devez déployer votre propre coffre Azure Key Vault ou votre propre module de sécurité matériel (HSM) Azure Key Vault. Vous devez générer ou importer votre propre clé. Vous devez accorder des autorisations requises sur le coffre de clés afin que votre instance de serveur flexible Azure Database pour PostgreSQL puisse effectuer les actions nécessaires sur la clé. Vous devez vous occuper de configurer tous les aspects réseau d’Azure Key Vault dans lesquels la clé est conservée, afin que votre instance de serveur flexible Azure Database pour PostgreSQL puisse accéder à la clé. La vérification des accès à la clé relève également de votre responsabilité. Enfin, vous êtes responsable de la rotation de la clé et, si nécessaire, de la mise à jour de la configuration de votre instance de serveur flexible Azure Database pour PostgreSQL afin qu’elle référence la version pivotée de la clé.

Quand vous configurez des clés gérées par le client pour un compte de stockage, Stockage Azure encapsule la clé de chiffrement des données (DEK) racine pour le compte avec la clé gérée par le client dans le coffre de clés ou le HSM managé associé. La protection de la clé de chiffrement racine change, mais les données de votre compte de stockage Azure restent toujours chiffrées. Aucune action supplémentaire n’est requise de votre part pour faire en sorte que vos données soient protégées. La protection par des clés gérées par le client prend effet immédiatement.

Azure Key Vault est un système de gestion de clés externe basé sur le cloud. Il est hautement disponible et fournit un stockage évolutif et sécurisé pour les clés de chiffrement RSA, éventuellement sauvegardées par des modules de sécurité matériels (HSM) validés par FIPS 140. Il ne permet pas l’accès direct à une clé stockée, mais fournit des services de chiffrement et de déchiffrement aux entités autorisées. Key Vault peut générer la clé, l’importer ou la recevoir par transfert depuis un appareil HSM local.

Voici la liste des conditions requises pour configurer le chiffrement des données pour Azure Database pour PostgreSQL :

• Pour les configurations CMK à locataire unique, Key Vault et votre instance de serveur flexible Azure Database pour PostgreSQL doivent appartenir au même locataire Microsoft Entra. Pour les scénarios mutualisés, consultez la rubrique Clés gérées par le client entre locataires. Pour déplacer par la suite la ressource Key Vault, vous devez reconfigurer le chiffrement des données.
• Nous vous recommandons de définir la configuration de Jours de conservation des coffres supprimés pour Key Vault sur 90 jours. Si vous avez configuré une instance Key Vault existante avec un nombre inférieur, elle devrait néanmoins être valide. Cependant, si vous souhaitez modifier ce paramètre et augmenter la valeur, il est nécessaire de créer une nouvelle instance Key Vault. Une fois qu’une instance est créée, il n’est pas possible de modifier ce paramètre.
• Activez la fonctionnalité supprimée de manière réversible dans Key Vault pour vous aider à protéger contre la perte de données, si une clé ou une instance Key Vault est supprimée accidentellement. Key Vault conserve les ressources supprimées de manière réversible pendant 90 jours, sauf si l'utilisateur les récupère ou les supprime définitivement dans l'intervalle. Les actions de récupération et de vidage ont leurs propres autorisations associées à un coffre de clés, un rôle RBAC ou à une autorisation de stratégie d’accès. La fonctionnalité de suppression réversible est activée par défaut. Si vous avez un coffre de clés qui a été déployé il y a longtemps, il se peut que la suppression réversible soit désactivée. Dans ce cas, vous pouvez l’activer en utilisant Azure CLI.
• Activez la protection contre la suppression définitive pour appliquer une période de rétention obligatoire pour les coffres et les objets de coffre supprimés.
• Accordez à l’identité managée affectée par l’utilisateur(-trice) d’Azure Database pour PostgreSQL– Instance de serveur flexible l’accès à la clé en :
• Préféré : Azure Key Vault doit être configuré avec le modèle d’autorisation RBAC et l’identité managée doit être affectée au rôle Utilisateur de chiffrement Service chiffrement Key Vault.
• Hérité : si Azure Key Vault est configuré avec le modèle d’autorisation de stratégie d’accès, accordez les autorisations suivantes à l’identité managée :
• get : pour récupérer les propriétés et la partie publique de la clé dans Key Vault.
• list : pour lister et itérer dans les clés stockées dans Key Vault.
• wrapKey : pour chiffrer la clé de chiffrement de données.
• unwrapKey : pour déchiffrer la clé de chiffrement de données.
• La clé utilisée pour chiffrer la clé de chiffrement de données peut être seulement asymétrique, RSA ou RSA-HSM. Les tailles de clé 2 048, 3 072 et 4 096 sont prises en charge. Nous vous recommandons d’utiliser une clé de 4 096 bits pour une meilleure sécurité.
• La date et l’heure de l’activation de la clé (si elles sont définies) doivent être dans le passé. La date et l’heure d’expiration (si définies) doivent être dans le futur.
• La clé doit être dans l’état Activé.
• Si vous importez une clé existante dans Key Vault, fournissez-la dans l’un des formats de fichier pris en charge (.pfx, .byok ou .backup).

Mises à jour de la version de clé CMK

CMK peut être configuré avec une rotation manuelle des clés et des mises à jour ou avec des mises à jour de version de clé automatique après une rotation manuelle ou automatique de clé dans le coffre de clés.

Pour plus d’informations, consultez Configurer le chiffrement des données avec une clé managée par le client pendant l’approvisionnement du serveur.

Rotation et mises à jour manuelles des clés

Lorsque vous configurez CMK avec des mises à jour de clés manuelles, vous devez mettre à jour manuellement la version de la clé dans l’instance de serveur flexible Azure Database pour PostgreSQL après une rotation manuelle ou automatique des clés dans key Vault. Le serveur continue d’utiliser l’ancienne version de clé jusqu’à ce que vous la mettez à jour. Vous approvisionnez ce mode en spécifiant un URI de clé, y compris la version GUID dans l’URI. Par exemple : https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Jusqu’à récemment, il s’agissait de la seule option disponible.

Chaque fois que vous faites pivoter manuellement la clé ou AKV autorote la clé en fonction de sa stratégie de rotation, vous devez mettre à jour la propriété CMK sur votre instance PostgreSQL. Cette approche s’est avérée sujette à des erreurs pour les opérateurs ou nécessite un script personnalisé pour gérer la rotation, en particulier lors de l’utilisation de la fonctionnalité de rotation automatique de Key Vault.

Mises à jour automatiques des versions de clé

Pour activer les mises à jour automatiques des versions de clé, utilisez un URI de clé sans version. Cette approche élimine la nécessité de mettre à jour la propriété de version de cmK dans votre instance PostgreSQL après une rotation de clé. PostgreSQL récupère automatiquement la nouvelle version de la clé et réencrypte la clé de chiffrement des données. Cela simplifie considérablement la gestion du cycle de vie de vos clés, en particulier avec la rotation automatique de Key Vault.

Pour implémenter à l’aide de Azure Resource Manager, Bicep, Terraform, Azure PowerShell ou Azure CLI, omettez la version GUID de votre URI de clé.

Dans le portail, cochez la case pour guider l’interface utilisateur pour supprimer les GUID de version pendant la sélection interactive et lors de la validation de l’URI.

Recommendations

Quand vous utilisez une clé gérée par le client pour le chiffrement de données, suivez ces recommandations pour configurer Key Vault :

• Pour empêcher la suppression accidentelle ou non autorisée de cette ressource critique, définissez un verrou de ressource sur Key Vault.
• Activez l'audit et la création de rapports sur toutes les clés de chiffrement. Key Vault fournit des journaux d’activité faciles à injecter dans d’autres outils de gestion d’événements et d’informations de sécurité (SIEM). Azure Monitor Logs est un exemple de service déjà intégré.
• Verrouillez Key Vault en sélectionnant Désactiver l’accès public et Autoriser les services Microsoft approuvés à contourner ce pare-feu.
• Activer les mises à jour automatiques des versions de clé.

• Conservez une copie de la clé managée par le client dans un endroit sécurisé ou déposez-la dans le service de dépôt.
• Si Key Vault génère la clé, créez une sauvegarde de celle-ci avant sa première utilisation. La sauvegarde ne peut être restaurée que dans Key Vault.

Considérations spéciales

Révocation accidentelle de l'accès à une clé depuis Azure Key Vault

Une personne disposant de droits d’accès suffisants à Key Vault pourrait désactiver accidentellement l’accès du serveur à la clé :

• En annulant l’attribution du rôle RBAC Utilisateur de chiffrement du service de chiffrement Key Vault ou en révoquant les autorisations de l’identité utilisée pour récupérer la clé dans Key Vault.
• Supprimant la clé.
• En supprimant l’instance Key Vault.
• En modifiant les règles de pare-feu Key Vault.
• Suppression de l’identité managée du serveur dans Microsoft Entra ID.

Surveiller les clés conservées dans Azure Key Vault

Pour surveiller l’état de la base de données et activer des alertes pour la perte de l’accès au protecteur du chiffrement de données, configurez les fonctionnalités Azure suivantes :

• Intégrité des ressources : une base de données qui a perdu l’accès à la clé CMK apparaît comme Inaccessible après la première connexion à la base de données.
• Journal d’activité : lorsque l’accès à la clé CMK dans l’instance Key Vault gérée par le client échoue, des entrées sont ajoutées au journal d’activité. Vous pouvez rétablir l’accès en créant des alertes pour ces événements dès que possible.
• Groupes d'actions : définissez ces groupes pour recevoir des notifications et des alertes basées sur vos préférences.

Restaurer des sauvegardes d’un serveur configuré avec une clé gérée par le client

Une fois que votre instance de serveur flexible Azure Database pour PostgreSQL est chiffrée avec une clé gérée par le client stockée dans Key Vault, toute copie de serveur nouvellement créée est également chiffrée. Vous pouvez créer cette copie par l’intermédiaire d’une opération de restauration à un instant dans le passé ou de réplicas en lecture.

Quand vous configurez le chiffrement de données avec une clé gérée par le client, pendant une opération comme la restauration d’une sauvegarde ou la création d’un réplica en lecture, vous pouvez éviter les problèmes en suivant ces étapes sur les serveurs principaux et restaurés ou les serveurs réplicas :

• Lancez le processus de restauration ou de création de réplica en lecture à partir de l’instance principale de serveur flexible Azure Database pour PostgreSQL.
• Sur le serveur restauré ou réplica, vous pouvez changer la clé gérée par le client et l’identité managée affectée par l’utilisateur utilisée pour accéder à Key Vault. Vérifiez que l’identité affectée dans le serveur nouvellement créé dispose des autorisations requises sur le coffre de clés.
• Ne révoquez pas la clé d’origine après la restauration. À ce stade, nous ne prenons pas en charge la révocation de clé après la restauration d’un serveur avec une clé gérée par le client sur un autre serveur.

Modules HSM managés

Les modules de sécurité matériels (HSM) sont des appareils matériels inviolables qui aident à sécuriser les processus de chiffrement en générant, en protégeant et en gérant les clés utilisées pour chiffrer les données, déchiffrer des données, créer des signatures numériques et créer des certificats numériques. Les HSM sont testés, validés et certifiés selon les normes de sécurité les plus élevées, notamment FIPS 140 et les critères communs.

Azure Key Vault Managed HSM est un service cloud complètement managé, hautement disponible, à locataire unique et conforme aux normes. Vous pouvez l’utiliser pour protéger les clés de chiffrement pour vos applications cloud via des HSM validés FIPS 140-3.

Quand vous créez des instances Azure Database pour PostgreSQL – Serveur flexible dans le portail Azure avec la clé gérée par le client, vous pouvez choisir HSM géré par Azure Key Vault en tant que magasin de clés comme alternative à Azure Key Vault. Les prérequis, en termes d’identité et d’autorisations définies par l’utilisateur, sont identiques à celles d’Azure Key Vault (comme indiqué plus haut dans cet article). Pour plus d’informations sur la création d’une instance HSM managée, ses avantages et ses différences par rapport à un magasin de certificats basé sur Key Vault partagé et comment importer des clés dans un HSM managé, consultez Qu’est-ce que HSM managé Azure Key Vault ?.

Condition de clé gérée par le client inaccessible

Quand vous configurez le chiffrement de données avec une clé gérée par le client stockée dans Key Vault, un accès continu à cette clé est requis pour que le serveur reste en ligne. Si ce n’est pas le cas, le serveur change d’état en inaccessible et commence à refuser toutes les connexions.

Voici les raisons possibles pour lesquelles l’état du serveur peut devenir Inaccessible :

Récupérer après la suppression d’une identité managée

Si l’identité managée affectée par l’utilisateur utilisée pour accéder à la clé de chiffrement stockée dans Key Vault est supprimée dans Microsoft Entra ID, procédez comme suit pour récupérer :

1. Récupérez l’identité ou créez une nouvelle identité managée Entra ID.
2. Si vous avez créé une nouvelle identité, même si elle porte le même nom qu’avant sa suppression, mettez à jour les propriétés d’instance de serveur flexible Azure Database pour qu’elle sache qu’elle doit utiliser cette nouvelle identité pour accéder à la clé de chiffrement.
3. Assurez-vous que cette identité dispose des autorisations appropriées pour les opérations sur la clé dans Azure Key Vault (AKV).
4. Attendez environ une heure jusqu’à ce que le serveur revalide la clé.

Utiliser le chiffrement des données avec des clés gérées par le client et des fonctionnalités de continuité d’activité géoredondantes

Azure Database pour PostgreSQL prend en charge les fonctionnalités avancées de récupération de données , telles que les réplicas et lasauvegarde géoredondante. Voici les conditions requises pour configurer le chiffrement des données avec une clé CMK et ces fonctionnalités, en plus des exigences de base pour le chiffrement des données avec des CMK :

• La clé de chiffrement de sauvegarde géoredondante doit être créée dans une instance Key Vault qui se trouve dans la région où la sauvegarde géoredondante est stockée.
• La version de l’API REST Azure Resource Manager pour la prise en charge des serveurs de CMK avec sauvegarde géoredondante est « 2022-11-01-preview ». Si vous souhaitez utiliser des modèles Azure Resource Manager pour automatiser la création de serveurs qui utilisent à la fois le chiffrement avec les clés CMK et les fonctionnalités de sauvegarde géoredondantes, utilisez cette version de l’API.
• Vous ne pouvez pas utiliser la même identité managée par l’utilisateur pour vous authentifier pour l’instance Key Vault de la base de données primaire et l’instance Key Vault qui contient la clé de chiffrement pour la sauvegarde géoredondante. Pour maintenir la résilience régionale, nous vous recommandons de créer l’identité managée par l’utilisateur dans la même région que les sauvegardes géoredondantes.
• Si vous configurez une base de données de réplica en lecture à chiffrer avec des clés CMK lors de la création, sa clé de chiffrement doit se trouver dans une instance Key Vault dans la région où réside la base de données de réplica en lecture. L’identité attribuée par l’utilisateur pour s’authentifier auprès de cette instance Key Vault doit être créée dans la même région.

Clés gérées par le client entre locataires (CMK) (version préliminaire)

Les clés gérées par le client interlocataire vous permettent d’utiliser des clés de chiffrement stockées dans une instance Key Vault ou Managed HSM qui appartient à une Microsoft Entra ID différente de celle de votre instance de serveur flexible Azure Database pour PostgreSQL. La configuration CMK multilocataire nécessite une configuration supplémentaire ainsi qu’une coordination entre les locataires. Dans le scénario interlocataire, la ressource Azure Database pour PostgreSQL réside dans un locataire géré par un fournisseur de logiciels indépendant (ISV) appelé fournisseur de services. La clé utilisée pour le chiffrement de la ressource Azure Database pour PostgreSQL réside dans un coffre de clés dans un autre locataire que le client gère.

Vue d’ensemble de la configuration

Sur le locataire ISV

• Créez une application multilocataire

  • Configurez l’identité managée affectée par l’utilisateur en tant qu’informations d’identification fédérées sur l’application

Sur le locataire du client

1. Installez l’application multilocataire

2. Créer ou utiliser un coffre de clés existant ou un HSM managé et accorder des autorisations de clé à l’application mutualisée

   1. Créez une clé ou utilisez une clé existante

   2. Récupérer la clé à partir d’Azure Key Vault ou d’Azure Managed HSM et enregistrer l’identificateur de clé

Sur le locataire ISV

Jusqu’à ce stade, vous avez configuré l’application mutualisée sur le tenant du fournisseur de services. Vous avez également installé l'application sur le tenant du client et configuré le coffre de clés et la clé sur le tenant du client. Ensuite, vous pouvez créer un compte Azure Database pour PostgreSQL sur le locataire du fournisseur de services et configurer des clés gérées par le client avec la clé à partir du locataire du client.

Lorsque vous créez une instance Azure Database pour PostgreSQL avec des clés gérées par le client, vous devez vous assurer qu’elle a accès aux clés utilisées par le client. Dans les scénarios à locataire unique, vous donnez un accès direct au coffre de clés à l’identité managée par l’utilisateur de l’instance Azure Database pour PostgreSQL. Dans un scénario interlocataire, vous ne pouvez plus dépendre d’un accès direct au coffre de clés, car il se trouve dans un autre locataire géré par le client. Cette contrainte explique pourquoi vous avez créé une application inter-locataire et enregistré une identité managée dans l’application afin de lui donner accès au coffre de clés du client dans les sections précédentes. Cette identité gérée, associée à l’ID d’application entre clients, est ce que vous utilisez lors de la création de la clé CMK entre les clients pour l’instance Azure Database pour PostgreSQL.

Chaque fois qu’une nouvelle version de la clé est disponible dans le coffre de clés, l’instance de Azure Database pour PostgreSQL récupère automatiquement la nouvelle version.

Utiliser le portail Azure

Pour configurer des clés gérées par le client multilocataire pour une nouvelle instance Azure Database pour PostgreSQL dans le portail Azure, procédez comme suit :

1. Dans la Azure Database pour PostgreSQL créer une ressource, sélectionnez l’onglet Security dans le portail Azure, puis sélectionnez Clé gérée parCustomer.

2. Attribuez l’identité gérée attribuée par l’utilisateur créée en tant que Identité gérée attribuée par l’utilisateur.

3. Attribuez l’application entre clients en utilisant le nom de l’application.

4. Entrez un identificateur de clé dans la méthode de sélection de clé en utilisant l’identificateur de clé du client obtenu à partir du locataire client.

Utiliser Azure Resource Manager modèles JSON et l’API REST

Déployez un modèle ARM avec les paramètres spécifiques suivants :

Voici un exemple d’API REST avec les trois paramètres configurés :

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Exemple de contenu de la demande :

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Voici un exemple d’API REST pour la rotation des clés. L’exemple PATCH met à jour uniquement l’URI de clé CMK pour faire pivoter la clé de chiffrement sans recréer le serveur.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Corps de la demande (exemple de clé de rotation) :

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Version préliminaire des limitations des clés gérées par le client (CMK) entre locataires

• Cette fonctionnalité n'est pas encore prise en charge dans Azure PowerShell ou Azure CLI.
• La création d’un serveur avec des sauvegardes géoredondantes et l’activation des opérations de sauvegarde de rétention à long terme ne sont pas prises en charge actuellement.
• La version préliminaire n’est actuellement prise en charge que dans les régions suivantes :
  • Est des États-Unis 2
  • Ouest des États-Unis 2
  • Centre des États-Unis
  • Australia Southeast
  • Australia East
  • North Europe

Limitations des clés gérées par le client (CMK)

Voici les limitations actuelles pour la configuration de la clé gérée par le client dans une instance de serveur flexible Azure Database pour PostgreSQL :

• Vous pouvez configurer le chiffrement par clé gérée par le client seulement lors de la création d’un serveur, et non pas dans le cadre d’une mise à jour vers une instance Azure Database pour PostgreSQL – Serveur flexible existante. Vous pouvez restaurer une sauvegarde de restauration à un instant dans le passé sur un nouveau serveur avec le chiffrement CMK à la place.
• Une fois que vous avez configuré le chiffrement par clé gérée par le client, vous ne pouvez pas revenir au chiffrement par clé gérée par le système. Si vous voulez y revenir, vous devez restaurer le serveur sur un nouveau serveur avec le chiffrement de données configuré avec la clé gérée par le système.
• L’instance du HSM géré par Azure Key Vault ou l’instance d’Azure Key Vault sur laquelle vous prévoyez de stocker la clé de chiffrement doit exister dans la même région que celle sur laquelle l’instance d’Azure Database for flexible server est créée.

Contenu connexe

• Configurer le chiffrement des données dans Azure Database pour PostgreSQL