Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O Azure Key Vault oferece dois modelos de controlo de acesso: controlo de acesso baseado em papéis do Azure (Azure RBAC) e um modelo de política de acesso. O Azure RBAC é o modelo padrão e recomendado de controlo de acesso para o Azure Key Vault. A partir da versão API 2026-02-01, o Azure RBAC é o modelo padrão de controlo de acesso para novos vaults. Para uma comparação dos dois métodos de autorização, veja Azure controlo de acesso baseado em funções (Azure RBAC) vs. políticas de acesso.
Para informações sobre como preparar as suas implementações existentes para esta alteração, consulte Prepare for Key Vault API versão 2026-02-01 e posteriores.
Este artigo fornece a informação necessária para migrar um cofre de chaves de um modelo de política de acesso para um modelo Azure RBAC.
Políticas de acesso para mapeamento de funções do Azure
O Azure RBAC tem vários papéis incorporados no Azure que pode atribuir a utilizadores, grupos, principais de serviço e identidades geridas. Se os papéis incorporados não responderem às necessidades específicas da sua organização, pode criar os seus próprios Azure funções personalizadas.
Key Vault funções incorporadas para gestão de acesso a chaves, certificados e segredos:
- Administrador do Key Vault
- Leitor do Key Vault
- Operador de Purga do Key Vault
- Oficial de Certificados Key Vault
- Utilizador do Certificado Key Vault
- Oficial de Cripto da Key Vault
- Utilizador de Criptografia do Cofre de Chaves
- Utilizador de Encriptação do Serviço de Criptografia Key Vault
- Utilizador do Lançamento do Serviço de Criptografia Key Vault
- Agente de Segredos do Key Vault
- Utilizador do Key Vault Secrets
Para mais informações sobre funções incorporadas existentes, consulte Azure funções incorporadas
As políticas de acesso ao Vault podem ser atribuídas com permissões selecionadas individualmente ou com modelos de permissão predefinidos.
Modelos de permissão predefinidos da política de acesso:
- Chave, Segredo, Gestão de Certificados
- Gestão de Chaves e Segredos
- Gestão de Segredos e Certificados
- Gestão de Chaves
- Gestão Secreta
- Certificate Management (Gestão de Certificados)
- SQL Server Connector
- Azure Data Lake Storage ou Armazenamento do Azure
- Azure Backup
- Chave de Cliente Exchange Online
- Chave do Cliente do SharePoint Online
- Azure Information BYOK
Modelos de políticas de acesso ao mapeamento de papéis do Azure
| Modelo de política de acesso | Operações | Azure role |
|---|---|---|
| Chave, Segredo, Gestão de Certificados | Chaves: todas as operações Certificados: todas as operações Segredos: todas as operações |
Administrador do Key Vault |
| Gestão de Chaves e Segredos | Chaves: todas as operações Segredos: todas as operações |
Oficial de Cripto da Key Vault Agente de Segredos do Key Vault |
| Gestão de Segredos e Certificados | Certificados: todas as operações Segredos: todas as operações |
Oficial de Certificados Key Vault Agente de Segredos do Key Vault |
| Gestão de Chaves | Chaves: todas as operações | Oficial de Cripto da Key Vault |
| Gestão Secreta | Segredos: todas as operações | Agente de Segredos do Key Vault |
| Certificate Management (Gestão de Certificados) | Certificados: todas as operações | Oficial de Certificados Key Vault |
| SQL Server Connector | Chaves: obter, listar, embrulhar chave, desembrulhar chave | Utilizador de Encriptação do Serviço de Criptografia Key Vault |
| Azure Data Lake Storage ou Armazenamento do Azure | Chaves: obter, listar, desencriptar chave | N/A Função personalizada necessária |
| Azure Backup | Chaves: get, list, backup Segredos: obter, listar, fazer backup |
N/A Função personalizada necessária |
| Chave de Cliente Exchange Online | Chaves: obter, listar, embrulhar chave, desembrulhar chave | Utilizador de Encriptação do Serviço de Criptografia Key Vault |
| Chave de Cliente Exchange Online | Chaves: obter, listar, embrulhar chave, desembrulhar chave | Utilizador de Encriptação do Serviço de Criptografia Key Vault |
| Azure Information BYOK | Chaves: obter, desencriptar, assinar | N/A Função personalizada necessária |
Mapeamento de escopos de atribuição
O Azure RBAC para Key Vault permite atribuição de papéis nos seguintes âmbitos:
- Grupo de Gestão
- Subscrição
- Grupo de recursos
- O recurso Key Vault
- Chave, segredo e certificado individuais
As políticas de acesso limitam-se à atribuição de políticas apenas ao nível dos recursos do Key Vault.
Em geral, é uma prática recomendada ter um cofre de chaves por aplicativo e gerenciar o acesso no nível do cofre de chaves. Há cenários em que o gerenciamento de acesso em outros escopos pode simplificar o gerenciamento de acesso.
Infraestrutura, administradores e operadores de segurança: gerenciar grupos de cofres de chaves no nível de grupo de gerenciamento, assinatura ou grupo de recursos com políticas de acesso ao cofre requer a manutenção de políticas para cada cofre de chaves. O Azure RBAC permite criar uma única atribuição de função em grupo de gestão, subscrição ou grupo de recursos. Essa atribuição será aplicada a quaisquer novos cofres de chaves criados sob o mesmo escopo. Neste cenário, recomenda-se usar o Privileged Identity Management com acesso just-in time em vez de fornecer acesso permanente.
Aplicativos: há cenários em que o aplicativo precisaria compartilhar segredo com outro aplicativo. Ao usar políticas de acesso ao cofre, um cofre separado para as chaves precisou ser criado para evitar conceder acesso a todos os segredos. O Azure RBAC permite atribuir uma função com um determinado escopo para um segredo específico em vez de usar um cofre de chaves único.
Como migrar
Siga estes passos para migrar o seu cofre de chaves para o Azure RBAC a partir das políticas de acesso:
- Preparar: certifique-se de ter as permissões adequadas e um inventário dos seus aplicativos.
- Inventário: documente todas as políticas e permissões de acesso existentes.
- Criar funções RBAC do Azure: Atribuir funções RBAC do Azure apropriadas a cada principal de segurança.
- Ativar Azure RBAC: Mude o cofre de chaves para usar o modelo de controlo de acesso Azure RBAC.
- Validar: teste o acesso para garantir que todos os aplicativos e usuários mantenham o acesso apropriado.
- Monitor: configure o monitoramento e o alerta para problemas de acesso.
Pré-requisitos
Antes de iniciar a migração, certifique-se de:
Permissões necessárias: Você deve ter as seguintes permissões no cofre de chaves:
- Permissão
Microsoft.Authorization/roleAssignments/write, incluída nos papéis de Proprietário e Administrador de Acesso ao Utilizador -
Microsoft.KeyVault/vaults/writepermissão, incluída na função de Contribuinte do Key Vault
Nota
As funções clássicas de administrador de subscrição (Administrador de Serviços e Co-Administrator) não são suportadas.
- Permissão
Inventário de aplicativos e identidades: liste todos os aplicativos, serviços e usuários que acessam o cofre de chaves e documente todas as políticas de acesso atuais e as permissões que elas concedem.
Inventariar políticas de acesso atuais
Documente todas as políticas de acesso existentes, observando as entidades de segurança (usuários, grupos, entidades de serviço) e suas permissões.
Use o comando CLI do Azure az keyvault show para obter as políticas de acesso:
# List all current access policies
az keyvault show --name <vault-name> --resource-group <resource-group> --query properties.accessPolicies
Criar atribuições equivalentes de funções Azure RBAC
Para cada principal de segurança com uma política de acesso, crie uma ou mais atribuições de funções RBAC no Azure com base na tabela de mapeamento acima.
Use o comando az role assignment create para conceder funções apropriadas:
# 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>"
Ativar o Azure RBAC
Depois de criar todas as atribuições de funções necessárias, mude o vault para usar o modelo de permissões Azure RBAC.
Use o comando az keyvault update para ativar Azure RBAC:
# Switch the vault to Azure RBAC
az keyvault update --name <vault-name> --resource-group <resource-group> --enable-rbac-authorization true
Validar acesso
Teste o acesso ao cofre para garantir que todas as aplicações e utilizadores ainda possam realizar as operações necessárias.
Teste o seu acesso com estes comandos:
# 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>
Configurar monitoramento e alertas
Após a migração, configure o monitoramento adequado para detetar quaisquer problemas de acesso:
Utilize o comando az monitor diagnostic-settings create.
# 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>
Governação de migração com o Azure Policy
Usando o serviço Azure Policy, pode gerir a migração do Azure RBAC nos seus cofres. Pode criar uma definição de política personalizada para auditar os cofres de chaves existentes e obrigar todos os novos cofres a usar o Azure RBAC.
Criar e atribuir definição de política para Key Vault Azure RBAC
- Navegue até Recurso de política
- Selecione Assignments em Authoring no lado esquerdo da página Azure Policy
- Selecione Atribuir política na parte superior da página
- Insira as seguintes informações:
- Defina o escopo da política escolhendo a assinatura e o grupo de recursos
- Selecione a definição da política: "[Pré-visualização]: Azure Key Vault deve usar Azure RBAC"
- Defina o efeito desejado da política (Auditar, Rejeitar ou Desativado)
- Conclua a tarefa revisando-a e criando-a
Depois de a política ser atribuída, pode demorar até 24 horas para efetuar a verificação. Depois de concluída a análise, pode ver os resultados de conformidade no painel do Azure Policy.
Política de Acesso à Ferramenta de Comparação Azure RBAC
Importante
Esta ferramenta é construída e mantida por membros da Comunidade Microsoft e sem suporte formal dos Serviços de Apoio ao Cliente. A ferramenta é fornecida no estado em que se encontra sem qualquer tipo de garantia.
Ferramenta PowerShell para comparar políticas de acesso do Key Vault com funções atribuídas do Azure RBAC, ajudando na migração de Políticas de Acesso para funções RBAC do Azure. A intenção da ferramenta é fornecer uma verificação de sanidade ao migrar o Key Vault existente para o Azure RBAC, para garantir que os papéis atribuídos com ações de dados subjacentes abrangem as Políticas de Acesso existentes.
Solução de problemas comuns
- Atraso na atribuição de função: as atribuições de função podem levar vários minutos para se propagar. Implemente a lógica de repetição em seus aplicativos.
- Atribuições de função perdidas após a recuperação: As atribuições de função não são preservadas quando um cofre é recuperado após a eliminação suave. Você deve recriar todas as atribuições de função após a recuperação.
-
Erros de acesso negado: Verifique se:
- As funções corretas são atribuídas no escopo certo
- A entidade de serviço ou identidade gerenciada tem as permissões exatas necessárias
- As regras de acesso à rede não estão a bloquear a sua ligação
- Os scripts falham após a migração: atualize quaisquer scripts que tenham utilizado políticas de acesso para usar atribuições de função.