Algumas perguntas só precisam de uma resposta de sim ou não. Se você ligar para um restaurante e perguntar: "Poderia fazer uma reserva para as 14h?" Algumas respostas razoáveis seriam "Sim", "Não" ou "Só temos mesas ao ar livre disponíveis". Tudo bem?"
Provavelmente ficaria surpreso ao ouvir: "Sim, mas um grupo de números ímpares deve reservar um lugar na frente do restaurante, enquanto um grupo de números pares deve reservar um lugar no fundo." Além disso, por favor, use roupas brancas e use o pé esquerdo para entrar no restaurante; caso contrário, você será rejeitado."
A surpresa aqui seria dupla: primeiro, você não esperava uma resposta tão longa e, segundo, não parece que essas condições deveriam existir em primeiro lugar.
Acontece que a aplicação da autenticação multifator (MFA) funciona de forma semelhante. Embora você espere que a pergunta "Esta conta está protegida por MFA?" tenha uma resposta simples de sim/não, a realidade é frequentemente muito mais complicada do que isso. Muitas vezes, alguns cenários aplicam o MFA para acesso a aplicativos, enquanto cenários diferentes permitem o acesso sem MFA — às vezes intencionalmente, mas frequentemente não.
O problema com a fragmentação
Um dos principais recursos a serem procurados em uma solução como o Okta Identity Security Posture Management é a capacidade de rastrear todos os cenários de autenticação que levam a cada conta em seus aplicativos SaaS e entender o status de proteção que cada um acarreta.
Esta é uma tarefa fácil quando se permite que apenas um único provedor de identidade autentique um aplicativo. Mas se torna muito mais complexo quando você adiciona políticas de autenticação variáveis, migrações de soluções de identidade anteriores, modelos hub-and-spoke e diferentes aplicativos SaaS aplicando regras diferentes para logins diretos e aplicação de MFA. Tudo isso resulta em vários cenários de login, tornando mais difícil rastrear — e proteger — todos eles.
Nesta postagem do blog, investigaremos mais a fundo muitas dessas fontes de fragmentação e exploraremos seu impacto potencial.
Políticas de autenticação
As políticas de autenticação, frequentemente chamadas de Políticas de Acesso Condicional, são usadas para impor requisitos de fator quando os usuários fazem login em aplicativos ou realizam determinadas ações.
Há muitos motivos para permitir diferentes tipos de fatores (ou até mesmo permitir o login sem MFA):
- Diferentes plataformas permitem o uso de vários fatores (e, como resultado, algumas plataformas podem ser acessíveis apenas a determinados aplicativos)
- Diferenciação entre dispositivos de propriedade da empresa e BYOD (Bring Your Own Device, traga seu próprio dispositivo)
- Isenção para contas de serviço e identidades não humanas
- Não exigir MFA ao acessar recursos não confidenciais para reduzir a fadiga de MFA
Naturalmente, essas diferenças nos requisitos devem ser consideradas ao exibir o status de aplicação de uma conta.
Lacunas acidentais na configuração da política
Diferentes provedores de identidade permitirão que você configure políticas de autenticação de diferentes maneiras.
Embora a Okta use um modelo baseado em prioridade para configurar políticas de autenticação, outros provedores configurarão políticas “globais” com a ação “mais severa” em vigor.
Embora ambos os métodos pareçam equivalentes na superfície, o segundo método dificulta muito a criação de exceções de todas as políticas, muitas vezes resultando em lacunas de segurança.
Embora este exemplo seja simplista e improvável ao configurar apenas algumas políticas, vale a pena lembrar:
- Grandes organizações geralmente têm dezenas de políticas em vigor, tornando provável que percam tais casos (frequentemente encontramos essas lacunas na prática ao analisar as políticas de acesso condicional definidas em outros provedores de identidade).
- Embora seja improvável que alguém esteja usando plataformas incomuns ao fazer login, as condições da plataforma são avaliadas usando o User Agent, que é facilmente e comumente falsificado durante campanhas de credential-stuffing.
Métodos de login alternativos
Embora a força motriz por trás do single sign-on (SSO) seja que o acesso a todos os aplicativos pode ser gerenciado a partir de um único local, geralmente existem várias maneiras de acessar uma determinada conta em um determinado aplicativo. Vamos revisar alguns desses casos.
Login direto
Muitas vezes, as contas que podem acessar um aplicativo via SSO também podem fazer login diretamente no aplicativo (usando uma combinação de nome de usuário e senha ou usando chaves de acesso).
Embora seja frequentemente uma escolha deliberada (por exemplo, para permitir o acesso de administrador de emergência ou durante a configuração do aplicativo), às vezes pode acontecer não intencionalmente. Em alguns serviços, o acesso com senha pode precisar ser desativado por usuário, mesmo que o SSO esteja configurado. Em outros serviços, as contas de administrador sempre podem ser conectadas diretamente sem uma opção para desativá-lo.
O principal a entender é que cada aplicativo se comporta de maneira diferente e não há um comportamento universal para se basear. Se o MFA estiver configurado para uma conta, alguns aplicativos ainda solicitarão, mesmo que o usuário faça login via SSO, enquanto alguns só solicitarão o MFA se o usuário tiver feito login diretamente. Outros serviços podem até permitir a configuração de qual dos dois comportamentos ocorrerá.
Múltiplos provedores de SSO
Em muitos casos, certas contas em um aplicativo podem ser acessadas usando vários provedores de identidade. Tais casos podem ocorrer devido a:
- Diferentes subsidiárias ou departamentos usando diferentes provedores de identidade, com potencial para sobreposições entre eles
- Sobras de soluções de identidade anteriores, onde uma migração habilitou o novo provedor de identidade, mas nunca desabilitou o antigo
- Testar configurações usadas para contas específicas ou antes de inscrever toda a organização
Às vezes, esses vários provedores são conhecidos e levados em conta; outras vezes, essas configurações ficam ocultas e fáceis de perder.
Força do fator
Até agora, tudo o que discutimos tratou “MFA/Sem MFA” como uma questão binária, mas a realidade é mais complicada do que isso.
Com mensagens SMS suscetíveis a ataques de tomada de controle e phishing desenfreados, sua organização pode preferir impor apenas fatores resistentes a phishing, ou mesmo abandonar o MFA tradicional em favor de ficar sem senha.
Tal esforço requer examinar esses diferentes cenários de autenticação, pois envolve a compreensão da força da autenticação em cada um deles.
Nesta postagem do blog, descobrimos as complexidades por trás da aplicação do MFA. Fatores como políticas de autenticação, vários provedores de SSO e diferenças nos comportamentos do aplicativo tornam tudo menos um status simples de sim/não.
Para superar os desafios que essa complexidade apresenta, recomendamos a adoção de uma estratégia abrangente para manter o padrão de autenticação da sua organização e verificar regularmente se todas as contas estão devidamente protegidas. Okta Identity Security Posture Management ajuda você a obter visibilidade dos fluxos de autenticação inesperados, garantindo um padrão consistente para a autenticação em toda a sua organização.
Tem dúvidas sobre esta postagem do blog? Entre em contato conosco em eng_blogs@okta.com.
Explore mais Blogs de Engenharia perspicazes da Okta para expandir seu conhecimento.
Pronto para se juntar à nossa apaixonada equipe de engenheiros excepcionais? Visite nossa página de carreiras.
Desbloqueie o potencial do gerenciamento de identidade moderno e sofisticado para sua organização. Entre em contato com vendas para obter mais informações.
Este blog e quaisquer recomendações aqui contidas não constituem aconselhamento jurídico, de privacidade, de segurança, de conformidade ou de negócios. Este blog destina-se apenas a fins informativos gerais e pode não refletir os desenvolvimentos de segurança, privacidade e legais mais atuais, nem todas as questões relevantes. Você é responsável por obter aconselhamento jurídico, de segurança, privacidade, conformidade ou negócios de seu próprio advogado ou outro consultor profissional e não deve confiar nas recomendações aqui contidas. A Okta não é responsável perante você por quaisquer perdas ou danos que possam resultar da implementação de recomendações contidas nestes materiais. A Okta não faz declarações ou oferece qualquer tipo de garantia em relação ao conteúdo destes materiais.
