À medida que as ameaças cibernéticas crescem em complexidade e frequência, a necessidade de uma segurança de identidade robusta nunca foi tão crítica. Ataques baseados em identidade, como credenciais comprometidas e acesso não autorizado, representam riscos significativos para as organizações. A proteção contra essas ameaças requer uma abordagem proativa e inteligente que detecte e responda a atividades suspeitas e se integre perfeitamente com as medidas de segurança existentes.
Apresentamos o Okta Identity Threat Protection com Okta AI, uma solução de ponta projetada para fortalecer a segurança de identidade da sua organização. Combinando o poder da inteligência artificial (IA) com a proteção de identidade abrangente, o Okta Identity Threat Protection oferece detecção de ameaças contínua e em tempo real, além de recursos de resposta personalizados para enfrentar os desafios exclusivos da segurança cibernética moderna.
Um dos recursos mais poderosos do Okta Identity Threat Protection com Okta AI é sua integração com o Okta Workflows. Esses workflows servem para criar automação e permitir que sua infraestrutura de segurança responda de forma dinâmica e eficaz às ameaças. Com ações personalizáveis e orientadas por políticas, o Okta Workflows pode ser usado para desativar ou colocar em quarentena contas comprometidas, impor a autenticação multifator (MFA) para atividades de alto risco e alertar as equipes de segurança sobre possíveis violações — ajudando a tornar suas defesas ativas e responsivas.
Vamos explorar como o Okta Identity Threat Protection com Okta AI e Okta Workflows, nossa plataforma de automação low-code, pode ajudá-lo a atingir melhor suas metas de segurança e negócios.
Automação personalizada para Okta Identity Threat Protection
A seguir, uma visão simplificada do Okta Identity Threat Protection com Okta AI. Sinais e eventos tanto da Okta quanto de parceiros são constantemente alimentados na Okta, e o mecanismo de risco do Identity Threat Protection determina os riscos e executa as políticas associadas.
Essas políticas podem acionar ações corretivas, como realizar um Logout Universal ou chamar um fluxo delegado no Okta Workflows. Neste artigo, chamaremos esses workflows iniciados por política.
A avaliação de risco também pode acionar ações dentro do Okta, como aumentar o nível de risco do usuário (chamado de nível de risco da entidade). Uma mudança no nível de risco do usuário é apenas um dos muitos eventos relacionados ao Identity Threat Protection que serão gravados nos logs do sistema Okta, juntamente com itens como reavaliação de políticas, alterações no contexto da sessão, recebimento de um sinal de risco de um fornecedor terceirizado e muito mais. Quase qualquer atividade dentro do Okta é registrada no log do sistema. É comum acionar workflows a partir de eventos elegíveis usando event hooks ou o conector Okta integrado dentro do Workflows. Neste artigo, chamaremos esses workflows iniciados por eventos.
Workflows iniciados por políticas
Da documentação do produto: Quando o Identity Threat Protection com Okta AI descobre um risco e o evento de correção requer ações adicionais além do encerramento de sessão universal, você pode executar automaticamente um fluxo de trabalho delegado.
Os aplicativos e serviços de terceiros fornecidos por meio dos conectores do Okta Workflows oferecem várias ações de correção possíveis.
- Notifique usuários ou administradores por meio do Slack ou e-mail
- Desativar um usuário
- Remova um usuário de um grupo privilegiado
- Mover um usuário para um novo grupo restrito
- Quarentenar um dispositivo
- Enviar um ticket de incidente para uma fila
- Configure diferentes fluxos para diferentes cenários de risco com base em seus requisitos
Além disso, você pode usar os cartões Custom API Action incluídos em quase todos os conectores para criar ações personalizadas que podem interagir com quaisquer endpoints de API de terceiros.
A documentação do Okta Identity Threat Protection ilustra vários exemplos de Workflow que podem ser iniciados a partir de políticas específicas, como:
- Enviar uma mensagem no Slack para indicar uma violação de política
- Limpe as sessões de usuário e envie uma notificação por e-mail para reduzir o risco
- Remova o usuário de todas as associações e desative sua conta
Assim, os workflows iniciados por política são úteis para a automação vinculada a riscos específicos gerados pelo Identity Threat Protection, pois os workflows estão vinculados a políticas específicas. Se você deseja direcionar a automação com base em situações mais genéricas, como uma alteração no nível de risco do usuário, os workflows iniciados por eventos são mais apropriados.
Exemplos de fluxo de trabalho iniciado por evento
Abaixo estão três exemplos de como acionar workflows a partir de eventos no log do sistema Okta e cobrindo diferentes casos de uso.
- Uma mudança no nível de risco do usuário aciona um ticket no ServiceNow e a atribuição a um grupo de alto risco no Okta.
- Quando um usuário é atribuído a um aplicativo de alto risco, um fluxo de trabalho verifica o risco do usuário e permite ou reverte o novo acesso.
- Quando um usuário é atribuído a um aplicativo de alto risco, um workflow verifica o risco do usuário e permite ou aciona uma Revisão de Acesso do Usuário no Okta Identity Governance.
1. Registrar um ticket do ServiceNow e atribuir um usuário a um grupo de alto risco
Neste exemplo, usamos um event hook inscrito em user.risk.detect eventos para disparar um workflow. Nesse cenário, notificamos nossa equipe de segurança sobre o evento no Slack com detalhes úteis e enviamos um e-mail ao gerente do usuário cujo nível de risco mudou.
Nos casos em que o nível de risco de um usuário é ALTO, também criamos um incidente no ServiceNow, adicionamos o usuário a um grupo de alto risco no Okta, enriquecemos nossa notificação com um link para o incidente do ServiceNow e indicamos que o usuário foi adicionado ao grupo. Quando o nível de risco do usuário diminui, ele é removido do grupo de alto risco.
O workflow irá:
- Seja acionado pelo evento `user.risk.detect` no log do sistema Okta. evento no log do sistema Okta. Usaremos um event hook apontado para um fluxo de API Endpoint. (Consulte Processando Okta Event Hooks com Workflows para obter mais informações.)
- Analisar os detalhes do evento
- Leia o usuário por ID para retornar informações de seu perfil e gerar um link para uma consulta de *log* do sistema relacionada ao evento
- Determine o nível de risco do usuário:
- Se agora for “ALTO”
- Criar um incidente no ServiceNow
- Adicione o usuário a um grupo Okta de alto risco
- Enviar e-mail para o gerente do usuário
- Enriquecer as notificações de bate-papo com contexto sobre as ações acima
- Se diminuiu de “ALTO”:
- Remova o usuário do grupo Okta de alto risco
- Enriquecer as notificações de bate-papo com contexto sobre as ações acima
- Se agora for “ALTO”
- Enviar notificações em todos os user.risk.detect eventos:
- Mensagem do Slack (ou Teams) para um canal de segurança para todos os user.risk.detect eventos
- Adicione informações sobre adição/remoção de grupo e link para o incidente do ServiceNow quando aplicável.
Vamos percorrer o fluxo. Primeiro, analisamos o payload de "user.risk.detect" evento e atribuímos alguns valores que usaremos mais tarde em nosso fluxo. Em seguida, fechamos a conexão com o event hook com um código de status 200.
Em seguida, chamaremos alguns fluxos auxiliares. Um nos ajudará a analisar ainda mais o evento debugData.risk para obter os níveis de risco atuais e anteriores. O outro recuperará algumas informações de perfil sobre o usuário cujo nível de risco foi elevado e criará um link para uma consulta de log do sistema sobre o evento.
Se o risco do usuário agora for “ALTO”, nós iremos
- Adicione-os ao grupo Okta de alto risco
- Enviar um e-mail para o gerente do usuário
- Criar um incidente no ServiceNow
- Personalize nossa notificação do Slack enviada com cada mudança de nível de risco para informar nossa equipe de que o usuário foi adicionado ao grupo e inclua um link para o incidente do ServiceNow. A mensagem também indicará se a ação “Criar Incidente” do ServiceNow falhar.
Finalmente, pegaremos as mensagens construídas dinamicamente, indicando
- O usuário foi adicionado ou removido do grupo Okta de alto risco
- Incidente do ServiceNow e link (ou link para investigar se a criação do incidente falhou)
Nós os combinaremos com o resto dos detalhes do evento de risco que enviamos por padrão com cada user.risk.detect evento, e enviaremos nossa notificação.
Implementar um fluxo como este aproveita o poder do Workflows e do Okta Identity Threat Protection para dar à sua equipe visibilidade contínua em tempo real dos sinais de risco detectados em seu *tenant* Okta. Ele permite que você integre diferentes plataformas que você usa para enviar notificações, criar *tickets* e automatizar respostas, como colocar o usuário em quarentena em um grupo de alto risco ou disparar um incidente com um SLA para resposta em outra plataforma. O grupo Okta de “Alto Risco” pode estar sujeito a políticas estritas que limitam o acesso de um usuário até que sua equipe tenha a chance de investigar. Adicionar usuários ao grupo pode acionar outros fluxos, ou você pode até ter políticas mais rigorosas dentro do Identity Threat Protection que se aplicam ao grupo.
2. Verificando o risco do usuário na atribuição de aplicativo de alto risco
Neste exemplo, temos um aplicativo de alto risco no Okta (como o produto PAM, Okta Advanced Server Access), e quando um usuário é atribuído a este aplicativo, queremos verificar o nível de risco do usuário. Se o usuário tiver um nível de risco Baixo, o acesso ao aplicativo é permitido. O acesso é permitido se o risco for Médio, mas uma mensagem do Slack é escrita para destacar isso. Se o risco for Alto, o acesso ao aplicativo é revertido.
O workflow irá:
- Ser acionado pelo evento application.user_membership.add no *log* do sistema Okta. Este é um evento padrão integrado ao conector Okta Workflows
- Pesquise o usuário por ID para obter detalhes caso uma mensagem do Slack seja necessária
- Determine o risco do usuário. Nesse caso, ele está fazendo uma pesquisa nos grupos do usuário para ver se eles estão em um grupo de risco Alto ou Médio, então
- Se o risco do usuário for baixo, ele permite o acesso ao aplicativo (ou seja, não faz nada)
- Se o risco do usuário for Médio, ele permite o acesso ao aplicativo, mas formata e envia uma mensagem do Slack para a equipe de administração
- Se o risco do usuário for Alto, ele remove a atribuição do usuário ao aplicativo.
Vamos percorrer o fluxo. Primeiro, temos um evento para indicar que um usuário, John Smith, foi adicionado ao aplicativo Okta Advanced Server Access.
Ele procura os detalhes de John e os grupos aos quais ele pertence para determinar seu risco.
Se John for de risco médio e, portanto, estiver no grupo de risco Médio correspondente (atribuído por Workflows quando seu risco mudou para Médio a partir de algum evento do Identity Threat Protection), uma mensagem será escrita no Slack.
Se John for de alto risco e estiver no grupo de alto risco correspondente, sua atribuição será revertida usando outra ação Okta.
Isso pode ser visto nos eventos de log do sistema Okta para o aplicativo (ou usuário).
Este é um exemplo bastante simples — e muito poderoso — de usar o risco do usuário para gerenciar o risco do aplicativo.
3. Verificação do risco do usuário na atribuição de aplicativo de alto risco com revisão de acesso do usuário
Em seguida, vamos estender o cenário anterior. Em vez de revogar automaticamente o acesso quando um usuário de alto risco recebe acesso a um aplicativo de alto risco, agora levantaremos uma Revisão de Acesso do Usuário no Okta Identity Governance.
O fluxo é basicamente o mesmo de antes, mas em vez de remover o acesso ao aplicativo na última etapa, o *workflow* criará e lançará uma revisão de acesso do usuário (certificação de acesso) usando a API Campaigns no Okta Identity Governance e o cartão de ação Custom API no Conector Okta (os detalhes estão enterrados em um fluxo auxiliar).
Como antes, quando o usuário é atribuído ao aplicativo, o nível de risco do usuário (Alto) encaminha o fluxo de trabalho para um fluxo auxiliar que cria o URL relativo e o requestBody necessários para criar e iniciar a campanha de Certificação de Acesso.
Isto é atribuído ao gerente do usuário para revisão e, quando o gerente faz login no Okta, ele vê que há uma campanha para revisar.
Ao verificar os detalhes, eles veem todos os aplicativos atribuídos a John Smith.
Eles revisam o acesso, decidem que John não precisa do aplicativo Okta Advanced Server Access e clicam no botão Revogar.
Isso causa a remoção do aplicativo, conforme mostrado nos eventos de log do sistema.
Esta abordagem oferece mais flexibilidade. Os usuários podem ter uma razão legítima para acessar um aplicativo de alto risco, então ter uma revisão de acesso do usuário por seu gerente é uma forma amigável à auditoria de gerenciá-lo (é claro, você poderia aplicar fluxos de Solicitação de Acesso, mas essa é uma conversa para outro artigo).
Ficar à frente do cenário de ameaças
Ao aproveitar esses recursos do Okta, você pode alcançar maior segurança e eficiência operacional, alinhando seus protocolos de segurança com seus objetivos de negócios. Seja aplicando o MFA para atividades suspeitas, desativando ou colocando em quarentena contas comprometidas ou notificando as equipes de segurança sobre possíveis violações, o Okta Identity Threat Protection e o Workflows permitem que sua organização permaneça resiliente contra ataques baseados em identidade.
À medida que navegamos pelas complexidades da segurança cibernética moderna, o Okta Identity Threat Protection com Okta AI se destaca como uma ferramenta crítica em seu arsenal de segurança. Ele protege melhor sua organização e aprimora sua capacidade de responder a ameaças de forma rápida e eficaz. Ao integrar esses serviços, você não está apenas acompanhando o cenário de ameaças em evolução — você está ficando à frente dele.
Abrace o futuro da segurança de identidade com o Okta e capacite sua organização a lidar com os desafios de hoje e de amanhã. Com o Okta Identity Threat Protection e o Okta Workflows, você pode proteger melhor seu cenário digital, ajudar a proteger seus ativos valiosos e buscar com confiança seus objetivos de negócios.
Saiba mais sobre o Okta Identity Threat Protection with Okta AI e o Okta Workflows.
Estes materiais são destinados apenas a fins informativos gerais e não se destinam a ser aconselhamento jurídico, de privacidade, de segurança, de conformidade ou de negócios.
