Central de Confiança

1. Arquitetura e localização

Clientes Enterprise podem ter instalação própria, com um banco de dados exclusivo. Lista completa em Fornecedores.

2. Identidade e sessão

• Entrada por e-mail com código de uso único ou pela conta Google; só entra quem tem perfil ativo.
• Sessão assinada pela plataforma, válida por até 8 horas, num cookie inacessível a scripts.
• Sair encerra a sessão; mudar o papel ou desligar uma pessoa derruba o acesso dela. Limitação: partes da plataforma que não consultam o banco aceitam a sessão até ela vencer (no máximo 8 horas).
• Freio contra tentativas repetidas de login, com registro embaralhado apagado em 1 dia.
• Toda função que gasta recurso ou lê dados exige sessão no servidor.
• Limitação: CPF e matrícula identificam a pessoa, mas não são segundo fator de autenticação.

3. Autorização

• Acesso negado por padrão no banco, no motor dos apps e no painel de administração.
• Regras por linha em todas as tabelas; quem não entrou não lê dados da plataforma.
• Visibilidade por app: pessoal (dono e construtores convidados), área ou empresa. A administração não vê automaticamente o conteúdo pessoal de outras pessoas.
• Regras de cada app publicado conferidas no servidor.

4. Segredos e criptografia

• Chaves de IA e do banco só no servidor; o navegador e os apps nunca as recebem.
• Credenciais das integrações num cofre cifrado (AES-GCM), com a chave fora do banco.
• Tráfego sempre em HTTPS; banco cifrado em repouso pelo fornecedor.
• Limitação conhecida: os dados cadastrados nos apps não são cifrados campo a campo. As regras de acesso decidem quem lê pela plataforma, mas quem tem acesso administrativo ao banco ou aos backups lê o conteúdo. Não use apps para guardar senhas.

5. Proteções da aplicação web

• HTTPS obrigatório (HSTS), com o prazo aumentado aos poucos.
• Política de segurança de conteúdo (CSP) mínima aplicada e a completa em observação.
• Conferência da origem em toda escrita, contra pedidos forjados por outros sites.
• Os apps rodam num quadro separado, com armazenamento local isolado por app, e nunca recebem a sessão: pedem à página, que chama o servidor.

6. Integrações e chamadas externas

• Endereços internos e redirecionamentos são barrados antes de cada chamada externa. Risco aceito: nomes que apontam para endereço interno não são barrados (o servidor não alcança rede interna).
• Integrações corporativas (Microsoft 365, Google Workspace) só com autorização da empresa e tokens no cofre.

7. Inteligência artificial

Limite diário por pessoa, teto por pedido e registro de cada chamada só com metadados, sem o texto. Veja IA e seus dados.

8. Auditoria e rastreabilidade

• Registro de ações (quem, o quê, quando) que ninguém altera nem apaga pela plataforma.
• Versões publicadas dos apps, com volta para a anterior.
• Pedidos de privacidade e anonimizações registrados (o fato e o tipo, nunca o texto).

9. Privacidade por padrão

• Em Privacidade e meus dados, você baixa os dados da sua conta e faz pedidos.
• Anonimização de pessoas sem quebrar o histórico.
• Ao sair, o navegador apaga as cópias locais dos apps.

10. Desenvolvimento e continuidade

• Toda mudança passa por checagem de tipos, lint, testes automatizados e build antes de ir ao ar; mudanças no banco são ensaiadas num banco local equivalente.
• Publicação só pelo fluxo revisado do repositório, sem envio manual.
• Limitações: a integração contínua automática está desligada (a validação é feita antes de cada publicação); frequência de backup e teste de restauração ainda a definir; sem acordo de nível de serviço (SLA) nesta fase.

11. Fale com a segurança

Achou uma vulnerabilidade? Escreva para Douglas Karnoski (encarregado) — [email protected] (um canal próprio de segurança está em definição). Pedimos que você não explore a falha nem acesse dados de terceiros.

Sob pedido de clientes: acordo de tratamento de dados (DPA), lista de suboperadores, plano de resposta a incidentes, registro das operações de tratamento e modelo de relatório de impacto (RIPD).