Partage via

Clés gérées 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, ou vous pouvez utiliser plusieurs options pour gérer de près 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). L’utilisation du chiffrement d’Azure Monitor est identique à celle du chiffrement Stockage Azure.

Pour gérer le cycle de vie des clés et pouvoir révoquer l’accès à vos données, vous pouvez chiffrer les données avec votre propre clé en utilisant Azure Key Vault.

Les clés gérées par le client sont disponibles sur des clusters dédiés et vous fournissent un niveau élevé de protection et de contrôle. Les données sont chiffrées deux fois dans le stockage : au niveau du service en utilisant des clés gérées par Microsoft ou des clés gérées par le client, et au niveau de l’infrastructure en tirant parti deux algorithmes de chiffrement différents et de deux clés différentes. Le Chiffrement double permet d’éviter un scénario impliquant une compromission possible des clés ou des algorithmes de chiffrement. Les clusters dédiés vous permettent é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 des requêtes sont conservées dans un cache à chaud (SSD) pour une meilleure efficacité des requêtes. Les données SSD sont chiffrées avec des clés Microsoft, peu importe si vous configurez les clés gérées par le client, mais votre contrôle de l’accès à SSD respecte la révocation de clé.

Important

Les clusters dédiés utilisent un modèle de tarification de niveau d’engagement d’au moins 100 Go/jour.

Fonctionnement des clés gérées 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 de clés gérées par le client sur plusieurs espaces de travail, une ressource de cluster Log Analytics sert de connexion d’identité intermédiaire entre votre instance 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 instance 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 le cluster lorsque identity type est réglé sur SystemAssigned. Cette identité est utilisée ultérieurement pour accorder un accès de stockage à votre coffre-fort de clés pour le chiffrement et le déchiffrement des données.
  • L'identité gérée attribuée à l'utilisateur vous permet de configurer les clés gérées par le client lors de la création du cluster, lorsque identity type est défini sur UserAssigned, et de lui accorder des autorisations dans votre coffre-fort de clés avant la création du cluster.

Vous pouvez configurer des clés gérées par le client sur un nouveau cluster ou sur un cluster existant lié à des espaces de travail et qui ingère déjà des donné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 les clés Microsoft. La configuration de la clé gérée par le client n’affecte pas vos requêtes qui continuent de s’exécuter en toute transparence sur les données anciennes et nouvelles. Vous pouvez dissocier les espaces de travail d’un cluster à tout moment. Vos 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é des clés gérées par le client est régionale. Vos Azure Key Vault, cluster et espaces de travail liés doivent se trouver dans la même région, mais ils peuvent être dans des abonnements différents.

Capture d’écran de la vue d’ensemble d’une clé gérée par le client.

  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 instance Key Vault et, si vous utilisez 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.

Capture d’écran des paramètres de suppression réversible et de protection contre la suppression définitive.

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. Configurez identity type la propriété à SystemAssigned ou UserAssigned lors de la création de votre cluster afin d'autoriser l'accès à votre coffre-fort de clés pour les opérations de chiffrement et de déchiffrement des données.

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

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

Remarque

Le type d’identité peut être modifié une fois le cluster créé sans interruption de l’ingestion ou des requêtes avec les considérations suivantes

  • Mise à jour de SystemAssigned vers UserAssigned—accorder l’identité UserAssign identity dans Key Vault, puis mettre à jour identity type dans le cluster
  • Mise à jour UserAssigned vers SystemAssigned—Étant donné que l’identité managée affectée par le système créée après la mise à jour du cluster identity type avec SystemAssigned, les étapes suivantes doivent être suivies
    1. Mettez à jour le cluster et supprimez le jeu de clés— keyVaultUri, keyNameet keyVersion avec la valeur « »
    2. Mettre à jour des clusters identity type à SystemAssigned
    3. Mettre à jour Key Vault et accorder des autorisations à l’identité
    4. Mettre à jour la clé dans le cluster

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ôle, vous devez disposer d’un rôle avec des autorisations Microsoft.Authorization/roleAssignments/write et Microsoft.Authorization/roleAssignments/delete, telles que Administrateur de l’accès utilisateur ou Propriétaire.

    1. Ouvrez votre instance Key Vault dans le Portail Azure, sélectionnez Paramètres>Configuration de l’accès>Contrôle d’accès en fonction du rôle Azure et Appliquer
    2. Cliquez sur le bouton Go to access control (IAM) et ajoutez l'attribution de rôles à l'utilisateur(-trice) du service de chiffrement de Key Vault Crypto.
    3. Sélectionnez identité managée sous l’onglet Membres, puis sélectionnez l’abonnement pour l’identité et l’identité en tant que membre

    Capture d'écran des autorisations Grant Key Vault RBAC.

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

    Ouvrez votre instance Key Vault dans le Portail Azure, puis sélectionnez Stratégies d’accès>Stratégie d’accès au coffre>+ Ajouter une stratégie d’accès pour créer une stratégie avec ces paramètres :

    • 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é

    Capture d’écran des autorisations de stratégie d’accès Grant Key Vault.

    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 version 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.

Capture d’écran de l’octroi d’autorisations d’accès au coffre de clés.

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 identity type 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 apportées aux 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 – mettre à jour "keyVaultProperties" propriétés dans le cluster et omettre "keyVersion" propriété, ou la définir sur "". Le stockage utilise automatiquement la dernière version de clé.
  • Mise à jour explicite de la version de la clé – mise à jour "keyVaultProperties" propriétés et mise à jour de la version de la clé dans "keyVersion" propriété. La rotation des clés nécessite une mise à jour explicite de "keyVersion" propriété dans le cluster. Pour découvrir plus d’informations, 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 pendant et 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.

Capture d'écran de l'enregistrement du classeur.

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 de sauvegarde dans le stockage sont considérées comme des artefacts de service et il est possible que leur format varie.
  • 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.

  • Lockbox ne s’applique pas aux tables avec le plan Auxiliaire.

  • 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 chiffrement double 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 des clés Microsoft. Vous pouvez interroger les données ingérées avant et après la configuration de 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 identity type 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.

  • Le plan de table Auxiliaire ne prend pas en charge les clés gérées par le client. Les données des tables ayant le plan Auxiliaire sont chiffrées avec des clés gérées par Microsoft, même si vous protégez les données dans le reste de votre espace de travail Log Analytics en utilisant votre clé de chiffrement.

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 à Key Vault : la fréquence à laquelle le stockage de cluster accède à 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 si l’espace de travail est lié à un autre cluster.

  • Si vous créez un cluster et spécifiez immédiatement KeyVaultProperties, il est possible que l’opération échoue jusqu’à ce qu’une identité soit affectée au 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 dans un état 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 – KeyVaultProperties n’est pas vide, mais son format est incorrect. Consultez mise à jour de l’identificateur de la clé.
    • 400 – Désolé... Nous n’avons pas pu valider 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 – Désolé... Nous ne pouvons pas exécuter l’opération pour le moment. Attendez que l’opération asynchrone se termine et réessayez.
    • 400 – Le cluster est dans un état 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 cette opération génère un conflit, le cluster se trouve dans le processus de suppression.

Étapes suivantes