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 com um número ímpar de pessoas deve reservar um lugar na frente do restaurante, enquanto um grupo com um número par 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) age 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 é muitas vezes muito mais complicada do que isso. Muitas vezes, alguns cenários exigirão MFA para acesso ao aplicativo, enquanto diferentes cenários permitirão 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 implica.
Esta é uma tarefa fácil quando se permite que apenas um provedor de identidade autentique um aplicativo. Mas torna-se muito mais complexo quando se adicionam políticas de autenticação variáveis, migrações de soluções de identidade anteriores, modelos hub-and-spoke e diferentes aplicativos SaaS que aplicam regras diferentes para logins diretos e aplicação de MFA (Autenticação Multifator). Tudo isso resulta em vários cenários de login, tornando mais difícil rastrear — e proteger — todos eles.
Nesta postagem do blog, nos aprofundaremos em 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 executam 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 certas aplicações)
- Diferenciando dispositivos pertencentes à empresa e BYOD (Bring Your Own Device)
- 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 (Autenticação Multifator)
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 maneiras diferentes.
Enquanto a Okta usa 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 soem equivalentes na superfície, o segundo método torna muito mais difícil criar 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 configuradas 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 muitas vezes seja 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 por senha pode precisar ser desativado por usuário, mesmo que o SSO (Single Sign-On) esteja configurado. Em outros serviços, as contas de administrador sempre podem ser acessadas diretamente sem uma opção para desativá-lo.
O principal a entender é que cada aplicativo se comporta de forma diferente e não há comportamento universal em que se possa confiar. Se o MFA estiver configurado para uma conta, alguns aplicativos ainda solicitarão, mesmo que o usuário faça login através do SSO, enquanto alguns só solicitarão o MFA se o usuário tiver feito login diretamente. Outros serviços podem até permitir configurar qual dos dois comportamentos ocorrerá.
Vários 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 desativou o antigo
- Testando 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 contabilizados; 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 (Autenticação Multifator) tradicional em favor de tornar-se passwordless.
Tal empreendimento exige examinar esses diferentes cenários de autenticação, pois envolve a compreensão da força da autenticação em cada um deles.
Neste post 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 dos aplicativos tornam isso tudo menos um status simples de sim/não.
Para enfrentar os desafios que essa complexidade apresenta, recomendamos adotar 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 perguntas sobre esta publicação 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 equipe apaixonada de engenheiros excepcionais? Visite nossa página de carreiras.
Desbloqueie o potencial de um gerenciamento de identidade moderno e sofisticado para sua organização. Entre em contato com o departamento de vendas para obter mais informações.
Este blog e quaisquer recomendações contidas não constituem aconselhamento jurídico, de privacidade, segurança, conformidade ou 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.
