docs: Adiciona análise de sizing e segurança de cache
This commit is contained in:
parent
44c0220cba
commit
441b69658c
|
|
@ -0,0 +1,203 @@
|
|||
# Discussão de Infraestrutura: Agente de IA Pathfinder
|
||||
|
||||
Este documento detalha a arquitetura determinística projetada para o Nginx Pathfinder Proxy, focando em alta performance, segurança ativa e operações sem downtime.
|
||||
|
||||
---
|
||||
|
||||
## 🏛️ Arquitetura do Sistema
|
||||
|
||||
A solução baseia-se em um modelo de **Container Principal + Sidecar**, permitindo que a segurança e a automação operem sem interferir na performance do proxy.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
User((Usuário / Internet)) -->|UDP 443 HTTP/3| Nginx[Nginx Master Container]
|
||||
User -->|TCP 80/443 HTTP/1.1/2| Nginx
|
||||
|
||||
subgraph "Nginx Master (High-End)"
|
||||
Nginx -->|ModSecurity v3| WAF[WAF / OWASP CRS]
|
||||
WAF -->|Audit Logs| Logs[(Detailed JSON Logs)]
|
||||
end
|
||||
|
||||
subgraph "Sidecar: Security & Automation"
|
||||
F2B[Fail2Ban Sidecar] -->|Lê| Logs
|
||||
F2B -->|Escreve| Blacklist[blacklist.conf]
|
||||
end
|
||||
|
||||
Blacklist -->|Incluso via| Nginx
|
||||
|
||||
subgraph "Persistent Storage (Windows Host)"
|
||||
Prod[./producao - Docker & Binários]
|
||||
Sites[./sites-ativos - Configs & SSL]
|
||||
LogDir[./sites-ativos/logs - Persistência]
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## <20> Pilares Técnicos Detalhados
|
||||
|
||||
### 1. Nginx "Turbo" (Produção)
|
||||
Para suportar o estado da arte, o binário será compilado com os seguintes módulos:
|
||||
* **QUIC/HTTP/3:** Utilizando `quictls` para garantir criptografia moderna e performance em redes instáveis.
|
||||
* **ModSecurity v3:** Conector nativo para inspeção de pacotes em tempo real.
|
||||
* **Brotli:** Compressão superior ao Gzip para reduzir latência.
|
||||
* **Headers More:** Para ocultar a versão do Nginx e manipular headers de segurança de forma granular.
|
||||
|
||||
### 2. Fluxo de Segurança Ativa (WAF + Fail2Ban)
|
||||
O sistema não apenas bloqueia, ele aprende e isola:
|
||||
1. **Detecção:** O ModSecurity identifica uma tentativa de SQLi ou XSS e registra no `error.log`.
|
||||
2. **Registro:** O Nginx gera logs no formato `detailed_proxy` (JSON) em `sites-ativos/logs`.
|
||||
3. **Processamento:** O Fail2Ban (Sidecar) monitora o arquivo JSON. Ao encontrar um IP reincidente, ele o adiciona ao arquivo `blacklist.conf`.
|
||||
4. **Bloqueio:** O Nginx, que possui um `include snippets/blacklist.conf` global, bloqueia o IP instantaneamente no próximo reload ou via processamento de hash dinâmico.
|
||||
|
||||
### 3. Gestão de Certificados SSL (Zero Downtime)
|
||||
O monitoramento e renovação serão totalmente automatizados:
|
||||
* **Certbot Portátil:** O Agente de IA (Antigravity) pode disparar o Certbot internamente.
|
||||
* **Desafio Webroot:** Utiliza a pasta `sites-ativos/snippets/acme_challenge.conf` para validar domínios sem interromper o tráfego 443.
|
||||
* **Reload Seguro:** Após a renovação, um script de "safe-deploy" valida a sintaxe e aplica os novos certificados.
|
||||
|
||||
---
|
||||
|
||||
## 📂 Estrutura de Diretórios Final
|
||||
|
||||
```text
|
||||
/
|
||||
├── producao/ # O "Motor" (Imutável)
|
||||
│ ├── Dockerfile # Build Multi-stage (Compilação)
|
||||
│ ├── docker-compose.yml # Orquestração (Nginx + Fail2Ban)
|
||||
│ └── entrypoint.sh # Scripts de boot e SSH
|
||||
├── sites-ativos/ # A "Inteligência" (Editável pelo Agente)
|
||||
│ ├── nginx.conf # Configuração mestre
|
||||
│ ├── conf.d/ # Arquivos .conf dos sites (Ex: site1.com.br.conf)
|
||||
│ ├── snippets/ # Peças reutilizáveis (Coração do reuso)
|
||||
│ │ ├── log_formats.conf# Seu padrão detailed_proxy
|
||||
│ │ ├── ssl_params.conf # Configs HTTP/3 e Cifras
|
||||
│ │ ├── modsecurity.conf# Ativação do WAF
|
||||
│ │ └── blacklist.conf # IPs banidos dinamicamente
|
||||
│ └── logs/ # Onde a mágica do monitoramento acontece
|
||||
└── DISCUSSAO_INFRA_AGENTE.md # Este documento de planejamento
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ O Script `safe-deploy.sh` (O "Gatilho" do Agente)
|
||||
|
||||
Para garantir que eu (o Agente) nunca quebre o seu ambiente, toda alteração passará por este fluxo:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# 1. Validação de Sintaxe
|
||||
OUT=$(docker exec nginx-proxy nginx -t 2>&1)
|
||||
if [ $? -eq 0 ]; then
|
||||
# 2. Aplicação Atômica
|
||||
docker exec nginx-proxy nginx -s reload
|
||||
echo '{"status": "success", "msg": "Configuração aplicada via Reload"}'
|
||||
else
|
||||
# 3. Reporte de Erro para IA
|
||||
echo "{\"status\": \"error\", \"details\": \"$OUT\"}"
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## 📊 Dimensionamento de Recursos (Sizing)
|
||||
|
||||
Para uma carga de **milhões de requisições por semana** (média de ~12 RPS com picos de ~500 RPS), aqui está a estimativa de consumo de RAM:
|
||||
|
||||
| Componente | Consumo Estimado (Pico) | Por que consome? |
|
||||
| :--- | :--- | :--- |
|
||||
| **Nginx (Workers)** | 500MB - 1GB | Buffers de proxy, conexões ativas e SSL/TLS. |
|
||||
| **ModSecurity v3** | 1GB - 2GB | WAF é pesado. Processar regras OWASP consome RAM por worker. |
|
||||
| **Fail2Ban Sidecar** | 300MB - 800MB | Parse de JSON e banco de dados SQLite de banimentos. |
|
||||
| **Cache Index (Keys)**| 100MB (Fixo) | Espaço reservado para o índice de cache na RAM. |
|
||||
| **TOTAL ESTIMADO** | **3GB - 5GB** | **Recomendação: Servidor com 8GB RAM.** |
|
||||
|
||||
> [!IMPORTANT]
|
||||
> O Nginx é ultra eficiente, mas o **ModSecurity v3** é um motor robusto de inspeção. Em picos de tráfego, ele é quem mais "bebe" RAM para garantir que nenhum ataque passe pelas regras.
|
||||
|
||||
---
|
||||
|
||||
## ⚡ Estratégia de Cache Dinâmico
|
||||
|
||||
O Nginx possui uma limitação técnica: a diretiva `proxy_cache_path` (que define o local e o tamanho da zona) deve ser declarada no bloco `http` de forma estática. Não é possível usar variáveis para o nome da zona ou o caminho em tempo de execução.
|
||||
|
||||
### Proposta para contornar o "Manual":
|
||||
|
||||
#### Opção A: Zona Universal Inteligente (Recomendada)
|
||||
Em vez de criar uma zona para cada site, usamos uma única zona robusta (`dynamic_cache`) de, por exemplo, 50GB.
|
||||
* **Vantagem:** Totalmente dinâmica. Um novo site não precisa de NADA no `cache_zones.conf`.
|
||||
* **Isolamento Tecnológico:** Garantido pela diretiva `proxy_cache_key`.
|
||||
* **Risco de "Entregar Informação Errada":** Praticamente ZERO, desde que a chave de cache seja única.
|
||||
|
||||
### 🛡️ Segurança e Isolamento de Cache
|
||||
|
||||
A pergunta vital: *Um site pode "vazar" para o outro?*
|
||||
|
||||
1. **Como o Nginx identifica o que entregar:**
|
||||
O Nginx gera um hash MD5 da string definida em `proxy_cache_key`.
|
||||
Nossa chave atual: `"$scheme$request_method$host$request_uri"`
|
||||
* **$host:** Este é o segredo. Se um usuário acessa `itguys.com.br` e outro `cliente.com.br`, os hashes serão completamente diferentes, mesmo que o caminho seja o mesmo (`/index.html`). O Nginx nunca confundirá os arquivos no disco.
|
||||
|
||||
2. **Risco de Cache Poisoning (Envenenamento):**
|
||||
O risco real não é o vazamento entre sites, mas sim alguém "enganar" o cache para guardar uma versão maliciosa de um arquivo.
|
||||
* **Mitigação no Pathfinder:** Nossa configuração já utiliza `$host` (que é validada pelo Nginx) e não headers não-confiáveis como `X-Forwarded-Host` na chave de cache.
|
||||
* **Proteção Adicional:** Sempre incluímos o `proxy_set_header Host $host` nos nossos snippets para garantir que o backend receba o host correto e o cache reflita a realidade.
|
||||
|
||||
3. **Isolamento de Disco (Quota):**
|
||||
O único "risco" do cache partilhado é um site "comilão" ocupar os 20GB sozinho e forçar a limpeza dos arquivos dos outros sites (LRU).
|
||||
* *Solução:* Se um site for crítico e volumoso, aí sim criamos uma zona isolada (Opção B).
|
||||
|
||||
#### Opção B: Automação pelo Agente (Eu)
|
||||
Como este ambiente é operado por mim (IA), eu posso automatizar o que o Nginx não faz nativamente.
|
||||
* **Fluxo:** Ao detectar que você pediu um site novo com "Cache Isolado", eu mesmo incluo a linha no `cache_zones.conf` e rodo o `safe-deploy.sh`.
|
||||
* **Resultado:** Para você, parecerá dinâmico, pois eu farei o trabalho manual.
|
||||
|
||||
#### Opção C: Mapeamento de Zonas
|
||||
Podemos usar um `map` para centralizar a escolha da zona:
|
||||
```nginx
|
||||
map $host $site_cache_zone {
|
||||
host1.com high_priority_cache;
|
||||
default dynamic_cache;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Cache Híbrido: RAM + Disco
|
||||
|
||||
Uma dúvida comum: *Como garantir que o cache seja ultra-rápido (RAM) mas ainda assim suporte grandes volumes (Disco)?*
|
||||
|
||||
### 1. O Modelo Nativo do Nginx (Híbrido Automático)
|
||||
O Nginx já divide o trabalho:
|
||||
* **Metadados (RAM):** O `keys_zone` (ex: 100MB) fica 100% na RAM. Ele é o índice. Quando chega um request, o Nginx checa a RAM primeiro.
|
||||
* **Conteúdo (Disco + OS Page Cache):** O arquivo em si fica no disco. No entanto, o **Linux é inteligente**: se um arquivo é acessado muitas vezes, o sistema operacional o mantém no **Page Cache** (RAM livre do servidor).
|
||||
* **Resultado:** Na prática, seus arquivos "quentes" já estarão na RAM sem você fazer nada.
|
||||
|
||||
### 2. Turbinando com RAM Disk (`tmpfs`)
|
||||
Se quisermos forçar que certos arquivos NUNCA toquem o disco (latência zero real):
|
||||
* **Como funciona:** Montamos uma pasta no Docker usando `tmpfs`.
|
||||
* **Vantagem:** Velocidade absurda (pense em micro-assets ou APIs voláteis).
|
||||
* **Desvantagem:** Se o container reiniciar, esse cache some (volátil) e consome RAM real do seu host.
|
||||
|
||||
### 3. Nossa Estratégia Sugerida
|
||||
Para o Pathfinder Proxy, manteremos o **Modelo de Disco (SSD)**:
|
||||
1. Confiamos no **Page Cache** do Linux para os arquivos frequentes.
|
||||
2. Mantemos a persistência (se o Nginx reiniciar, o cache continua lá).
|
||||
3. Não arriscamos travar o servidor por falta de RAM se o cache crescer rápido demais.
|
||||
|
||||
> [!TIP]
|
||||
> **Dica de Performance:** O parâmetro `use_temp_path=off` que já incluímos no seu config faz com que o Nginx escreva o arquivo diretamente na pasta final, evitando cópias desnecessárias no disco.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Próximos Passos (Mão na Massa)
|
||||
|
||||
1. **[ ]** Construir o `Dockerfile` com compilação `quictls` e `modsecurity`. (CONCLUÍDO)
|
||||
2. **[ ]** Atualizar o `docker-compose.yml` para incluir o Sidecar do Fail2Ban. (CONCLUÍDO)
|
||||
3. **[ ]** Refatorar `cache_zones.conf` para o modelo de **Zona Universal**.
|
||||
4. **[ ]** Testar a primeira emissão de SSL via Certbot no novo modelo.
|
||||
|
||||
**João, este detalhamento cobre todas as suas preocupações? Se sim, podemos iniciar o Passo 1.**
|
||||
Loading…
Reference in New Issue