Conceito e mecanismo
Key Vault tem plano de gestão e plano de dados. Num cofre RBAC, Key Vault Reader lê metadados, enquanto Secrets User permite ler valores de segredos. Contributor gere o recurso e não deve ser tratado como concessão direta de dados nesse modelo. Migrar de access policies para RBAC invalida as permissões anteriores; inventaria consumidores e prepara roles equivalentes mínimas antes do corte. A documentação atual usa RBAC por defeito na API2026-02-01, mas isso não prova a configuração de cofres existentes nem deve ser projetado retroativamente sobre todo o programa histórico. Verifica sempre o modelo efetivo do recurso.
Aplicação guiada
Soft delete permite recuperar objetos eliminados; purge protection impede remoção definitiva durante retenção, mas não mantém um segredo eliminado disponível para a aplicação. Em Azure Policy, remediação de recursos existentes com modify ou deployIfNotExists exige a tarefa apropriada e uma managed identity autorizada. Uma assignment criada por SDK não garante automaticamente todas as roles de execução. Ao reportar Defender for Cloud, distingue avaliações automáticas, evidência manual, âmbito e controlo ainda por demonstrar. Um relatório pode apoiar auditores sem certificar por si a organização. Por exemplo,18 avaliações aprovadas em24 aplicáveis representam75% dessa população, não probabilidade de ausência de incidente nem a fórmula de secure score.
O administrador abre o cofre, mas a aplicação recebe403 após migração RBAC. Testa a data action e a identidade do consumidor, não apenas a gestão no portal.
Armadilhas comuns
Cofre visível como segredo legível; purge protection como disponibilidade; painel verde como certificação externa.
Tópicos relacionados: Identidade e privilégio temporário · Fronteiras de rede e acesso privado · Computação e acesso operacional
Preserva a ligação entre evidência, âmbito e decisão de aceitação.
Referência: Key Vault control and data planes and RBAC migration · AZ-500 objectives2026-01-22; retired2026-08-31