# Estratégia de Segurança — Mud Sentinel

**Documento:** `operacao/01-seguranca.md`  
**Versão:** 1.0.0  
**Status:** Vigente

---

## 1. Objetivos de segurança

Proteger confidencialidade, integridade e disponibilidade dos dados e da plataforma, com ênfase em:

- Isolamento multi-tenant.
- Prevenção de vazamento de dados públicos agregados + anotações privadas do cliente.
- Integridade da trilha de auditoria.
- Uso responsável de IA (exfiltração via prompt, poisoning).

---

## 2. Princípios

1. **Defense in depth**
2. **Least privilege**
3. **Secure by default**
4. **Assume breach** (detecção e resposta)
5. **Privacy by design** (LGPD: minimização, finalidade, retenção)

---

## 3. Modelo de ameaças (resumo STRIDE)

| Ameaça | Exemplos no Mud Sentinel | Controles |
|-------|--------------------------|-----------|
| Spoofing | Token roubado, sessão hijack | OIDC, MFA, rotating refresh, device binding futuro |
| Tampering | Alterar dossiê/export | Controles de authz, hash de manifesto, audit |
| Repudiation | Negar exportação | Audit append-only |
| Information disclosure | Cross-tenant, logs com PII | Guards, redaction, encryption |
| DoS | Travessia de grafo absurda, flood IA | Quotas, rate limit, timeouts, WAF |
| Elevation of privilege | Analista vira admin | RBAC revisado, step-up MFA |

---

## 4. Autenticação e autorização

| Controle | Padrão |
|----------|--------|
| Protocolo | OAuth2/OIDC |
| MFA | Obrigatório para admins; recomendado a todos |
| Sessão | Timeout ocioso + absoluto |
| Autorização | RBAC no MVP; ABAC progressivo |
| Verificação | **Sempre** no application boundary (nunca só UI) |
| M2M | Client credentials + scopes estreitos |

**Justificativa:** produto B2B compliance não tolera authz “no frontend”.

---

## 5. Proteção de dados

| Camada | Controle |
|--------|----------|
| Trânsito | TLS 1.2+; HSTS no edge |
| Repouso | Criptografia de volumes e buckets |
| Segredos | Secret manager; rotação |
| Campos sensíveis | Classificação; mascaramento em UI; Encryptopcional de colunas se necessário |
| Backups | Cifrados; restore testado |

Classificação mínima: `Public`, `Internal`, `Confidential`, `Restricted`.

---

## 6. Segurança multi-tenant

- `tenant_id` derivado do token — **não** confiar em parâmetro de request como fonte de verdade.
- Testes automatizados de isolamento (gate de release).
- Evitar raw SQL; quando inevitável, review obrigatório.
- Avaliar RLS PostgreSQL como defesa em profundidade (ADR).

---

## 7. Segurança de aplicação (ASVS-inspired)

- Input validation nas bordas (Pydantic).
- Encoded output / CSP no frontend.
- CSRF mitigado no modelo de auth adotado (SameSite, tokens).
- SSRF protection em conectores/HTTP clients (allowlists).
- Upload/export com tipos e tamanhos limitados.
- Headers de segurança no gateway.

---

## 8. Segurança de IA

| Risco | Controle |
|-------|----------|
| Prompt injection | Separar system vs. user; grounding only; não executar ferramentas perigosas sem allowlist |
| Exfiltração | Redaction de segredos; DLP básico em prompts |
| Alucinação operacional | Citar fontes; UI marca hipóteses |
| Abuse/custo | Quotas por tenant; rate limit |

---

## 9. Supply chain

- Lockfiles commitados.
- Scan de deps e imagens no CI (Trivy, etc.).
- Assinatura de imagens (futuro progressivo).
- Políticas de vendors (LLM, IdP, cloud) com DPA.

---

## 10. SDLC de segurança

| Atividade | Frequência |
|-----------|------------|
| SAST / linters security | Todo PR |
| Dependency scan | Todo PR / diário |
| Threat model leve | Features P0 sensíveis |
| Pentest | Antes de escala comercial / anual |
| Incident response runbook | Mantido contínuo |

---

## 11. Resposta a incidentes (mínimo)

1. Detectar / triagem de severidade.
2. Conter (revogar tokens, isolar tenant/credencial).
3. Erradicar e recuperar.
4. Comunicar conforme LGPD/contratos.
5. Postmortem blameless com actions.

---

## 12. Trade-offs conscientes

Controles fortes aumentam fricção UX (MFA, timeouts).  
**Decisão:** preferir fricção em papéis privilegiados a afrouxar isolamento ou auditoria.