Isolamento por empresa, aplicado no banco de dados
Cada tabela que guarda dado de clínica — pacientes, mensagens, agenda, prontuário, financeiro — tem uma política de Row-Level Security (RLS) aplicada diretamente no PostgreSQL, não só na lógica da aplicação. Isso significa que mesmo que uma consulta ao banco tivesse algum erro de código, o próprio banco de dados nega acesso a linhas que não pertencem à empresa autenticada naquele momento — quem decide qual empresa está “ativa” numa consulta é sempre o servidor, derivado da sessão de quem está logado, nunca um valor que o navegador possa enviar.
Esse controle é fail-closed: se por algum motivo o contexto de qual empresa está consultando não estiver definido, a política nega tudo — o sistema prefere devolver nenhum resultado a devolver o resultado errado.
Cifra em repouso
Além do isolamento por linha, alguns dados especialmente sensíveis são cifrados antes de serem gravados — não bastam a permissão de acesso, o dado em si fica ilegível sem a chave certa. Isso cobre, entre outros: conteúdo de mensagens (WhatsApp/Instagram), notas clínicas, CPF, e os tokens de acesso das integrações Meta. Cada categoria usa chave própria, então comprometer uma finalidade não abre as demais. Onde o modelo exige, a cifra ainda amarra o conteúdo ao identificador da empresa dona daquele dado — então nem uma cópia do banco, sozinha, seria suficiente pra decifrar tudo de uma vez.
Autenticação e sessões
- Autenticação em duas etapas (MFA) disponível, e obrigatória para papéis com mais privilégio (dono, administrador, gerente) quando a empresa ativa essa política.
- Ações sensíveis (ex.: desativar MFA, alterar permissão de outro usuário) exigem uma confirmação recente de identidade — não basta a sessão estar aberta, mesmo que ainda válida.
- Sessão fica em cookie protegido contra leitura por JavaScript malicioso (
httpOnly) em produção.
Auditoria — um registro que ninguém apaga
Ações relevantes (quem aprovou o quê, quem mudou permissão de quem, quem excluiu um registro) ficam num log de auditoria em que cada entrada carrega um encadeamento criptográfico com a entrada anterior — se alguém tentasse alterar ou remover um registro antigo sem refazer toda a cadeia depois dele, isso ficaria detectável. A própria aplicação bloqueia qualquer tentativa de editar ou apagar um registro de auditoria já gravado.
LGPD: retenção e exclusão
Dados de atendimento (mensagens de CRM) seguem um prazo de retenção definido — parâmetro operacional atual de até 730 dias, salvo exigência legal diferente — depois do qual são removidos automaticamente por um processo periódico, não por lembrete manual de alguém da equipe. Empresa cliente ou paciente final que queira solicitar a exclusão de dados específicos antes disso pode fazer isso a qualquer momento — ver Exclusão de Dados.
O que fazemos quando algo falha
Falha de comunicação com um provedor externo (Meta, gateway de pagamento) nunca é tratada como “desistir na hora” — o sistema distingue um problema temporário (rede instável, limite de uso momentâneo) de um erro definitivo (dado inválido, permissão ausente), e só marca algo como falho de verdade depois de esgotar tentativas razoáveis. Isso evita tanto alarme falso quanto silêncio quando algo realmente precisa de atenção humana.
Encontrou algo que parece uma falha de segurança? Fale com a gente antes de divulgar publicamente — preferimos corrigir rápido a discutir depois.
Tratamento completo de dados pessoais: Política de Privacidade. Termos de uso da plataforma: Termos de Uso.