Prontuário médico é dado sensível. Tratamos assim.

Esconder um botão na tela não impede alguém de chamar a rota por trás dele — por isso a checagem de permissão acontece de novo no servidor, em toda requisição, independente do que a interface mostra.

Na prática, cada rota da API passa por duas camadas antes de tocar qualquer dado:

1. Sessão válida — o token de sessão é verificado antes de qualquer outra coisa. Sem sessão, a resposta é recusada (401), nem chega perto da lógica da rota.
2. Permissão para aquele módulo ou ação — o perfil da sessão (Gestor, Médico, Recepção, Desenvolvedor) é comparado contra o que aquela rota específica exige. Um médico tentando acessar uma rota do módulo Financeiro recebe 403 (Acesso negado), mesmo tendo uma sessão válida.

Há ainda uma terceira camada em rotas que lidam com dados de um paciente específico: mesmo um médico com acesso ao módulo clínico só enxerga prontuários de pacientes com quem já teve algum agendamento — um médico não consegue abrir o prontuário de um paciente que nunca atendeu, só porque adivinhou o identificador dele.

O registro fica disponível para o gestor consultar a qualquer momento, em Configurações → Auditoria, com filtros por perfil, por pessoa e por período — útil tanto para investigar um problema pontual quanto para atender uma exigência de conformidade no futuro.

Cada linha da trilha guarda, no mínimo:

• quem fez a ação (nome e perfil de acesso no momento);
• o que foi feito (criar paciente, assinar prontuário, emitir prescrição, criar ou remover usuário, alterar a própria senha, entre outras);
• a entidade afetada e seu identificador, quando aplicável;
• data e hora exatas do servidor — não o relógio do computador de quem agiu.

O registro de auditoria é gravado de forma independente da ação principal: mesmo que o registro de auditoria falhe por algum motivo, ele nunca bloqueia nem reverte a ação do usuário — e o inverso também vale, a ação em si não depende da auditoria para acontecer.

Mesmo que a aplicação seja comprometida, a credencial que ela usa não tem permissão para alterar a estrutura do banco — só para ler e escrever os dados do dia a dia.

Algumas camadas adicionais de isolamento:

• Rede privada Docker — o banco não tem porta exposta na internet pública; só os containers da própria aplicação, na mesma rede interna, conseguem alcançá-lo.
• Credenciais separadas por função — a credencial usada pela aplicação no dia a dia é diferente da credencial usada para aplicar migrações de schema, que só é usada manualmente, no momento de um deploy.
• Acesso administrativo só por túnel SSH — quando é preciso inspecionar o banco diretamente (raramente), o acesso passa por um túnel autenticado por chave, nunca por uma porta aberta ao público.
• Backups diários com rotação — reduz o impacto de uma falha de infraestrutura ou de um erro operacional.

Documentos anexados ao prontuário (exames, PDFs) também ficam salvos direto no banco, não em um serviço de arquivos externo — um ponto a menos de exposição.

O hash é uma via de mão única — não existe forma de “descriptografar” de volta para a senha original, nem para quem tem acesso direto ao banco de dados.

O algoritmo usado é o bcrypt, com um fator de custo deliberadamente alto — o que torna cada tentativa de adivinhação por força bruta computacionalmente cara, mesmo que alguém consiga uma cópia do banco de dados. Cada senha recebe também um “sal” único, então duas pessoas com a mesma senha nunca geram o mesmo hash — o que impede ataques baseados em tabelas pré-computadas (rainbow tables).

Trocar a própria senha (Configurações → Minha conta) sempre exige informar a senha atual antes de definir a nova.

Depois de várias tentativas seguidas sem sucesso, novas tentativas para aquela conta ficam bloqueadas por um tempo — o suficiente para inviabilizar um ataque automatizado sem atrapalhar quem só errou a senha uma vez.

O limite é aplicado no servidor, por origem da tentativa — não depende de nenhuma configuração no navegador de quem está tentando entrar, então não há como simplesmente limpar o histórico ou trocar de aba para contornar o bloqueio. Passado o tempo de espera, as tentativas voltam ao normal automaticamente, sem precisar de intervenção manual do gestor ou do suporte.

Os quatro perfis do ClinCRM, e o que cada um foi desenhado para enxergar:

• Gestor — visão completa da clínica: dashboard geral, agenda de todos os médicos, financeiro, estoque, documentação legal e gestão de usuários.
• Médico(a) — área médica, prontuário e prescrição; a própria agenda e os próprios pacientes, não os de outros profissionais.
• Recepção — agendamento, cadastro de pacientes e um dashboard operacional enxuto; sem acesso ao conteúdo clínico do prontuário nem ao financeiro.
• Desenvolvedor(a) — acesso técnico de manutenção, incluindo as áreas administrativas, para suporte e evolução do sistema.

Veja a lista completa de recursos por perfil na página de recursos.