Quando credenciais roubadas abrem a porta para informações sensíveis, precisamos fazer duas perguntas: quem estamos deixando entrar e o que estamos permitindo que faça depois de entrar?
Tudo começou com algo que fazemos todos os dias. Confiar em alguém.
Imagine que você está no trabalho quando alguém entra em contato dizendo ser do departamento de TI da sua empresa.
A pessoa parece profissional. Sabe o suficiente sobre a organização para parecer legítima. Diz que há um problema com sua conta e que precisa da sua ajuda para resolvê-lo.
Você colabora.
Afinal, é alguém da TI. Certo?
Só que não é.
E o que parece uma interação comum pode se tornar o início de uma falha de segurança extraordinária.
Segundo uma reportagem de novembro de 2026 da DataBreachToday, um ataque cibernético contra a Marathon Health pode ter afetado quase 5,7 milhões de pessoas.
A sequência relatada é perturbadoramente simples. Um invasor se passou por um profissional de TI, obteve as credenciais de um funcionário e as utilizou para acessar um aplicativo hospedado na nuvem. Em seguida, informações foram exportadas.
Pense nisso.
Quase 5,7 milhões de pessoas potencialmente afetadas.
Não necessariamente porque alguém explorou uma vulnerabilidade de software até então desconhecida.
Não necessariamente porque o invasor derrotou todos os controles de segurança que protegiam a organização.
Mas porque um invasor conseguiu explorar a confiança, obter credenciais e acessar informações sensíveis.
E isso levanta uma pergunta que não fazemos com a frequência necessária.
Quando alguém apresenta credenciais válidas, estamos verificando a pessoa ou simplesmente confiando nas credenciais?
Uma credencial válida não torna alguém legítimo
Durante décadas, grande parte da segurança digital funcionou com base em uma suposição simples.
Se alguém fornece o nome de usuário e a senha corretos, deve ser a pessoa autorizada a usá-los.
As credenciais conferem. O sistema abre a porta.
Mas há uma falha óbvia nesse raciocínio.
E se as credenciais tiverem sido roubadas?
O sistema pode reconhecer a senha perfeitamente. O que ele não consegue necessariamente reconhecer é que quem a está digitando é um impostor.
Saber a senha de alguém não faz de você essa pessoa.
Mesmo assim, os invasores construíram toda uma indústria em torno da exploração dessa distinção.
Por que passar semanas tentando romper defesas sofisticadas de segurança se é possível convencer alguém a entregar as chaves?
Phishing, falsidade de identidade, roubo de credenciais e engenharia social funcionam porque pessoas e sistemas às vezes confundem familiaridade com legitimidade.
E, no incidente da Marathon Health, o uso relatado de credenciais comprometidas ilustra como um invasor pode explorar um processo legítimo de autenticação para obter acesso não autorizado.
As credenciais podiam ser válidas.
A pessoa que as utilizava não era.
Mas há outra parte dessa história que merece tanta atenção quanto essa.
Uma AUTH não basta. E um login bem-sucedido também não.
Segundo os relatos, o invasor não apenas entrou em um aplicativo hospedado na nuvem.
Informações foram exportadas.
São dois eventos diferentes, que deveriam suscitar duas perguntas de segurança diferentes.
A primeira é a autenticação.
Quem é você? Consegue provar que é quem afirma ser?
A segunda é a autorização.
Agora que uma identidade foi estabelecida, o que você realmente tem permissão para acessar ou fazer?
É uma distinção que parece técnica, mas o princípio é bastante simples.
Pense em entrar em um prédio de escritórios.
Seu crachá de funcionário pode permitir a passagem pela porta principal. Isso é autenticação.
Mas isso não significa que ele também deva abrir os escritórios da diretoria, o departamento de folha de pagamento, a sala de servidores e todos os arquivos trancados.
Essas permissões são uma questão de autorização.
E, mesmo que você tenha permissão para entrar no departamento de folha de pagamento, isso não significa necessariamente que deva poder sair carregando os registros confidenciais de todos os funcionários.
Passar pela porta principal nunca deveria significar ter acesso irrestrito a tudo lá dentro.
Agora aplique esse mesmo raciocínio ao incidente da Marathon Health.
Um invasor teria obtido credenciais legítimas de um funcionário e acessado um aplicativo.
A primeira decisão de segurança não conseguiu distinguir o invasor do funcionário autorizado.
Mas e a segunda?
Quais informações aquela conta tinha permissão para acessar? Quais restrições se aplicavam à exportação de dados? Ações especialmente sensíveis exigiam verificação adicional?
As informações públicas não permitem responder a todas essas perguntas.
Mas são exatamente as perguntas que as organizações deveriam fazer.
Porque autenticação e autorização não são a mesma coisa.
E uma autenticação bem-sucedida nunca deve ser interpretada como autorização ilimitada.
Autorização: a decisão de segurança que continua depois do login
É aqui que a distinção se torna especialmente importante.
Sistemas tradicionais de autorização frequentemente atribuem permissões com base na função do funcionário.
Um contador pode acessar registros financeiros.
Um profissional de saúde pode acessar determinadas informações de pacientes.
Um administrador pode ter privilégios mais amplos nos sistemas.
Isso faz sentido.
Mas considere o que acontece quando um invasor compromete uma conta que já possui direitos legítimos de acesso.
O invasor pode herdar essas mesmas permissões.
Se o funcionário pode exportar registros sensíveis, o invasor talvez também possa.
É por isso que a autorização não pode ser simplesmente uma lista estática de permissões estabelecida uma vez e depois esquecida.
Ela precisa ser capaz de avaliar o que alguém está tentando fazer, a sensibilidade das informações envolvidas e se a ação é adequada naquelas circunstâncias.
Por exemplo, um funcionário que normalmente consulta registros individuais pode, de repente, tentar baixar milhares deles.
Uma solicitação pode se originar de um dispositivo desconhecido.
Uma sessão pode apresentar comportamento incomum.
Ou alguém pode tentar uma operação tecnicamente permitida por sua função, mas incompatível com suas responsabilidades habituais.
Essas circunstâncias deveriam importar.
As organizações podem aplicar permissões de privilégio mínimo, restringir exportações em massa, avaliar os riscos de sessões e dispositivos e exigir verificação mais forte antes de operações especialmente sensíveis.
Em alguns casos, a resposta adequada é negar completamente a ação.
Há outra proteção importante que merece consideração. Para operações especialmente sensíveis, a autorização pode exigir uma nova verificação da presença do usuário legítimo por meio de um mecanismo de autenticação confiável e vinculado ao dispositivo. Isso pode incluir uma verificação biométrica realizada localmente no dispositivo do usuário, permitindo o uso de uma credencial criptográfica protegida sem expor a própria biometria ao aplicativo.
Pense no que isso significa para um invasor que roubou as credenciais de acesso de alguém. Mesmo que essas credenciais permitam o acesso inicial, talvez não sejam suficientes para autorizar a extração de informações sensíveis. Sem acesso ao dispositivo confiável do usuário legítimo e sem conseguir satisfazer seus requisitos de verificação, o invasor pode descobrir que a própria ação que pretendia executar foi negada. A primeira decisão de segurança pode ter sido comprometida, mas a segunda oferece uma oportunidade independente de interromper o ataque.
É claro que nenhum sistema de autorização pode garantir a detecção de toda ação maliciosa. Uma conta comprometida ainda pode ser usada para executar atividades que estejam dentro de suas permissões legítimas.
Mas isso não é um argumento contra a autorização.
É um argumento a favor de torná-la mais precisa, contextual e sensível ao risco.
A autenticação determina se uma identidade pode entrar. A autorização determina o que essa identidade pode fazer.
As duas decisões importam.
E nenhuma deve ser tratada como um exercício de confiança feito uma única vez.
Há outro problema. Quem está autenticando a outra parte?
Até agora, examinamos o que acontece quando um invasor apresenta credenciais roubadas e acessa um sistema.
Mas vamos voltar ao início do incidente da Marathon Health.
O invasor teria se passado por um profissional de TI.
Antes de as credenciais serem roubadas, alguém precisou acreditar que a pessoa que as solicitava era legítima.
Isso nos leva a uma questão maior.
Gastamos enormes quantidades de tempo e dinheiro pedindo aos usuários que comprovem sua identidade.
- Senhas.
- Códigos de verificação.
- Aplicativos autenticadores.
- Biometria.
- Perguntas de segurança.
Mas com que frequência fazemos a outra pergunta, igualmente importante?
O que a pessoa, o site ou o aplicativo que solicita nossas credenciais fez para comprovar sua própria identidade para nós?
Pense na última vez em que você acessou sua conta bancária.
Esperava-se que você comprovasse quem era.
Mas como você estabeleceu que estava realmente se comunicando com seu banco?
Verificou o destino de forma independente ou confiou no site porque ele parecia familiar?
Os invasores entendem esse desequilíbrio.
Criam páginas de login convincentes. Fazem-se passar por funcionários de confiança. Enviam mensagens que parecem vir de organizações legítimas.
Sabem que as pessoas estão condicionadas a responder quando alguém que afirma ter autoridade pede que se autentiquem.
E essa é a fraqueza fundamental da confiança unilateral.
Exigimos provas do usuário enquanto, com frequência excessiva, esperamos que ele presuma a legitimidade de quem as solicita.
Isso não é uma relação equilibrada de confiança.
E certamente não é o alicerce sobre o qual deveríamos construir o futuro da identidade digital.
A Confiança Mútua muda a conversa
A confiança deveria ser uma relação de mão dupla.
Entendemos isso instintivamente no mundo físico.
Se alguém bate à sua porta dizendo representar seu banco, você não o convida automaticamente para entrar só porque ele sabe seu nome.
Faz perguntas.
Pede identificação.
Talvez ligue para o banco usando um número que sabe, de forma independente, ser legítimo.
Verifica antes de confiar.
No mundo digital, porém, frequentemente nos pedem para fazer o contrário.
- Clique no link.
- Digite sua senha.
- Aprove a notificação.
- Forneça o código.
E presuma que a parte que solicita tudo isso é legítima.
Não precisa funcionar assim.
A Autenticação Mútua estabelece a legitimidade de ambas as partes envolvidas em uma troca de autenticação digital.
O usuário comprova sua identidade para o serviço.
O serviço comprova sua identidade para o usuário ou para o mecanismo de autenticação confiável do usuário.
Nenhum dos lados precisa depender apenas das aparências ou de uma alegação não verificada.
Métodos modernos de autenticação criptográfica podem ajudar a tornar isso possível sem exigir que os usuários se tornem especialistas em cibersegurança.
E, quando esses métodos são resistentes a phishing, podem dificultar significativamente a captura ou reutilização de credenciais de autenticação por invasores por meio de sites fraudulentos.
Mas a Autenticação Mútua não é uma solução universal contra a falsidade de identidade.
Uma conexão criptograficamente verificada com um aplicativo legítimo não comprova automaticamente que alguém que diz ser funcionário de TI ao telefone seja legítimo.
Essas interações exigem seus próprios procedimentos confiáveis de verificação.
O princípio, porém, continua o mesmo.
Ninguém deveria ser obrigado a entregar informações sensíveis ou conceder acesso simplesmente porque a outra parte afirma ser confiável.
A identidade precisa ser estabelecida.
E a confiança precisa ser conquistada pelos dois lados.
A MFA é importante. Mas mais autenticação não significa automaticamente mais confiança.
A autenticação multifator deu uma contribuição importante à cibersegurança.
Exigir um fator adicional além da senha pode reduzir substancialmente o risco de acesso não autorizado às contas.
Mas nem todos os métodos de MFA são igualmente resistentes a ataques.
Alguns códigos de verificação podem ser capturados por phishing.
Algumas solicitações de autenticação podem ser manipuladas por engenharia social.
Algumas informações de sessão podem ser roubadas após a autenticação.
E um evento de MFA bem-sucedido não significa necessariamente que cada ação posterior deva ser considerada confiável.
É por isso que acredito que precisamos deixar de pensar na autenticação como um conjunto de obstáculos que os usuários devem superar.
Adicionar mais etapas não é o mesmo que estabelecer mais confiança.
Uma abordagem mais forte combina autenticação resistente a phishing, verificação adequada do serviço, proteção de dispositivos e sessões e controles de autorização que reflitam a sensibilidade da ação solicitada.
O objetivo não é tornar cada login mais difícil.
O objetivo é tornar a falsidade de identidade mais difícil e dificultar a conclusão de ações não autorizadas.
São objetivos muito diferentes.
E levam a uma conversa muito mais produtiva sobre segurança.
A confiança não deveria terminar na tela de login
Esta é a lição mais ampla que tiro do incidente da Marathon Health.
Segurança não é uma decisão única tomada quando alguém digita um nome de usuário e uma senha.
É uma série de decisões ao longo de uma interação digital.
- Quem está solicitando acesso?
- Essa identidade é legítima?
- O próprio serviço é legítimo?
- Quais informações estão sendo solicitadas?
- A ação solicitada está autorizada?
- O contexto justifica uma análise adicional?
Essas perguntas não deveriam desaparecer simplesmente porque um login foi bem-sucedido.
Considere como poderia ser uma segurança mais forte.
- Um usuário se autentica por um método resistente a phishing que não expõe credenciais reutilizáveis.
- O processo de autenticação verifica se o usuário está se comunicando com o serviço legítimo.
- A organização concede apenas as permissões necessárias às responsabilidades do usuário.
- Quando informações especialmente sensíveis são solicitadas, os controles de autorização avaliam se aquela ação é adequada.
- E, quando as circunstâncias indicam risco incomum, o sistema pode exigir verificação adicional, restringir o acesso ou negar a operação.
Nada disso garante que todos os ataques serão impedidos.
Mas reduz o número de suposições das quais um invasor pode depender.
E, talvez o mais importante, muda a forma como pensamos sobre confiança.
A confiança não é um privilégio permanente concedido no login. É uma relação que precisa ser estabelecida, protegida e reavaliada quando as circunstâncias justificarem.
Essa é uma base muito mais sólida para a segurança digital.
Por trás de 5,7 milhões de registros estão 5,7 milhões de pessoas
É fácil ficar insensível às manchetes sobre cibersegurança.
Mais um vazamento.
Mais uma conta comprometida.
Mais uma organização investigando acesso não autorizado.
Mais um número medido em milhões.
Mas, por trás do incidente relatado da Marathon Health, estão quase 5,7 milhões de pessoas cujas informações pessoais podem ter sido afetadas.
Pessoas que confiaram informações sensíveis a uma organização com a expectativa razoável de que seriam protegidas.
Pessoas que talvez agora precisem monitorar suas contas, ficar atentas a comunicações suspeitas ou se preocupar com o uso indevido de suas informações.
A maioria não teve nada a ver com a interação que, segundo os relatos, permitiu o acesso do invasor.
Não responderam ao impostor.
Não divulgaram as credenciais.
Não autorizaram a exportação.
Mesmo assim, podem enfrentar as consequências.
É por isso que acredito que essa conversa vai além da tecnologia de autenticação.
É uma questão de responsabilidade.
Quando as organizações coletam e mantêm informações sensíveis, assumem a obrigação de protegê-las.
E cumprir essa obrigação exige mais do que verificar se alguém tem a senha certa.
Exige decisões criteriosas sobre identidade, acesso, autorização e a legitimidade das partes envolvidas.
Confiança não é apenas um recurso de cibersegurança. É uma responsabilidade que temos com as pessoas cujas informações guardamos.
Duas AUTHs. Um princípio fundamental.
O incidente da Marathon Health ilustra por que precisamos questionar algumas suposições antigas sobre segurança digital.
Uma credencial válida não significa necessariamente que quem a apresenta seja legítimo.
Um login bem-sucedido não significa necessariamente que cada ação posterior deva ser permitida.
E uma solicitação de autenticação não significa automaticamente que a pessoa ou o serviço que a faz seja confiável.
São três problemas diferentes, mas compartilham um mesmo fio condutor.
A confiança não pode se basear apenas em posse, aparências ou suposições.
A autenticação precisa estabelecer a identidade.
A autorização precisa determinar o que essa identidade pode fazer.
A Autenticação Mútua precisa ajudar a garantir que ambas as partes da troca de autenticação sejam legítimas.
E controles adequados precisam continuar protegendo as informações sensíveis depois do login inicial.
Não podemos afirmar com certeza que qualquer uma dessas medidas teria impedido o incidente da Marathon Health. Os fatos relatados publicamente não sustentam essa conclusão.
Mas podemos dizer que o incidente levanta questões importantes sobre como as organizações estabelecem e fazem valer a confiança.
E essas questões merecem respostas sérias.
Por tempo demais, concentramos nossos esforços em melhorar a maneira de pedir às pessoas que comprovem quem são.
Agora precisamos tratar com a mesma seriedade a verificação de quem está pedindo, qual acesso é justificado e quais ações devem ser permitidas.
Porque uma credencial pode abrir uma porta.
Mas não pode, por si só, nos dizer quem está passando por ela.
E, mesmo quando alguém entrou legitimamente no prédio, isso não significa que deva ter as chaves de todas as salas.
Uma AUTH não basta™.
E a confiança unilateral também não.
A confiança começa aqui™.