Segurança e confiança
Como o QLAC protege dados, projetos, relatórios e acessos sem reivindicar certificações não obtidas nem prometer risco zero.
Última atualização: 2026-05-11
1. Princípio de segurança
O QLAC foi desenhado para tratar informação técnica de projetos com separação entre console interno e Portal Cliente, permissões por função, validação de ownership e rastreabilidade de ações sensíveis.
2. Acesso e isolamento
- Backoffice reservado a perfis internos autorizados.
- Portal Cliente separado por rotas, layouts, policies e dados filtrados.
- Clientes devem ver apenas projetos, relatórios, documentos e evidências autorizados para seu tenant.
- Downloads privados por controladores autorizados, sem expor paths reais de storage.
3. Arquivos, repositórios e evidências
ZIPs e arquivos de projeto são tratados como não confiáveis. O QLAC valida formato, tamanho, paths perigosos, symlinks, nested archives e armazenamento privado. Fluxos cliente não executam código enviado.
GitHub e GitLab, quando disponíveis, devem usar consentimento explícito, permissões mínimas, tokens criptografados e revogação visível.
4. Auditorias e limites
Lighthouse executa com validação SSRF, filas, timeouts e armazenamento privado de artefatos. Os resultados são dados de laboratório e rotulados como tal. O QLAC não apresenta Lighthouse como certificação nem como medição direta de INP real.
5. Billing e dados de pagamento
Paddle atua como provedor de pagamento quando checkout está ativo. O QLAC guarda estados, planos, eventos e referências necessárias para assinatura, mas não armazena cartões nem dados bancários.
6. Transparência
O QLAC comunica medidas razoáveis, limites e responsabilidades. Não afirma ISO 27001, SOC 2, OWASP certified, NIST certified nem segurança absoluta salvo certificação real e verificável.