O pior incidente possível numa plataforma como esta é o dado de um hospital aparecer na tela de outro. Partimos do princípio de que o atacante pode ser um usuário legítimo de outra instituição, e por isso a separação é verificada duas vezes, por mecanismos diferentes. Abaixo está cada proteção pelo que ela garante, com o termo técnico logo depois, para quem precisa reconhecer. No fim, a lista do que ainda não está no lugar.
A separação por organização e por unidade é verificada na aplicação e verificada de novo no banco de dados. Não é a mesma checagem repetida por precaução: são dois mecanismos com origens diferentes, para que uma falha em um deles seja contida pelo outro.
Toda operação protegida percorre a cadeia de autorização completa na API antes de executar: autenticação, organização, assinatura, módulo contratado, funcionalidade habilitada, permissão do papel, unidade autorizada e limite de consumo. Cada passo devolve um erro diferente, de propósito, porque não ter o módulo contratado e não ter permissão são problemas distintos para quem vai resolver.
No PostgreSQL, políticas de Row Level Security filtram as linhas por organização e por unidade. A aplicação conecta com um papel sem SUPERUSER e sem BYPASSRLS, portanto as políticas valem também para ela. Um erro de autorização escrito na aplicação não é suficiente para atravessar a fronteira entre dois clientes.
A aplicação informa ao banco apenas o identificador do usuário autenticado. Não informa a organização, não informa a unidade e não informa as permissões: o banco deriva tudo isso sozinho, a partir do usuário. Na prática, a aplicação não consegue mentir sobre a qual instituição ela pertence, porque ela nunca afirma isso.
Ao lado está uma tentativa de acesso indevido percorrendo a verificação: um profissional da unidade A pedindo o atendimento de um paciente da unidade B. O pedido para antes de executar, e a tentativa fica registrada.
Esse cenário é repetido pelos testes automatizados a cada alteração do código, e precisa falhar na aplicação e falhar também no banco. Um teste que só prova que o acesso permitido funciona não é evidência de separação entre instituições.
Ver de onde vem cada orientação clínicaEsconder um item do menu não é controle de acesso, e por isso a verificação acontece no servidor, e não na tela. Ter o módulo contratado não dá permissão ao usuário, e a permissão do usuário não dispensa o consentimento do paciente.
A segunda camada não é uma política só. São quatro mecanismos de naturezas diferentes, e essa diversidade é intencional: uma política mal escrita não derruba os outros três.
A permissão de operação decide se o papel usado pela aplicação pode sequer ler ou escrever naquela tabela. É a pergunta anterior a qualquer filtro de linha.
É a política de linha do Row Level Security, derivada da organização e das unidades a que o usuário tem acesso. Vale para leitura e vale para escrita, o que impede também gravar dado no lugar errado.
A chave estrangeira é composta: ela carrega a organização junto da unidade. A mistura deixa de ser um erro que alguém precisa lembrar de evitar e passa a ser uma gravação que o banco recusa.
A trilha de auditoria e os retratos de caso são append-only: alteração e remoção são recusadas pelo próprio banco, por gatilho, e não pela disciplina de quem escreve o código. Nem quem administra o sistema consegue reescrever o que ficou registrado.
A identidade de quem faz o pedido vale apenas durante aquela transação e é descartada no fim dela. Quando a conexão volta para o conjunto reaproveitado, ela não carrega mais o contexto de quem a usou antes. Esse é um dos erros mais comuns e mais graves em segurança de linha com conexão reaproveitada, e a escolha está registrada na documentação de arquitetura do projeto.
Dado pessoal e dado de saúde são cifrados pela aplicação antes de serem gravados, com o identificador da chave registrado em cada linha. É isso que permite trocar a chave sem perder o histórico, que é a diferença entre ter cifra e ter cifra operável.
O navegador nunca fala com o banco de dados. Ele fala apenas com a API, que é a única camada autorizada a tocar dado clínico. Chave de provedor externo, credencial de banco e segredo de sessão existem somente no servidor, e um verificador impede a publicação se encontrar qualquer um deles no que iria ao navegador.
A busca usa um código determinístico derivado do documento com HMAC-SHA256 e um segredo do servidor. O mesmo número gera sempre o mesmo código, o que permite localizar o cadastro, e o código não permite voltar ao número original. Não existe índice sobre texto claro, e a tela nunca exibe o documento completo.
O log nunca recebe dado pessoal, dado clínico, token ou credencial. O componente de log tem função de redação, e a auditoria recusa chaves sensíveis por gatilho no próprio banco. Identificador de paciente, nome e dado clínico também não aparecem no endereço da página, porque endereço vai para o histórico do navegador e para o registro do proxy.
A gravação depende de consentimento registrado, de indicador visual permanente durante a captura e de uma política de retenção aprovada pela instituição, com teto definido. A transcrição é cifrada e o áudio fica em armazenamento privado, acessível apenas por endereço assinado de vida curta. A gravação contínua nasce desligada.
Dado identificável só vai para provedor externo com contrato, região verificada e autorização específica da instituição. O provedor usado é informado antes da contratação. O sistema também não aprende regra clínica a partir de prontuário e não transforma o feedback de um profissional em regra para os demais.
A sessão vive apenas em cookie que o JavaScript não consegue ler, expira por tempo absoluto e por inatividade, e o encerramento é revogado no servidor. Gerenciar acessos, ouvir áudio de paciente, exportar dados, alterar retenção, aprovar protocolo e consultar a trilha de auditoria pedem autenticação de novo dentro do fluxo.
Respostas curtas e autocontidas, prontas para serem copiadas para o formulário de avaliação de fornecedor da sua instituição. Cada uma tem endereço próprio nesta página, para você mandar o link direto de uma delas.
O isolamento é aplicado em duas camadas independentes. Na API, cada operação verifica organização, unidade, papel e permissão antes de executar. No banco de dados PostgreSQL, políticas de Row Level Security filtram as linhas por organização e por unidade. Uma camada nunca substitui a outra, e a negação é exercitada por teste automatizado a cada alteração.
Não. A aplicação conecta com um papel sem SUPERUSER e sem BYPASSRLS, então as políticas valem também para ela. Além disso, a API informa ao banco apenas o identificador do usuário autenticado: não informa a organização, não informa a unidade e não informa as permissões. O banco deriva tudo isso sozinho.
A busca usa um código determinístico derivado do CPF por HMAC-SHA256 com um segredo do servidor. O mesmo CPF gera sempre o mesmo código, o que permite localizar o cadastro, e o código não permite voltar ao número original. Não existe índice sobre texto claro, e a tela nunca exibe o documento completo.
Não. O registro técnico nunca recebe dado pessoal, dado clínico, token ou credencial: o componente de log tem função de redação, e a auditoria recusa chaves sensíveis por gatilho no próprio banco. A trilha de auditoria guarda a referência do que foi acessado e por quem, e não o conteúdo do que foi lido.
Não. A trilha é append-only: não aceita alteração nem remoção, e isso é garantido por permissão do banco e por gatilho, não por disciplina de quem escreve o código. Toda ação sensível gera registro na mesma transação da operação, o que impede que uma delas exista sem a outra. A tentativa negada também é registrada.
Nunca. O navegador fala apenas com a API, e a API é a única camada autorizada a tocar dado clínico. Chave de provedor de inteligência artificial, credencial de banco e segredo de sessão existem somente no servidor. Um verificador roda no build e falha a publicação se encontrar segredo, comentário ou endereço interno no que iria ao navegador.
Por arquivo de migração numerado e versionado, revisado antes de rodar e com plano de volta escrito. Produção nunca é alterada à mão. As migrações são aplicadas automaticamente na publicação, depois da verificação automatizada passar, e voltar a versão da aplicação não desfaz migração: o schema só anda para frente.
Esta lista sai da nossa documentação de operação e é reproduzida aqui sem edição de conveniência. Preferimos que você leia agora, e não que descubra na diligência. Se algum destes itens for impeditivo para a sua instituição, é melhor saber antes da primeira reunião.
O contexto que torna a lista legível: a plataforma ainda não opera com dado real de paciente. São exatamente estes os itens que precisam fechar antes disso.
O backup é diário e cifrado, e a restauração já foi comprovada contra o schema real. O que falta é a cópia externa, junto com a chave de cifra correspondente, que hoje existe apenas no mesmo servidor.
Falta monitoramento com alerta ativo, plano escrito de resposta a incidente com quem aciona quem, e um ambiente de homologação separado do de produção.
Nada é publicado sem passar pela verificação automatizada, que inclui testes de acesso negado contra um banco real. O que falta é a exigência formal de revisor humano e o bloqueio de reescrita de histórico no repositório.
A credencial usada pela publicação automática ainda não está separada da credencial administrativa do servidor. A separação está definida e pendente de execução.
A verificação de dependências roda a cada integração e a atualização de versão é automatizada, mas o alerta dedicado de vulnerabilidade ainda não está ligado.
Documentos jurídicos ainda em revisão, incluindo a política de privacidade e os termos de uso, estão sinalizados como pendentes nas próprias páginas. Nenhuma afirmação de conformidade é feita neste site sem parecer que a sustente.
A conversa mais produtiva com uma área de segurança começa pelo formulário que ela já usa. Respondemos item a item, apontando o que está implementado e verificado, o que está escrito mas ainda não exercitado, e o que não existe.
Falar com um especialistaAs telas exibidas neste site usam dados sintéticos e servem para demonstrar a interface. Nenhum dado de paciente real é utilizado em material público.