RBAC, Policy e Resource Locks: como a governança do Azure se encaixa

Estudando para o AZ-900, esses três ficavam se misturando para mim. Todos são sobre restringir coisas, todos são descritos como governança, e ler sobre eles separadamente fazia parecer três versões da mesma feature.

Não são. Cada um responde a uma pergunta diferente, e assim que tive as perguntas claras, a distinção parou de ser confusa.

RBAC responde "quem pode fazer isso?"

Role-Based Access Control é sobre identidade. Uma pessoa ou um serviço recebe uma role, essa role tem permissões, e ela se aplica num scope específico.

A parte do scope foi o que eu inicialmente perdi. Uma atribuição de role não é global, ela é anexada a um nível: um management group, uma subscription, um resource group, ou um resource único. Atribua a alguém Contributor num resource group e ele consegue fazer coisas de contributor com tudo dentro dele, mas nada fora.

Três roles built-in cobrem a maior parte do que você esperaria:

• Owner pode fazer tudo, incluindo conceder acesso para outras pessoas
• Contributor pode criar e gerenciar resources, mas não pode conceder acesso
• Reader pode olhar e não tocar

A distinção entre Contributor e Owner é a interessante. Conseguir gerenciar todo resource numa subscription e conseguir passar essa habilidade para outra pessoa são poderes genuinamente diferentes, e separá-los é o que faz least privilege de fato funcionar.

Azure Policy responde "isso tem permissão para existir?"

Policy não é sobre pessoas de jeito nenhum, o que foi o que finalmente separou isso do RBAC na minha cabeça. Ele avalia resources contra regras independentemente de quem os está criando.

Um Owner tem permissão total para criar resources. Uma policy que diz "virtual machines só podem ser criadas nessas regions" ainda vai impedir, porque a policy não está checando permissões, está checando o resource em si.

Exemplos típicos: restringir quais regions podem ser usadas, exigir tags específicas em resources, bloquear tamanhos caros de VM, impor que storage accounts exijam encryption.

Policy também pode só reportar em vez de bloquear. Uma policy em modo audit sinaliza resources que não estão em compliance sem impedi-los, o que é como você descobre o quão ruim um ambiente existente está antes de começar a impor qualquer coisa e quebrar tudo.

Resource locks respondem "isso deveria ser deletável?"

Locks são o mais simples dos três e o que eu teria descartado como sem importância. Eles existem para acidentes, não para atacantes.

Dois tipos:

• CanNotDelete permite mudanças mas bloqueia deleção
• ReadOnly bloqueia tanto mudanças quanto deleção

A coisa chave é que um lock se aplica a todo mundo, incluindo um Owner. Alguém com permissões totais que roda o comando de delete errado ainda é barrado. O que é exatamente o ponto, já que a pessoa mais capaz de deletar um database de produção por engano é alguém com permissão para deletá-lo.

Para de fato deletar um resource travado você tem que remover o lock primeiro, deliberadamente, como uma ação separada. Esse passo extra é a feature inteira.

Por que os três, e não só um

Juntos, eles cobrem falhas que os outros não conseguem.

RBAC impede alguém de fazer algo que não deveria conseguir fazer de jeito nenhum. Não consegue impedir uma pessoa autorizada de fazer algo autorizado mas errado.

Policy impede resources que não deveriam existir na forma em que estão, não importa quem os crie. Não consegue impedir alguém de deletar algo que já existe e está em compliance.

Locks impedem destruição acidental por pessoas que genuinamente têm permissão. Elas não restringem quem tem permissão em primeiro lugar.

É por isso que são três features em vez de uma. Não são camadas da mesma restrição, são respostas para três formas diferentes de as coisas darem errado.

Onde isso se conecta a escrever código

A ideia de least privilege é a mesma que eu já aplico numa aplicação, o que foi o que fez o RBAC parecer familiar em vez de novo. Uma conta de database com a qual minha API se conecta não deveria ter permissão para dropar tabelas, pelo mesmo motivo que um desenvolvedor não deveria ter Owner numa subscription de produção: não porque eu espere que abusem disso, mas porque a permissão só de existir é o que torna o acidente possível.

O Azure só torna isso explícito, com roles e scopes que você de fato consegue inspecionar, em vez de viver numa connection string que ninguém revisa.