Migração Azure Key Vault para RBAC: Guia Completo

Publicado em Fevereiro 2026 | Por Okeh | ... visualizações

Se você utiliza Azure Key Vault com Access Policies (modelo legado), recebeu uma notificação urgente da Microsoft. Este é um dos maiores mudanças de segurança no Key Vault em anos. O Azure RBAC oferece segurança superior, auditoria melhorada e integração mais robusta com os serviços do Azure. Vamos explorar tudo que você precisa saber para fazer essa transição com sucesso.

Entendendo a Mudança: Access Policies vs Azure RBAC

O Modelo Legado: Access Policies

Como funciona: Um modelo simples e direto onde você concede permissões específicas a um principal (usuário, aplicação, managed identity) diretamente no Key Vault.

Problemas:

• ❌ Granularidade limitada - permissões em bloco
• ❌ Difícil auditar quem tem acesso a quê
• ❌ Sem suporte a conditional access
• ❌ Não integra com Azure governance
• ❌ Atribuições gerenciadas manualmente

O Novo Modelo: Azure RBAC (Role-Based Access Control)

Como funciona: Controle de acesso baseado em funções, usando as mesmas roles do Azure (Contributor, Owner, etc) e roles customizadas.

Vantagens:

• ✅ Controle granular com mais de 150 roles
• ✅ Auditoria completa com Azure Monitor
• ✅ Suporte a Conditional Access
• ✅ Integração com Azure Governance e Policy
• ✅ Atribuições via ARM, Bicep, Terraform
• ✅ Compatível com PIM (Privileged Identity Management)

Aspecto	Access Policies	Azure RBAC
Granularidade	Limitada (14 permissões)	Muito fina (150+ roles)
Auditoria	Básica	Completa com Azure Monitor
Conditional Access	❌	✅
Suporte Microsoft	Legado (deprecated)	Padrão (futuro)
Integração IaC	Complexa	Nativa (Terraform, Bicep)

O Que Vai Parar de Funcionar?

🔴 Cenário 1: Criação de Novas Vaults

Após 27 fevereiro 2027:

Se você não configurar explicitamente enableRbacAuthorization: false, todas as novas vaults serão criadas com RBAC obrigatoriamente. Se seu código espera Access Policies, você receberá HTTP 403 Forbidden.

// ❌ Após 27 fev 2027 - Falhará porque tentará usar Access Policies
az keyvault create --name meuVault --resource-group meuRG

// ✅ Solução 1: Criar com RBAC (recomendado)
az keyvault create --name meuVault --resource-group meuRG \
  --enable-rbac-authorization true

// ✅ Solução 2: Forçar Access Policies (legado - não recomendado)
az keyvault create --name meuVault --resource-group meuRG \
  --enable-rbac-authorization false

🔴 Cenário 2: Integrações com Serviços Azure

Serviços afetados:

• Azure App Gateway / Load Balancer: Certificados com Access Policies falharão
• Azure Web Application Firewall (WAF): Certificados gerenciados pelo WAF
• Azure WebApp: Certificados SSL/TLS do Key Vault
• Azure Functions: Acesso a secrets via MSI (Managed Identity)
• Application Gateway SSL Offloading: Renovação automática de certificados

Se essas integrações estiverem usando Access Policies, receberão HTTP 403 errors após a aposentadoria da API legada.

🔴 Cenário 3: Certificados com Renovação Automática

Problema específico: Se você tem certificados contratados diretamente (não gerados pelo Key Vault) com renovação automática, a autoridade certificadora precisará de permissões para:

• Ler a configuração do certificado
• Renover o certificado
• Atualizar a versão no Key Vault

Com RBAC, essa integração usa Managed Identity com role "Key Vault Certificate Officer" em vez de Access Policies.

Mudanças por Serviço: Como Integrar com RBAC

1️⃣ Azure App Gateway + Load Balancer + WAF

Situação atual (Access Policies):

# App Gateway com acesso ao certificado via Access Policy
$vault = Get-AzKeyVault -VaultName "meuVault"
Set-AzKeyVaultAccessPolicy -VaultName "meuVault" \
  -ServicePrincipalName "00000000-0000-0000-0000-000000000000" \
  -PermissionsToSecrets get,list \
  -PermissionsToCertificates get,list

Com Azure RBAC (novo):

# 1. Obter a Managed Identity do App Gateway
$appGateway = Get-AzApplicationGateway -Name "meuAppGateway" -ResourceGroupName "meuRG"
$identity = $appGateway.Identity.PrincipalId

# 2. Atribuir role no Key Vault
New-AzRoleAssignment -ObjectId $identity \
  -RoleDefinitionName "Key Vault Secrets User" \
  -Scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

# 3. Para certificados
New-AzRoleAssignment -ObjectId $identity \
# 3. Para certificados
New-AzRoleAssignment -ObjectId $identity \
  -RoleDefinitionName "Key Vault Certificate User" \
  -Scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

Roles RBAC necessárias para App Gateway:

• Key Vault Secrets User - Ler secrets
• Key Vault Certificate User - Ler certificados
• Key Vault Certificates Officer - Gerenciar ciclo de vida (renovação automática)

2️⃣ Azure WebApp (App Service)

Mudança de integração: WebApps acessam certificados e secrets via Managed Identity.

# 1. Habilitar Managed Identity na WebApp
$webApp = Get-AzWebApp -Name "minhaApp" -ResourceGroupName "meuRG"
$identity = $webApp.Identity.PrincipalId

# 2. Atribuir role RBAC
New-AzRoleAssignment -ObjectId $identity \
  -RoleDefinitionName "Key Vault Secrets User" \
  -Scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

# 3. No código da aplicação, usar DefaultAzureCredential
# Isso carrega automaticamente as credenciais via MSI
var client = new SecretClient(vaultUri, new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync("meuSecret");

3️⃣ Azure Functions

Impacto: Functions que usam Key Vault bindings precisarão de RBAC configurado.

# 1. Habilitar Managed Identity na Function App
$functionApp = Get-AzFunctionApp -Name "minhaFunction" -ResourceGroupName "meuRG"
$identity = $functionApp.Identity.PrincipalId

# 2. Atribuir role RBAC
New-AzRoleAssignment -ObjectId $identity \
  -RoleDefinitionName "Key Vault Secrets User" \
  -Scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

# 3. No settings.json, referenciar o secret
{
  "KeyVaultName": "meuVault",
  "ConnectionString": "@Microsoft.KeyVault(SecretUri=https://meuVault.vault.azure.net/secrets/minhaConexao)"
}

4️⃣ Certificados com Renovação Automática

Problema específico: Autoridadores certificadoras (Let's Encrypt, GlobalSign, etc) precisam renovar certificados automaticamente.

# 1. Criar uma Managed Identity para o processo de renovação
$identityRenewal = New-AzUserAssignedIdentity -Name "CertificateRenewal" -ResourceGroupName "meuRG"

# 2. Atribuir role para renovar certificados
New-AzRoleAssignment -ObjectId $identityRenewal.PrincipalId \
  -RoleDefinitionName "Key Vault Certificates Officer" \
  -Scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

# 3. Usar essa identidade na autoridade certificadora
# Configurar na integração da CA (Let's Encrypt, DigiCert, etc) para usar essa identidade
# A renovação acontecerá automaticamente com essas permissões

5️⃣ Storage Account: Criptografia com Customer-Managed Keys

O que é: Você pode usar chaves armazenadas no Key Vault para criptografar dados em Storage Accounts (blobs, files, queues, tables).

Situação atual (Access Policies):

# 1. Storage Account com Access Policy
$storageAccount = Get-AzStorageAccount -Name "meuStorage" -ResourceGroupName "meuRG"
$storage = $storageAccount.Identity.PrincipalId

# 2. Atribuir permissão (Access Policy - legado)
Set-AzKeyVaultAccessPolicy -VaultName "meuVault" \
  -ObjectId $storage \
  -PermissionsToKeys get,wrapkey,unwrapkey

Com Azure RBAC (novo):

# 1. Storage Account já tem Managed Identity habilitada
$storageAccount = Get-AzStorageAccount -Name "meuStorage" -ResourceGroupName "meuRG"
$storage = $storageAccount.Identity.PrincipalId

# 2. Atribuir role RBAC no Key Vault
New-AzRoleAssignment -ObjectId $storage \
  -RoleDefinitionName "Key Vault Crypto Service Encryption User" \
  -Scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

# 3. Configurar Storage Account para usar a chave
$key = Get-AzKeyVaultKey -VaultName "meuVault" -Name "minhaChave"
Set-AzStorageAccount -ResourceGroupName "meuRG" \
  -Name "meuStorage" \
  -KeyvaultEncryption \
  -KeyName "minhaChave" \
  -KeyVersion $key.Version \
  -KeyVaultUri "https://meuVault.vault.azure.net"

⚠️ O que muda:

• Antes: Storage Account usa Access Policies para acessar chave
• Depois: Storage Account usa Managed Identity + RBAC com role "Key Vault Crypto Service Encryption User"

6️⃣ Disk Encryption: Chaves de Disco Gerenciadas pelo Key Vault

O que é: Azure Disk Encryption (ADE) permite criptografar discos de VMs usando chaves no Key Vault. Requer RBAC para continuar funcionando.

Situação atual (Access Policies):

# 1. VM com Managed Identity
$vm = Get-AzVM -Name "minhaVM" -ResourceGroupName "meuRG"
$vmIdentity = $vm.Identity.PrincipalId

# 2. Access Policy para criptografia de disco (legado)
Set-AzKeyVaultAccessPolicy -VaultName "meuVault" \
  -ObjectId $vmIdentity \
  -PermissionsToKeys create,get,wrapkey,unwrapkey,decrypt,encrypt

Com Azure RBAC (novo):

# 1. VM com Managed Identity (system-assigned ou user-assigned)
$vm = Get-AzVM -Name "minhaVM" -ResourceGroupName "meuRG"
$vmIdentity = $vm.Identity.PrincipalId

# 2. Atribuir role RBAC para criptografia de disco
New-AzRoleAssignment -ObjectId $vmIdentity \
  -RoleDefinitionName "Key Vault Crypto Officer" \
  -Scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

# Ou para apenas ler (decrypt):
New-AzRoleAssignment -ObjectId $vmIdentity \
  -RoleDefinitionName "Key Vault Crypto User" \
  -Scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

Cenários de disco criptografado:

• OS Disk Encryption: Disco do sistema operacional criptografado
• Data Disk Encryption: Discos de dados adicionais
• Temporary Disk Encryption: Disco temporário (D: em Windows)
• Host-based Encryption: Criptografia no host da infraestrutura

⚠️ Impacto da migração: Se seu disco está criptografado com uma chave do Key Vault e você não migrar para RBAC, a VM não conseguirá descriptografar o disco após a aposentadoria da API legada.

Resumo: Tudo que usa Key Vault com Access Policies

Serviço/Recurso	Tipo de Acesso	RBAC Role Necessária	Se Não Migrar
Storage Account	Criptografia de dados em repouso	Crypto Service Encryption User	❌ Dados inacessíveis
VM Disk Encryption	Criptografia de discos (OS + Data)	Crypto Officer / User	❌ VM não inicia
App Gateway	Certificados SSL/TLS	Certificate User	❌ Sem HTTPS
WebApp	Secrets e certificados	Secrets User	❌ Erro HTTP 403
Azure Functions	Secrets	Secrets User	❌ Execução falha
Database TDE	Transparent Data Encryption	Crypto User	❌ DB inacessível

Passo a Passo: Migração Completa

Passo 1: Inventário - O Que Você Tem?

Primeiro, identifique todos os Key Vaults e integrações:

# Listar todos os Key Vaults
az keyvault list --query "[].{name:name, resourceGroup:resourceGroup, enableRbac:properties.enableRbacAuthorization}"

# Ver quem tem permissão em cada vault (Access Policies)
az keyvault list-deleted --query "[].{vaultName:name, accessPolicies:properties.accessPolicies}" --output table

Passo 2: Planejar a Migração

Passo 3: Habilitar RBAC no Key Vault

# Via PowerShell
Update-AzKeyVault -VaultName "meuVault" -ResourceGroupName "meuRG" \
  -EnableRbacAuthorization $true

# Via CLI
az keyvault update --name meuVault --resource-group meuRG \
  --enable-rbac-authorization true

# Via Terraform
resource "azurerm_key_vault" "example" {
  # ...
  enable_rbac_authorization = true
}

⚠️ Importante: Após habilitar RBAC, Access Policies deixam de ser usados. Se você tiver acesso via Access Policies, perderá acesso até atribuir RBAC.

Passo 4: Converter Access Policies para RBAC

# Exemplo: Access Policy antigo (legado)
Set-AzKeyVaultAccessPolicy -VaultName "meuVault" \
  -UserPrincipalName "usuario@empresa.com" \
  -PermissionsToSecrets get,list,set,delete

# Conversão para RBAC (novo)
$user = Get-AzADUser -UserPrincipalName "usuario@empresa.com"
New-AzRoleAssignment -ObjectId $user.Id \
  -RoleDefinitionName "Key Vault Administrator" \
  -Scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

Passo 5: Atualizar Integrações

Para cada serviço (App Gateway, WebApp, Functions), configure RBAC como mostrado nas seções anteriores.

Passo 6: Testar e Validar

# Testar acesso a um secret
az keyvault secret show --vault-name meuVault --name meuSecret

# Verificar permissões atribuídas
az role assignment list --scope "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.keyvault/vaults/{vaultName}"

# Monitorar logs de acesso
az monitor activity-log list --resource-group meuRG --query "[?resourceType=='Microsoft.KeyVault/vaults']"

Cuidados Importantes Durante a Migração

Roles RBAC Comuns para Key Vault

Role	Permissões	Caso de Uso
Key Vault Administrator	Acesso completo	DevOps, SRE
Key Vault Secrets User	Ler secrets apenas	WebApp, Functions, App Service
Key Vault Certificate User	Ler certificados	App Gateway, Load Balancer
Key Vault Certificates Officer	Gerenciar certificados	Renovação automática, CA integrations
Key Vault Crypto User	Usar chaves de criptografia	Aplicações com TDE, DataBox

O Que Acontece Se Não Migrar?

Checklist: Antes da Migração

Timeline Importante

Data	Evento	Ação Recomendada
Fevereiro 2026	Lançamento API 2026-02-01	COMECE AQUI - Comece testes em dev
Até Junho 2026	Período de transição	Complete migração em teste/homolog
Até Janeiro 2027	Final do suporte	URGENTE - Migre produção
27 Fevereiro 2027	DEADLINE - APIs antigas desligam	CRÍTICO - Sistema parará se não migrado

Referências e Recursos

• Azure Key Vault RBAC Guide - Documentação Oficial
• Key Vault Certificate Authority Integration
• Azure RBAC - Role Assignments
• Key Vault - Soft Delete e Purge Protection