1. ARQUITETURA DE CONFIANÇA MÍNIMA
A RET Tecnologia trata entradas externas como não confiáveis por padrão e aplica controles proporcionais ao risco do portal público.
Princípio do Menor Privilégio: Variáveis sensíveis não usam prefixo público, webhooks exigem segredo e integrações externas ficam centralizadas.Separação de Responsabilidades: Formulário, analytics, provedor de pagamento, e-mail, políticas públicas e páginas comerciais têm limites claros de dados.Revisão Contínua: Mudanças relevantes passam por testes, lint, build e checagens de segurança antes de publicação.A camada pública combina proteção da hospedagem com controles próprios nos pontos sensíveis:
Filtros de borda: Bloqueio de padrões automatizados e tráfego abusivo quando aplicável.Honeypot e PoW leve: Formulários usam campos invisíveis, prova de trabalho leve e sinais do navegador para reduzir spam.Limite por chave protegida: Requisições usam identificador derivado de IP com hash, sem expor o IP bruto nas notificações.Mitigação de volume: A hospedagem ajuda a absorver tráfego abusivo; o portal mantém limites próprios para endpoints sensíveis.3. ISOLAMENTO CROSS-ORIGIN
Headers de segurança implementados para proteção contra ataques Spectre e exfiltração de dados:
Cross-Origin-Embedder-Policy (COEP): configurado de forma compatível com recursos externos necessários.Cross-Origin-Opener-Policy (COOP): same-origin — isola o browsing context contra ataques side-channel.Cross-Origin-Resource-Policy (CORP): same-origin — restringe acesso a recursos ao mesmo domínio.X-Permitted-Cross-Domain-Policies: none — bloqueia políticas Flash/PDF cross-domain.4. POLÍTICA DE SCRIPTS E CONTEÚDO
A política CSP reduz a chance de scripts inesperados rodarem no navegador:
script-src usa identificador por requisição e strict-dynamic.upgrade-insecure-requests força HTTPS nos recursos.frame-ancestors 'none' protege contra carregamento indevido em iframe.Fontes externas ficam limitadas aos domínios aprovados.Proteção da cadeia de dependências usada no portal:
Lockfile versionado: O package-lock.json torna a instalação previsível em CI/CD.npm audit: Bloqueio de vulnerabilidades críticas/altas na esteira de validação.License Audit: Checagem de licenças de produção para reduzir risco jurídico.Inventário de dependências: A árvore instalada fica rastreável pelo lockfile.O portal é uma aplicação Next.js hospedada em ambiente gerenciado. A baseline de release evita assumir privilégios desnecessários:
Build Reprodutível: package-lock.json versionado e instalação previsível por CI.Runtime Enxuto: Código público, rotas API e integrações externas separados por responsabilidade.Sem PWA: Não há manifesto, install prompt ou app-shell offline. O endpoint /sw.js é apenas um tombstone de desinstalação para remover service workers antigos e limpar caches.Sem Segredos no Frontend: Chaves privadas de pagamento, e-mail e automações não podem aparecer em NEXT_PUBLIC_*.7. CONTROLES LGPD & PROTEÇÃO DE DADOS
.strict()).Direitos do Titular: Solicitações de titulares seguem o prazo legal aplicável, com triagem inicial e registro interno.8. SEGURANÇA DE PAGAMENTO E ENTREGA
9. HEADERS DE SEGURANÇA IMPLEMENTADOS
10. SEGURANÇA DE EMAIL (DMARC / SPF / DKIM)
Proteção em camadas contra spoofing, phishing e falsificação de identidade:
DMARC: v=DMARC1; p=reject — Política de rejeição total. Emails não-autenticados são descartados na origem.SPF/DKIM: O domínio raiz mantém Zoho como remetente autorizado. E-mails transacionais enviados por Resend devem usar domínio ou subdomínio verificado no provedor, com SPF, DKIM, MX/return-path e DMARC alinhados antes de qualquer disparo em produção.Monitoramento: Relatórios forenses (ruf), agregados (rua), bounces, complaints e suppressions são tratados como sinais operacionais para bloqueio, reenvio seguro ou investigação.Selos e links externos, quando exibidos, servem como verificação pontual e não como promessa permanente:
SSL / Headers: Devem ser conferidos nos validadores públicos antes de campanhas relevantes.DMCA.com Protection: Monitoramento e takedown de conteúdo quando ativo.Google Safe Browsing / reputação: Status pode mudar e deve ser revalidado periodicamente.Registro Interno: Mudanças de segurança relevantes devem deixar evidência em CI, logs sanitizados e checklist de release.Documento mantido com controles de segurança e privacidade.
DMARC/SPF/DKIM · HSTS em produção · CSP com nonce por rota · logs sanitizados
verificado independentemente · clique em qualquer selo para auditar