Delen via

Door de klant beheerde Azure Monitor-sleutels

  • Artikel

Gegevens in Azure Monitor worden versleuteld met door Microsoft beheerde sleutels. U kunt uw eigen versleutelingssleutel gebruiken om gegevens in uw werkruimten te beveiligen. Door de klant beheerde sleutels in Azure Monitor bieden u controle over de levenscyclus van de versleutelingssleutel en toegang tot logboeken. Na de configuratie worden nieuwe gegevens die zijn opgenomen in gekoppelde werkruimten versleuteld met uw sleutel in Azure Key Vault of met Azure Key Vault beheerd 'HSM'.

Overzicht van door de klant beheerde sleutel

Data Encryption at Rest is een algemene privacy- en beveiligingsvereiste in organisaties. U kunt Azure inactieve versleuteling volledig laten beheren of verschillende opties gebruiken om versleuteling en versleutelingssleutels nauwkeurig te beheren.

Azure Monitor zorgt ervoor dat alle gegevens en opgeslagen query's at rest worden versleuteld met behulp van door Microsoft beheerde sleutels (MMK). Het gebruik van versleuteling van Azure Monitor is identiek aan de manier waarop Azure Storage-versleuteling werkt.

Als u de levenscyclus van de sleutel wilt beheren met de mogelijkheid om toegangsgegevens in te trekken, versleutelt u gegevens met uw eigen sleutel in Azure Key Vault of beheerde HSM van Azure Key Vault. De mogelijkheid voor door de klant beheerde sleutels is beschikbaar op toegewezen clusters en biedt u een hoger beveiligings- en beheerniveau.

Gegevens die worden opgenomen in toegewezen clusters, worden tweemaal versleuteld: op serviceniveau met behulp van door Microsoft beheerde sleutels of door de klant beheerde sleutels, en op infrastructuurniveau, met behulp van twee verschillende versleutelingsalgoritmen en twee verschillende sleutels. Dubbele versleuteling beschermt tegen een scenario waarbij een van de versleutelingsalgoritmen of sleutels wordt aangetast. Met toegewezen clusters kunt u ook gegevens beveiligen met Lockbox.

Gegevens die in de afgelopen 14 dagen zijn opgenomen of onlangs worden gebruikt in query's, worden bewaard in hot-cache (ssd-back) voor query-efficiëntie. SSD-gegevens worden versleuteld met door Microsoft beheerde sleutels, ongeacht of u door de klant beheerde sleutels configureert, maar uw controle over SSD-toegang voldoet aan het intrekken van sleutels.

Belangrijk

Toegewezen clusters maken gebruik van een prijsmodel voor toezeggingscategorieën van ten minste 100 GB per dag.

Hoe door de klant beheerde sleutels werken in Azure Monitor

Azure Monitor maakt gebruik van een beheerde identiteit om toegang te verlenen tot uw sleutel in Azure Key Vault. De identiteit van de Log Analytics-clusters wordt ondersteund op clusterniveau. Als u door de klant beheerde sleutels wilt bieden voor meerdere werkruimten, fungeert een Log Analytics-clusterresource als een tussenliggende identiteitsverbinding tussen uw Key Vault en uw Log Analytics-werkruimten. De opslag van het cluster maakt gebruik van de beheerde identiteit die is gekoppeld aan het cluster om te verifiëren bij uw Azure Key Vault via Microsoft Entra-id.

Clusters ondersteunen twee beheerde identiteitstypen: door het systeem toegewezen en door de gebruiker toegewezen, terwijl één identiteit kan worden gedefinieerd in een cluster, afhankelijk van uw scenario.

  • Door het systeem toegewezen beheerde identiteit is eenvoudiger en automatisch gegenereerd met cluster wanneer identity type deze is ingesteld op SystemAssigned. Deze identiteit wordt later gebruikt om opslagtoegang te verlenen tot uw Key Vault voor gegevensversleuteling en -ontsleuteling.
  • Met door de gebruiker toegewezen beheerde identiteit kunt u door de klant beheerde sleutels configureren bij het maken van het cluster, wanneer identity type deze is ingesteld UserAssignedop en deze machtigingen verlenen in uw Key Vault voordat het cluster wordt gemaakt.

U kunt door de klant beheerde sleutels configureren op een nieuw cluster of een bestaand toegewezen cluster met gekoppelde werkruimten die gegevens opnemen. Op dezelfde manier kunt u werkruimten op elk gewenst moment loskoppelen van een cluster. Nieuwe gegevens die zijn opgenomen in gekoppelde werkruimten, worden versleuteld met uw sleutel en oudere gegevens blijven versleuteld met door Microsoft beheerde sleutels. De configuratie onderbreekt de opname of query's niet, waarbij query's naadloos worden uitgevoerd op oude en nieuwe gegevens. Wanneer u werkruimten loskoppelt van een cluster. Nieuwe gegevens die worden opgenomen, worden versleuteld met door Microsoft beheerde sleutels.

Belangrijk

De mogelijkheid voor door de klant beheerde sleutels is regionaal. Uw Azure Key Vault, toegewezen cluster en gekoppelde werkruimten moeten zich in dezelfde regio bevinden, maar kunnen zich in verschillende abonnementen bevinden.

Schermopname van het overzicht van de door de klant beheerde sleutel.

  1. Key Vault
  2. Log Analytics-clusterresource met een beheerde identiteit met machtigingen voor Key Vault: de identiteit wordt doorgegeven aan de onderlay toegewezen clusteropslag
  3. Toegewezen cluster
  4. Werkruimten die zijn gekoppeld aan een toegewezen cluster

Typen versleutelingssleutels

Er zijn drie typen sleutels betrokken bij opslaggegevensversleuteling:

  • "KEK" - Sleutelversleutelingssleutel (uw door de klant beheerde sleutel)
  • "AEK" - Accountversleutelingssleutel
  • "DEK" - Gegevensversleutelingssleutel

De volgende regels zijn van toepassing:

  • De clusteropslag heeft een unieke versleutelingssleutel voor elk opslagaccount, dat de AEK wordt genoemd.
  • De 'AEK' wordt gebruikt om 'DEK's af te leiden. Dit zijn de sleutels die worden gebruikt om elk blok gegevens te versleutelen dat naar de schijf wordt geschreven.
  • Bij het configureren van door de klant beheerde sleutel 'KEK' in uw cluster, voert de clusteropslag aanvragen 'wrap' en 'uitpakken' uit naar uw Key Vault voor AEK-versleuteling en -ontsleuteling.
  • Uw 'KEK' verlaat nooit uw sleutelkluis en, als u uw sleutel opslaat in azure Key Vault beheerde 'HSM', blijft de hardware nooit achter.
  • Azure Storage maakt gebruik van de beheerde identiteit die is gekoppeld aan het cluster voor verificatie. Azure Key Vault wordt geopend via Microsoft Entra-id.

Stappen voor het inrichten van door de klant beheerde sleutels

  1. Azure Key Vault maken en sleutel opslaan
  2. Een toegewezen cluster maken
  3. Machtigingen verlenen aan uw Key Vault
  4. Een toegewezen cluster bijwerken met sleutel-id-details
  5. Werkruimten koppelen

Door de klant beheerde sleutelconfiguratie wordt momenteel niet voltooid in Azure Portal en het inrichten kan worden uitgevoerd via PowerShell-, CLI- of REST-aanvragen .

Versleutelingssleutel (KEK) opslaan

Een portfolio met Azure Key Management-producten bevat de kluizen en beheerde HSM's die kunnen worden gebruikt.

Maak of gebruik een bestaande Azure Key Vault in de regio waarin het cluster is gepland. Genereer of importeer in uw Sleutelkluis een sleutel die moet worden gebruikt voor logboekversleuteling. De Azure Key Vault moet worden geconfigureerd als herstelbaar, om uw sleutel en de toegang tot uw gegevens in Azure Monitor te beveiligen. U kunt deze configuratie controleren onder eigenschappen in uw Sleutelkluis. Voorlopig verwijderen en Beveiliging tegen opschonen moet zijn ingeschakeld.

Schermopname van de beveiligingsinstellingen voor voorlopig verwijderen en opschonen.

Deze instellingen kunnen worden bijgewerkt in Key Vault via CLI en PowerShell:

Vereiste machtigingen

Als u clustergerelateerde acties wilt uitvoeren, hebt u deze machtigingen nodig:

Actie Benodigde machtigingen of rol
Een toegewezen cluster maken Microsoft.Resources/deployments/*en Microsoft.OperationalInsights/clusters/write machtigingen, zoals geleverd door de ingebouwde rol Log Analytics-inzender, bijvoorbeeld
Clustereigenschappen wijzigen Microsoft.OperationalInsights/clusters/write machtigingen, zoals geleverd door de ingebouwde rol Log Analytics-inzender, bijvoorbeeld
Werkruimten koppelen aan een cluster Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/writeen Microsoft.OperationalInsights/workspaces/linkedservices/write machtigingen, zoals geleverd door de ingebouwde rol Log Analytics-inzender, bijvoorbeeld
Status van werkruimtekoppeling controleren Microsoft.OperationalInsights/workspaces/read machtigingen voor de werkruimte, zoals geleverd door de ingebouwde rol log analytics-lezer, bijvoorbeeld
Clusters ophalen of de inrichtingsstatus van een cluster controleren Microsoft.OperationalInsights/clusters/read machtigingen, zoals geleverd door de ingebouwde rol log analytics-lezer, bijvoorbeeld
Toezeggingslaag of billingType bijwerken in een cluster Microsoft.OperationalInsights/clusters/write machtigingen, zoals geleverd door de ingebouwde rol Log Analytics-inzender, bijvoorbeeld
De vereiste machtigingen verlenen De rol Eigenaar of Inzender met */write machtigingen of de ingebouwde rol Log Analytics-inzender, die machtigingen heeft Microsoft.OperationalInsights/*
Een werkruimte ontkoppelen van een cluster Microsoft.OperationalInsights/workspaces/linkedServices/delete machtigingen, zoals geleverd door de ingebouwde rol Log Analytics-inzender, bijvoorbeeld
Een toegewezen cluster verwijderen Microsoft.OperationalInsights/clusters/delete machtigingen, zoals geleverd door de ingebouwde rol Log Analytics-inzender, bijvoorbeeld

Cluster maken

Clusters gebruiken beheerde identiteit voor gegevensversleuteling met uw Key Vault. Configureer identity type de eigenschap voor SystemAssigned of UserAssigned bij het maken van uw cluster om toegang tot uw Key Vault toe te staan voor gegevensversleuteling en ontsleutelingsbewerkingen.

Voorbeeld: voeg deze eigenschappen toe in de aanvraagbody voor door het systeem toegewezen beheerde identiteit

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

Notitie

Identiteitstype kan worden gewijzigd nadat het cluster is gemaakt zonder onderbreking van opname of query's, met de volgende overwegingen

  • Identiteit en sleutel kunnen niet tegelijkertijd worden bijgewerkt in het cluster: bijwerken in twee opeenvolgende bewerkingen
  • Bijwerken SystemAssigned naar UserAssigned: identiteit verlenen UserAssign in Key Vault en vervolgens bijwerken identity in cluster
  • Bijwerken UserAssigned naar SystemAssigned: identiteit verlenen SystemAssigned in Key Vault en vervolgens bijwerken identity in cluster

Volg de procedure die wordt geïllustreerd in het artikel over toegewezen clusters.

Key Vault-machtigingen verlenen

Er zijn twee machtigingsmodellen in Key Vault om toegang te verlenen tot uw cluster en onderlayopslag: op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) en kluistoegangsbeleid (verouderd).

  1. Azure RBAC toewijzen die u kunt beheren (aanbevolen)

    Als u roltoewijzingen wilt toevoegen, moet u een rol hebben met Microsoft.Authorization/roleAssignments/write en Microsoft.Authorization/roleAssignments/delete machtigingen, zoals Beheerder voor gebruikerstoegang of Eigenaar.

    1. Open uw Key Vault in De Azure-portal en selecteer Op rollen gebaseerd toegangsbeheer van Azure Settings>Access>en Apply
    2. Klik op Ga naar de knop Toegangsbeheer (IAM) en voeg de roltoewijzing Key Vault Crypto Service Encryption User toe.
    3. Selecteer beheerde identiteit op het tabblad Leden en selecteer het abonnement voor identiteit en de identiteit als lid

    Schermopname van Key Vault RBAC-machtigingen verlenen.

  2. Toegangsbeleid voor kluis toewijzen (verouderd)

    Open uw Key Vault in De Azure-portal en selecteer toegangsbeleid> voor Access Policies>Vault+ Toegangsbeleid toevoegen om een beleid te maken met deze instellingen:

    • Sleutelmachtigingen: selecteer Sleutel ophalen, inpakken en uitpakken.
    • Principal selecteren, afhankelijk van het identiteitstype dat wordt gebruikt in het cluster (door het systeem of de gebruiker toegewezen beheerde identiteit)
      • Door het systeem toegewezen beheerde identiteit - voer de clusternaam of de principal-id van het cluster in
      • Door de gebruiker toegewezen beheerde identiteit - voer de naam van de identiteit in

    Schermopname van Key Vault-toegangsbeleidsmachtigingen verlenen.

    De machtiging Ophalen is vereist om te controleren of uw Sleutelkluis is geconfigureerd als herstelbaar om uw sleutel en de toegang tot uw Azure Monitor-gegevens te beveiligen.

Cluster bijwerken met sleutel-id-details

Voor alle bewerkingen op het cluster is de Microsoft.OperationalInsights/clusters/write actiemachtiging vereist. Deze machtiging kan worden verleend via de eigenaar of inzender die de */write actie bevat, of via de rol Log Analytics-inzender die de Microsoft.OperationalInsights/* actie bevat.

In deze stap wordt toegewezen clusteropslag bijgewerkt met de sleutel en versie die moet worden gebruikt voor 'AEK' verpakken en uitpakken.

Belangrijk

  • Sleutelrotatie kan automatisch of per expliciete sleutelversie zijn. Zie Sleutelrotatie om de geschikte benadering te bepalen voordat u de details van de sleutel-id in het cluster bijwerkt.
  • Bij het bijwerken van het cluster mogen niet zowel de id- als de sleutel-id-gegevens in dezelfde bewerking worden opgenomen. Als u beide wilt bijwerken, moet de update twee opeenvolgende bewerkingen hebben.

Schermopname van Key Vault-machtigingen verlenen.

KeyVaultProperties bijwerken in het cluster met sleutel-id-details.

De bewerking is asynchroon en kan enige tijd in beslag nemen.

N.v.t.

Belangrijk

Deze stap moet alleen worden uitgevoerd na het inrichten van het cluster. Als u werkruimten koppelt en gegevens opneemt vóór de inrichting, worden opgenomen gegevens verwijderd en kunnen ze niet worden hersteld.

Volg de procedure die wordt geïllustreerd in het artikel Toegewezen clusters.

Volg de procedure die wordt geïllustreerd in het artikel Toegewezen clusters.

Sleutelintrekking

Belangrijk

  • De aanbevolen manier om de toegang tot uw gegevens in te trekken, is door uw sleutel uit te schakelen of het toegangsbeleid in uw sleutelkluis te verwijderen.
  • Als u instelt dat het cluster identity type None ook de toegang tot uw gegevens intrekt, wordt deze methode niet aanbevolen, omdat u deze niet kunt herstellen zonder contact op te leggen met de ondersteuning.

De opslag van het cluster respecteert altijd wijzigingen in sleutelmachtigingen binnen een uur of eerder en opslag is niet beschikbaar. Nieuwe gegevens die zijn opgenomen in gekoppelde werkruimten, worden verwijderd en onherstelbaar. Gegevens zijn niet toegankelijk voor deze werkruimten en query's mislukken. Eerder opgenomen gegevens blijven in de opslag zolang uw cluster en uw werkruimten niet worden verwijderd. Ontoegankelijke gegevens vallen onder het beleid voor gegevensretentie en worden verwijderd wanneer de retentie wordt bereikt. Gegevens die in de afgelopen 14 dagen zijn opgenomen en gegevens die onlangs in query's worden gebruikt, worden ook bewaard in hot-cache (SSD-back) voor query-efficiëntie. De gegevens op SSD worden verwijderd bij het intrekken van sleutels en zijn niet toegankelijk. De clusteropslag probeert Key Vault periodiek te bereiken voor verpakken en uitpakken, en zodra de sleutel is ingeschakeld, slaagt het uitpakken, worden SSD-gegevens opnieuw geladen vanuit de opslag en worden gegevensopname en query binnen 30 minuten hervat.

Sleutelroulatie

Sleutelrotatie heeft twee modi:

  • Automatischerotatie: werk "keyVaultProperties" eigenschappen in het cluster bij en laat de "keyVersion" eigenschap weg of stel deze in op "". Opslag maakt automatisch gebruik van de nieuwste sleutelversie.
  • Expliciete update van sleutelversie: werk eigenschappen bij "keyVaultProperties" en werk de sleutelversie bij in "keyVersion" de eigenschap. Voor sleutelrotatie is een expliciete update van "keyVersion" de eigenschap in het cluster vereist. Zie Cluster bijwerken met sleutel-id-details voor meer informatie. Als u een nieuwe sleutelversie in Key Vault genereert, maar de sleutel niet bijwerkt in het cluster, blijft de clusteropslag de vorige sleutel gebruiken. Als u de oude sleutel uitschakelt of verwijdert voordat u een nieuwe sleutel in het cluster bijwerkt, krijgt u de status sleutelintrekking .

Al uw gegevens blijven toegankelijk tijdens en na de sleutelrotatiebewerking. Gegevens worden altijd versleuteld met de accountversleutelingssleutel (AEK), die is versleuteld met uw nieuwe KEK-versie (Key Encryption Key) in Key Vault.

Door de klant beheerde sleutel voor opgeslagen query's en waarschuwingen voor zoeken in logboeken

De querytaal die wordt gebruikt in Log Analytics is expressief en kan gevoelige informatie bevatten in opmerkingen of in de querysyntaxis. Sommige organisaties vereisen dat dergelijke informatie wordt beveiligd onder door de klant beheerd sleutelbeleid en u moet uw query's opslaan die zijn versleuteld met uw sleutel. Met Azure Monitor kunt u opgeslagen query's opslaan en waarschuwingen voor zoeken in logboeken die zijn versleuteld met uw sleutel in uw eigen opslagaccount wanneer deze zijn gekoppeld aan uw werkruimte.

Door de klant beheerde sleutel voor werkmappen

Met de overwegingen voor door de klant beheerde sleutel voor opgeslagen query's en waarschuwingen voor zoeken in logboeken kunt u met Azure Monitor werkmapquery's opslaan die zijn versleuteld met uw sleutel in uw eigen opslagaccount, wanneer u Opslaan van inhoud selecteert in een Azure Storage-account in de bewerking Opslaan in werkmap Opslaan.

Schermopname van Werkmap opslaan.

Notitie

Query's blijven versleuteld met Microsoft-sleutel (MMK) in de volgende scenario's, ongeacht de configuratie van door de klant beheerde sleutels: Azure-dashboards, Azure Logic App, Azure Notebooks en Automation-runbooks.

Wanneer u uw opslagaccount koppelt voor opgeslagen query's, worden in de service opgeslagen query's opgeslagen en waarschuwingsquery's voor logboeken in uw opslagaccount opgeslagen. Als u controle hebt over het versleutelings-at-rest-beleid van uw opslagaccount, kunt u opgeslagen query's en waarschuwingen voor zoeken in logboeken beveiligen met door de klant beheerde sleutel. U bent echter wel verantwoordelijk voor de kosten die aan dat opslagaccount zijn gekoppeld.

Overwegingen voordat u door de klant beheerde sleutel instelt voor query's

  • U moet schrijfmachtigingen hebben voor uw werkruimte en opslagaccount.
  • Zorg ervoor dat u uw opslagaccount maakt in dezelfde regio als uw Log Analytics-werkruimte, met door de klant beheerde sleutelversleuteling. Dit is belangrijk omdat opgeslagen query's worden opgeslagen in tabelopslag en deze alleen kunnen worden versleuteld bij het maken van het opslagaccount.
  • Query's die zijn opgeslagen in het querypakket , worden niet versleuteld met de door de klant beheerde sleutel. Selecteer Opslaan als verouderde query bij het opslaan van query's om ze te beveiligen met door de klant beheerde sleutel.
  • Query's in de opslag worden beschouwd als serviceartefacten en hun indeling kan veranderen.
  • Als u een opslagaccount koppelt voor query's, worden bestaande opgeslagen query's uit uw werkruimte verwijderd. Met kopiëren worden query's opgeslagen die u nodig hebt vóór deze configuratie. U kunt uw opgeslagen query's weergeven met behulp van PowerShell.
  • Query 'geschiedenis' en 'vastmaken aan dashboard' worden niet ondersteund bij het koppelen van een opslagaccount voor query's.
  • U kunt één opslagaccount koppelen aan een werkruimte voor zowel opgeslagen query's als waarschuwingsquery's voor logboekzoekopdrachten.
  • Waarschuwingen voor zoeken in logboeken worden opgeslagen in blobopslag en door de klant beheerde sleutelversleuteling kunnen worden geconfigureerd bij het maken van een opslagaccount of later.
  • Geactiveerde waarschuwingen voor zoeken in logboeken bevatten geen zoekresultaten of waarschuwingsquery's. U kunt waarschuwingsdimensies gebruiken om context op te halen in de geactiveerde waarschuwingen.

BYOS configureren voor opgeslagen query's

Koppel een opslagaccount voor query's om opgeslagen query's in uw opslagaccount te bewaren.

N.v.t.

Na de configuratie worden nieuwe opgeslagen zoekquery's opgeslagen in uw opslag.

BYOS configureren voor waarschuwingsquery's voor zoeken in logboeken

Koppel een opslagaccount voor waarschuwingen om logboekzoekquery's in uw opslagaccount te bewaren.

N.v.t.

Na de configuratie wordt elke nieuwe waarschuwingsquery opgeslagen in uw opslag.

Klanten-lockbox

Lockbox geeft u het beheer om microsoft-technicusaanvragen goed te keuren of af te wijzen voor toegang tot uw gegevens tijdens een ondersteuningsaanvraag.

Lockbox wordt geleverd in een toegewezen cluster in Azure Monitor, waar uw machtiging voor toegang tot gegevens wordt verleend op abonnementsniveau.

Meer informatie over Customer Lockbox voor Microsoft Azure

Door de klant beheerde sleutelbewerkingen

De door de klant beheerde sleutel wordt verstrekt op een toegewezen cluster en deze bewerkingen worden genoemd in het artikel over toegewezen clusters

  • Alle clusters in resourcegroep ophalen
  • Alle clusters in abonnement ophalen
  • Capaciteitsreservering in cluster bijwerken
  • BillingType in cluster bijwerken
  • Een werkruimte ontkoppelen van een cluster
  • Cluster verwijderen

Beperkingen

  • Er kunnen maximaal vijf actieve clusters worden gemaakt in elke regio en elk abonnement.

  • Er kunnen maximaal zeven gereserveerde clusters (actief of recent verwijderd) bestaan in elke regio en elk abonnement.

  • Er kunnen maximaal 1000 Log Analytics-werkruimten aan een cluster worden gekoppeld.

  • Er zijn maximaal twee werkruimtekoppelingsbewerkingen voor bepaalde werkruimten toegestaan in een periode van 30 dagen.

  • Het verplaatsen van een cluster naar een andere resourcegroep of een ander abonnement wordt momenteel niet ondersteund.

  • Bij het bijwerken van het cluster mogen niet zowel identiteits- als sleutel-id-gegevens in dezelfde bewerking worden opgenomen. Als u beide moet bijwerken, moet de update zich in twee opeenvolgende bewerkingen bevinden.

  • Lockbox is momenteel niet beschikbaar in China.

  • Lockbox is niet van toepassing op tabellen met het hulpplan.

  • Dubbele versleuteling wordt automatisch geconfigureerd voor clusters die zijn gemaakt vanaf oktober 2020 in ondersteunde regio's. U kunt controleren of uw cluster is geconfigureerd voor dubbele versleuteling door een GET-aanvraag op het cluster te verzenden en te observeren dat de isDoubleEncryptionEnabled waarde voor clusters is waarvoor dubbele versleuteling is true ingeschakeld.

    • Als u een cluster maakt en een fout krijgt: 'regionaam biedt geen ondersteuning voor dubbele versleuteling voor clusters', kunt u het cluster nog steeds maken zonder dubbele versleuteling door de hoofdtekst van de REST-aanvraag toe te voegen "properties": {"isDoubleEncryptionEnabled": false} .
    • Dubbele versleutelingsinstellingen kunnen niet worden gewijzigd nadat het cluster is gemaakt.

  • Het verwijderen van een gekoppelde werkruimte is toegestaan terwijl deze is gekoppeld aan het cluster. Als u besluit om de werkruimte te herstellen tijdens de periode voor voorlopig verwijderen, keert deze terug naar de vorige status en blijft deze gekoppeld aan het cluster.

  • Door de klant beheerde sleutelversleuteling is van toepassing op nieuw opgenomen gegevens na de configuratietijd. Gegevens die zijn opgenomen voordat de configuratie versleuteld blijft met Microsoft-sleutels. U kunt naadloos query's uitvoeren op gegevens die zijn opgenomen voor en na de door de klant beheerde sleutelconfiguratie.

  • De Azure Key Vault moet worden geconfigureerd als herstelbaar. Deze eigenschappen zijn niet standaard ingeschakeld en moeten worden geconfigureerd met cli of PowerShell:

  • Uw Azure Key Vault, cluster en werkruimten moeten zich in dezelfde regio en in dezelfde Microsoft Entra-tenant bevinden, maar ze kunnen zich in verschillende abonnementen bevinden.

  • Als u instelt dat het cluster identity type None ook de toegang tot uw gegevens intrekt, wordt deze methode niet aanbevolen, omdat u deze niet kunt herstellen zonder contact op te leggen met de ondersteuning. De aanbevolen manier om de toegang tot uw gegevens in te trekken, is het intrekken van sleutels.

  • U kunt de door de klant beheerde sleutel niet gebruiken met door de gebruiker toegewezen beheerde identiteit als uw Key Vault zich in Private Link (vNet) bevindt. In dit scenario kunt u door het systeem toegewezen beheerde identiteit gebruiken.

  • Het hulptabelplan biedt geen ondersteuning voor door de klant beheerde sleutels. Gegevens in tabellen met het hulpplan worden versleuteld met door Microsoft beheerde sleutels, zelfs als u de gegevens in de rest van uw Log Analytics-werkruimte beveiligt met uw eigen versleutelingssleutel.

Probleemoplossing

  • Gedrag per Key Vault-beschikbaarheid:

    • Normale werking: opslag slaat 'AEK' gedurende korte tijd in de cache op en gaat terug naar Key Vault om periodiek uit te pakken.

    • Key Vault-verbindingsfouten: opslag verwerkt tijdelijke fouten (time-outs, verbindingsfouten, 'DNS'-problemen), doordat sleutels tijdens het beschikbaarheidsprobleem in de cache kunnen blijven en problemen met blip's en beschikbaarheid worden opgelost. De mogelijkheden voor query's en opname worden zonder onderbreking voortgezet.

  • Key Vault-toegangssnelheid - de frequentie waarmee de clusteropslag toegang heeft tot Key Vault voor terugloop en uitpakken - ligt tussen 6 en 60 seconden.

  • Als u uw cluster bijwerkt terwijl het de inrichtingsstatus heeft of de status bijwerkt, mislukt de update.

  • Als er een conflict optreedt: fout bij het maken van een cluster, is een cluster met dezelfde naam mogelijk in de afgelopen 14 dagen verwijderd en gereserveerd gehouden. De naam van het verwijderde cluster wordt 14 dagen na verwijdering beschikbaar.

  • Het koppelen van een werkruimte aan een cluster mislukt als de werkruimte is gekoppeld aan een ander cluster.

  • Als u een cluster maakt en de KeyVaultProperties onmiddellijk opgeeft, kan de bewerking mislukken totdat een identiteit is toegewezen aan het cluster en wordt verleend aan Key Vault.

  • Als u een bestaand cluster bijwerkt met KeyVaultProperties en 'Get'-sleuteltoegangsbeleid ontbreekt in Key Vault, mislukt de bewerking.

  • Als u uw cluster niet implementeert, controleert u of uw Azure Key Vault- en gekoppelde werkruimten zich in dezelfde regio bevinden. De abonnementen kunnen zich in verschillende abonnementen bevinden.

  • Als u uw sleutel roteert in Key Vault en de details van de nieuwe sleutel-id niet bijwerkt in het cluster, blijft het cluster de vorige sleutel gebruiken en zijn uw gegevens niet toegankelijk. Werk de details van de nieuwe sleutel-id in het cluster bij om gegevensopname en query te hervatten. U kunt de sleutelversie bijwerken met '''' zodat opslag altijd automatisch late sleutelversies gebruikt.

  • Sommige bewerkingen worden lang uitgevoerd en kunnen enige tijd duren, waaronder het maken van clusters, het bijwerken van de clustersleutel en het verwijderen van het cluster. U kunt de bewerkingsstatus controleren door GET-aanvraag naar het cluster of de werkruimte te verzenden en het antwoord te bekijken. Niet-gekoppelde werkruimte heeft bijvoorbeeld niet de clusterResourceId onder functies.

  • Foutberichten

    Clusterupdate

    • 400 - Cluster heeft de status Verwijderd. Asynchrone bewerking wordt uitgevoerd. Het cluster moet de bewerking voltooien voordat een updatebewerking wordt uitgevoerd.
    • 400 - KeyVaultProperties is niet leeg, maar heeft een slechte indeling. Zie de update van de sleutel-id.
    • 400 - Kan sleutel niet valideren in Key Vault. Dit kan worden veroorzaakt door een gebrek aan machtigingen of als de sleutel niet bestaat. Controleer of u sleutel- en toegangsbeleid hebt ingesteld in Key Vault.
    • 400 - Sleutel kan niet worden hersteld. Key Vault moet zijn ingesteld op Voorlopig verwijderen en Beveiliging opschonen. Raadpleeg de Key Vault-documentatie
    • 400 - De bewerking kan nu niet worden uitgevoerd. Wacht tot de Async-bewerking is voltooid en probeer het opnieuw.
    • 400 - Cluster heeft de status Verwijderd. Wacht tot de Async-bewerking is voltooid en probeer het opnieuw.

    Cluster ophalen

    • 404--Cluster niet gevonden, het cluster is mogelijk verwijderd. Als u probeert een cluster met die naam te maken en een conflict op te halen, bevindt het cluster zich in het verwijderingsproces.

Volgende stappen