Segurança

Cada empresa isolada

Cada empresa cliente é separada das outras no próprio banco de dados, com Row Level Security do PostgreSQL: toda consulta só enxerga as linhas da empresa em uso, mesmo que haja um erro no código da aplicação. A aplicação se conecta ao banco com um usuário sem permissão para desligar essa regra.

Um prestador PJ que atende várias empresas vê os próprios dados em cada uma, mas uma empresa nunca vê o que o PJ tem com outra. Dentro da empresa, cada pessoa só acessa o que o perfil dela e as políticas da empresa permitem, como o sigilo por área.

Criptografia

• No caminho: toda conexão usa HTTPS, com TLS 1.2 ou superior, do seu aparelho até os nossos servidores.
• Nos dados: CPF, arquivos de contratos e notas, comprovantes, segredos das duas etapas e mensagens com dados pessoais são cifrados pela aplicação antes de chegar ao banco ou ao armazenamento. Quem tivesse acesso só ao banco ou aos arquivos veria dados ilegíveis.
• Nas chaves: as chaves de criptografia ficam fora do banco e do código, e podem ser trocadas sem parar o sistema, recifrando tudo com a chave nova.
• Nas buscas: o CPF continua pesquisável por um código derivado com chave secreta (HMAC), e não por um hash simples, que seria fácil de reverter.
• Nas cópias de segurança: os backups do banco são cifrados antes de sair do servidor.

Senhas, duas etapas e sessões

Senhas

• Pelo menos 15 caracteres, sem regras de composição: uma frase funciona bem.
• Senhas que aparecem em vazamentos conhecidos são recusadas. A conferência é anônima: só os 5 primeiros caracteres de um código derivado da senha saem do Pejotiza, nunca a senha ou o seu e-mail.
• Guardamos só o resultado do argon2id, um cálculo feito para ser caro de reverter.
• Contra tentativas repetidas, cada erro de um aparelho desconhecido aumenta o tempo de espera e, depois de alguns, exige o desafio "não sou robô" da Cloudflare. Quem entra pelo aparelho de sempre, reconhecido por um cookie de segurança de 90 dias, não é travado por um invasor; o dono recebe um e-mail quando há muitas tentativas. O login responde igual, exista ou não o e-mail, para não revelar quem tem conta.

Verificação em duas etapas

• Com aplicativo autenticador (como Google Authenticator ou Microsoft Authenticator) ou com chave física e passkey (padrão FIDO2/WebAuthn).
• Obrigatória para os perfis admin e financeiro. A empresa pode exigi-la de todos e aceitar só chaves presas a um aparelho, sem cópia na nuvem.
• Entrar com Google ou Microsoft substitui só a senha: as duas etapas continuam valendo.
• 10 códigos de recuperação, mostrados uma única vez, para quando o celular não estiver à mão.

Sessões

• No navegador, a sessão fica num cookie que os scripts da página não conseguem ler, e termina com 30 minutos sem uso ou 8 horas depois do login.
• No app, as chaves ficam no armazenamento seguro do celular e são renovadas a cada 15 minutos. Se uma chave antiga for reutilizada, todas as sessões da pessoa são encerradas.
• Trocar a senha encerra as sessões em todas as empresas.
• Ações sensíveis, como mudar senha, duas etapas ou sessões, pedem a senha de novo se o login tiver mais de 15 minutos.
• Você vê as próprias sessões abertas e pode encerrar qualquer uma.

Documentos assinados

Todos os signatários assinam o mesmo arquivo, identificado por uma impressão digital (hash SHA-256). Cada assinatura é confirmada com um código de uso único enviado ao e-mail de quem assina, e cada passo fica registrado com data, hora, IP, porta e navegador. No fim, o PDF é selado no padrão PAdES com o certificado da plataforma e um carimbo do tempo: qualquer alteração posterior aparece ao abrir o arquivo.

Registros e auditoria

• Trilha de auditoria: cada inclusão, alteração ou exclusão nas tabelas da plataforma é registrada pelo próprio banco. Nem a aplicação consegue alterar ou apagar esses registros. E-mails, telefones e segredos ficam fora da cópia.
• Registros de acesso: IP, porta, data e hora de cada acesso, guardados por 6 meses como exige o Marco Civil da Internet. A consulta é restrita, exige um motivo e também fica registrada.
• Eventos de segurança: logins, falhas, trocas de senha e mudanças nas duas etapas, por 12 meses.
• Sem dados pessoais nos logs da aplicação: nem e-mails, nem tokens, nem conteúdo de mensagens.

Acesso da equipe do Pejotiza

A administração da plataforma usa um acesso separado, com duas etapas obrigatória, que não lê os dados das empresas clientes. Só o encarregado de dados pode acessar dados de uma empresa, e só para atender um pedido do titular ou da própria empresa, responder a um incidente ou cumprir ordem judicial. Nesse caso, ele confirma a senha e informa o motivo; o acesso tem limite por hora, gera aviso por e-mail aos responsáveis pela plataforma e fica registrado para sempre.

Infraestrutura

• A Cloudflare fica na frente de tudo: protege contra ataques de negação de serviço, filtra tráfego malicioso e limita tentativas na rota de login.
• Os servidores só aceitam conexões vindas da Cloudflare, e o acesso administrativo exige chave criptográfica.
• Os bancos de dados e as filas internas não ficam abertos para a internet.
• Dados reais ficam só no ambiente de produção. Testes e desenvolvimento usam dados fictícios.

Onde ficam os servidores e quais fornecedores tratam dados: veja Transferência internacional de dados.

Incidentes

Se algo acontecer, seguimos um roteiro escrito, desde o primeiro minuto:

1. contemos o problema, revogando acessos e sessões;
2. preservamos as evidências;
3. avisamos as empresas clientes afetadas em até 24 horas, com o que já se sabe;
4. quando somos o controlador dos dados e há risco relevante, comunicamos a ANPD e as pessoas afetadas em até 3 dias úteis (Resolução CD/ANPD nº 15/2024);
5. registramos o incidente e as medidas tomadas, e guardamos esse registro por 5 anos.

Encontrou uma falha?

Escreva para [email protected] com a descrição e os passos para reproduzir. Pedimos que você não acesse dados de outras pessoas nem divulgue a falha antes da correção. Respondemos o quanto antes e contamos o que foi feito.