# 📐 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.

```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.
* **Tecnologias**: Docker, Docker Compose, PostgreSQL 18 (Standby Replica em Container).
* **Vantagens de Segurança & Performance**:
  * **Replicação Streaming Real-Time (Staging)**: 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
```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), exceto para o fluxo estritamente necessário de replicação de dados.

* **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)   -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR]
  - Permitir VPS 4 (Staging)   -> VPS 3 (Produção - Outras portas / serviços)   [BLOQUEAR]
  ```

* **🌐 DNS e Acesso Seguro à Internet no WireGuard**:
  Na topologia estrela (*Hub-and-Spoke*), as VPSs clientes utilizam o túnel estritamente para tráfego privado (`AllowedIPs = 10.99.0.0/24`). Para evitar que as máquinas fiquem offline ou sem resolução de nomes (DNS Timeouts), aplica-se a seguinte diretriz de design:
  * **Omissão da Diretiva `DNS`**: Os arquivos `wg0.conf` dos clientes (**nunca**) devem declarar a diretiva `DNS = 1.1.1.1` ou similar.
  * **Explicação**: Se declarada, o gerenciador `systemd-resolved` tenta forçar as consultas de DNS pela interface virtual `wg0`. Como os servidores DNS são IPs públicos fora da faixa `10.99.0.0/24`, as consultas de DNS são descartadas pela criptografia do túnel, deixando o sistema e quaisquer agentes de IA totalmente incapazes de resolver nomes de internet e APIs externas.
  * **Padrão Correto**: Remover a linha `DNS` das interfaces dos clientes para que as consultas de internet continuem sendo resolvidas instantaneamente via interface pública de uplink (`eth0`), mantendo a conectividade do host estável.

---

### 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 de Privilégios Mínimos (Zero-Root) e Containers
Como princípio fundamental de segurança de toda a infraestrutura, **absolutamente nada e ninguém deve rodar ou possuir privilégios de `root`**, especialmente os ambientes de containers Docker e serviços locais. O privilégio de superusuário (`root`) é restrito exclusivamente ao administrador humano de forma temporária e monitorada via comandos `sudo` específicos.

* **🚫 Política de Zero-Root Geral**:
  * É expressamente proibido rodar serviços, scripts personalizados, bancos de dados, crons ou ferramentas de monitoramento como `root`. 
  * Todos os softwares do host devem rodar sob contas de sistema dedicadas e não privilegiadas (ex: usuário `deploy`, `postgres`, `git`, etc.).

* **🐋 Hardening Estrito no Docker**:
  * **Docker Rootless Mode**: O motor do Docker Daemon deve ser instalado e operado no modo **Rootless** (sem privilégios de root no host). Isso garante que, mesmo que ocorra uma vulnerabilidade severa de escape de container ou comprometimento do daemon do Docker, o atacante ganhará apenas privilégios de um usuário comum e sem direitos administrativos no servidor principal.
  * **Uso Obrigatório de Usuários Não Privilegiados (`USER`)**: É obrigatório declarar um usuário não root (ex: `USER node` ou `USER 1000:1000`) nas etapas finais de construção de todas as imagens Docker e arquivos `docker-compose.yml`. Nenhum processo interno de container pode rodar como UID `0` (root).
  * **No-New-Privileges**: Todos os containers devem subir com a flag `--security-opt=no-new-privileges` ativa, impedindo que processos internos ganhem novos privilégios via binários `setuid` ou `setgid`.
  * **Read-Only Root Filesystem**: O sistema de arquivos raiz do container deve ser montado como apenas leitura (`read_only: true`), limitando qualquer escrita temporária estritamente a volumes efêmeros montados em memória (`tmpfs`).
  * **CAP Drop**: O container deve descartar todas as capacidades administrativas padrão do Linux Kernel (`cap_drop: [ "ALL" ]`) e habilitar estritamente apenas o mínimo necessário para a sua execução lógica básica.

---

### 7. 🔗 Sincronização e Orquestração de Estado no Gitea
Como os agentes de IA operam sob restrições rígidas de movimentação lateral Zero-Trust (sem permissões de SSH automático irrestrito entre as VPSs), o Gitea atua como o orquestrador assíncrono de estado e documentação da infraestrutura.

* **Sincronização Física do Arquivo `authorized_keys`**:
  Ao gerenciar ou inserir chaves públicas (`Deploy Keys` ou `Public Keys` de usuários) diretamente no banco de dados do Gitea (`PostgreSQL:giteadb`) ou por rotinas externas, a tabela do banco de dados sincroniza, mas o arquivo de chaves autorizado físico do daemon de SSH do Gitea (porta 2222) não é reescrito de forma imediata. Isso gera erros de rejeição de chave SSH nos clientes durante tentativas de `git clone` ou `git pull`.
* **Solução via Gitea CLI**:
  Para reescrever de forma limpa e forçada o arquivo físico de chaves SSH autorizadas e restabelecer imediatamente a sincronização de agentes e repositórios sem necessidade de intervenção humana ou cliques manuais na interface web, executa-se o utilitário nativo de administração de dentro do host do Gitea (VPS 3):
  ```bash
  sudo -u git GITEA_WORK_DIR=/var/lib/gitea /usr/local/bin/gitea --config /etc/gitea/app.ini admin regenerate keys
  ```
