VPS 4 Builder
131d4060fb
- seguranca_deploy_user.md: corrige Pilar 2 — adiciona aviso crítico sobre grupo docker em instalações rootless, documenta estado correto da VPS 1 e registra incidente de 2026-05-14 com causa raiz e comandos de correção - scoreodonto/deploy.md: adiciona seção de alerta Docker Duplo com sintoma porta 8020 bloqueada por docker-proxy zumbi e diagnóstico/solução - clube67/arquitetura.md: adiciona regra crítica de Docker Rootless na VPS 1 com tabela de restrições e verificação de saúde pós-manutenção Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
307 lines
18 KiB
Markdown
307 lines
18 KiB
Markdown
# 📐 Arquitetura de Rede e Topologia de Servidores (Clube67 / NewWhats)
|
|
|
|
> [!WARNING]
|
|
> **REGRAS DE ISOLAMENTO (MULTI-TENANT)**
|
|
> Este documento dita a arquitetura EXCLUSIVA do ecossistema Clube67 e NewWhats.
|
|
> As informações contidas aqui (como MySQL, redis na porta 6379 índice 0, e uso da VPS 5) **NÃO SE APLICAM** ao ScoreOdonto ou outros projetos.
|
|
|
|
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.
|
|
|
|
```mermaid
|
|
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> (Staging / 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 (Staging)
|
|
* **Função Principal**: Testar novos recursos, hospedar containers de staging 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.
|
|
* **Vantagens de Segurança & Performance**:
|
|
* **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
|
|
```mermaid
|
|
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:
|
|
```text
|
|
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):
|
|
|
|
```mermaid
|
|
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/staging (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).
|
|
|
|
* **Regras de Isolamento Lateral (Exemplo no Firewall da VPS 3)**:
|
|
```text
|
|
# 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 (Staging) -> VPS 3 (Produção) [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).
|
|
|
|
### ⚠️ Regra Crítica — Docker Rootless na VPS 1
|
|
|
|
A VPS 1 roda **Docker Rootless** (daemon como usuário `deploy`, socket em `/run/user/1000/docker.sock`). O daemon root (`docker.service`) está **desabilitado permanentemente**.
|
|
|
|
| Regra | Motivo |
|
|
|-------|--------|
|
|
| `docker.service` deve permanecer `disabled` | Daemon root + `deploy` no grupo `docker` = escalonamento de privilégios trivial |
|
|
| `deploy` NÃO deve estar no grupo `docker` | Grupo `docker` dá acesso ao socket root; basta omitir `DOCKER_HOST` para criar containers root |
|
|
| Todo script que roda na VPS 1 deve usar `DOCKER_HOST` explícito | SSH não herda variáveis de ambiente do shell do usuário por padrão |
|
|
|
|
```bash
|
|
# Verificação de saúde — executar após qualquer manutenção na VPS 1
|
|
sudo systemctl status docker # deve estar: inactive (dead)
|
|
groups deploy # não deve conter "docker"
|
|
DOCKER_HOST=unix:///run/user/1000/docker.sock docker ps # deve listar os containers ativos
|
|
```
|
|
|
|
> [!WARNING]
|
|
> Se o `docker.service` for reativado acidentalmente (ex: `apt upgrade` do pacote docker.io), ele voltará como enabled. Verificar após atualizações de sistema.
|
|
|
|
---
|
|
|
|
## 🤖 Fluxo de Auto-Cura (Self-Healing) com Grafana/Gitea
|
|
|
|
O Clube67 / NewWhats utiliza um fluxo GitOps de Auto-Cura para detecção e mitigação autônoma de falhas. Quando ocorrem falhas críticas de execução no container, o Grafana deve enviar um webhook para a Gitea-Bridge.
|
|
|
|
Para configurar alertas de auto-cura no Grafana:
|
|
1. Acesse o **Grafana** e crie uma nova regra de alerta baseada em LogQL (Loki) do container afetado.
|
|
2. Na seção de **Labels**, você **não precisa** definir a label `repo`, pois o `clube67_newwhats.local` é o repositório padrão de fallback da Bridge.
|
|
3. Roteie a notificação para o Contact Point `Gitea-Bridge`.
|
|
|
|
Assim que a falha disparar, a Gitea-Bridge multi-tenant criará uma Issue automática com o prefixo `🚨 [AUTO-BUG]` no repositório `clube67_newwhats.local`, contendo todo o stack trace para o Agente IA realizar a manutenção e o hotfix.
|
|
|
|
---
|
|
|
|
## 🔄 Fluxo de Deploy Contínuo e Versionamento Automático (+1)
|
|
No ecossistema do **Clube67 / NewWhats**, o webhook escuta na porta `9000` na VPS 4 e aciona a automação de compilação e rsync para a VPS 1.
|
|
|
|
### 📦 Regras Obrigatórias de Incremento de Versão (Build Bump)
|
|
Para assegurar que a interface web do painel exiba sempre a versão real compilada e que o histórico de deploys em `deploys.json` avance de forma autônoma:
|
|
|
|
1. O script `update-version.js` deve ser mantido na raiz do projeto.
|
|
2. No arquivo `frontend/package.json`, o comando de build DEVE ser rigorosamente configurado como:
|
|
```json
|
|
"scripts": {
|
|
"build": "node ../update-version.js && next build"
|
|
}
|
|
```
|
|
|
|
### 🐳 Regra de Contexto Docker
|
|
1. O **Build Context** no `docker-compose.yml` deve obrigatoriamente apontar para a raiz do projeto (`context: .`).
|
|
2. O `Dockerfile` do frontend deve copiar os arquivos da raiz e definir o `WORKDIR` apropriado.
|
|
|
|
> [!WARNING]
|
|
> **COMPORTAMENTO DE VERSIONAMENTO NO DOCKER**
|
|
> O incremento do `+1` ocorre dentro do container isolado durante a compilação na VPS 4. A nova versão aparecerá instantaneamente no ar, mas os arquivos no repositório Git não sofrerão commit automático. Em lançamentos de grandes releases (ex: `V2.0.0`), o desenvolvedor deve realizar o bump manual no VSCode antes de disparar o webhook.
|