ruicesar/clube67_newwhats.local
1
0
Fork 0
Code Issues 13 Pull Requests Actions Packages Projects 11 Releases Wiki Activity
Files
6621d774870c5e44a95382cac0e424756aa2e079
clube67_newwhats.local/newwhats.clube67.com/newwhats.local/arquitetura.md
T
VPS 4 Deploy Agent 2064ff1ae7 docs: renomeia terminologia "staging" -> "dev" (ambiente nunca foi isolado) 
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 03:39:15 +02:00

15 KiB
Raw Blame History

📐 Arquitetura de Rede e Topologia de Servidores

Este documento descreve detalhadamente a arquitetura de servidores e rede privada projetada para garantir alta performance, isolamento de riscos, segurança de dados e facilidade de escalonamento.

🗺️ Visão Geral da Topologia (Rede VPN WireGuard)

Toda a comunicação crítica entre os servidores trafega por dentro de uma rede privada criptografada baseada no protocolo WireGuard (10.99.0.0/24). Os servidores possuem seus firewalls públicos trancados, permitindo apenas acessos necessários e isolando os dados vitais.

graph TD
    subgraph "Rede Pública (Internet)"
        Internet((Internet Pública))
        Client([Notebook Rui])
    end

    subgraph "Rede Privada VPN (10.99.0.0/24)"
        VPS1["🖥️ VPS 1 (Produção) <br> IP: 10.99.0.1 <br> (Traefik / Apps)"]
        VPS3["🗄️ VPS 3 (Banco de Dados) <br> IP: 10.99.0.3 <br> (PostgreSQL Dedicado)"]
        VPS4["🧪 VPS 4 (Desenvolvimento) <br> IP: 10.99.0.4 <br> (Dev / Builds)"]
        VPS5["💬 VPS 5 (CRM WhatsApp) <br> IP: 10.99.0.5 <br> (Bots / APIs)"]
    end

    %% Conexões Públicas
    Internet == HTTP/HTTPS (80/443) ==> VPS1
    Client == Conexão VPN Criptografada ==> VPS1

    %% Conexões Privadas VPN
    VPS1 <== Canal Seguro VPN ==> VPS3
    VPS1 <== Canal Seguro VPN ==> VPS4
    VPS1 <== Canal Seguro VPN ==> VPS5
    Client <== Acesso SSH Seguro ==> VPS1
    Client <== Acesso SSH Seguro ==> VPS3
    Client <== Acesso SSH Seguro ==> VPS4
    Client <== Acesso SSH Seguro ==> VPS5

    %% Conexões de Banco de Dados Internas
    VPS1 -- PostgreSQL (Porta 5432) --> VPS3
    VPS4 -- PostgreSQL (Porta 5432) --> VPS3
    VPS5 -- PostgreSQL (Porta 5432) --> VPS3

    style VPS3 fill:#1E293B,stroke:#3B82F6,stroke-width:3px,color:#fff
    style VPS1 fill:#1E293B,stroke:#10B981,stroke-width:2px,color:#fff
    style VPS4 fill:#1E293B,stroke:#F59E0B,stroke-width:2px,color:#fff
    style VPS5 fill:#1E293B,stroke:#EC4899,stroke-width:2px,color:#fff

📋 Especificação Detalhada dos Servidores

1. 🗄️ VPS 3: Servidor de Banco de Dados Dedicado (Appliance)

  • Função Principal: Hospedar exclusivamente o banco de dados PostgreSQL Bare-Metal (Nativo) e serviços fundamentais de persistência.
  • IP Privado VPN: 10.99.0.3
  • Tecnologias: PostgreSQL (Instalação Nativa via Host), WireGuard, nftables. (O Docker é estritamente omitido para reduzir superfície de ataque e otimizar I/O).
  • Políticas do Firewall (nftables):
    • Porta 22 (SSH): Bloqueada publicamente. Liberada apenas para o IP reservado do administrador via VPN (10.99.0.10).
    • Porta 5432 (PostgreSQL): Bloqueada publicamente. Liberada apenas para conexões originadas de IPs autorizados na VPN (10.99.0.1 e 10.99.0.5).
  • Vantagens de Segurança & Performance:
    • Zero vazamento de dados: O banco não pode ser acessado de fora da VPN sob hipótese alguma.
    • Conceito de Appliance: Sem Docker daemon (sem socket de root adicional) ou compiladores, a superfície de invasão é reduzida ao menor nível matemático possível.
    • Performance Máxima (Tuning de Host): Como a máquina é nativa e dedicada, as configurações de cache e buffers de memória do PostgreSQL podem usufruir livremente do Page Cache nativo do Linux e Huge Pages do Kernel, garantindo o máximo rendimento físico do SSD e RAM.

🚀 2. VPS 1: Servidor de Sistemas em Produção

  • Função Principal: Gateway de entrada do tráfego público e hospedagem das aplicações em produção.
  • IP Privado VPN: 10.99.0.1 (Atua como Hub WireGuard)
  • Políticas do Firewall (UFW):
    • Portas 80 (HTTP) e 443 (HTTPS): Abertas ao público para permitir o acesso dos clientes aos sites e sistemas.
    • Porta 22 (SSH): Bloqueada publicamente. Apenas acessível via VPN.
    • Porta 3002 (Antigo Dev): Bloqueada publicamente no Docker (atrelada apenas ao IP privado 10.99.0.1 do container).
  • Vantagens de Segurança & Performance:
    • Serviços sem Estado (Stateless): A VPS 1 apenas processa as requisições web e consome os dados da VPS 3. Caso a VPS 1 sofra um pico extremo de acessos, o banco de dados continua intacto e seguro.
    • Centralização com Traefik: Proxy reverso centralizado gerenciando SSL e direcionamento interno seguro de containers.

🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Dev)

  • Função Principal: Testar novos recursos, hospedar containers de dev e realizar builds de desenvolvimento.
  • IP Privado VPN: 10.99.0.4
  • Políticas do Firewall (UFW):
    • Porta 22 (SSH): Bloqueada publicamente. Apenas acessível via VPN.
    • Portas de teste (ex: 3002, 8080): Bloqueadas publicamente ou atreladas apenas ao IP privado da VPN para acesso exclusivo dos desenvolvedores autorizados.
  • Tecnologias: Docker, Docker Compose, PostgreSQL 18 (Standby Replica em Container).
  • Vantagens de Segurança & Performance:
    • Replicação Streaming Real-Time (Dev): Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal.
    • Isolamento de Riscos: Compilações de código (npm run build, docker build) e testes pesados de carga rodam aqui e consomem CPU sem comprometer os servidores de produção e banco de dados.
    • Ambiente Espelho: Homologação idêntica à produção para validações precisas antes de aplicar modificações em produção.

💬 4. VPS 5: Servidor de Aplicação Proprietária (newwhats)

  • Função Principal: Hospedar o backend e workers da plataforma proprietária newwhats (Backend Express com Socket.IO, Workers do Temporal e broker NATS).
  • IP Privado VPN: 10.99.0.5
  • Políticas do Firewall (UFW):
    • Portas de Integração Web: Liberadas apenas para os Webhooks e requisições públicas de Socket.IO mapeadas via gateway.
    • Porta 22 (SSH): Bloqueada publicamente. Apenas acessível via VPN.
  • Vantagens de Segurança & Performance:
    • Isolamento de Estado: Executar o backend Node.js (Prisma/Knex), os workers de workflows do Temporal e o broker de mensagens NATS na VPS 5 impede que oscilações no tráfego de mensagens do WhatsApp ou alto uso de CPU nos workers interfiram com o banco de dados principal de produção (VPS 3).
    • Separação de CPU: O processamento pesado das sessões de WhatsApp e emulação de instâncias roda na VPS 5, consumindo sua CPU e RAM de forma isolada do Gateway (VPS 1) e do Banco (VPS 3).

🔒 Diretrizes de Segurança Corporativa (Resumo)

  1. Acesso Administrativo: Realizado exclusivamente via chave SSH criptográfica. Autenticação por senhas desativada em todas as máquinas.
  2. Login de Root Desativado: Bloqueado login direto de root via SSH. Todos conectam como o usuário deploy e elevam privilégios de forma segura via sudo após a conexão.
  3. Ponto Único de Falha: Se a VPS 1 (Hub WireGuard) cair, a comunicação VPN é temporariamente pausada. O console VNC da Contabo é mantido ativo como canal redundante de suporte imediato.
  4. Logs Automatizados: Logins SSH bem-sucedidos ou suspeitos geram alertas em segundo plano com marcações de 30 minutos na agenda central do Google, permitindo controle visual de acessos em tempo real.

🛡️ Fase 2: Hardening Avançado e Arquitetura Zero-Trust (Roadmap)

Esta seção documenta as decisões estratégicas e o plano de ação de segurança de curto e médio prazo projetados para elevar a maturidade da infraestrutura de rede e servidores ao nível Enterprise / DevSecOps Sênior.

🗺️ Visão Geral do Fluxo de Segurança na Borda

graph TD
    subgraph "Camadas de Defesa (Defense in Depth)"
        Internet((Internet Pública)) --> PM[1. Proteção de Borda do Provedor]
        PM --> NFT[2. nftables + CrowdSec <br> Bloqueio Dinâmico / Comportamental]
        NFT --> TF[3. Traefik Reverse Proxy <br> SSL/TLS & Roteamento]
        TF --> DK[4. Containers Docker <br> Rootless / Hardened]
    end

1. 🌐 Desativação Proativa de IPv6 (Curto/Médio Prazo)

Para eliminar vetores de bypass acidentais de firewall e reduzir a complexidade da superfície de ataque, o suporte a IPv6 é totalmente desativado em todas as VPSs.

  • Ações de Configuração: Para desativar em tempo de execução e garantir persistência pós-reboot, o arquivo /etc/sysctl.d/99-disable-ipv6.conf deve ser criado com as seguintes diretivas:

    net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

    Comando para aplicar imediatamente: sudo sysctl --system

  • Gatilhos para Reativação do IPv6: O IPv6 só será reabilitado caso surja uma necessidade real de negócio, tais como:

    • Requisitos de conformidade corporativa (Enterprise Compliance).
    • Integração obrigatória com CDNs IPv6-only ou arquiteturas de borda distribuída (Anycast).
    • Casos em que a reativação exigirá a implementação completa de nftables dual-stack, filtros de Router Advertisement (RA), NDP e SLAAC seguros.

2. 🐋 Isolamento de Redes Docker (Prevenção de Movimentação Lateral)

O uso da rede de ponte padrão (bridge) do Docker é estritamente proibido em produção. Os containers são segmentados em redes de domínios funcionais isolados, limitando severamente o raio de colisão (blast radius) caso um container de aplicação (especialmente bots de CRM/WhatsApp ou navegadores invisíveis) seja comprometido.

🔀 Matriz de Conectividade de Dados (newwhats):

graph TD
    subgraph "VPS 1: Gateway de Borda pública"
        Traefik[Traefik Router]
    end

    subgraph "VPS 5: Camada de Aplicação (newwhats)"
        Express[Backend Express & Socket.IO]
        TempWorker[Temporal Worker]
        NATS[NATS Broker :4222]
        
        Express <--> NATS
        TempWorker <--> Express
    end

    subgraph "Túnel VPN Criptografado (wg0)"
        WG0((Canal Privado WireGuard))
    end

    subgraph "VPS 3: Appliance de Dados Bare-Metal"
        Postgres[(PostgreSQL :5432)]
        Dragonfly[(DragonflyDB :6379)]
        Temporal[(Temporal Server :7233)]
    end

    %% Roteamento Web e Sockets
    Traefik == HTTPS Proxy / Sockets ==> WG0 ==> Express

    %% Conexões de Dados da Aplicação via VPN
    Express ==> WG0 ==> Postgres
    Express ==> WG0 ==> Dragonfly
    TempWorker ==> WG0 ==> Temporal
    Temporal -. Persistência Interna .-> Postgres

    style Postgres fill:#1E293B,stroke:#3B82F6,stroke-width:2px,color:#fff
    style Dragonfly fill:#1E293B,stroke:#10B981,stroke-width:2px,color:#fff
    style Temporal fill:#1E293B,stroke:#F59E0B,stroke-width:2px,color:#fff
  • Diretrizes de Conectividade:
    • Tráfego de Borda: O Traefik na VPS 1 encaminha o tráfego HTTP/HTTPS e conexões persistentes do Socket.IO diretamente para a VPS 5 (10.99.0.5) pela interface de túnel criptografado, mantendo as portas da VPS 5 públicas totalmente fechadas.
    • Persistência de Negócio (Prisma + Knex): Ambas as ORMs/Query Builders centralizadas na VPS 5 apontam diretamente para o IP interno 10.99.0.3:5432 da VPS 3.
    • Cache e Estados Rápidos: O DragonflyDB na VPS 3 atende instantaneamente às solicitações de sessões e QR codes da VPS 5 via 10.99.0.3:6379, provendo tempos de resposta na faixa de microssegundos sem concorrência local de CPU.
    • Workflows Assíncronos: O Temporal Server processa o agendamento de tarefas e status de reputação na VPS 3, enquanto o Temporal Worker na VPS 5 consome e executa as atividades pesadas locais da aplicação.

3. 🔑 Zero-Trust Interno no WireGuard (ACLs no Firewall)

A rede VPN WireGuard (10.99.0.0/24) deixa de ser tratada como uma zona de confiança irrestrita. Implementa-se uma política de privilégio mínimo na comunicação entre os servidores da VPN.

  • O Problema de Movimentação Lateral: Se a máquina de desenvolvimento/dev (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados.

  • Regras de Isolamento Lateral (Exemplo no Firewall da VPS 3):

    # Bloquear por padrão toda conexão vinda da VPN exceto as estritamente autorizadas:
- Permitir VPS 1 (Produção) -> Porta 5432 (PostgreSQL)                       [ACEITAR]
- Permitir VPS 5 (CRM)       -> Porta 5432 (PostgreSQL)                       [ACEITAR]
- Permitir VPS 4 (Dev)   -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR]
- Permitir VPS 4 (Dev)   -> VPS 3 (Produção - Outras portas / serviços)   [BLOQUEAR]

4. 🎛️ Migração de Borda: nftables + CrowdSec

Substitui-se a pilha clássica e reativa do iptables / Fail2Ban por uma arquitetura ativa, dinâmica e de alta performance na VPS pública 1.

  • Por que nftables? A sintaxe nativa do nftables permite a criação de conjuntos dinâmicos (sets) de IP de forma extremamente eficiente, processados diretamente no kernel com consumo mínimo de CPU durante ataques volumétricos.
  • Por que CrowdSec? Diferente do Fail2Ban (que analisa logs localmente e de forma reativa por expressões regulares), o CrowdSec utiliza detecção baseada em comportamentos locais de ataque e sincroniza uma base global de reputação de IPs (inteligência coletiva). Se um IP atacou outra infraestrutura na internet, ele é bloqueado na sua VPS antes mesmo de fazer a primeira requisição ao seu Traefik.

5. 💔 Mitigação do Ponto Único de Falha (SPOF) da VPS 1

Atualmente, a VPS 1 acumula as funções de Gateway de Borda (Traefik), Hub Central de VPN (WireGuard) e Hospedagem de Aplicações.

  • Visão de Evolução Futura: Para eliminar o risco de interrupção total dos serviços em caso de queda da VPS 1, planeja-se a separação física de responsabilidades em médio prazo:
    1. VPS Edge Dedicated: Uma máquina leve rodando exclusivamente o gateway de entrada (Traefik), nftables e o concentrador WireGuard.
    2. VPS App Dedicated: Servidores internos que hospedam as aplicações (sem expor portas SSH ou HTTP à internet), consumindo tráfego encaminhado diretamente pelo Gateway da Edge.

6. 🔒 Hardening Avançado de Containers

Para garantir que a invasão de um container não resulte no comprometimento do sistema operacional host, aplicam-se as seguintes diretrizes de segurança no provisionamento de containers Docker:

  • No-New-Privileges: Impede que processos dentro do container ganhem novos privilégios via binários setuid ou setgid.
  • Read-Only Root Filesystem: Monta o sistema de arquivos do container como apenas leitura, forçando gravações temporárias apenas em volumes declarados ou /tmp na memória (tmpfs).
  • CAP Drop: Remove capacidades de sistema desnecessárias ao container (ex: NET_ADMIN, SYS_ADMIN, SYS_CHROOT).
  • Rootless Containers: Sempre que suportado pela aplicação, os containers devem rodar com IDs de usuário não privilegiados (non-root).
Reference in New Issue View Git Blame Copy Permalink