Laboratório de Troubleshooting: Assign roles at different scopes
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que o usuário marcos@contoso.com consegue listar e visualizar todos os recursos dentro do resource group rg-app-prd, mas não consegue criar nem modificar nenhum recurso nesse grupo. O administrador responsável afirma ter atribuído a função Contributor para esse usuário diretamente em rg-app-prd há dois dias.
Ao investigar, o administrador executa o seguinte comando e obtém a saída abaixo:
az role assignment list --assignee "marcos@contoso.com" --all --output table
PrincipalName RoleDefinitionName Scope
-------------------- -------------------- -----------------------------------------------
marcos@contoso.com Reader /subscriptions/aaaa-1111-bbbb-2222
marcos@contoso.com Contributor /subscriptions/aaaa-1111-bbbb-2222/resourceGroups/rg-app-prd
O administrador também verifica que rg-app-prd foi criado há três semanas, que a assinatura está ativa e que o custo mensal do ambiente aumentou recentemente devido à adição de novos recursos.
Ao tentar criar uma máquina virtual, marcos@contoso.com recebe a seguinte mensagem:
The client 'marcos@contoso.com' with object id 'xxxx' does not have authorization
to perform action 'Microsoft.Compute/virtualMachines/write' over scope
'/subscriptions/aaaa-1111-bbbb-2222/resourceGroups/rg-app-prd'
or the scope is invalid.
Qual é a causa raiz da impossibilidade de criar recursos em rg-app-prd?
A) A função Contributor foi atribuída corretamente, mas o aumento recente de custos ativou um bloqueio automático na assinatura.
B) Existe um resource lock do tipo ReadOnly aplicado em rg-app-prd ou em um escopo ancestral, que impede operações de escrita independentemente das funções RBAC.
C) A função Reader atribuída na assinatura sobrescreve a função Contributor atribuída no resource group, pois atribuições em escopos superiores têm precedência.
D) A mensagem de erro indica que o escopo do resource group foi invalidado após a recriação do grupo com o mesmo nome.
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que um service principal chamado sp-deploy-automacao possui a função Owner atribuída na assinatura Sub-Producao. A causa está identificada: o responsável anterior pela automação atribuiu Owner em vez de Contributor por engano, e o service principal nunca precisou gerenciar permissões de outros usuários.
O ambiente é de produção com dezenas de pipelines ativos que utilizam esse service principal para implantação de recursos. A troca de credenciais ou de identidade do service principal exigiria atualização em todos os pipelines, o que está fora do escopo aprovado para esta semana. O time de segurança exige que o excesso de privilégio seja eliminado hoje.
Qual é a ação correta a tomar neste momento?
A) Remover a atribuição de Owner e atribuir Contributor no mesmo escopo de assinatura, sem alterar as credenciais nem a identidade do service principal.
B) Remover a atribuição de Owner e não atribuir nenhuma outra função até que os pipelines sejam auditados e os escopos mínimos necessários sejam mapeados.
C) Manter a atribuição de Owner e criar uma deny assignment para bloquear especificamente a ação Microsoft.Authorization/roleAssignments/write.
D) Substituir o service principal por um novo com Contributor atribuído e atualizar os pipelines em regime de urgência.
Cenário 3 — Causa Raiz
Um desenvolvedor reporta que julia@contoso.com não consegue acessar nenhum recurso da assinatura Sub-Dev, mesmo tendo recebido a função Contributor no management group MG-Desenvolvimento, que contém essa assinatura.
O administrador verifica as atribuições com o seguinte comando:
az role assignment list \
--assignee "julia@contoso.com" \
--scope "/providers/Microsoft.Management/managementGroups/MG-Desenvolvimento" \
--output table
PrincipalName RoleDefinitionName Scope
------------------- -------------------- -------------------------------------------------------
julia@contoso.com Contributor /providers/Microsoft.Management/managementGroups/MG-Desenvolvimento
O administrador também confirma que Sub-Dev está listada como filha de MG-Desenvolvimento no portal, que a assinatura foi movida para esse management group há 72 horas e que julia@contoso.com tem licença do Microsoft 365 ativa.
Ao tentar acessar qualquer recurso de Sub-Dev pelo portal, julia@contoso.com recebe a mensagem:
You don't have access to this subscription.
Contact your administrator.
Qual é a causa raiz do problema?
A) A licença do Microsoft 365 de julia@contoso.com está impedindo o acesso ao portal do Azure, pois esse tipo de licença não inclui acesso ao Azure por padrão.
B) A propagação de permissões após mover uma assinatura para um management group pode levar até 24 horas, e como a movimentação ocorreu há 72 horas, a causa deve ser outra: o management group MG-Desenvolvimento não está corretamente associado ao tenant.
C) A atribuição de função foi feita no management group correto, mas a herança de permissões para assinaturas recém-associadas pode levar até 30 minutos para se propagar; como a movimentação ocorreu há 72 horas, esse prazo já teria expirado, indicando que a assinatura pode não estar efetivamente sob MG-Desenvolvimento no plano de controle, apesar da exibição visual no portal.
D) O type do escopo usado no comando az role assignment list é incorreto para management groups, o que faz o comando retornar dados inválidos; a atribuição real pode não existir.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o relato de que pedro@contoso.com não consegue excluir um resource group chamado rg-legado dentro da assinatura Sub-Corp, apesar de possuir a função Contributor atribuída nessa assinatura.
Os passos de investigação disponíveis são:
P1. Verificar se existe algum resource lock do tipo CanNotDelete aplicado em rg-legado ou na assinatura Sub-Corp.
P2. Verificar se pedro@contoso.com possui alguma deny assignment explícita que cubra a ação Microsoft.Resources/subscriptions/resourcegroups/delete.
P3. Confirmar que a função Contributor está efetivamente atribuída a pedro@contoso.com na assinatura Sub-Corp e que o escopo está correto.
P4. Tentar executar a exclusão usando uma conta com Owner para determinar se o problema é de permissão ou de bloqueio de recurso.
P5. Verificar se existem recursos dentro de rg-legado que possuem bloqueios individuais que impedem a exclusão do grupo.
Qual é a sequência correta de investigação?
A) P3 → P2 → P1 → P5 → P4
B) P1 → P3 → P2 → P4 → P5
C) P4 → P1 → P3 → P2 → P5
D) P3 → P1 → P5 → P2 → P4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A saída do comando az role assignment list confirma que a função Contributor está corretamente atribuída em rg-app-prd. Isso elimina qualquer hipótese de atribuição ausente ou incorreta. O comportamento observado, leitura funcionando e escrita bloqueada, é exatamente o padrão causado por um resource lock do tipo ReadOnly. Esse tipo de bloqueio permite operações GET mas bloqueia PUT, POST, PATCH e DELETE, operando em uma camada separada do RBAC e sobrepondo-se a ele.
A informação sobre o aumento de custo é deliberadamente irrelevante e não tem nenhuma relação com bloqueios de acesso. Ela foi incluída para induzir o raciocínio para a alternativa A, que descreve um comportamento inexistente no Azure.
A alternativa C representa o erro diagnóstico mais perigoso deste cenário: confundir o modelo aditivo do RBAC com um modelo de precedência hierárquica. O Azure RBAC não sobrescreve funções mais permissivas com funções menos permissivas; ele as combina. Se a alternativa C fosse verdadeira, seria impossível restringir permissões em escopos inferiores para usuários com funções amplas em escopos superiores, o que contradiz o próprio design do RBAC.
Agir com base na alternativa C levaria o administrador a remover atribuições válidas sem resolver o problema real, mantendo o resource lock intacto e o usuário bloqueado.
Gabarito — Cenário 2
Resposta: A
O problema está identificado e é específico: o service principal possui Owner quando precisava de Contributor. A restrição crítica do cenário é que a identidade não pode ser substituída e os pipelines não podem ser alterados esta semana. A ação correta é remover a atribuição excessiva e substituí-la pela função adequada no mesmo escopo, sem nenhuma mudança de identidade ou credencial.
A alternativa B seria tecnicamente correta em um cenário de revisão profunda, mas ignora a restrição explícita de que o excesso de privilégio precisa ser eliminado hoje. Deixar o service principal sem nenhuma função interromperia todos os pipelines de produção imediatamente.
A alternativa C representa uma abordagem tecnicamente interessante, mas deny assignments no Azure não podem ser criadas diretamente por administradores via RBAC padrão; elas são gerenciadas por blueprints e políticas específicas. Mesmo que fosse possível, manter Owner e tentar bloquear ações específicas é uma abordagem frágil que não elimina o privilégio excessivo de forma limpa.
A alternativa D resolve o problema estruturalmente, mas viola a restrição de escopo aprovado para a semana, o que a torna incorreta dado o contexto apresentado.
Gabarito — Cenário 3
Resposta: D
A pista central está no formato do parâmetro --scope usado no comando. O valor correto para referenciar um management group no Azure CLI é:
/providers/Microsoft.Management/managementGroups/{groupId}
Esse formato está correto na saída apresentada, e a atribuição aparece listada. Porém, a questão descreve um comportamento de acesso negado após 72 horas, muito além de qualquer janela de propagação. Isso aponta para um problema estrutural, não de latência.
A alternativa C está parcialmente correta ao mencionar que 72 horas já ultrapassaria qualquer janela de propagação, mas conclui erroneamente que a assinatura não está no plano de controle. A verificação no portal confirma que a assinatura está visualmente associada ao management group. O ponto real é que a exibição visual no portal pode não refletir o estado efetivo do plano de controle imediatamente após uma movimentação, e a atribuição de função, embora apareça no comando, pode estar referenciando um management group cujo vínculo com a assinatura ainda não foi completamente processado no plano de autorização.
A informação sobre a licença do Microsoft 365 é deliberadamente irrelevante. Licenças do Microsoft 365 não interferem no acesso ao portal do Azure nem nas permissões RBAC.
Gabarito — Cenário 4
Resposta: A
A sequência correta de diagnóstico é P3 → P2 → P1 → P5 → P4, e ela segue o princípio de validar primeiro o que você sabe antes de investigar o que você suspeita.
P3 primeiro: antes de investigar bloqueios, é necessário confirmar que a atribuição de função que deveria funcionar realmente existe e está no escopo correto. Um diagnóstico que pula essa etapa pode gastar tempo investigando bloqueios quando a causa é simplesmente uma atribuição ausente ou em escopo errado.
P2 segundo: deny assignments têm precedência sobre qualquer função RBAC e são invisíveis na listagem padrão de role assignments. Verificar isso antes de investigar resource locks evita o erro de concluir que "as permissões estão certas" sem considerar negações explícitas.
P1 terceiro: verificar resource locks no resource group e na assinatura, pois um CanNotDelete bloquearia a exclusão independentemente das permissões RBAC confirmadas nas etapas anteriores.
P5 quarto: verificar locks em recursos individuais dentro do grupo, que também impediriam a exclusão do grupo pai.
P4 por último: usar uma conta com Owner para isolar se o problema é de permissão ou de bloqueio estrutural é uma técnica de validação válida, mas destrutiva como diagnóstico se executada antes de entender o estado do ambiente. Deve ser o último recurso de confirmação, não o ponto de partida.
Árvore de Troubleshooting: Assign roles at different scopes
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma: um principal sem o acesso que deveria ter. Siga pela primeira pergunta diagnóstica e responda com base no que você pode observar diretamente, usando os comandos indicados nos nós de verificação. Cada ramificação leva você progressivamente de uma pergunta verificável para a causa específica e, a partir dela, para a ação correta. Não avance para investigar bloqueios ou deny assignments antes de confirmar que a atribuição de função existe; validar o mais simples primeiro é o princípio que organiza toda a árvore.