APRENDER. PRATICAR. EVOLUIR.1. Organizar por necessidade de controlo
Uma hierarquia deve tornar previsível a aplicação de políticas e acessos. Num programa fictício, produção e experimentação têm restrições diferentes, mas as aplicações partilham equipas. Não copies automaticamente o organigrama para management groups: identifica primeiro que conjuntos de subscrições precisam dos mesmos controlos. Uma política ou role assignment num grupo propaga-se aos descendentes. Uma atribuição na raiz merece análise do impacto porque alcança um âmbito muito amplo. Cada subscrição tem um único pai, pelo que uma necessidade de classificação transversal pode exigir tags ou outra vista, sem duplicar a subscrição na árvore. Documenta as razões de cada fronteira: responsabilidade, ciclo de vida, acesso e restrições. A hierarquia não deve mudar apenas porque uma pessoa passou a reportar a outro diretor.
2. Tratar a mudança de pai como uma mudança de controlo
Mover uma subscrição entre management groups pode alterar políticas e acesso herdados. Antes de executar, compara os controlos efetivos na origem e no destino, incluindo quem mantém capacidade de administrar o percurso. No caso fictício, uma equipa só é Owner por herança do grupo anterior. O plano de mudança precisa de verificar as permissões necessárias e a continuidade de administração, sem presumir que a herança antiga acompanha a subscrição. Uma custom role pode ainda depender de um assignable scope que deixa de estar no caminho da hierarquia. A análise deve cobrir essa relação antes da janela. Depois da mudança, verifica resultados efetivos e considera atrasos de atualização das vistas. Um diagrama com o novo pai não prova que todos os consumidores já observam o novo estado. O rollback deve também inventariar efeitos já aplicados aos recursos: repor o pai antigo não demonstra que essas alterações de configuração sejam automaticamente desfeitas.
3. Calcular acesso a partir de todas as concessões
Uma role definition descreve permissões; a atribuição liga principal, papel e âmbito. Disponibilizar uma custom role num assignable scope não a atribui automaticamente a utilizadores. Também não deves tratar NotActions como uma recusa global. Se uma atribuição retira uma ação do seu próprio conjunto, outra atribuição pode continuar a concedê-la. No exercício local, a primeira função permite ler mas exclui eliminar; a segunda permite eliminar. A união ainda contém eliminar. O modelo usa nomes fictícios de ações e uma lista explícita de recusas, sem simular o avaliador Azure. No trabalho real, inventaria atribuições diretas, herdadas e de grupos, condições aplicáveis e o plano de controlo ou de dados. Um teste deve usar a identidade prevista, o recurso certo e a operação relevante.
4. Atribuir custos sem confundir tags e orçamento
Tags ajudam a identificar serviço, owner e centro de custo, mas não são uma fronteira geral de segurança nem são automaticamente herdadas pelos recursos. Se o desenho exige propagação de uma tag do resource group, define o mecanismo e a correção de recursos existentes. Evita segredos e informação pessoal nos valores. Um budget, por sua vez, acompanha custos e dispara notificações; não representa por si só uma ordem de parar todos os recursos ao atingir um euro exato. No projeto fictício, o sponsor quer alerta antecipado e uma decisão humana antes de suspender ambientes. Define quem recebe, que atraso de dados é aceitável e que ações estão autorizadas. Uma automação de paragem deve considerar dependências, continuidade e recuperação, em vez de ser tratada como consequência invisível do valor do budget.
5. Disponibilizar privilégio apenas durante a necessidade
PIM permite distinguir elegibilidade de ativação. Um técnico elegível ainda pode ter de cumprir requisitos de ativação, como justificação, autenticação ou aprovação. A duração da elegibilidade e a duração de cada ativação são decisões diferentes. No exemplo fictício, o fornecedor participa num projeto durante três meses, mas só precisa de administrar um recurso durante mudanças aprovadas. A equipa deve escolher o âmbito mínimo e ensaiar o percurso com a identidade do fornecedor. Não basta registar uma aprovação num ticket e assumir que a operação já está autorizada no Azure. Prepara também responsáveis disponíveis fora de horas e a forma de tratar pedidos recusados ou expirados. O objetivo é permitir a tarefa necessária com exposição limitada e evidência, sem transformar a equipa de aprovação num ponto único de bloqueio. Distingue ainda administração de roles Entra e de roles de recursos Azure. Ser Privileged Role Administrator no diretório não concede por omissão a administração das atribuições Azure de uma subscrição.
6. Fechar revisões com efeitos confirmados
Uma decisão de access review e a sua aplicação ao recurso são etapas distintas. Confirma se os resultados serão aplicados automaticamente ou se existe uma ação manual pendente. Além disso, o tipo de origem condiciona o que pode ser alterado: grupos sincronizados a partir de on-premises exigem tratamento na origem; pertenças dinâmicas dependem de regras; caminhos por grupos aninhados podem manter acesso. No caso fictício, um consultor foi recusado numa revisão, mas continua a entrar por outra atribuição. O relatório deve separar decisão tomada, aplicação concluída e acesso residual identificado. Define o owner da correção, o prazo e a evidência de resultado. Não declares revogação total a partir de uma linha marcada como recusada se os restantes caminhos ainda não foram avaliados.
7. Agrupar acesso de projeto com ciclo de vida
Entitlement management permite organizar recursos num access package com políticas de pedido, aprovação e duração. Num projeto internacional fictício, a equipa externa precisa de um grupo, uma aplicação e um espaço de colaboração. O pacote torna explícito o conjunto aprovado, mas não deve incluir acesso amplo só porque seria conveniente noutro projeto. Define quem pode pedir, quem aprova, quando termina e como se revê a necessidade. Quando uma atribuição expira, verifica também concessões feitas fora do pacote: uma autorização direta pode continuar a existir. A remoção de um pacote não é prova universal de eliminação da identidade externa. O handover deve mostrar o inventário de recursos, owners e caminhos alternativos, para que a saída do fornecedor não dependa de memória individual ou de uma lista de emails. A delegação por catálogo tem limites: um criador não administrador não passa a possuir recursos de outras equipas apenas por criar o catálogo.
8. Preparar acesso de emergência sem normalizar o seu uso
O acesso de emergência deve continuar utilizável quando falham as dependências normais de administração. As recomendações atuais incluem contas cloud-only, autenticação resistente a phishing, proteção das credenciais, monitorização e ensaios regulares. Não transformes a exceção de Conditional Access numa recomendação para retirar autenticação forte: a conta continua a precisar de proteção apropriada. No cenário fictício, a equipa descobre que todos os administradores dependem de aprovação e do mesmo serviço indisponível. Um percurso previamente preparado evita improvisar concessões excessivas durante o incidente. Depois de cada uso, revê autorização, ações e necessidade de correções. A evidência final desta aula é uma matriz que distingue acesso permanente, elegível, ativo, de projeto e de emergência, com owners e formas de provar a retirada quando termina a necessidade.
def granted(assignments, denied=()):
# Explicit fictional action sets only; not Azure RBAC evaluation.
allowed = set()
for actions, excluded in assignments:
allowed |= set(actions) - set(excluded)
return allowed - set(denied)
limited = ({"read", "delete"}, {"delete"})
extra = ({"delete"}, set())
assert granted([limited]) == {"read"}
assert granted([limited, extra]) == {"read", "delete"}
assert granted([limited, extra], {"delete"}) == {"read"}
assert granted([]) == set()
assert granted([extra, limited]) == granted([limited, extra])
assert granted([limited, limited]) == {"read"}
print("six fictional grant-set checks passed; no Azure authorization evaluated")
Caso fictício: uma subscrição muda de grupo para uniformizar políticas, mas a equipa de RUN perde uma atribuição herdada. A mudança é aceite apenas depois de validar o novo acesso mínimo, os controlos aplicados e a responsabilidade de suporte.
Armadilhas comuns
Tratar NotActions como deny global; confundir elegibilidade com ativação; contar uma revisão concluída como revogação efetiva; usar tags ou budgets como fronteiras de controlo que não fornecem.
Tópicos relacionados: Azure Policy e RBAC · Entrada e saída de fornecedores · FinOps e responsabilidade
Governance é verificável quando cada concessão, herança e exceção tem âmbito, duração, responsável e evidência do efeito real.
Referência: What are Azure management groups? · AZ-305 objectives 2026-04-17