Landing zone e organização de contas

Landing zone é a estrutura pronta onde novos ambientes “aterrissam”: contas organizadas, identidade federada, rede planejada, log centralizado, guardrails ligados e um caminho automatizado para criar mais. Sem ela, cada time resolve tudo de novo, do seu jeito, e a padronização vira projeto de arqueologia dois anos depois.

Não precisa ser grandiosa. Uma landing zone mínima e viável no primeiro mês vale mais que um desenho perfeito que nunca sai do papel.

Por que uma conta só não escala

Tudo em uma conta parece simples até o primeiro problema real:

• Raio de alcance. Uma permissão errada afeta produção e desenvolvimento juntos.
• Cota. Limites são por conta ou assinatura; o teste de carga do time A trava o provisionamento do time B.
• Custo. Sem separação, atribuir gasto depende de disciplina perfeita de tags.
• Permissão. Fica impossível dar acesso amplo em desenvolvimento e restrito em produção.
• Auditoria. “Quem pode mexer em produção?” não tem resposta simples.

A separação é a fronteira mais barata que existe — e a única que continua valendo quando alguém erra.

Estrutura por ambiente e domínio

Organização
├── Segurança
│   ├── log-arquivo        (destino imutável de todos os logs de auditoria)
│   └── seguranca-tooling  (ferramentas, acesso somente leitura ao resto)
├── Infraestrutura
│   ├── rede-compartilhada (hub de conectividade, DNS)
│   └── pipelines          (identidades de CI, artefatos)
├── Produção
│   ├── loja-prod
│   └── dados-prod
└── Não produção
    ├── loja-dev
    └── sandbox-<pessoa>   (limite de gasto, expira sozinha)

Os nomes mudam por provedor — conta (AWS), assinatura (Azure), projeto (GCP) — a lógica é a mesma. Comece com o eixo ambiente, e só depois divida por domínio quando houver times suficientes para justificar.

O ambiente de sandbox por pessoa, com orçamento e expiração, é o que evita que experimentos apareçam em produção. É barato e resolve um problema cultural.

Guardrails: o que ninguém pode fazer

Guardrail é política preventiva no nível da organização — vale mesmo para quem tem administrador na conta filha.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SomenteRegioesPermitidas",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "route53:*", "cloudfront:*", "support:*"],
      "Resource": "*",
      "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["sa-east-1", "us-east-1"] } }
    },
    {
      "Sid": "NaoDesligarAuditoria",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "config:DeleteConfigRule"],
      "Resource": "*"
    }
  ]
}

O conjunto inicial que resolve a maior parte do risco, em qualquer nuvem:

1. Restringir regiões (limita custo, superfície e transferência internacional).
2. Impedir desligar log de auditoria e alterar seu destino.
3. Negar armazenamento com acesso público.
4. Exigir tags de dono e centro de custo.
5. Proibir credencial estática de longa duração.
6. Impedir remover as próprias proteções (papel de emergência à parte).

Guardrails são chatos por definição — por isso precisam vir com caminho de exceção com dono e prazo, e com um papel de emergência (break-glass), auditado e alertado quando usado.

Baseline: o que toda conta nova já nasce tendo

• Identidade: SSO federado, MFA obrigatório, sem usuário local.
• Log: auditoria em todas as regiões, enviada para a conta de log, com escrita apenas em anexação e retenção definida.
• Rede: VPC padrão do provedor removida, VPC criada a partir do bloco reservado, Flow Logs ativos.
• Segurança: detector de ameaça e postura ligados (GuardDuty/Security Hub, Defender for Cloud, Security Command Center); criptografia em repouso por padrão.
• Backup: política de backup e retenção nos serviços com estado.
• Custo: orçamento com alerta e tags obrigatórias.
• Acesso de emergência: papel break-glass documentado e monitorado.

Escreva essa baseline como código — uma pasta de módulos aplicada a cada conta nova — não como uma lista de tarefas em um wiki.

Provisionando uma conta nova

O objetivo é transformar dias de trabalho manual em um pull request:

module "conta_loja_prod" {
  source = "git::https://github.com/empresa/tf-landing-zone.git//conta?ref=v3.1.0"

  nome            = "loja-prod"
  ambiente        = "prod"
  unidade         = "producao"
  dono            = "time-loja"
  centro_de_custo = "CC-4821"
  orcamento_mensal_brl = 25000
}

O módulo cria a conta, aplica os guardrails da unidade, provisiona a baseline, conecta a rede ao hub, registra o log e cadastra o orçamento. Ferramentas próprias do provedor (Control Tower, Landing Zone Accelerator, Terraform Landing Zone) fazem parte disso; a decisão de usá-las ou montar com módulos depende de quanto você quer customizar.

Migrando quem já está bagunçado

Se você já tem uma conta única com tudo dentro, a ordem que funciona: crie a organização e mova a conta existente para dentro dela (sem quebrar nada); crie contas novas para ambientes novos; aplique guardrails em modo auditoria e meça; migre por domínio, começando pelo menos crítico; e só então ligue o bloqueio.

Não tente mover tudo de uma vez. Landing zone é infraestrutura viva — ela melhora por versão, como qualquer módulo.

Próximo passo: você fechou a trilha de Nuvem. Automatize a criação disso tudo com Testando infraestrutura e controle o gasto com FinOps.