Delen via


Door de klant beheerde Azure Monitor-sleutels

Gegevens in Azure Monitor worden versleuteld met door Microsoft beheerde sleutels. U kunt uw eigen versleutelingssleutel gebruiken om de gegevens en opgeslagen query's in uw werkruimten te beveiligen. Door de klant beheerde sleutels in Azure Monitor bieden meer flexibiliteit om toegangsbeheer voor logboeken te beheren. Zodra de configuratie is uitgevoerd, worden nieuwe gegevens die zijn opgenomen in gekoppelde werkruimten versleuteld met uw sleutel die is opgeslagen in Azure Key Vault of beheerde HSM in Azure Key Vault.

Bekijk de beperkingen en beperkingen vóór de configuratie.

Overzicht van door de klant beheerde sleutel

Versleuteling at Rest is een algemene vereiste voor privacy en beveiliging in organisaties. U kunt Azure inactieve versleuteling volledig laten beheren of u kunt 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 en de toegang tot uw gegevens wilt intrekken, kunt u gegevens versleutelen met uw eigen sleutel met behulp van Azure Key Vault.

Door de klant beheerde sleutels zijn beschikbaar op toegewezen clusters en bieden u een hoger beschermingsniveau en beheer. Gegevens worden tweemaal in de opslag 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 mogelijk 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 Microsoft-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 de toezeggingscategorie 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 Azure Key Vault. De identiteit van het Log Analytics-cluster wordt ondersteund op clusterniveau. Als u door de klant beheerde sleutels in meerdere werkruimten wilt toestaan, 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.
  • Door de gebruiker toegewezen beheerde identiteit stelt u in staat om door de klant beheerde sleutels te configureren bij het maken van clusters, wanneer identity type deze is ingesteld UserAssignedop en deze machtigingen te 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 cluster dat is gekoppeld aan werkruimten en al gegevens opneemt. Nieuwe gegevens die zijn opgenomen in gekoppelde werkruimten, worden versleuteld met uw sleutel en oudere gegevens die worden opgenomen voordat de configuratie versleuteld blijft met Microsoft-sleutels. De configuratie van door de klant beheerde sleutels heeft geen invloed op uw query's, die naadloos blijven worden uitgevoerd op oude en nieuwe gegevens. U kunt werkruimten op elk gewenst moment loskoppelen van een cluster. Nieuwe gegevens die u opneemt nadat de ontkoppeling is versleuteld met Microsoft-sleutels en query's worden uitgevoerd op oude en nieuwe gegevens naadloos.

Belangrijk

De mogelijkheid voor door de klant beheerde sleutels is regionaal. Uw Azure Key Vault-, cluster- en gekoppelde werkruimten moeten zich in dezelfde regio bevinden, maar ze 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

Bewerking van 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.
  • Wanneer u een sleutel in uw sleutelkluis configureert en de sleuteldetails in het cluster bijwerken, voert de clusteropslag aanvragen uit om 'teruglopen' en 'uitpakken' 'AEK' uit te voeren voor versleuteling en ontsleuteling.
  • Uw 'KEK' verlaat nooit uw sleutelkluis en, als u een beheerde 'HSM' gebruikt, blijft de hardware nooit achter.
  • Azure Storage maakt gebruik van een beheerde identiteit die is gekoppeld aan de clusterresource 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. Cluster maken
  3. Machtigingen verlenen aan uw Key Vault
  4. Cluster bijwerken met sleutel-id-details
  5. Werkruimten koppelen

Door de klant beheerde sleutelconfiguratie wordt momenteel niet ondersteund 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:

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.

Identiteitsinstellingen in cluster 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

  • Bijwerken SystemAssigned naar UserAssigned: UserAssign-identiteit verlenen in Key Vault en vervolgens bijwerken identity type in cluster
  • Bijwerken UserAssigned naar SystemAssigned- Aangezien door het systeem toegewezen beheerde identiteit is gemaakt na het bijwerken van het cluster identity type , SystemAssignedmoeten de volgende stappen worden gevolgd
    1. Cluster bijwerken en de sleutel verwijderen, instellen keyVaultUri, keyNameen keyVersion met de waarde ''
    2. Cluster bijwerken identity type naar SystemAssigned
    3. Key Vault bijwerken en machtigingen verlenen aan de identiteit
    4. Sleutel bijwerken in cluster

Volg de procedure die wordt geïllustreerd in het artikel 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 te bepalen welke benadering geschikt is voor u 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.

U moet schrijfmachtigingen hebben voor uw werkruimte en cluster om deze bewerking uit te voeren. Het omvat Microsoft.OperationalInsights/workspaces/write en Microsoft.OperationalInsights/clusters/write.

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 clusteropslag respecteert altijd wijzigingen in sleutelmachtigingen binnen een uur of eerder en de 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