feat: sincronização de desenvolvimento local da VPS 4 para o Gitea
This commit is contained in:
VPS 4 Deploy Agent
@@ -0,0 +1,5 @@
|
||||
# Ignorar arquivos de configuração sensíveis locais se copiados acidentalmente
|
||||
gcal_key.json
|
||||
ssh_alerts_config.json
|
||||
*.log
|
||||
.DS_Store
|
||||
@@ -0,0 +1,247 @@
|
||||
# 📐 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]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 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).
|
||||
@@ -0,0 +1,152 @@
|
||||
# 📂 Guia de Compartilhamento da Pasta de Instruções entre VPSs
|
||||
|
||||
Este documento descreve as melhores estratégias e o passo a passo técnico para que **agentes (humanos, automatizados ou IA)** em outras VPSs da sua rede segura (`10.99.0.0/24`) tenham acesso de leitura e escrita à pasta `/home/deploy/instrucoes`.
|
||||
|
||||
Como você já possui uma infraestrutura de rede privada criptografada baseada em **WireGuard**, podemos aproveitar essa segurança para compartilhar os arquivos de forma extremamente protegida e eficiente.
|
||||
|
||||
---
|
||||
|
||||
## 🗺️ Tabela Comparativa de Abordagens
|
||||
|
||||
| Abordagem | Tipo | Sincronização | Segurança | Complexidade | Recomendação |
|
||||
| :--- | :--- | :--- | :--- | :--- | :--- |
|
||||
| **1. Git Privado** | Repositório | Manual / CI-CD | 🟢 **Máxima** (Chaves SSH) | 🟡 Baixa | **Altamente Recomendado** para desenvolvimento e IA |
|
||||
| **2. Syncthing** | P2P Ativo | Instantânea | 🟢 **Excelente** (TLS + VPN) | 🟡 Média | **Ideal** para espelhamento em tempo real bidirecional |
|
||||
| **3. SSHFS** | Mount Direto | Sob demanda | 🟢 **Excelente** (SSH s/ VPN) | 🟢 Muito Baixa | **Excelente** para montagem rápida sem duplicar arquivos |
|
||||
| **4. Rsync + Cron** | Script Push/Pull | Periódica | 🟢 **Excelente** (SSH) | 🟢 Muito Baixa | Para espelhamento simples de leitura apenas |
|
||||
|
||||
---
|
||||
|
||||
## 🕸️ Opção 1: Repositório Git Privado (Recomendado para Agentes & IA)
|
||||
|
||||
Esta é a abordagem padrão da indústria. Em vez de compartilhar a pasta fisicamente via rede (o que gera dependência de conexão direta), transformamos a pasta `instrucoes` em um **repositório Git privado** (ex: no GitHub ou GitLab).
|
||||
|
||||
### Como funciona:
|
||||
Cada VPS possui um clone local em `/home/deploy/instrucoes`. Quando um agente ou você altera algo, faz um `git commit` e `git push`. As outras VPSs fazem `git pull`.
|
||||
|
||||
### Vantagens para Agentes de IA:
|
||||
Os agentes de IA (como o Antigravity e outros) lidam nativamente de forma excelente com comandos Git. Isso garante controle de versão, histórico de quem alterou o quê, facilidade de rollback e elimina riscos de corrupção de arquivos por escrita simultânea.
|
||||
|
||||
### Passo a Passo de Configuração:
|
||||
|
||||
1. **Inicializar o Git localmente na máquina de origem (ex: VPS 1):**
|
||||
```bash
|
||||
cd /home/deploy/instrucoes
|
||||
git init
|
||||
# Adicionar um .gitignore para ignorar arquivos temporários ou chaves sensíveis que não devem subir
|
||||
echo "gcal_key.json" >> .gitignore
|
||||
echo "ssh_alerts_config.json" >> .gitignore
|
||||
git add .
|
||||
git commit -m "feat: commit inicial das instrucoes"
|
||||
```
|
||||
|
||||
2. **Criar um Repositório Privado** no GitHub/GitLab.
|
||||
|
||||
3. **Gerar chaves de acesso SSH (Deploy Keys) nas outras VPSs:**
|
||||
Em cada VPS que precisa de acesso, gere uma chave SSH para o usuário `deploy`:
|
||||
```bash
|
||||
ssh-keygen -t ed25519 -C "vps-instrucoes-deploy" -f ~/.ssh/id_ed25519_github
|
||||
```
|
||||
Adicione a chave pública (`.pub`) gerada como **Deploy Key** (com permissão de escrita, se necessário) nas configurações do repositório no GitHub.
|
||||
|
||||
4. **Clonar o repositório nas outras VPSs:**
|
||||
```bash
|
||||
cd /home/deploy
|
||||
git clone git@github.com:seu-usuario/seu-repositorio.git instrucoes
|
||||
```
|
||||
|
||||
5. **Automatizar o Pull (Opcional):**
|
||||
Se quiser que as outras VPSs atualizem as instruções automaticamente sempre que houver mudanças no repositório remoto, configure um cronjob de 5 em 5 minutos para rodar o pull:
|
||||
```bash
|
||||
crontab -e
|
||||
# Adicione a linha abaixo:
|
||||
*/5 * * * * cd /home/deploy/instrucoes && git pull origin main > /dev/null 2>&1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Opção 2: Syncthing (Sincronização em Tempo Real Descentralizada)
|
||||
|
||||
O **Syncthing** é um serviço peer-to-peer de sincronização contínua de arquivos. Ele roda como um daemon leve nas VPSs e garante que qualquer arquivo criado ou modificado em uma pasta seja propagado instantaneamente para as outras em questão de segundos.
|
||||
|
||||
### Como configurar de forma segura via VPN WireGuard:
|
||||
|
||||
1. **Instalar o Syncthing em todas as VPSs:**
|
||||
```bash
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y syncthing
|
||||
```
|
||||
|
||||
2. **Configurar para escutar apenas no IP da VPN (Zero-Trust):**
|
||||
Edite o arquivo de configuração do Syncthing (gerado após a primeira execução em `~/.config/syncthing/config.xml`) e ajuste o endereço da interface gráfica e de sincronização para rodar apenas nos IPs locais ou de VPN, prevenindo exposição pública.
|
||||
* Altere a linha do GUI para escutar localmente: `<address>127.0.0.1:8384</address>` (Você pode acessar usando um túnel SSH do seu notebook: `ssh -L 8384:127.0.0.1:8384 deploy@10.99.0.1`).
|
||||
|
||||
3. **Adicionar os Servidores como Peers:**
|
||||
* No painel do Syncthing da VPS 1, copie o **Device ID**.
|
||||
* Adicione esse Device ID no painel da VPS 4/5, especificando o endereço fixo da VPN (ex: `tcp://10.99.0.1:22000`).
|
||||
* Compartilhe a pasta `/home/deploy/instrucoes` entre eles.
|
||||
|
||||
4. **Habilitar o Serviço na inicialização:**
|
||||
```bash
|
||||
sudo systemctl enable syncthing@deploy.service
|
||||
sudo systemctl start syncthing@deploy.service
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Opção 3: SSHFS (Montagem de Pasta sobre SSH na VPN)
|
||||
|
||||
O **SSHFS** permite montar um diretório remoto de um servidor em outro servidor de forma transparente, utilizando o próprio protocolo SSH de transporte. Como a sua porta SSH (22) está aberta e protegida dentro da rede privada da VPN (`10.99.0.0/24`), este método é extremamente simples e não exige serviços extras rodando em segundo plano além do próprio SSH.
|
||||
|
||||
### Como configurar:
|
||||
|
||||
Digamos que a pasta física está na **VPS 1 (IP `10.99.0.1`)** e você deseja acessá-la em tempo real na **VPS 4 (IP `10.99.0.4`)**:
|
||||
|
||||
1. **Instalar o SSHFS na VPS de destino (ex: VPS 4):**
|
||||
```bash
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y sshfs
|
||||
```
|
||||
|
||||
2. **Garantir que o usuário `deploy` da VPS 4 tem acesso SSH sem senha à VPS 1:**
|
||||
Adicione a chave SSH pública (`~/.ssh/id_ed25519.pub`) do usuário `deploy` da VPS 4 no arquivo `/home/deploy/.ssh/authorized_keys` da VPS 1.
|
||||
|
||||
3. **Criar a pasta de montagem na VPS de destino (VPS 4):**
|
||||
```bash
|
||||
mkdir -p /home/deploy/instrucoes
|
||||
```
|
||||
|
||||
4. **Montar o diretório manualmente para testar:**
|
||||
```bash
|
||||
sshfs deploy@10.99.0.1:/home/deploy/instrucoes /home/deploy/instrucoes -o IdentityFile=/home/deploy/.ssh/id_ed25519 -o allow_other -o reconnect -o ServerAliveInterval=15
|
||||
```
|
||||
|
||||
5. **Tornar a montagem permanente pós-reboot (fstab):**
|
||||
Adicione a seguinte linha ao final do arquivo `/etc/fstab` na VPS de destino:
|
||||
```text
|
||||
deploy@10.99.0.1:/home/deploy/instrucoes /home/deploy/instrucoes fuse.sshfs x-systemd.automount,IdentityFile=/home/deploy/.ssh/id_ed25519,allow_other,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,_netdev 0 0
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Opção 4: Rsync Automatizado via Cron (Espelhamento Simples)
|
||||
|
||||
Se os agentes nas outras VPSs precisam apenas ler as instruções ou executar instaladores (como o `install.sh`) e você quer uma solução extremamente leve e direta sem montagens de disco.
|
||||
|
||||
### Script de sincronização unidirecional (VPS 1 -> VPS de Destino):
|
||||
|
||||
Na **VPS 1**, crie um script simples ou configure uma tarefa recorrente no Cron para enviar as atualizações:
|
||||
|
||||
```bash
|
||||
# Sincroniza a pasta de instruções para a VPS 4 através da VPN segura
|
||||
rsync -avz --delete -e "ssh -i /home/deploy/.ssh/id_ed25519" /home/deploy/instrucoes/ deploy@10.99.0.4:/home/deploy/instrucoes/
|
||||
```
|
||||
|
||||
Você pode programar isso para rodar a cada hora ou a cada 15 minutos de forma silenciosa e imperceptível.
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Veredito: Qual escolher?
|
||||
|
||||
* **Escolha o Git Privado (Opção 1)** se você deseja que múltiplos agentes (incluindo IAs) façam alterações nos scripts e nos documentos de forma colaborativa, sem riscos de conflitos cegos de escrita e mantendo histórico de auditoria perfeito.
|
||||
* **Escolha o SSHFS (Opção 3)** se você quer facilidade máxima de implementação imediata: a pasta fica unificada, consome armazenamento físico de apenas uma máquina e reflete edições instantaneamente sem sincronizações adicionais.
|
||||
Executable
+192
@@ -0,0 +1,192 @@
|
||||
#!/bin/bash
|
||||
# ==============================================================================
|
||||
# 🚀 SCRIPT DE INSTALAÇÃO UNIFICADA: ALERTAS SSH (GCAL + TELEGRAM + PAM)
|
||||
# ==============================================================================
|
||||
# Este script automatiza o deploy completo da arquitetura de monitoramento em
|
||||
# qualquer VPS da rede. Ele configura o PAM, Python, Telegram e Banners.
|
||||
# ==============================================================================
|
||||
|
||||
# Cores para formatação de saída
|
||||
RED='\033[0;31m'
|
||||
GREEN='\033[0;32m'
|
||||
YELLOW='\033[1;33m'
|
||||
NC='\033[0m' # Sem Cor
|
||||
|
||||
echo -e "${YELLOW}========================================================================${NC}"
|
||||
echo -e "${YELLOW} 🛡️ MONITORAMENTO SSH AUTOMÁTICO - INSTALADOR DE DEPLOY ${NC}"
|
||||
echo -e "${YELLOW}========================================================================${NC}"
|
||||
|
||||
# 1. Verificar se é root
|
||||
if [ "$EUID" -ne 0 ]; then
|
||||
echo -e "${RED}Erro: Este script precisa ser executado como root (sudo ./install.sh).${NC}"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 2. Captura de Parâmetro de VPS (IP ou Nome)
|
||||
VPS_PREFIX=""
|
||||
while [[ "$#" -gt 0 ]]; do
|
||||
case $1 in
|
||||
--vps) VPS_PREFIX="$2"; shift ;;
|
||||
*) echo "Parâmetro desconhecido: $1"; exit 1 ;;
|
||||
esac
|
||||
shift
|
||||
done
|
||||
|
||||
# Se não foi passado --vps, tenta auto-detectar o IP da interface wg0 (VPN) ou eth0
|
||||
if [ -z "$VPS_PREFIX" ]; then
|
||||
echo -e "${YELLOW}Auto-detectando o IP da VPS...${NC}"
|
||||
# Tenta pegar o IP da interface wg0 primeiro
|
||||
VPS_PREFIX=$(ip -o -4 addr show dev wg0 2>/dev/null | awk '{split($4,a,"/"); print a[1]}')
|
||||
|
||||
if [ -z "$VPS_PREFIX" ]; then
|
||||
# Tenta pegar o IP da interface eth0
|
||||
VPS_PREFIX=$(ip -o -4 addr show dev eth0 2>/dev/null | awk '{split($4,a,"/"); print a[1]}')
|
||||
fi
|
||||
fi
|
||||
|
||||
if [ -z "$VPS_PREFIX" ]; then
|
||||
VPS_PREFIX="127.0.0.1"
|
||||
fi
|
||||
|
||||
echo -e "${GREEN}✅ Prefixo/IP Identificado para esta VPS: ${YELLOW}$VPS_PREFIX${NC}"
|
||||
|
||||
# 3. Instalação de Dependências
|
||||
echo -e "\n${YELLOW}[Passo 1/6] Instalando pacotes e dependências (Apt)...${NC}"
|
||||
apt-get update -qq
|
||||
apt-get install -y -qq python3-googleapi curl
|
||||
echo -e "${GREEN}✅ Pacotes instalados com sucesso.${NC}"
|
||||
|
||||
# 4. Criar Chave de Conta de Serviço se não existir
|
||||
echo -e "\n${YELLOW}[Passo 2/6] Verificando chave da Conta de Serviço Google Cloud...${NC}"
|
||||
if [ ! -f "/etc/ssh/gcal_key.json" ]; then
|
||||
echo -e "${YELLOW}⚠️ Aviso: O arquivo /etc/ssh/gcal_key.json não foi encontrado.${NC}"
|
||||
echo -e "${YELLOW}Por favor, certifique-se de salvar a chave JSON da conta de serviço em /etc/ssh/gcal_key.json e aplicar as permissões corretas.${NC}"
|
||||
else
|
||||
echo -e "${GREEN}✅ Chave da Conta de Serviço detectada em /etc/ssh/gcal_key.json.${NC}"
|
||||
chown root:deploy /etc/ssh/gcal_key.json 2>/dev/null || chown root:root /etc/ssh/gcal_key.json
|
||||
chmod 640 /etc/ssh/gcal_key.json
|
||||
fi
|
||||
|
||||
# 5. Criar arquivo de configurações se não existir
|
||||
echo -e "\n${YELLOW}[Passo 3/6] Criando arquivo de configurações centralizadas (/etc/ssh/ssh_alerts_config.json)...${NC}"
|
||||
if [ ! -f "/etc/ssh/ssh_alerts_config.json" ]; then
|
||||
cat <<EOF > /etc/ssh/ssh_alerts_config.json
|
||||
{
|
||||
"telegram_token": "8641435108:AAGL3rOiVj1GpYAyUi4D-pdeDJ9K_JUdlgM",
|
||||
"telegram_chat_id": "",
|
||||
"calendar_id": "385857c79ef3aed0f4923b29007637a8b7764d6f8359959500bce27611833f5d@group.calendar.google.com"
|
||||
}
|
||||
EOF
|
||||
echo -e "${GREEN}✅ Arquivo de configurações criado.${NC}"
|
||||
else
|
||||
echo -e "${GREEN}✅ Arquivo de configurações já existe. Mantendo configurações atuais.${NC}"
|
||||
fi
|
||||
chown root:deploy /etc/ssh/ssh_alerts_config.json 2>/dev/null || chown root:root /etc/ssh/ssh_alerts_config.json
|
||||
chmod 640 /etc/ssh/ssh_alerts_config.json
|
||||
|
||||
# 6. Criar Scripts Integradores no Servidor
|
||||
echo -e "\n${YELLOW}[Passo 4/6] Configurando scripts integradores em /usr/local/bin/...${NC}"
|
||||
|
||||
# Copia ou escreve o script principal Python
|
||||
if [ -f "ssh_gcal_alert.py" ]; then
|
||||
cp ssh_gcal_alert.py /usr/local/bin/ssh_gcal_alert.py
|
||||
else
|
||||
# Escreve o arquivo diretamente se rodando solto
|
||||
curl -s https://raw.githubusercontent.com/sua-uri-ou-copia-local/ssh_gcal_alert.py -o /usr/local/bin/ssh_gcal_alert.py 2>/dev/null
|
||||
fi
|
||||
chown root:root /usr/local/bin/ssh_gcal_alert.py
|
||||
chmod 755 /usr/local/bin/ssh_gcal_alert.py
|
||||
|
||||
# Copia ou escreve o script do instalador Telegram
|
||||
if [ -f "ssh_alert_setup_telegram.py" ]; then
|
||||
cp ssh_alert_setup_telegram.py /usr/local/bin/ssh_alert_setup_telegram.py
|
||||
else
|
||||
curl -s https://raw.githubusercontent.com/sua-uri-ou-copia-local/ssh_alert_setup_telegram.py -o /usr/local/bin/ssh_alert_setup_telegram.py 2>/dev/null
|
||||
fi
|
||||
chown root:root /usr/local/bin/ssh_alert_setup_telegram.py
|
||||
chmod 755 /usr/local/bin/ssh_alert_setup_telegram.py
|
||||
|
||||
# Criar o gatilho do PAM dinamicamente com o VPS_PREFIX correto
|
||||
cat <<EOF > /usr/local/bin/ssh_pam_trigger.sh
|
||||
#!/bin/bash
|
||||
# Executa apenas se o estágio do PAM for 'open_session' e o serviço for o 'sshd'
|
||||
if [ "\$PAM_TYPE" = "open_session" ] && [ "\$PAM_SERVICE" = "sshd" ]; then
|
||||
USER_LOGIN="\$PAM_USER"
|
||||
IP_LOGIN="\$PAM_RHOST"
|
||||
DATE_LOGIN=\$(date "+%Y-%m-%d %H:%M:%S")
|
||||
|
||||
# Se o IP vier vazio (comum em alguns túneis locais), assume localhost
|
||||
if [ -z "\$IP_LOGIN" ]; then
|
||||
IP_LOGIN="127.0.0.1"
|
||||
fi
|
||||
|
||||
# Validação de IP seguro da VPN
|
||||
if [[ ! "\$IP_LOGIN" =~ ^10\.99\.0\. ]]; then
|
||||
AVISO_INDEVIDO="🚨 ALERTA: Acesso fora da rede VPN segura detectado!"
|
||||
else
|
||||
AVISO_INDEVIDO="✅ Acesso autorizado através da rede VPN segura."
|
||||
fi
|
||||
|
||||
# Dispara o script Python de calendário e Telegram em segundo plano
|
||||
/usr/local/bin/ssh_gcal_alert.py --vps "$VPS_PREFIX" --user "\$USER_LOGIN" --ip "\$IP_LOGIN" --status "\$AVISO_INDEVIDO" > /dev/null 2>&1 &
|
||||
fi
|
||||
EOF
|
||||
chown root:root /usr/local/bin/ssh_pam_trigger.sh
|
||||
chmod 755 /usr/local/bin/ssh_pam_trigger.sh
|
||||
echo -e "${GREEN}✅ Scripts integradores configurados e autorizados.${NC}"
|
||||
|
||||
# 7. Configurar o PAM
|
||||
echo -e "\n${YELLOW}[Passo 5/6] Configurando o subsistema PAM para SSH (/etc/pam.d/sshd)...${NC}"
|
||||
PAM_LINE="session optional pam_exec.so type=open_session /usr/local/bin/ssh_pam_trigger.sh"
|
||||
|
||||
if grep -q "ssh_pam_trigger.sh" /etc/pam.d/sshd; then
|
||||
echo -e "${GREEN}✅ PAM para SSH já está devidamente configurado (ignorado para evitar duplicidade).${NC}"
|
||||
else
|
||||
echo "$PAM_LINE" >> /etc/pam.d/sshd
|
||||
echo -e "${GREEN}✅ Gatilho do PAM anexado com sucesso ao fim do arquivo /etc/pam.d/sshd.${NC}"
|
||||
fi
|
||||
|
||||
# 8. Configurar o Banner Visual do Terminal (profile.d)
|
||||
echo -e "\n${YELLOW}[Passo 6/6] Configurando banner visual de auditoria no terminal (/etc/profile.d/ssh_alert.sh)...${NC}"
|
||||
cat <<EOF > /etc/profile.d/ssh_alert.sh
|
||||
#!/bin/bash
|
||||
# Script de Banner de Auditoria SSH
|
||||
|
||||
USER_LOGIN=\$USER
|
||||
IP_LOGIN=\$(echo \$SSH_CONNECTION | awk '{print \$1}')
|
||||
DATE_LOGIN=\$(date "+%Y-%m-%d %H:%M:%S")
|
||||
|
||||
# Validação de IP seguro da VPN (10.99.0.X)
|
||||
if [[ ! "\$IP_LOGIN" =~ ^10\.99\.0\. ]]; then
|
||||
AVISO_INDEVIDO="🚨 ALERTA: Acesso fora da rede VPN segura detectado!"
|
||||
else
|
||||
AVISO_INDEVIDO="✅ Acesso autorizado através da rede VPN segura."
|
||||
fi
|
||||
|
||||
# Exibição do Banner de Auditoria ao Usuário no Terminal
|
||||
echo -e "\033[1;33m"
|
||||
echo "========================================================================="
|
||||
echo " 🖥️ AUDITORIA DE ACESSO SISTÊMICO "
|
||||
echo "========================================================================="
|
||||
echo -e "\033[0m"
|
||||
echo " Usuário Conectado: \$USER_LOGIN"
|
||||
echo " IP de Origem: \$IP_LOGIN"
|
||||
echo " Data do Login: \$DATE_LOGIN"
|
||||
echo " Status do Canal: \$AVISO_INDEVIDO"
|
||||
echo ""
|
||||
echo " * Todas as operações estão sendo monitoradas e auditadas."
|
||||
echo "========================================================================="
|
||||
echo ""
|
||||
EOF
|
||||
chmod 755 /etc/profile.d/ssh_alert.sh
|
||||
echo -e "${GREEN}✅ Banner visual de terminal ativado.${NC}"
|
||||
|
||||
# Finalização e Próximos Passos
|
||||
echo -e "\n${GREEN}========================================================================${NC}"
|
||||
echo -e "${GREEN}🎉 INSTALAÇÃO CONCLUÍDA COM SUCESSO!${NC}"
|
||||
echo -e "${GREEN}========================================================================${NC}"
|
||||
echo -e "\n${YELLOW}👉 PRÓXIMO PASSO (VINCULAR TELEGRAM):${NC}"
|
||||
echo -e "Para receber notificações instantâneas no seu Telegram, execute o comando abaixo"
|
||||
echo -e "como administrador e envie uma mensagem para o seu bot:"
|
||||
echo -e "\n ${GREEN}sudo /usr/local/bin/ssh_alert_setup_telegram.py${NC}\n"
|
||||
echo -e "========================================================================"
|
||||
@@ -0,0 +1,121 @@
|
||||
# 📅 Guia de Implementação: Alertas de SSH no Google Calendar & Telegram
|
||||
|
||||
Este guia fornece o instalador automatizado, scripts de configuração dinâmica e documentação técnica para implantar o sistema de monitoramento, auditoria de logins e alertas em tempo real em qualquer servidor da sua rede (ex: VPS 4, VPS 1, etc.).
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ Como o Sistema Funciona
|
||||
|
||||
Para garantir que **100% de todos os acessos** sejam auditados (incluindo acessos de túneis de portas `-N`, SFTP, conexões VS Code e logins interativos) de forma robusta e assíncrona, o sistema é dividido em dois módulos integrados:
|
||||
|
||||
```text
|
||||
[Login SSH Concluído]
|
||||
│
|
||||
├─► [Gatilho do PAM: /etc/pam.d/sshd] (Intercepta todas as sessões: túneis, VS Code, shell, etc.)
|
||||
│ │
|
||||
│ └─► [Executa em Background: /usr/local/bin/ssh_pam_trigger.sh]
|
||||
│ │
|
||||
│ └─► [Chama: /usr/local/bin/ssh_gcal_alert.py]
|
||||
│ │
|
||||
│ ├─► [Busca GeoIP & ISP] (Cidade, Estado, País e Operadora)
|
||||
│ │
|
||||
│ ├─► [Rate-Limiting / Debounce] (Evita enchentes de alertas em curto tempo)
|
||||
│ │
|
||||
│ ├─► [Local Syslog] (Salva logs localmente em caso de falha de rede)
|
||||
│ │
|
||||
│ ├─► [Telegram Push] ──► Mensagem instantânea no Celular
|
||||
│ │
|
||||
│ └─► [Google Calendar API] ──► Registra Bloco Visual na Agenda
|
||||
│
|
||||
└─► [Sourced: /etc/profile.d/ssh_alert.sh] (Apenas em shells de login interativos)
|
||||
│
|
||||
└─► Exibe Banner de Auditoria Amarelo no Terminal do Usuário
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ⚡ Método Rápido (Recomendado - Instalação em 10 segundos)
|
||||
|
||||
Se você já possui o repositório de instruções em seu servidor, a instalação é totalmente automatizada através do script `install.sh`.
|
||||
|
||||
### Passo 1: Executar o Instalador Automático
|
||||
Acesse a pasta de instruções e execute o instalador como `root` especificando o IP/Prefixo desta nova VPS (ex: `10.99.0.4`):
|
||||
|
||||
```bash
|
||||
sudo ./install.sh --vps "10.99.0.X"
|
||||
```
|
||||
*(O script irá baixar e configurar todas as dependências, permissões, scripts integradores, PAM e o banner visual do terminal automaticamente).*
|
||||
|
||||
### Passo 2: Vincular o seu Chat do Telegram ao Bot
|
||||
Para receber as notificações instantâneas no seu celular através do bot `@AcessosVPSbot`, execute o assistente de emparelhamento automático:
|
||||
|
||||
```bash
|
||||
sudo /usr/local/bin/ssh_alert_setup_telegram.py
|
||||
```
|
||||
|
||||
1. Abra o Telegram no seu celular.
|
||||
2. Pesquise por **`@AcessosVPSbot`** (ou acesse [t.me/AcessosVPSbot](https://t.me/AcessosVPSbot)) e clique em **"Começar"** ou envie `/start`.
|
||||
3. O terminal detectará instantaneamente a sua mensagem, capturará o seu Chat ID, atualizará a configuração do servidor e enviará uma confirmação no seu chat!
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Detalhamento Técnico e Estrutura de Arquivos
|
||||
|
||||
Caso queira entender a estrutura ou realizar alterações manuais, o ecossistema é formado pelos seguintes componentes:
|
||||
|
||||
### 1. Arquivo de Configuração Centralizada (`/etc/ssh/ssh_alerts_config.json`)
|
||||
Guarda as chaves e credenciais de forma segura, com permissões restritas apenas para leitura (`chmod 640` para `root:deploy`).
|
||||
```json
|
||||
{
|
||||
"telegram_token": "8641435108:AAGL3rOiVj1GpYAyUi4D-pdeDJ9K_JUdlgM",
|
||||
"telegram_chat_id": "SEU_CHAT_ID_CAPTURADO_AQUI",
|
||||
"calendar_id": "385857c79ef3aed0f4923b29007637a8b7764d6f8359959500bce27611833f5d@group.calendar.google.com"
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Script de Integração e Decisão (`/usr/local/bin/ssh_gcal_alert.py`)
|
||||
Escrito em Python 3, realiza a chamada da API do Google Calendar e do Telegram, com tratamento de erros integrado no `syslog` local, controle de frequência (Rate-Limiting de 120s para o mesmo usuário/IP) e enriquecimento de GeoIP/ISP.
|
||||
|
||||
### 3. Script de Gatilho do PAM (`/usr/local/bin/ssh_pam_trigger.sh`)
|
||||
Intercepta no nível de kernel/autenticação cada abertura de sessão SSH e envia os dados para o script Python em segundo plano.
|
||||
```bash
|
||||
#!/bin/bash
|
||||
if [ "$PAM_TYPE" = "open_session" ] && [ "$PAM_SERVICE" = "sshd" ]; then
|
||||
USER_LOGIN="$PAM_USER"
|
||||
IP_LOGIN="$PAM_RHOST"
|
||||
DATE_LOGIN=$(date "+%Y-%m-%d %H:%M:%S")
|
||||
|
||||
if [ -z "$IP_LOGIN" ]; then
|
||||
IP_LOGIN="127.0.0.1"
|
||||
fi
|
||||
|
||||
if [[ ! "$IP_LOGIN" =~ ^10\.99\.0\. ]]; then
|
||||
AVISO_INDEVIDO="🚨 ALERTA: Acesso fora da rede VPN segura detectado!"
|
||||
else
|
||||
AVISO_INDEVIDO="✅ Acesso autorizado através da rede VPN segura."
|
||||
fi
|
||||
|
||||
/usr/local/bin/ssh_gcal_alert.py --vps "10.99.0.X" --user "$USER_LOGIN" --ip "$IP_LOGIN" --status "$AVISO_INDEVIDO" > /dev/null 2>&1 &
|
||||
fi
|
||||
```
|
||||
|
||||
### 4. Configuração do PAM (`/etc/pam.d/sshd`)
|
||||
Garante que o gatilho acima seja executado. É adicionada a seguinte linha ao final do arquivo:
|
||||
```text
|
||||
session optional pam_exec.so type=open_session /usr/local/bin/ssh_pam_trigger.sh
|
||||
```
|
||||
|
||||
### 5. Banner de Terminal (`/etc/profile.d/ssh_alert.sh`)
|
||||
Exibe o banner amarelo chamativo de auditoria apenas para usuários conectando de forma convencional via shell de terminal interativo.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Como Testar
|
||||
|
||||
Para certificar-se de que tudo está rodando adequadamente e simular o disparo direto do PAM com busca de GeoIP externa:
|
||||
|
||||
```bash
|
||||
sudo PAM_TYPE=open_session PAM_SERVICE=sshd PAM_USER=deploy PAM_RHOST=8.8.8.8 /usr/local/bin/ssh_pam_trigger.sh
|
||||
```
|
||||
|
||||
O evento correspondente deverá aparecer na sua agenda imediatamente (em vermelho intenso indicando fora da VPN), e uma mensagem push de alerta chegará instantaneamente no seu Telegram!
|
||||
@@ -0,0 +1,72 @@
|
||||
# 🤖 Protocolo Gitea Swarm (PGS): Coordenação de Multi-Agentes em Ambiente Multi-VPS
|
||||
|
||||
Este documento estabelece o protocolo de comunicação padrão, obrigatório e imutável para todos os Agentes de Inteligência Artificial (IAs) que atuarem no gerenciamento, desenvolvimento ou manutenção da infraestrutura do **Clube67** distribuída em múltiplos servidores.
|
||||
|
||||
Como a arquitetura adota segurança **Zero-Trust de movimentação lateral** (impedindo que agentes em uma VPS acessem outras máquinas via SSH automático), o **Gitea** atua como o **Orquestrador de Estado Assíncrono** do enxame de agentes.
|
||||
|
||||
---
|
||||
|
||||
## 📋 Regras de Engajamento para Agentes
|
||||
|
||||
Sempre que um agente for invocado para resolver uma Issue ou realizar uma implementação, ele deve obrigatoriamente seguir os 4 passos de ciclo de vida abaixo:
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[1. Autocognição: Onde estou?] --> B[2. Leitura de Histórico na Issue]
|
||||
B --> C[3. Execução Local na VPS Atual]
|
||||
C --> D[4. Comentário de Hand-off e Status]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Passo 1: Autocognição (Em qual VPS estou?)
|
||||
Toda IA, ao iniciar sua execução, deve identificar em qual máquina física ou container está rodando, executando comandos como `hostname` ou inspecionando o IP da VPN WireGuard local.
|
||||
* *Exemplo:* "Identificado que estou rodando na **VPS 3 (Data Server - 10.99.0.3)**."
|
||||
|
||||
### 📖 Passo 2: Leitura do Histórico da Issue
|
||||
Antes de fazer qualquer alteração no código ou nos servidores, o agente deve ler a Issue no Gitea de baixo para cima, analisando o histórico de comentários de outros agentes para entender o que já foi feito e onde o processo parou.
|
||||
|
||||
### 🛠️ Passo 3: Execução Local Estrita
|
||||
O agente deve realizar apenas as alterações correspondentes à VPS onde ele está ativamente rodando. Ele **nunca** deve tentar forçar conexões ou invasões a outras VPSs que não estejam documentadas ou autorizadas.
|
||||
|
||||
### 💬 Passo 4: Comentário de Hand-off (O Passe de Bastão)
|
||||
Ao concluir sua tarefa local, o agente **não deve simplesmente fechar a tarefa**, caso ela dependa de ações em outros servidores. Ele deve postar um comentário estruturado seguindo o modelo abaixo:
|
||||
|
||||
---
|
||||
|
||||
## 📝 Modelo Padrão de Comentário de Hand-off ( PGS )
|
||||
|
||||
O comentário de encerramento do agente na Issue deve conter obrigatoriamente os seguintes blocos:
|
||||
|
||||
```markdown
|
||||
### 🖥️ [VPS ATUAL]: [Nome da VPS, ex: VPS 3 (Data Appliance)]
|
||||
* **O que foi realizado localmente:** [Lista clara de arquivos modificados, bancos criados ou serviços configurados].
|
||||
* **Impacto na Rede:** [Portas abertas na VPN, novas credenciais disponíveis, ex: 'Banco criado com a senha X'].
|
||||
|
||||
### ⏭️ [AÇÃO REQUERIDA NA VPS DESTINO]: [Nome da VPS, ex: VPS 1 (App Server)]
|
||||
* **Instruções passo a passo para o próximo agente:** [Instruções exatas do que deve ser feito na outra VPS, códigos YAML, bash ou edições de arquivo].
|
||||
* **Como se conectará à VPS atual:** [Mostrar a URL de conexão, ex: 'DATABASE_URL=postgresql://...'].
|
||||
|
||||
### 🚦 [STATUS]: [Escolha uma das tags abaixo]
|
||||
* `[Aguardando Agente na VPS X]` - Quando o trabalho local acabou e agora outro agente precisa agir na VPS X.
|
||||
* `[Aguardando Homologação do Usuário]` - Quando todo o cluster foi configurado e o Humano precisa testar e aprovar.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Exemplo de Aplicação Real (Issue #2 - newwhats)
|
||||
|
||||
1. **Agente A (na VPS 3 - Banco):**
|
||||
* Cria o banco `newwhats` e configura DragonflyDB.
|
||||
* Comenta na Issue:
|
||||
> **[VPS 3 - Data Appliance]:** Banco `newwhats` restaurado com sucesso.
|
||||
> **[REQUERIDO NA VPS 1]:** Próximo agente, edite o `docker-compose.yml` da aplicação apontando para `10.99.0.3` usando a senha `X`. Comente quando terminar.
|
||||
> **[STATUS]:** `[Aguardando Agente na VPS 1]`
|
||||
2. **Agente B (na VPS 1 - Frontend):**
|
||||
* Inicia na VPS 1, lê o comentário acima, altera o `docker-compose.yml` local e sobe o container.
|
||||
* Comenta na Issue:
|
||||
> **[VPS 1 - App Server]:** docker-compose.yml atualizado e container reiniciado. Conexão com VPS 3 validada e healthy.
|
||||
> **[STATUS]:** `[Aguardando Homologação do Usuário]`
|
||||
|
||||
---
|
||||
*Este protocolo garante consistência, segurança máxima e clareza absoluta na comunicação humana e de inteligência artificial em nosso ecossistema.*
|
||||
@@ -0,0 +1,106 @@
|
||||
# 🛡️ Guia de Segurança e Liberdade para o Usuário `deploy`
|
||||
|
||||
Na cultura de DevOps moderna, a "lenda" do usuário `deploy` poder trabalhar com total liberdade sem ter acesso ao usuário `root` é, na verdade, uma **melhor prática de segurança chamada "Princípio do Menor Privilégio" (Least Privilege)**.
|
||||
|
||||
Se o usuário `deploy` pudesse dar `sudo su` e virar `root` a qualquer momento, qualquer vulnerabilidade na sua aplicação web (ex: um upload de arquivo malicioso ou injeção de código) daria controle total do servidor inteiro para um invasor.
|
||||
|
||||
Para dar ao usuário `deploy` toda a liberdade de desenvolvimento e publicação de aplicações com **segurança absoluta**, implementamos 4 pilares práticos:
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ Pilar 1: Controle Total do Diretório Web (Sem `sudo`)
|
||||
O usuário `deploy` não precisa de permissão de root para alterar os arquivos da aplicação. Basta torná-lo dono dos diretórios de publicação.
|
||||
|
||||
### Prática:
|
||||
Geralmente usamos a pasta `/var/www/` ou criamos um diretório de aplicações na própria Home do usuário (`/home/deploy/apps/`).
|
||||
Para dar controle total ao `deploy` sem precisar de `sudo` para editar arquivos:
|
||||
|
||||
```bash
|
||||
# Criar a pasta do seu projeto
|
||||
sudo mkdir -p /var/www/meu-app
|
||||
|
||||
# Definir o usuário deploy como proprietário da pasta
|
||||
sudo chown -R deploy:deploy /var/www/meu-app
|
||||
|
||||
# Aplicar permissões recomendadas (pastas 755 e arquivos 644)
|
||||
find /var/www/meu-app -type d -exec chmod 755 {} \;
|
||||
find /var/www/meu-app -type f -exec chmod 644 {} \;
|
||||
```
|
||||
|
||||
**Resultado**: O usuário `deploy` agora pode usar Git, SFTP, VSCode, criar arquivos, deletar e subir atualizações dentro de `/var/www/meu-app` com total liberdade e **zero** necessidade de usar `sudo`.
|
||||
|
||||
---
|
||||
|
||||
## 🐋 Pilar 2: Gerenciamento do Docker sem Root
|
||||
Se as suas aplicações rodam em Docker (ou Docker Compose), o usuário `deploy` não precisa usar `sudo docker` para gerenciar os containers.
|
||||
|
||||
### Prática:
|
||||
Adicionamos o usuário `deploy` ao grupo do Docker no Linux:
|
||||
|
||||
```bash
|
||||
sudo usermod -aG docker deploy
|
||||
```
|
||||
|
||||
**Resultado**: Após fazer logout e login novamente, o usuário `deploy` poderá rodar comandos como `docker ps`, `docker compose up -d`, `docker restart` e fazer builds de imagens diretamente, com total liberdade, sem nunca usar `sudo`.
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ Pilar 3: Sudoers com Limitação Cirúrgica (Segurança Avançada)
|
||||
Muitas vezes, a aplicação precisa apenas de tarefas muito específicas do sistema operacional, como por exemplo:
|
||||
* Reiniciar o servidor web Nginx (`systemctl restart nginx`).
|
||||
* Recarregar as configurações do Nginx (`systemctl reload nginx`).
|
||||
* Reiniciar um serviço específico da sua aplicação em NodeJS/Python criado no Systemd (`systemctl restart api-app`).
|
||||
|
||||
### Prática:
|
||||
Em vez de dar acesso total ao `sudo` para o `deploy`, nós liberamos **apenas estes comandos específicos**, sem requisição de senha!
|
||||
|
||||
1. Criamos um arquivo de configuração exclusivo no Sudoers para o `deploy`:
|
||||
```bash
|
||||
sudo nano /etc/sudoers.d/deploy
|
||||
```
|
||||
2. Adicionamos a regra cirúrgica:
|
||||
```text
|
||||
# Permite que o usuário deploy execute APENAS estes comandos listados como root, sem pedir senha:
|
||||
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/systemctl status nginx
|
||||
```
|
||||
3. Aplicamos a permissão correta ao arquivo do sudoers:
|
||||
```bash
|
||||
sudo chmod 440 /etc/sudoers.d/deploy
|
||||
```
|
||||
|
||||
**Resultado**: O usuário `deploy` agora pode rodar `sudo systemctl reload nginx` para aplicar uma mudança de domínio na web com total liberdade, mas se ele tentar rodar `sudo apt update` ou `sudo userdel`, o sistema **negará o acesso**.
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Pilar 4: Processos em Espaço de Usuário (PM2 / Systemd User)
|
||||
Se a sua aplicação web não roda em Docker e precisa ficar ativa em segundo plano (ex: aplicações Node.js, Python FastAPI, Go), o usuário `deploy` pode gerenciá-la de duas formas sem root:
|
||||
|
||||
### A. Utilizando o PM2 (NodeJS Process Manager)
|
||||
O PM2 roda diretamente no espaço de memória do usuário `deploy`.
|
||||
```bash
|
||||
# Como usuário deploy, instalar e rodar apps:
|
||||
pm2 start app.js --name "minha-api"
|
||||
pm2 save
|
||||
```
|
||||
O `deploy` tem controle total para reiniciar (`pm2 restart minha-api`), parar, e ver logs sem precisar do root.
|
||||
|
||||
### B. Serviços Systemd do Usuário (`systemd --user`)
|
||||
O Linux moderno permite que usuários criem seus próprios arquivos de serviço que rodam sob sua conta na pasta:
|
||||
`~/.config/systemd/user/`
|
||||
|
||||
Você pode gerenciar o serviço rodando:
|
||||
```bash
|
||||
systemctl --user daemon-reload
|
||||
systemctl --user restart meu-servico.service
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 Tabela de Comparação de Segurança:
|
||||
|
||||
| Ação | Como o Root faria (Inseguro) | Como o `deploy` faz com segurança |
|
||||
| :--- | :--- | :--- |
|
||||
| **Subir arquivos Web** | Usa `sudo` ou loga como `root` | Altera livremente dentro de `/var/www/` (Dono da pasta) |
|
||||
| **Gerenciar Containers** | `sudo docker compose restart` | `docker compose restart` (Membro do grupo `docker`) |
|
||||
| **Reiniciar Nginx** | `sudo systemctl restart nginx` | `sudo systemctl restart nginx` (Autorizado via Sudoers Cirúrgico) |
|
||||
| **Atualizar Código (Git)** | Roda `git pull` como root | Roda `git pull` usando suas chaves SSH do usuário |
|
||||
@@ -0,0 +1,111 @@
|
||||
# 🛡️ Plano de Contingência e Alta Disponibilidade da VPN
|
||||
|
||||
Este documento descreve detalhadamente as soluções propostas para evitar o bloqueio de acesso e garantir a continuidade da comunicação entre os servidores (**VPS 3, 4 e 5**) caso o servidor central de VPN (**VPS 1**) sofra uma queda ou falha de sistema.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 O Problema: O Ponto Único de Falha (SPOF)
|
||||
Atualmente, a rede privada utiliza uma topologia em **Estrela (Hub-and-Spoke)**, onde a **VPS 1** é o Hub central. Se a VPS 1 cair:
|
||||
1. A rede VPN criptografada (`10.99.0.0/24`) deixa de funcionar.
|
||||
2. A comunicação interna entre os servidores (como o envio de dados do app para o banco de dados na VPS 3) é interrompida.
|
||||
3. Como o SSH padrão (porta 22) está fechado na internet pública para as outras VPSs, você fica **impedido de acessar os servidores via terminal de forma convencional**, necessitando recorrer ao Console VNC no painel web da Contabo.
|
||||
|
||||
Abaixo estão as três soluções de contingência, ordenadas de forma prática.
|
||||
|
||||
---
|
||||
|
||||
## 🚪 Opção A: Estratégia Sênior Zero-Trust (Recomendado - 🛡️ Segurança Absoluta)
|
||||
|
||||
Esta abordagem elimina qualquer necessidade de expor portas SSH na internet pública (mesmo portas altas secundárias). Em vez de manter uma porta pública de "fallback" (vulnerável a ruído de scanners e bots), a administração e o tráfego de diagnóstico são restringidos a **100% de conexões internas criptografadas por VPN WireGuard**.
|
||||
|
||||
### Como mitigar o risco de lockout (Bloqueio de Acesso):
|
||||
Para evitar o isolamento de acesso caso o servidor central de VPN caia, adota-se uma trilha tripla de contingência:
|
||||
|
||||
1. **Console VNC nativo do Provedor (Ex: Contabo)**:
|
||||
Mantido ativo na console web do provedor como canal de recuperação direta de emergência e console físico absoluto em caso de desastre.
|
||||
2. **Peers WireGuard Redundantes (Multi-Device)**:
|
||||
Configuração de múltiplos dispositivos do administrador autorizados no Hub:
|
||||
* **Peer 1**: Notebook Principal.
|
||||
* **Peer 2**: Notebook Reserva, celular corporativo ou VM dedicada.
|
||||
3. **Backups Offline de Chaves e Configurações**:
|
||||
Armazenamento das configurações de VPN do Wireguard (`wg0.conf`) de forma cifrada offline (Ex: Pendrive criptografado, Cofre físico ou Vault de segurança como Bitwarden/1Password).
|
||||
|
||||
### Vantagens dessa Abordagem:
|
||||
* **Zero Exposição Pública**: Nenhuma porta além de 80 e 443 (na VPS 1) e da porta UDP do WireGuard ficam abertas na internet.
|
||||
* **Redução de Overhead**: Conectar de ferramentas administrativas (como DBeaver ou SSH direto) diretamente via IP da VPN (`10.99.0.3`) sem necessidade de fazer túneis SSH adicionais desnecessários sobre o canal VPN.
|
||||
|
||||
---
|
||||
|
||||
## 🕸️ Opção B: Comunicação Direta entre as VPSs (Full-Mesh - 🛠️ Intermediário)
|
||||
Consiste em criar túneis diretos do WireGuard entre as VPSs 3, 4 e 5, dispensando a necessidade de a VPS 1 estar online para que elas conversem entre si.
|
||||
|
||||
### Como configurar as rotas diretas:
|
||||
|
||||
Para fazer isso, precisamos adicionar as chaves públicas e os IPs de endpoint físicos das outras VPSs diretamente no arquivo `/etc/wireguard/wg0.conf` de cada uma das máquinas.
|
||||
|
||||
**Exemplo de configuração na VPS 3 (`/etc/wireguard/wg0.conf`):**
|
||||
```ini
|
||||
[Interface]
|
||||
Address = 10.99.0.3/24
|
||||
PrivateKey = <Chave_Privada_da_VPS_3>
|
||||
ListenPort = 52830
|
||||
|
||||
# Peer 1: VPS 1 (Hub Central)
|
||||
[Peer]
|
||||
PublicKey = <Chave_Publica_da_VPS_1>
|
||||
AllowedIPs = 10.99.0.1/32
|
||||
Endpoint = 158.220.109.237:51820
|
||||
PersistentKeepalive = 25
|
||||
|
||||
# Peer 2: VPS 4 (Conexão Direta - Redundância)
|
||||
[Peer]
|
||||
PublicKey = <Chave_Publica_da_VPS_4>
|
||||
AllowedIPs = 10.99.0.4/32
|
||||
Endpoint = <IP_Publico_da_VPS_4>:51820
|
||||
PersistentKeepalive = 25
|
||||
|
||||
# Peer 3: VPS 5 (Conexão Direta - Redundância)
|
||||
[Peer]
|
||||
PublicKey = <Chave_Publica_da_VPS_5>
|
||||
AllowedIPs = 10.99.0.5/32
|
||||
Endpoint = <IP_Publico_da_VPS_5>:51820
|
||||
PersistentKeepalive = 25
|
||||
```
|
||||
|
||||
### Vantagens:
|
||||
* Se a VPS 1 quebrar, as conexões de banco de dados (`10.99.0.3`) das VPSs 4 e 5 continuam funcionando de forma 100% direta e automática.
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Opção C: VPN Secundária de Backup (Failover Hub - 🛠️ Avançado)
|
||||
Consiste em configurar a **VPS 3** (Banco de Dados) ou a **VPS 5** (CRM) como um **segundo servidor de VPN (redundante)** rodando sob uma interface separada (ex: `wg1`), criando um caminho de fuga independente.
|
||||
|
||||
### Estrutura de Rede da VPN de Backup:
|
||||
* **VPN Principal (`wg0`)**: Hub na VPS 1, rede `10.99.0.0/24`.
|
||||
* **VPN de Backup (`wg1`)**: Hub na VPS 3, rede `10.98.0.0/24`.
|
||||
|
||||
### Configuração da VPS 3 como Hub Redundante (`/etc/wireguard/wg1.conf`):
|
||||
```ini
|
||||
[Interface]
|
||||
Address = 10.98.0.3/24 # IP da VPS 3 na nova rede de backup
|
||||
PrivateKey = <Chave_Privada_de_Backup_da_VPS_3>
|
||||
ListenPort = 51821 # Porta diferente para não colidir com o wg0
|
||||
|
||||
# Peer 1: Seu Notebook
|
||||
[Peer]
|
||||
PublicKey = <Chave_Publica_do_Seu_Notebook>
|
||||
AllowedIPs = 10.98.0.10/32
|
||||
|
||||
# Peer 2: VPS 4
|
||||
[Peer]
|
||||
PublicKey = <Chave_Publica_de_Backup_da_VPS_4>
|
||||
AllowedIPs = 10.98.0.4/32
|
||||
|
||||
# Peer 3: VPS 5
|
||||
[Peer]
|
||||
PublicKey = <Chave_Publica_de_Backup_da_VPS_5>
|
||||
AllowedIPs = 10.98.0.5/32
|
||||
```
|
||||
|
||||
### Vantagens:
|
||||
* Se a VPS 1 desaparecer da internet por completo, basta que você e seus sistemas ativem a interface `wg1` do WireGuard. Toda a sua infraestrutura continuará conectada em questão de segundos através da nova rede segura comandada pela VPS 3!
|
||||
@@ -0,0 +1,212 @@
|
||||
# 🗄️ Guia de Provisionamento e Tuning de Dados: VPS 3 (newwhats)
|
||||
|
||||
Este documento centraliza as instruções práticas de configuração, tuning e provisionamento para o banco de dados principal de produção (**PostgreSQL**) e o cache de alta performance (**DragonflyDB**) hospedados na **VPS 3 dedicada** (especificações físicas: **8 GB de RAM e 4 núcleos de CPU**).
|
||||
|
||||
---
|
||||
|
||||
## 🏛️ Divisão e Partilha Fisiológica de Recursos (Capacidade: 8 GB RAM / 4 CPUs)
|
||||
|
||||
Para garantir estabilidade absoluta do sistema e impedir que oscilações no tráfego de mensagens do WhatsApp causem o encerramento forçado de serviços pelo OOM (*Out Of Memory Killer*) do Linux, o hardware é segmentado de forma cirúrgica:
|
||||
|
||||
| Componente | Memória Alocada | Threads / CPUs | Função / Justificativa |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **PostgreSQL shared_buffers** | **2.0 GB** (25%) | Automático (Host) | Cache interno nativo de tabelas e índices de negócio do PostgreSQL. |
|
||||
| **PostgreSQL work_mem & OS** | **2.2 GB** (~27%) | Automático (Host) | Ordenações locais de queries, conexões e buffers de escrita do banco. |
|
||||
| **DragonflyDB `--memlimit_gb`** | **3.0 GB** (~38%) | **`--num_threads 2`** | Armazenamento seguro de sessões de WhatsApp, presenças e QR codes ativos. |
|
||||
| **Sistema Operacional (SO) & Redes** | **800 MB** (~10%) | Reservado (2 CPUs) | Processamento da rede VPN WireGuard, kernel e deamon de firewall. |
|
||||
|
||||
> [!IMPORTANT]
|
||||
> **Tuning de CPU**: O DragonflyDB é multi-threaded por natureza. Definir `--num_threads 2` confina a execução do cache a apenas 2 núcleos, deixando 2 núcleos de processamento físico totalmente livres para as consultas SQL do PostgreSQL e para a criptografia do túnel Wireguard.
|
||||
|
||||
---
|
||||
|
||||
## 🚪 Escolha Estratégica do Temporal: **Opção B (Temporal Server na VPS 5)**
|
||||
|
||||
O **Temporal Server** possui uma pegada de RAM ativa que consome entre **400 MB a 800 MB** em produção. Rodá-lo na VPS 3 deixaria a máquina no limite crítico de recursos físicos (apenas ~600 MB livres de folga).
|
||||
|
||||
Portanto, adota-se a **Opção B: Hospedar o Temporal Server na VPS 5 (Aplicação)**:
|
||||
* **Ganho de Estabilidade**: Preserva a VPS 3 exclusivamente como um *Data Appliance* de alta performance (Postgres + DragonflyDB).
|
||||
* **Latência Zero de API**: Como o **Temporal Worker** roda ao lado do backend Express na VPS 5, colocá-los na mesma máquina permite que a comunicação entre Worker e Server aconteça via `localhost`, eliminando overhead de rede VPN.
|
||||
* **Persistência**: O Temporal Server na VPS 5 continuará salvando seus dados persistentes de workflows (agenda/reputação) de forma segura no database dedicado `temporal` na VPS 3 via túnel privado.
|
||||
|
||||
---
|
||||
|
||||
## 🗄️ 1. Separação de Databases e Privilégios no PostgreSQL
|
||||
|
||||
O banco de dados do negócio (`newwhats`) e a infraestrutura interna do orquestrador (`temporal`) são isolados fisicamente em databases independentes para evitar conflito de migrações (Prisma/Knex vs `temporal-sql-tool`), facilitar backups por tabela e prover auditoria de acessos.
|
||||
|
||||
Acesse o console do PostgreSQL (`sudo -u postgres psql`) e execute o script SQL abaixo:
|
||||
|
||||
```sql
|
||||
-- ====================================================
|
||||
-- 1. CRIAÇÃO DE DATABASES INDEPENDENTES
|
||||
-- ====================================================
|
||||
CREATE DATABASE newwhats;
|
||||
CREATE DATABASE temporal;
|
||||
|
||||
-- ====================================================
|
||||
-- 2. CRIAÇÃO DOS USUÁRIOS/ROLES ESTREITOS
|
||||
-- ====================================================
|
||||
CREATE USER newwhats_user WITH PASSWORD 'SuaSenhaForteNewwhatsAqui';
|
||||
CREATE USER temporal_user WITH PASSWORD 'SuaSenhaForteTemporalAqui';
|
||||
|
||||
-- ====================================================
|
||||
-- 3. REVOGAÇÃO DE ACESSOS PÚBLICOS PADRÃO (ZERO-TRUST)
|
||||
-- ====================================================
|
||||
REVOKE ALL ON DATABASE newwhats FROM PUBLIC;
|
||||
REVOKE ALL ON DATABASE temporal FROM PUBLIC;
|
||||
|
||||
-- ====================================================
|
||||
-- 4. ATRIBUIÇÃO DE CONEXÕES EXCLUSIVAS
|
||||
-- ====================================================
|
||||
GRANT CONNECT ON DATABASE newwhats TO newwhats_user;
|
||||
GRANT CONNECT ON DATABASE temporal TO temporal_user;
|
||||
|
||||
-- ====================================================
|
||||
-- 5. CONFIGURAÇÃO DE PRIVILÉGIOS GRANULARES
|
||||
-- ====================================================
|
||||
|
||||
-- Conecte no banco 'newwhats' (\c newwhats) e execute:
|
||||
GRANT USAGE ON SCHEMA public TO newwhats_user;
|
||||
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO newwhats_user;
|
||||
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO newwhats_user;
|
||||
ALTER DATABASE newwhats OWNER TO newwhats_user;
|
||||
|
||||
-- Conecte no banco 'temporal' (\c temporal) e execute:
|
||||
-- O temporal-sql-tool precisa de privilégios plenos dentro de seu banco para autogerenciar tabelas
|
||||
GRANT ALL PRIVILEGES ON DATABASE temporal TO temporal_user;
|
||||
ALTER DATABASE temporal OWNER TO temporal_user;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 2. Hardening da Configuração do PostgreSQL (`pg_hba.conf`)
|
||||
|
||||
Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para garantir que o acesso ao banco de dados seja liberado apenas para os papéis designados originados da rede interna da VPN Wireguard:
|
||||
|
||||
```text
|
||||
# TYPE DATABASE USER ADDRESS METHOD
|
||||
|
||||
# 1. Permissões locais do sistema operacional (Apenas Root local)
|
||||
local all postgres peer
|
||||
|
||||
# 2. Permitir que o backend (VPS 5) conecte apenas no database de negócio
|
||||
host newwhats newwhats_user 10.99.0.5/32 scram-sha-256
|
||||
|
||||
# 3. Permitir que o orquestrador Temporal (VPS 5) conecte apenas no database temporal
|
||||
host temporal temporal_user 10.99.0.5/32 scram-sha-256
|
||||
|
||||
# 4. Bloqueio preventivo total para qualquer outro IP ou usuário
|
||||
host all all 0.0.0.0/0 reject
|
||||
```
|
||||
|
||||
*Para aplicar as alterações:*
|
||||
```bash
|
||||
sudo systemctl reload postgresql
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 3. Provisionamento do DragonflyDB (Systemd)
|
||||
|
||||
O **DragonflyDB** roda nativamente como um serviço leve do sistema, configurado com escuta restrita e controle estrito de memória física.
|
||||
|
||||
### 🛠️ Configuração do Serviço `/etc/systemd/system/dragonfly.service`:
|
||||
|
||||
Crie o arquivo de configuração de unidade do Systemd:
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=DragonflyDB Cache Server
|
||||
After=network.target
|
||||
Wants=network-online.target
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
User=dragonfly
|
||||
Group=dragonfly
|
||||
# Inicialização endurecida e otimizada para 8 GB RAM / 4 CPUs
|
||||
ExecStart=/usr/local/bin/dragonfly \
|
||||
--bind 10.99.0.3 \
|
||||
--port 6379 \
|
||||
--memlimit_gb 3 \
|
||||
--num_threads 2 \
|
||||
--save_schedule "" \
|
||||
--logtostdout \
|
||||
--requirepass SENHA_DRAGONFLY_PRODUCAO
|
||||
|
||||
Restart=always
|
||||
RestartSec=5
|
||||
LimitNOFILE=65536
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> **Hardening de Escuta**: O parâmetro `--bind 10.99.0.3` substitui o padrão inseguro `0.0.0.0`. Isso força o DragonflyDB a escutar **exclusivamente** as requisições que transitam por dentro do túnel privado do Wireguard, impossibilitando tentativas de conexão direta a partir da internet pública.
|
||||
|
||||
### 🏁 Passos de ativação do serviço:
|
||||
1. Certifique-se de criar o usuário dedicado do sistema:
|
||||
```bash
|
||||
sudo useradd -r -s /bin/false dragonfly
|
||||
```
|
||||
2. Recarregue os daemons e ative o DragonflyDB:
|
||||
```bash
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable dragonfly
|
||||
sudo systemctl start dragonfly
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🏛️ 4. Centralização de Múltiplos Projetos (Database Appliance)
|
||||
|
||||
Centralizar os bancos de dados de todos os seus projetos (ex: `google.com`, `facebook.com`, `newwhats`) na **VPS 3 dedicada**, mantendo as aplicações e frontends isolados na **VPS 1 (ou outras VPSs de app)**, é uma excelente decisão de design.
|
||||
|
||||
Isso separa a computação volátil das aplicações (onde acontecem picos de tráfego, deploys, memory leaks e builds pesados) da consistência estável da camada de persistência de dados.
|
||||
|
||||
### ⚠️ Regras de Segurança e Isolamento Mandatórias:
|
||||
Para operar esse modelo compartilhado com segurança de nível corporativo e evitar que uma falha em um projeto comprometa ou degrade os outros (efeito *Noisy Neighbor*):
|
||||
|
||||
#### 1. Isolamento Lógico Absoluto (Databases & Roles Independentes)
|
||||
**Nunca** use o mesmo banco de dados ou o mesmo usuário PostgreSQL para projetos distintos. Cada projeto deve ter seu banco de dados próprio e seu usuário com privilégios restritos ao seu respectivo banco.
|
||||
|
||||
```text
|
||||
PostgreSQL (VPS 3)
|
||||
├── database: google_db ──> OWNER: google_user (Apenas VPS 1 / 10.99.0.1)
|
||||
├── database: facebook_db ──> OWNER: facebook_user (Apenas VPS 1 / 10.99.0.1)
|
||||
└── database: newwhats ──> OWNER: newwhats_user (Apenas VPS 5 / 10.99.0.5)
|
||||
```
|
||||
|
||||
#### 2. Configuração do `pg_hba.conf` para Múltiplos Projetos:
|
||||
Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para mapear de forma cirúrgica as origens permitidas para cada projeto:
|
||||
|
||||
```text
|
||||
# TYPE DATABASE USER ADDRESS METHOD
|
||||
|
||||
# 1. Permissões de Administração local
|
||||
local all postgres peer
|
||||
|
||||
# 2. Projeto GOOGLE (Frontend/Backend na VPS 1 -> Banco na VPS 3)
|
||||
host google_db google_user 10.99.0.1/32 scram-sha-256
|
||||
|
||||
# 3. Projeto FACEBOOK (Frontend/Backend na VPS 1 -> Banco na VPS 3)
|
||||
host facebook_db facebook_user 10.99.0.1/32 scram-sha-256
|
||||
|
||||
# 4. Projeto NEWWHATS (Backend na VPS 5 -> Banco na VPS 3)
|
||||
host newwhats newwhats_user 10.99.0.5/32 scram-sha-256
|
||||
|
||||
# 5. BLOQUEIO PADRÃO TOTAL (Zero-Trust)
|
||||
host all all 0.0.0.0/0 reject
|
||||
```
|
||||
|
||||
#### 3. Gestão de Pools de Conexão no Node.js (Prisma/Knex)
|
||||
Cada aplicação Node.js aberta na VPS 1 tentará criar um pool de conexões persistentes. Se muitos projetos rodarem simultaneamente, as conexões ativas podem saturar a memória RAM da VPS 3 (cada conexão ativa no Postgres é um processo físico consumindo ~10MB-20MB de RAM).
|
||||
* **Solução**: Restrinja o tamanho máximo de pool nas variáveis de ambiente `.env` de cada projeto na VPS 1:
|
||||
```env
|
||||
# Exemplo de limite de conexões no Prisma
|
||||
DATABASE_URL="postgresql://google_user:SENHA@10.99.0.3:5432/google_db?connection_limit=10"
|
||||
```
|
||||
* **PgBouncer (Avançado)**: Se o número de projetos escalonar para dezenas de aplicações na VPS 1, configure o **PgBouncer** na VPS 3 para multiplexar centenas de conexões virtuais em poucas conexões físicas reais do Postgres, reduzindo drasticamente o consumo de RAM.
|
||||
|
||||
Reference in New Issue
Block a user