Revisão Azure Well-Architected

Este fluxo de trabalho realiza uma revisão estruturada do Azure Well-Architected Framework (WAF) nos arquivos de IaC da sua carga de trabalho e na infraestrutura implantada. Ele identifica riscos em todos os 5 pilares do WAF e cria problemas no GitHub para rastrear a remediação.

Pré-requisitos

• Azure CLI (az) configurado e autenticado
• Arquivos de IaC presentes no repositório (Bicep, Terraform ou modelos ARM)
• Servidor GitHub MCP configurado e autenticado

Etapas do Fluxo de Trabalho

Etapa 1: Carregar Referência do Well-Architected Framework

Busque as melhores práticas atuais do Azure WAF:

• https://learn.microsoft.com/en-us/azure/well-architected/
• Guias de serviço para os serviços Azure em uso (https://learn.microsoft.com/en-us/azure/well-architected/service-guides/)
• Orientação específica da carga de trabalho relevante para o tipo de carga de trabalho (SaaS, missão crítica, IA, etc.)

Se o servidor MCP microsoft.docs.mcp estiver disponível, use-o para consultar as listas de verificação de pilares mais recentes e recomendações específicas de serviço.

Etapa 2: Descobrir IaC e Arquitetura

Estabeleça o escopo da revisão e, em seguida, inventarie o código e o ambiente ativo:

1. Confirmar o escopo do Azure: Pergunte ao usuário quais assinaturas/grupos de recursos estão no escopo, ou infira-os dos parâmetros de IaC e confirme.
2. Verificar o repositório em busca de arquivos de IaC:
   • Bicep: **/*.bicep, bicepconfig.json
   • Terraform: **/*.tf (provedores azurerm/azapi)
   • Modelos ARM: **/azuredeploy*.json, **/*.template.json, arquivos com $schema contendo deploymentTemplate
3. Inventariar recursos ativos (sempre, mesmo quando o IaC existir): az resource list --resource-group <rg> --output json (ou em toda a assinatura), mais chamadas direcionadas de az <service> show para detalhes de configuração que as verificações de pilar precisam.
4. Comparar IaC com inventário ativo: Sinalizar desvios — recursos presentes no Azure, mas ausentes do IaC (criados pelo portal), recursos definidos no IaC, mas não implantados, e incompatibilidades de configuração. Registre as descobertas de desvio para a Etapa 3 (geralmente mapeiam para o pilar de Excelência Operacional).

Identifique os principais serviços Azure em uso (computação, dados, rede, segurança, observabilidade) e gere um diagrama de arquitetura Mermaid.

Etapa 3: Revisão Pilar por Pilar

Pilar 1: Confiabilidade

• Zonas de disponibilidade habilitadas para serviços zonais (VMs, VMSS, pools de nós AKS, Serviço de Aplicativo, SQL, Armazenamento ZRS)
• SKUs de produção suportam o SLA necessário (sem níveis Básico/Gratuito em caminhos críticos)
• Backup do Azure SQL / Cosmos DB e restauração ponto a ponto configurados com retenção apropriada
• Geo-redundância configurada onde o RPO a exige (armazenamento GRS/RA-GRS, grupos de failover SQL, multi-região do Cosmos DB)
• Regras de escala automática configuradas para planos do Serviço de Aplicativo, VMSS, AKS (sem instância única fixa para produção)
• Sondagens de integridade configuradas em back-ends do Balanceador de Carga / Gateway de Aplicativo / Front Door
• Dead-lettering habilitado para filas/assinaturas do Barramento de Serviço e assinaturas do Grade de Eventos
• Políticas de repetição com backoff exponencial implementadas para tratamento de falhas transitórias
• Plano de recuperação de desastres definido (RTO/RPO documentados, failover testado)

Pilar 2: Segurança

• Identidades gerenciadas usadas em vez de entidades de serviço com segredos ou cadeias de conexão
• Sem credenciais, chaves ou cadeias de conexão codificadas em IaC ou código
• Segredos armazenados no Azure Key Vault com autorização RBAC (não políticas de acesso)
• Contas de armazenamento negam acesso público a blobs e desabilitam acesso por chave compartilhada sempre que possível
• Pontos de extremidade privados (ou no mínimo pontos de extremidade de serviço + regras de firewall) para serviços de dados PaaS
• NSGs restringem o tráfego de entrada às portas/CIDRs mínimos necessários (sem regras de permissão * → *)
• TLS 1.2+ imposto em todos os pontos de extremidade (minimumTlsVersion, httpsOnly)
• Azure RBAC segue o menor privilégio (sem Proprietário/Colaborador no escopo da assinatura para identidades de carga de trabalho)
• Microsoft Defender for Cloud habilitado nos tipos de recursos relevantes (az security pricing list)
• Azure WAF (Gateway de Aplicativo ou Front Door) configurado para pontos de extremidade web voltados para o público
• Configurações de diagnóstico enviam logs de segurança para Log Analytics / Microsoft Sentinel

Pilar 3: Otimização de Custo

• Reservas ou planos de economia avaliados para computação em estado estável (VMs, Serviço de Aplicativo, SQL)
• Políticas de gerenciamento de ciclo de vida de armazenamento movem blobs para camadas fria/arquivada
• SKUs dimensionadas corretamente com base na utilização real (sem VMs/planos de Serviço de Aplicativo superdimensionados)

…