Eseguire la migrazione dai criteri di accesso al controllo degli accessi in base al ruolo (RBAC) di Azure

Azure Key Vault offre due modelli di controllo di accesso: Azure Controllo degli accessi in base al ruolo (Azure RBAC) e un modello di criteri di accesso. Azure RBAC è il modello di controllo degli accessi predefinito e consigliato per Azure Key Vault. A partire dalla versione dell'API 2026-02-01, Azure RBAC è il modello di controllo degli accessi predefinito per i nuovi vault. Per un confronto tra i due metodi di autorizzazione, vedere Azure role-based access control (Azure RBAC) e criteri di accesso.

Per informazioni sulla preparazione delle distribuzioni esistenti per questa modifica, vedere Prepare per Key Vault API versione 2026-02-01 e successive.

Questo articolo fornisce le informazioni necessarie per eseguire la migrazione di un Key Vault da un modello di criteri di accesso a un modello Azure RBAC (Controllo degli Accessi Basato sui Ruoli).

Criteri di accesso al mapping dei ruoli di Azure

Azure RBAC include diversi ruoli predefiniti di Azure che possono essere assegnati a utenti, gruppi, principal di servizi e identità gestite. Se i ruoli predefiniti non soddisfano le esigenze specifiche dell'organizzazione, è possibile creare ruoli personalizzati Azure ruoli personalizzati.

Key Vault ruoli predefiniti per chiavi, certificati e gestione degli accessi ai segreti:

• amministratore di Key Vault
• Lettore di Key Vault
• Operatore Cancellazione Key Vault
• Responsabile dei Certificati di Key Vault
• utente certificato Key Vault
• Responsabile Crypto di Key Vault
• Utente di crittografia di Key Vault
• Key Vault Encryption del Servizio Utente di Crittografia
• Key Vault utente della versione di Crypto Service
• Responsabile dei Segreti del Key Vault
• User di Key Vault Secrets

Per altre informazioni sui ruoli predefiniti esistenti, vedere Azure ruoli predefiniti

I criteri di accesso all'insieme di credenziali possono essere assegnati con autorizzazioni selezionate singolarmente o con modelli di autorizzazione predefiniti.

Modelli di autorizzazione predefiniti dei criteri di accesso:

• Gestione di chiavi, segreti e certificati
• Gestione delle chiavi e dei segreti
• Gestione di segreti e certificati
• Gestione chiavi
• Gestione dei segreti
• Gestione dei certificati
• connettore SQL Server
• Azure Data Lake Storage o Archiviazione di Azure
• Backup di Azure
• Chiave cliente di Exchange Online
• SharePoint Online Customer Key
• Azure Information BYOK

Modelli di criteri di accesso alla mappatura dei ruoli di Azure

Mapping degli ambiti delle assegnazioni

Azure RBAC per Key Vault consente l'assegnazione dei ruoli agli ambiti seguenti:

• Gruppo di gestione
• Abbonamento
• Gruppo di risorse
• risorsa Key Vault
• Singole chiavi, segreti e certificati

I criteri di accesso sono limitati all'assegnazione di criteri solo a livello di risorsa Key Vault.

In generale, è consigliabile avere un insieme di credenziali delle chiavi per ogni applicazione e gestire l'accesso a livello di insieme di credenziali delle chiavi. Esistono scenari in cui la gestione dell'accesso in altri ambiti può semplificare la gestione degli accessi.

• Infrastruttura, amministratori della sicurezza e operatori: la gestione di gruppi di insiemi di credenziali a livello di gruppo di gestione, gruppo di risorse o sottoscrizione con criteri di accesso dell'insieme di credenziali richiede la gestione dei criteri per ogni insieme di credenziali delle chiavi. Azure RBAC consente di creare un'assegnazione di ruolo nel gruppo di gestione, nella sottoscrizione o nel gruppo di risorse. Tale assegnazione verrà applicata a tutti i nuovi insiemi di credenziali delle chiavi creati nello stesso ambito. In questo scenario, è consigliabile usare il Privileged Identity Management con accesso Just-In-Time anziché fornire accesso permanente.

• Applicazioni: esistono scenari in cui l'applicazione deve condividere il segreto con altre applicazioni. Per evitare di concedere l'accesso a tutti i segreti, è necessario creare criteri di accesso all'insieme di credenziali delle chiavi separati. Azure RBAC consente di assegnare un ruolo con ambito per un singolo segreto invece di utilizzare un singolo Key Vault.

Come eseguire la migrazione

Seguire i seguenti passaggi per eseguire la migrazione del Key Vault a Azure RBAC (controllo degli accessi in base al ruolo) dai criteri di accesso:

• Preparazione: assicurarsi di disporre delle autorizzazioni appropriate e di un inventario delle applicazioni.
• Inventario: documentare tutti i criteri di accesso e le autorizzazioni esistenti.
• Creare ruoli RBAC di Azure: Assegnare i ruoli RBAC di Azure appropriati a ogni entità di sicurezza.
• Abilita Azure RBAC: Passa all'insieme di credenziali delle chiavi per utilizzare il modello di controllo degli accessi RBAC di Azure.
• Convalida: testare l'accesso per garantire che tutte le applicazioni e gli utenti mantengano l'accesso appropriato.
• Monitoraggio: configurare il monitoraggio e gli avvisi per i problemi di accesso.

Prerequisiti

Prima di avviare la migrazione, assicurarsi di disporre di:

1. Permessi necessari: è necessario disporre dei seguenti permessi nel Key Vault:

   • autorizzazione Microsoft.Authorization/roleAssignments/write, inclusa nei ruoli Proprietario e Amministratore dell'accesso degli utenti
   • autorizzazione Microsoft.KeyVault/vaults/write inclusa nel ruolo Collaboratore Key Vault

   Note

   I ruoli di amministratore della sottoscrizione classica (amministratore del servizio e Co-Administrator) non sono supportati.

2. Inventario di applicazioni e identità: elencare tutte le applicazioni, i servizi e gli utenti che accedono all'insieme di credenziali delle chiavi e documentare tutti i criteri di accesso correnti e le autorizzazioni concesse.

Inventario dei criteri di accesso correnti

Documentare tutti i criteri di accesso esistenti, notando le entità di sicurezza (utenti, gruppi, entità servizio) e le relative autorizzazioni.

# List all current access policies
az keyvault show --name <vault-name> --resource-group <resource-group> --query properties.accessPolicies

# List all current access policies
$vault = Get-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<resource-group>"
$vault.AccessPolicies

Creare assegnazioni di ruolo equivalenti per il controllo degli accessi basato sui ruoli di Azure

Per ogni principale di sicurezza con un criterio di accesso, creare una o più assegnazioni di ruolo di Azure RBAC in base alla tabella di mapping precedente.

# Example for Key Vault Administrator role:
az role assignment create --role "Key Vault Administrator" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Secrets Officer:
az role assignment create --role "Key Vault Secrets Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Crypto Officer:
az role assignment create --role "Key Vault Crypto Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Certificates Officer:
az role assignment create --role "Key Vault Certificates Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Administrator role:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Administrator" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Secrets Officer:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Secrets Officer" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Crypto Officer:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Crypto Officer" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Certificates Officer:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Certificates Officer" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

Abilitare controllo degli accessi basato sui ruoli di Azure

Dopo aver creato tutte le assegnazioni di ruolo necessarie, passare il vault a utilizzare il modello di autorizzazione Azure RBAC.

# Switch the vault to Azure RBAC
az keyvault update --name <vault-name> --resource-group <resource-group> --enable-rbac-authorization true

# Switch the vault to Azure RBAC permission model
$vault = Get-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<resource-group>"
Update-AzKeyVault -VaultName $vault.VaultName -ResourceGroupName $vault.ResourceGroupName -EnableRbacAuthorization $true

Convalidare l'accesso

Verificare l'accesso all'insieme di credenziali per garantire che tutte le applicazioni e gli utenti possano comunque eseguire le operazioni richieste.

# Try to list secrets to verify access
az keyvault secret list --vault-name <vault-name>

# Try to get a secret to verify access
az keyvault secret show --vault-name <vault-name> --name <secret-name>

# Try to list secrets to verify access
Get-AzKeyVaultSecret -VaultName "<vault-name>"

# Try to get a secret to verify access
Get-AzKeyVaultSecret -VaultName "<vault-name>" -Name "<secret-name>"

Configurare il monitoraggio e gli avvisi

Dopo la migrazione, configurare il monitoraggio appropriato per rilevare eventuali problemi di accesso:

# Enable diagnostics logging for Key Vault
az monitor diagnostic-settings create --resource <vault-id> --name KeyVaultLogs --logs "[{\"category\":\"AuditEvent\",\"enabled\":true}]" --workspace <log-analytics-workspace-id>

# Get the vault resource ID
$vaultResourceId = (Get-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<resource-group>").ResourceId

# Enable diagnostics logging for Key Vault
$logs = @()
$logs += New-AzDiagnosticSettingLogSettingsObject -Category "AuditEvent" -Enabled $true
Set-AzDiagnosticSetting -ResourceId $vaultResourceId -Name "KeyVaultLogs" -WorkspaceId "<log-analytics-workspace-id>" -Log $logs

Governance della migrazione con Criteri di Azure

Utilizzando il servizio Criteri di Azure, è possibile gestire la migrazione RBAC di Azure attraverso i vostri insiemi di credenziali di Azure. È possibile creare una definizione di criteri personalizzata per controllare i key vault esistenti e imporre a tutti i nuovi key vault di utilizzare il controllo degli accessi in base al ruolo di Azure.

Creare e assegnare la definizione dei criteri per Key Vault Azure controllo degli accessi in base al ruolo

1. Passare alla risorsa Criteri
2. Selezionare Assegnazioni in Authoring sul lato sinistro della pagina Criteri di Azure
3. Selezionare Assegna criteri nella parte superiore della pagina
4. Immettere le seguenti informazioni:
   • Definire l'ambito dei criteri scegliendo la sottoscrizione e il gruppo di risorse
   • Selezionare la definizione del criterio: "[Anteprima]: Azure Key Vault deve utilizzare Azure RBAC"
   • Definire l'effetto desiderato del criterio (Audit, Nega o Disabilitato)
5. Completare l'incarico esaminandolo e creandolo

Una volta assegnato il criterio, il completamento dell'analisi può richiedere fino a 24 ore. Al termine dell'analisi, è possibile visualizzare i risultati di conformità nel dashboard Criteri di Azure.

Politica di accesso a Azure strumento di confronto RBAC

PowerShell tool per confrontare i criteri di accesso di Key Vault con i ruoli RBAC assegnati in Azure, per facilitare la migrazione dai criteri di accesso a RBAC di Azure. Lo strumento intende fornire una verifica dell'integrità durante la migrazione dei Key Vault esistenti verso Azure RBAC per garantire che i ruoli assegnati, insieme alle azioni sui dati sottostanti, coprano i criteri di accesso esistenti.

Risoluzione dei problemi comuni

• Ritardo dell'assegnazione di ruolo: la propagazione delle assegnazioni di ruolo può richiedere alcuni minuti. Implementare la logica di ripetizione dei tentativi nelle applicazioni.
• Assegnazioni di ruolo perse dopo il ripristino: le assegnazioni di ruolo non vengono mantenute quando un archivio viene recuperato dopo un'eliminazione temporanea. È necessario ricreare tutte le assegnazioni di ruolo dopo il ripristino.
• Errori di accesso negato: verificare che:
  • I ruoli corretti vengono assegnati nell'ambito corretto
  • L'entità servizio o l'identità gestita hanno esattamente le autorizzazioni necessarie
  • Le regole di accesso alla rete non bloccano la connessione
• Gli script hanno esito negativo dopo la migrazione: aggiornare tutti gli script che hanno usato i criteri di accesso per usare invece le assegnazioni di ruolo.

Altre informazioni

• Panoramica di Azure RBAC
• Esercitazione su ruoli personalizzati
• Privileged Identity Management