Segurança — Askio

1. Controles verificáveis

entrada por Google OAuth ou código temporário por e-mail;
origens confiáveis configuráveis na camada de autenticação;
segredos mantidos em variáveis de servidor, fora do frontend;
escopo por tenant e workspace nos principais módulos Convex;
validação server-side de permissões em operações protegidas;
auditoria de ações sensíveis nos fluxos que a implementam;
hash ou redação de identificadores sensíveis em fluxos revisados;
vínculo entre a sessão de upload, usuário, finalidade, tenant, workspace e resumo criptográfico quando o fluxo o fornece;
validação de tipo e tamanho nos uploads compatíveis;
validação server-side de tipo, tamanho, vínculo, escopo e resumo criptográfico antes do processamento documental;
payloads de webhook sanitizados conforme o contrato do WhatsApp.

2. Responsabilidade compartilhada

O escritório deve manter usuários e permissões atualizados, proteger contas de e-mail, revisar contatos autorizados, classificar documentos e não inserir dados além do necessário. Códigos temporários, tokens e credenciais nunca devem ser compartilhados.

Integrações externas precisam de contas e configurações próprias. Uma indicação visual não substitui a confirmação do servidor ou do fornecedor.

3. Limites atuais

Algumas configurações operacionais ainda são demonstrativas e não representam controles ativos. Prazos de retenção configuráveis, expurgo automático, exportação LGPD, mascaramento universal, exclusão self-service e matriz completa de sensibilidade dependem de trabalho adicional no backend e na operação. O Askio não executa detecção de malware; arquivos enviados permanecem conteúdo não confiável e passam apenas pelos controles técnicos descritos nesta página.

O Askio não reivindica atualmente certificações ISO 27001, SOC 2, PCI DSS ou certificação de conformidade LGPD; tampouco promete monitoramento 24×7, criptografia ponta a ponta, residência exclusiva no Brasil ou ausência total de incidentes.

4. Reporte responsável

Vulnerabilidades e incidentes devem ser reportados por um canal privado de segurança, a ser publicado após definição da pessoa jurídica responsável. Inclua rota, impacto e passos de reprodução minimizados. Não envie credenciais, documentos ou dados reais de clientes.

O widget público de feedback e issues públicas do GitHub não devem ser usados para vulnerabilidades ou incidentes. Não existe programa de bug bounty enquanto ele não for formalmente anunciado.

5. Incidentes e continuidade

Eventos suspeitos devem ser contidos, registrados, investigados e avaliados conforme o impacto. Comunicações a clientes, titulares ou autoridades dependem da natureza do incidente e das obrigações aplicáveis; esta página não substitui o plano operacional de resposta.

6. Próximos controles