Key Vault Administrator + Key Vault Secrets Officer

Detalhe da regra SoD — cinco plataformas, três provedores

CriticalAzure RBAC

Key Vault Administrator + Key Vault Secrets Officer

Administrar a configuração/políticas de acesso do Key Vault e, ao mesmo tempo, poder ler e modificar todos os secrets armazenados.

Azure RBACbuilt-in role
Key Vault Administrator
Azure RBACbuilt-in role
Key Vault Secrets Officer

Por que isso é um conflito

Key Vault Administrator já pode gerenciar as políticas de acesso do cofre (incluindo conceder a si mesmo qualquer role de dados via Azure RBAC), tornando Key Vault Secrets Officer redundante em termos de poder real e reforçando a concentração de controle sobre credenciais/segredos críticos (connection strings, API keys, certificados) em uma única identidade.

Risco

Acesso irrestrito a segredos de produção (strings de conexão de banco de dados, chaves de API de terceiros) sem qualquer segregação entre quem administra o cofre e quem deveria apenas consumir segredos específicos.

Como mitigar

  • Conceder Key Vault Secrets Officer apenas para aplicações/identidades gerenciadas específicas, nunca para administradores humanos com Key Vault Administrator.
  • Habilitar Private Link e logging detalhado de todo acesso a secrets via Azure Monitor.
  • Usar cofres separados por sensibilidade/ambiente (produção vs. desenvolvimento) com atribuições de role independentes.

Frameworks aplicáveis

SOXISO 27001PCI-DSSNIST CSF