O incidente que expõe a fragilidade do ambiente digital
Quando a notícia de que Radia Perlman — a cientista da computação que contribuiu decisivamente para a criação do protocolo Spanning Tree e para a própria infraestrutura da internet moderna — caiu em um golpe online, a reação imediata de muitos foi de incredulidade. Se alguém que ajudou a construir as bases da rede mundial de computadores pode ser enganado, o que isso diz sobre o resto de nós? A resposta é desconfortável: diz que a segurança digital nunca foi apenas sobre tecnologia, e que o elo mais fraco continua sendo o comportamento humano, independentemente do QI ou do currículo da vítima.
O golpe relatado pelo portal Globo — em que Perlman tentava renovar a carteira de habilitação online e foi direcionada a um site falso — é um caso clássico de engenharia social combinada com falha de UX. A cientista não cometeu um erro técnico primário. Ela confiou em um fluxo de navegação que parecia legítimo, exatamente como qualquer usuário faria. A diferença é que, neste caso, a vítima tem um dos currículos mais impressionantes da computação mundial, o que torna o episódio um estudo de caso obrigatório para profissionais de segurança, produto e experiência do usuário.
Vamos analisar o que aconteceu sob a ótica de quem constrói sistemas, não apenas de quem os usa. Afinal, o golpe contra Radia Perlman não é sobre ela. É sobre nós, engenheiros, designers, gerentes de produto e tomadores de decisão responsáveis por projetar os ecossistemas digitais que deveriam proteger todos os cidadãos.
O mecanismo do golpe: para além do phishing tradicional
O que torna esse caso particularmente revelador não é a técnica usada pelos golpistas, que é relativamente comum: criar uma réplica convincente do site oficial de um órgão público e capturar os dados inseridos pela vítima. O que surpreende é a eficácia do ataque contra uma profissional que, por décadas, trabalhou com padrões de rede, segurança e protocolos. Isso sugere que o problema não está na capacidade de discernimento da vítima, mas na arquitetura de confiança do sistema.
No modelo atual de interação com serviços públicos digitais, o cidadão precisa navegar por uma cadeia de links, redirecionamentos e domínios que, na prática, são indistinguíveis do original para um olhar desatento. A engenharia social explorada aqui é sofisticada porque não depende de um erro grosseiro, como clicar em um link de e-mail suspeito. Depende da fadiga de decisão do usuário e da complexidade burocrática dos processos governamentais.
Se você já renovou a CNH ou qualquer outro documento online, sabe que o processo envolve múltiplas telas, uploads de documentos, pagamentos via boleto ou cartão, e confirmações por e-mail ou SMS. Cada um desses pontos de interação é uma superfície de ataque. O que falta, na maioria das implementações, é um mecanismo de verificação contínua da identidade do serviço, não apenas da identidade do usuário.
A falha de UX que transformou conhecimento em vulnerabilidade
Há um viés interessante aqui: pessoas com alto conhecimento técnico tendem a confiar mais em sistemas digitais porque entendem como eles "deveriam" funcionar. Radia Perlman sabe o que é um certificado SSL, sabe o que é DNS, sabe como funcionam os handshakes de rede. Mas esse conhecimento não a protegeu porque o golpe não explorou uma vulnerabilidade técnica — explorou uma vulnerabilidade de processo.
O site falso provavelmente usava um domínio similar ao oficial, talvez com algum caractere visualmente idêntico (como o "o" substituído por um "0", ou um "rn" que parece "m"). A página replicava o layout legítimo, os logotipos e o fluxo de interação. O navegador, por sua vez, mostrou o cadeado de conexão segura (HTTPS) — afinal, o site falso também podia ter um certificado válido emitido para domínio enganoso. Para a maioria dos sistemas de defesa atuais, a transação era perfeitamente válida.
O ponto crítico é que a validação da identidade do destinatário — o site do Detran ou similar — não é feita de forma proativa pelo navegador ou pelo sistema operacional. O usuário é quem precisa decidir se "www.detran-sp.gov.br-login.com" é ou não legítimo. Isso é um design de segurança falido, porque transfere para o usuário final uma responsabilidade que ele não tem condições técnicas de cumprir consistentemente.
A dimensão psicológica: por que ninguém está imune
Outro aspecto que merece aprofundamento é o contexto da vítima. Perlman não estava "em serviço" quando caiu no golpe. Ela estava resolvendo uma burocracia cotidiana, provavelmente com pressa, talvez cansada. Engenharia social funciona melhor quando o alvo está distraído ou sob estresse. A combinação de urgência (renovação da habilitação perto do vencimento) com a banalidade percebida da tarefa (só mais um formulário online) reduz drasticamente o nível de alerta.
Para profissionais de segurança, a lição é que treinamento e conscientização têm limites. Por melhor que seja o programa de segurança da informação de uma empresa, haverá momentos em que até o CTO cairá em um golpe bem construído, especialmente fora do ambiente de trabalho, onde os mecanismos de proteção corporativos (filtros de URL, proxies, autenticação multifator centralizada) não existem.
Isso não é um argumento contra educação em segurança — é um argumento a favor de projetar sistemas que sejam seguros por padrão, mesmo quando o usuário comete erros. O conceito de "defense in depth" precisa ser aplicado também à experiência do usuário, não apenas à infraestrutura de rede.
O que o mercado de IA e automação pode aprender com o caso
Como especialista em transformação digital e automação, vejo nesse episódio um alerta direto para quem está desenhando soluções baseadas em inteligência artificial para processos governamentais e corporativos. A automação de workflows, quando mal projetada, pode amplificar o dano causado por um golpe bem-sucedido.
Imagine se o site falso, além de capturar os dados pessoais de Perlman, tivesse integrado com sistemas de automação para gerar documentos falsos ou iniciar transações financeiras automaticamente. Esse é o cenário que estamos construindo: automação sem verificação adequada de identidade e procedência. A IA pode ser usada tanto para detectar padrões de fraude quanto para criá-los em escala industrial.
As empresas que oferecem soluções de verificação de identidade digital (como reconhecimento facial, análise de documentos, biometria comportamental) precisam integrar esses mecanismos não apenas na ponta do usuário, mas também na validação do prestador de serviço. O equivalente a um "certificado digital reverso" — onde o site precisa provar sua identidade para o usuário de forma ativa, não apenas passiva via cadeado no navegador.
Um paralelo com o mundo corporativo
No ambiente empresarial, casos como o de Perlman acontecem todos os dias com executivos e funcionários de TI. Golpes de "falso fornecedor" ou "falso CEO" que solicitam pagamentos urgentes por meio de e-mails que imitam perfeitamente a comunicação interna. A diferença é que, no âmbito corporativo, há mais camadas de proteção (como aprovação dupla de pagamentos, confirmação por canais alternativos, sistemas de antifraude).
Para o cidadão comum, essas camadas não existem. E o Estado, que deveria ser o provedor de confiança, muitas vezes terceiriza a segurança para o próprio usuário, com portais que não seguem boas práticas mínimas de UX security. O resultado é uma população vulnerável, inclusive seus membros mais qualificados tecnicamente.
Profissionais de produto que atuam em plataformas de serviços públicos digitais deveriam realizar testes de penetração focados em engenharia social, não apenas em vulnerabilidades de código. Deveriam auditar a jornada completa do usuário como se o próprio time de desenvolvimento fosse o alvo dos golpistas. Porque, no fim das contas, somos todos alvos potenciais.
O que fazer: recomendações práticas para projetistas de sistemas
Com base na análise desse caso e na minha experiência em transformação digital, listo algumas ações concretas que podem mitigar riscos similares — tanto para engenheiros de software quanto para gestores de produto e tomadores de decisão em órgãos públicos:
- Implementar verificação bidirecional de identidade: o site deve provar sua autenticidade ao usuário por meio de canais secundários (como um código enviado por SMS ou pelo aplicativo oficial sempre que o acesso for feito por um link externo). Isso quebra a dependência exclusiva do julgamento visual do usuário.
- Usar domínios curtos e memoráveis para serviços públicos: URLs longas e cheias de subdomínios são um convite ao phishing. Órgãos públicos deveriam consolidar seus serviços em um número mínimo de domínios oficiais, de fácil verificação, e desativar variações obsoletas ou suspeitas proativamente.
- Automação assistida com verificação redundante: para transações sensíveis como renovação de documentos, a automação do fluxo deve incluir pontos de parada obrigatórios para verificação manual ou automatizada cruzada. Exemplo: validar o CNPJ do site de pagamento contra uma base oficial antes de autorizar a transação.
- Design de UX que reduza a carga cognitiva do usuário: em vez de mostrar um cadeado genérico, o navegador ou o sistema operacional poderia exibir um resumo legível da identidade do site ("Você está no site oficial do Detran SP, verificado em DD/MM/AAAA"). Isso já existe em certificados EV (Extended Validation), mas é subutilizado.
- IA para detecção de anomalias contextuais: sistemas de inteligência artificial podem ser treinados para identificar comportamentos atípicos na jornada do usuário — como acessar o site de renovação por um domínio nunca antes utilizado por aquele IP, ou downloads de scripts suspeitos durante a navegação. Isso seria um complemento à segurança tradicional.
Reflexão editorial: o custo da confiança mal projetada
A história de Radia Perlman cair em um golpe não é uma piada nem uma ironia do destino. É um sintoma de uma indústria de tecnologia que, por décadas, tratou a experiência do usuário como algo separado da segurança. Construímos sistemas incrivelmente complexos nos bastidores e interfaces absurdamente simplificadas na frente, mas falhamos em criar uma camada intermediária de verificação contextual que proteja o usuário mesmo quando ele está distraído.
Para o profissional de engenharia e produto que lê este artigo, a pergunta que fica é: quais pontos cegos existem no sistema que você está construindo hoje? Não assuma que seus usuários são experts em segurança. Projete para o cenário em que o usuário está cansado, com pressa, e que pode ser enganado por um site que se parece com o seu. O teste real de um sistema seguro não é "o que acontece quando tudo funciona", mas "o que acontece quando alguém tenta quebrar a confiança". Se a resposta depender exclusivamente da vigilância do usuário, o sistema já está quebrado por design.