VPC Bem Desenhada: Arquitetura Multi-Tier pra ERP Brasileiro (2026)

ERP brasileiro na nuvem sem VPC bem desenhada é acidente esperando pra acontecer. TOTVS, Sage, Domínio, Sankhya, Bimer — todos processam dado financeiro, folha, nota fiscal. Um único IP público exposto no lugar errado vira porta aberta pra ransomware. Este guia mostra o padrão multi-tier que ERP corporativo sério exige.

O que é VPC e por que ERP precisa de uma

VPC (Virtual Private Cloud) é uma rede virtual isolada dentro do datacenter. Você define subnets, roteamento, firewall, gateway, peering. Serve pra dar ao ERP o mesmo isolamento de rede que teria em rack físico — mas com elasticidade cloud.

Rodar ERP em VM avulsa com IP público é o cenário que engineer BR sério NUNCA aceita:

• Porta 3389 (RDP) exposta = alvo primário de brute force de ransomware
• Postgres/SQL Server com bind 0.0.0.0 = dado financeiro a 1 credencial vazada de vazamento
• Sem log de tráfego = auditoria Bacen/CFM sem evidência técnica
• Sem segmentação = 1 servidor comprometido derruba tudo (movimento lateral livre)

Arquitetura multi-tier: as 4 camadas obrigatórias

Camada 1 — DMZ (perímetro público)

Único ponto exposto à internet. Aqui ficam:

• WAF (Web Application Firewall): bloqueia SQL injection, XSS, brute force por reputação de IP
• Reverse proxy (Nginx, HAProxy, Traefik) com TLS terminando aqui
• Load balancer distribuindo pra camada de aplicação interna
• Bastion host pra acesso administrativo (SSH + MFA obrigatório, IP allowlist)

Regra: nada mais acessa internet direto. Aplicação e banco ficam em subnets privadas sem IP público.

Camada 2 — Aplicação

Servidores rodando ERP, API, integrações. Ficam em subnet privada, acessíveis só pelo LB da DMZ. Saída pra internet (pra atualizar dependência, chamar Serpro/SEFAZ, integração bancária) via NAT Gateway — assim IP público muda mas subnet interna continua não-roteável.

• Firewall permite entrada apenas do LB (portas 80/443 internas)
• SSH restrito ao bastion host
• Egress via NAT Gateway com log completo
• Segmentação por serviço se ERP tem múltiplos módulos (financeiro, folha, fiscal separados)

Camada 3 — Banco de dados

Camada mais crítica. Postgres, SQL Server, Oracle. Ficam em subnet ainda mais restrita:

• Firewall permite entrada apenas da subnet de aplicação (porta 5432 pra Postgres, 1433 pra SQL Server)
• Zero acesso administrativo direto — DBA usa bastion host
• Backup contínuo (WAL/binlog archiving) pra Object Storage separado
• Criptografia at-rest obrigatória, criptografia in-transit (TLS) entre app e banco
• Log de todas as conexões pra compliance

Camada 4 — Rede de gestão / administrativa

Bastion host (jump server), monitoramento (Prometheus/Grafana), coleta de log (Loki/ELK), backup orquestrador. Isolada das outras camadas mas com acesso auditado a tudo.

• MFA obrigatório no bastion (TOTP ou hardware key)
• Session recording (asciinema, Teleport) pra auditoria
• IP allowlist do escritório físico e VPN corporativa
• Alerta pra login fora de horário ou de IP novo

Padrões de conexão pra ERP: VPN, peering, IX privado

VPN site-to-site pro escritório físico

Escritório físico se conecta à VPC por túnel IPsec. Máquinas do escritório enxergam ERP como se fosse rede local. Vantagens:

• Terminal ERP não precisa exposição pública
• Impressoras fiscais locais acessam servidor de emissão de NFe direto
• Domain Controller local sincroniza com AD do ERP

Configuração típica: 2 túneis IPsec com failover automático, roteamento BGP dinâmico se múltiplos escritórios.

VPN client pra usuário remoto

Home office e viagem: WireGuard ou OpenVPN entregando IP na subnet interna. MFA obrigatório antes de estabelecer túnel. Split tunnel opcional (só tráfego ERP vai pela VPN, resto vai direto pra internet).

VPC peering entre ambientes (prod, homolog, dev)

Ambientes separados em VPCs distintas. Peering permite comunicação seletiva (só serviço X da homolog acessa serviço Y da produção). Segmentação forte previne que bug de dev afete produção.

Interconexão IX (Internet Exchange) pra parceiros

Se ERP conversa com adquirente (Cielo, Rede, Stone), banco (Bradesco, Itaú CIP), ou marketplace, tráfego via IX privado (IX.br) evita internet pública. Latência 5-10ms, sem exposição ao mundo. Provedor cloud BR sério tem presença no IX SP.

ERP brasileiro específico: TOTVS, Sage, Domínio, Sankhya

TOTVS Protheus/RM

Arquitetura em 3 camadas: cliente Smart Client, servidor de aplicação (AppServer), banco (SQL Server ou Oracle). VPC ideal: Smart Client via VPN chega no LB, LB roteia pro AppServer em subnet privada, AppServer conversa com SQL Server em subnet ainda mais restrita. TSS (TOTVS Service SOA) pra NFe fica em subnet separada por integrar SEFAZ.

Sage 4x/Sage 5

Terminal Server (RDP) é o padrão. NUNCA expor RDP direto — sempre atrás de VPN + RD Gateway com MFA. Fileserver (compartilhamento SMB pra dados do Sage) em subnet privada, criptografia in-transit obrigatória.

Domínio Contábil

Cliente-servidor sobre TCP customizado + SMB pra pastas de arquivo. Cliente via VPN, servidor em subnet privada, backup do arquivo do escritório (base .DTS) em Object Storage BR com Object Lock (documento fiscal exige guarda 5 anos).

Sankhya Om

Web nativo, mais amigável pra cloud. LB público → aplicação Java em subnet privada → Postgres/Oracle em subnet mais restrita. WAF na frente absolutamente obrigatório (aplicação web = superfície de ataque OWASP Top 10).

Compliance: Bacen, CFM, LGPD — o que VPC precisa provar

• Bacen (Resolução 4.893/2021) pra fintech e cliente regulado: log de tráfego 5 anos, segregação de ambiente por criticidade, plano de continuidade documentado, direito de auditoria contratado
• CFM (Resolução 2.314/2022) pra saúde: prontuário eletrônico em rede segregada, log de acesso por profissional, backup imutável 20 anos
• LGPD (art. 46): medidas técnicas comprovadas — criptografia em rest e trânsito, controle de acesso por perfil, log de operação, DPA no contrato
• TJSP e-SAJ: rede isolada pra advogado que integra com peticionamento eletrônico

Custos: VPC não é linha separada, mas alguns componentes cobram

• VPC em si: em provedor BR sério geralmente incluída sem custo separado
• NAT Gateway: cobrança por hora + GB processado
• Load Balancer gerenciado: cobrança fixa mensal + volume
• VPN Gateway: cobrança por hora do túnel + tráfego
• Peering: geralmente gratuito dentro do mesmo provedor
• Tráfego intra-VPC: em provedor BR sério, gratuito (diferente de cloud gringa que cobra egress interzona)

Erros comuns em VPC pra ERP

1. Uma subnet só pra tudo: aplicação, banco e admin misturados. Movimento lateral livre em caso de comprometimento
2. Firewall permissivo por comodidade: "libera 0.0.0.0/0 pro banco pra facilitar debug" — vira porta aberta esquecida
3. Bastion sem MFA: SSH com senha, exposto à internet, senha compartilhada. Vira alvo prioritário de credential stuffing
4. VPN sem log: túnel estabelecido sem registrar quem, quando, IP origem. Compliance impossível
5. Sem NAT Gateway pra egress: aplicação com IP público direto pra baixar update. Superfície de ataque desnecessária
6. Backup na mesma VPC: ransomware que entrou na VPC também deleta backup. Backup em Object Storage separado + Object Lock é obrigatório

FAQ VPC pra ERP brasileiro

Quantas subnets criar pra ERP típico?

Mínimo 4: DMZ pública, aplicação privada, banco privada, gestão privada. Se ERP tem múltiplos módulos com criticidade diferente (folha vs financeiro), vale dividir mais. Máximo prático: uma subnet por serviço isolável.

Preciso de IP público separado por VPC?

Não. Um único IP público na DMZ (com LB e WAF) atende. NAT Gateway cuida do egress pra internet sem expor máquinas internas.

VPN site-to-site ou MPLS?

Depende de volume e criticidade. VPN IPsec funciona bem até uns 500Mbps sustained. Acima disso ou se latência precisa ser previsível (sub-10ms constantes), MPLS ou link dedicado via IX vale. Custo MPLS é muito maior que VPN — só quando a exigência técnica justifica.

Ambiente de homologação/dev na mesma VPC de produção?

Não recomendado. Idealmente VPCs separadas por ambiente, com peering seletivo se precisar. Se orçamento aperta, ao menos subnets separadas dentro da mesma VPC com firewall bloqueando comunicação por padrão.

Como monitorar tráfego na VPC?

Flow log (registro de conexão: origem, destino, portas, bytes, decisão do firewall) enviado pra Object Storage ou SIEM. Ferramentas open source: nfdump, ntopng. Comercial: Datadog, Grafana Cloud. Retention típico: 6 meses pra investigação, 5 anos pra compliance financeiro.

Preciso de firewall dedicado (Fortinet, PaloAlto) ou security group basta?

Security group da VPC + regras de subnet + WAF cuidam da maioria dos casos. Firewall dedicado agrega em cenário com muitas regras L7 (deep packet inspection), inspeção de tráfego criptografado com re-terminação SSL, IPS avançado. Antes de contratar appliance caro, avalie se WAF + security group não resolve.

VPC de provedor BR conecta com AWS/Azure?

Sim, por VPN IPsec ou Direct Connect / ExpressRoute. Cenário híbrido comum: dado sensível (folha, financeiro) fica em VPC BR, workload analítico ou IA fica em AWS/Azure conectado por VPN. Tráfego interconectado paga egress cambial só do lado gringo — no BR não gera fatura extra.

Próximos passos

• Cloud privada vs pública vs híbrida no Brasil
• ERP na nuvem por vertical: indústria, varejo, serviços
• VPC / Cloud Privada Audaks — arquitetura multi-tier em datacenter Tier III BR
• Servidor Dedicado — quando ERP crítico exige hardware exclusivo