A Okta está comprometida em fornecer aos nossos clientes o mais alto nível de segurança. Fomos um dos primeiros fornecedores de tecnologia a prometer nosso compromisso com os sete princípios de Segurança por Design da Agência de Segurança Cibernética e Infraestrutura dos EUA (CISA) e, há um ano, lançamos o Compromisso de Identidade Segura da Okta.
Sob estas iniciativas, anunciamos e entregamos várias funcionalidades e upgrades essenciais para a nossa infraestrutura corporativa e portfólio de produtos. Isto inclui incentivar os clientes a usar uma das medidas de segurança mais eficazes disponíveis: uma abordagem forte e consistente para a autenticação multifator (MFA). Para ajudar a aumentar a base de segurança para todos, começamos a impor a MFA para todos os logins do Okta Admin Console em 2024, uma etapa inteligente e necessária em nosso compromisso compartilhado com a segurança identity-first.
Hoje, temos o orgulho de compartilhar que a Okta alcançou 100% de aplicação de MFA para o Okta Admin Console para todos os tenants Okta existentes em um ano. E para todos os novos tenants, a MFA é um requisito padrão e imutável para as políticas de acesso ao Okta Admin Console.
Por que a MFA está sendo aplicada para o Okta Admin Console?
O Okta Admin Console é o hub central para gerenciar usuários Okta, aplicativos protegidos pela Okta e políticas de segurança da Okta. O acesso não autorizado a este console pode ter consequências devastadoras que incluem:
- Violações de dados: invasores podem acessar informações confidenciais de usuários e dados de aplicativos.
- Comprometimento do sistema: agentes de ameaças podem alterar as configurações de segurança, criar contas de backdoor e desativar recursos de segurança criados.
- Interruções do serviço: alterações não autorizadas podem levar a interrupções e funcionalidade prejudicada para os usuários finais.
- Danos à reputação: um incidente de segurança pode afetar gravemente os negócios e a marca de uma organização.
O MFA reduz significativamente o risco desses resultados, exigindo um segundo fator de verificação além de uma senha, como uma senha de uso único baseada em tempo (TOTP) de um aplicativo autenticador móvel, uma leitura de impressão digital ou um token de hardware. Embora a Okta apenas exija o MFA com quaisquer dois fatores de conhecimento, posse ou inerência, a Okta incentiva fortemente os administradores a abandonar as senhas e habilitar os autenticadores mais seguros disponíveis, que incluem autenticadores resistentes a phishing como o Okta Verify FastPass e os autenticadores FIDO2 WebAuthn.
A Okta fornece recursos robustos para impor o MFA para acesso administrativo. Todos os tenants Okta vêm com um número de base de fatores suportados, como Okta Verify TOTP, FastPass e e-mail, além de senhas. A Okta também fornece uma política flexível que permite que os administradores imponham o MFA especificamente ao Okta Admin Console.
A política de aplicação para o console sempre exigiu a MFA por padrão. No entanto, os administradores tinham permissão para fazer o downgrade da configuração para a autenticação de fator único (1FA), o que muitos optaram por fazer por vários motivos. Agora, a Okta impede que essa postura de segurança padrão seja rebaixada, e ajudamos todos os clientes existentes a elevar sua postura de segurança com a MFA.
Como convencemos os clientes Okta a impor a Autenticação Multifator (MFA)
Vamos analisar como ajudamos os administradores a superar sua necessidade real e percebida de manter políticas 1FA e adotar a MFA para proteger o acesso ao Okta Admin Console. Em geral, os clientes aceitaram que a MFA era uma coisa boa para incutir. No entanto, havia vários motivos comuns pelos quais eles acreditavam que tinham que permanecer no nível de garantia 1FA:
- Os administradores não sabiam que tinham regras de política que permitiam o acesso 1FA.
- Os administradores pensavam que não precisavam de MFA, pois armazenavam suas senhas em cofres e as alteravam a cada uso.
- Os administradores concluíram a MFA com um provedor de identidade (IdP) diferente da Okta e estavam federando no Okta Admin Console.
- Os administradores tinham contas de teste automatizadas que precisavam fazer login no console.
- Os administradores estavam preocupados com as operações do Lightweight Directory Access Protocol (LDAP) e do agente Active Directory (AD).
Nós nos esforçamos para abordar cada um desses obstáculos e preocupações. Essa última questão foi fácil de resolver com uma simples confirmação de que não haveria impacto nas operações normais do agente.
No entanto, quanto ao resto, primeiro publicamos avisos aos administradores se eles tivessem um tenant com quaisquer regras permitindo acesso 1FA por meio de nosso recurso HealthInsights.
Também publicamos avisos da política do Okta Admin Console, destacando essas regras ofensivas.
Para os administradores que acreditavam que não precisavam de MFA, pois regularmente protegiam e alternavam suas senhas, reforçamos que a proteção MFA é superior. Embora os clientes devam continuar a proteger e alternar seus segredos, eles também devem adicionar um requisito de fator adicional, especificamente um fator de posse ou biométrico (Autenticação Multifator, MFA). Se as senhas protegidas forem compartilhadas com vários usuários, recomendamos que cada usuário tenha sua própria conta exclusiva.
Quanto a outros clientes, alguns optaram por concluir a MFA em um IdP externo e federar no Okta Admin Console. Até recentemente, o Okta tratava essa federação de entrada como um único fator. No entanto, agora temos um novo recurso chamado claims sharing. O IdP pode enviar declarações AMR baseadas em padrões dentro da resposta SAML ou OIDC, e o Okta honrará os fatores concluídos com o outro IdP como satisfatórios para a garantia de MFA. Assim, mais um obstáculo foi removido.
Para clientes com contas de teste automatizadas que faziam login no console para concluir os testes, os administradores acreditavam que fornecer um fator adicional não seria possível para tais contas. A Okta resolveu esse problema recomendando que as contas de teste se inscrevessem em um fator TOTP e armazenassem o segredo compartilhado junto com a senha. Depois de verificar a senha, o segredo compartilhado também pode ser verificado e utilizado para gerar programaticamente o TOTP no momento do login.
Com todos esses desafios do cliente resolvidos, nossos clientes estavam prontos para agir.
Preparando-se para implementar as alterações
Dado o grande número de tenants Okta com os quais estávamos lidando, desde tenants de avaliação gratuita e desenvolvedores até tenants com implementações grandes e complicadas, foi necessário escalonar a implementação para ajudar a garantir o mínimo de interrupção nas operações normais. Portanto, empregamos várias táticas para impor cuidadosamente a MFA ao Okta Admin Console:
- Anuncie a iniciativa: Além de anúncios públicos e blogs indicando a aplicação iminente da MFA, publicamos guias e banners no produto nos portais de desenvolvedores e suporte da Okta e enviamos e-mails direcionados aos administradores para informá-los sobre as próximas alterações.
- Impedir a criação de todas as novas políticas de acesso 1FA: Como um primeiro passo, o Okta implementou alterações em todos os tenants para que nenhuma nova política de acesso 1FA pudesse ser estabelecida. A ideia era estancar o sangramento antes que a correção completa fosse implementada.
- Divida os clientes em grupos para a aplicação da MFA: Para mitigar o risco de uma enxurrada de tickets de suporte para a Okta e evitar bloqueios desnecessários de administradores, implementamos essa alteração por grupos de clientes. Primeiro, examinamos as configurações de cada locatário e os agrupamos com base nas etapas de correção que eles exigiriam para aplicar a MFA. Então, selecionamos diferentes datas de aplicação para cada grupo e preparamos instruções de correção específicas.
Os administradores foram instruídos a modificar suas políticas do Okta Admin Console das seguintes maneiras:
- As regras com garantia apenas de senha devem ser modificadas para exigir uma senha e outro fator.
- As regras com qualquer garantia 1FA ou garantia somente de fator de posse devem ser modificadas para exigir quaisquer dois fatores.
Uma vez feita a alteração, os administradores não foram autorizados a fazer o downgrade de volta para a garantia 1FA. Se um administrador não tomasse nenhuma atitude, a Okta aplicaria a MFA ao console para esse tenant em uma data claramente comunicada.
Clientes da Okta iniciam rapidamente a MFA
Nos primeiros quatro meses do lançamento, a Okta concluiu a aplicação da MFA em 99% de todos os tenants aplicáveis. O 1% restante eram tenants que exigiam suporte adicional da Okta, seja na forma de aprimoramentos de recursos, como compartilhamento de declarações, ou tempo para atualizar vários processos para operar neste novo nível de segurança exigido. A Okta permaneceu em contato com este grupo de clientes para entender profundamente seus pontos problemáticos e colaborar com eles até que estivessem confiantes em seguir em frente nesta nova direção.
Com a aplicação de 100% da MFA no Admin Console da Okta, os administradores agora estão utilizando uma variedade de fatores e autenticadores para fazer login no console. Os três principais fatores usados incluem senha, notificações push do Okta Verify e Okta FastPass. Combinações comuns desses fatores usados para concluir um desafio de MFA incluem senha e push do Okta Verify, bem como senha e Okta FastPass.
Hoje, o acesso MFA ao Okta Admin Console é um requisito não negociável para todos os administradores Okta atuais e recém-integrados. Ao adotar essa postura segura por padrão, os clientes se beneficiam de uma superfície de ataque reduzida e maior proteção da infraestrutura de identidade crítica.
Saiba mais sobre o produto MFA da Okta visitando a página da Web do Adaptive MFA. Fique de olho no que a Okta está fazendo para combater ataques baseados em identidade, aprendendo sobre o Compromisso de Identidade Segura da Okta.
