▲ Upperstack

Assessment AWS — Bell Software

Análise completa de Segurança, Custos, Desempenho e Arquitetura
Conta AWS: 748018363708
Cliente: Bell Software
Data: 30/03/2026
Região: us-east-2 (Ohio)
📋 Visão Geral para o Cliente

O que encontramos

Realizamos uma análise completa da infraestrutura AWS da Bell Software, que hospeda um ERP SaaS utilizado por aproximadamente 3.000 clínicas de estética em todo o Brasil. A aplicação roda em 16 servidores na região Ohio (us-east-2), com um banco de dados MariaDB em um servidor de alta capacidade (48 processadores, 192GB de memória).

O custo mensal atual gira em torno de USD $3.400 (~R$ 20.000). Identificamos 12 vulnerabilidades de segurança (5 críticas), oportunidades de redução de custo de até 40%, e uma proposta de rearquitetura que trará mais segurança, escalabilidade e economia.

🔓

Segurança em Risco

A conta não possui auditoria de ações (CloudTrail desativado), o que significa que não há registro de quem fez o quê na infraestrutura. Além disso, 10 dos 16 servidores têm a porta SSH (acesso remoto) aberta para toda a internet, e o servidor de banco de dados principal possui IP público — qualquer pessoa na internet pode tentar acessá-lo.

Para uma empresa que lida com dados sensíveis de pacientes de clínicas de estética (nome, CPF, histórico de procedimentos, fotos), isso representa um risco significativo de vazamento de dados e possíveis implicações com a LGPD.

12 vulnerabilidades encontradas
💸

Custo Pode Ser Menor

O servidor de banco de dados (M6A.12xlarge) custa aproximadamente USD $1.500/mês sozinho, mas opera com CPU média de apenas 28%. A aplicação PHP (M5A.4xlarge) tem CPU média de 19% durante o dia e cai para 3-4% nos finais de semana.

Isso significa que a infraestrutura está superdimensionada e paga 24 horas por dia, 7 dias por semana, mesmo quando o uso é mínimo (madrugada e domingos). Com auto-scaling e instâncias reservadas, é possível reduzir significativamente o custo mensal.

Economia estimada de até 40%

Sem Escalabilidade

Hoje a aplicação roda em um único servidor. Se esse servidor tiver um problema, todas as 3.000 clínicas ficam sem acesso. Não há redundância, não há auto-scaling, e o backup do banco é feito apenas uma vez por dia — em caso de falha, podem ser perdidas até 24 horas de dados.

O banco de dados MariaDB roda diretamente em uma instância EC2 (não é um serviço gerenciado), o que significa que a equipe da Bell é responsável por patches, backups, recuperação de desastres e monitoramento.

Single point of failure
📊

Sem Visibilidade

Não existe CloudTrail (auditoria), VPC Flow Logs (monitoramento de rede), nem CloudWatch Agent nos servidores. Isso significa que não há como saber se alguém acessou indevidamente a infraestrutura, não há como investigar incidentes, e não há métricas detalhadas de performance da aplicação.

Sem logs centralizados, qualquer problema de performance ou segurança se torna um "tiro no escuro" para diagnosticar.

Zero visibilidade operacional
~R$ 8.000/mês
Economia estimada com a rearquitetura proposta (redução de ~40% sobre o custo atual)

O que propomos

Um plano em 3 fases que resolve os problemas de segurança imediatamente, reduz custos no curto prazo, e moderniza a arquitetura no médio prazo:

Fase 1 — Segurança (Semana 1-2)

Correção imediata das vulnerabilidades críticas: fechar portas abertas, habilitar auditoria, configurar políticas de senha, ativar detecção de ameaças. Sem custo adicional significativo (a maioria dos serviços de segurança da AWS tem custo mínimo).

Fase 2 — Otimização (Mês 1-2)

Migrar o banco de dados para Amazon RDS (serviço gerenciado), implementar auto-scaling na aplicação, adicionar WAF e CloudFront. Economia estimada de 25-35% com mais segurança e disponibilidade.

Fase 3 — Modernização (Mês 2-4)

Containerizar a aplicação com ECS Fargate, migrar para Aurora Serverless. A infraestrutura escala automaticamente conforme a demanda. Economia de até 40-50% e zero gerenciamento de servidores.

📊 Resumo Técnico

Score de Segurança

30
de 100
Crítico
5 findings
Alto
4 findings
Médio
3 findings
OK
2 itens (GuardDuty ativo, root com MFA)
12
Vulnerabilidades
16
Instâncias EC2
14
Running
7
S3 Buckets
$3.427
Custo Mar/2026
10
IAM Users
h4>strong>
🔒 Segurança

🔴 Crítico

CRÍTICO CloudTrail Desativado — Sem Auditoria

A conta não possui CloudTrail configurado. Isso significa que não há registro de quem acessou a conta, quem alterou configurações, quem parou/iniciou servidores, ou qualquer outra ação. Em caso de incidente de segurança, não há como investigar o que aconteceu.

💡 Habilitar CloudTrail multi-região com entrega para S3 e integração com CloudWatch Logs. Custo estimado: ~$5-10/mês.

CRÍTICO SSH aberto para internet (0.0.0.0/0) em múltiplos servidores

10 Security Groups permitem acesso SSH (porta 22) de qualquer IP da internet. Isso inclui os servidores principais: php-belle, php-saas, db01, db02, bellemessage, websites-webserver, munin. Qualquer pessoa pode tentar ataques de força bruta para acessar esses servidores.

Security GroupNomeServidores AfetadosPortas Abertas 0.0.0.0/0
sg-065192f32b38781a2launch-wizard-2php-belle, bellemessage, logging, meetbelleSSH(22), HTTP(80), HTTPS(443)
sg-0d9597ba2cb2d5ba3launch-wizard-3db01 (M6A.12xlarge), db02SSH(22)
sg-02a24340bbbaeebdflaunch-wizard-5php-saasSSH(22), HTTP(80), HTTPS(443), Kibana(5601)
sg-0290e83d0b11e1625launch-wizard-8websites-webserver, web-nginxSSH(22), HTTP(80), HTTPS(443)
sg-0057a85575e9c4b8assh+web+ftpmuninSSH(22), HTTP(80), HTTPS(443)
sg-0688f413530a56c61chat-hardenedplaychat, bellechat-v2SSH(22), HTTP(80), HTTPS(443)
sg-0715e9deeda0c2c3dlaunch-wizard-9websites-dbSSH(22)
sg-05bdbd18cac152190new-apis-SSH(22), HTTP(80), HTTPS(443)
💡 Restringir SSH apenas para IPs da VPN (18.217.207.70) ou IPs fixos da equipe. Usar AWS Systems Manager Session Manager como alternativa ao SSH.

CRÍTICO Banco de dados principal (db01) com IP público

O servidor db01 (M6A.12xlarge) que contém todos os dados das 3.000 clínicas possui IP público (3.13.7.154). Embora o MariaDB (porta 3306) esteja restrito a IPs internos no Security Group, o servidor em si está exposto na internet com SSH aberto. Isso é um risco grave para dados sensíveis protegidos pela LGPD.

💡 Mover o banco de dados para uma subnet privada (sem IP público). Acesso apenas via VPN ou bastion host.

CRÍTICO Sem Password Policy

A conta não possui política de senha configurada. Usuários podem criar senhas fracas sem requisitos de complexidade ou rotação.

💡 Configurar password policy: mínimo 14 caracteres, letras maiúsculas/minúsculas, números, caracteres especiais, rotação a cada 90 dias.

CRÍTICO Kibana (5601) exposto na internet

O servidor php-saas tem a porta 5601 (Kibana/Elasticsearch) aberta para 0.0.0.0/0. Kibana exposto pode revelar logs, dados internos e ser usado como vetor de ataque.

💡 Restringir acesso ao Kibana apenas para IPs internos ou via VPN.

🟠 Alto

ALTO MFA ausente em 8 de 10 usuários

Apenas root e 1 usuário possuem MFA. Usuários sem MFA: alessandro, andre, apis-firewall, claudemir, gabriel, joao, lucas, playsaas, s3-unlayer, tarso.

💡 Habilitar MFA para todos os usuários com acesso ao console (alessandro, andre, gabriel, joao, lucas, tarso, claudemir).

ALTO Access Keys antigas e sem rotação

UsuárioKey CriadaÚltimo UsoProblema
apis-firewallJul/2020Set/2021Key de 5 anos, sem uso há 4+ anos
tarsoFev/2020Mar/2026 (ativa)Key de 6 anos, nunca rotacionada
alessandroJan/2025Jan/2025Sem uso há 14 meses
s3-unlayerAbr/2023Out/2025Key de 3 anos
claudemirDez/2025Nunca usadaKey criada mas nunca utilizada
💡 Remover key de apis-firewall (sem uso há 4 anos). Rotacionar key do tarso. Remover key não usada do claudemir.

ALTO VPC Flow Logs desativados

Sem monitoramento de tráfego de rede. Impossível detectar tráfego suspeito, tentativas de acesso não autorizado ou exfiltração de dados.

💡 Habilitar VPC Flow Logs na VPC principal (vpc-530bd13a). Enviar para S3 com lifecycle policy.

ALTO 15 de 16 instâncias sem IAM Role

Apenas php-saas possui IAM Instance Profile (CodeDeployRole). As demais 15 instâncias não têm role associada, o que significa que qualquer acesso a serviços AWS de dentro delas provavelmente usa access keys hardcoded.

💡 Criar IAM Roles com permissões mínimas e associar a todas as instâncias. Remover access keys hardcoded.

🟡 Médio

MÉDIO Senhas antigas sem rotação

Vários usuários com senhas que nunca foram alteradas: tarso (Set/2021 — 4.5 anos), alessandro (Nov/2022 — 3.4 anos), gabriel (Abr/2023 — 3 anos).

MÉDIO Todos os servidores na mesma VPC/subnet

Todos os 16 servidores estão na VPC default (vpc-530bd13a) sem segmentação. Banco de dados, aplicação e serviços auxiliares compartilham a mesma rede sem isolamento.

MÉDIO Sem CloudWatch Agent — Sem logs centralizados

Nenhuma instância envia logs de aplicação (nginx, php, mariadb) para o CloudWatch. Custo de CloudWatch de apenas $3.69/mês confirma que só métricas básicas de EC2 estão sendo coletadas. Sem logs centralizados, é impossível diagnosticar problemas de performance ou investigar incidentes.

💡 Instalar CloudWatch Agent em todas as instâncias. Configurar envio de logs: nginx access/error, php-fpm slow log, MariaDB slow query log, syslog.

✅ Pontos Positivos

GuardDuty Ativo

GuardDuty está habilitado em us-east-2 com 13 findings de baixa severidade. Custo de $37/mês — bom investimento em detecção de ameaças.

Root com MFA

A conta root possui MFA habilitado, o que é uma boa prática fundamental.

💰 Custos

Evolução de Custos Mensais (6 meses)

Conta 748018363708 — Out/2025 a Mar/2026

Distribuição por Serviço — Março/2026

Total: USD $3.427

Detalhamento Mensal

MêsCusto (USD)Custo (BRL ~6x)Variação
Out/2025$4.320~R$ 25.920-
Nov/2025$4.422~R$ 26.530+2.4%
Dez/2025$3.840~R$ 23.040-13.2%
Jan/2026$3.600~R$ 21.600-6.3%
Fev/2026$3.180~R$ 19.080-11.7%
Mar/2026$3.427~R$ 20.562+7.8%

Tendência de queda de Out a Fev (~28% de redução). Março com leve aumento. Média dos últimos 6 meses: ~$3.715/mês (~R$ 22.290).

Top Serviços por Custo — Março/2026

ServiçoCusto (USD)% do TotalObservação
Savings Plans (Compute)$1.23436.0%Compromisso de uso já contratado
EC2 Compute (On-Demand)$1.01429.6%Instâncias não cobertas pelo SP
EC2 Other (EBS, IPs, etc)$44212.9%Volumes EBS + Elastic IPs
Tax$36110.5%Impostos
S3$2507.3%Armazenamento de arquivos
VPC$531.5%NAT Gateway / Data Transfer
GuardDuty$371.1%Detecção de ameaças
ElastiCache$220.6%Cache Redis/Memcached
SQS$60.2%Filas de mensagens
Lambda + CloudWatch + Outros$80.2%Serviços auxiliares

Análise de Custo EC2 (65% do total)

EC2 Compute + Savings Plans + EBS representam $2.690/mês (78% do custo total). Detalhamento por instância:

InstânciaTipovCPUsRAMCusto Est./mêsCPU MédiaObservação
db01m6a.12xlarge48192 GB~$1.50028%Banco principal — superdimensionado
php-bellem5a.4xlarge1664 GB~$50019%App principal — 3-4% nos domingos
db02m6a.2xlarge832 GB~$250-Banco secundário
playchatm6g.2xlarge832 GB~$220-PlayChat
bellemessagem6g.2xlarge832 GB~$220-Belle Message
php-saasm5a.xlarge416 GB~$125-PlaySaaS
muninm5.large28 GB~$70-Monitoramento
websites-dbt4g.large28 GB~$50-DB websites
websites-webservert4g.large28 GB~$50-Webserver sites
Outros (5 inst.)t2/t3/t4g micro--~$40-vpn, logging, monitor, meet, bellechat-v2
td>tr>td>td>th>tr>td>
🖥️ Inventário

Instâncias EC2 — us-east-2 (Ohio)

h>
NomeTipoEstadoSecurity GroupIAM Role
db01m6a.12xlarge▶ running3.13.7.154launch-wizard-3Nenhum
db02m6a.2xlarge▶ running3.17.124.228launch-wizard-3Nenhum
php-bellem5a.4xlarge▶ running3.17.101.139launch-wizard-2Nenhum
php-saasm5a.xlarge▶ running3.137.99.25launch-wizard-5CodeDeployRole
playchatm6g.2xlarge▶ running3.132.156.149chat-hardenedNenhum
bellemessagem6g.2xlarge▶ running3.143.159.36launch-wizard-2Nenhum
muninm5.large▶ running3.134.184.40ssh+web+ftpNenhum
websites-dbt4g.large▶ running3.22.78.142launch-wizard-9Nenhum
websites-webservert4g.large▶ running3.22.85.209launch-wizard-8Nenhum
vpnt2.micro▶ running18.217.207.70OpenVPNNenhum
loggingt2.micro▶ running3.145.190.132launch-wizard-2Nenhum
monitort4g.micro▶ running3.22.166.162monitor-hardenedNenhum
meetbellesoftwaret3.micro▶ running3.16.152.209launch-wizard-2Nenhum
bellechat-v2t3.micro▶ running52.14.209.203chat-hardenedNenhum
web-nginxm5.large⏹ stopped-launch-wizard-8Nenhum
webdbm5.large⏹ stopped-launch-wizard-9Nenhum
td>td>

IAM Users

UsuárioMFAConsoleAccess KeyÚltimo LoginSenha Alterada
root-Dez/2025Dez/2025
tarsoAtiva (6 anos)Mar/2026Set/2021
alessandroAtiva (sem uso 14m)Fev/2026Nov/2022
andre-Mar/2026Nov/2024
gabriel-Mar/2026Abr/2023
joao-Fev/2026Mai/2024
lucas-Dez/2025Abr/2024
claudemirAtiva (nunca usada)Jan/2026Dez/2025
playsaas-Ativa (em uso)--
s3-unlayer-Ativa (3 anos)--
apis-firewall-Ativa (sem uso 4+ anos)--
📈 Desempenho & Métricas
28%
CPU Média db01 (MariaDB)
91.7%
CPU Pico db01
19%
CPU Média php-belle
3.7%
CPU php-belle (Domingo)

CPU — db01 (MariaDB M6A.12xlarge)

Média e pico diário — Março/2026. Picos de 91% nos dias 13-14/Mar.

CPU — php-belle (Aplicação M5A.4xlarge)

Padrão claro: dias úteis ~20%, sábados ~13%, domingos ~4%.

Análise de Desempenho

⚠️ db01 — Picos de CPU preocupantes
  • CPU média de 28% mas com picos de 91% nos dias 13-14/Mar
  • Padrão semanal claro: ~29% dias úteis, ~25% sábados, ~20% domingos
  • Picos podem indicar queries pesadas não otimizadas ou locks no banco
  • Instância M6A.12xlarge (48 vCPUs) — considerar otimização de queries antes de escalar
⚠️ php-belle — Fortemente subutilizada
  • CPU média de 19% em dias úteis, caindo para 3.7% aos domingos
  • M5A.4xlarge (16 vCPUs, 64GB RAM) é superdimensionada para o uso atual
  • Picos de até 82% (dia 17/Mar) — pode ser deploy ou processo pesado
  • Candidata ideal para auto-scaling: escalar para cima nos picos, reduzir na madrugada/domingo

🔍 Limitação: Logs Internos

Não foi possível analisar logs dentro das instâncias
  • O acesso de assessment é read-only via API da AWS — não temos acesso SSH
  • 15 de 16 instâncias não possuem IAM Role, impossibilitando uso do SSM Session Manager
  • CloudWatch Agent não está instalado — logs de nginx, PHP, MariaDB não são enviados para a AWS
  • Sem logs centralizados, não é possível analisar: slow queries do MariaDB, erros PHP, access logs do nginx, tentativas de login SSH

Recomendação: Como próximo passo, instalar o CloudWatch Agent em todas as instâncias para enviar logs de aplicação. Isso permitirá uma análise muito mais profunda de performance e segurança.

li>""
🏗️ Proposta de Rearquitetura

❌ Arquitetura Atual

Internet (3.000 clínicas) └→ EC2 php-belle (m5a.4xlarge) ├→ Nginx + PHP-FPM ├→ Cron jobs, filas, etc └→ EC2 db01 (m6a.12xlarge) └→ MariaDB (IP público!) └→ Backup snapshot 1x/dia EC2 php-saas → PlaySaaS EC2 playchat → PlayChat EC2 bellemessage → Belle Message EC2 bellechat-v2 → Belle Chat Bitbucket → Pipeline → Deploy na EC2 S3 → Arquivos (fotos, docs)
⚠️ Single point of failure em todas as camadas
⚠️ DB com IP público e SSH aberto
⚠️ Sem auto-scaling (paga 24/7)
⚠️ Sem WAF/CDN
⚠️ RPO de 24 horas
⚠️ Sem segmentação de rede

✅ Fase 1 — Quick Wins

Internet └→ CloudFront (CDN + Cache) └→ AWS WAF (OWASP Top 10) └→ ALB (Load Balancer) └→ Auto Scaling Group ├→ EC2 PHP (min:1 max:4) └→ RDS MariaDB Multi-AZ ├→ Subnet privada ├→ Read Replica └→ PITR (RPO 5min)
  • Economia de 25-35% com ASG + Reserved Instances
  • DB em subnet privada, sem IP público
  • WAF protege contra SQL Injection, XSS, DDoS
  • Multi-AZ: failover automático do banco
  • RPO de 5 minutos (vs 24h atual)
  • CloudFront reduz latência para clínicas no Brasil

🚀 Fase 2 — Modernização Completa

Internet (3.000 clínicas) └→ CloudFront (CDN + Cache estático + WAF) └→ ALB └→ ECS Fargate (containers PHP) ├→ Auto-scaling por CPU/requests ├→ Scale to near-zero (madrugada/domingo) └→ Aurora MySQL Serverless v2 ├→ 0.5 ACU (madrugada) → 128 ACU (pico) ├→ Backup contínuo PITR └→ Read Replica automática Produtos secundários → ECS Fargate (services separados) S3 → Assets via CloudFront Bitbucket → CodePipeline → ECR → ECS Blue/Green

Comparativo de Custos Estimados

🎯 Plano de Ação

🔴 Imediato (Semana 1-2)

Segurança
Habilitar CloudTrail

Multi-região, S3 + CloudWatch Logs

Segurança
Fechar SSH (0.0.0.0/0)

Restringir para IP da VPN apenas

Segurança
Remover IP público do db01

Mover para subnet privada

Segurança
Password Policy + MFA

Todos os usuários com console

Segurança
Limpar Access Keys

Remover apis-firewall, rotacionar tarso

Segurança
Fechar Kibana (5601)

Restringir para VPN

Observabilidade
VPC Flow Logs

Habilitar na VPC principal

🟠 Curto Prazo (Mês 1-2)

CloudWatch Agent

Instalar em todas as instâncias

AWS WAF + CloudFront

Proteção OWASP + CDN

Migrar db01 → RDS Multi-AZ

Backup PITR, subnet privada

Auto Scaling Group

php-belle com min:1 max:4

IAM Roles nas instâncias

Remover access keys hardcoded

Security Hub

CIS Foundations benchmark

p>h5>
""

🟢 Médio Prazo (Mês 2-4)

Containerizar PHP

Docker + ECR

ECS Fargate

Migrar app principal

Aurora Serverless v2

Escala automática 0.5-128 ACU

CI/CD CodePipeline

Blue/Green deploy

Produtos secundários

PlayChat, BelleMessage → Fargate

🔵 Longo Prazo (Mês 4-6)

ElastiCache otimizado

Cache para queries de agenda

Performance Insights

Otimizar slow queries

Savings Plans Fargate

Compromisso para economia extra

Segmentação de rede

VPC com subnets públicas/privadas

Matriz de Riscos

RiscoSeveridadeStatus AtualImpactoAção
Vazamento de dados (LGPD)CRÍTICOSSH aberto, DB públicoMulta LGPD + reputaçãoFechar SGs + subnet privada
Sem auditoriaCRÍTICOCloudTrail desativadoImpossível investigar incidentesHabilitar CloudTrail
IndisponibilidadeALTOSingle point of failure3.000 clínicas offlineRDS Multi-AZ + ASG
Perda de dadosALTOBackup 1x/diaAté 24h de dados perdidosPITR (RPO 5min)
Custo excessivoMÉDIOSem auto-scaling~R$8.000/mês desperdiçadosASG + Serverless
▲ UPPERSTACK

Relatório gerado em 30/03/2026

Acesso: role upperstack-assessment (read-only) | Conta: 748018363708