Condividi tramite

Chiavi gestite dai clienti di Azure Monitor

I dati in Monitoraggio di Azure vengono crittografati con chiavi gestite da Microsoft. È possibile usare la propria chiave di crittografia per proteggere i dati nelle aree di lavoro. Le chiavi gestite dal cliente in Monitoraggio di Azure consentono di controllare il ciclo di vita della chiave di crittografia e l'accesso ai log. Dopo la configurazione, i nuovi dati inseriti nelle aree di lavoro collegate vengono crittografati con la tua chiave in Azure Key Vault o nel Modulo di Sicurezza Hardware (HSM) gestito di Azure Key Vault.

Panoramica delle chiavi gestite 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 o utilizzare varie opzioni per gestire attentamente la crittografia e le chiavi di crittografia.

Azure Monitor assicura che tutti i dati e le query salvate siano crittografati a riposo 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 controllare il ciclo di vita delle chiavi con la possibilità di revocare l'accesso ai dati, crittografare i dati con la propria chiave in Azure Key Vault o il modulo di protezione hardware gestito di Azure Key Vault. La funzionalità chiavi gestite dal cliente è disponibile in cluster dedicati e offre un livello superiore di protezione e controllo.

I dati inseriti in cluster dedicati vengono crittografati due volte, 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 di crittografia o delle chiavi viene 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 SSD vengono crittografati con chiavi gestite da Microsoft indipendentemente dal fatto che si configurino chiavi gestite dal cliente, ma il controllo sull'accesso SSD è conforme alla revoca delle chiavi.

Importante

I cluster dedicati usano un modello tarifario basato su un impegno di almeno 100 GB al giorno.

Funzionamento delle chiavi gestite dal cliente in Monitoraggio di Azure

Azure Monitor utilizza l'Identità Gestita per concedere l'accesso alla propria chiave in Azure Key Vault. L'identità dei cluster di Log Analytics è supportata a livello di cluster. Per fornire chiavi gestite dal cliente in più spazi di lavoro, una risorsa cluster di Log Analytics funge da connessione di identità intermedia tra il Key Vault e gli spazi di lavoro di Log Analytics. L'archiviazione del cluster utilizza l'identità gestita associata al cluster per autenticarsi su 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 identitytype è 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 identitytype è impostato su UserAssigned e concedendole le autorizzazioni nel Key Vault prima della creazione del cluster.

Configurare chiavi gestite dal cliente in un nuovo cluster o un cluster dedicato esistente con aree di lavoro collegate che inseriscono dati. È possibile scollegare le aree di lavoro da un cluster in qualsiasi momento. I nuovi dati inseriti nelle aree di lavoro collegate vengono crittografati con la chiave e i dati meno recenti rimangono crittografati con chiavi gestite da Microsoft. La configurazione non interrompe l’ingestione né le query, che vengono eseguite in modo continuo su dati nuovi e vecchi. Quando si scollegano le aree di lavoro da un cluster, i nuovi dati inseriti vengono crittografati con chiavi gestite da Microsoft.

Importante

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

Screenshot della panoramica della chiave gestita dal cliente.

  1. Key Vault (archivio di chiavi)
  2. Risorsa cluster di Log Analytics con un'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

Tipi di chiavi di crittografia

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

  • KEK - Chiave per la crittografia delle chiavi (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.
  • L'AEK viene usato per derivare deks, ovvero le chiavi usate per crittografare ogni blocco di dati scritto su disco.
  • Quando si configura il KEK gestito dal cliente nel cluster, l'archiviazione del cluster esegue le richieste wrap e unwrap al Key Vault per la crittografia e la decrittografia AEK.
  • Il KEK non lascia mai il Key Vault. Se si archivia la chiave in un modulo di protezione hardware gestito di Azure Key Vault, la chiave non lascerà mai quell'hardware.
  • Azure Storage utilizza l'identità gestita associata al 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 dedicato
  3. Concessione delle autorizzazioni a Key Vault
  4. Aggiornamento di un cluster dedicato con i dettagli dell'identificatore di chiave
  5. Collegamento di aree di lavoro

Una configurazione della chiave gestita dal cliente non supporta la configurazione dei dettagli dell'identità e dell'identificatore di chiave. Eseguire queste operazioni tramite PowerShell, l'interfaccia della riga di comando o le richieste REST .

Autorizzazioni necessarie

Per eseguire azioni correlate al cluster, sono necessarie queste autorizzazioni:

Azione Autorizzazioni o ruoli necessari
Creare un cluster dedicato Le autorizzazioni Microsoft.Resources/deployments/* e Microsoft.OperationalInsights/clusters/write, come specificato dal ruolo predefinito Collaboratore per Log Analytics, ad esempio
Modificare le proprietà del cluster Le autorizzazioni Microsoft.OperationalInsights/clusters/write, come specificato dal ruolo predefinito Collaboratore per Log Analytics, ad esempio
Collegare aree di lavoro a un cluster Ad esempio, le autorizzazioni Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/write e Microsoft.OperationalInsights/workspaces/linkedservices/write, come specificato dal ruolo predefinito Collaboratore per Log Analytics.
Controllare lo stato del collegamento dell'area di lavoro Autorizzazioni Microsoft.OperationalInsights/workspaces/read per l'area di lavoro Log Analytics fornite dal ruolo predefinito Lettore di Log Analytics, ad esempio
Ottenere i cluster o controllare lo stato del provisioning di un cluster Le autorizzazioni Microsoft.OperationalInsights/clusters/read, come specificato dal ruolo predefinito Lettore per Log Analytics, ad esempio
Aggiornare il livello di impegno o il tipo di fatturazione in un cluster Le autorizzazioni Microsoft.OperationalInsights/clusters/write, come specificato dal ruolo predefinito Collaboratore per Log Analytics, ad esempio
Concedere le autorizzazioni necessarie Ruolo Proprietario o Collaboratore con autorizzazioni */write, oppure il ruolo predefinito Collaboratore Log Analytics, che dispone di permessi Microsoft.OperationalInsights/*.
Scollegare un'area di lavoro dal cluster Le autorizzazioni Microsoft.OperationalInsights/workspaces/linkedServices/delete, come specificato dal ruolo predefinito Collaboratore per Log Analytics, ad esempio
Eliminare un cluster dedicato Le autorizzazioni Microsoft.OperationalInsights/clusters/delete, come specificato dal ruolo predefinito Collaboratore per Log Analytics, ad esempio

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. La configurazione del servizio Azure Key Vault deve essere recuperabile per proteggere la chiave e l'accesso ai dati in Azure Monitor. È possibile verificare questa configurazione nelle proprietà del tuo Key Vault, devono essere abilitate sia la Eliminazione reversibile che la Protezione dalla rimozione.

Importante

È consigliabile configurare la notifica tramite Griglia di eventi di Azure per rispondere efficacemente agli eventi di Azure Key Vault, ad esempio una chiave che sta per scadere. Quando la chiave scade, l'inserimento e le query non sono interessati, ma non è possibile aggiornare la chiave nel cluster. Seguire questi passaggi per risolverlo

  1. Identificare la chiave usata nella pagina di panoramica del cluster nel portale di Azure, in Visualizzazione JSON
  2. Estendere la data di scadenza della chiave in Azure Key Vault
  3. Aggiornare il cluster con la chiave attiva, preferibilmente con il valore di versione "", per usare sempre la versione più recente automaticamente

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 identitytype proprietà su SystemAssigned o UserAssigned quando si crea il cluster per consentire l'accesso al Key Vault per le operazioni di crittografia e decrittografia dei dati.

Ad esempio, aggiungere queste proprietà nel corpo della richiesta 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:

  • L'identità e la chiave non possono essere aggiornate contemporaneamente per un cluster. Eseguire l'aggiornamento in due operazioni consecutive.
  • Quando si esegue l'aggiornamento di SystemAssigned a UserAssignedConcedere UserAssign l'identità in Key Vault, quindi aggiornare identity nel cluster.
  • Quando si esegue l'aggiornamento di UserAssigned a SystemAssignedConcedere SystemAssigned l'identità in Key Vault, quindi aggiornare identity nel cluster.

Seguire la procedura illustrata nell'articolo dedicato al cluster .

Concedere le autorizzazioni di Key Vault

In Key Vault sono disponibili due modelli di autorizzazione per concedere l'accesso al cluster e all'archiviazione sottostante: il controllo degli accessi in base al ruolo di Azure (Azure RBAC) e i criteri di accesso di Vault (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. Apri il Key Vault nel portale di Azure e seleziona Impostazioni>Configurazione dell'accesso>Controllo di accesso basato sui ruoli di Azure e Applica.
    2. Selezionare Vai al controllo di accesso (IAM) e aggiungere l'assegnazione di ruolo utente Utente crittografo del servizio di crittografia di Key Vault.
    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)

    Apri il Key Vault nel portale di Azure e seleziona Access Policies>Vault access policy>+ Add Access Policy per creare una policy con queste impostazioni:

    • Autorizzazioni per le chiavi: selezionare Ottieni>Esegui il wrapping della chiave e Annulla il wrapping della chiave.
    • Selezionare un'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 principale del 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 Get è necessaria per verificare che il tuo Key Vault sia configurato come recuperabile per proteggere la tua chiave e l'accesso ai tuoi dati di Azure Monitor.

Aggiornare il cluster con i dettagli dell'ID chiave

Tutte le operazioni nel cluster richiedono l'autorizzazione dell'azione Microsoft.OperationalInsights/clusters/write. È possibile concedere l'autorizzazione attraverso il Proprietario o il Collaboratore che contiene l'azione */write, oppure attraverso il ruolo di 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 AEKwrap e unwrap.

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.
  • Se si abilita o si modifica la CMK, usare l'API REST anziché l'interfaccia della riga di comando. La CLI di aggiornamento del cluster invia un aggiornamento alla capacità anche quando questa proprietà non è utilizzata nel comando, attivando soglie di 30 giorni di cambiamento o un minimo di 500 GB.

Screenshot della sezione della concessione delle autorizzazioni di Key Vault.

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 la configurazione del cluster. Se si collegano aree di lavoro e si inseriscono dati prima del provisioning, i dati inseriti vengono eliminati e non possono essere recuperati.

Seguire la procedura illustrata nell'articolo sui cluster dedicati.

Seguire la procedura illustrata nell'articolo sui cluster dedicati.

Revoca delle chiavi

Importante

  • Il modo consigliato per revocare l'accesso ai tuoi dati consiste nel disabilitare la tua chiave o eliminare il criterio di accesso nel Key Vault.
  • L'impostazione di identitytype 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 del cluster rispetta sempre le modifiche apportate alle autorizzazioni delle chiavi entro un'ora o meno, e l'archiviazione diventa non 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. La politica di conservazione dei dati governa i dati inaccessibili e li elimina quando viene raggiunto il periodo di 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 nell'operazione di revoca delle chiavi e diventano inaccessibili. L'archiviazione del cluster tenta di raggiungere Periodicamente Key Vault per le operazioni wrap e unwrap. Una volta abilitata la chiave e completato unwrap, i dati SSD vengono ricaricati dalla memoria. La funzionalità di inserimento dati e query viene ripresa entro 30 minuti.

Rotazione delle chiavi

La rotazione delle chiavi ha due modalità:

  • Autorotazione: aggiornare le proprietà nel cluster "keyVaultProperties" e omettere la proprietà "keyVersion", oppure impostarla su "". L'archiviazione usa automaticamente la versione della chiave più recente.
  • Aggiornamento esplicito della versione della chiave: modifica "keyVaultProperties" proprietà e aggiorna la versione della chiave nella proprietà "keyVersion". La rotazione delle chiavi richiede un aggiornamento esplicito della proprietà "keyVersion" 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 sono sempre crittografati con la chiave di crittografia dell'account (AEK), che è crittografata con la nuova versione della chiave di crittografia (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 nella sintassi delle query o nei commenti. Le organizzazioni vincolate da requisiti normativi e di conformità rigorosi devono mantenere tali informazioni crittografate con la chiave gestita dal cliente. Azure Monitor consente di archiviare query salvate, funzioni e avvisi di ricerca log crittografati con la tua chiave nel proprio account di archiviazione quando è collegato all'area di lavoro.

Chiave gestita dal cliente per Workbooks

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, Azure Notebooks 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 salvate

  • È necessario disporre delle autorizzazioni di "scrittura" nell'area di lavoro e nell'account di archiviazione.
  • L'account di archiviazione deve essere StorageV2 e nella stessa area dell'area di lavoro Log Analytics.
  • Quando si collega un account di archiviazione per le query salvate, le query e le funzioni salvate esistenti vengono rimosse dall'area di lavoro per la privacy. Se è necessario avere queste informazioni utili, copiare le query e le funzioni salvate esistenti prima della configurazione. È possibile visualizzare le query salvate usando PowerShell o quando si esporta il modello in Automazione nell'area di lavoro.
  • Le query salvate in Query Pack non vengono archiviate nell'account di archiviazione collegato e non possono essere crittografate con la chiave gestita dal cliente. È consigliabile salvare come Query Legacy per proteggere le query con una chiave gestita dal Cliente.
  • Le query salvate e le funzioni nell'account di archiviazione collegato sono considerate artefatti del servizio e il relativo formato potrebbe cambiare.
  • La "cronologia" delle query e la funzione "aggiungi al dashboard" non sono supportate durante il collegamento dell'account di archiviazione per le query salvate.
  • È possibile collegare un singolo o separato account di archiviazione per le query salvate e le query di avviso di ricerca nei log.
  • Per mantenere le query e le funzioni crittografate con la tua chiave, configurare l'account di archiviazione collegato con una chiave gestita dal cliente. Questa operazione può essere eseguita durante la creazione dell'account di archiviazione o successivamente.

Configurare l'account di archiviazione collegato per le query salvate

Collega un account di archiviazione per le query e le funzioni salvate, in modo da mantenere le query salvate nel tuo account di archiviazione.

Nota

L'operazione rimuove le query salvate e le funzioni dallo spazio di lavoro verso una tabella nel tuo account di archiviazione. È possibile scollegare l'account di archiviazione per le query salvate per spostare le query e le funzioni salvate nell'area di lavoro. Aggiornare il browser se le query o le funzioni non salvate non vengono visualizzate nel portale di Azure dopo l'operazione.

N/D

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

Configurare l'account di archiviazione collegato per le query di avviso di ricerca log

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

  • Le query di avviso vengono salvate come blob nell'Account di Archiviazione.
  • Gli avvisi di ricerca log attivati non contengono i risultati della ricerca o la query di avviso. Usare le dimensioni degli avvisi per ottenere il contesto per gli avvisi attivati.
  • Per mantenere le query e le funzioni crittografate con la tua chiave, configurare l'account di archiviazione collegato con una chiave gestita dal cliente. Questa operazione può essere eseguita durante la creazione dell'account di archiviazione o successivamente.

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 nel tuo archivio.

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 in un cluster dedicato nel Monitor di Azure, dove l'autorizzazione ad accedere ai dati è concessa 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
  • Visualizza 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 di tabella 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 GET richiesta nel cluster e osservando che il isDoubleEncryptionEnabled valore è 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 identitytype 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 una chiave gestita dal cliente con l'identità gestita assegnata dall'utente se l'insieme di credenziali delle chiavi si trova in una rete privata (rete virtuale). Usare un'identità gestita assegnata dal sistema in questo scenario.

Risoluzione dei problemi

  • Comportamento in base alla disponibilità di Key Vault:

    • L'archiviazione normale delle operazioni memorizza nella cache AEK per brevi periodi di tempo e torna periodicamente a Key Vault a unwrap.

    • 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 superando brevi interruzioni e problemi di disponibilità. Le funzionalità di query e inserimento proseguono senza interruzioni.

  • Frequenza di accesso a Key Vault: la frequenza con cui lo storage del cluster accede a Key Vault per le operazioni wrap e unwrap varia tra 6 e 60 secondi.

  • Se si aggiorna il cluster mentre è nello stato di provisioning o di aggiornamento, l'aggiornamento fallisce.

  • Se si verifica un errore di conflitto durante la creazione di un cluster, è possibile che un cluster con lo stesso nome sia stato eliminato negli ultimi 14 giorni e il suo nome sia stato riservato. I nomi dei cluster eliminati diventano disponibili 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 KeyVaultProperties immediatamente , l'operazione potrebbe non riuscire fino a quando non viene assegnata un'identità al cluster e concessa a Key Vault.

  • Se si aggiorna un cluster esistente con KeyVaultProperties e Get e la policy di accesso chiave manca nel Key Vault, l'operazione fallisce.

  • Se non riesci a distribuire il cluster, verifica che Azure Key Vault, il cluster e le aree di lavoro collegate si trovino nella stessa regione. 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 dei dati e la funzionalità di query. Aggiorna la versione della chiave con la notazione '' per garantire che l'archiviazione utilizzi automaticamente sempre la versione più recente della chiave.

  • 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 GET richiesta al cluster o all'area di lavoro e osservare la risposta. Ad esempio, un'area di lavoro non collegata non ha l'oggetto clusterResourceId in features.

  • 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 - Il cluster non è stato 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