Arquitetura de governança do Azure: hierarquia, assinaturas, grupos, tags, Policy, RBAC e zonas de destino
Projete governança aplicável entre grupos de gerenciamento, assinaturas, grupos de recursos, identidade, políticas, metadados, conformidade e zonas de destino por código.
Tempo de estudo sugerido: 75 minutos • Nível intermediário • Reescrita autoral completa com resumo conciso de cada tópico
Por João Ricardo Dutra••Conteúdo autoral completo
1. Governança transforma padrões em controle aplicável
Governança estabelece regras e políticas, atribui responsabilidades e verifica a aplicação. Ela mantém aplicativos e recursos alinhados a requisitos setoriais, como gestão da segurança da informação, e a padrões corporativos, como criptografia de rede. É especialmente valiosa com várias equipes, assinaturas, obrigações regulatórias ou padrões comuns.
A arquitetura deve levantar requisitos, priorizar iniciativas, construir a hierarquia e posicionar cada controle no escopo adequado. O capítulo aborda grupos de gerenciamento, assinaturas, grupos de recursos, tags, , do e zonas de destino.
Resumo do tópico
Governança converte requisitos em regras atribuídas, aplicáveis e mensuráveis em toda a propriedade de nuvem.
2. Use a hierarquia para controlar em escala
A governança do normalmente usa quatro escopos: grupos de gerenciamento, assinaturas, grupos de recursos e recursos. Controles superiores podem ser herdados. Requisitos amplos devem ficar altos o suficiente para evitar duplicação, enquanto regras específicas permanecem próximas da carga.
O escopo determina a herança: proteções da plataforma ficam acima e controles específicos ficam abaixo.
Resumo do tópico
A hierarquia oferece escopos progressivamente menores para acesso, política, conformidade, cobrança e ciclo de vida.
3. Entenda o grupo raiz do locatário
Todos os grupos de gerenciamento e assinaturas pertencem a uma hierarquia de diretório. O grupo raiz do locatário permite e atribuições de função em todo o diretório. Como o alcance é extremo, use-o apenas para controles universais cuidadosamente revisados.
Resumo do tópico
O grupo raiz governa toda a hierarquia e deve receber somente controles universais e bem revisados.
4. Grupos de gerenciamento governam várias assinaturas
Grupos de gerenciamento criam um escopo acima das assinaturas para acesso, política e conformidade. Eles agregam definições e iniciativas, limitam regiões de VMs, concedem acesso herdado e facilitam auditoria. A árvore aceita até seis níveis abaixo da raiz, sem contar raiz e assinatura; cada filho tem um pai e novas assinaturas começam sob a raiz.
Resumo do tópico
Grupos de gerenciamento criam uma fronteira corporativa acima das assinaturas e simplificam herança de políticas e acesso.
5. Mantenha uma hierarquia proposital
Projete segundo necessidades de governança, sem copiar cada linha do organograma. Uma estrutura relativamente plana, normalmente com três ou quatro níveis significativos, é mais operável. Use um escopo superior para controles comuns e separe departamentos, geografias, ambientes ou cargas reguladas somente quando exigirem regras distintas.
A hierarquia expressa diferenças duradouras de governança, não projetos temporários.
Resumo do tópico
Um ramo se justifica quando seus descendentes compartilham requisitos permanentes de política, conformidade, conectividade ou acesso.
6. Considere produção, sandbox e dados sensíveis
Crie um ramo de produção para controles comuns aos produtos.
Ofereça sandbox isolado de desenvolvimento, teste e produção.
Use geografia apenas quando a conformidade regional realmente diferir.
Separe cargas sensíveis que precisem de controles reforçados.
Evite ramos profundos ou vazios sem valor de governança.
Resumo do tópico
Produção, sandbox, geografia e dados sensíveis são padrões úteis quando representam requisitos materialmente diferentes.
7. Assinaturas são unidades de gerenciamento, escala e cobrança
Uma assinatura do é o contêiner lógico para criar e pagar serviços. Contrato Enterprise, Pagamento Conforme o Uso e outras ofertas variam comercialmente, mas toda assinatura estabelece limites de cobrança, gerenciamento, cotas e escala. Assinaturas distintas isolam ambientes ou cargas especializadas e esclarecem custos.
Resumo do tópico
A assinatura reúne fronteira de cobrança, administração, política, cota e escala.
8. Alinhe assinaturas ao negócio e à governança
Trate assinaturas como unidades democratizadas de gerenciamento alinhadas às prioridades. Coloque assinaturas com as mesmas políticas e funções sob um grupo comum. Não crie um grupo de gerenciamento apenas para poucas assinaturas quando uma política no escopo da assinatura oferece o isolamento necessário.
Resumo do tópico
O posicionamento das assinaturas segue governança compartilhada e responsabilidade de negócio.
9. Projete assinaturas de serviços compartilhados e grande escala
Uma assinatura de serviços compartilhados pode isolar conectividade e rateio, incluindo e . HPC, , SAP ou plataformas intensivas em integração podem precisar de assinaturas próprias para evitar cotas e acoplamento. Consulte sempre os limites atuais dos serviços.
Assinaturas separam cobrança, administração, política, cotas e raio de impacto; grupos fornecem proteções comuns.
Resumo do tópico
Dedique uma assinatura quando serviços comuns, escala, cotas, administração ou propriedade de custos exigirem fronteira própria.
10. Revise administração e acesso privilegiado
A assinatura separa administradores e responsabilidades. Oriente os proprietários e revise privilégios trimestral ou semestralmente com o e revisões de acesso. Prefira elevação elegível e temporária a privilégio permanente.
Resumo do tópico
Administrar assinaturas exige proprietários explícitos, separação de funções, revisões e elevação controlada.
11. Avalie política e topologia de rede antes de dividir
Grupos e assinaturas são limites de atribuição do . Uma carga PCI pode ser isolada por assinatura sem criar outro ramo. Redes virtuais pertencem a assinaturas, mas comunicam-se por emparelhamento, de , ou padrões aprovados. Mapeie a comunicação antes de definir limites.
Resumo do tópico
O desenho de assinaturas precisa considerar isolamento de política e conectividade entre assinaturas, além da cobrança.
12. Grupos de recursos alinham ciclo de vida e controle
Um grupo de recursos é o contêiner lógico em que recursos são implantados e gerenciados. Pode organizar por aplicativo, ciclo, tipo, localização, departamento ou centro de custo; servir de escopo para e ; e receber bloqueios contra exclusão ou alteração acidental.
Resumo do tópico
Grupos de recursos são contêineres de ciclo de vida e gerenciamento, não apenas pastas visuais.
13. Conheça as restrições dos grupos de recursos
O grupo possui uma região para seus , embora os recursos possam estar em outras regiões.
Se a região de ficar indisponível, os recursos continuam funcionando, mas atualizações podem ser bloqueadas.
Recursos comunicam-se entre grupos e muitos podem ser movidos, conforme limitações do serviço.
Grupos não podem ser aninhados nem renomeados.
Cada recurso pertence a exatamente um grupo por vez.
Resumo do tópico
A região afeta o plano de gerenciamento, e o modelo sem aninhamento torna o planejamento do ciclo de vida importante.
14. Escolha uma estratégia de organização
Agrupe por aplicativo quando os recursos compartilham ciclo, política e propriedade. Agrupe por tipo para serviços compartilhados ou sob demanda. Departamento, região, cobrança e ambiente também podem ajudar, mas uma combinação costuma atender melhor a propriedades reais.
O melhor desenho reúne recursos implantados, atualizados, protegidos e desativados juntos.
Resumo do tópico
A melhor fronteira acompanha ciclo de vida, administração, política e propriedade comuns.
15. Equilibre ciclo, sobrecarga, acesso e conformidade
Reúna recursos criados, atualizados e excluídos em conjunto. Estime a sobrecarga da quantidade de grupos e o modelo de administração. Aplique funções, políticas e bloqueios no grupo e escolha a região dos conforme conformidade e resiliência do plano de gerenciamento.
Resumo do tópico
O desenho equilibra coordenação de ciclo, sobrecarga, controle de acesso, bloqueios e conformidade.
16. Tags adicionam operacionais e de negócio
Uma tag é um par nome-valor, como env=production. Ela pode ser atribuída a recursos, grupos e assinaturas com , CLI do , modelos do , ou portal. Tags do grupo não são herdadas automaticamente; a herança deve vir da implantação ou do .
Resumo do tópico
Tags tornam recursos pesquisáveis e automatizáveis, mas não há herança automática a partir do grupo.
17. Comece com objetivo e taxonomia definidos
Defina se as tags apoiarão busca, automação, custos, confidencialidade, propriedade ou relatórios. Alinhe chaves e valores ao vocabulário organizacional. Tags de TI descrevem carga, aplicativo, camada e ambiente; tags de negócio expressam propriedade, custo, criticidade, receita e valor.
Resumo do tópico
Uma taxonomia útil começa por resultados mensuráveis, vocabulário aceito e contexto técnico e empresarial.
18. Use cinco categorias complementares
Categorias comuns de tags.
Categoria
Finalidade
Exemplos
Funcional
Finalidade na carga
app, tier, webserver, env
Classificação
Uso e proteção esperada
confidentiality,
Contabilidade
Cobrança e associação organizacional
department, program, region
Parceria
Pessoas responsáveis ou afetadas
owner, contactAlias, stakeholders
Propósito
Função e valor para o negócio
businessProcess, businessImpact, revenueImpact
Resumo do tópico
As cinco categorias conectam tecnologia a operação, proteção, propriedade, custo e valor.
19. Implante e imponha tags progressivamente
Prototipe poucas tags críticas, meça o resultado e amplie após ouvir stakeholders. Nem toda tag pertence a todo recurso; Impact pode ser obrigatório apenas para ativos críticos. Use para exigir, adicionar, herdar ou reaplicar tags.
Resumo do tópico
Um conjunto pequeno, testado e governado é mais eficaz do que uma taxonomia extensa e descontrolada.
20. governa o estado dos recursos
cria, atribui e gerencia regras que auditam ou controlam configurações. Definições podem compor iniciativas, atribuições são herdadas e a avaliação alcança e recursos compatíveis habilitados para . Use definições internas e personalizadas.
Os efeitos podem auditar, negar, modificar, implantar recursos relacionados e corrigir recursos existentes. A integração com permite verificações antes e depois da implantação.
Resumo do tópico
avalia e corrige o estado para manter configurações alinhadas às regras, independentemente de quem alterou.
21. Entenda quando a política avalia
A avaliação ocorre quando um recurso no escopo é criado, alterado ou excluído; quando uma atribuição ou iniciativa é criada ou atualizada; e no ciclo regular, geralmente a cada 24 horas. Relatórios podem ter atraso e a operação deve considerá-lo.
Resumo do tópico
Mudanças em recursos e atribuições disparam avaliação, além do ciclo periódico; o painel pode atrasar.
22. Use o painel de conformidade e a correção
O painel agrega a postura e permite detalhar políticas e recursos. Escolha o efeito conforme o risco: negar, auditar, modificar, implantar recursos relacionados ou corrigir. Correções em massa tratam recursos existentes; identidades gerenciadas apoiam tarefas compatíveis.
Resumo do tópico
O painel explica a postura; efeitos e correção transformam achados em prevenção ou ajuste.
23. e resolvem problemas diferentes
Modelos complementares.
Aspecto
do
Pergunta
O estado está em conformidade?
Quem executa quais ações em qual escopo?
Foco
Propriedades e configuração
Autorização e acesso
Implementação
Definições, iniciativas, atribuições e efeitos
Definições e atribuições de função
Padrão
Regras usam o efeito configurado
Acesso negado sem atribuição permissiva
Relação
Pode bloquear resultado incompatível de usuário autorizado
Permite a ação, mas não garante estado compatível
Resumo do tópico
Use para ações e para o estado resultante; arquiteturas maduras combinam ambos.
24. O acesso segue um ciclo de identidade
A identidade começa sem acesso. concede ações, do verifica condições, monitora risco e revisões de acesso confirmam a necessidade. Governe concessão, uso, monitoramento, revisão e remoção.
Resumo do tópico
O ciclo de acesso combina autorização, verificação condicional, detecção de risco, revisão e remoção.
25. do é um modelo de permissão
avalia solicitações com base em atribuições. A definição contém ações; a atribuição liga função a usuário, grupo, ou em um escopo. Leitura não inclui gravação sem permissão explícita.
Resumo do tópico
concede somente ações expressas pela função no escopo; o restante permanece negado.
26. Projete para privilégio mínimo
Defina ações e atribua no maior escopo que não exponha recursos desnecessários.
Conceda o mínimo e separe responsabilidades.
Prefira grupos a usuários individuais.
Dê identidades não humanas aos aplicativos.
Crie funções personalizadas somente quando as internas forem insuficientes.
Resumo do tópico
eficaz minimiza escopo e permissões, usa grupos e fornece identidades próprias a aplicativos.
27. Calcule permissões efetivas sobrepostas
é aditivo: permissões efetivas somam atribuições aplicáveis. Colaborador na assinatura não é reduzido por Leitor em um grupo filho. Analise atribuições herdadas e diretas em conjunto e use negações ou controles privilegiados apenas conforme o comportamento documentado.
Resumo do tópico
Leitor no escopo estreito não subtrai direitos de Colaborador no escopo amplo porque as permissões se somam.
28. Zonas de destino preparam a fundação
Uma zona de destino do é um ambiente de infraestrutura preparado para cargas. Como serviços urbanos instalados antes das casas, identidade, acesso, conectividade, política, gerenciamento e monitoramento precisam estar prontos antes da migração. Grupos e assinaturas permitem escalar.
Resumo do tópico
A zona de destino estabelece capacidades compartilhadas e proteções antes da implantação das cargas.
29. Separe zonas de plataforma e de aplicativo
A zona de plataforma hospeda assinaturas compartilhadas de identidade, conectividade e gerenciamento operadas centralmente. Zonas de aplicativo hospedam cargas e ambientes de desenvolvimento, teste e produção. mantém conformidade enquanto equipes trabalham dentro das proteções.
Serviços compartilhados e autonomia das cargas são separados e conectados por política, rede, identidade e observabilidade.
Resumo do tópico
A zona de plataforma centraliza capacidades; zonas de aplicativos dão espaços governados ao ciclo das cargas.
30. Implante zonas por código e evolua
Pré-provisione com infraestrutura como código. O acelerador IaC de zonas de destino usa ou Terraform por meio de Verified Modules; há alternativa pelo portal para organizações sem experiência em IaC. Trate o código como produto versionado e evolutivo.
Projete para migração e desenvolvimento do zero, prefira serviços nativos quando adequados e foque resultados de aplicativos. Propriedades existentes podem implantar o acelerador em paralelo no mesmo locatário e migrar progressivamente. Faça uma revisão de zona de destino para identificar investimentos.
Resumo do tópico
Zonas de destino são produtos de plataforma versionados, implantados por código e preparados para migração e desenvolvimento novo.
31. Aplique o cenário de governança
Decisões do cenário Tailwind Traders.
Requisito
Controle recomendado
Motivo
Política uniforme de VMs
Grupo de gerenciamento com
A herança padroniza assinaturas
com redundância geográfica
exigindo redundância aprovada
Tags e grupos não configuram redundância
Custos do produto entre departamentos
Tag consistente de produto ou custo
Permite agrupar custos entre escopos
ISO 27001
Hierarquia, iniciativas, atribuições, modelos, evidências e responsáveis
Conformidade combina controles técnicos e processuais
Resumo do tópico
A avaliação testa o escopo: grupos para várias assinaturas, Policy para configuração e tags para custos entre fronteiras.
32. Checklist final e recursos
Mapeie normas a responsáveis, escopos, controles, evidências e cadência.
Mantenha grupos estáveis e alinhe assinaturas a cobrança, administração, escala e política.
Agrupe por ciclo e use bloqueios quando mudanças acidentais forem perigosas.
Controle a taxonomia de tags para propriedade, valor, custo, automação e classificação.
Combine e , monitore conformidade e revise privilégios.
Implante zonas de plataforma e aplicativo por código e melhore continuamente.
O Microsoft Copilot pode comparar hierarquias, propor taxonomias, explicar Policy versus ou aplicar o Well-Architected a um cenário. Valide recomendações na documentação oficial e nos requisitos.
