Brain Tower

Segurança

Como o Brain Tower protege os dados de saúde

Em saúde, segurança não se promete: se prova. Esta página mostra o que protege os dados — e a prova. Uma parte roda agora, enquanto você lê; a outra roda a cada alteração do sistema, contra um banco de verdade.

Prova ao vivo, agora

Ao abrir esta página (a prova é refeita a cada minuto), o servidor fez o que qualquer pessoa na internet poderia fazer: pegou a chave pública do Brain Tower — a mesma que vai no navegador de todo mundo — e tentou ler o que não é dela. O banco precisa recusar tudo.

O que tentamos, sem login	Resultado	O que o banco respondeu
Ler o painel de um consórcio	recusado	o banco recusou (HTTP 401: permission denied for table painel_bundle)
Ler quem tem acesso a cada cliente	recusado	o banco recusou (HTTP 401: permission denied for table membro)
Ler a trilha de auditoria	recusado	o banco recusou (HTTP 401: permission denied for table auditoria)
Ler o cadastro de pacientes da central	recusado	o banco recusou (HTTP 406: Invalid schema: agenda)
Pedir a fila de pacientes de uma cidade	recusado	o banco recusou (HTTP 401: permission denied for function central_fila)
Abrir um lembrete de consulta sem o link	recusado	o banco recusou (HTTP 401: permission denied for function cidadao_lembrete)

Tudo recusado · conferido em 26/10/2026, 20:14:46

O que protege

O dado do paciente fica numa área separada

O cadastro, a fila e os horários dos pacientes moram numa parte do banco que não se abre para fora. Só se chega a eles pelas funções do próprio sistema, que conferem o papel de quem pede antes de responder — e cada ficha aberta fica registrada.

Um cliente não vê o outro

Vários consórcios e municípios usam a mesma instalação. A regra de quem vê o quê está escrita dentro do banco, e não só na tela: mesmo apontando o código de outra cidade, o banco não entrega.

A sessão não fica aberta

Nas telas da equipe, fechou o navegador, saiu; 20 minutos sem uso, saiu — conferido no servidor a cada pedido e na própria tela, que avisa 2 minutos antes. Num plantão, quem sai não deixa o sistema aberto para quem chega.

Senha sozinha não abre

Quem vê dado de paciente entra com a senha e um código que só o celular dele gera — é obrigatório. Sem o código, o banco não entrega nada, nem chamando o banco direto, por fora das telas. Para o resto da equipe, a verificação é opcional e recomendada.

O histórico não se apaga

Quem entrou, quem liberou acesso a quem, quem abriu a ficha de um paciente e cada versão do painel ficam registrados, e o registro não se reescreve nem se apaga — nem pelo administrador do servidor.

A senha não passa pela Brain

A senha é guardada pelo serviço de login com criptografia de mão única (bcrypt): ninguém da Brain consegue lê-la. Na recuperação de senha, a resposta é sempre a mesma, para não revelar se um e-mail tem cadastro.

Link sem login vale só para uma coisa

O lembrete de consulta e a TV da recepção abrem sem login, por um código de 144 bits que vale só para aquilo. O banco guarda apenas a impressão digital do código — quem lê o banco não consegue montar o link. A chave de um app parceiro segue a mesma regra.

Nenhum segredo no código

Um verificador automático barra qualquer senha ou chave antes de ela entrar no código do sistema. O certificado digital da Secretaria e as chaves de serviço ficam só no cofre do servidor.

O site se defende no navegador

O Brain Tower não pode ser aberto dentro de outro site (o golpe do clique falso), não manda o endereço completo da página para outros sites e não pede câmera, microfone nem localização.

LGPD: o município decide, a Brain opera

No contrato, o município é o controlador e a Brain é a operadora: o dado é tratado só para a finalidade contratada, com acesso por papel. Dado de paciente nunca é usado para treinar inteligência artificial.

As 65 provas que rodam a cada alteração

Cada vez que o sistema muda, um robô cria um banco de dados de verdade, coloca dois clientes fictícios lado a lado e tenta, de todos os jeitos abaixo, fazer um ver o que é do outro — e cada papel fazer o que não é dele. As frases são os nomes dos próprios testes.

A sessão não fica aberta · 4 provasFechou o navegador ou ficou 20 minutos parado, a equipe sai.

o cookie do login perde a validade (vira cookie de sessão); o de apagar continua apagando
com carimbo de uso, vale até 20 minutos depois dele; carimbo mexido não vale
sem carimbo, só vale o login que acabou de acontecer; login antigo (restaurado dias depois) não vale
vale nas telas da equipe; fica de fora o app do cidadão, a TV fixa, as entradas e as páginas públicas

Senha sozinha não abre · 13 provasQuem vê dado de paciente precisa do código do celular; sem ele, o banco não entrega nada.

no painel: com o segundo fator ativo, sessão só de senha não vê nada; com o código, vê
na central: sessão só de senha não abre a fila nem a trilha; com o código, abre
fator cadastrado mas não confirmado não conta; quem não ativou segue igual
a checagem antes de cada pedido da API recusa só de senha, e deixa passar o código, o visitante e o servidor
toda tabela com RLS do schema public tem a política das duas etapas (tabela nova também precisa)
obrigatória para quem vê paciente (035): sem o código cadastrado, a regulação não recebe nada — só a pergunta da tela
a gestão que administra uma central também é obrigada; a Secretaria que só vê números, não
central de demonstração (pacientes fictícios) fica de fora: a apresentação funciona sem celular
só quem administra a central zera, de alguém da equipe dela, nunca o próprio; fica na trilha
zerar o código só de quem está inteiramente sob a sua gestão; quem também é de outro cliente vai pelo suporte
o app do cidadão responde sem o código da equipe; o resto continua exigindo
com central no município, só quem é dela mexe no link da TV
a política das duas etapas confere uma vez por consulta

Ninguém de fora entra · 10 provasVisitante sem login, ou logado sem vínculo, não lê nem executa nada.

é barrado em todas as tabelas e views do schema public
não executa nenhuma função do schema public
não chama o RPC de carga nem o de vínculo (são do servidor)
não enxerga região, município, fato nem bundle
o contexto dele vem vazio
ninguém de fora lê as tabelas do schema agenda — nem logado, nem anon
anon não executa nenhuma função da central; a carga do catálogo é só do servidor
as funções internas do schema agenda não são chamáveis por ninguém de fora
quem não tem papel na central não vê fila, paciente nem agenda
a central vizinha não enxerga Jacarezinho — nem apontando o código

Um cliente não vê o outro · 4 provasO consórcio vizinho, na mesma instalação, não enxerga nada do seu — nem apontando o código.

vê só a própria região, nunca a do CISNORPI
não lê o município do CISNORPI nem apontando o código
não lê internação, dengue nem nascimento do CISNORPI
não se enfia como membro do tenant alheio

O histórico não se apaga · 12 provasQuem entrou, quem liberou quem, quem viu a ficha: o registro não se reescreve, nem pelo servidor.

registra sozinha quem ganhou acesso
não se altera nem se apaga — nem pelo servidor
o leitor não lê a trilha; a gestão lê
cada carga guarda a versão do painel; cada região vê só as suas
o histórico das cargas e as versões não se reescrevem nem se apagam — nem pelo servidor
anon não lê as versões; quem é de fora da região também não
quem abriu a ficha, quem pediu e quem marcou fica registrado — com o nome dos campos, nunca o valor
a trilha não se altera nem se apaga — nem pelo dono do banco
o leitor vê os números da central, nunca o paciente; a unidade não lê a trilha
a resposta não se reescreve nem se apaga — nem pelo dono do banco; só a marca de lida muda
a ajuda de custo: só com TFD autorizado com ajuda; o item certo para cada pessoa; pagar, recibo; paga não se apaga
a alta do especialista fica na lista da unidade até alguém conseguir falar com o paciente; o registro não se apaga

O que é do servidor fica no servidor · 12 provasRotinas, chaves de parceiros e links sem login: o navegador não alcança, e o banco guarda só a impressão digital das chaves.

só o servidor pergunta quem avisar — a função lê e-mail em auth.users
só o servidor pede os avisos pendentes (com o telefone inteiro) e registra o resultado
a marca pública sai só pelo servidor (chave secreta), sem o logo pesado e sem dado de pessoa
a tabela entra só pelo servidor, guarda o nome escrito à mão e não muda o que a central oferece
entram só pelo servidor, só de unidade conhecida e com CNS que confere; a tela mostra os do SUS
a porta é só do servidor; a gestão das chaves, de quem está logado
só quem administra a central cria e revoga chave; o banco guarda o começo e a impressão digital, nunca a chave
as portas: só o servidor pega os documentos e grava o resultado; a tela é de quem está logado
as portas: o lembrete e o link são do servidor; a lista de confirmação, de quem está logado
o lembrete: dois dias antes, só com consentimento, um por horário, com o link pessoal guardado só pela impressão digital
a página pública da cidade sai só pelo servidor, com as UBS da própria cidade e nenhum dado de pessoa
quem abre a tela do município fixa; fixar de novo troca o link; cancelar desliga; o banco guarda só a impressão digital

Cada um faz só o que é seu · 10 provasO leitor não muda nada; quem pede não marca; a unidade vê só os pedidos dela; o texto clínico fica com quem cuida.

vê os dois municípios da região e o bundle dela
o contexto diz o tenant, a região e o papel
ninguém escreve fato pela tela — nem o dono
o leitor não dá acesso a ninguém; o gestor dá
o registro de envios: a gestão vê o do consórcio, o leitor só o dele, o vizinho nada, a tela não escreve
o leitor do cliente e a gestão do vizinho não mexem na equipe de Jacarezinho
quem agenda abre o pedido; a outra unidade, não; abrir fica na trilha
o texto clínico fica com quem cuida: agendamento e acompanhamento veem só o desfecho, e a trilha não guarda o texto
liga o cadastro com documento, nascimento e código; vê só a própria agenda; confirma e avisa que não vai
"ainda precisa?": o pedido parado vira alerta; a unidade dele confirma por telefone; a outra unidade não

O que ainda não está no ar

O Brain Tower ainda não está publicado na nuvem. Quando estiver (centro de dados em São Paulo), a cópia de segurança diária do banco, com a prova de que ela restaura, passa a aparecer no status do sistema, ao lado da disponibilidade de cada parte.

uma solução Brain Algorithms · status do sistema ·