Clé gérée par le client dans Azure Monitor

  • Article

Les données dans Azure Monitor sont chiffrées avec des clés gérées par Microsoft. Vous pouvez utiliser votre propre clé de chiffrement pour protéger les données et les requêtes enregistrées dans vos espaces de travail. Les clés gérées par le client dans Azure Monitor vous offrent une plus grande flexibilité pour gérer les contrôles d’accès aux journaux. Une fois les clés configurées, les nouvelles données ingérées dans les espaces de travail liés sont chiffrées avec votre clé stockée dans Azure Key Vault ou dans le HSM managé Azure Key Vault.

Passez en revue les limitations et contraintes avant la configuration.

Vue d’ensemble des clés gérées par le client

Le chiffrement au repos est une exigence de sécurité et de confidentialité courante dans les organisations. Si vous pouvez laisser Azure gérer complètement le chiffrement au repos, plusieurs options vous permettent de gérer le chiffrement et des clés de chiffrement.

Azure Monitor veille à ce que toutes les données et requêtes enregistrées soient chiffrées au repos à l’aide de clés gérées par Microsoft (MMK). Vous pouvez chiffrer les données avec votre propre clé dans Azure Key Vault, ce qui vous permet de contrôler le cycle de vie des clés, et révoquer l’accès à vos données. L’utilisation du chiffrement par Azure Monitor est identique à celle du chiffrement par Stockage Azure.

La clé gérée par le client est fournie sur des clusters dédiés offrant un niveau de protection et un contrôle plus élevés. Les données sont chiffrées deux fois dans le stockage : une fois au niveau du service à l’aide de clés managées par Microsoft ou d’une clé gérée par le client, et une fois au niveau de l’infrastructure à l’aide de deux algorithmes de chiffrement différents et de deux clés différentes. Le double chiffrement permet d’éviter un scénario impliquant une possible compromission d’un algorithme ou d’une clé de chiffrement. Le cluster dédié vous permet également de protéger les données avec Lockbox.

Les données ingérées au cours des 14 derniers jours ou les données récemment utilisées dans les requêtes sont conservées dans un cache à chaud (SSD) pour une meilleure efficacité des requêtes. Les données SSD restent chiffrées avec des clés Microsoft, quelle que soit la configuration de clé gérée par le client, mais votre contrôle de l’accès à SSD est sujet à une révocation de clé.

Le modèle tarifaire des clusters dédiés Log Analytics nécessite un niveau d’engagement à partir de 100 Go par jour.

Fonctionnement de la clé gérée par le client dans Azure Monitor

Azure Monitor utilise l’identité pour accorder l’accès à votre Azure Key Vault. L’identité du cluster Log Analytics est prise en charge au niveau du cluster. Pour permettre l’utilisation d’une clé gérée par le client sur plusieurs espaces de travail, une ressource de cluster Log Analytics s’exécute en tant que connexion d’identité intermédiaire entre votre Key Vault et vos espaces de travail Log Analytics. Le stockage du cluster utilise l’identité managée associée au cluster pour s’authentifier auprès de votre coffre Azure Key Vault via Microsoft Entra ID.

Les clusters prennent en charge deux types d’identités managées : affectée par le système et affectée par l’utilisateur, tandis qu’une seule identité peut être définie dans un cluster en fonction de votre scénario.

  • L’identité managée affectée par le système est plus simple et générée automatiquement avec la création du cluster lorsque le type de l’identité est défini sur « SystemAssigned ». Cette identité peut être utilisée ultérieurement pour autoriser l’accès au stockage à votre coffre de clés pour les opérations d’enveloppage et désenveloppage.
  • L’identité managée affectée par l’utilisateur vous permet de configurer la clé gérée par le client lors de la création du cluster, lorsque vous lui accordez des autorisations dans votre Key Vault avant la création du cluster.

Vous pouvez appliquer une configuration de clé gérée par le client à un nouveau cluster, ou à un cluster existant lié à des espaces de travail et à des données ingérées. Les nouvelles données ingérées dans les espaces de travail liés sont chiffrées avec votre clé, et les anciennes données ingérées avant la configuration restent chiffrées avec la clé Microsoft. Vos requêtes ne sont pas affectées par la configuration de la clé gérée par le client, et sont exécutées en toute transparence sur les données anciennes et nouvelles. Vous pouvez dissocier les espaces de travail du cluster à tout moment. Les nouvelles données ingérées après la dissociation sont chiffrées avec la clé Microsoft, et les requêtes sont exécutées en toute transparence sur les données anciennes et nouvelles.

Important

La capacité de clé gérée par le client est régionale. Azure Key Vault, le cluster et les espaces de travail liés doivent se trouver dans la même région, mais ils peuvent être dans des abonnements différents.

Screenshot of customer-managed key overview.

  1. Key Vault
  2. Ressource de cluster Log Analytics ayant une identité managée avec des autorisations sur Key Vault. L’identité est propagée vers le stockage de cluster dédié sous-jacent.
  3. Cluster dédié
  4. Espaces de travail liés au cluster dédié

Opération de clés de chiffrement

Trois types de clés interviennent dans le chiffrement des données du stockage :

  • « KEK » : clé de chiffrement de clé (votre clé gérée par le client)
  • « AEK » : clé de chiffrement de compte
  • « DEK » : clé de chiffrement de données

Les règles suivantes s’appliquent :

  • Le stockage de cluster a une clé de chiffrement unique pour chaque compte de stockage, connue sous le nom de clé « AEK ».
  • La clé « AEK » est utilisée pour dériver les clés « DEK », qui sont utilisées pour chiffrer chaque bloc de données écrit sur le disque.
  • Quand vous configurez une clé dans votre Key Vault et que vous avez mis à jour les détails de la clé dans le cluster, le stockage du cluster effectue des requêtes 'wrap' et 'unwrap' sur la clé « AEK » pour le chiffrement et le déchiffrement.
  • Votre clé « KEK » ne quitte jamais votre Key Vault et, dans le cas d’un « HSM » managé, elle ne quitte jamais le matériel.
  • Stockage Azure utilise une identité managée associée à la ressource Cluster pour l’authentification. Il accède à Azure Key Vault via Microsoft Entra ID.

Étapes de configuration de clé gérée par le client

  1. Création du coffre de clés Azure et stockage de la clé
  2. Création du cluster
  3. Octroi d’autorisations d’accès à votre coffre de clés
  4. Mise à jour du cluster avec les détails de l’identificateur de clé
  5. Liaison d’espaces de travail

La configuration de clé gérée par le client n’est pas actuellement prise en charge dans le portail Azure, et le provisionnement peut s’effectuer par le biais de requêtes PowerShell, CLI ou REST.

Stockage de la clé de chiffrement (« KEK »)

Un portefeuille de produits Azure Key Management répertorie les coffres et les HSM managés qui peuvent être utilisés.

Créez ou utilisez un coffre Azure Key Vault existant dans la région où le cluster est planifié. Dans votre coffre de clés, générez ou importez une clé à utiliser pour le chiffrement des journaux. Le coffre de clés Azure Key Vault doit être configuré comme récupérable pour protéger votre clé et l’accès à vos données dans Azure Monitor. Vous pouvez vérifier cette configuration dans les propriétés de votre coffre de clés : les fonctionnalités de suppression réversible et de protection contre la suppression définitive doivent être activées.

Screenshot of soft delete and purge protection settings.

Ces paramètres peuvent être mis à jour dans Key Vault par le biais de l’interface CLI et de PowerShell :

Créer un cluster

Les clusters utilisent l’identité managée pour le chiffrement des données avec votre Key Vault. Quand vous créez un cluster, définissez sa propriété d’identité type à la valeur SystemAssigned afin d’autoriser l’accès à votre Key Vault pour les opérations 'wrap' et 'unwrap'.

Paramètres d’identité dans le cluster pour l’identité managée affectée par le système

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Suivez la procédure illustrée dans l’article sur les Clusters dédiés.

Octroi d’autorisations d’accès au coffre de clés

Il existe deux modèles d’autorisation dans Key Vault pour accorder l’accès à votre cluster et à votre stockage sous-jacent—le contrôle d’accès en fonction du rôle Azure (Azure RBAC) et les stratégies d’accès Vault (héritées).

  1. Attribuez Azure RBAC que vous contrôlez (recommandé)

    Pour ajouter des attributions de rôles, vous devez disposer des autorisations Microsoft.Authorization/roleAssignments/write et Microsoft.Authorization/roleAssignments/delete, telles que User Access Administrator ou Owner.

    Ouvrez votre Key Vault dans le portail Azure, cliquez sur Configuration d’accès dans Paramètres et sélectionnez l’option de contrôle d’accès en fonction du rôle Azure. Entrez ensuite Contrôle d’accès (IAM) et ajoutez l’attribution du rôle d’utilisateur Key Vault Crypto Service Encryption.

    Screenshot of Grant Key Vault RBAC permissions.

  2. Attribuer une stratégie d'accès au coffre-fort (ancienne)

    Ouvrez votre Key Vault dans le Portail Azure, puis cliquez sur Stratégies d’accès, sélectionnez Stratégie d’accès au coffre puis cliquez sur + Ajouter une stratégie d'accès pour créer une stratégie avec les paramètres ci-après :

    • Autorisations de clé : sélectionnez Obtenir, Inclure la clé et Ne pas inclure la clé.
    • Sélectionner le principal : selon le type d’identité utilisée dans le cluster (identité managée affectée par le système ou par l’utilisateur)
      • Identité managée affectée par le système : entrez le nom du cluster ou l’ID du principal de cluster
      • Identité managée affectée par l’utilisateur : entrez le nom de l’identité

    Screenshot of Grant Key Vault access policy permissions.

    L’autorisation Obtenir est nécessaire pour vérifier que votre coffre de clés est configuré comme récupérable pour protéger votre clé et l’accès à vos données Azure Monitor.

Mettre à jour le cluster avec les détails de l’identificateur de clé

Toutes les opérations sur le cluster requièrent l’autorisation de l’action Microsoft.OperationalInsights/clusters/write. Cette autorisation peut être accordée via le propriétaire ou le contributeur qui contient l’action */write ou via le rôle Contributeur Log Analytics qui contient l’action Microsoft.OperationalInsights/*.

Cette étape met à jour le stockage de cluster dédié avec la clé et la version à utiliser pour les opérations 'wrap' et 'unwrap' sur la clé « AEK ».

Important

  • La rotation des clés peut être automatique ou nécessiter une mise à jour des clés explicite. Consultez Rotation des clés pour déterminer l’approche adaptée à vos besoins avant de mettre à jour les détails relatifs à l’identificateur de clé dans le cluster.
  • La mise à jour du cluster ne doit pas inclure les détails relatifs à l’identité et à l’identificateur de clé dans la même opération. S’il vous faut les mettre à jour, cette mise à jour doit faire l’objet de deux opérations consécutives.

Screenshot of Grant Key Vault permissions.

Mettez à jour la propriété KeyVaultProperties du cluster avec les détails de l’identificateur de clé.

L’opération est asynchrone et peut prendre du temps.

S/O

Important

Cette étape ne doit être exécutée qu’après le provisionnement du cluster. Si vous liez des espaces de travail et ingérez des données avant cet approvisionnement, les données ingérées sont définitivement supprimées.

Pour effectuer cette opération, vous devez disposer des autorisations d’écriture (« write ») sur votre espace de travail et votre cluster. et comprend Microsoft.OperationalInsights/workspaces/write et Microsoft.OperationalInsights/clusters/write.

Suivez la procédure illustrée dans l’article sur les Clusters dédiés.

Révocation de la clé

Important

  • La méthode recommandée pour révoquer l’accès à vos données consiste à désactiver votre clé ou à supprimer la stratégie d’accès dans votre Key Vault.
  • La définition de identitytype du cluster sur None révoque également l’accès à vos données, mais cette approche n’est pas recommandée, car vous ne pouvez pas l’annuler sans contacter le support.

Le stockage de cluster respecte toujours les modifications des autorisations de clé dans l’heure qui suit. Il devient alors indisponible. Les nouvelles données ingérées dans les espaces de travail liés sont supprimées et ne sont pas récupérables. Les données ne sont pas accessibles dans ces espaces de travail et les requêtes échouent. Les données précédemment ingérées restent dans le stockage tant que votre cluster et vos espaces de travail ne sont pas supprimés. Les données inaccessibles sont régies par la stratégie de conservation des données, et sont vidées à la fin de la durée de conservation. Les données ingérées au cours des 14 derniers jours et les données récemment utilisées dans les requêtes sont également conservées dans un cache à chaud (SSD) pour l’efficacité des requêtes. Les données sur SSD sont supprimées lors d’une opération de révocation de clé et deviennent inaccessibles. Le stockage de cluster tente périodiquement d’atteindre votre coffre Key Vault pour effectuer le wrapping et l’unwrapping et, quand la clé est activée, l’opération unwrap réussit, les données du SSD sont rechargées à partir du stockage, et l’ingestion et la requête des données sont relancées dans les 30 minutes qui suivent.

Rotation des clés

La rotation des clés propose deux modes :

  • Autorotation : mettez à jour votre cluster avec "keyVaultProperties", mais n’incluez pas la propriété "keyVersion" (si vous l’incluez, définissez-la sur la valeur ""). Le stockage utilise automatiquement la dernière version de clé.
  • Mise à jour explicite de la version de la clé : mettez à jour votre cluster avec la version de clé dans la propriété "keyVersion". La permutation des clés nécessite une mise à jour explicite de "keyVaultProperties" dans le cluster. Consultez Mettre à jour le cluster avec les détails de l’identificateur de clé. Si vous générez la nouvelle version de la clé dans Key Vault sans mettre à jour la clé dans le cluster, le stockage de cluster continue d’utiliser votre clé précédente. Si vous désactivez ou supprimez votre ancienne clé avant d’en mettre une à jour dans le cluster, vous passez à l’état révocation de clé.

Toutes vos données restent accessibles après l’opération de rotation des clés. Les données sont toujours chiffrées avec la clé de chiffrement de compte (« AEK »), qui est chiffrée avec votre nouvelle version de clé de chiffrement de clé (« KEK ») dans Key Vault.

Clé gérée par le client pour les requêtes enregistrées et les alertes de recherche dans les journaux

Le langage de requête utilisé dans Log Analytics est expressif et peut contenir des informations sensibles dans les commentaires ou dans la syntaxe des requêtes. Certaines organisations requièrent que ces informations soient protégées dans le cadre de la stratégie de clé gérée par le client, et vous devez sauvegarder vos requêtes en les chiffrant avec votre clé. Azure Monitor vous permet de stocker des requêtes enregistrées et des alertes de recherche dans les journaux chiffrées avec votre clé dans votre propre compte de stockage lorsqu'elles sont liées à votre espace de travail.

Clé gérée par le client pour les classeurs

Avec les considérations mentionnées pour Clé gérée par le client pour les requêtes enregistrées et les alertes de recherche dans les journaux, Azure Monitor vous permet de stocker les requêtes de classeur chiffrées avec votre clé dans votre propre compte de stockage, lorsque vous sélectionnez Enregistrer le contenu sur un compte de stockage Azure dans l'opération « Enregistrer » du classeur.

Screenshot of Workbook save.

Remarque

Les requêtes restent chiffrées avec la clé Microsoft (« MMK ») dans les scénarios suivants, quelle que soit la configuration de la clé gérée par le client : tableaux de bord Azure, Azure Logic App, Azure Notebooks et Automation Runbooks.

Lors de la liaison de votre compte de stockage pour les requêtes enregistrées, le service stocke les requêtes enregistrées et les requêtes d'alertes de recherche dans les journaux dans votre compte de stockage. En contrôlant la politique de chiffrement au repos de votre compte de stockage, vous pouvez protéger les requêtes enregistrées et enregistrer les alertes de recherche dans les journaux avec une clé gérée par le client. Toutefois, vous êtes responsable des coûts associés à ce compte de stockage.

Considérations à prendre en compte avant de définir la clé gérée par le client pour les requêtes

  • Vous devez disposer des autorisations d’écriture (« write ») sur votre espace de travail et votre compte de stockage.
  • Veillez à créer votre compte de stockage dans la même région que celle où se trouve votre espace de travail Log Analytics, avec le chiffrement par clé gérée par le client. Cela est important, car les requêtes enregistrées sont stockées dans le stockage de table et ne peuvent être chiffrées que lors de la création du compte de stockage.
  • Les requêtes enregistrées dans un pack de requêtes ne sont pas chiffrées avec la clé gérée par le client. Sélectionnez plutôt Enregistrer en tant que requête héritée lors de l’enregistrement de requêtes, afin de les protéger avec une clé gérée par le client.
  • Les requêtes enregistrées dans le stockage sont considérées comme des artefacts de service et leur format peut changer.
  • La liaison d’un compte de stockage pour les requêtes supprime les requêtes enregistrées existantes de votre espace de travail. Copy enregistre les requêtes dont vous avez besoin avant cette configuration. Vous pouvez afficher vos requêtes enregistrées à l'aide de PowerShell.
  • L’historique des requêtes et « épingler au tableau de bord » n’est pas pris en charge lors de la liaison Stockage compte pour les requêtes.
  • Vous pouvez lier un seul compte de stockage à un espace de travail pour les requêtes enregistrées et les requêtes d’alertes de recherche dans les journaux.
  • Les alertes de recherche dans les journaux sont enregistrées dans le stockage d’objets blob, et le chiffrement par clé gérée par le client peut être configuré lors de la création du compte de stockage ou plus tard.
  • Les alertes de recherche dans les journaux déclenchées ne contiendront pas de résultats de recherche ou de requête d’alerte. Vous pouvez utiliser les dimensions d’alerte pour obtenir du contexte dans les alertes déclenchées.

Configurer BYOS pour les requêtes enregistrées

Associez un compte de stockage pour les requêtes afin de conserver les requêtes enregistrées dans votre compte de stockage.

N/A

Après la configuration, toute nouvelle requête de recherche enregistrée sera sauvegardée dans votre stockage.

Configurer BYOS pour les requêtes d’alertes de recherche dans les journaux

Liez un compte de stockage pour les alertes afin d’y conserver les requêtes d’alertes de recherche dans les journaux.

N/A

Après la configuration, toute nouvelle requête d’alerte sera sauvegardée dans votre stockage.

Customer Lockbox

Lockbox vous permet d’approuver ou de rejeter la demande d’un ingénieur Microsoft d’accéder à vos données lors d’une demande de support.

Lockbox est fourni dans un cluster dédié dans Azure Monitor, où l’autorisation d’accéder aux données est accordée au niveau de l’abonnement.

En savoir plus sur Customer Lockbox pour Microsoft Azure

Opérations de clés gérées par le client

Une clé gérée par le client est fournie sur un cluster dédié et ces opérations sont mentionnées dans l’article de cluster dédié

  • Obtenir tous les clusters dans un groupe de ressources
  • Obtenir tous les clusters dans un abonnement
  • Mettre à jour la réservation de capacité dans un cluster
  • Mettre à jour la propriété billingType dans le cluster
  • Dissocier un espace de travail d’un cluster
  • Supprimer un cluster

Limitations et contraintes

  • Un maximum de cinq clusters actifs peut être créé dans chaque région et abonnement.

  • Un nombre maximal de sept clusters réservés (actifs ou récemment supprimés) peut exister dans chaque région et abonnement.

  • Un maximum de 1 000 espaces de travail Log Analytics peuvent être liés à un cluster.

  • Un maximum de deux opérations de liaison d’espace de travail sur un espace de travail particulier est autorisé sur une période de 30 jours.

  • Le déplacement d’un cluster vers un autre groupe de ressources ou un autre abonnement n’est pas pris en charge actuellement.

  • La mise à jour du cluster ne doit pas inclure à la fois les détails relatifs à l’identité et à l’identificateur de clé dans la même opération. S’il vous faut les mettre à jour, cette mise à jour doit faire l’objet de deux opérations consécutives.

  • Actuellement, Lockbox n’est pas disponible en Chine.

  • Le double chiffrement est automatiquement configuré pour les clusters créés depuis octobre 2020 dans les régions prises en charge. Pour vérifier si votre cluster est configuré pour le chiffrement double, envoyez une requête GET sur le cluster et observez la valeur de isDoubleEncryptionEnabled. Une valeur true correspond aux clusters pour lesquels le chiffrement double est activé.

    • Si vous créez un cluster et recevez une erreur « region-name ne prend pas en charge le chiffrement double pour les clusters », vous pouvez toujours créer le cluster sans le double chiffrement en ajoutant "properties": {"isDoubleEncryptionEnabled": false} dans le corps de la requête REST.
    • Les paramètres de double chiffrement ne peuvent pas être modifiés une fois le cluster créé.

La suppression d’un espace de travail lié est autorisée tant que celui-ci est lié au cluster. Si vous décidez de récupérer l’espace de travail pendant la période de suppression réversible, celui-ci revient à son état précédent et reste lié au cluster.

  • Le chiffrement par clé gérée par le client s’applique aux données nouvellement ingérées après l’heure de la configuration. Les données ingérées avant la configuration restent chiffrées avec une clé Microsoft. Vous pouvez interroger les données ingérées avant et après la configuration la clé gérée par le client en toute simplicité.

  • Le coffre de clés Azure doit être configuré comme récupérable. Les propriétés ci-après, qui ne sont pas activées par défaut, doivent être configurées à l’aide de l’interface CLI ou de PowerShell :

  • Votre coffre Azure Key Vault, le cluster et les espaces de travail doivent se trouver dans la même région et dans le même locataire Microsoft Entra, mais peuvent être dans des abonnements différents.

  • La définition de identitytype du cluster sur None révoque également l’accès à vos données, mais cette approche n’est pas recommandée, car vous ne pouvez pas l’annuler sans contacter le support. La méthode recommandée pour révoquer l’accès à vos données est la révocation de clé.

  • Vous ne pouvez pas utiliser une clé gérée par le client avec une identité managée affectée par l’utilisateur si votre coffre de clés se trouve dans Azure Private Link (réseau virtuel). Dans ce scénario, vous pouvez utiliser une identité managée affectée par le système.

  • Les requêtes asynchrones de travaux de recherche ne sont pas prises en charge dans le scénario de clé gérée par le client actuellement.

Dépannage

  • Le comportement varie selon la disponibilité du Key Vault :

    • Fonctionnement normal : le stockage met en cache la clé « AEK » pendant de courtes périodes et revient régulièrement dans Key Vault pour l’opération unwrap.

    • Erreurs de connexion à Key Vault : le stockage gère les erreurs temporaires (expirations de délai d’attente, échecs de connexion, problèmes de système DNS) en autorisant les clés à rester en cache pendant la durée du problème de disponibilité, et il compense les problèmes de blocage et de disponibilité. Les fonctionnalités de requête et d’ingestion se poursuivent sans interruption.

  • Taux d’accès au Key Vault : la fréquence à laquelle le stockage de cluster accède au Key Vault pour les opérations wrap et unwrap est comprise entre 6 et 60 secondes.

  • Si vous mettez à jour votre cluster alors qu’il est en cours de provisionnement ou de mise à jour, la mise à jour échoue.

  • Si vous recevez une erreur de conflit lors de la création d’un cluster, il se peut qu’un cluster du même nom ait été supprimé au cours des 14 derniers jours et laissé à l’état réservé. Le nom du cluster supprimé devient disponible 14 jours après la suppression.

  • La liaison d’un espace de travail à un cluster échoue s’il est lié à un autre cluster.

  • Si vous créez un cluster et spécifiez immédiatement KeyVaultProperties, l’opération peut échouer jusqu’à ce que l’identité soit affectée dans le cluster et accordée à Key Vault.

  • Si vous mettez à jour le cluster existant avec KeyVaultProperties et que la stratégie d’accès de clé « Obtenir » est manquante dans Key Vault, l’opération échoue.

  • Si vous ne parvenez pas à déployer votre cluster, vérifiez que votre Azure Key Vault, le cluster et les espaces de travail liés se trouvent dans la même région. Ils peuvent être liés à des abonnements différents.

  • Si vous permutez votre clé dans Key Vault sans mettre à jour les détails du nouvel identificateur de clé dans le cluster, celui-ci continue à utiliser votre clé précédente, et vos données deviennent inaccessibles. Mettez à jour les détails du nouvel identificateur de clé dans le cluster pour reprendre l’ingestion des données et la requête. Vous pouvez mettre à jour la version de clé avec "''" pour que le stockage utilise toujours automatiquement la version de clé la plus récente.

  • Certaines opérations sont longues et peuvent prendre du temps, notamment les opérations de création du cluster, de mise à jour de la clé du cluster et de suppression du cluster. Vous pouvez vérifier l’état de l’opération en envoyant une requête GET au cluster ou à l’espace de travail et en observant la réponse. Par exemple, l’espace de travail dissocié n’a pas de clusterResourceId sous features.

  • Messages d’erreur

    Mise à jour d’un cluster

    • 400 — Le cluster est en cours de suppression. L’opération asynchrone est en cours. Le cluster doit effectuer cette opération avant l’exécution d’une opération de mise à jour.
    • 400 — Les propriétés KeyVaultProperties ne sont pas vides, mais leur format est incorrect. Consultez mise à jour de l’identificateur de la clé.
    • 400 — Échec de validation de la clé dans Key Vault. Peut être dû à un manque d’autorisations ou à l’inexistence de la clé. Vérifiez que vous avez défini la clé et la stratégie d’accès dans Key Vault.
    • 400 — La clé n’est pas récupérable. La suppression réversible et la protection contre le vidage doivent être définis pour Key Vault. Consulter la documentation sur Key Vault
    • 400 — Impossible d’exécuter l’opération pour le moment. Attendez que l’opération asynchrone se termine et réessayez.
    • 400 — Le cluster est en cours de suppression. Attendez que l’opération asynchrone se termine et réessayez.

    Obtention de cluster

    • 404--Cluster introuvable, le cluster a peut-être été supprimé. Si vous essayez de créer un cluster portant ce nom et que cela génère un conflit, le cluster se trouve dans un processus de suppression.

Étapes suivantes