A segurança é tratada em camadas. Este documento descreve controles públicos sem revelar regras específicas, credenciais, endereços, runbooks ou topologia privada.
| Princípio | Aplicação |
|---|---|
| Defesa em profundidade | Perímetro, aplicação, identidade, dados e providers |
| Menor privilégio | Roles e acesso administrativo restrito |
| Segredos fora do código | Configuração externa e repositórios privados |
| Redução de superfície | Serviços de dados não destinados à exposição direta |
| Rastreabilidade | Logs de uso, providers e ações administrativas |
| Configuração segura | Recursos opcionais desabilitáveis e feature flags |
flowchart LR
E[Internet]
N[NGINX / HTTPS]
A[Aplicação]
I[Identidade e roles]
R[Limites e políticas]
P[(PostgreSQL)]
S[(MinIO / S3)]
L[Providers autorizados]
E --> N --> A --> I --> R
R --> P
R --> S
R --> L
- HTTPS/TLS no endpoint público;
- reverse proxy separando Internet e serviços internos;
- headers de segurança configuráveis;
- redirecionamento de HTTP quando aplicável;
- rate limiting e proteção de abuso;
- integração opcional com serviços de borda e CAPTCHA.
Detalhes de firewall, certificados e regras não são publicados.
A linha estável documenta:
- autenticação local com senha por hash;
- Google OAuth conforme configuração;
- sessão assinada;
- roles de usuário e administrador;
- procedures protegidas;
- recuperação e verificação de contato opcionais;
- limites específicos para endpoints de autenticação.
A autorização considera:
- usuário autenticado;
- role administrativa;
- ownership do recurso;
- plano e capacidade disponível;
- feature flags;
- política do ambiente.
Um usuário autenticado não recebe automaticamente privilégios administrativos ou acesso a assets de terceiros.
Controles podem incluir:
- validação de schema;
- limites de tamanho;
- allowlist de formatos;
- timeout de processamento;
- sanitização de nomes e metadados;
- armazenamento fora da raiz pública;
- URLs assinadas ou entrega controlada;
- bloqueio de recursos não habilitados.
PostgreSQL e MinIO/S3 são componentes internos. O acesso externo direto não faz parte do desenho público de referência.
- queries por ORM e parâmetros;
- credenciais separadas da aplicação;
- ownership e metadados no banco;
- objetos no storage;
- backup e retenção definidos pela operação privada.
O uso de providers deve considerar política de dados, contrato, região, rate limits e subprocessadores. Inferência local pode reduzir chamadas externas, mas depende da implantação.
Nenhum provider cloud é tratado como zero-retention por padrão neste documento.
Eventos de billing devem ser autenticados pelo mecanismo de assinatura do provedor de pagamento. Dados completos de cartão não são armazenados pela aplicação documental. A configuração real permanece privada.
A plataforma pode registrar:
- autenticação e falhas relevantes;
- ações administrativas;
- provider/modelo/status;
- uso e limites;
- criação e acesso a assets;
- erros sanitizados.
Logs não devem registrar segredos deliberadamente. Ainda assim, a operação deve revisar campos, retenção e acesso.
- nenhuma arquitetura é imune a falhas;
- segurança depende de configuração e atualização contínuas;
- este documento não constitui pentest ou certificação;
- conformidade legal depende do uso, contrato e processos da organização;
- recursos de IA podem gerar conteúdo incorreto ou inseguro e exigem supervisão.
Consulte SECURITY.md para reporte responsável.