Fundamentação Teórica: Assign roles at different scopes

1. Intuição Inicial

Imagine que você é o gerente de segurança de um grande campus universitário com vários prédios: Reitoria, Biblioteca, Laboratórios e Restaurante. Você precisa definir quem pode acessar o quê.

Algumas pessoas precisam de acesso a tudo: o diretor de segurança circula por todo o campus. Outros têm acesso apenas a um prédio específico: o bibliotecário entra só na Biblioteca. Outros ainda têm acesso restrito a um único laboratório dentro do prédio de Laboratórios.

No Azure, essa lógica é exatamente o conceito de escopo (scope) na atribuição de papéis RBAC. O escopo define o perímetro dentro do qual uma permissão se aplica. Atribuir o papel Contributor a uma assinatura inteira é como dar a chave de todo o campus. Atribuir o mesmo papel a um único Resource Group é como dar a chave de um único prédio.

A diferença não está no papel em si, mas em onde ele se aplica.

2. Contexto

No módulo anterior, aprendemos o que são os papéis integrados do Azure e como eles funcionam. Agora o foco muda para a dimensão espacial do RBAC: onde as permissões se aplicam.

O escopo é o segundo dos três elementos fundamentais de qualquer role assignment:

100%

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

O escopo determina até onde a permissão "alcança". E como os escopos no Azure formam uma hierarquia, uma permissão atribuída em um nível superior se propaga automaticamente para todos os níveis abaixo. Esse mecanismo se chama herança de permissões.

Entender os escopos é fundamental para:

Aplicar o princípio do menor privilégio de forma precisa
Evitar concessão acidental de acesso excessivo
Estruturar o controle de acesso de forma escalável
Diagnosticar problemas de acesso corretamente

3. Construção dos Conceitos

3.1 A Hierarquia de Escopos do Azure

O Azure organiza todos os seus recursos em uma hierarquia de quatro níveis, do mais abrangente ao mais específico:

100%

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

Cada nível desta hierarquia é um escopo onde papéis podem ser atribuídos:

Nível	Escopo	Formato do ID de escopo
Root	Raiz do tenant	`/`
Management Group	Grupo de gerenciamento	`/providers/Microsoft.Management/managementGroups/{mgId}`
Subscription	Assinatura	`/subscriptions/{subscriptionId}`
Resource Group	Grupo de recursos	`/subscriptions/{subId}/resourceGroups/{rgName}`
Resource	Recurso individual	`/subscriptions/{subId}/resourceGroups/{rgName}/providers/{provider}/{type}/{name}`

3.2 Management Groups: O Nível Mais Alto

Os Management Groups (grupos de gerenciamento) são contêineres que organizam assinaturas. Eles não contêm recursos diretamente; contêm assinaturas (e outros Management Groups aninhados).

Cada tenant tem automaticamente um Root Management Group criado quando o Entra ID é provisionado. Todas as assinaturas do tenant são filhas do Root Management Group, diretamente ou através de Management Groups intermediários.

Para que servem os Management Groups?

Imagine uma empresa com 50 assinaturas organizadas por: ambiente (produção, dev, homologação), região (Brasil, Europa, EUA) e unidade de negócio (Varejo, B2B, Corporativo). Sem Management Groups, aplicar uma política de segurança ou uma atribuição de papel a todas as assinaturas de produção exigiria 50 operações individuais. Com Management Groups, uma única atribuição no Management Group "Produção" se propaga automaticamente para todas as assinaturas dentro dele.

3.3 O Princípio da Herança

Herança significa que uma permissão concedida em um escopo superior é automaticamente herdada por todos os escopos abaixo na hierarquia. Não é necessário nenhuma configuração adicional; a herança acontece automaticamente.

100%

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

Consequência importante: a herança não pode ser "bloqueada" no nível inferior. Se um grupo recebe Reader no Management Group raiz, ele pode ler recursos em todas as assinaturas do tenant, sem exceção. Não existe um mecanismo para dizer "herda este papel em todos os escopos filhos EXCETO neste Resource Group específico" usando apenas role assignments.

A única forma de negar acesso explicitamente é através de Deny Assignments, que como vimos são criados por Blueprints e Managed Applications, não diretamente pelo administrador.

3.4 Combinação de Permissões de Múltiplos Escopos

Um usuário pode ter múltiplas role assignments em diferentes escopos. As permissões são aditivas: o conjunto efetivo de permissões é a união de todas as permissões de todos os papéis em todos os escopos aplicáveis.

Exemplo:

100%

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

Para a usuária Ana:

No RG Dev: apenas Reader (herdado da assinatura)
No RG Produção: Reader (herdado) + Contributor (atribuído diretamente) = efetivamente Contributor
Na VM prod-01: Reader (herdado da assinatura) + Contributor (herdado do RG Produção) = efetivamente Contributor

A permissão mais ampla prevalece quando há sobreposição. Se alguém tem Reader em um escopo e Contributor em um escopo filho, no escopo filho a permissão efetiva é Contributor.

3.5 O Escopo de Recurso Individual

O escopo mais granular é o recurso individual. Uma atribuição neste nível afeta apenas aquele recurso específico.

Exemplo de escopo para uma VM específica:

/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-frontend-01

Este nível é útil quando:

Uma pessoa ou equipe gerencia apenas um recurso específico
Um script ou aplicação precisa de acesso a apenas um storage account ou Key Vault
Você quer dar acesso temporário e preciso a um recurso para debugging

4. Visão Estrutural

Mapa Completo de Herança e Combinação

100%

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

Análise das permissões efetivas neste cenário:

Principal	No RG App-Alpha	Na VM alpha-web-01	No Storage alphalogs
Grupo-Auditoria	Reader (herdado do MG)	Reader (herdado)	Reader (herdado)
Grupo-SecOps	Security Admin (herdado)	Security Admin (herdado)	Security Admin (herdado)
Grupo-DevOps	Contributor (herdado da Sub)	Contributor (herdado)	Contributor (herdado)
joao@contoso.com	Owner (herdado da Sub)	Owner (herdado)	Owner (herdado)
Grupo-Ops	Virtual Machine Contributor (direto no RG)	Virtual Machine Contributor (herdado do RG)	Nenhuma permissão adicional além do herdado
maria@contoso.com	Sem atribuição no RG	Reader (direto no recurso)	Sem acesso
Grupo-Analytics	Sem atribuição no RG	Sem acesso	Storage Blob Data Reader (direto no recurso, DataActions)

5. Funcionamento na Prática

Como o Azure Resolve o Escopo em Tempo Real

Quando um usuário tenta executar uma operação, o Azure avalia permissões percorrendo a hierarquia de cima para baixo:

100%

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

Comportamento não óbvio: o Azure não avalia apenas a role assignment mais próxima (a do recurso em si). Ele coleta todas as role assignments que afetam aquele usuário em todos os escopos aplicáveis (o recurso, o RG pai, a assinatura pai, o Management Group pai, até o root). A permissão efetiva é a soma de todas elas (menos os NotActions e Deny Assignments).

Propagação de Mudanças

Quando você cria ou remove uma role assignment, a mudança precisa se propagar pelo sistema distribuído do Azure. Em condições normais, leva alguns minutos. Em casos extremos (alta carga no sistema, mudanças em larga escala), pode levar até 30 minutos.

Durante esse período de propagação:

Um usuário recém-autorizado pode receber erros de acesso negado por alguns minutos
Um usuário que teve acesso revogado pode ainda conseguir acessar por alguns minutos

Em operações de segurança onde a revogação precisa ser imediata (por exemplo, comprometimento de credenciais), isso é um fator a considerar. O mecanismo mais eficaz para revogação imediata em situações de emergência é desabilitar a conta no Entra ID, não apenas remover a role assignment.

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: atribuições pontuais em qualquer nível da hierarquia.

O caminho para atribuição varia conforme o escopo desejado:

Escopo desejado	Caminho no portal
Management Group	`Management Groups > [selecionar MG] > Access control (IAM)`
Subscription	`Subscriptions > [selecionar Sub] > Access control (IAM)`
Resource Group	`Resource Groups > [selecionar RG] > Access control (IAM)`
Recurso individual	`[Navegar ao recurso] > Access control (IAM)`

Em qualquer um desses caminhos, o processo é idêntico: Add > Add role assignment > [selecionar papel] > [selecionar principal].

Visualizar atribuições herdadas: na aba Role assignments do IAM de qualquer recurso, você pode filtrar por Type: Inherited para ver apenas as atribuições herdadas de escopos superiores. Isso é muito útil para diagnóstico.

6.2 Azure CLI

Atribuição por escopo explícito via parâmetro --scope:

# Management Group
az role assignment create \
  --assignee-object-id <group-object-id> \
  --assignee-principal-type Group \
  --role "Reader" \
  --scope "/providers/Microsoft.Management/managementGroups/mg-corporativo"

# Subscription
az role assignment create \
  --assignee-object-id <group-object-id> \
  --assignee-principal-type Group \
  --role "Contributor" \
  --scope "/subscriptions/12345678-1234-1234-1234-123456789012"

# Resource Group
az role assignment create \
  --assignee-object-id <group-object-id> \
  --assignee-principal-type Group \
  --role "Virtual Machine Contributor" \
  --scope "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/rg-producao"

# Recurso individual (VM específica)
az role assignment create \
  --assignee-object-id <user-object-id> \
  --assignee-principal-type User \
  --role "Reader" \
  --scope "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-frontend-01"

Listar atribuições em um escopo específico (sem herança):

az role assignment list \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao" \
  --output table

Listar atribuições incluindo as herdadas:

az role assignment list \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao" \
  --include-inherited \
  --output table

O parâmetro --include-inherited é fundamental para entender o acesso efetivo, pois sem ele você vê apenas as atribuições diretas naquele escopo, não o quadro completo.

6.3 PowerShell (Az Module)

# Atribuição no Management Group
New-AzRoleAssignment `
  -ObjectId "<group-object-id>" `
  -RoleDefinitionName "Reader" `
  -Scope "/providers/Microsoft.Management/managementGroups/mg-corporativo"

# Atribuição na Subscription
New-AzRoleAssignment `
  -ObjectId "<group-object-id>" `
  -RoleDefinitionName "Contributor" `
  -Scope "/subscriptions/<subscription-id>"

# Alternativa para Resource Group (parâmetro dedicado)
New-AzRoleAssignment `
  -ObjectId "<group-object-id>" `
  -RoleDefinitionName "Virtual Machine Contributor" `
  -ResourceGroupName "rg-producao"

# Recurso individual (VM)
New-AzRoleAssignment `
  -ObjectId "<user-object-id>" `
  -RoleDefinitionName "Reader" `
  -ResourceGroupName "rg-producao" `
  -ResourceName "vm-frontend-01" `
  -ResourceType "Microsoft.Compute/virtualMachines"

Listar todas as atribuições incluindo herdadas para um usuário:

Get-AzRoleAssignment `
  -SignInName "joao.silva@contoso.com" `
  -Scope "/subscriptions/<sub-id>/resourceGroups/rg-producao" `
  -ExpandPrincipalGroups |
  Select-Object DisplayName, RoleDefinitionName, Scope

O -ExpandPrincipalGroups expande os grupos dos quais o usuário é membro para mostrar atribuições herdadas via grupo, não apenas atribuições diretas.

6.4 Bicep e ARM Templates (Infrastructure as Code)

Ao definir recursos como código, role assignments em diferentes escopos requerem abordagens diferentes em Bicep:

Role assignment no escopo do Resource Group (arquivo Bicep no contexto do RG):

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

Role assignment no escopo da Subscription (requer targetScope = 'subscription'):

targetScope = 'subscription'

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

Role assignment no escopo do Management Group (requer targetScope = 'managementGroup'):

targetScope = 'managementGroup'

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

A diferença entre subscriptionResourceId, tenantResourceId e a função sem prefixo de escopo é crítica ao trabalhar com Bicep em diferentes níveis da hierarquia.

7. Controle e Segurança

Quem Pode Atribuir Papéis em Cada Escopo?

Para criar uma role assignment em um escopo, o usuário precisa ter a permissão Microsoft.Authorization/roleAssignments/write naquele escopo. Os papéis que concedem essa permissão são:

Papel	Pode atribuir papéis em:
Owner	O escopo onde tem Owner, e todos os escopos filhos
User Access Administrator	O escopo onde tem UAA, e todos os escopos filhos
Role Based Access Control Administrator	Apenas gerencia RBAC, pode ser configurado com condições

Importante: você só pode atribuir papéis cujas permissões são um subconjunto das suas próprias permissões. Não é possível usar o Owner para dar a alguém um papel que você mesmo não tem. Isso previne escalada de privilégios.

Condições ABAC (Attribute-Based Access Control)

Para alguns papéis específicos (principalmente Storage Blob Data Reader/Contributor e alguns papéis de filas), o Azure suporta condições que adicionam uma camada de controle baseada em atributos do recurso.

Exemplo: você quer que o Grupo-Analytics tenha acesso de leitura apenas a blobs em containers que tenham a tag confidentiality: public, e não a containers com confidentiality: restricted. Com uma condição ABAC, é possível expressar isso:

(
  (!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}))
  OR
  (
    @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEqualsIgnoreCase 'logs-publicos'
  )
)

Condições ABAC são uma forma de tornar atribuições de escopo mais granulares sem precisar criar papéis customizados ou múltiplas atribuições separadas.

8. Tomada de Decisão

Em qual escopo atribuir?

Situação	Escopo recomendado	Motivo
Equipe de auditoria que precisa ler todos os recursos da empresa	Management Group raiz com Reader	Cobertura completa com uma única atribuição
Time de segurança que aplica políticas em todas as assinaturas de produção	Management Group "Produção"	Escopo adequado sem afetar Dev e Homologação
Time DevOps que gerencia uma assinatura específica	Subscription	Escopo correto para gerência transversal
Time de aplicação que gerencia um conjunto de recursos de um projeto	Resource Group	Isola o acesso ao projeto sem afetar outros
Operador que gerencia apenas uma VM específica	Recurso individual	Menor privilégio possível
Pipeline CI/CD que faz deploy em um RG específico	Resource Group (Contributor no RG de destino)	Escopo restrito ao necessário para o deploy
Aplicação que lê segredos de um Key Vault específico	Recurso individual (Key Vault)	Acesso somente ao cofre necessário

Quando usar atribuição direta vs. herança?

Abordagem	Quando usar	Cuidados
Atribuição em escopo alto + herança	Papéis transversais como Reader para auditores, Security Admin para SecOps	Não pode ser bloqueada em escopos filhos
Atribuição em escopo baixo (RG ou recurso)	Papéis específicos de times ou serviços	Mais controle, mais atribuições a gerenciar
Combinação de ambos	A maioria dos ambientes reais	Auditor com Reader no MG + DevOps com Contributor no RG de cada projeto

9. Boas Práticas

Estruture os Management Groups antes de começar a atribuir papéis: a hierarquia de Management Groups determina como as permissões se propagam. Definir essa estrutura depois de já ter muitas atribuições é muito mais trabalhoso. Planeje primeiro: o critério mais comum para organizar Management Groups é por ambiente (Produção / NonProdução) ou por unidade de negócio.

Use o escopo de Resource Group como unidade padrão de acesso: o Resource Group é o escopo mais natural para a maioria dos cenários operacionais. Ele agrupa recursos relacionados de um projeto ou aplicação, e atribuir papéis no RG garante que um time tem acesso a tudo que precisa para aquele projeto sem afetar outros.

Reserva do escopo de Subscription para papéis transversais: papéis atribuídos na assinatura devem ser para atividades que genuinamente atravessam todos os Resource Groups, como monitoramento, auditoria ou políticas de segurança. Evite atribuir Contributor no nível da assinatura para times que só precisam trabalhar em um subconjunto dos recursos.

Reserve o Management Group para políticas corporativas: atribuições no Management Group devem ser para papéis que toda a organização precisa ter de forma consistente, como o grupo de auditoria com Reader. Não use Management Group para dar acesso operacional a times específicos.

Documente o escopo e o motivo de cada atribuição crítica: especialmente para atribuições em escopos altos (MG e Subscription), documente: quem pediu, por que foi concedido, quando deve ser revisado. A ausência de documentação transforma uma herança intencional em um mistério de auditoria anos depois.

Implemente revisões de acesso por escopo: configure Access Reviews (Entra ID P2) específicas para grupos com papéis em escopos amplos (como Contributor em uma assinatura inteira). Revisões frequentes para escopos mais abrangentes ajudam a identificar acesso excessivo antes que se torne um risco.

10. Erros Comuns

Atribuir papel no escopo da Subscription quando o Resource Group seria suficiente

Este é o erro mais frequente e vem da intenção de "garantir que funcione". O resultado é que o usuário ou grupo ganha acesso a todos os recursos de todos os Resource Groups da assinatura, incluindo aqueles que não eram intenção. Em uma assinatura com 20 Resource Groups, isso é uma concessão de acesso 20x maior do que o necessário.

Não considerar permissões herdadas ao diagnosticar "acesso excessivo"

Um administrador identifica que um usuário tem acesso a um recurso que não deveria e remove a role assignment direta. O acesso continua. A investigação revela que o usuário é membro de um grupo que tem uma atribuição herdada de um Management Group. Remoções de acesso precisam considerar toda a cadeia de herança, não apenas o escopo imediato.

Usar --include-inherited como opcional em vez de padrão em diagnósticos

Quando investigando problemas de acesso, muitos administradores listam role assignments sem --include-inherited e concluem erroneamente que não há permissão quando na verdade a permissão existe mas é herdada. Sempre use --include-inherited (ou a aba "Inherited" no portal) quando fazendo diagnóstico de acesso.

Criar role assignments no escopo de recurso individual para muitos recursos

Uma abordagem que parece precisa (cada aplicação tem acesso apenas ao seu storage account) rapidamente se torna inviável: centenas de role assignments individuais, difíceis de auditar, que consomem os 4.000 slots disponíveis por assinatura. A solução escalável é agrupar recursos relacionados no mesmo Resource Group e atribuir papéis no nível do RG.

Assumir que remover um papel em um escopo filho revoga todas as permissões

Se um usuário tem Contributor herdado de uma assinatura e você adiciona depois um Reader diretamente em um Resource Group (talvez tentando "rebaixar" a permissão naquele escopo), o resultado não é o esperado. As permissões são aditivas: o usuário mantém Contributor naquele RG por herança, e a atribuição Reader direta não "bloqueia" a herança. Para reduzir permissões herdadas, é necessário atuar no escopo de origem da herança.

11. Operação e Manutenção

Inventário por Escopo

Para obter uma visão consolidada de todas as atribuições em cada nível:

# Todas as atribuições no nível de Management Group
Get-AzRoleAssignment -Scope "/providers/Microsoft.Management/managementGroups/mg-corporativo" |
  Select-Object DisplayName, RoleDefinitionName, Scope, ObjectType

# Todas as atribuições diretas na assinatura (sem herdadas)
Get-AzRoleAssignment -Scope "/subscriptions/<sub-id>" |
  Where-Object { $_.Scope -eq "/subscriptions/<sub-id>" } |
  Select-Object DisplayName, RoleDefinitionName, ObjectType

O segundo comando filtra apenas atribuições diretamente no escopo da assinatura (sem as herdadas de MGs acima nem as atribuídas em RGs abaixo), o que é útil para auditoria focada.

Verificar Acesso Efetivo de um Usuário Específico

Para um diagnóstico completo de por que um usuário tem ou não tem acesso a um recurso:

# Verificar todas as role assignments que afetam um usuário em um recurso específico
az role assignment list \
  --assignee joao.silva@contoso.com \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-01" \
  --include-inherited \
  --include-groups \
  --output table

O --include-groups inclui atribuições que o usuário herda por ser membro de grupos, o que é fundamental para o diagnóstico completo.

Detecção de Atribuições Duplicadas

Em ambientes grandes, é comum ter a mesma permissão concedida em múltiplos escopos (ex: Reader em um MG e Reader também em várias assinaturas dentro daquele MG). As atribuições da assinatura são redundantes. Um script de limpeza pode identificar isso:

$subAssignments = Get-AzRoleAssignment -Scope "/subscriptions/<sub-id>"
$mgAssignments = Get-AzRoleAssignment -Scope "/providers/Microsoft.Management/managementGroups/mg-corp"

# Encontrar atribuições redundantes (mesmo papel, mesmo principal)
foreach ($subAssign in $subAssignments) {
    $duplicate = $mgAssignments | Where-Object {
        $_.ObjectId -eq $subAssign.ObjectId -and
        $_.RoleDefinitionName -eq $subAssign.RoleDefinitionName
    }
    if ($duplicate) {
        Write-Output "Redundante: $($subAssign.DisplayName) - $($subAssign.RoleDefinitionName) em $($subAssign.Scope)"
    }
}

12. Integração e Automação

Atribuições em Escala com Azure Policy

O Azure Policy com efeito deployIfNotExists pode garantir que toda nova assinatura ou Resource Group receba automaticamente um conjunto padrão de role assignments:

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Resources/subscriptions"
  },
  "then": {
    "effect": "deployIfNotExists",
    "details": {
      "type": "Microsoft.Authorization/roleAssignments",
      "deploymentScope": "subscription",
      "deployment": {
        "properties": {
          "mode": "incremental",
          "template": {
            // template que cria a role assignment padrão
          }
        }
      }
    }
  }
}

Com essa abordagem, toda assinatura criada no Management Group automaticamente recebe, por exemplo, o grupo de auditoria com Reader, sem nenhuma ação manual do administrador.

Blueprints para Atribuições em Landing Zones

O Azure Blueprints (e sua evolução, o Azure Deployment Environments) permite definir um "pacote" de configurações para uma nova assinatura que inclui:

Políticas
Role assignments em múltiplos escopos
Resource Groups pré-criados
Templates ARM/Bicep

Quando uma nova assinatura é provisionada a partir do Blueprint, todas as role assignments definidas são criadas automaticamente nos escopos corretos, garantindo conformidade desde o primeiro momento.

Terraform para Gestão de Escopos

No Terraform, role assignments em diferentes escopos são expressas com o mesmo recurso azurerm_role_assignment, variando apenas o argumento scope:

# Scope: Subscription
resource "azurerm_role_assignment" "devops_contributor_sub" {
  scope                = "/subscriptions/${var.subscription_id}"
  role_definition_name = "Contributor"
  principal_id         = var.devops_group_id
}

# Scope: Resource Group
resource "azurerm_role_assignment" "ops_vm_contributor_rg" {
  scope                = azurerm_resource_group.producao.id
  role_definition_name = "Virtual Machine Contributor"
  principal_id         = var.ops_group_id
}

# Scope: Recurso individual (Key Vault)
resource "azurerm_role_assignment" "app_kv_reader" {
  scope                = azurerm_key_vault.app_vault.id
  role_definition_name = "Key Vault Secrets User"
  principal_id         = azurerm_user_assigned_identity.app_identity.principal_id
}

Gerenciar essas atribuições como código Terraform garante que o estado desejado seja sempre documentado, versionado e reproduzível.

13. Resumo Final

Pontos essenciais:

O escopo define onde uma permissão se aplica na hierarquia: Root > Management Group > Subscription > Resource Group > Resource.
Permissões são herdadas de cima para baixo: uma atribuição em um Management Group se propaga automaticamente para todas as assinaturas, Resource Groups e recursos dentro dele.
Permissões de múltiplos papéis e escopos são aditivas: a permissão efetiva é a soma de todas as permissões aplicáveis.
A herança não pode ser bloqueada em escopos filhos via role assignments. Deny Assignments podem bloquear, mas não são criados diretamente pelo administrador.

Diferenças críticas:

Atribuição direta no escopo vs. atribuição herdada: visualmente distintas no portal (aba "Inherited"), mas operacionalmente equivalentes para o usuário.
Listar atribuições sem --include-inherited vs. com --include-inherited: o primeiro mostra apenas atribuições diretas naquele escopo; o segundo mostra o quadro completo de acesso efetivo.
Adicionar Reader em escopo filho não reduz a permissão Contributor herdada de escopo pai: permissões são aditivas, não substitutivas.
Management Group scope vs. Subscription scope: o MG afeta todas as assinaturas dentro dele (presente e futuras); a Subscription afeta apenas aquela assinatura específica.

O que precisa ser lembrado:

O escopo correto para a maioria dos acessos operacionais de times é o Resource Group, não a Subscription.
Atribuições em Management Groups e Subscriptions devem ser para papéis transversais (auditoria, segurança, monitoramento), não para acesso operacional de times específicos.
Ao diagnosticar problemas de acesso, sempre use --include-inherited e --include-groups para ver o quadro completo.
A propagação de mudanças em role assignments pode levar até 30 minutos.
O limite de 4.000 role assignments por assinatura aplica-se às atribuições diretamente naquela assinatura e nos escopos dentro dela (RGs e recursos). Atribuições em Management Groups não contam para esse limite.
Em Infrastructure as Code (Bicep, Terraform), o targetScope do arquivo deve corresponder ao escopo da atribuição: use targetScope = 'subscription' para atribuições na subscription, targetScope = 'managementGroup' para Management Groups.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 A Hierarquia de Escopos do Azure​

3.2 Management Groups: O Nível Mais Alto​

3.3 O Princípio da Herança​

3.4 Combinação de Permissões de Múltiplos Escopos​

3.5 O Escopo de Recurso Individual​

4. Visão Estrutural​

Mapa Completo de Herança e Combinação​

5. Funcionamento na Prática​

Como o Azure Resolve o Escopo em Tempo Real​

Propagação de Mudanças​

6. Formas de Implementação​

6.1 Portal do Azure​

6.2 Azure CLI​

6.3 PowerShell (Az Module)​

6.4 Bicep e ARM Templates (Infrastructure as Code)​

7. Controle e Segurança​

Quem Pode Atribuir Papéis em Cada Escopo?​

Condições ABAC (Attribute-Based Access Control)​

8. Tomada de Decisão​

Em qual escopo atribuir?​

Quando usar atribuição direta vs. herança?​

9. Boas Práticas​

10. Erros Comuns​

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

Inventário por Escopo​

Verificar Acesso Efetivo de um Usuário Específico​

Detecção de Atribuições Duplicadas​

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

Atribuições em Escala com Azure Policy​

Blueprints para Atribuições em Landing Zones​

Terraform para Gestão de Escopos​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 A Hierarquia de Escopos do Azure

3.2 Management Groups: O Nível Mais Alto

3.3 O Princípio da Herança

3.4 Combinação de Permissões de Múltiplos Escopos

3.5 O Escopo de Recurso Individual

4. Visão Estrutural

Mapa Completo de Herança e Combinação

5. Funcionamento na Prática

Como o Azure Resolve o Escopo em Tempo Real

Propagação de Mudanças

6. Formas de Implementação

6.1 Portal do Azure

6.2 Azure CLI

6.3 PowerShell (Az Module)

6.4 Bicep e ARM Templates (Infrastructure as Code)

7. Controle e Segurança

Quem Pode Atribuir Papéis em Cada Escopo?

Condições ABAC (Attribute-Based Access Control)

8. Tomada de Decisão

Em qual escopo atribuir?

Quando usar atribuição direta vs. herança?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Inventário por Escopo

Verificar Acesso Efetivo de um Usuário Específico

Detecção de Atribuições Duplicadas

12. Integração e Automação

Atribuições em Escala com Azure Policy

Blueprints para Atribuições em Landing Zones

Terraform para Gestão de Escopos

13. Resumo Final