Relatório Executivo — Azure Subscription AZURE_ASSESSMENT_SAMPLE

Gerado em: Análise completa da subscription AZURE_ASSESSMENT_SAMPLE

Região Principal: Brazil South (brazilsouth)

Ambiente: Staging (stg) — Aplicação: SampleCommerce (sc)

📊 Visão Geral

Resumo Executivo

A subscription AZURE_ASSESSMENT_SAMPLE hospeda o ambiente de staging da aplicação SampleCommerce, composto por 48 recursos distribuídos em 20 tipos distintos, todos concentrados na região Brazil South. A infraestrutura segue um padrão bem estruturado baseado em escala horizontal via Virtual Machine Scale Sets (VMSS), com isolamento de rede via Private Endpoints e forte adoção de práticas de segurança perimetral. O gerenciamento de infraestrutura é feito via Terraform, evidenciado pela storage account dedicada ao estado remoto.

Distribuição de Recursos por Tipo

🗂️ Inventário por Tipo

🖥️ Compute

Inferência de Workloads: Os três VMSS revelam a arquitetura da aplicação SampleCommerce:

• process: Workers/processadores de mensagens ou tarefas assíncronas

• rabbitmq: Cluster de mensageria RabbitMQ (broker de mensagens)

• client: Servidores de frontend/API voltados ao cliente

🗄️ Database & Cache

🌐 Network

🔐 DNS Privado

✅ Todas as zonas DNS privadas possuem Virtual Network Links configurados, garantindo resolução DNS correta para os Private Endpoints.

💾 Storage

🔑 Segurança & Identidade

🖥️ Infraestrutura Detalhada

Virtual Machines Standalone

⚠️ Nenhuma VM standalone encontrada. O ambiente utiliza exclusivamente Virtual Machine Scale Sets (VMSS) para os workloads de compute, o que é uma boa prática para ambientes elásticos.

Virtual Network — vnet-demo-app-network-brs-001

📌 Observações:

• O address space /21 é bem dimensionado para um ambiente staging, com espaço para expansão

• A subnet do AGW (/24) está generosamente provisionada — pode ser reduzida

• Não há VNet Peering registrado, sugerindo ambiente isolado ou conectividade via ExpressRoute/VPN não visível neste inventário

• Não há subnet dedicada para RabbitMQ VMSS — provavelmente compartilha snet-demo-app-app-brs-001

Mapeamento VMSS → Subnet → NSG

Application Gateway (pip-agw-demo-app-brs-001)
    └── snet-demo-app-agw-brs-001 (172.16.4.0/24)
            ↓
    snet-demo-app-client-brs-001 ← NSG: nsg-demo-app-client-brs-001
        └── vmss-demo-app-client-brs-001
            └── vmss-demo-app-rabbitmq-brs-001 (provável)
    snet-demo-app-app-brs-001 ← NSG: nsg-demo-app-app-brs-001
        └── vmss-demo-app-process-brs-001
    snet-demo-app-data-brs-001 ← NSG: nsg-demo-app-data-brs-001
        └── mysql-flex-demo-app-brs-001
        └── redis-demo-app-brs-001
    snet-demo-app-pe-brs-001 ← NSG: nsg-demo-app-pe-brs-001
        └── pe-stdemoappdata001-blob
        └── pe-stdemoappdata001-file
        └── pe-kvdemoappbrs001
        └── pe-redis-demo-app-brs-001-redis
        └── pe-mysql-flex-demo-app-brs-001

AzureBastionSubnet (172.16.3.0/26)
    └── bas-demo-app-brs-001 (pip-bas-demo-app-brs-001)

NAT Gateway: nat-demo-app-network-brs-001 (pip-nat-demo-app-network-brs-001)
    └── Saída controlada para internet dos VMSS

Load Balancer: lb-demo-app-brs-001
    └── Provável balanceamento interno para VMSS

AKS Clusters

ℹ️ Nenhum cluster AKS encontrado nesta subscription.

🗄️ Bancos de Dados

1. Azure Database for MySQL — Flexible Server

✅ Isolado da internet — acesso exclusivo via rede privada

2. Azure Cache for Redis Enterprise

⚠️ Redis Enterprise é o tier mais caro do Azure Cache for Redis. Para um ambiente de staging, avaliar se o tier Premium ou Standard seria suficiente (ver seção de custos).

Resumo de Conectividade dos Bancos

🔒 Segurança

Análise dos Network Security Groups

Regras padrão do Azure (presentes em todo NSG):

• AllowVNetInBound — permite tráfego intra-VNet (prioridade 65000)

• AllowAzureLoadBalancerInBound — permite health probes (prioridade 65001)

• DenyAllInBound — nega todo tráfego externo restante (prioridade 65500)

• AllowVnetOutBound — permite saída intra-VNet (prioridade 65000)

• AllowInternetOutBound — permite saída para internet (prioridade 65001) ⚠️

• DenyAllOutBound — nega demais saídas (prioridade 65500)

🚨 Riscos e Alertas de Segurança

Risco 1 — NSGs sem Regras Customizadas ⚠️ MÉDIO

Impacto: NSGs criados mas sem regras customizadas dependem
         exclusivamente das regras padrão do Azure.
         A regra "AllowInternetOutBound" está ativa por padrão,
         permitindo que os VMSS façam conexões de saída irrestrita
         para a internet.

Afetados: Todos os 4 NSGs
Mitigação: Adicionar regras explícitas de deny/allow conforme
           o princípio do menor privilégio.

Risco 2 — Saída para Internet via NAT Gateway ℹ️ INFORMATIVO

O nat-demo-app-network-brs-001 com IP público pip-nat-demo-app-network-brs-001
provê saída à internet para os VMSS. Isso é esperado para
atualizações de SO e chamadas a APIs externas, mas deve ser
monitorado e, idealmente, restrito via NSG de saída.

Risco 3 — Storage Account stdemoapptfstate (Terraform State) ⚠️ ALTO

Nome: stdemoapptfstate
RG: rg-demo-terraform-state
SKU: Standard_LRS (sem redundância geográfica)

CRÍTICO: Esta storage account armazena o Terraform state file,
que contém configurações sensíveis de TODA a infraestrutura.

Verificar:
- Acesso público está desabilitado?
- Private Endpoint configurado? (NÃO há PE registrado para esta SA)
- Versioning habilitado para rollback do state?
- Soft delete habilitado?
- Acesso restrito apenas à pipeline CI/CD via Managed Identity?

Risco 4 — Apenas 1 Managed Identity Registrada ⚠️ MÉDIO

Apenas id-agw-demo-app-brs-001 está visível no inventário.
Os VMSS e outros serviços podem estar usando System-Assigned
Identities (não visíveis neste inventário) ou, pior,
credenciais estáticas armazenadas em variáveis de ambiente.

Recomendação: Auditar autenticação de todos os VMSS
              e garantir uso de Managed Identities.

Risco 5 — Key Vault sem Diagnóstico Confirmado ℹ️ INFORMATIVO

Nome: kvdemoappbrs001
O inventário não confirma se Diagnostic Settings estão
habilitados no Key Vault para auditoria de acesso a secrets.
Verificar habilitação de audit logs no Azure Monitor.

✅ Pontos Positivos de Segurança

🎯 Recomendações

🔴 Prioridade Alta — Segurança

🟡 Prioridade Média — Disponibilidade & Resiliência

🟢 Prioridade Baixa — Otimização & Governança

💰 Análise de Custos e Otimização

Nota: Estimativas baseadas nos preços públicos da região Brazil South (USD/BRL). Valores aproximados para fins de planejamento. Sem informações de SKU dos VMSS, estimativas usam configurações típicas para workloads similares.

Estimativa de Custo Mensal por Recurso

🔍 Análise de Otimização de Custos

💡 Resumo de Economia Potencial

Custo atual estimado: ~$1.859–$3.355/mês

Custo estimado pós-otimização: ~$1.330–$2.180/mês

Redução potencial: 35–60% dependendo do tier do Redis

📌 Observações Sobre Redis Enterprise

O recurso redis-demo-app-brs-001 utiliza o tier Redis Enterprise, que é destinado a workloads de produção de alta escala com features como:

• Active Geo-Replication
• Redis Modules (RediSearch, RedisJSON, etc.)
• SLA 99.99%

Para um ambiente de staging, este tier raramente é justificado a não ser que seja necessário testar comportamentos específicos do Enterprise. A migração para Premium ou até Standard pode representar a maior economia individual desta subscription.

📋 Sumário Executivo Final

Pontos Fortes ✅

1. Arquitetura bem segmentada — 6 subnets com propósitos claros e NSGs por camada

2. 100% dos PaaS críticos via Private Endpoints — MySQL, Redis, Key Vault, Storage

3. Infraestrutura como Código — Terraform state dedicado e centralizado

4. Zero VMs com IP público — Acesso gerenciado exclusivamente via Bastion

5. Nomenclatura consistente — Padrão tipo-env-app-recurso-região-seq em todos os recursos

6. VMSS com Shared Image Galleries — Imutabilidade e rastreabilidade de imagens

Pontos de Atenção ⚠️

1. NSGs sem regras customizadas — Dependência das regras default do Azure

2. Redis Enterprise em staging — Custo desproporcional ao ambiente

3. Storage do Terraform State sem Private Endpoint confirmado

4. Sem evidência de Azure Monitor/Log Analytics configurado

5. Storage Accounts com LRS — Sem redundância zonal para dados da aplicação

Próximos Passos Recomendados (30 dias)

Semana 1: Adicionar regras customizadas nos 4 NSGs
Semana 2: Avaliar downgrade do Redis Enterprise → Premium
Semana 3: Configurar Private Endpoint para stdemoapptfstate
Semana 4: Implementar Azure Monitor + Budget Alerts

*Relatório gerado com base no inventário da subscription AZURE_ASSESSMENT_SAMPLE. Valores de custo são estimativas baseadas em preços públicos da região Brazil South e podem variar conforme configurações específicas de SKU, consumo real e descontos contratuais.*