Fundamentação Teórica: Manage built-in Azure roles

1. Intuição Inicial

Imagine um prédio corporativo com diferentes áreas: a sala de servidores, o arquivo financeiro, o escritório de RH e a recepção. Cada funcionário tem um crachá que libera apenas as portas que ele precisa acessar para fazer seu trabalho. O segurança tem acesso a todas as portas. O contador tem acesso ao arquivo financeiro mas não à sala de servidores. O estagiário tem acesso só à recepção.

No Azure, esse sistema de crachás é o RBAC (Role-Based Access Control), e os "modelos de crachá" são os papéis (roles). Em vez de definir manualmente o que cada pessoa pode fazer, você atribui um papel que já define um conjunto de permissões. Os papéis integrados (built-in roles) são os modelos pré-definidos pela Microsoft que cobrem os casos de uso mais comuns.

O Azure tem mais de 300 papéis integrados, mas na prática, um conjunto pequeno cobre a grande maioria das situações. Entender como esses papéis funcionam, como se hierarquizam e como são atribuídos é fundamental para controlar quem pode fazer o quê nos seus recursos.

2. Contexto

O RBAC do Azure é o sistema de controle de acesso para recursos Azure (VMs, storage accounts, redes, databases, etc.). Ele é diferente dos papéis do Entra ID que vimos anteriormente: os papéis do Entra ID controlam quem pode administrar o diretório de identidades; o RBAC do Azure controla quem pode agir sobre os recursos da infraestrutura.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Os dois sistemas coexistem e são complementares, mas são independentes. Ser Global Administrator no Entra ID não concede automaticamente acesso a VMs ou Storage Accounts. E ser Owner de uma assinatura Azure não torna o usuário Global Administrator do Entra ID.

Exceção importante: um Global Administrator pode "elevar" seu próprio acesso para User Access Administrator no escopo raiz do Azure (Root Management Group), o que lhe dá a capacidade de gerenciar atribuições RBAC em toda a hierarquia. Essa elevação deve ser temporária e auditada.

3. Construção dos Conceitos

3.1 Os Três Elementos de uma Atribuição de Papel

Uma atribuição de papel no Azure é sempre a combinação de três elementos:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Security Principal (quem): pode ser um usuário, um grupo, uma service principal (identidade de aplicação) ou uma managed identity (identidade gerenciada de recurso Azure).

Role Definition (o quê): a definição do papel, que especifica quais ações são permitidas e quais são negadas. É um JSON com listas de Actions, NotActions, DataActions e NotDataActions.

Scope (onde): o recurso ou contêiner de recursos ao qual a permissão se aplica.

3.2 A Hierarquia de Escopos

O Azure organiza recursos em uma hierarquia de quatro níveis. Permissões atribuídas em um nível superior são herdadas pelos níveis inferiores:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Exemplo de herança: se você atribui o papel Reader a um usuário no escopo da assinatura, ele pode ler todos os recursos em todos os grupos de recursos daquela assinatura. Se você atribui Contributor a um grupo no escopo de um Resource Group específico, todos os membros desse grupo podem criar e gerenciar recursos naquele Resource Group, mas não em outros.

Essa herança é sempre para baixo na hierarquia, nunca para cima.

3.3 A Estrutura de uma Role Definition

Para entender os papéis integrados, é preciso entender o que compõe uma definição de papel:

Campo	Descrição	Exemplo
Actions	Operações de gerenciamento permitidas	`Microsoft.Compute/virtualMachines/start/action`
NotActions	Exceções dentro das Actions	`Microsoft.Authorization/*/Delete`
DataActions	Operações de dados permitidas	`Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
NotDataActions	Exceções dentro das DataActions	nenhuma nos papéis comuns
AssignableScopes	Escopos onde o papel pode ser atribuído	`/subscriptions/{id}`, `/` (global)

A diferença entre Actions e DataActions é fundamental:

Actions controlam operações de gerenciamento: criar uma VM, modificar configurações de rede, criar um storage account. São o "plano de controle" (control plane).
DataActions controlam operações nos dados dentro dos recursos: ler blobs de um storage, escrever mensagens em uma fila, acessar segredos do Key Vault. São o "plano de dados" (data plane).

Um usuário pode ter permissão para gerenciar um storage account (Actions) mas não para ler os dados armazenados nele (DataActions), e vice-versa. Essa separação é uma camada adicional de segurança.

A permissão efetiva é: (Actions - NotActions). O NotActions não é uma negação explícita; é uma subtração das Actions. Se o papel A tem * em Actions e Microsoft.Authorization/*/Delete em NotActions, significa que pode fazer tudo exceto deletar atribuições de papéis.

3.4 Os Quatro Papéis Fundamentais

O Azure tem mais de 300 papéis integrados, mas quatro são a base de toda a estrutura e são os mais cobrados no AZ-104:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Papel	Actions	NotActions	Pode gerenciar acesso?	Cria recursos?	Lê recursos?
Owner	`*` (tudo)	Nenhuma	Sim	Sim	Sim
Contributor	`*` (tudo)	`Microsoft.Authorization//Write`, `Microsoft.Authorization//Delete`	Não	Sim	Sim
Reader	`*/read`	Nenhuma	Não	Não	Sim
User Access Administrator	`Microsoft.Authorization/*`	Nenhuma	Sim	Não	Mínimo

A distinção crítica entre Owner e Contributor: ambos podem criar e gerenciar qualquer tipo de recurso Azure. A única diferença é que o Contributor não pode gerenciar atribuições de papel RBAC (não pode dar ou revogar acesso a outros usuários). O Owner pode.

Isso é essencial para o princípio do menor privilégio: se alguém precisa criar e gerenciar recursos mas não precisa administrar quem tem acesso, Contributor é o papel correto. Dar Owner seria excessivo.

O papel User Access Administrator é específico: ele só pode gerenciar atribuições de papel, mas não pode criar nem configurar recursos. É útil quando você quer delegar a gestão de acesso sem dar permissão para modificar recursos.

3.5 Papéis Específicos por Serviço

Além dos quatro papéis fundamentais, o Azure tem papéis integrados específicos para cada serviço. Alguns exemplos importantes:

Papel	Serviço	O que permite
Virtual Machine Contributor	Compute	Gerenciar VMs, mas não a rede nem o storage associado
Virtual Machine Administrator Login	Compute	Fazer login como administrador em VMs via Azure AD
Network Contributor	Networking	Gerenciar redes, mas não VMs nem acesso
Storage Account Contributor	Storage	Gerenciar storage accounts (não os dados)
Storage Blob Data Reader	Storage	Ler dados de blobs (DataActions, não Actions)
Storage Blob Data Contributor	Storage	Ler e escrever dados de blobs
Key Vault Administrator	Key Vault	Gerenciar o cofre e seus segredos/chaves/certificados
Key Vault Secrets User	Key Vault	Apenas ler segredos (DataActions)
SQL DB Contributor	SQL	Gerenciar bancos SQL, mas não acesso nem dados
Monitoring Reader	Monitor	Ler métricas e logs de monitoramento
Backup Contributor	Backup	Gerenciar backups, mas não excluir cofres

A existência de papéis granulares como Virtual Machine Contributor versus Contributor reflete o princípio do menor privilégio em ação: um time de operações que gerencia apenas VMs não precisa de acesso para criar storage accounts ou configurar redes.

4. Visão Estrutural

Fluxo de Avaliação de Permissões

Quando um usuário tenta fazer uma ação em um recurso Azure, o sistema segue este fluxo:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Deny Assignments são atribuições de negação explícita. São mais raras (criadas principalmente pelo Azure Blueprints e por Azure Managed Applications), mas têm prioridade absoluta sobre qualquer permissão. Se existe um deny assignment, nem mesmo o Owner pode fazer a ação.

Herança em Ação: Exemplo Concreto

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Neste exemplo:

O Grupo-Auditoria pode ler recursos em toda a hierarquia (Management Group herda para baixo)
O Grupo-DevOps pode criar e gerenciar recursos em toda a assinatura Produção, mas não na assinatura Dev
O Grupo-Support pode ler o RG App-Frontend e todos os recursos dentro dele
joao@contoso.com pode gerenciar especificamente a VM frontend-01, mas não outros recursos no mesmo RG

5. Funcionamento na Prática

Ciclo de Vida de uma Atribuição de Papel

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Propagação: quando uma role assignment é criada ou removida, pode levar até 30 minutos para que a mudança se propague completamente. Em termos práticos, isso significa que um usuário recém-autorizado pode levar alguns minutos para conseguir acessar o recurso, e um usuário que teve acesso revogado pode ainda conseguir acessar por alguns minutos após a revogação.

Verificar Permissões Efetivas

O Azure permite verificar quais permissões um usuário efetivamente tem em um recurso, levando em conta todas as atribuições e heranças:

No portal: vá ao recurso > Access control (IAM) > aba Check access > selecione o usuário.

Isso mostra todas as role assignments que afetam aquele usuário naquele escopo, incluindo as herdadas de escopos superiores.

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: atribuições pontuais, verificação de acesso, visualização de quem tem acesso a um recurso.

Caminho: qualquer recurso, grupo de recursos ou assinatura > Access control (IAM) > Add role assignment

O fluxo no portal tem três passos:

Role: selecionar o papel da lista (filtrar por nome ajuda muito)
Members: selecionar o security principal (usuário, grupo, managed identity)
Conditions (opcional): adicionar condições ABAC (Attribute-Based Access Control) para papéis como Storage Blob Data Reader/Contributor

Vantagens: visual, mostra descrição do papel, permite verificar permissões antes de confirmar.

Limitações: não escala para múltiplas atribuições; não permite automação.

6.2 Azure CLI

Quando usar: scripts, automação em bash, pipelines CI/CD.

Verificar role assignments em um resource group:

az role assignment list \
  --resource-group rg-producao \
  --output table

Atribuir um papel a um usuário em um resource group:

az role assignment create \
  --assignee joao.silva@contoso.com \
  --role "Contributor" \
  --resource-group rg-producao

Atribuir papel a um grupo em uma assinatura:

az role assignment create \
  --assignee-object-id <object-id-do-grupo> \
  --assignee-principal-type Group \
  --role "Reader" \
  --scope "/subscriptions/<subscription-id>"

Remover uma atribuição de papel:

az role assignment delete \
  --assignee joao.silva@contoso.com \
  --role "Contributor" \
  --resource-group rg-producao

Listar todos os papéis disponíveis (integrados e customizados):

az role definition list --output table

Inspecionar a definição de um papel específico:

az role definition list --name "Contributor" --output json

Vantagens: scriptável, integrável a pipelines, sintaxe clara.

Limitações: menos verboso que PowerShell para operações complexas.

6.3 PowerShell (Az Module)

Quando usar: scripts complexos, automação em Windows, relatórios detalhados.

Listar role assignments em um escopo:

Get-AzRoleAssignment -ResourceGroupName "rg-producao"

Atribuir papel:

New-AzRoleAssignment `
  -SignInName "joao.silva@contoso.com" `
  -RoleDefinitionName "Contributor" `
  -ResourceGroupName "rg-producao"

Atribuir papel a um grupo por Object ID:

New-AzRoleAssignment `
  -ObjectId "<object-id-do-grupo>" `
  -RoleDefinitionName "Reader" `
  -Scope "/subscriptions/<subscription-id>"

Remover atribuição:

Remove-AzRoleAssignment `
  -SignInName "joao.silva@contoso.com" `
  -RoleDefinitionName "Contributor" `
  -ResourceGroupName "rg-producao"

Verificar permissões efetivas de um usuário:

# Lista todas as atribuições que afetam um usuário em uma assinatura
Get-AzRoleAssignment -SignInName "joao.silva@contoso.com" `
  -Scope "/subscriptions/<subscription-id>" `
  -ExpandPrincipalGroups

O parâmetro -ExpandPrincipalGroups é importante: ele inclui atribuições herdadas através de grupos dos quais o usuário é membro, não apenas atribuições diretas.

6.4 Microsoft Graph e ARM API

Para automação avançada e integração com sistemas externos, as role assignments são recursos do Azure Resource Manager acessíveis via API REST:

PUT https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId}?api-version=2022-04-01
Content-Type: application/json

{
  "properties": {
    "roleDefinitionId": "/subscriptions/{subId}/providers/Microsoft.Authorization/roleDefinitions/{roleDefId}",
    "principalId": "{object-id-do-security-principal}",
    "principalType": "Group"
  }
}

O {roleAssignmentId} é um GUID gerado pelo cliente (pode ser um UUID aleatório). O roleDefinitionId pode ser obtido com az role definition list --name "Contributor".

6.5 Azure Policy e Blueprints para Atribuição em Escala

Para garantir que determinados papéis sejam sempre atribuídos em novos recursos ou assinaturas, o Azure Policy (com efeito deployIfNotExists) pode criar role assignments automaticamente. Isso é particularmente útil para garantir que toda nova assinatura tenha um conjunto padrão de atribuições de papel.

7. Controle e Segurança

Limites de Role Assignments

Limite	Valor
Role assignments por assinatura	4.000
Papéis customizados por tenant	5.000
Role assignments por Management Group	500

O limite de 4.000 role assignments por assinatura é frequentemente atingido em ambientes com muitas atribuições granulares diretas a usuários individuais. A solução é usar grupos em vez de atribuições diretas a usuários: uma única atribuição de papel a um grupo serve para todos os membros do grupo, consumindo apenas 1 das 4.000 slots.

Deny Assignments

Deny assignments não podem ser criados diretamente pelo administrador via portal ou CLI. Eles são criados automaticamente pelo:

Azure Blueprints: ao aplicar um blueprint com lock, cria deny assignments para proteger recursos gerenciados
Azure Managed Applications: protege recursos gerenciados pelo publisher da aplicação
Azure Lighthouse: em cenários de gestão delegada entre tenants

Para visualizar deny assignments:

az role assignment list --include-deny-assignments --output table

Privileged Identity Management (PIM)

Em ambientes com licença Entra ID P2, o Privileged Identity Management adiciona uma camada de controle sobre role assignments:

Eligible assignments (atribuições elegíveis): o usuário tem o papel elegível mas precisa "ativar" explicitamente quando necessário, com justificativa e por tempo limitado.
Active assignments (atribuições ativas): o papel está ativo permanentemente, como o comportamento padrão do RBAC.

Com PIM, um desenvolvedor pode ter o papel Contributor como elegível em produção, ativando-o apenas quando precisar fazer uma mudança emergencial, com duração máxima configurada (ex: 8 horas) e registro automático de justificativa.

8. Tomada de Decisão

Qual papel atribuir em cada situação?

Situação	Papel recomendado	Motivo
Admin que gerencia tudo e precisa dar acesso a outros	Owner	Único papel com controle de RBAC + gestão de recursos
Time de DevOps que cria e gerencia infraestrutura	Contributor	Gerencia recursos sem poder alterar quem tem acesso
Auditor ou analista que só precisa visualizar	Reader	Somente leitura, sem risco de alteração
Responsável por gestão de acessos sem criar recursos	User Access Administrator	Gerencia RBAC sem criar/modificar recursos
Operação que gerencia apenas VMs	Virtual Machine Contributor	Escopo reduzido ao necessário
Aplicação que precisa ler blobs de storage	Storage Blob Data Reader	DataActions específicas, sem acesso ao plano de controle
Pipeline CI/CD que faz deploy de app	Contributor no RG específico	Escopo limitado ao necessário para o pipeline
Desenvolvedor em ambiente de produção sensível	Contributor elegível via PIM	Acesso just-in-time com auditoria e tempo limitado

Em qual escopo atribuir?

Situação	Escopo recomendado	Motivo
Acesso a um recurso específico (ex: uma VM)	Recurso individual	Menor superfície de acesso
Time que gerencia todos os recursos de um projeto	Resource Group	Agrupa recursos relacionados sem afetar outros grupos
Acesso transversal a todos os recursos de uma assinatura	Subscription	Necessário para papéis como Monitoring Reader
Política corporativa que se aplica a todas as assinaturas	Management Group	Atribuição propagada automaticamente

9. Boas Práticas

Atribua papéis a grupos, nunca diretamente a usuários individuais: uma atribuição a um grupo serve para todos os membros, usa apenas 1 slot dos 4.000 disponíveis, e facilita muito a gestão: adicionar ou remover alguém do grupo é suficiente, sem precisar gerenciar múltiplas role assignments.

Use o escopo mais restrito possível: se o usuário só precisa gerenciar VMs em um Resource Group, não atribua Contributor na assinatura inteira. O escopo mais restrito minimiza o impacto de um erro ou comprometimento de credenciais.

Prefira papéis específicos de serviço ao papel Contributor genérico: Virtual Machine Contributor em vez de Contributor; Storage Blob Data Reader em vez de Reader quando o foco é dados. Isso garante que o acesso seja exatamente o necessário.

Use PIM para papéis privilegiados: Owner e User Access Administrator especialmente devem ser atribuições elegíveis via PIM, não atribuições ativas permanentes. O acesso elevado deve ser usado apenas quando necessário e por tempo limitado.

Documente o motivo de cada atribuição: ao criar uma role assignment, use o campo de descrição (disponível via API e PowerShell) para registrar o motivo. Isso facilita imensamente as revisões futuras: "por que esse grupo tem Owner aqui?" não deveria ser uma pergunta sem resposta.

Implemente revisões periódicas de acesso: com Entra ID P2, os Access Reviews do Azure RBAC permitem que gestores confirmem periodicamente se as atribuições de papel ainda são necessárias. Isso combate o acúmulo de permissões ao longo do tempo.

10. Erros Comuns

Atribuir Owner quando Contributor seria suficiente

Este é o erro mais frequente. "Para garantir que ele consiga fazer tudo que precisa" é a justificativa típica. O resultado é que a pessoa também pode alterar quem tem acesso, potencialmente concedendo privilégios excessivos a outros. Sempre avalie se o usuário realmente precisa gerenciar atribuições de papel ou apenas gerenciar recursos.

Confundir papéis do Entra ID com papéis RBAC do Azure

Global Administrator não é Owner. Owner não é Global Administrator. São sistemas completamente diferentes. Um desenvolvedor que é Owner da assinatura não tem acesso para criar usuários no Entra ID. Um Global Administrator não pode criar VMs a menos que também tenha uma role assignment RBAC.

Atribuir papel diretamente ao usuário em vez de ao grupo

Com o tempo, isso consome os 4.000 slots de role assignment por assinatura e torna a gestão inviável. Cada novo funcionário que precisa de acesso consome mais slots, e quando alguém sai da empresa, é necessário lembrar de remover todas as atribuições diretas espalhadas por múltiplos escopos.

Não verificar permissões efetivas antes de encerrar o acesso

Um administrador remove uma atribuição de papel de um usuário, achando que revogou o acesso. Mas o usuário era membro de um grupo que tinha outra atribuição no mesmo escopo. O acesso continua. Sempre use "Check access" no portal ou -ExpandPrincipalGroups no PowerShell para verificar o acesso efetivo, não apenas as atribuições diretas.

Esquecer que NotActions não é uma negação explícita

Se o papel A tem * em Actions e Microsoft.Authorization/*/Delete em NotActions, isso significa que o papel não inclui a capacidade de deletar atribuições, não que está explicitamente negada. Se o usuário tem outro papel que inclui essa ação, ele consegue fazê-la. NotActions subtrai do papel atual; não bloqueia outras fontes de permissão.

Atingir o limite de 4.000 role assignments

Organizações que crescem rápido e atribuem papéis diretamente a usuários individuais atingem esse limite. Quando o limite é atingido, novas atribuições falham com erro e o acesso não pode ser concedido. A solução é uma migração trabalhosa para atribuições baseadas em grupos.

11. Operação e Manutenção

Auditoria de Role Assignments

Todas as criações e remoções de role assignments são registradas no Azure Activity Log:

Caminho: Monitor > Activity log > filtrar por Operation: Create role assignment ou Delete role assignment

Para consultar via PowerShell:

Get-AzLog -ResourceGroupName "rg-producao" `
  -StartTime (Get-Date).AddDays(-30) |
  Where-Object { $_.OperationName -like "*role*assignment*" } |
  Select-Object EventTimestamp, Caller, OperationName, Status

Inventário Completo de Acesso

Para obter um relatório de todas as role assignments em uma assinatura:

Get-AzRoleAssignment -Scope "/subscriptions/<subscription-id>" |
  Select-Object DisplayName, SignInName, RoleDefinitionName, Scope |
  Export-Csv -Path "role-assignments-report.csv" -NoTypeInformation

Detectar Role Assignments Órfãos

Role assignments para usuários que foram excluídos do Entra ID aparecem com um Object ID sem nome associado. Eles consumem slots e devem ser removidos:

$assignments = Get-AzRoleAssignment -Scope "/subscriptions/<subscription-id>"
$orphaned = $assignments | Where-Object { 
    $_.DisplayName -eq $null -and $_.SignInName -eq $null 
}
$orphaned | ForEach-Object {
    Write-Output "Órfão: $($_.ObjectId) - Papel: $($_.RoleDefinitionName) - Escopo: $($_.Scope)"
}

Verificar Uso dos Slots de Role Assignment

$assignments = Get-AzRoleAssignment -Scope "/subscriptions/<subscription-id>"
Write-Output "Total de role assignments: $($assignments.Count) / 4000"

12. Integração e Automação

Atribuição Automática em Pipelines de Infraestrutura

Em projetos de Infrastructure as Code com Terraform ou Bicep, role assignments são recursos gerenciados como código:

Bicep:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(resourceGroup().id, principalId, contributorRoleId)
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', contributorRoleId)
    principalId: principalId
    principalType: 'Group'
  }
}

Gerenciar role assignments como código garante que o estado desejado seja sempre reproduzível e auditável via controle de versão.

Integração com Azure Policy

O Azure Policy pode garantir que determinados papéis sejam sempre atribuídos em recursos criados:

deployIfNotExists: quando um Resource Group é criado, automaticamente atribui um papel a um grupo de auditoria.
modify: modifica atribuições existentes para conformidade.

Managed Identities e Atribuições Automáticas

Quando uma Managed Identity (identidade gerenciada) é criada para um recurso Azure (como uma VM ou uma Function App), ela frequentemente precisa de role assignments para interagir com outros recursos. Por exemplo, uma VM que precisa ler segredos do Key Vault precisa da role Key Vault Secrets User atribuída à sua Managed Identity.

Essa atribuição pode ser automatizada no template de deployment:

# Criar VM com system-assigned managed identity
az vm create --name minha-vm \
  --resource-group rg-producao \
  --assign-identity '[system]' \
  ...

# Obter o object ID da managed identity
IDENTITY_ID=$(az vm identity show --name minha-vm \
  --resource-group rg-producao \
  --query principalId -o tsv)

# Atribuir papel ao Key Vault
az role assignment create \
  --assignee-object-id $IDENTITY_ID \
  --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets User" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.KeyVault/vaults/meu-keyvault"

13. Resumo Final

Pontos essenciais:

O RBAC do Azure controla acesso a recursos (VMs, storage, redes). É diferente dos papéis do Entra ID, que controlam o diretório de identidades.
Uma role assignment é sempre a combinação de: security principal (quem) + role definition (o quê) + scope (onde).
Permissões são herdadas de cima para baixo na hierarquia: Management Group > Subscription > Resource Group > Resource.
Actions controlam operações de gerenciamento (plano de controle). DataActions controlam operações nos dados (plano de dados).
NotActions não nega explicitamente; subtrai ações do conjunto do papel atual.

Diferenças críticas:

Owner vs. Contributor: ambos gerenciam recursos. Owner também pode gerenciar atribuições RBAC; Contributor não pode.
Actions vs. DataActions: um usuário pode gerenciar um storage account (Actions) sem poder ler os dados nele (DataActions), e vice-versa.
Deny Assignment vs. NotActions: Deny Assignment é uma negação explícita com prioridade máxima, criada por Blueprints/Managed Apps, não pelo administrador. NotActions apenas subtrai ações de um papel.
Papéis do Entra ID vs. papéis Azure RBAC: sistemas independentes. Global Admin não é Owner. Owner não é Global Admin.

O que precisa ser lembrado:

Sempre atribua papéis a grupos, nunca diretamente a usuários individuais. Isso escala melhor e respeita o limite de 4.000 role assignments.
Use o escopo mais restrito possível para cada atribuição.
O limite de 4.000 role assignments por assinatura é real e pode ser atingido em ambientes grandes com atribuições diretas a usuários.
Após criar ou remover uma role assignment, pode levar até 30 minutos para propagar.
Role assignments para usuários excluídos do Entra ID ficam órfãs no sistema e consomem slots. Remova-as periodicamente.
O papel User Access Administrator permite gerenciar RBAC sem criar recursos. É diferente do Owner, que faz as duas coisas.
Em ambientes com Entra ID P2, use PIM para tornar papéis privilegiados (Owner, User Access Administrator) elegíveis em vez de ativos permanentemente.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 Os Três Elementos de uma Atribuição de Papel​

3.2 A Hierarquia de Escopos​

3.3 A Estrutura de uma Role Definition​

3.4 Os Quatro Papéis Fundamentais​

3.5 Papéis Específicos por Serviço​

4. Visão Estrutural​

Fluxo de Avaliação de Permissões​

Herança em Ação: Exemplo Concreto​

5. Funcionamento na Prática​

Ciclo de Vida de uma Atribuição de Papel​

Verificar Permissões Efetivas​

6. Formas de Implementação​

6.1 Portal do Azure​

6.2 Azure CLI​

6.3 PowerShell (Az Module)​

6.4 Microsoft Graph e ARM API​

6.5 Azure Policy e Blueprints para Atribuição em Escala​

7. Controle e Segurança​

Limites de Role Assignments​

Deny Assignments​

Privileged Identity Management (PIM)​

8. Tomada de Decisão​

Qual papel atribuir em cada situação?​

Em qual escopo atribuir?​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Auditoria de Role Assignments​

Inventário Completo de Acesso​

Detectar Role Assignments Órfãos​

Verificar Uso dos Slots de Role Assignment​

12. Integração e Automação​

Atribuição Automática em Pipelines de Infraestrutura​

Integração com Azure Policy​

Managed Identities e Atribuições Automáticas​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 Os Três Elementos de uma Atribuição de Papel

3.2 A Hierarquia de Escopos

3.3 A Estrutura de uma Role Definition

3.4 Os Quatro Papéis Fundamentais

3.5 Papéis Específicos por Serviço

4. Visão Estrutural

Fluxo de Avaliação de Permissões

Herança em Ação: Exemplo Concreto

5. Funcionamento na Prática

Ciclo de Vida de uma Atribuição de Papel

Verificar Permissões Efetivas

6. Formas de Implementação

6.1 Portal do Azure

6.2 Azure CLI

6.3 PowerShell (Az Module)

6.4 Microsoft Graph e ARM API

6.5 Azure Policy e Blueprints para Atribuição em Escala

7. Controle e Segurança

Limites de Role Assignments

Deny Assignments

Privileged Identity Management (PIM)

8. Tomada de Decisão

Qual papel atribuir em cada situação?

Em qual escopo atribuir?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Auditoria de Role Assignments

Inventário Completo de Acesso

Detectar Role Assignments Órfãos

Verificar Uso dos Slots de Role Assignment

12. Integração e Automação

Atribuição Automática em Pipelines de Infraestrutura

Integração com Azure Policy

Managed Identities e Atribuições Automáticas

13. Resumo Final