06 Out 2026
Zero Trust em saúde: por que acesso clínico remoto não cabe mais em perímetro de rede
Hospital conectado tem especialista acessando prontuário de casa, dispositivo médico na rede e fornecedor fazendo manutenção remota — nenhum desses cenários sobrevive à lógica de "dentro da rede é confiável".
Poucos ambientes concentram tanta heterogeneidade de acesso quanto um hospital conectado hoje: médico especialista acessando prontuário de casa por telemedicina, equipamento médico antigo plugado na mesma rede que sistemas administrativos, fabricante de dispositivo fazendo manutenção remota, profissional de plantão usando dispositivo pessoal numa emergência. Nenhum desses cenários sobrevive à lógica de que "dentro da rede do hospital é confiável, fora não é".
Zero Trust parte exatamente desse reconhecimento: a confiança não deveria vir de onde o acesso está acontecendo, e sim de uma verificação contínua de quem está pedindo acesso, de qual dispositivo, e para qual dado — repetida a cada solicitação, não concedida uma vez no login e mantida pelo resto da sessão.
Por que saúde quebra o modelo de perímetro antes de qualquer outro setor
A maioria dos setores já convive com alguma mistura de dispositivo remoto e acesso de terceiro. Saúde leva isso a um extremo: equipamento médico que roda sistema operacional sem atualização há anos, especialista externo que só precisa de acesso pontual a um caso específico, e emergência que não pode esperar um processo de autenticação lento — tudo isso coexistindo na mesma infraestrutura, com dado clínico sensível no centro.
Tratar essa rede como um espaço único de confiança, onde qualquer coisa conectada internamente é automaticamente segura, ignora que boa parte do risco real já está dentro dela — só esperando lateralidade de acesso para ser explorado.
Verificação contínua em vez de confiança única no login
O princípio central de Zero Trust é simples de enunciar e exigente de implementar: nenhum acesso é confiável por padrão, mesmo vindo de dentro da rede corporativa — cada solicitação é avaliada por identidade, postura do dispositivo e contexto da situação, com autenticação adaptativa ajustando o nível de verificação conforme o risco real.
Isso já aparece de forma concreta em ambientes clínicos que equilibram proteção de dado sensível com velocidade de atendimento — mas Zero Trust estende esse princípio além do controle de acesso ao prontuário, cobrindo toda solicitação de rede, não só a camada de aplicação.
Dispositivo médico não roda agente de segurança — e tudo bem, se a rede for desenhada pra isso
Boa parte do equipamento médico conectado simplesmente não suporta agente de segurança tradicional, seja por limitação técnica, seja por restrição regulatória do próprio fabricante sobre alterar o sistema do equipamento. Isso costuma ser tratado como motivo pra desistir de proteger esses ativos — é na verdade o motivo pra desenhar a rede em microssegmentos isolados, onde um dispositivo comprometido fica contido, sem caminho lateral livre até sistema crítico ou dado sensível.
O controle, nesse caso, não vem do dispositivo — vem da arquitetura de rede ao redor dele, que assume por padrão que qualquer equipamento pode ser comprometido e limita o raio de ação antes que isso aconteça.
Fornecedor remoto também é identidade a verificar, não exceção
É comum que fabricante de equipamento médico ou prestador de manutenção remota receba uma credencial de acesso permanente, criada uma vez e nunca revisada depois. Sob Zero Trust, esse tipo de acesso segue a mesma régua de qualquer identidade privilegiada: concedido sob demanda, com escopo limitado à tarefa específica, com tempo de expiração definido e sessão registrada — não uma porta aberta que fica esquecida até alguém perguntar por que ainda existe.
Rede confiável é suposição, não arquitetura
Nenhum hospital decide, conscientemente, confiar cegamente em tudo que está conectado à própria rede — isso acontece por ausência de arquitetura, não por escolha. A UNIQ ajuda instituições de saúde a desenhar essa transição para Zero Trust de forma gradual, começando pelos pontos de maior risco real. Fale com o time técnico antes que a suposição de rede confiável seja testada por um incidente real.