Door de klant beheerde sleutel van Azure Monitor

  • Artikel

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, terwijl u verschillende opties hebt 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). U kunt gegevens versleutelen met behulp van uw eigen sleutel in Azure Key Vault, voor controle over de levenscyclus van de sleutel en de mogelijkheid om de toegang tot uw gegevens in te trekken. Het gebruik van versleuteling in Azure Monitor is identiek aan de manier waarop Azure Storage-versleuteling werkt.

Door de klant beheerde sleutel wordt geleverd op toegewezen clusters die een hoger beveiligingsniveau en een hoger beheer bieden. Gegevens worden tweemaal versleuteld in de opslag, eenmaal op serviceniveau met behulp van door Microsoft beheerde sleutels of door de klant beheerde sleutels, en eenmaal 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 kan worden aangetast. Met een toegewezen cluster kunt u ook gegevens beveiligen met Lockbox.

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

Het prijsmodel voor Toegewezen Clusters voor Log Analytics vereist een toezeggingslaag vanaf 100 GB per dag.

Hoe door de klant beheerde sleutel werkt 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 sleutel in meerdere werkruimten wilt toestaan, wordt een Log Analytics-clusterresource uitgevoerd 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 wordt automatisch gegenereerd met het maken van het cluster wanneer de identiteit type is ingesteld op 'SystemAssigned'. Deze identiteit kan later worden gebruikt om opslagtoegang te verlenen tot uw Key Vault voor inpak- en uitpakbewerkingen.
  • Met door de gebruiker toegewezen beheerde identiteit kunt u door de klant beheerde sleutel configureren bij het maken van een cluster, wanneer u deze machtigingen in uw Key Vault verleent voordat het cluster wordt gemaakt.

U kunt door de klant beheerde sleutelconfiguratie toepassen op een nieuw cluster of een bestaand cluster dat is gekoppeld aan werkruimten en gegevens opnemen. Nieuwe gegevens die zijn opgenomen in gekoppelde werkruimten, worden versleuteld met uw sleutel en oudere gegevens die vóór de configuratie worden opgenomen, blijven versleuteld met Microsoft-sleutel. Uw query's worden niet beïnvloed door door de klant beheerde sleutelconfiguratie en worden naadloos uitgevoerd op oude en nieuwe gegevens. U kunt werkruimten op elk gewenst moment loskoppelen van het cluster. Nieuwe gegevens die worden opgenomen nadat de koppeling is ontkoppeld, worden versleuteld met de Microsoft-sleutel en query's worden naadloos uitgevoerd op oude en nieuwe gegevens.

Belangrijk

Door de klant beheerde sleutelmogelijkheid is regionaal. Uw Azure Key Vault-, cluster- en gekoppelde werkruimten moeten zich in dezelfde regio bevinden, maar ze kunnen zich in verschillende abonnementen bevinden.

Screenshot of customer-managed key overview.

  1. Sleutelkluis
  2. Log Analytics-clusterresource met 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 Key Vault en in het geval van beheerde 'HSM' verlaat deze nooit de hardware.
  • 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.

Screenshot of soft delete and purge protection settings.

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 de identiteitseigenschap type voor SystemAssigned het maken van uw cluster om toegang tot uw Key Vault toe te staan voor 'verpakken' en 'uitpakken'-bewerkingen.

Identiteitsinstellingen in cluster voor door het systeem toegewezen beheerde identiteit

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

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 beschikken over machtigingen voor Microsoft.Authorization/roleAssignments/write en Microsoft.Authorization/roleAssignments/delete, zoals User Access Beheer istrator of Owner.

    Open uw Key Vault in Azure Portal, klik op Access-configuratie in Instellingen en selecteer de optie op basis van op rollen gebaseerd toegangsbeheer van Azure. Voer vervolgens toegangsbeheer (IAM) in en voeg key Vault Crypto Service Encryption User role assignment toe.

    Screenshot of Grant Key Vault RBAC permissions.

  2. Toegangsbeleid voor kluis toewijzen (verouderd)

    Open uw Key Vault in Azure Portal en klik op Toegangsbeleid, selecteer Kluistoegangsbeleid en klik vervolgens op + 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

    Screenshot of Grant Key Vault access policy permissions.

    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 zijn of expliciete sleutelupdate vereisen. 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.

Screenshot of Grant Key Vault permissions.

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 identitytypeNone 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 opslag is niet beschikbaar. Nieuwe gegevens die zijn opgenomen in gekoppelde werkruimten, worden verwijderd en kunnen niet worden hersteld. 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 uw cluster bij met "keyVaultProperties" maar laat de "keyVersion" eigenschap weg of stel het in op "". Opslag maakt automatisch gebruik van de nieuwste sleutelversie.
  • Expliciete update van sleutelversie: werk uw cluster bij met de sleutelversie in "keyVersion" de eigenschap. Voor het roteren van sleutels is een expliciete "keyVaultProperties" update in het cluster vereist. Zie Cluster bijwerken met de details van de sleutel-id. Als u een nieuwe sleutelversie in Key Vault genereert, maar deze 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 na de bewerking van de sleutelrotatie. 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.

Screenshot of Workbook save.

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.

  • 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 vóór de configuratie zijn opgenomen, blijven versleuteld met de Microsoft-sleutel. 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 identitytypeNone 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.

  • Asynchrone query's voor zoektaken worden momenteel niet ondersteund in het door de klant beheerde sleutelscenario.

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 azure de clusteropslag toegang heeft tot Key Vault voor terugloop en uitpakken, is 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.

  • De werkruimtekoppeling naar het cluster mislukt als deze is gekoppeld aan een ander cluster.

  • Als u een cluster maakt en de KeyVaultProperties onmiddellijk opgeeft, kan de bewerking mislukken totdat de identiteit is toegewezen in het cluster en wordt verleend bij 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 ongeldige indeling. Zie de update van de sleutel-id.
    • 400 : kan de 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 conflict op te halen, wordt het cluster verwijderd.

Volgende stappen