Condividi tramite

Chiavi gestite 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 nell'HSM, "modulo di protezione hardware", gestito da Azure Key Vault.

Esaminare le limitazioni e i vincoli prima della configurazione.

Panoramica delle chiavi gestite dal cliente

La crittografia di dati inattivi è un requisito comune per la privacy e la sicurezza nelle organizzazioni. È possibile lasciare che Azure gestisca completamente la crittografia di dati inattivi oppure è possibile usare diverse opzioni per gestire con precisione 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. L'uso della crittografia da parte di Monitoraggio di Azure è identico a quello della crittografia di Archiviazione di Azure.

Per gestire il ciclo di vita delle chiavi e poter revocare l'accesso ai dati, è possibile crittografare i dati con la propria chiave usando Azure Key Vault.

Le chiavi gestite dal cliente sono disponibili in cluster dedicati e offrono un livello superiore di protezione e controllo. I dati vengono crittografati due volte nell'archiviazione, ovvero a livello di servizio usando chiavi gestite da Microsoft o chiavi gestite dal cliente e 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 o delle chiavi di crittografia può essere compromesso. I cluster dedicati consentono 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 dell'unità SSD vengono crittografati con chiavi Microsoft indipendentemente dalla configurazione delle chiavi gestite dal cliente, ma il controllo sull'accesso all'unità SSD è conforme alla revoca delle chiavi.

Importante

I cluster dedicati usano un modello tariffario del livello di impegno di almeno 100 GB al giorno.

Funzionamento delle chiavi gestite 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 le chiavi gestite dal cliente in più aree di lavoro, una risorsa cluster Log Analytics funge da connessione di identità intermedia tra Key Vault e le aree di lavoro Log Analytics. L'archiviazione del cluster usa l'identità gestita associata al cluster per l'autenticazione ad Azure Key Vault 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 generata automaticamente con il cluster quando identity type è impostata su SystemAssigned. Questa identità viene usata in un secondo momento per concedere all'insieme di credenziali delle chiavi l'accesso all'insieme di credenziali delle chiavi per la crittografia e la decrittografia dei dati.
  • L'identità gestita assegnata dall'utente consente di configurare le chiavi gestite dal cliente durante la creazione del cluster, quando identity type è impostata su UserAssignede concedendole le autorizzazioni nell'insieme di credenziali delle chiavi prima della creazione del cluster.

È possibile configurare chiavi gestite dal cliente in un nuovo cluster o in un cluster esistente che è collegato alle aree di lavoro e sta già inserendo i 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 le chiavi Microsoft. La configurazione della chiave gestita dal cliente non influisce sulle query, che continuano a essere eseguite su dati vecchi e nuovi senza problemi. È possibile scollegare le aree di lavoro da un cluster in qualsiasi momento. I nuovi dati vengono inseriti dopo che il collegamento viene crittografato con le chiavi Microsoft e le query vengono eseguite sui dati precedenti e i nuovi dati senza problemi.

Importante

La funzionalità delle chiavi gestite dal cliente è disponibile a livello di area. Azure Key Vault di Azure, il cluster e le aree di lavoro collegate devono trovarsi nella stessa area, ma possono trovarsi in sottoscrizioni diverse.

Screenshot della panoramica della chiave gestita dal cliente.

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

Funzionamento delle chiavi di crittografia

La crittografia dei dati di archiviazione include tre tipi di chiavi:

  • "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 di archiviazione, noto come "AEK".
  • La chiave "AEK" viene usata per ottenere chiavi "DEK", ovvero le chiavi usate per crittografare ogni blocco di dati scritti su disco.
  • Quando si configura una chiave in Azure Key Vault e si aggiornano i dettagli della chiave nel cluster, l'archiviazione cluster esegue richieste di "wrapping" e "unwrapping" (annullamento di wrapping) "AEK" per la crittografia e la decrittografia.
  • La chiave "KEK" non esce mai dall'insieme di credenziali delle chiavi e se si usa un "HSM" gestito, non esce mai dall'hardware.
  • Archiviazione di Azure usa l'identità gestita associata alla 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'ID chiave
  5. Collegamento di aree di lavoro

La configurazione della chiave gestita dal cliente non è attualmente supportata nel portale di Azure 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 Azure Key Vault esistente nell'area in cui è pianificato il cluster. In Azure Key Vault generare o importare una chiave da usare per la crittografia dei log. L'istanza di Azure Key Vault deve essere configurata come recuperabile 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 delle impostazioni di eliminazione temporanea ed eliminazione della protezione.

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 identity type la proprietà su SystemAssigned o UserAssigned quando si crea il cluster per consentire l'accesso all'insieme di credenziali delle chiavi per le operazioni di crittografia e decrittografia dei dati.

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

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

Nota

Il tipo di identità può essere modificato dopo la creazione del cluster senza interruzioni per l'inserimento o le query con le considerazioni seguenti

  • Aggiornamento SystemAssigned a UserAssigned- Concedere l'identità UserAssign in Key Vault e quindi aggiornare identity type nel cluster
  • Aggiornamento a SystemAssigned: poiché l'identità UserAssigned gestita assegnata dal sistema è stata creata dopo l'aggiornamento del cluster identity type con SystemAssigned, è necessario seguire questa procedura
    1. Aggiornare il cluster e rimuovere la chiave: impostare keyVaultUri, keyNamee keyVersion con il valore ""
    2. Aggiornare il cluster identity type a SystemAssigned
    3. Aggiornare Key Vault e concedere le autorizzazioni all'identità
    4. Aggiornare la chiave nel cluster

Seguire la procedura illustrata nell'articolo sui 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 all'insieme di credenziali (legacy).

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

    Per aggiungere assegnazioni di ruolo, è necessario avere un ruolo con autorizzazioni Microsoft.Authorization/roleAssignments/write e Microsoft.Authorization/roleAssignments/delete, ad esempio Amministratore Accesso utenti o Proprietario.

    1. Aprire l'insieme di credenziali delle chiavi in portale di Azure e selezionare Impostazioni>>Configurazione dell'accesso in base al ruolo di Azure e Applica
    2. Fare clic sul pulsante Vai al controllo di accesso (IAM) e aggiungere l'assegnazione di ruolo utente crittografia crittografia del servizio di crittografia dell'insieme di credenziali delle chiavi.
    3. Selezionare Identità gestita nella scheda Membri e selezionare la sottoscrizione per l'identità e l'identità come membro

    Screenshot della concessione delle autorizzazioni di controllo degli accessi in base al ruolo di Key Vault.

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

    Aprire l'insieme di credenziali delle chiavi nel portale di Azure e selezionare Criteri di accesso>Criteri di accesso all'insieme di credenziali>+ Aggiungi criterio di accesso per creare un criterio con queste impostazioni:

    • Autorizzazioni chiave: selezionare le autorizzazioni Recupera, Esegui il wrapping della chiave e Annulla 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 della sezione della concessione delle autorizzazioni dei criteri di accesso di Key Vault.

    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'ID chiave

Tutte le operazioni nel cluster richiedono l'autorizzazione dell'azione Microsoft.OperationalInsights/clusters/write. 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 l'annullamento del wrapping "AEK".

Importante

  • La rotazione delle chiavi può essere automatica o per versione esplicita 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 della chiave nella stessa operazione. Se è necessario aggiornare entrambi, l'aggiornamento deve avere luogo in due operazioni consecutive.

Screenshot della sezione della concessione delle autorizzazioni di Key Vault.

Aggiornare KeyVaultProperties nel cluster con i dettagli dell'ID 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 le 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" nell'area di lavoro e nel cluster. Include Microsoft.OperationalInsights/workspaces/write e Microsoft.OperationalInsights/clusters/write.

Seguire la procedura illustrata nell'articolo sui 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 in Azure Key Vault.
  • L'impostazione di identity type del cluster su None revoca anche l'accesso ai dati, tuttavia 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 anche prima, così l'archiviazione non è più disponibile. I nuovi dati inseriti nelle aree di lavoro collegate vengono eliminati e non sono recuperabili. I dati non sono accessibili in queste aree di lavoro e le query hanno esito negativo. I dati inseriti in precedenza rimangono nello spazio di archiviazione purché il cluster e le aree di lavoro non siano eliminate. I dati inaccessibili sono regolati dai criteri di conservazione dei dati e sono eliminati al raggiungimento della scadenza della 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 sull'unità SSD vengono eliminati durante l'operazione di revoca della chiave e diventano inaccessibili. L'archiviazione cluster tenta di raggiungere Key Vault per eseguire periodicamente il wrapping e l'annullamento del wrapping e, una volta abilitata la chiave, l'anullamento del wrapping ha esito positivo, 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 "keyVaultProperties" le proprietà nel cluster e omettere "keyVersion" la proprietà oppure impostarla su "". L'archiviazione usa automaticamente la versione della chiave più recente.
  • Aggiornamento esplicito della versione della chiave: aggiornare "keyVaultProperties" le proprietà e aggiornare la versione della chiave nella "keyVersion" proprietà . La rotazione delle chiavi richiede l'aggiornamento esplicito della "keyVersion" proprietà nel cluster. Per altre informazioni, vedere Aggiornare il cluster con i dettagli dell'identificatore 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 durante e 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, pertanto è 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 di archiviazione quando è collegato all'area di lavoro.

Chiave gestita dal cliente per Cartelle di lavoro

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

Screenshot del salvataggio di cartelle di lavoro.

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 di archiviazione per le query salvate, il servizio archivia le query salvate e le query di avviso di ricerca log nell'account di archiviazione. Disponendo del controllo sui criteri di crittografia dei dati inattivi dell'account di archiviazione, è possibile proteggere le query salvate e gli avvisi di ricerca log con la chiave gestita dal cliente. Si sarà tuttavia responsabili dei costi associati a tale account di archiviazione.

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

  • È necessario disporre delle autorizzazioni di "scrittura" nell'area di lavoro e nell'account di archiviazione.
  • Assicurarsi di creare l'account di 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 durante la creazione dell'account di archiviazione.
  • Le query salvate in pacchetto query non vengono crittografate con la chiave gestita dal cliente. Selezionare Salva come query di 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 di archiviazione delle query rimuove le query esistenti e salva query dall'area di lavoro. Copia le query salvate necessarie prima di questa configurazione. È possibile visualizzare le query salvate usando PowerShell.
  • La "cronologia" delle query la funzioni "aggiungi alla dashboard" non sono supportate durante il collegamento dell'account di archiviazione delle query.
  • È possibile collegare un singolo account di archiviazione a un'area di lavoro sia per le query salvate sia per le 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 al momento della creazione dell'account di 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 di archiviazione delle query per mantenere le query salvate nell'account di 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 di archiviazione per gli avvisi per mantenere le query di avviso di ricerca log nell'account di 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 al 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 sul cluster dedicato

  • 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. Se è necessario aggiornare entrambi, l'aggiornamento deve avere luogo in due operazioni consecutive.

  • Lockbox non è attualmente disponibile in Cina.

  • Lockbox non si applica alle tabelle con il piano Ausiliario.

  • 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 valore isDoubleEncryptionEnabled sia true per i cluster con crittografia doppia 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 doppia crittografia dopo la creazione del cluster.

  • L'eliminazione di un'area di lavoro collegata è consentita quando è collegata al cluster. Se si decide di ripristinare l'area di lavoro durante il periodo di eliminazione temporanea, l'area di lavoro torna allo stato precedente e rimane collegata 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 le chiavi 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 recuperabile. Queste proprietà non sono abilitate per impostazione predefinita e devono essere configurate tramite interfaccia della riga di comando o PowerShell:

  • Azure Key Vault, 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 di identity type del cluster su None revoca anche l'accesso ai dati, tuttavia 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 Azure Key Vault si trova in Collegamento privato (vNet). In questo scenario è possibile usare l'identità gestita assegnata dal sistema.

  • Il piano di tabella Ausiliario non supporta le chiavi gestite dal cliente. I dati nelle tabelle con il piano Ausiliario sono crittografati con chiavi gestite da Microsoft, anche se si proteggono i dati nel resto dell'area di lavoro di Log Analytics usando la propria chiave di crittografia.

Risoluzione dei problemi

  • Comportamento in base alla disponibilità di Key Vault:

    • Funzionamento normale: l'archiviazione memorizza la chiave "AEK" nella cache per brevi periodi di tempo e torna a Key Vault per annullare il ritorno a capo periodicamente.

    • 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 nel corso del 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 a Key Vault: la frequenza con cui l'archiviazione cluster di Azure accede a Key Vault per le operazioni di wrapping e annullamento del 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 dell'area di lavoro a un cluster ha esito negativo se l'area di lavoro è collegata a un altro cluster.

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

  • Se si aggiorna il cluster esistente con KeyVaultProperties e i Criteri di accesso "Recupera" non sono presenti in Key Vault, l'operazione ha esito negativo.

  • 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 ID chiave nel cluster, il cluster continua a usare la chiave precedente e i dati diventano inaccessibili. Aggiornare i dettagli del nuovo ID chiave nel cluster per riavviare l'inserimento dati e l'esecuzione di query sui dati. È possibile aggiornare la versione della chiave con "''" per fare in modo che l'archiviazione usi sempre automaticamente la versione della chiave più recente.

  • 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à il clusterResourceId in funzionalità.

  • Messaggi di errore

    Aggiornamento 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 aggiornamento dell'identificatore di chiave.
    • 400 - Non è stato possibile convalidare la chiave in Key Vault. Potrebbe essere dovuto alla mancanza di autorizzazioni o a una chiave inesistente. Verificare di aver impostato i criteri di accesso e chiave in Key Vault.
    • 400 - La chiave non è recuperabile. Key Vault deve essere impostato su Eliminazione temporanea e Protezione dalla rimozione definitiva. Vedere Documentazione di Key Vault
    • 400 - L'operazione non può essere eseguita in questo momento. 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 prova a creare un cluster con tale nome e si verifica un conflitto, il cluster è in fase di eliminazione.

Passaggi successivi