Usuários, Grupos e Atribuições de Funções

O Azure Role-Based Access Control (RBAC) é o sistema de autorização que controla quem pode fazer o quê nos recursos do Azure. Em vez de atribuir permissões diretamente a indivíduos, você atribui funções a entidades de segurança (usuários, grupos, entidades de serviço ou identidades gerenciadas) em um escopo específico. Essa separação mantém as permissões gerenciáveis à medida que sua organização cresce.

Cada atribuição do RBAC envolve três componentes. Uma entidade de segurança é quem recebe o acesso (usuário, grupo ou identidade gerenciada). Uma definição de função especifica quais ações são permitidas (por exemplo, ler VMs e gravar no armazenamento). Um escopo define onde o acesso se aplica — do mais amplo ao mais restrito: grupo de gerenciamento, assinatura, grupo de recursos ou recurso individual. O acesso é herdado para baixo na hierarquia de escopos.

O Azure fornece centenas de funções internas. As quatro mais usadas em todos os tipos de recurso são: Owner — acesso total, incluindo a capacidade de atribuir funções a outras pessoas; Contributor — acesso total para criar e gerenciar recursos, mas sem poder conceder acesso a outras pessoas; Reader — acesso somente para exibição; e administrador de acesso de usuário — pode gerenciar atribuições de funções sem contribuir diretamente para os recursos.

Uma atribuição de função concede à entidade de segurança especificada as permissões definidas na definição de função, no escopo especificado. As atribuições de função se propagam para todos os escopos filho — atribuir Contributor no nível do grupo de recursos concede acesso de Contributor a todos os recursos desse grupo. Atribuir no nível da assinatura concede Contributor em todos os grupos de recursos dessa assinatura.

O princípio do menor privilégio estabelece que cada identidade deve ter somente as permissões mínimas necessárias para executar seu trabalho. No Azure RBAC, isso significa: prefira Reader a Contributor quando não for necessário escrever, prefira o escopo do grupo de recursos ao escopo da assinatura e use funções específicas no nível do recurso (por exemplo, Storage Blob Data Contributor) em vez da função ampla Contributor sempre que possível.

Quando nenhuma função interna atende exatamente aos seus requisitos, você pode criar uma função personalizada. Uma definição de função personalizada especifica um conjunto de Actions (operações do plano de controle permitidas), NotActions (excluídas do conjunto permitido), DataActions (operações do plano de dados em recursos, como a leitura do conteúdo de blobs) e AssignableScopes (assinaturas ou grupos de gerenciamento nos quais a função pode ser atribuída).

Atribuir funções a grupos, em vez de a usuários individuais, é uma prática recomendada. Quando um novo desenvolvedor entra na DevTeam, você o adiciona ao grupo de segurança DevTeam no Entra ID — ele herda automaticamente todas as atribuições de função que o grupo possui, sem nenhuma alteração no Azure RBAC. Esse ponto único de gerenciamento evita atribuições individuais dispersas, que se tornam difíceis de auditar ou revogar quando alguém deixa a organização.

Uma entidade de serviço é uma identidade usada por aplicativos, scripts e ferramentas de automação para se autenticar no Azure e acessar recursos. Diferentemente de uma identidade de usuário, as entidades de serviço não têm capacidade de entrada interativa. Você as cria a partir de registros de aplicativos no Entra ID e, em seguida, atribui funções do RBAC no escopo apropriado — por exemplo, concedendo a uma pipeline de CI/CD acesso de Contributor a um único grupo de recursos para implantar a infraestrutura.

As atribuições de negação bloqueiam ações específicas para entidades de segurança, mesmo que uma atribuição de função permitisse essas ações. Diferentemente das atribuições de função, as atribuições de negação não podem ser criadas diretamente por administradores — elas são anexadas pelo Azure Blueprints ou por aplicativos gerenciados para impedir que usuários modifiquem recursos protegidos. Uma atribuição de negação tem precedência sobre qualquer atribuição de função correspondente.

O Privileged Identity Management (PIM) é um recurso do Entra ID P2 que fornece acesso privilegiado just-in-time. Em vez de atribuir permanentemente a função Owner ou Global Administrator, você torna os usuários elegíveis para essa função. Quando precisam dela, eles ativam a atribuição por um período limitado (por exemplo, de 1 a 8 horas), opcionalmente com exigência de um fluxo de aprovação e de uma justificativa. Isso reduz significativamente a superfície de ataque permanente causada por contas com privilégios excessivos.

As revisões de acesso (Entra ID P2) são revisões automatizadas periódicas que solicitam aos proprietários de recursos ou gerentes que confirmem se os membros de suas equipes ainda precisam das atribuições de função atuais. Os revisores aprovam ou negam a continuidade do acesso diretamente na interface de revisão. Isso identifica permissões obsoletas resultantes de mudanças de função, conclusão de projetos ou saída de funcionários — um requisito importante para programas de conformidade regulatória.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) apresentados nesta lição.

Nesta lição, você aprendeu que: o Azure RBAC atribui funções a entidades de segurança em um escopo específico, o princípio do menor privilégio significa conceder somente as permissões mínimas necessárias e o PIM fornece ativação just-in-time para funções com privilégios elevados, em vez de uma atribuição permanente. A seguir, abordaremos a Autenticação Multifator e o Acesso Condicional no Entra ID.