Governança no Azure: regras que valem para todas as assinaturas, de uma vez

Como usar Management Groups, Azure Policy, RBAC, Microsoft Entra ID, tags e Cost Management para manter o Azure seguro, organizado e com custo explicável, seguindo o Cloud Adoption Framework.

6 min de leitura

O Azure costuma começar com uma assinatura e uma equipe pequena, e nesse tamanho o combinado verbal funciona. Depois chegam novas assinaturas, novos projetos, fornecedores com acesso, ambientes de teste. Em algum momento alguém pergunta por que existe uma máquina numa região que ninguém escolheu, ou de quem é aquele custo que dobrou, e a resposta exige uma investigação.

Governança é o que transforma esse combinado em regra aplicada pela própria plataforma. Você define uma vez, no lugar certo da hierarquia, e todas as assinaturas abaixo seguem. Este guia mostra as peças que a Microsoft oferece para isso e como elas se encaixam.

Resumo rápido

• Management Groups criam uma hierarquia acima das assinaturas; políticas e permissões aplicadas num grupo são herdadas por tudo o que está abaixo.
• Azure Policy impede ou corrige recursos fora do padrão, como regiões não autorizadas ou recursos sem as tags obrigatórias.
• Microsoft Entra ID e Azure RBAC definem quem pode fazer o quê; o MFA já é obrigatório para gerenciar recursos no Azure.
• Tags e Microsoft Cost Management mostram onde o dinheiro vai, e o Cloud Adoption Framework oferece a arquitetura de referência (Azure landing zone) para juntar tudo.

A hierarquia: Management Groups

Os Management Groups são uma camada de governança acima das assinaturas. Tudo o que você aplica num grupo, seja uma política ou uma atribuição de função, é herdado pelos grupos, assinaturas, resource groups e recursos abaixo dele.

Alguns fatos que ajudam a planejar, segundo a documentação da Microsoft:

• Cada diretório tem um único grupo no topo, o Tenant root group, cujo ID é o mesmo do tenant do Microsoft Entra ID. Novas assinaturas caem nele por padrão.
• A árvore aceita até seis níveis de profundidade, sem contar a raiz e o nível das assinaturas.
• Cada assinatura ou grupo tem um único pai.

A própria Microsoft recomenda cuidado com o que se aplica na raiz, porque vale para todo o diretório. Ali entram apenas as regras que realmente devem valer para tudo.

A arquitetura de referência: Azure landing zone

O Cloud Adoption Framework (CAF) da Microsoft descreve uma arquitetura de referência chamada Azure landing zone, com duas partes:

• Platform landing zone: a base centralizada, com a hierarquia de Management Groups e os recursos compartilhados, como conectividade, identidade, segurança e gerenciamento.
• Workload landing zones: os ambientes onde cada carga de trabalho roda, com desenvolvimento, teste e produção, dentro das regras definidas pela plataforma.

Na hierarquia de referência, as assinaturas das cargas de trabalho ficam sob um grupo de landing zones, separadas por perfil (por exemplo, cargas internas e cargas expostas à internet), além de grupos para sandbox e para assinaturas em desativação. Você não precisa copiar o modelo ao pé da letra: ele é um ponto de partida testado, e a Microsoft oferece aceleradores em infraestrutura como código para implantá-lo.

As regras: Azure Policy

Pedir para ninguém criar recurso fora do padrão depende de memória e boa vontade. Com o Azure Policy, a plataforma avalia cada criação ou alteração e aplica o efeito definido. Entre os efeitos disponíveis:

• deny: bloqueia a criação do recurso fora do padrão. Exemplo clássico: a política interna Allowed locations, que restringe as regiões permitidas.
• audit: permite, mas registra o recurso como não conforme, útil para medir antes de bloquear.
• modify e append: ajustam o recurso na criação, por exemplo adicionando uma tag.
• deployIfNotExists: implanta uma configuração que está faltando, como o envio de logs para um workspace.

Quando várias políticas atingem o mesmo recurso, o resultado é cumulativo e prevalece a mais restritiva. Um caminho seguro é começar em audit, entender o impacto e só depois passar para deny.

Se o seu ambiente ainda usa Azure Blueprints, vale planejar a migração: a Microsoft anunciou a aposentadoria do serviço em 31 de janeiro de 2027, com retirada gradual a partir de 31 de julho de 2026, e recomenda migrar para Deployment Stacks e Template Specs.

Os acessos: Microsoft Entra ID e Azure RBAC

A identidade do Azure é o Microsoft Entra ID (antigo Azure AD). Sobre ela, o Azure RBAC define papéis em escopos: uma função atribuída num Management Group vale para todas as assinaturas abaixo, o que evita repetir a mesma atribuição assinatura por assinatura.

Sobre autenticação multifator, um ponto importante: a Microsoft tornou o MFA obrigatório para entrar no portal do Azure, e desde 1º de outubro de 2025 a exigência começou a ser aplicada também a Azure CLI, Azure PowerShell, ferramentas de infraestrutura como código e API REST para operações de criação, alteração e exclusão. Identidades de carga de trabalho, como managed identities e service principals, não são afetadas, e a recomendação é migrar automações que usam contas de usuário para elas. O controle fino do MFA continua no Microsoft Entra ID, com Acesso Condicional (Microsoft Entra ID P1 ou P2) ou, sem essa licença, com os padrões de segurança.

O custo: tags e Microsoft Cost Management

Sem atribuição, custo vira discussão. Dois cuidados resolvem boa parte disso:

Tags. Pares chave e valor como centro de custo, aplicação e ambiente. Um detalhe que surpreende: os recursos não herdam as tags do resource group nem da assinatura. Para garantir a tag em todo recurso, use as políticas de tag do Azure Policy, que podem exigir a tag ou copiá-la do resource group. E não coloque informação sensível em tags, porque elas são armazenadas em texto simples e aparecem em relatórios de custo.

Budgets no Microsoft Cost Management. Você define orçamentos por Management Group, assinatura ou resource group, com alertas sobre o custo real e o previsto. O orçamento avisa, mas não desliga recursos. Para automatizar uma reação, nos escopos de assinatura e resource group o orçamento pode acionar um action group.

Um roteiro para começar

1. Desenhe a hierarquia de Management Groups a partir do modelo de Azure landing zone, adaptado ao seu tamanho.
2. Defina as poucas regras que valem para tudo, como regiões permitidas e tags obrigatórias, e aplique primeiro em modo audit.
3. Revise as atribuições de RBAC e passe a atribuir no nível de grupo, não recurso a recurso.
4. Confirme que o MFA está configurado no Microsoft Entra ID e que nenhuma automação depende de conta de usuário.
5. Crie orçamentos com alertas por área e acompanhe o custo por tag todo mês.

Onde a Lavineda entra

A Lavineda opera ambientes Azure no Cloud Care, com governança, segurança e custo acompanhados pela mesma equipe. Quando a sua equipe já tem o ambiente sob controle, entramos como apoio para revisar a estrutura e propor melhorias. Mais detalhes sobre a plataforma em Azure.

Fontes

• Microsoft Learn: Organize your resources with management groups
• Microsoft Learn: What is an Azure landing zone? (Cloud Adoption Framework)
• Microsoft Learn: Azure Policy definitions effect basics
• Azure Policy (GitHub oficial da Microsoft): definição interna Allowed locations
• Microsoft Learn: Assign policy definitions for tag compliance
• Microsoft Learn: Overview of Azure Blueprints (aviso de aposentadoria)
• Microsoft Learn: Plan for mandatory Microsoft Entra multifactor authentication
• Microsoft Learn: Use tags to organize your Azure resources and management hierarchy
• Microsoft Learn: Create and manage budgets (Microsoft Cost Management)

O próximo passo

Toda nuvem que cresce precisa, em algum momento, de regras que se apliquem sozinhas. Numa conversa de diagnóstico gratuita, olhamos com você como as assinaturas estão organizadas, quem tem acesso a quê e como o custo é atribuído, e você sai com um feedback honesto e os próximos passos claros, sem compromisso.