Chiave gestita dal cliente di Monitoraggio di Azure

  • Articolo

I dati in Monitoraggio di Azure vengono crittografati con chiavi gestite da Microsoft. È possibile usare la propria chiave di crittografia per proteggere i dati e le query salvate nelle aree di lavoro. Le chiavi gestite dal cliente in Monitoraggio di Azure offrono maggiore flessibilità per gestire i controlli di accesso ai log. Dopo la configurazione, i nuovi dati inseriti nelle aree di lavoro collegate vengono crittografati con la chiave archiviata in Azure Key Vault o il "modulo di protezione hardware" gestito da Azure Key Vault.

Esaminare le limitazioni e i vincoli prima della configurazione.

Panoramica della chiave gestita dal cliente

La crittografia dei dati inattivi è un requisito comune di privacy e sicurezza nelle organizzazioni. È possibile consentire ad Azure di gestire completamente la crittografia dei dati inattivi, mentre sono disponibili varie opzioni per gestire attentamente la crittografia e le chiavi di crittografia.

Monitoraggio di Azure assicura che tutte le query salvate e tutti i dati siano crittografati quando inattivi con chiavi gestite da Microsoft. È possibile crittografare i dati usando la propria chiave in Azure Key Vault, per controllare il ciclo di vita della chiave e per revocare l'accesso ai dati. L'uso della crittografia di Monitoraggio di Azure è identico al funzionamento della crittografia Archiviazione di Azure.

La chiave gestita dal cliente viene distribuita in cluster dedicati che forniscono un livello di protezione e un controllo più elevati. I dati vengono crittografati due volte nell'archiviazione, una volta a livello di servizio usando chiavi gestite da Microsoft o chiavi gestite dal cliente e una volta a livello di infrastruttura, usando due algoritmi di crittografia diversi e due chiavi diverse. la doppia crittografia protegge da uno scenario in cui uno degli algoritmi di crittografia o delle chiavi può essere compromesso. Il cluster dedicato consente anche di proteggere i dati con Lockbox.

I dati inseriti negli ultimi 14 giorni o usati di recente nelle query vengono mantenuti nella cache ad accesso frequente (ssd) per garantire l'efficienza delle query. I dati SSD vengono crittografati con chiavi Microsoft indipendentemente dalla configurazione della chiave gestita dal cliente, ma il controllo sull'accesso SSD è conforme alla revoca delle chiavi

Il modello tariffario cluster dedicati di Log Analytics richiede il livello di impegno a partire da 100 GB al giorno.

Funzionamento della chiave gestita dal cliente in Monitoraggio di Azure

Monitoraggio di Azure usa l'identità gestita per concedere l'accesso ad Azure Key Vault. L'identità del cluster di Log Analytics è supportata a livello di cluster. Per consentire la chiave gestita dal cliente in più aree di lavoro, una risorsa cluster di Log Analytics viene eseguita come connessione di identità intermedia tra l'insieme di credenziali delle chiavi e le aree di lavoro Log Analytics. L'archiviazione del cluster usa l'identità gestita associata al cluster per l'autenticazione nell'insieme di credenziali delle chiavi di Azure tramite Microsoft Entra ID.

I cluster supportano due tipi di identità gestita: assegnati dal sistema e assegnati dall'utente, mentre una singola identità può essere definita in un cluster a seconda dello scenario.

  • L'identità gestita assegnata dal sistema è più semplice e viene generata automaticamente con la creazione del cluster quando l'identità type è impostata su "SystemAssigned". Questa identità può essere usata in un secondo momento per concedere l'accesso alle risorse di archiviazione all'insieme di credenziali delle chiavi per eseguire il wrapping e annullare il wrapping delle operazioni.
  • L'identità gestita assegnata dall'utente consente di configurare la chiave gestita dal cliente durante la creazione del cluster, concedendole le autorizzazioni nell'insieme di credenziali delle chiavi prima della creazione del cluster.

È possibile applicare la configurazione della chiave gestita dal cliente a un nuovo cluster o a un cluster esistente collegato alle aree di lavoro e all'inserimento di dati. I nuovi dati inseriti nelle aree di lavoro collegate vengono crittografati con la chiave e i dati meno recenti inseriti prima della configurazione rimangono crittografati con la chiave Microsoft. Le query non sono interessate dalla configurazione della chiave gestita dal cliente e eseguite tra i dati precedenti e i nuovi dati senza problemi. È possibile scollegare le aree di lavoro dal cluster in qualsiasi momento. I nuovi dati inseriti dopo che il collegamento viene crittografato con la chiave Microsoft e le query vengono eseguite tra i dati precedenti e i nuovi dati vengono eseguiti senza problemi.

Importante

La funzionalità chiave gestita dal cliente è a livello di area. L'insieme di credenziali delle chiavi di Azure, il cluster e le aree di lavoro collegate devono trovarsi nella stessa area, ma possono trovarsi in sottoscrizioni diverse.

Screenshot of customer-managed key overview.

  1. Insieme di credenziali delle chiavi di
  2. Risorsa del cluster di Log Analytics con identità gestita con autorizzazioni per Key Vault: l'identità viene propagata all'archiviazione cluster dedicata sottostante
  3. Cluster dedicato
  4. Aree di lavoro collegate a un cluster dedicato

Funzionamento delle chiavi di crittografia

Esistono tre tipi di chiavi coinvolte nella crittografia dei dati Archiviazione:

  • "KEK" - Chiave di crittografia della chiave (chiave gestita dal cliente)
  • "AEK" - Chiave di crittografia dell'account
  • "DEK" - Chiave di crittografia dei dati

Si applicano le seguenti regole:

  • L'archiviazione cluster ha una chiave di crittografia univoca per ogni account Archiviazione, noto come "AEK".
  • "AEK" viene usato per derivare "DEK, ovvero le chiavi usate per crittografare ogni blocco di dati scritto su disco.
  • Quando si configura una chiave nell'insieme di credenziali delle chiavi e si aggiornano i dettagli della chiave nel cluster, l'archiviazione cluster esegue richieste di "wrapping" e "annulla il wrapping" "AEK" per la crittografia e la decrittografia.
  • La chiave "KEK" non lascia mai l'insieme di credenziali delle chiavi e, nel caso del modulo di protezione hardware gestito, non lascia mai l'hardware.
  • Archiviazione di Azure usa l'identità gestita associata a Risorsa cluster per l'autenticazione. Accede ad Azure Key Vault tramite Microsoft Entra ID.

Passaggi di provisioning delle chiavi gestite dal cliente

  1. Creazione di Azure Key Vault e archiviazione della chiave
  2. Creazione di un cluster
  3. Concessione delle autorizzazioni a Key Vault
  4. Aggiornamento del cluster con i dettagli dell'identificatore di chiave
  5. Collegamento di aree di lavoro

La configurazione della chiave gestita dal cliente non è supportata in portale di Azure attualmente e il provisioning può essere eseguito tramite PowerShell, l'interfaccia della riga di comando o le richieste REST.

Archiviazione della chiave di crittografia ("KEK")

Un portfolio di prodotti di Gestione chiavi di Azure elenca gli insiemi di credenziali e i moduli di protezione hardware gestiti che possono essere usati.

Creare o usare un insieme di credenziali delle chiavi di Azure esistente nell'area in cui è pianificato il cluster. Nell'insieme di credenziali delle chiavi generare o importare una chiave da usare per la crittografia dei log. Azure Key Vault deve essere configurato come ripristinabile per proteggere la chiave e l'accesso ai dati in Monitoraggio di Azure. È possibile verificare questa configurazione nelle proprietà dell'istanza di Key Vault. Devono essere abilitate sia Eliminazione temporanea che Protezione dall'eliminazione.

Screenshot of soft delete and purge protection settings.

Queste impostazioni possono essere aggiornate in Key Vault tramite l'interfaccia della riga di comando e PowerShell:

Creare cluster

I cluster usano l'identità gestita per la crittografia dei dati con Key Vault. Configurare la proprietà Identity type su SystemAssigned quando si crea il cluster per consentire l'accesso all'insieme di credenziali delle chiavi per le operazioni di "wrapping" e "annullamento del wrapping".

Impostazioni di identità nel cluster per l'identità gestita assegnata dal sistema

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

Seguire la procedura illustrata nell'articolo Cluster dedicati.

Concedere le autorizzazioni di Key Vault

In Key Vault sono disponibili due modelli di autorizzazione per concedere l'accesso al cluster e all'archiviazione con risorse di archiviazione, ovvero il controllo degli accessi in base al ruolo di Azure e i criteri di accesso dell'insieme di credenziali (legacy).

  1. Assegnare il controllo degli accessi in base al ruolo di Azure (scelta consigliata)

    Per aggiungere assegnazioni di ruolo, è necessario disporre di autorizzazioni Microsoft.Authorization/roleAssignments/write e Microsoft.Authorization/roleAssignments/delete, ad esempio Accesso utenti Amministrazione istrator o Proprietario.

    Aprire l'insieme di credenziali delle chiavi in portale di Azure, fare clic su Configurazione di accesso in Impostazioni e selezionare l'opzione Controllo degli accessi in base al ruolo di Azure. Immettere quindi Controllo di accesso (IAM) e aggiungere l'assegnazione di ruolo utente Crittografia servizio crittografia key vault.

    Screenshot of Grant Key Vault RBAC permissions.

  2. Assegnare i criteri di accesso all'insieme di credenziali (legacy)

    Aprire l'insieme di credenziali delle chiavi in portale di Azure e fare clic su Criteri di accesso, selezionare Criteri di accesso dell'insieme di credenziali, quindi fare clic su + Aggiungi criteri di accesso per creare un criterio con queste impostazioni:

    • Autorizzazioni per le chiavi: selezionare Recupera, Eseguire il wrapping della chiave e Annullare il wrapping della chiave.
    • Selezionare l'entità, a seconda del tipo di identità usato nel cluster (identità gestita assegnata dal sistema o dall'utente)
      • Identità gestita assegnata dal sistema: immettere il nome del cluster o l'ID entità cluster
      • Identità gestita assegnata dall'utente: immettere il nome dell'identità

    Screenshot of Grant Key Vault access policy permissions.

    L'autorizzazione Recupera è necessaria per verificare che l'istanza di Key Vault sia configurata come recuperabile per proteggere la chiave e l'accesso ai dati di Monitoraggio di Azure.

Aggiornare il cluster con i dettagli dell'identificatore di chiave

Tutte le operazioni nel cluster richiedono l'autorizzazione di Microsoft.OperationalInsights/clusters/write azione. Questa autorizzazione può essere concessa tramite il proprietario o il collaboratore che contiene l'azione */write o tramite il ruolo Collaboratore Log Analytics che contiene l'azione Microsoft.OperationalInsights/* .

Questo passaggio aggiorna l'archiviazione cluster dedicata con la chiave e la versione da usare per il wrapping e il wrapping "AEK".

Importante

  • La rotazione delle chiavi può essere automatica o richiedere l'aggiornamento esplicito della chiave, vedere Rotazione delle chiavi per determinare l'approccio appropriato prima di aggiornare i dettagli dell'identificatore di chiave nel cluster.
  • L'aggiornamento del cluster non deve includere i dettagli dell'identità e dell'identificatore di chiave nella stessa operazione. Se è necessario aggiornare entrambi, l'aggiornamento deve essere in due operazioni consecutive.

Screenshot of Grant Key Vault permissions.

Aggiornare KeyVaultProperties nel cluster con i dettagli dell'identificatore di chiave.

L'operazione è asincrona e può richiedere del tempo.

N/D

Importante

Questo passaggio deve essere eseguito solo dopo il provisioning del cluster. Se si collegano aree di lavoro e si inseriscono dati prima del provisioning, i dati inseriti verranno eliminati e non saranno recuperabili.

Per eseguire questa operazione, è necessario disporre delle autorizzazioni di "scrittura" per l'area di lavoro e il cluster. Include Microsoft.OperationalInsights/workspaces/write e Microsoft.OperationalInsights/clusters/write.

Seguire la procedura illustrata nell'articolo Cluster dedicati.

Revoca delle chiavi

Importante

  • Il modo consigliato per revocare l'accesso ai dati consiste nel disabilitare la chiave o eliminare i criteri di accesso nell'insieme di credenziali delle chiavi.
  • L'impostazione del identitytype cluster su None revoca anche l'accesso ai dati, ma questo approccio non è consigliato perché non è possibile annullarlo senza contattare il supporto tecnico.

L'archiviazione cluster rispetta sempre le modifiche apportate alle autorizzazioni delle chiavi entro un'ora o prima e l'archiviazione non è più disponibile. I nuovi dati inseriti nelle aree di lavoro collegate vengono eliminati e non recuperabili. I dati non sono accessibili in queste aree di lavoro e le query hanno esito negativo. I dati inseriti in precedenza rimangono nell'archiviazione finché il cluster e le aree di lavoro non vengono eliminate. I dati inaccessibili sono regolati dai criteri di conservazione dei dati e eliminati quando viene raggiunta la conservazione. I dati inseriti negli ultimi 14 giorni e i dati usati di recente nelle query vengono mantenuti anche nella cache ad accesso frequente (con supporto SSD) per l'efficienza delle query. I dati nell'unità SSD vengono eliminati durante l'operazione di revoca delle chiavi e diventano inaccessibili. L'archiviazione del cluster tenta di raggiungere Key Vault per eseguire periodicamente il wrapping e il wrapping e annullare il wrapping e una volta abilitata la chiave, annullare il wrapping, i dati SSD vengono ricaricati dall'archiviazione e l'inserimento dei dati e la query vengono ripresi entro 30 minuti.

Rotazione delle chiavi

La rotazione delle chiavi ha due modalità:

  • Autorotation: aggiornare il cluster con "keyVaultProperties" ma omettere "keyVersion" la proprietà o impostarla su "". Archiviazione usa automaticamente la versione della chiave più recente.
  • Aggiornamento esplicito della versione della chiave: aggiornare il cluster con la versione della chiave nella "keyVersion" proprietà . La rotazione delle chiavi richiede un aggiornamento esplicito "keyVaultProperties" nel cluster, vedere Aggiornare il cluster con i dettagli dell'identificatore di chiave. Se si genera una nuova versione della chiave in Key Vault ma non la si aggiorna nel cluster, l'archiviazione cluster continua a usare la chiave precedente. Se si disabilita o si elimina la chiave precedente prima di aggiornarne una nuova nel cluster, si ottiene lo stato di revoca della chiave.

Tutti i dati rimangono accessibili dopo l'operazione di rotazione delle chiavi. I dati vengono sempre crittografati con la chiave di crittografia dell'account ("AEK"), crittografata con la nuova versione della chiave di crittografia della chiave ("KEK") in Key Vault.

Chiave gestita dal cliente per query salvate e avvisi di ricerca log

Il linguaggio di query usato in Log Analytics è espressivo e può contenere informazioni riservate nei commenti o nella sintassi della query. Alcune organizzazioni richiedono che tali informazioni siano protette in Criteri di chiave gestita dal cliente ed è necessario salvare le query crittografate con la chiave. Monitoraggio di Azure consente di archiviare query salvate e avvisi di ricerca log crittografati con la chiave nel proprio account Archiviazione quando è collegato all'area di lavoro.

Chiave gestita dal cliente per cartelle di lavoro

Con le considerazioni indicate per la chiave gestita dal cliente per le query salvate e gli avvisi di ricerca log, Monitoraggio di Azure consente di archiviare le query della cartella di lavoro crittografate con la chiave nel proprio account Archiviazione, quando si seleziona Salva contenuto in un account Archiviazione di Azure nell'operazione "Salva" della cartella di lavoro.

Screenshot of Workbook save.

Nota

Le query rimangono crittografate con la chiave Microsoft ("MMK") negli scenari seguenti indipendentemente dalla configurazione della chiave gestita dal cliente: dashboard di Azure, app per la logica di Azure, Notebook di Azure e runbook di automazione.

Quando si collega l'account Archiviazione per le query salvate, il servizio archivia le query salvate e le query di avviso di ricerca log nell'account Archiviazione. Avere il controllo sui criteri di crittografia dei dati inattivi dell'account Archiviazione, è possibile proteggere le query salvate e gli avvisi di ricerca nei log con la chiave gestita dal cliente. Tuttavia, si sarà responsabili dei costi associati a tale account Archiviazione.

Considerazioni prima di impostare la chiave gestita dal cliente per le query

  • È necessario disporre delle autorizzazioni di "scrittura" per l'area di lavoro e Archiviazione account.
  • Assicurarsi di creare l'account Archiviazione nella stessa area dell'area di lavoro Log Analytics, con la crittografia della chiave gestita dal cliente. Questo aspetto è importante perché le query salvate vengono archiviate nell'archiviazione tabelle e possono essere crittografate solo in fase di creazione dell'account Archiviazione.
  • Le query salvate in Query Pack non vengono crittografate con la chiave gestita dal cliente. Selezionare Salva come query legacy durante il salvataggio delle query per proteggerle con la chiave gestita dal cliente.
  • Le query salvate nell'archiviazione vengono considerate artefatti del servizio e il relativo formato può cambiare.
  • Il collegamento di un account Archiviazione per le query rimuove le query esistenti salva dall'area di lavoro. Copia salva le query necessarie prima di questa configurazione. È possibile visualizzare le query salvate usando PowerShell.
  • La query 'history' e 'pin to dashboard' non sono supportate durante il collegamento di Archiviazione Account per le query.
  • È possibile collegare un singolo account Archiviazione a un'area di lavoro per query salvate e query di avviso di ricerca log.
  • Gli avvisi di ricerca log vengono salvati nell'archiviazione BLOB e la crittografia della chiave gestita dal cliente può essere configurata in fase di creazione dell'account Archiviazione o versione successiva.
  • Gli avvisi di ricerca log attivati non contengono risultati di ricerca o query di avviso. È possibile usare le dimensioni degli avvisi per ottenere il contesto negli avvisi attivati.

Configurare BYOS per le query salvate

Collegare un account Archiviazione per le query per mantenere le query salvate nell'account Archiviazione.

N/D

Dopo la configurazione, qualsiasi nuova query di ricerca salvata verrà salvata nella risorsa di archiviazione.

Configurare BYOS per le query di avviso di ricerca log

Collegare un account Archiviazione per gli avvisi per mantenere le query di avviso di ricerca log nell'account Archiviazione.

N/D

Dopo la configurazione, qualsiasi nuova query di avviso verrà salvata nella risorsa di archiviazione.

Customer Lockbox

Lockbox offre il controllo per approvare o rifiutare la richiesta del tecnico Microsoft di accedere ai dati durante una richiesta di supporto.

Lockbox viene fornito nel cluster dedicato in Monitoraggio di Azure, in cui viene concessa l'autorizzazione per accedere ai dati a livello di sottoscrizione.

Altre informazioni su Customer Lockbox per Microsoft Azure

Operazioni delle chiavi gestite dal cliente

La chiave gestita dal cliente viene fornita nel cluster dedicato e queste operazioni sono riportate nell'articolo dedicato del cluster

  • Ottenere tutti i cluster nel gruppo di risorse
  • Ottenere tutti i cluster nella sottoscrizione
  • Aggiornare la prenotazione della capacità nel cluster
  • Aggiornare billingType nel cluster
  • Scollegare un'area di lavoro dal cluster
  • Eliminare il cluster

Limiti e vincoli

  • È possibile creare un massimo di cinque cluster attivi in ogni area e sottoscrizione.

  • Un numero massimo di sette cluster riservati (attivi o eliminati di recente) può esistere in ogni area e sottoscrizione.

  • È possibile collegare un massimo di 1.000 aree di lavoro Log Analytics a un cluster.

  • Nel periodo di 30 giorni è consentito un massimo di due operazioni di collegamento all'area di lavoro in un'area di lavoro specifica.

  • Lo spostamento di un cluster in un altro gruppo di risorse o sottoscrizione non è attualmente supportato.

  • L'aggiornamento del cluster non deve includere i dettagli dell'identità e dell'identificatore della chiave nella stessa operazione. Nel caso in cui sia necessario aggiornare entrambi, l'aggiornamento deve essere in due operazioni consecutive.

  • Lockbox non è attualmente disponibile in Cina.

  • La doppia crittografia viene configurata automaticamente per i cluster creati da ottobre 2020 nelle aree supportate. È possibile verificare se il cluster è configurato per la doppia crittografia inviando una richiesta GET nel cluster e osservando che il isDoubleEncryptionEnabled valore è true per i cluster con doppia crittografia abilitata.

    • Se si crea un cluster e viene visualizzato un errore: "region-name non supporta la doppia crittografia per i cluster", è comunque possibile creare il cluster senza crittografia doppia aggiungendo "properties": {"isDoubleEncryptionEnabled": false} nel corpo della richiesta REST.
    • Non è possibile modificare le impostazioni di crittografia doppia dopo la creazione del cluster.

L'eliminazione di un'area di lavoro collegata è consentita durante il collegamento al cluster. Se si decide di ripristinare l'area di lavoro durante il periodo di eliminazione temporanea, torna allo stato precedente e rimane collegato al cluster.

  • La crittografia della chiave gestita dal cliente si applica ai dati appena inseriti dopo l'ora di configurazione. I dati inseriti prima della configurazione rimangono crittografati con la chiave Microsoft. È possibile eseguire query sui dati inseriti prima e dopo la configurazione della chiave gestita dal cliente senza problemi.

  • Azure Key Vault deve essere configurato come ripristinabile. Queste proprietà non sono abilitate per impostazione predefinita e devono essere configurate tramite interfaccia della riga di comando o PowerShell:

    • Eliminazione temporanea.
    • La protezione dall'eliminazione deve essere attivata per evitare l'eliminazione forzata del segreto, insieme di credenziali anche dopo l'eliminazione temporanea.

  • L'insieme di credenziali delle chiavi di Azure, il cluster e le aree di lavoro devono trovarsi nella stessa area e nello stesso tenant di Microsoft Entra, ma possono trovarsi in sottoscrizioni diverse.

  • L'impostazione del identitytype cluster su None revoca anche l'accesso ai dati, ma questo approccio non è consigliato perché non è possibile annullarlo senza contattare il supporto tecnico. Il modo consigliato per revocare l'accesso ai dati è la revoca delle chiavi.

  • Non è possibile usare la chiave gestita dal cliente con l'identità gestita assegnata dall'utente se l'insieme di credenziali delle chiavi si trova in Collegamento privato (vNet). In questo scenario è possibile usare l'identità gestita assegnata dal sistema.

  • Le query asincrone dei processi di ricerca non sono attualmente supportate nello scenario di chiave gestita dal cliente.

Risoluzione dei problemi

  • Comportamento per la disponibilità di Key Vault:

    • Normale operazione: l'archiviazione memorizza nella cache "AEK" per brevi periodi di tempo e torna a Key Vault per annullare periodicamente il wrapping.

    • Errori di connessione di Key Vault: l'archiviazione gestisce gli errori temporanei (timeout, errori di connessione, problemi "DNS"), consentendo alle chiavi di rimanere nella cache durante il problema di disponibilità e risolve i problemi di disponibilità e i problemi di disponibilità. Le funzionalità di query e inserimento proseguono senza interruzioni.

  • Frequenza di accesso di Key Vault: la frequenza con cui l'archiviazione cluster di Azure accede a Key Vault per eseguire il wrapping e annullare il wrapping è compresa tra 6 e 60 secondi.

  • Se si aggiorna il cluster mentre è in stato di provisioning o si aggiorna lo stato, l'aggiornamento ha esito negativo.

  • Se si verifica un conflitto: errore durante la creazione di un cluster, un cluster con lo stesso nome potrebbe essere stato eliminato negli ultimi 14 giorni e mantenuto riservato. Il nome del cluster eliminato diventa disponibile 14 giorni dopo l'eliminazione.

  • Il collegamento all'area di lavoro al cluster ha esito negativo se è collegato a un altro cluster.

  • Se si crea un cluster e si specifica immediatamente KeyVaultProperties, l'operazione potrebbe non riuscire fino a quando non viene assegnata l'identità nel cluster e concessa in Key Vault.

  • Se si aggiorna un cluster esistente con KeyVaultProperties e 'Get' key Access Policy manca nell'insieme di credenziali delle chiavi, l'operazione non riesce.

  • Se non si distribuisce il cluster, verificare che Azure Key Vault, il cluster e le aree di lavoro collegate si trovino nella stessa area. Le sottoscrizioni possono essere diverse.

  • Se si ruota la chiave in Key Vault e non si aggiornano i dettagli del nuovo identificatore di chiave nel cluster, il cluster continua a usare la chiave precedente e i dati diventano inaccessibili. Aggiornare i dettagli del nuovo identificatore di chiave nel cluster per riprendere l'inserimento e la query dei dati. È possibile aggiornare la versione della chiave con "''" per fare in modo che l'archiviazione usi sempre la versione della chiave lates automaticamente.

  • Alcune operazioni sono a esecuzione prolungata e possono richiedere del tempo, tra cui la creazione del cluster, l'aggiornamento della chiave del cluster e l'eliminazione del cluster. È possibile controllare lo stato dell'operazione inviando una richiesta GET al cluster o all'area di lavoro e osservare la risposta. Ad esempio, l'area di lavoro non collegata non avrà clusterResourceId nelle funzionalità.

  • Messaggi di errore

    Aggiornamento del cluster

    • 400 - Il cluster è in stato di eliminazione. L'operazione asincrona è in corso. Il cluster deve completare l'operazione prima di eseguire qualsiasi operazione di aggiornamento.
    • 400 - KeyVaultProperties non è vuoto ma ha un formato non valido. Vedere l'aggiornamento dell'identificatore di chiave.
    • 400 - Impossibile convalidare la chiave in Key Vault. Potrebbe essere dovuto alla mancanza di autorizzazioni o quando la chiave non esiste. Verificare di impostare la chiave e i criteri di accesso in Key Vault.
    • 400 - La chiave non è recuperabile. Key Vault deve essere impostato su Eliminazione temporanea e Protezione dall'eliminazione. Vedere la documentazione di Key Vault
    • 400 - L'operazione non può essere eseguita ora. Attendere il completamento dell'operazione asincrona e riprovare.
    • 400 - Il cluster è in stato di eliminazione. Attendere il completamento dell'operazione asincrona e riprovare.

    Recupero cluster

    • 404--Cluster non trovato, il cluster potrebbe essere stato eliminato. Se si tenta di creare un cluster con tale nome e si verifica un conflitto, il cluster è in fase di eliminazione.

Passaggi successivi