Partager 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 dans vos espaces de travail. Les clés gérées par le client dans Azure Monitor vous permettent de contrôler le cycle de vie des clés de chiffrement et d’accéder aux journaux. Une fois configurées, les nouvelles données ingérées dans les espaces de travail liés sont chiffrées avec votre clé dans Azure Key Vault ou dans le module HSM géré Azure Key Vault (module de sécurité matérielle).

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

Le chiffrement des données 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 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 contrôler le cycle de vie des clés avec la possibilité de révoquer les données d’accès, chiffrez les données avec votre propre clé dans Azure Key Vault ou azure Key Vault Managed HSM. La fonctionnalité de clés gérées par le client est disponible sur les clusters dédiés et vous offre un niveau de protection et de contrôle plus élevé.

Les données ingérées dans les clusters dédiés sont chiffrées deux fois : une fois au niveau du service à l’aide de clés géré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 de compromission d’un algorithme ou d’une clé 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 gérées par 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 une identité managée pour accorder l'accès à votre clé dans Azure Key Vault. L’identité du cluster Log Analytics est prise en charge au niveau du cluster. Pour fournir des 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 quand identitytype est définie 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 identitytype est défini sur UserAssigned, et de lui accorder des autorisations dans votre coffre-fort de clés avant la création du cluster.

Configurez des clés gérées par le client sur un nouveau cluster ou un cluster dédié existant avec des espaces de travail liés qui ingèrent des données. La dissociation des espaces de travail à partir d’un cluster peut être effectuée à tout moment. Les nouvelles données ingérées aux espaces de travail liés sont chiffrées avec votre clé, et les données plus anciennes restent chiffrées avec des clés gérées par Microsoft. La configuration n’interrompt pas l’ingestion ou les requêtes, lorsque les requêtes sont effectuées de manière transparente sur les anciennes et nouvelles données. Lorsque vous dissociez les espaces de travail d’un cluster, les nouvelles données ingérées sont chiffrées avec des clés gérées par Microsoft.

Important

La fonctionnalité des clés gérées par le client est limitée à une région. Votre coffre Azure Key Vault, votre cluster dédié et vos espaces de travail liés doivent se trouver dans la même région, mais 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. Coffre-fort de clés
  2. Ressource de cluster Log Analytics disposant d’une identité managée avec des autorisations pour Key Vault : l’identité est propagée au stockage de cluster dédié sous-jacent
  3. Cluster dédié
  4. Espaces de travail liés au cluster dédié

Types de clés de chiffrement

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

  • KEK - Clé de chiffrement principale (votre clé gérée par le client)
  • AEK - Clé de chiffrement de compte
  • DEK - Clé de chiffrement des données

Les règles suivantes s’appliquent :

  • Le stockage de cluster a une clé de chiffrement unique pour chaque compte de stockage, appelé AEK.
  • L’AEK est utilisé pour dériver des clés DEK, qui sont les clés utilisées pour chiffrer chaque bloc de données écrit sur le disque.
  • Lors de la configuration de la clé gérée par le client KEK dans votre cluster, le stockage de cluster effectue des requêtes wrap et unwrap à votre coffre de clés pour le chiffrement et le déchiffrement AEK.
  • Votre KEK ne quitte jamais votre coffre de clés. Si vous stockez votre clé dans un HSM managé Azure Key Vault, elle ne laisse jamais ce matériel non plus.
  • Stockage Azure utilise une identité managée associée au 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 d’un cluster dédié
  3. Octroi d’autorisations d’accès à votre coffre de clés
  4. Mise à jour du cluster dédié avec les détails de l’identifiant de clé
  5. Liaison d’espaces de travail

Une configuration de clé gérée par le client ne prend pas en charge la configuration des détails de l’identité et de l’identificateur de clé. Effectuez ces opérations via des requêtes PowerShell, CLI ou REST .

Autorisations requises

Pour effectuer des actions liées au cluster, vous avez besoin de ces autorisations :

Action Autorisations ou rôle nécessaires
Créer un cluster dédié Autorisations Microsoft.Resources/deployments/* et Microsoft.OperationalInsights/clusters/write, fournies par le rôle intégré contributeur Log Analytics, par exemple
Modifier les propriétés du cluster Autorisations Microsoft.OperationalInsights/clusters/write, fournies par le rôle intégré contributeur Log Analytics, par exemple
Lier des espaces de travail à un cluster Autorisations Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/write et Microsoft.OperationalInsights/workspaces/linkedservices/write, fournies par le rôle intégré contributeur Log Analytics, par exemple
Vérifier l’état du lien de l’espace de travail Autorisations Microsoft.OperationalInsights/workspaces/read sur l’espace de travail, telles que fournies par le rôle intégré Lecteur Log Analytics, par exemple
Obtenir des clusters ou vérifier l’état d’approvisionnement d’un cluster Autorisations Microsoft.OperationalInsights/clusters/read, fournies par le rôle intégré Lecteur Log Analytics, par exemple
Mettre à jour le niveau d’engagement ou le type de facturation dans un cluster Autorisations Microsoft.OperationalInsights/clusters/write, fournies par le rôle intégré contributeur Log Analytics, par exemple
Accorder les autorisations nécessaires Rôle Propriétaire ou Contributeur disposant d’autorisations */write, ou rôle intégré Contributeur Log Analytics, disposant d’autorisations Microsoft.OperationalInsights/*
Dissocier un espace de travail d’un cluster Autorisations Microsoft.OperationalInsights/workspaces/linkedServices/delete, fournies par le rôle intégré contributeur Log Analytics, par exemple
Supprimer un cluster dédié Autorisations Microsoft.OperationalInsights/clusters/delete, fournies par le rôle intégré contributeur Log Analytics, par exemple

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.

Important

La meilleure pratique consiste à configurer une notification via Azure Event Grid pour répondre efficacement aux événements Azure Key Vault tels qu’une clé proche de l’expiration. Lorsque la clé expire, l’ingestion et les requêtes ne sont pas affectées, mais vous ne pouvez pas effectuer de mise à jour sur la clé tant que vous n’avez pas contacté le support technique.

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 la propriété identitytype sur SystemAssigned ou UserAssigned lors de la création de votre cluster afin d’autoriser l’accès à votre coffre Key Vault pour les opérations de chiffrement et de déchiffrement des données.

Par exemple, ajoutez ces propriétés dans le corps de la demande 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 :

  • L’identité et la clé ne peuvent pas être mises à jour simultanément pour un cluster. Mise à jour en deux opérations consécutives.
  • Lors de la mise à jour de SystemAssigned vers UserAssigned, accordez l’identité UserAssign dans Key Vault, puis mettez à jour identity dans le cluster.
  • Lors de la mise à jour de UserAssigned vers SystemAssigned, accordez l’identité SystemAssigned dans Key Vault, puis mettez à jour identity 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 coffre de clés dans le portail Azure et sélectionnez Paramètres>, Configuration de l’accès>, contrôle d’accès en fonction du rôle Azure, puis Appliquer.
    2. Sélectionnez Accéder au contrôle d’accès (IAM) et ajoutez l’attribution de rôle Utilisateur de chiffrement du service de chiffrement de coffre de clés .
    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 de l'octroi des autorisations RBAC pour Key Vault.

  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électionnez un principal en fonction du type d’identité utilisé dans le cluster (identité managée affectée par le système ou 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 la politique d’accès du 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 AEKwrap et unwrap.

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

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

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

N/A

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ériez des données avant l’approvisionnement, les données ingérées sont supprimées et ne peuvent pas être récupérées.

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

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 coffre de clés.
  • 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 système de stockage du cluster respecte toujours les modifications apportées aux autorisations de clé dans un délai d’une heure ou moins, ce qui rend le stockage 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. La stratégie de rétention des données régit les données inaccessibles et la purge lorsque la période de rétention est atteinte. 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 de l’opération de révocation de clé et sont inaccessibles. Le stockage de cluster tente d’atteindre Key Vault pour les opérations wrap et unwrap régulièrement. Une fois la clé activée et que unwrap s'exécute avec succès, les données du SSD sont rechargées depuis le stockage. La fonctionnalité d’ingestion et de requête des données est reprise dans les 30 minutes.

Rotation des clés

La rotation des clés propose deux modes :

  • Autorotation – mettre à jour les propriétés "keyVaultProperties" dans le cluster et omettre la propriété "keyVersion", ou la définir sur "". Le stockage utilise automatiquement la dernière version de clé.
  • Mise à jour explicite de la version de la clé – mettre à jour les propriétés "keyVaultProperties" et mettre à jour la version de la clé dans les propriétés "keyVersion". La rotation des clés nécessite une mise à jour explicite de la propriété "keyVersion" du 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 clé gérée par le client : tableaux de bord Azure, Azure Logic App, Azure Notebooks et Runbooks Automation.

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 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. Ce détail est important, car les requêtes enregistrées sont stockées dans le stockage de tables et peuvent uniquement être chiffrées 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 de journal déclenchées ne contiennent pas de résultats de recherche ni la requête d’alerte. Utilisez les dimensions d’alerte pour obtenir le contexte des 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 de table auxiliaire.

  • Le double chiffrement est automatiquement configuré pour les clusters créés depuis octobre 2020 dans les régions prises en charge. Vous pouvez vérifier si votre cluster est configuré pour le chiffrement double en envoyant une GET demande sur le cluster et en observant que la isDoubleEncryptionEnabled valeur est true pour les clusters avec double chiffrement activé.

    • Si vous créez un cluster et obtenez une erreur : « Le nom de région ne prend pas en charge le chiffrement double pour les clusters », vous pouvez toujours créer le cluster sans 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 Azure Key Vault, votre cluster et vos espaces de travail doivent se trouver dans la même région et le même locataire Microsoft Entra, mais ils 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 un Private-Link (réseau virtuel). Utilisez une identité managée affectée par le système dans ce scénario.

Dépannage

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

    • Le fonctionnement normal du stockage met en cache AEK pendant de courtes périodes et revient périodiquement à Key Vault unwrap.

    • Erreurs de connexion au Key Vault : le stockage gère les erreurs temporaires (délais d’attente, échecs de connexion, problèmes DNS) en permettant aux clés de rester en cache pendant le problème de disponibilité, et elle surmonte les fluctuations et les problèmes 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 du 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 pendant qu’il est en état d’approvisionnement ou en cours de mise à jour, la mise à jour échoue.

  • Si vous obtenez une erreur de conflit lors de la création d’un cluster, un cluster portant le même nom peut avoir été supprimé au cours des 14 derniers jours et son nom réservé. Les noms de cluster supprimés deviennent disponibles 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, l’opération peut échouer 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é Get 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 faites pivoter votre clé dans Key Vault et que vous ne mettez pas à jour les nouveaux détails de l’identificateur de clé dans le cluster, le cluster continue à utiliser la clé précédente et vos données sont inaccessibles. Mettez à jour les nouveaux détails de l’identificateur de clé dans le cluster pour reprendre l’ingestion et la fonctionnalité de requête des données. Mettez à jour la version de clé avec '' notation pour garantir que le stockage utilise toujours la dernière version de clé automatiquement.

  • 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 GET demande au cluster ou à l’espace de travail et en observant la réponse. Par exemple, un espace de travail non lié n’a pas le 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