# Guia de Segurança para Novos Sistemas ## Atualizacao 2026-05-10 - Pre-producao AlmaLinux - [x] 2FA administrativo ganhou codigos de recuperacao de uso unico, exibidos uma vez e armazenados apenas como hash. - [x] Login administrativo aceita TOTP ou recovery code; recovery code usado e consumido e gera alerta/audit log. - [x] Super Admin ganhou `/tikah-admin/configuracoes/seguranca` com 2FA proprio, lista de admins e reset assistido de 2FA de outro admin. - [x] Reset de 2FA por Super Admin limpa segredo/codigos, incrementa `sessionVersion` e registra `SUPER_ADMIN_2FA_RESET`. - [x] Em producao, `ADMIN`/`SUPER_ADMIN` sem 2FA sao direcionados para a tela de seguranca antes de acessar areas administrativas. - [x] Criado readiness check em `lib/production-readiness.ts`, endpoint `/api/tikah-admin/readiness`, painel visual e script `npm run security:readiness`. - [x] Readiness valida secrets, 2FA de admins, Super Admin ativo, banco, SMTP, alertas, backups, WAF e hardening AlmaLinux. - [x] Alertas de seguranca podem ser enviados por e-mail quando `SECURITY_ALERT_EMAIL` estiver configurado. - [x] `DEPLOY_TIKAH.md` e runbook AlmaLinux agora documentam `TWO_FACTOR_SECRET_KEY`, `SECURITY_ALERT_EMAIL`, `TIKAH_WAF_CONFIRMED`, `TIKAH_SERVER_HARDENED` e readiness. ## Atualizacao 2026-05-10 - CSP com nonce - [x] CSP saiu do header estatico em `next.config.ts` e passou para `proxy.ts`, permitindo nonce novo por request. - [x] `lib/csp.ts` centraliza `Content-Security-Policy` para producao/desenvolvimento e facilita teste automatizado. - [x] `script-src` usa `'nonce-{valor}'` e `'strict-dynamic'`, sem `unsafe-inline`. - [x] Em producao, `style-src` tambem usa nonce e remove `unsafe-inline`; em desenvolvimento, `unsafe-inline` permanece apenas para estilos exigidos pelo runtime/ferramentas do Next. - [x] HTML manual de PDF de submissao le o `x-nonce` e aplica o atributo no script de impressao. - [x] Testes de seguranca validam que a CSP de producao remove `unsafe-inline` e que a CSP de desenvolvimento nao libera `unsafe-inline` em scripts. ## Atualizacao 2026-05-10 - Rodada operacional de 10 tarefas de 2FA - [x] Adicionados campos de 2FA em `User`: ativo, segredo criptografado, data de confirmacao e ultimo contador TOTP usado. - [x] Criado helper TOTP local em `lib/totp.ts`, com geracao de segredo, URI `otpauth://`, validacao com janela curta e bloqueio de replay por contador. - [x] Segredos TOTP sao criptografados em repouso com AES-256-GCM usando `TWO_FACTOR_SECRET_KEY` ou `NEXTAUTH_SECRET`. - [x] Login administrativo (`ADMIN`/`SUPER_ADMIN`) passa a exigir codigo 2FA quando o usuario tiver 2FA ativo. - [x] Formularios de login global e por tenant receberam campo opcional de codigo 2FA com `autocomplete=one-time-code`. - [x] Criado endpoint `/api/admin/2fa` para preparar, ativar e desativar 2FA com logs em `AccessLog`. - [x] Criada tela `/admin/seguranca` para o administrador gerar segredo, copiar URI/segredo e ativar/desativar 2FA. - [x] Ativar ou desativar 2FA incrementa `sessionVersion`, invalidando sessoes antigas. - [x] Testes automatizados cobrem TOTP valido, rejeicao de replay e criptografia/descriptografia do segredo 2FA. - [x] `docs/ADMIN_2FA_PLAN.md`, README/GUIA/descricao/todo e memorias foram atualizados para refletir a primeira versao real do 2FA. ## Atualizacao 2026-05-10 - Rodada operacional anterior - [x] Centralizado em `lib/security.ts` o contrato de revogacao de sessoes para mudancas sensiveis de usuario. - [x] Rota administrativa de usuarios passou a usar o helper comum para revogar sessoes em mudanca de role/status. - [x] Teste automatizado cobre que troca/reset de senha deve revogar sessoes existentes via incremento de `sessionVersion`. - [x] Criado workflow `DAST Security Scan` com banco SQLite efemero, build, healthcheck e OWASP ZAP baseline. - [x] Criado `docs/EDGE_SECURITY_RUNBOOK.md` com WAF, rate limit de borda, bots, geografia e validacao. - [x] Criado `docs/SECRET_ROTATION_RUNBOOK.md` para tratar segredo exposto como comprometido e rotacionar por ambiente. - [x] Criado `docs/SERVER_HARDENING_RUNBOOK.md` para usuario nao-root, SSH por chave, root login e atualizacoes automaticas. - [x] Criado `docs/PENTEST_DAST_PLAN.md` com escopo de pentest leve e criterios de saida. - [x] Checklist minimo passou a referenciar que WAF/CDN ja tem runbook pronto, mantendo ativacao operacional pendente. - [x] Pendencias operacionais agora diferenciam o que depende de provedor/servidor do que ja foi codificado no repositorio. ## Atualizacao 2026-05-10 - Rodada de mais 10 controles aplicados - [x] Sessões JWT agora carregam `sessionVersion`; alteração de role/status do usuário incrementa a versão e invalida tokens antigos. - [x] Não há refresh token persistido em banco; o padrão atual evita refresh token em texto puro e usa cookie HttpOnly/Secure/SameSite para a sessão. - [x] Rotas de upload passam a usar helper comum para limite de tamanho, bloqueando arquivo vazio e arquivo acima do limite antes da gravação. - [x] Testes automatizados cobrem senha forte, redaction de secrets, uploads SVG/HTML/PHP, assinatura real, limite de tamanho e rate limit. - [x] Novo workflow `Security Checks` roda semanalmente e em PR: `npm audit` de produção, audit incluindo dev dependencies e testes de segurança. - [x] SQL cru remanescente da configuração de comunicação foi trocado de `$queryRawUnsafe`/`$executeRawUnsafe` para tagged templates parametrizados. - [x] `proxyClientMaxBodySize` foi fixado em 6 MB para reduzir abuso de body buffering no Proxy. - [x] CSP ficou mais explícita para `media-src`, `worker-src` e `frame-src`, limitando iframes aos domínios usados para mapas. - [x] Regex de detecção de IPv4 no Proxy foi removida e substituída por validação determinística por partes, reduzindo risco de ReDoS. - [x] Checklist local registra que uploads atuais são lidos em memória e não criam temporários próprios para limpar em erro. ## Atualizacao 2026-05-10 - Rodada adicional de 15 controles - [x] Criado `scripts/restore-verify-tikah.sh` para validar integridade do backup mais recente e testar restore SQLite/PostgreSQL em ambiente separado quando `RESTORE_DATABASE_URL` estiver configurado. - [x] Criado workflow `Restore Test` semanal/manual para exercitar o restore fora do deploy. - [x] Workflow de backup agora roda verificação de restore/integridade após gerar backup. - [x] Deploy passou a executar backup antes de migrations/sincronização quando `BACKUP_DIR` estiver configurado. - [x] Criado `scripts/health-monitor-tikah.sh` para monitorar healthcheck HTTP, disco, load, memória, PM2 e banco PostgreSQL quando aplicável. - [x] Criado workflow `Operations Monitor` a cada 15 minutos para rodar monitoramento operacional no runner self-hosted. - [x] Deploy passou a aplicar permissões restritas em `.env`, diretório da aplicação e uploads. - [x] Deploy passou a executar smoke checks pós-reload em `/api/health`, `/login`, `/demo` e landing. - [x] `.htaccess` de uploads foi versionado como baseline, além da geração no deploy. - [x] Testes automatizados validam que `.htaccess` bloqueia listagem e execução de extensões perigosas. - [x] Teste automatizado valida invalidação de sessão por usuário inativo ou token com `sessionVersion` antigo. - [x] Política de senha bloqueia senhas demo/comuns que contenham padrões conhecidos. - [x] Contas e senhas demo da tela `/login` são uma exceção operacional deliberada: ficam públicas apenas para os perfis fictícios predefinidos e não afrouxam a política de senha de cadastros reais. - [x] Plano formal de 2FA administrativo foi documentado em `docs/ADMIN_2FA_PLAN.md`. - [x] Modelo de registro de manutenção foi criado em `docs/SECURITY_MAINTENANCE_LOG.md`. - [x] Checklist operacional passou a exigir evidência de backup, build, audit, testes, healthcheck, restart e rollback em manutenções. ## Prioridade 1 - Proteção Imediata - [ ] Ativar Cloudflare/WAF ou proteção equivalente para rotas críticas: - `/admin`; - `/api/auth/login`; - `/api/upload` ou equivalentes; - rotas de importação; - rotas financeiras ou sensíveis. - Runbook pronto em `docs/EDGE_SECURITY_RUNBOOK.md`; ativação depende do provedor/DNS. - [ ] Configurar rate limit na borda para: - login; - recuperação de senha; - contato; - upload; - importações; - APIs públicas sensíveis. - Plano de limites pronto em `docs/EDGE_SECURITY_RUNBOOK.md`; ativação depende do provedor/CDN. - [ ] Ativar proteção contra bots, se disponível. Runbook pronto em `docs/EDGE_SECURITY_RUNBOOK.md`. - [ ] Bloquear ou desafiar países fora do público esperado, se fizer sentido operacional. Runbook pronto em `docs/EDGE_SECURITY_RUNBOOK.md`. - [x] Implementar 2FA para administradores. - [x] Usar autenticação com cookies `HttpOnly`, `Secure` e `SameSite=Lax/Strict`. - [x] Criar rotina automática de backup do banco. - [x] Testar restore do backup em ambiente separado. - [x] Confirmar que `.env` nunca está versionado. - [ ] Se algum segredo já foi para o Git, tratar como comprometido e trocar. Procedimento definido em `docs/SECRET_ROTATION_RUNBOOK.md`. - [x] Validar estritamente o isolamento de dados (IDOR/BOLA): toda query de leitura, edição ou exclusão no banco DEVE incluir e validar o tenant_id ou user_id logado. ## Prioridade 2 - Dependências e Build - [x] Manter backend com audit zerado ou sem vulnerabilidades altas/críticas. - [x] Manter frontend de produção com audit zerado ou sem vulnerabilidades altas/críticas. - [x] Incluir no CI/CD: - `npm audit --audit-level=high --omit=dev`; - bloqueio de deploy se aparecer vulnerabilidade alta/crítica. - [x] Avaliar periodicamente dependências de desenvolvimento, como Vite, esbuild, Webpack ou equivalentes. - [x] Nunca rodar `npm audit fix --force` sem avaliar breaking changes. - [x] Validar build após qualquer atualização de dependências. - [x] Validar fluxo principal da aplicação após updates. ## Prioridade 3 - Sessões e Autenticação - [x] Usar segredo JWT forte, longo e aleatório. - [x] Usar segredo diferente por ambiente. - [x] Armazenar refresh token como hash no banco. No desenho atual não há refresh token persistido; se esse recurso for criado, o padrão obrigatório é hash. - [x] Nunca salvar refresh token em texto puro. No desenho atual não há refresh token persistido. - [x] Revogar refresh tokens em troca/reset de senha. Sessões JWT atuais são versionadas por usuário e a mesma versão deve ser incrementada em qualquer futuro fluxo de senha. - [x] Usar cookies `HttpOnly/Secure/SameSite` para tokens. - [x] Evitar `localStorage` para tokens de autenticação. - [x] Implementar 2FA para administradores. - [x] Aplicar política forte para senha de admin: - mínimo 12 a 14 caracteres; - bloquear senhas comuns; - exigir boa entropia. - [x] Criar alerta para muitas falhas de login. - [x] Criar alerta para criação/alteração de usuário admin. - [x] Invalidar sessões de usuário desativado. ## Prioridade 4 - Uploads e Arquivos - [x] Bloquear SVG quando não houver sanitização real. - [x] Validar extensão do arquivo. - [x] Validar MIME type. - [x] Validar assinatura real do arquivo quando possível. - [x] Usar nome gerado pelo servidor. - [x] Limitar tamanho por tipo de upload. - [x] Apagar temporários mesmo em erro. Uploads atuais validam bytes em memória e só gravam o arquivo final após extensão/MIME/assinatura/tamanho passarem. - [x] Restringir upload/importação a roles autorizados. - [x] Confirmar no servidor que `.htaccess`, Nginx config ou equivalente está sendo respeitado. - [x] Confirmar que diretórios de upload não executam PHP, CGI, shell, Python etc. - [x] Confirmar que diretórios de upload não listam arquivos. - [x] Fazer backup automático dos diretórios de upload importantes. ## Prioridade 5 - Monitoramento e Auditoria - [x] Adicionar audit logs para rotas administrativas: - configurações; - usuários; - roles/permissões; - uploads; - importações; - pagamentos; - conteúdo publicado; - alterações sensíveis. - [x] Registrar: - usuário; - data/hora; - IP; - user-agent; - ação executada; - payload resumido, sem secrets. - [x] Criar alerta para: - muitas falhas de login; - alteração de admin; - upload; - mudança de configuração sensível; - erro 500 recorrente; - pico anormal de requisições. - [x] Monitorar processo da aplicação. - [x] Monitorar CPU, RAM, disco, banco e rede. - [x] Configurar healthcheck com alerta, não só restart silencioso. ## Prioridade 6 - Endurecimento da Aplicação - [x] Usar Helmet ou headers equivalentes. - [x] Endurecer CSP gradualmente. - [x] Remover `unsafe-inline` quando possível. - [x] Usar nonce/hash para scripts quando necessário. - [x] Limitar `img-src`, `connect-src`, `script-src` e `frame-src` aos domínios realmente usados. - [x] Configurar CORS apenas para origens confiáveis. - [x] Validar URLs salvas em painel admin: - aceitar apenas `https://`; - `mailto:`; - `tel:`; - caminhos internos seguros. - [x] Sanitizar HTML vindo da API quando houver conteúdo rico/CMS. - [x] Garantir que endpoints públicos não vazam SMTP, secrets, tokens ou chaves privadas. - [x] Retornar erros genéricos para o cliente. - [x] Registrar detalhes técnicos apenas no log interno. - [x] Bloquear Mass Assignment: NUNCA passar o payload inteiro (ex: req.body) diretamente para comandos de insert/update do banco. Fazer o destruct/validação explícita apenas dos campos permitidos. - [x] Proibir o uso de Expressões Regulares (Regex) complexas ou não testadas para validação de entrada de usuários para evitar ReDoS (travar o Event Loop do Node). Usar bibliotecas de schema validation (ex: Zod, Joi). - [x] Proibir absolutamente a concatenação de strings para montar queries SQL. Obrigar o uso de Parameterized Queries (Prepared Statements) ou os métodos seguros do ORM escolhido. ## Prioridade 7 - Servidor e Operação - [ ] Rodar aplicação com usuário não-root sempre que possível. Procedimento definido em `docs/SERVER_HARDENING_RUNBOOK.md`. - [ ] SSH somente por chave. Procedimento definido em `docs/SERVER_HARDENING_RUNBOOK.md`. - [ ] Desativar login root por SSH, se o ambiente permitir. Procedimento definido em `docs/SERVER_HARDENING_RUNBOOK.md`. - [ ] Ativar atualizações automáticas de segurança do sistema operacional. Procedimento definido em `docs/SERVER_HARDENING_RUNBOOK.md`. - [x] Revisar permissões de: - `.env`; - diretório do backend; - diretório do frontend; - uploads; - backups. - [x] Confirmar Apache/cPanel/Nginx sem listagem de diretórios. - [x] Confirmar backup antes de mudanças sensíveis. - [x] Registrar toda manutenção: - comandos; - pacotes alterados; - resultado de audit; - resultado de build/testes; - horário de restart da aplicação. ## Prioridade 8 - Testes de Segurança - [x] Teste garantindo que upload de SVG/PHP/HTML falha. - [x] Teste garantindo que arquivo grande demais falha. - [x] Teste garantindo limpeza de temporário após erro. - [x] Teste de brute force/rate limit no login. - [x] Teste garantindo que usuário desativado perde acesso mesmo com token antigo. - [x] Teste garantindo que reset/troca de senha revoga sessões. - [x] Teste garantindo que endpoint público de configuração não vaza dados sensíveis. - [x] Teste garantindo que diretórios de upload não listam arquivos. - [x] Teste garantindo que diretórios de upload não executam scripts. - [x] Planejar pentest externo leve antes de divulgação ampla. Plano criado em `docs/PENTEST_DAST_PLAN.md`. - [x] Configurar pipeline de CI/CD no GitHub Actions com ambiente efêmero e banco de dados temporário para rodar testes automatizados (DAST) antes do deploy. ## Checklist Mínimo Para Todo Novo Sistema - [x] `.env` fora do Git. - [x] Secrets fortes e diferentes por ambiente. - [x] JWT secret forte. - [x] Refresh token com hash no banco. No desenho atual não há refresh token persistido; manter hash obrigatório se for implementado. - [x] Tokens fora do `localStorage`. - [x] Cookies `HttpOnly/Secure/SameSite` para sessão. - [x] Rate limit em autenticação. - [x] Helmet ou headers de segurança configurados. - [x] CORS restrito. - [x] Upload validado por extensão, MIME e assinatura. - [x] SVG bloqueado ou sanitizado. - [x] Validação estrita de isolamento de clientes (IDOR) e bloqueio de Mass Assignment. - [x] Audit backend sem vulnerabilidades altas/críticas. - [x] Audit frontend de produção sem vulnerabilidades altas/críticas. - [x] Build validado. - [x] Backups automáticos. - [x] Restore testado. - [x] Healthcheck configurado. - [x] Logs revisados. - [x] Admin protegido com 2FA ou plano definido. - [ ] WAF/CDN configurado quando aplicável. Runbook pronto em `docs/EDGE_SECURITY_RUNBOOK.md`; ativação depende do provedor. - [x] Rotina de manutenção documentada.