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, e ela é a que não depende de ninguém lembrar: toda consulta ao banco carrega o identificador da clínica. Um verificador percorre o código inteiro a cada publicação e a reprova se encontrar uma consulta sem esse filtro — as exceções deliberadas são poucas, nomeadas e trazem o motivo escrito. Isolamento entre clínicas não é uma regra que cada rota precisa repetir corretamente; é uma condição que o build confere.

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 Astantis CRM, 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.

Três regras que valem sempre, sem exceção:

1. Nunca pedimos sua senha: por e-mail, telefone, WhatsApp ou qualquer outro canal. Ninguém da nossa equipe precisa dela para ajudar você — nem nós conseguimos vê-la, porque o banco guarda só um resumo criptográfico.
2. Nunca pedimos o código de verificação: o código de 6 dígitos que chega por e-mail serve só para você digitar na nossa tela de login. Quem pedir esse código está tentando entrar na sua conta naquele exato momento.
3. Todo link nosso aponta para o nosso domínio: antes de clicar, passe o mouse sobre o link e confira o endereço. Se ele leva para outro domínio, não é nosso.

Nossos e-mails automáticos avisam quando algo importante muda na sua conta: um acesso de dispositivo novo, uma troca de senha e uma troca do e-mail de acesso. Se você receber um desses avisos e não reconhecer a ação, troque a senha imediatamente e avise quem administra a clínica.

Recebeu um e-mail suspeito em nome do Astantis CRM? Não clique em nada e encaminhe para o nosso canal de privacidade — o endereço está na Política de Privacidade.