Laboratório de Troubleshooting: Manage Built-in Azure Roles
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma engenheira de plataforma recebe reclamações de que um desenvolvedor não consegue fazer deploy de uma aplicação via Azure CLI. O desenvolvedor tem acesso ao portal e consegue visualizar todos os recursos do resource group rg-apps-prod sem problemas. A assinatura foi migrada para um novo Management Group há três dias como parte de uma reorganização interna.
Ao tentar executar o deploy, o desenvolvedor recebe o seguinte erro:
$ az webapp deploy --resource-group rg-apps-prod --name app-contoso --src-path ./build.zip
(AuthorizationFailed) The client 'dev@contoso.com' with object id 'a1b2c3...'
does not have authorization to perform action
'Microsoft.Web/sites/write' over scope
'/subscriptions/xxxx/resourceGroups/rg-apps-prod/resources'
or the scope is invalid.
A engenheira verifica as atribuições de role e encontra o seguinte:
$ az role assignment list --assignee dev@contoso.com --all
[
{
"roleDefinitionName": "Contributor",
"scope": "/subscriptions/xxxx/resourceGroups/rg-apps-prod",
"principalName": "dev@contoso.com"
}
]
O desenvolvedor não relatou nenhum problema no dia anterior à migração. A conta do desenvolvedor foi criada há seis meses e nunca foi desativada.
Qual é a causa raiz do problema observado?
A) A role Contributor não inclui a permissão Microsoft.Web/sites/write, que requer a role Website Contributor
B) Existe um deny assignment aplicado no escopo do Management Group ou da assinatura que bloqueia a ação
C) O token de sessão do desenvolvedor foi invalidado pela migração do Management Group e precisa ser renovado
D) A role Contributor foi atribuída no resource group, mas a ação de deploy exige atribuição no escopo da assinatura
Cenário 2 — Decisão de Ação
Um administrador identificou que um processo automatizado de provisionamento falhou porque a service principal usada pelo pipeline de CI/CD perdeu sua atribuição de role após uma limpeza manual de permissões realizada por outro administrador. A causa está confirmada: a role Contributor que existia no resource group rg-infra-dev foi removida inadvertidamente.
O ambiente é de desenvolvimento, sem impacto em produção. O pipeline está parado há 40 minutos. O administrador tem a role Owner na assinatura. A equipe de segurança exige que qualquer nova atribuição de role em ambientes gerenciados seja registrada via ticket no sistema de ITSM antes de ser aplicada, mas o processo de aprovação leva em média 2 horas.
Qual é a ação correta a tomar neste momento?
A) Reatribuir imediatamente a role Contributor à service principal no resource group, pois o ambiente é de desenvolvimento e o impacto é baixo
B) Escalar para o time de segurança solicitando uma exceção de emergência e aguardar aprovação antes de qualquer ação
C) Abrir o ticket no ITSM registrando a atribuição necessária e aguardar o processo de aprovação antes de aplicar a mudança
D) Atribuir temporariamente a role Owner à service principal para restaurar o pipeline enquanto o ticket é processado
Cenário 3 — Causa Raiz
Um administrador de nuvem relata que um usuário com a role User Access Administrator no escopo de uma assinatura está conseguindo modificar recursos diretamente, criando e deletando storage accounts sem nenhuma role adicional atribuída. O administrador abriu um chamado afirmando que o comportamento viola o modelo de permissões esperado.
A equipe de segurança solicita urgência na investigação. O tenant usa Microsoft Entra ID com licença P2. O usuário em questão é membro de três grupos de segurança.
A investigação retorna o seguinte:
$ az role assignment list --assignee user-ops@contoso.com --all --include-groups
[
{
"roleDefinitionName": "User Access Administrator",
"scope": "/subscriptions/xxxx",
"principalName": "user-ops@contoso.com"
},
{
"roleDefinitionName": "Contributor",
"scope": "/subscriptions/xxxx",
"principalName": "sg-platform-team"
}
]
Qual é a causa raiz do comportamento observado?
A) A role User Access Administrator inclui permissões de escrita sobre recursos, o que explica a capacidade de criar storage accounts
B) O usuário está recebendo a role Contributor por herança de grupo, e essa atribuição não estava visível na consulta inicial sem o flag --include-groups
C) A licença Microsoft Entra ID P2 ativa permissões elevadas automaticamente para usuários membros de múltiplos grupos
D) Existe uma custom role mal configurada sobreposta à User Access Administrator que expande as permissões do usuário
Cenário 4 — Impacto Colateral
Para resolver um problema de acesso pontual, um administrador remove a role Owner de um grupo de segurança chamado sg-platform-admins no escopo da assinatura e a substitui pela role Contributor no mesmo escopo. A ação resolve o problema imediato reportado.
Qual consequência secundária essa mudança pode causar?
A) Os membros do grupo perdem a capacidade de visualizar recursos na assinatura, pois Contributor não inclui permissões de leitura
B) Os membros do grupo perdem a capacidade de criar novas atribuições de role e de aplicar políticas de acesso na assinatura
C) A mudança invalida automaticamente todos os tokens de sessão ativos dos membros do grupo, forçando re-autenticação imediata
D) Os membros do grupo perdem acesso aos recursos criados antes da mudança, mas mantêm acesso aos recursos criados após a nova atribuição
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva no enunciado é a menção à migração para um novo Management Group três dias antes do problema surgir. Essa operação é o único evento que pode ter introduzido um deny assignment herdado de políticas ou configurações aplicadas no nível do Management Group, bloqueando ações específicas mesmo com a role Contributor corretamente atribuída no resource group.
O comando az role assignment list confirma que a role Contributor existe e está no escopo correto. O erro de autorização, portanto, não é causado por ausência de permissão concedida, mas por uma permissão explicitamente negada sobreposta. Deny assignments têm precedência sobre qualquer role concedida, independente do escopo.
A informação sobre a conta ter sido criada há seis meses e nunca desativada é irrelevante: o problema não é de autenticação, mas de autorização. A alternativa C usa essa informação irrelevante como isca.
A alternativa A é factualmente incorreta: Microsoft.Web/sites/write está incluída na role Contributor. A alternativa D representa um equívoco clássico sobre herança de escopo: atribuições em escopos pai propagam-se para escopos filhos, não o inverso. O distrator mais perigoso é C, pois leva o administrador a reiniciar a sessão do usuário sem resolver nada, desperdiçando tempo em produção.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é o processo de segurança que exige registro via ticket antes da atribuição. Mesmo que o ambiente seja de desenvolvimento e o impacto seja baixo, a política organizacional não faz exceção por criticidade de ambiente. A ação correta é abrir o ticket e aguardar, pois agir antes do registro viola um controle de governança estabelecido.
A alternativa A ignora a restrição de governança apoiando-se na justificativa de baixo impacto, o que é um erro de raciocínio comum: restrições de processo existem independentemente do risco técnico percebido. A alternativa B representa uma ação válida em alguns contextos, mas o enunciado não descreve uma emergência que justifique exceção formal, e escalar sem abrir o ticket também não resolve o registro obrigatório. A alternativa D é o distrator mais perigoso: além de violar o processo, ainda eleva o privilégio além do necessário, substituindo Contributor por Owner sem justificativa técnica.
Gabarito — Cenário 3
Resposta: B
A pista decisiva está na saída do segundo comando, executado com o flag --include-groups. Ele revela que o grupo sg-platform-team, do qual o usuário faz parte, possui a role Contributor na assinatura. A consulta inicial, sem esse flag, retornou apenas atribuições diretas ao usuário, ocultando permissões herdadas via grupo.
O comportamento é completamente esperado pelo modelo de RBAC do Azure: permissões são aditivas e incluem atribuições diretas e indiretas via grupo. O administrador que abriu o chamado cometeu o erro diagnóstico de consultar apenas atribuições diretas.
A informação sobre a licença Microsoft Entra ID P2 é irrelevante para permissões de plano de controle de recursos: P2 habilita recursos como PIM e Identity Protection, mas não expande permissões de role automaticamente. A alternativa C usa essa informação como distração. A alternativa A é factualmente incorreta sobre o escopo da User Access Administrator. A alternativa D seria plausível, mas o enunciado não apresenta nenhuma evidência de custom role, e o diagnóstico deve seguir a evidência disponível antes de especular.
Gabarito — Cenário 4
Resposta: B
A diferença fundamental entre Owner e Contributor é que Owner inclui Microsoft.Authorization/*/write, que permite criar e gerenciar atribuições de role, e permissões para aplicar Azure Policy. Ao substituir Owner por Contributor, todos os membros do grupo perdem essa capacidade imediatamente, o que pode impedir que eles gerenciem acessos futuros na assinatura, criem novos deny assignments ou deleguem permissões a outros usuários e service principals.
A alternativa A é incorreta: Contributor inclui todas as permissões de Reader como subconjunto, portanto a leitura não é afetada. A alternativa C é incorreta porque mudanças em atribuições de role não invalidam tokens de sessão ativos: as permissões são reavaliadas a cada chamada de API, mas sessões existentes não são encerradas forçosamente. A alternativa D representa uma confusão entre RBAC e propriedade de recurso: o RBAC do Azure não vincula acesso ao momento de criação do recurso; as permissões se aplicam uniformemente a todos os recursos no escopo, independentemente de quando foram criados.
Árvore de Troubleshooting: Manage Built-in Azure Roles
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | 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 de autorização negada. Siga cada pergunta respondendo com base no que você consegue observar diretamente no ambiente: execute os comandos indicados nos nós de verificação antes de assumir uma causa. Resista à tentação de pular para uma causa antes de percorrer os nós de diagnóstico na sequência, pois a causa mais óbvia frequentemente não é a causa real quando há deny assignments ou herança de grupo envolvidos.