Configurer des clés gérées par le client pour votre compte Azure Cosmos DB existant avec Azure Key Vault

Article
08/15/2024

S’APPLIQUE À : NoSQL MongoDB Gremlin Table

L’activation d’une deuxième couche de chiffrement pour les données au repos à l’aide de clés gérées par le client lors de la création d’un compte Azure Cosmos DB est en disponibilité générale depuis un certain temps. En guise d’étape suivante, nous avons maintenant la possibilité d’activer CMK sur des comptes Azure Cosmos DB existants.

Cette fonctionnalité élimine le besoin de migration des données vers un nouveau compte pour activer CMK. Elle permet d’améliorer la posture de sécurité et de conformité des clients.

L’activation de CMK lance un processus asynchrone en arrière-plan pour chiffrer toutes les données existantes dans le compte, tandis que les nouvelles données entrantes sont chiffrées avant de persister. Il n’est pas nécessaire d’attendre la réussite de l’opération asynchrone. Le processus d’activation consomme des unités de requête inutilisées/de rechange afin de ne pas impacter vos charges de travail en lecture/écriture. Vous pouvez vous reporter à ce lien pour la planification de la capacité une fois votre compte chiffré.

Commencer à activer CMK sur des comptes existants

Important

Étudiez attentivement la section des prérequis. Il s’agit de considérations importantes.

Prérequis

Toutes les étapes préalables nécessaires pour configurer des clés gérées par le client pour les nouveaux comptes sont applicables pour activer CMK sur votre compte existant. Reportez-vous aux étapes indiquées ici.

Remarque

Il est important de noter qu’activer le chiffrement sur votre compte Azure Cosmos DB ajoutera une petite surcharge à l’ID de votre document, limitant la taille maximale de l’ID de document à 990 octets au lieu de 1024 octets. Si votre compte contient des documents dont les ID dépassent 990 octets, le processus de chiffrement échouera jusqu’à ce que ces documents soient supprimés.

Pour vérifier si votre compte est conforme, vous pouvez utiliser l’application console fournie hébergée ici pour analyser votre compte. Vérifiez que vous utilisez le point de terminaison de la propriété « sqlEndpoint » de votre compte, quelle que soit l’API sélectionnée.

Si vous souhaitez désactiver la validation côté serveur pour cette opération pendant la migration, contactez le support.

Étapes à suivre pour activer CMK sur un compte existant

Pour activer CMK sur un compte existant, mettez à jour le compte avec un modèle ARM définissant un identificateur de clé Key Vault dans la propriété keyVaultKeyUri, tout comme lors de l’activation de CMK sur un nouveau compte. Cette étape peut être effectuée en émettant un appel PATCH avec la charge utile suivante :

    {
        "properties": {
        "keyVaultKeyUri": "<key-vault-key-uri>"
        }
    }

La sortie de cette commande CLI pour l’activation de CMK attend la fin du chiffrement des données.

    az cosmosdb update --name "testaccount" --resource-group "testrg" --key-uri "https://keyvaultname.vault.azure.net/keys/key1"

Étapes à suivre pour activer CMK sur votre compte Azure Cosmos DB existant avec un compte de sauvegarde continue ou de magasin analytique

Pour activer CMK sur un compte existant pour lequel la sauvegarde continue et la restauration dans le temps (PITR) sont activées, nous devons effectuer des étapes supplémentaires. Effectuez les étapes 1 à 5, puis suivez les instructions pour activer CMK sur un compte existant.

Configurez une identité managée sur votre compte Cosmos Configurer des identités managées avec Microsoft Entra ID pour votre compte Azure Cosmos DB

Mettre à jour le compte Cosmos pour définir l’identité par défaut pour qu’elle pointe vers l’identité managée ajoutée à l’étape précédente

Pour une identité managée par le système :

az cosmosdb update--resource-group $resourceGroupName --name $accountName --default-identity "SystemAssignedIdentity"

Pour une identité managée par l’utilisateur :

az cosmosdb update -n $sourceAccountName -g $resourceGroupName --default-identity "UserAssignedIdentity=/subscriptions/00000000-0000-0000-0000-00000000/resourcegroups/MyRG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyID"

Configurez Key Vault conformément à la documentation ici
Ajoutez une stratégie d’accès dans le coffre de clés pour l’identité par défaut définie à l’étape précédente
Mettre à jour le compte Cosmos pour définir l’URI du coffre de clés. Cette mise à jour déclenche l’activation de CMK sur le compte
```
az cosmosdb update --name $accountName --resource-group $resourceGroupName --key-uri $keyVaultKeyURI  
```

Limitations connues

Nous ne prenons pas en charge l’activation de CMK sur des comptes Azure Cosmos DB pour Apache Cassandra existants.
L’activation de CMK est disponible uniquement au niveau d’un compte Cosmos DB, pas au niveau des collections.
Nous ne prenons pas en charge l’activation de CMK sur des comptes existants qui sont également activés pour les vues matérialisées et le mode flux de modification de toutes les versions et suppressions.
Assurez-vous que le compte ne doit pas avoir de documents avec des ID volumineux supérieurs à 990 octets avant d’activer CMK. Si ce n’est pas le cas, vous obtiendrez une erreur en raison de la limite maximale prise en charge de 1 024 octets après le chiffrement.
Pendant le chiffrement des données existantes, les actions du plan de contrôle telles que « ajouter une région » sont bloquées. Ces actions sont débloquées et peuvent être utilisées juste après la fin du chiffrement.

Surveiller la progression du chiffrement résultant

L’activation de CMK sur un compte existant est une opération asynchrone qui lance une tâche en arrière-plan qui chiffre toutes les données existantes. Par conséquent, la demande d’API REST pour activer CMK fournit dans sa réponse une URL « Azure-AsyncOperation ». L’interrogation de cette URL avec des requêtes GET retourne l’état de l’opération globale, qui finit par réussir. Ce mécanisme est entièrement décrit dans cet article.

Le compte Cosmos DB peut continuer à être utilisé et les données peuvent continuer à être écrites sans attendre la réussite de l’opération asynchrone. La commande CLI pour l’activation de CMK attend la fin du chiffrement des données.

Pour permettre à un compte Cosmos DB existant d’utiliser la clé CMK, une analyse doit être effectuée pour garantir que le compte n’a pas d’« ID volumineux ». Un « ID volumineux » est un ID de document qui dépasse 990 caractères. Cette analyse est obligatoire pour la migration de la clé CMK et elle est effectuée automatiquement par Microsoft. Durant ce processus, il se peut que vous rencontriez une erreur.

ERREUR : (InternalServerError) erreur inattendue sur l’analyse de document pour la migration de la clé CMK. Réessayez l’opération.

Cela se produit lorsque le processus d’analyse utilise plus de RU que celles configurées sur la collection, ce qui génère une erreur 429. Une solution pour ce problème sera de réduire temporairement considérablement leurs RU. Vous pouvez également utiliser l’application console fournie hébergée ici pour analyser leurs collections.

Remarque

Si vous souhaitez désactiver la validation côté serveur pour cette opération pendant la migration, contactez le support. Cette méthode est conseillée uniquement si vous êtes sûr qu’il n’y a pas d’ID volumineux. Si le système rencontre un ID volumineux pendant le chiffrement, le processus s’arrête jusqu’à ce que le document d’ID volumineux ait été traité.

Si vous avez d’autres questions, contactez le Support Microsoft.

FAQ

Quels sont les facteurs dont dépend la durée de chiffrement ?

L’activation de CMK est une opération asynchrone qui dépend d’un nombre suffisant d’unités de requête inutilisées disponibles. Nous vous suggérons d’activer CMK pendant les heures creuses et, le cas échéant, d’augmenter le nombre d’unités de requête au préalable afin d’accélérer le chiffrement. La durée de chiffrement varie également en fonction de la taille des données.

Devons-nous anticiper un temps d’arrêt ?

L’activation de CMK lance un processus asynchrone en arrière-plan pour chiffrer toutes les données. Il n’est pas nécessaire d’attendre la réussite de l’opération asynchrone. Le compte Azure Cosmos DB est disponible pour les opérations de lecture et d’écriture et il n’est pas nécessaire de prévoir un temps d’arrêt.

Pouvez-vous augmenter le nombre d’unités de requête une fois CMK déclenché ?

Il est recommandé d’augmenter le nombre d’unités de requête avant de déclencher CMK. Une fois CMK déclenché, certaines opérations de plan de contrôle sont bloquées jusqu’à ce que le chiffrement soit terminé. Ce blocage peut empêcher l’utilisateur d’augmenter le nombre d’unités de requête une fois CMK déclenché.

Pour permettre à un compte Cosmos DB existant d’utiliser la clé CMK, Microsoft effectue automatiquement une analyse d’ID volumineux par Microsoft pour résoudre l’une des limitations connues répertoriées précédemment. Ce processus consomme également des RU supplémentaires et il est judicieux d’augmenter considérablement les RU pour éviter l’erreur 429.

Est-il possible d’annuler ou de désactiver le chiffrement après le déclenchement de CMK ?

Une fois déclenché, le processus de chiffrement des données à l’aide de CMK ne peut plus être annulé.

L’activation du chiffrement à l’aide de CMK sur un compte existant a-t-elle un impact sur la taille des données et les opérations de lecture/écriture ?

Comme vous pouvez vous y attendre, l’activation de CMK entraîne une légère augmentation de la taille des données et des unités de requête pour prendre en charge des opérations de chiffrement/déchiffrement supplémentaires.

Devez-vous sauvegarder les données avant d’activer CMK ?

L’activation de CMK ne présente aucun risque de perte de données.

Les anciennes sauvegardes faisant partie de la sauvegarde périodique sont-elles chiffrées ?

Nombre Les anciennes sauvegardes périodiques ne sont pas chiffrées. Les nouvelles sauvegardes générées après l’activation de CMK sont chiffrées.

Quel est le comportement sur des comptes existants sur lesquels la sauvegarde continue est activée ?

Quand CMK est activé, le chiffrement est également activé pour les sauvegardes continues. Une fois CMK activée, tous les comptes restaurés seront à l’avenir activés par CMK.

Quel est le comportement si CMK est activé sur un compte avec PITR et que nous restaurons le compte à un instant où CMK était désactivé ?

Dans ce cas, CMK est explicitement activé sur le compte cible restauré pour les raisons suivantes :

Une fois CMK activé sur le compte, il n’existe aucune option permettant de le désactiver.
Ce comportement est conforme à la conception actuelle de la restauration d’un compte sur lequel CMK est activée avec la sauvegarde périodique

Que se passe-t-il quand l’utilisateur révoque la clé alors que la migration CMK est en cours ?

L’état de la clé est vérifié quand le chiffrement CMK est déclenché. Si la clé dans Azure Key Vault est en règle, le chiffrement démarre et se poursuit sans aucune autre vérification. Même si la clé est révoquée ou qu’Azure Key Vault est supprimé ou indisponible, le processus de chiffrement réussit.

Pouvons-nous activer le chiffrement CMK sur notre compte de production existant ?

Oui. Étudiez attentivement la section des prérequis. Nous vous recommandons de tester tous les scénarios sur des comptes hors production d’abord et, une fois que vous êtes à l’aise, vous pouvez envisager des comptes de production.

Étapes suivantes

Découvrez plus en détail le chiffrement des données dans Azure Cosmos DB.
Vous pouvez choisir d’ajouter une deuxième couche de chiffrement avec vos propres clés. Pour en savoir plus, consultez l’article Clés gérées par le client.
Pour plus d’informations sur les certifications Microsoft, consultez le Centre de confidentialité Azure.

Partager via