Sinais de exposição verificados para decisões sobre riscos de identidade

Antes de começar

• Acesso como titular da conta LeakData, com acesso à integração Enterprise SIEM. Contas de usuários adicionais não podem configurar a conexão.
• Um administrador do Okta que possa instalar e autorizar integrações de serviço de API e uma organização com suporte ao receptor Shared Signals. O Identity Threat Protection é necessário para os recursos correspondentes de políticas de risco.
• Um monitor de e-mail pessoal ativo cujo endereço tenha a titularidade verificada ou pertença a um dos seus domínios verificados. Para testar um sinal assinado, use um usuário de exemplo sob seu controle com o mesmo e-mail em uma organização de teste do Okta.

1. Instale e autorize no Okta

A inclusão no catálogo público está pendente. Se o LeakData não estiver disponível no seu catálogo, entre em contato com o suporte para saber o procedimento atual de configuração antes de continuar.

1. Abra Aplicativos e recursos > Integrações de serviço de API no console de administração do Okta e instale o LeakData Shared Signals quando ele estiver disponível no seu catálogo.
2. Autorize apenas okta.securityEventsProviders.manage. Copie imediatamente o segredo do cliente, exibido uma única vez, e registre o ID do cliente e o domínio Okta dessa mesma instância.
3. Use a origem não personalizada da organização, como https://integrator-1234567.okta.com. Remova -admin, caminhos, strings de consulta e números de porta.

Essas credenciais vêm de uma integração de serviço de API OIN instalada. Um token de API ou um aplicativo genérico de serviço OAuth criado por meio de Criar integração de aplicativo não fornece a mesma configuração de ID e segredo do cliente OIN.

2. Conecte no LeakData

1. Entre como titular da conta e abra Painel > Integrações > Okta Shared Signals.
2. Insira a URL da organização, o ID do cliente e o segredo do cliente da mesma instância autorizada. Escolha Alta e crítica ou Apenas crítica.
3. Leia e confirme a restrição a endereços verificados e o efeito das suas políticas de risco do Okta. Em seguida, selecione Conectar Okta. O LeakData verifica as credenciais e cria ou reutiliza seu provedor de eventos de segurança.
4. Após a configuração, o provedor fica ativo. O LeakData criptografa o segredo e não o exibe novamente.

3. Verifique a conexão

1. Selecione Verificar conexão para verificar as credenciais e o estado do provedor sem enviar um sinal de risco. Confirme que o provedor está ativo e que há um ID do provedor em Detalhes da conexão.
2. Confira os monitores de e-mail elegíveis. Apenas endereços de e-mail exatos com titularidade verificada ou pertencentes a um dos seus domínios verificados são elegíveis; o monitor de domínio em si nunca é enviado.
3. Em uma conta dedicada de teste/QA e em uma organização Okta Integrator sob seu controle, confira o e-mail de exemplo e a confirmação de ciência sobre as políticas antes de usar Testar um sinal assinado. Esse teste pode acionar as políticas de risco configuradas.
4. HTTP 202 confirma apenas a aceitação. Confira no log do sistema do Okta os eventos security.events.provider.receive_event e user.risk.detect para seu usuário de exemplo. Um e-mail desconhecido pode ser ignorado sem aviso.

4. Substitua as credenciais ou altere a organização

1. Para a mesma organização, selecione Substituir credenciais e insira um novo par de ID e segredo do cliente de uma instância autorizada de serviço de API do LeakData nessa organização. Ao salvar, a conexão é verificada e ativada.
2. Pausar envio mantém o vínculo com a organização e as credenciais salvas. Essa ação não prepara a conta para outra organização.
3. Para retomar o envio para a mesma organização, selecione Iniciar envio e depois Verificar conexão. Confirme que o provedor está ativo.
4. Para usar outra organização, confira primeiro a opção Remover conexão. Ao confirmar a remoção, o provedor, as credenciais criptografadas e o histórico local de envios são excluídos. Em seguida, configure a nova organização. Se a remoção falhar, entre em contato com o suporte; não presuma que o provedor antigo foi removido.

Solução de problemas

Credenciais rejeitadas

Confira se os três valores vêm da mesma instância de serviço de API OIN instalada e autorizada. Durante a análise, use uma instância da versão atualmente enviada. Tokens de API e credenciais de aplicativos genéricos de serviço OAuth não podem substituir as credenciais dessa configuração.

Permissão ou acesso ao receptor negado

Confirme que okta.securityEventsProviders.manage foi autorizado e que sua organização Okta oferece suporte ao receptor SSF. Confira o acesso de administrador e as políticas da organização.

Já conectado a outra organização

Substitua as credenciais apenas para a organização exibida. Pausar não remove a conexão. Confira as etapas de remoção acima antes de alterar a organização.

Sem sinal ou sem evento de risco do usuário

Confira se o endereço tem a titularidade verificada ou pertence a um domínio verificado, se o monitor pessoal está ativo e se o achado de segurança foi verificado e tem gravidade alta ou crítica. Confira também o limite de gravidade selecionado. A aceitação pelo receptor, por si só, não comprova a correspondência com um usuário nem a execução de uma ação de política.

Precisa de ajuda?

Entre em contato com o suporte do LeakData e informe a operação que falhou e o código de erro. Não inclua senhas, segredos do cliente nem tokens de acesso.