Passkeys: Elas estão prontas para uso corporativo?

Este blog foi publicado pela primeira vez em 2024 e foi atualizado. 

As chaves de acesso estão se tornando cada vez mais comuns graças a serviços voltados ao consumidor, como Google, Apple, Facebook, Meta e outros. O uso de chaves de acesso aumenta significativamente a segurança em comparação com os logins tradicionais baseados em senha ou com a autenticação multifatorial (MFA) sem senha.

É normal que algumas soluções para o consumidor sejam transferidas para o uso profissional - pense em poder enviar reações de emojis para e-mails. Mas só porque o Instagram me permite fazer login usando uma chave de acesso, isso significa que as empresas deveriam fazê-lo?

Resumindo: as chaves de acesso estão prontas para uso empresarial?

O Aliança FIDO foi fundada em 2013 por várias empresas para desenvolver um padrão de autenticação que serviria como um segundo fator; atualmente, o FIDO pode servir como um método de autenticação forte sem senha.

Desde 2013, o FIDO tornou-se um dos métodos de login sem senha mais populares, em grande parte porque faz jus à sigla que compõe seu nome: ele proporciona uma identificação rápida online. A Aliança FIDO tem um forte foco no ambiente de consumo. Não é de se admirar que seus maiores membros atuem nessa área: Apple, Google, PayPal e Microsoft. A RSA é membro da FIDO Alliance e copreside seu Grupo de Trabalho sobre Implantação Corporativa.

As credenciais FIDO usam pares de chaves assimétricas para autenticar em um serviço. Quando uma credencial FIDO é registrada em um serviço, um novo par de chaves é gerado no autenticador FIDO e o serviço passa a confiar nesse par de chaves - e somente nesse par de chaves. O par de chaves é conectado ao nome de domínio exato do serviço.

Essa associação rígida entre um serviço e uma credencial FIDO é o que proporciona um alto grau de resistência ao phishing: se um usuário tentasse fazer login em um site falso de phishing com a senha criada para o site verdadeiro, a tentativa falharia porque o nome do domínio não corresponderia à credencial.

Em 2022, a Apple, o Google e a Microsoft lançaram o suporte para um novo tipo de credencial FIDO, que eles chamaram de chave de acesso. Em 2023, a FIDO Alliance adotou o termo "chave de acesso" para qualquer tipo de credencial FIDO, levando a uma possível confusão sobre o que exatamente uma organização quer dizer quando menciona "passkeys".

Essa possível ambiguidade foi abordada pela FIDO Alliance (veja abaixo), mas ainda pode existir nas organizações. É importante abordar essa ambiguidade, pois nem todas as chaves de acesso são iguais ou apropriadas para uso corporativo.

Tipos de chaves de acesso

Agora existem dois tipos de chaves de acesso, conforme definido pela FIDO Alliance: vinculadas a dispositivos e sincronizadas.

Chaves de acesso vinculadas ao dispositivo vs. chaves de acesso sincronizadas

As chaves de acesso vinculadas a dispositivos são geralmente armazenadas em dispositivos específicos chamados “chaves de segurança”. Esse tipo de chave de acesso é geralmente considerado mais seguro, pois a chave privada nunca sai do dispositivo, o que a torna resistente à extração ou ao comprometimento remoto.

No entanto, isso também significa que, caso o dispositivo seja perdido ou danificado, o usuário precisaria registrar uma nova chave de acesso em um novo dispositivo. As chaves de acesso vinculadas ao dispositivo são particularmente preferidas em ambientes de alta segurança e em casos de uso corporativo, muitas vezes utilizando hardware como chaves de segurança ou Módulos de Plataforma Confiável (TPMs).

As chaves de acesso vinculadas a dispositivos também são agora compatíveis com determinados aplicativos móveis, como o aplicativo RSA Authenticator para iOS e Android.

Chaves de acesso sincronizadas

Com as chaves de acesso sincronizadas, o material da chave é salvo por meio do chamado “remote sync fabric”, e pode então ser restaurado em qualquer outro dispositivo de propriedade do mesmo usuário. As principais estruturas de sincronização atuais são Microsoft, Google e Apple. Isso significa que, se você registrar seu celular Android como uma chave de acesso, o material de chave correspondente será armazenado pelo Google e, portanto, estará disponível em todos os seus outros dispositivos Android logo em seguida.

As senhas sincronizadas são - além de terem o suporte de serviços amplamente usados, como o WhatsApp ou o Facebook - o principal motivo do aumento acentuado do uso geral de senhas. É fácil entender o motivo: um usuário com muitas contas e muitos dispositivos pode usar a mesma senha sincronizada em todos eles.

As chaves de acesso substituem as senhas tradicionais por pares de chaves criptográficas, proporcionando uma autenticação robusta e resistente a tentativas de phishing. Quando um usuário se cadastra em um serviço, seu dispositivo gera um par exclusivo de chaves privada e pública. A chave privada permanece armazenada com segurança no dispositivo do usuário, enquanto a chave pública é compartilhada com o serviço. Durante a autenticação, o dispositivo comprova a posse da chave privada assinando um desafio enviado pelo serviço, e a assinatura é verificada por meio da chave pública armazenada. Nenhum segredo compartilhado é transmitido, e nenhuma senha é criada ou armazenada, reduzindo drasticamente o risco de roubo de credenciais ou ataques de repetição.

As senhas tradicionais se baseiam em segredos compartilhados que podem ser adivinhados, roubados ou fraudados, o que as torna um ponto de entrada comum para os invasores. Elas geralmente são reutilizadas em várias contas, armazenadas de forma insegura e vulneráveis a ataques de força bruta ou de preenchimento de credenciais.

As chaves de acesso eliminam esses riscos ao substituir as senhas pela criptografia de chave pública-privada. A autenticação ocorre ao comprovar a posse dessa chave — sem transmiti-la. Essa abordagem torna obsoletos os vetores de ataque mais comuns, incluindo phishing, roubo de credenciais e reutilização de senhas. Para as organizações, as chaves de acesso representam um grande avanço na autenticação segura, ao mesmo tempo em que reduzem a carga de redefinições de senha e solicitações de suporte.

• Resistente a phishing: As chaves de acesso são projetadas para evitar ataques tradicionais de phishing. Como não há nenhuma senha envolvida, não há nada para roubar ou reutilizar.
• Rápido e conveniente: Fazer login com uma chave de acesso geralmente é tão simples quanto usar a biometria (como o Face ID ou uma impressão digital), tornando a experiência mais fácil para os usuários.
• Experiência de usuário familiar: Os logins Passkey se assemelham aos padrões comuns de autenticação móvel, portanto, há pouca ou nenhuma curva de aprendizado.
• Segurança de correspondência de domínios: As chaves de acesso oferecem uma camada extra de proteção, garantindo que o material da chave funcione apenas com o domínio de serviço original - um benefício que nem todos os métodos de MFA oferecem.
• Aprovado pelo governo: Nos EUA, a resistência ao phishing é um dos principais motivadores das exigências federais. Ordem Executiva 14028 requer autenticação sem senha e resistente a phishing para proteger a infraestrutura crítica.

Embora as chaves de acesso ofereçam vantagens significativas, elas também apresentam alguns desafios e problemas significativos.

• Experiência do usuário: As solicitações relacionadas à chave de segurança — como, por exemplo, pedidos para inserir a chave de segurança na porta USB ou digitar o PIN — apresentam aparências diferentes dependendo do sistema operacional e do navegador. Essas solicitações provavelmente tornarão mais difícil treinar os usuários e aumentarão o número de chamadas para o suporte técnico.
• Distração causada por outros ataques: Quem pensa que o uso de passkeys de repente o torna imune a formas de contornar a autenticação multifatorial (MFA), como ataques de engenharia social, está redondamente enganado. As chaves de acesso ajudam a combater um tipo específico de ataque de engenharia social: o phishing. Infelizmente, existem outras variantes. Os ataques à MGM Resorts e ao Caesars Palace, em Las Vegas, tiveram um componente de engenharia social: a exploração do suporte técnico para permitir que o invasor registrasse ele mesmo um autenticador de MFA.
• Desafios relacionados à perda ou atualização de dispositivos: Se os usuários perderem o acesso a um dispositivo compatível com chaves de acesso vinculadas ao dispositivo, elas não poderão ser recuperadas.
• Suporte limitado em todos os serviços: Embora a adoção esteja crescendo, nem todos os sites ou sistemas corporativos oferecem suporte a passkeys ainda, o que pode limitar sua usabilidade no dia a dia.
• Confusão do usuário ou falta de conhecimento: O conceito de chaves de acesso ainda é novo para muitos usuários, o que pode causar confusão sobre a configuração, a sincronização ou o que está acontecendo nos bastidores. As variações na terminologia (chaves de acesso, chaves de segurança, chaves FIDO) e a evolução dos padrões no setor podem aumentar essa confusão e tornar difícil para usuários e organizações compreenderem claramente as melhores práticas e implementarem e adotarem as chaves de acesso de maneira consistente. Isso também pode levar a erros durante a configuração e o uso, aumento no número de chamadas de suporte e possíveis falhas de segurança.
• Preparação da infraestrutura: A implantação de chaves de acesso pode exigir que as organizações realizem atualizações nas plataformas de identidade, nas políticas de gerenciamento de dispositivos e nas iniciativas de treinamento — especialmente ao abandonarem a autenticação legada. As organizações podem constatar que recursos legados ou locais podem não ser compatíveis com as chaves de acesso devido à autenticação exclusivamente pela web. Nesses casos, as organizações devem modernizar sua autenticação multifatorial (MFA) com sem senha recursos capazes de abranger diversos ambientes e dar suporte à infraestrutura legada.

Considerando os desafios que os passkeys atuais apresentam quando se trata de fornecer fluxos de trabalho uniformes em vários navegadores, dispositivos e sistemas operacionais, o que o setor pode fazer para garantir uma experiência verdadeiramente perfeita e entre plataformas? Como podemos determinar o melhor caminho para resolver as inconsistências que podem confundir os usuários e impedir a adoção generalizada?

Na RSA, nossa liderança em UX está ativamente envolvida nos grupos de trabalho da FIDO Alliance para defender experiências de usuário consistentes. Ao contribuir com nossos insights, pretendemos ajudar a moldar padrões que resultem em menos distrações, menos atrito e mais uniformidade para os usuários finais.

A mobilidade é outro aspecto da criação de uma experiência de chave de acesso perfeita em todos os ambientes. Os usuários da força de trabalho esperam cada vez mais a conveniência de fluxos de trabalho que priorizam a mobilidade. Se o acesso aos recursos corporativos em um smartphone parecer tão intuitivo quanto o desbloqueio desse mesmo dispositivo, a adoção de novos métodos de autenticação, como as senhas, será significativamente mais fácil. Uma experiência móvel sem atritos ajuda a quebrar a resistência do usuário, minimizando a curva de aprendizado e tornando a transição das senhas muito mais suave. Ao fornecer uma interface que seja familiar, transparente em relação às permissões e consistente, independentemente do dispositivo ou da plataforma do usuário, as organizações podem reduzir a confusão e aumentar a confiança. A solução FIDO móvel da RSA serve como exemplo de como implementar uma chave de acesso de maneira independente do dispositivo.

Para instalações seguras e ambientes de alta segurança onde a autenticação móvel não é permitida, o Série RSA iShield Key 2 fornece um autenticador de hardware certificado FIPS 140-3 Nível 3, FIDO2, que oferece segurança sem senha, resistente a phishing e multiplataforma.

Dizem que quando se tem um martelo, tudo pode parecer um prego. Transformar uma solução - mesmo que seja uma ótima solução - que foi originalmente planejada para uso do consumidor em um aplicativo corporativo pode introduzir riscos significativos.

Ao ler este artigo, você pode ter tido uma sensação de desconforto ao ouvir a menção de "tecido sincronizado". Sua intuição estava certa.

O fato de as chaves de acesso sincronizadas aparecerem como por magia em todos os dispositivos nos quais o usuário está conectado via Apple ou Google é um grande sinal de alerta no ambiente corporativo e deve suscitar algumas questões importantes:

• Os usuários devem ter permissão para usar vários dispositivos (possivelmente também usados de forma privada) para autenticação? Se sim... quantos?
• As chaves de acesso sincronizadas possibilitam a restauração de uma chave de acesso "perdida" com os processos de recuperação de conta do Google ou da Apple, por exemplo. Isso é ótimo... mas esses processos são seguros o suficiente para você?
• O recurso da Apple que permite que os usuários compartilhem chaves de acesso com amigos ou familiares é muito bom... mas será que isso também se aplica às chaves de acesso usadas para fazer login em aplicativos corporativos?

Ao usar senhas sincronizadas, a segurança de sua empresa passa a depender em grande parte da segurança técnica e organizacional da Apple e do Google. Claro, há uma certa dependência de qualquer forma devido ao uso de iOS e Android-mas as chaves de acesso sincronizadas aumentam consideravelmente essa dependência.

Essa também não é uma vulnerabilidade teórica. Retool discutiu como os agentes de ameaças a usaram para obter acesso a seus sistemas, observando que a funcionalidade significa que “se sua conta do Google estiver comprometida, seus códigos MFA também estarão”.”

Não é possível responder de maneira geral se as chaves de acesso devem ser usadas na empresa. Cada organização é diferente e deve equilibrar suas prioridades operacionais e de segurança exclusivas.

Além disso, o uso de senhas não deve ser uma questão de sim ou não. A introdução de chaves de acesso ou logins sem senha em geral deve ser usada para revisar fundamentalmente todos os processos de MFA de uma organização. O que foi bom para os tokens OTP de hardware por 15 anos provavelmente não é mais totalmente verdadeiro para as chaves de acesso ou outros métodos de MFA atualmente.

A RSA acredita que as chaves de acesso podem ser implementadas para uso corporativo se estiverem alinhadas à estratégia organizacional e se as organizações refletirem cuidadosamente sobre suas respostas às seguintes perguntas. Temos visto organizações utilizarem as chaves de acesso com sucesso em RSA^® ID Plus, nossa abrangente plataforma de gerenciamento de identidade e acesso (IAM), que oferece uma variedade de opções sem senha.

Como somos uma organização que prioriza a segurança e usamos os princípios Secure by Design / Secure by Default, evitamos o uso de senhas sincronizadas por padrão. Somente as senhas vinculadas a dispositivos estão disponíveis por padrão nos ambientes RSA para fornecer o nível máximo de segurança pronta para uso e sem nenhum trabalho extra por parte dos administradores.

Ao avaliar a introdução de passkeys, as organizações devem perguntar: Como nossos autenticadores são registrados? Existem processos que lidam com segurança com o cenário "Perdi meu autenticador"? E quanto à classificação de usuários, aplicativos e dados?

As chaves de acesso são um Método MFA entre muitos outros. Sim, a resistência deles ao phishing é fantástica, mas será que os usuários conseguem fazer login com ele em todos os recursos protegidos aos quais precisam acessar?.

Por esses e muitos outros motivos, é importante que seu sistema MFA não seja apenas tecnicamente atualizado, mas que também ofereça suporte a uma ampla variedade de métodos MFA, como códigos QR, biometria, OTP, mensagens push e chaves de acesso.

Também é importante que os processos relacionados à MFA sejam adaptados às novas ameaças. Isso vai muito além do sistema MFA real: seu help desk também está protegido contra ataques de engenharia social?

Se as chaves de acesso fazem sentido para você, queremos ajudar. Entre em contato conosco para saber mais ou iniciar um teste gratuito de 45 dias do ID Plus.

Decidir implementar as chaves de acesso é a parte fácil. Este guia aborda as três fases de uma implantação bem-sucedida — avaliação, projeto-piloto e implantação corporativa — com exemplos reais de organizações que já passaram por esse processo. Para uma visão geral completa dos recursos sem senha da RSA, acesse o Página de soluções sem senha da RSA.

Fase 1: Avaliação e planejamento (quatro a oito semanas)

1. Realize uma auditoria de autenticação. Identifique todos os aplicativos, infraestruturas e sistemas que exigem ou estão envolvidos no processo de autenticação, observando quais ainda não oferecem suporte ao FIDO2.
2. Identifique grupos de usuários de alto risco. Administradores com privilégios, funcionários da área financeira, trabalhadores remotos e usuários de dispositivos compartilhados exigem abordagens diferentes — segmente sua força de trabalho por nível de risco antes de planejar a implantação.
3. Defina sua política de chaves de acesso. Decida quais grupos de usuários devem usar chaves de acesso vinculadas ao dispositivo, chaves de acesso sincronizadas ou uma combinação das duas. A RSA recomenda as chaves vinculadas ao dispositivo como padrão, reservando as chaves sincronizadas para casos em que a vantagem justifique essa escolha.
4. Revise as políticas internas que possam afetar o uso de chaves de acesso, como restrições ao uso de portas USB, BLE ou dispositivos móveis. Elabore um cronograma de implantação em fases. Estabeleça marcos, designe responsáveis e defina critérios de aprovação ou rejeição. Obtenha o apoio da diretoria desde o início.

Fase 2: Implantação piloto (seis a dez semanas)

1. Escolha cuidadosamente seu grupo piloto. Os funcionários das áreas de TI e segurança são os primeiros usuários ideais. Incluir um pequeno grupo de assistentes executivos ajuda a identificar casos-limite práticos, como computadores compartilhados e situações de delegação de tarefas.
2. Dependendo dos seus casos de uso, teste os dois tipos de senha de acesso em seu ambiente. Verifique o cadastro, o login, a reautenticação após o dispositivo entrar em modo de suspensão e o SSO em todos os tipos de dispositivos e sistemas operacionais utilizados pela sua organização.
3. Elabore e teste os procedimentos do suporte técnico. Simule cenários como perda de dispositivos, esquecimento de PIN, integração e desligamento de funcionários antes que eles ocorram em ambiente de produção. A equipe do suporte técnico deve ser capaz de executar fluxos de trabalho de recuperação com segurança, sem estar suscetível a técnicas de engenharia social.
4. Defina métricas de sucesso. Acompanhe as taxas de inscrição, as taxas de sucesso/falha na autenticação e o volume de tickets do suporte técnico como referências antes de expandir a escala.
5. Colete feedback estruturado. Realize pesquisas com os usuários-piloto após duas e seis semanas. Use o que for aprendido para atualizar os materiais de treinamento e a configuração antes da implantação em maior escala.

Fase 3: Implantação na empresa (dois a seis meses)

1. Implemente um programa de gestão de mudanças. Vídeos curtos com orientações passo a passo e guias de trabalho escritos funcionam melhor do que documentações extensas. Adapte o conteúdo a cada segmento de usuários — a experiência de um desenvolvedor remoto é diferente da de um usuário que trabalha em um ambiente com estações de trabalho compartilhadas.
2. Implemente em etapas. Faça a implantação por departamento, região geográfica ou nível de risco. Os usuários de alto risco geralmente são os primeiros; os usuários que utilizam dispositivos compartilhados e os que dependem de sistemas legados, por último.
3. Mantenha métodos alternativos de autenticação disponíveis. Não remova a autenticação multifatorial (MFA) legada imediatamente. Mantenha o envio de OTP por notificação push, códigos QR ou tokens de hardware como alternativas até que o número de usuários cadastrados atinja o limite-alvo (normalmente 90%+ por departamento).
4. Monitore a adoção e o desempenho da autenticação. Use os painéis da plataforma para acompanhar a conclusão dos registros, as taxas de falha e as tendências do suporte técnico. Defina alertas para detectar anomalias com antecedência.
5. Complete o ciclo com medidas de segurança. Após a implantação total, atualize a documentação da sua política de MFA e realize uma revisão pós-implantação. As passkeys eliminam o phishing de credenciais — mas a engenharia social no suporte técnico continua sendo um risco real.

A seguir, apresentamos exemplos ilustrativos baseados em padrões comuns de implantação.

Cenário 1: Serviços financeiros — banco regional, 5.000 funcionários
Um banco regional de médio porte implementou chaves de acesso vinculadas a dispositivos por meio de RSA ID Plus com Chaves de segurança de hardware com certificação FIPS 140-3 para usuários com privilégios e funcionários das filiais.

• Desafio principal: O aplicativo de caixa bancário antigo exigia uma camada de proxy FIDO2; a equipe do suporte técnico precisou passar por um treinamento de resistência à engenharia social antes da implantação.
• Tipo de senha: Chaves de segurança de hardware vinculadas a dispositivos
• Linha do tempo: Seis meses
• Resultados: Redução de 43% nos tickets de suporte; zero violações relacionadas a senhas após a implantação

Cenário 2: Governo — órgão federal, 12.000 funcionários
Uma agência federal civil precisava cumprir as exigências da Ordem Executiva 14028 e da diretriz M-22-09 do OMB relativas à autenticação multifatorial (MFA) resistente a phishing em um ambiente híbrido que incluía segmentos de rede classificados isolados fisicamente.

• Principais desafios: Os segmentos isolados da Internet precisavam de autenticação sem conexão com a Internet; um sistema legado de gerenciamento de casos exigia uma camada de proxy FIDO2; mais de 30 escritórios regionais precisavam de suporte para cadastro remoto.
• Tipo de senha: FIPS 140-3 Nível 3 RSA iShield Key 2 para todos os funcionários; tokens RSA DS100 OTP para segmentos isolados da rede
• Linha do tempo: Dez meses
• Resultados: Certificação de conformidade total com a EO 14028 / M-22-09; a taxa de captura de credenciais caiu de 18% para menos de 1%; redução de 38% nos tickets de suporte técnico