Laboratório de Troubleshooting: Interpret Access Assignments
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações reporta que a usuária Beatriz não consegue iniciar máquinas virtuais no grupo de recursos rg-operacoes. O administrador verifica o portal e confirma que Beatriz possui a função Virtual Machine Contributor atribuída diretamente no grupo de recursos rg-operacoes. A assinatura foi criada há três meses e está ativa. Beatriz consegue visualizar os recursos sem problemas e relata que a opção de iniciar a VM aparece na interface, mas retorna erro de autorização ao ser confirmada.
O administrador também nota que Beatriz faz parte do grupo Equipe-Dev, ao qual foi atribuída a função Reader na assinatura. A conta de Beatriz foi criada no Microsoft Entra ID há duas semanas e ela já acessou outros grupos de recursos sem problemas.
Ao tentar iniciar uma VM manualmente via CLI, o seguinte erro é retornado:
(AuthorizationFailed) The client 'beatriz@contoso.com' with object id '...'
does not have authorization to perform action
'Microsoft.Compute/virtualMachines/start/action'
over scope '/subscriptions/.../resourceGroups/rg-operacoes/providers/
Microsoft.Compute/virtualMachines/vm-prod-01'
or the scope is invalid.
Qual é a causa raiz do problema?
A) A função Reader herdada da assinatura via grupo Equipe-Dev está sobrescrevendo a função Virtual Machine Contributor de Beatriz
B) Existe uma deny assignment aplicada sobre o recurso vm-prod-01 ou sobre o grupo de recursos rg-operacoes que bloqueia explicitamente a ação de iniciar VMs
C) A conta de Beatriz é recente demais e o Microsoft Entra ID ainda não propagou as permissões para o plano de controle do Azure
D) A função Virtual Machine Contributor não inclui a ação Microsoft.Compute/virtualMachines/start/action por definição
Cenário 2 — Decisão de Ação
O administrador identificou que um grupo de segurança chamado Equipe-Auditoria possui a função Owner atribuída em escopo de assinatura. Essa atribuição foi feita por engano há seis dias e precisa ser removida. A assinatura está em produção ativa com dezenas de recursos críticos. O time de segurança confirmou que nenhum membro do grupo utilizou as permissões de Owner desde a atribuição incorreta, e isso foi validado nos logs do Microsoft Entra ID.
A remoção precisa ser feita agora, durante o horário comercial, sem janela de manutenção agendada. O administrador possui a função User Access Administrator na assinatura. Não há nenhuma deny assignment protegendo os recursos.
Qual é a ação correta a tomar neste momento?
A) Aguardar uma janela de manutenção para remover a atribuição, pois alterações de RBAC em produção podem causar interrupção de serviços em execução
B) Remover imediatamente a atribuição de função Owner do grupo Equipe-Auditoria no escopo da assinatura usando o portal ou CLI, sem necessidade de janela de manutenção
C) Antes de remover, aplicar uma deny assignment cobrindo todas as ações do grupo Equipe-Auditoria para bloquear o acesso imediatamente, e depois agendar a remoção da atribuição Owner
D) Rebaixar a função do grupo de Owner para Reader como medida provisória e agendar a remoção completa para fora do horário comercial
Cenário 3 — Causa Raiz
O desenvolvedor Carlos relata que não consegue fazer upload de blobs em um Storage Account chamado stgprojeto01. O administrador verifica o painel de Access Control (IAM) do Storage Account e encontra o seguinte estado:
| Principal | Tipo | Função | Escopo |
|---|---|---|---|
| Carlos | Usuário | Storage Blob Data Contributor | stgprojeto01 |
| Equipe-Dev | Grupo | Reader | Assinatura |
Carlos é membro do grupo Equipe-Dev. O Storage Account utiliza redundância LRS e está na região East US. A conta de armazenamento tem o firewall configurado para permitir acesso apenas de redes virtuais específicas, mas Carlos confirma que está operando a partir de uma VM conectada a uma dessas redes autorizadas. O time de rede confirmou que não há NSG bloqueando a porta 443.
Carlos tenta via CLI e recebe:
ERROR: This request is not authorized to perform this operation using
this permission.
RequestId: a3f1...
Time: 2025-10-14T10:23:45.0000000Z
Qual é a causa raiz do problema?
A) A função Reader do grupo Equipe-Dev no escopo da assinatura está impedindo a escrita, pois atribuições de grupo têm precedência sobre atribuições individuais
B) A redundância LRS do Storage Account impede operações de escrita originadas fora da região primária
C) O acesso ao plano de dados do Storage Account está sendo bloqueado pelo firewall da conta de armazenamento, pois a VM de Carlos não pertence a uma das redes virtuais autorizadas
D) A função Storage Blob Data Contributor foi atribuída no escopo do recurso, mas o token de autenticação de Carlos está sendo emitido para o escopo da assinatura, causando incompatibilidade de escopo na autorização do plano de dados
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: "Não consigo excluir um recurso no portal do Azure. Tenho certeza de que possuo permissão para isso."
Os passos de investigação disponíveis estão listados abaixo em ordem aleatória:
- Verificar se existe uma deny assignment aplicada ao recurso, ao grupo de recursos ou à assinatura que cubra a ação de exclusão
- Confirmar qual função está atribuída ao usuário e em qual escopo, usando o painel IAM ou
az role assignment list - Verificar se o recurso possui um lock do tipo
CanNotDeleteouReadOnlyaplicado - Reproduzir o erro e coletar a mensagem exata retornada pelo portal ou CLI
- Verificar se a função atribuída inclui a ação de exclusão específica para o tipo de recurso
Qual é a sequência correta de investigação?
A) 2, 5, 1, 3, 4
B) 4, 2, 5, 3, 1
C) 3, 1, 2, 5, 4
D) 1, 3, 2, 5, 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro retornada pelo CLI indica claramente que o principal não possui autorização para executar a ação, mesmo com a função Virtual Machine Contributor atribuída. O ponto decisivo é que o Azure RBAC é aditivo: a função Reader do grupo Equipe-Dev jamais poderia bloquear permissões concedidas por outra atribuição. Isso elimina diretamente a alternativa A, que representa o equívoco mais comum de supor que roles menos permissivas "ganham" sobre roles mais permissivas.
A pista que confirma a alternativa B é exatamente a contradição entre a atribuição válida e o erro de autorização persistente: quando um usuário possui uma função que claramente cobre a ação solicitada e ainda assim recebe negação, a única explicação possível dentro do modelo RBAC do Azure é a existência de uma deny assignment ativa, que tem precedência absoluta sobre qualquer role assignment.
A informação sobre a conta ter sido criada há duas semanas é propositalmente irrelevante. A propagação de permissões no Microsoft Entra ID e no Azure RBAC ocorre em segundos a poucos minutos, não em semanas, e o próprio enunciado confirma que Beatriz já acessa outros recursos normalmente.
A alternativa D é factualmente incorreta: start/action está incluída na definição da função Virtual Machine Contributor. O distrator mais perigoso é o A, pois leva o administrador a tentar resolver um problema inexistente (conflito entre roles aditivas) enquanto a deny assignment permanece ativa bloqueando o acesso.
Gabarito — Cenário 2
Resposta: B
A causa já está declarada no enunciado: atribuição de Owner por engano. O contexto fornece todas as informações necessárias para a decisão. Remoções de atribuições RBAC não afetam recursos em execução, pois o RBAC controla o plano de controle, não o plano de dados ou o estado operacional de VMs, bancos de dados ou outros serviços. Portanto, não há justificativa técnica para aguardar janela de manutenção, o que elimina a alternativa A.
O administrador possui User Access Administrator, que inclui a permissão Microsoft.Authorization/roleAssignments/delete, suficiente para executar a remoção sem escalonamento. A ação deve ser tomada imediatamente para encerrar a exposição de risco.
A alternativa C representa uma ação tecnicamente válida em outros contextos, mas desnecessariamente complexa aqui: criar uma deny assignment para cobrir temporariamente um Owner introduz um objeto adicional que precisará ser removido depois, aumentando o risco operacional sem nenhum benefício dado que a remoção direta é segura e imediata.
A alternativa D é a mais perigosa: rebaixar para Reader ainda mantém o grupo com acesso legítimo a todos os recursos da assinatura, o que pode não ser aceitável do ponto de vista de segurança, e adia a resolução completa sem necessidade.
Gabarito — Cenário 3
Resposta: C
Carlos possui Storage Blob Data Contributor atribuído diretamente no Storage Account, o que seria suficiente para operações de escrita no plano de dados. O modelo aditivo do RBAC garante que a função Reader do grupo Equipe-Dev não interfere. Isso elimina a alternativa A pelo mesmo princípio do cenário anterior.
A pista crítica está no enunciado: o firewall do Storage Account está configurado para permitir acesso apenas de redes virtuais específicas. A mensagem de erro retornada (This request is not authorized to perform this operation using this permission) é a mensagem padrão do Azure Storage quando uma requisição é bloqueada pelo firewall de rede da conta de armazenamento, e não uma mensagem de RBAC. Erros de RBAC retornam AuthorizationFailed com menção explícita ao principal e à ação, como visto no Cenário 1.
A informação sobre redundância LRS e a confirmação do time de rede sobre NSG são propositalmente irrelevantes. LRS não tem qualquer relação com autorização de escrita, e a ausência de bloqueio NSG na porta 443 não garante que a VM esteja na lista de redes autorizadas no firewall do próprio Storage Account, que é um controle independente.
A alternativa D descreve um comportamento que não existe no Azure: o escopo da atribuição RBAC não afeta a emissão nem a validade do token de autenticação para o plano de dados de Storage.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 4, 2, 5, 3, 1, e a lógica é de diagnóstico progressivo do mais simples para o mais específico.
O primeiro passo é sempre reproduzir e coletar a mensagem exata (passo 4), pois ela já pode revelar se o bloqueio é de RBAC, de lock ou de deny assignment, direcionando todo o restante da investigação.
Em seguida, confirmar a atribuição de função e o escopo (passo 2) valida se o usuário de fato possui alguma role que deveria cobrir a ação. Só depois disso faz sentido verificar se a role inclui a ação de exclusão para o tipo de recurso específico (passo 5), pois funções como Contributor não cobrem todos os tipos de recursos uniformemente.
O passo 3 (verificar locks) vem antes do passo 1 (deny assignments) porque locks são muito mais comuns em ambientes de produção e são verificáveis rapidamente no portal, enquanto deny assignments são menos frequentes e requerem consulta via CLI ou APIs específicas.
A sequência da alternativa A começa pela atribuição antes de coletar o erro, o que é ineficiente. A alternativa C começa pelos locks, que é uma hipótese específica sem evidência inicial. A alternativa D começa pelas deny assignments, que são o mecanismo menos comum e mais custoso de verificar, invertendo a lógica de eliminação por probabilidade.
Árvore de Troubleshooting: Interpret Access Assignments
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigação
- Azul médio: pergunta diagnóstica, nó de decisão
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
- Laranja: validação intermediária ou resultado ambíguo que requer revisão de expectativa
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa no ambiente, não no que você supõe. A primeira bifurcação mais importante é a leitura da mensagem de erro: ela já separa problemas de autorização RBAC de problemas de rede ou plano de dados, economizando toda uma linha de investigação desnecessária. Siga os caminhos até chegar a uma causa identificada e só então execute a ação correspondente.