Os invasores cibernéticos estão em constante evolução e desenvolvendo métodos mais sofisticados. Os ataques de phishing e engenharia social estão aumentando e, tão rápido quanto as organizações implementam autenticadores mais avançados, os invasores se adaptam a eles. Uma estratégia emergente envolve o roubo de tokens de sessão diretamente dos navegadores da web dos usuários, apresentando um novo desafio na batalha contínua pela segurança digital.
Na Okta, impedir que invasores acessem informações confidenciais nos dispositivos de nossos usuários é uma prioridade máxima. Okta FastPass ajuda a impedir esses tipos de ataques usando a reavaliação de contexto.
O que é a reavaliação de contexto e quais são seus benefícios?
O FastPass realiza verificações de segurança silenciosamente cada vez que você acessa um novo aplicativo e impede o acesso adicional se a Okta determinar que a identidade ou a postura do dispositivo foi alterada materialmente, o que pode indicar uma sessão comprometida. Essa capacidade de lidar com mudanças de risco do dispositivo e do usuário oferece um benefício enorme, impedindo que sessões roubadas acessem aplicativos downstream.
Como configurar o Okta FastPass com reavaliação de contexto?
Passo 1: Adicione o Okta Verify como um autenticador.
Etapa 2: Criar uma política de inscrição de autenticador. Na seção “Autenticadores elegíveis”, certifique-se de que o Okta Verify esteja definido como “Obrigatório”.
Etapa 3: Crie uma política de autenticação e atribua os aplicativos.
- Adicione uma regra de política de autenticação com as seguintes configurações.
- “Device state” está definido como “Registered”.
- “O usuário deve autenticar com” está definido como “Posse”.
- Acaixa de seleção “Resistente a Phishing” está marcada.
- A caixa de seleção “Hardware Protected” está marcada (recomendado).
- Você também pode definir "User's group membership includes" para um grupo específico para fins de teste.
- Na seção “Frequência de reautenticação”, defina “Reautenticar após” para duas horas. Este valor pode ser modificado com base nas necessidades de negócios.
- Edite a Regra Catch-all padrão e defina “Acesso” como “Negado”.
Siga as etapas listadas na Etapa 4 para garantir que seus usuários não sejam bloqueados.
- Adicione aplicativo(s) downstream à política.
- Selecione a aba “Applications” e clique em “Add app.”
- Clique em “Adicionar” para cada aplicativo que você deseja adicionar a esta política.
- Clique em “Close.”
Etapa 4: Verifique usando a Access Testing Tool (recomendado)
A Access Testing Tool permite que você execute simulações de solicitações de usuário do mundo real para acessar um aplicativo. O resultado mostra se o usuário teria permissão para acessar o aplicativo e quais regras e configurações de sua configuração foram correspondidas para criar os requisitos de autenticação e registro.
- No Admin Console, vá para “Relatórios > Ferramenta de Teste de Acesso”.
- Application: Selecione o aplicativo usado na Etapa 3.
- Username: Insira o nome de usuário de um usuário cujo acesso você deseja testar. Selecione-o na lista quando aparecer.
- Defina o Device State para “Registered”.
- Modifique outras opções conforme necessário
- Clique em “Run Test.”
Analise os resultados na seção “Resultados” da página. Na seção “Políticas Correspondentes”, todas as políticas que correspondiam aos critérios aparecem se o teste foi bem-sucedido. Na opção“Jornada de login”, selecione o bloco “Autenticar” . Esta opção mostra quais políticas continham os autenticadores e os requisitos de autenticação que correspondiam aos critérios que você configurou no simulador. Aqui, você deve ver a política de autenticação criada na Etapa 3.
Etapa 5. Adicionar aplicativos downstream adicionais à política de autenticação (opcional).
Etapa 6: Adicione uma política de garantia de dispositivo (recomendado).
As verificações de garantia do dispositivo incluem conjuntos de atributos de dispositivo relacionados à segurança. Ao adicionar verificações de garantia de dispositivo às regras da política de autenticação, você pode estabelecer requisitos mínimos para dispositivos com acesso a sistemas e aplicativos em sua organização.
Etapa 6.1: Adicionar uma política de garantia de dispositivo.
Etapa 6.2: Adicionar garantia de dispositivo a uma política de autenticação.
Agora, vamos ver a reavaliação do contexto em ação.
O que vem agora?
A Okta está comprometida em melhorar continuamente como o FastPass pode oferecer ainda mais segurança às organizações. Atualmente, estamos trabalhando com fornecedores de navegadores em uma solução padrão para evitar que cookies de sessão sejam roubados e usados em qualquer dispositivo que não seja o dispositivo original ao qual foram concedidos.
—
Tem uma pergunta sobre o FastPass ou a Segurança do Dispositivo? Participe do fórum da comunidade Okta Devices and Mobility e inicie uma conversa.
Tem perguntas sobre esta postagem do blog? Entre em contato conosco em eng_blogs@okta.com.
Explore Blogs de Engenharia mais 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 do gerenciamento de identidade moderno e sofisticado para sua organização.
Entre em contato com o departamento de vendas para obter mais informações.
