Monitorar, investigar e corrigir usuários arriscados com privilégios elevados

  • 16 minutos

Investigar risco

O Identity Protection fornece às organizações três relatórios que elas podem usar para investigar os riscos de identidade nos ambientes: usuários suspeitos, entradas suspeitas e detecções de risco. A investigação de eventos é a chave para uma melhor compreensão e identificação dos pontos fracos em sua estratégia de segurança.

Todos os três relatórios permitem o download de eventos no formato CSV para análise adicional fora do portal do Azure. Os relatórios de usuários suspeitos e de entradas suspeitas permitem baixar as 2,500 entradas mais recentes, e o relatório de detecções de risco permite baixar os 5,000 registros mais recentes.

As organizações podem aproveitar as integrações da API do Microsoft Graph para agregar dados a outras fontes às quais têm acesso como organização.

Você pode encontrar os três relatórios no centro de administração do Microsoft Entra, em seguida, Identidade e, em seguida, Proteção – proteção de identidade.

Cada relatório é iniciado com uma lista de todas as detecções do período que aparece na parte superior do relatório. Cada relatório permite a adição ou a remoção de colunas com base na preferência do administrador. Os administradores podem optar por baixar os dados no formato .CSV ou .JSON. Os relatórios podem ser filtrados usando-se os filtros na parte superior do relatório.

Selecionar entradas individuais permite entradas adicionais na parte superior do relatório, como a capacidade de confirmar uma entrada como comprometida ou segura, confirmar um usuário como comprometido ou descartar o risco do usuário.

A seleção de entradas individuais expande uma janela de detalhes abaixo das detecções. A exibição de detalhes permite que os administradores investiguem e executem ações em cada detecção.

Captura de tela do relatório do Identity Protection mostrando entradas suspeitas e detalhes.

Usuários de risco

Com as informações fornecidas pelo relatório de usuários suspeitos, os administradores podem descobrir:

  • Quais usuários estão em risco, tiveram o risco corrigido ou tiveram o risco ignorado?
  • Detalhes sobre as detecções.
  • Histórico de todas as entradas suspeitas.
  • Histórico de risco.

Depois, os administradores poderão optar por tomar medidas sobre esses eventos. Eles podem optar por:

  • Redefinir a senha do usuário.
  • Confirmar usuário comprometido.
  • Ignorar o risco de usuário.
  • Bloquear a entrada de um usuário.
  • Investigar mais usando o ATP do Azure.

Entradas de risco

O relatório de entradas suspeitas contém dados filtráveis para até os últimos 30 dias (1 mês).

Com as informações fornecidas pelo relatório de entradas suspeitas, os administradores podem descobrir:

  • Quais entradas são classificadas como em risco, comprometimento confirmado, segurança confirmada, ignoradas ou corrigidas.
  • Níveis de risco agregados e em tempo real associados a tentativas de entrada.
  • Tipos de detecção disparados.
  • Políticas de acesso condicional aplicadas.
  • Detalhes da Autenticação Multifator.
  • Informações do dispositivo.
  • Informações do aplicativo.
  • Informações de localização.

Depois, os administradores poderão optar por tomar medidas sobre esses eventos. Os administradores podem escolher:

  • Confirmar entrada comprometida.
  • Confirmar entrada segura.

Detecções de risco

O relatório de detecções de risco contém dados filtráveis para até os últimos 90 dias (3 meses).

Com as informações fornecidas pelo relatório de detecções de risco, os administradores podem descobrir:

  • Informações sobre cada detecção de risco, incluindo o tipo.
  • Outros riscos disparados ao mesmo tempo.
  • Local da tentativa de entrada.

Depois, os administradores poderão optar por retornar ao relatório de risco ou de entradas do usuário para executar ações com base nas informações coletadas.

O relatório de detecção de risco também fornece um link clicável para a detecção no portal do MDCA (Microsoft Defender for Cloud Apps), no qual você pode exibir logs e alertas adicionais.

Observação

Nosso sistema detecta que o evento de risco que contribuiu para a pontuação de risco do usuário de risco era um falso positivo ou que o risco do usuário foi corrigido com a imposição de política, como a conclusão de um prompt de MFA ou uma alteração de senha segura. Portanto, nosso sistema ignorará o estado de risco, e um detalhe de risco de "segurança de entrada confirmada por IA" será exibido e não contribuirá mais para o risco do usuário.

Corrigir riscos e desbloquear usuários

Depois de concluir uma investigação, você deverá tomar medidas para corrigir o risco ou desbloquear os usuários. As organizações também têm a opção de habilitar a correção automatizada usando suas políticas de risco. As organizações devem tentar fechar todas as detecções de riscos com as quais elas são apresentadas em um período que seja confortável para sua organização. A Microsoft recomenda o fechamento dos eventos rapidamente, pois o tempo é essencial quando se lida com riscos.

Remediação

Todos os eventos de risco ativos contribuem para o cálculo de um nível de risco do usuário chamado valor. O nível de risco do usuário é um indicador (baixo, médio, alto) para a probabilidade de que uma conta tenha sido comprometida. Como administrador, você deseja fechar todos os eventos de risco de modo que os usuários afetados não estejam mais em risco.

Algumas detecções de risco são marcadas pelo Identity Protection como "Fechado (sistema)" porque os eventos não foram mais determinados como arriscados.

Os administradores têm as seguintes opções para corrigir:

  • Correção automática com a política de risco.
  • Redefinição de senha manual.
  • Ignorar o risco de usuário.
  • Fechar detecções de risco individuais manualmente.

Correção automática com a política de risco

Se você permitir que os usuários resolvam os problemas de forma autônoma, com autenticação multifator (MFA) e redefinição de senha self-service (SSPR) em suas políticas de risco, eles poderão se desbloquear quando riscos forem detectados. Essas detecções são consideradas fechadas. Os usuários devem ter se registrado anteriormente para MFA e SSPR para usá-las quando o risco é detectado.

Algumas detecções não aumentam o risco para o nível em que uma autocorreção do usuário seria necessária, mas os administradores ainda devem avaliar essas detecções. Os administradores determinam que medidas adicionais são necessárias, como bloquear o acesso de locais ou reduzir o risco aceitável em suas políticas.

Redefinição de senha manual

Se exigir uma redefinição de senha usando uma política de risco do usuário não for uma opção, os administradores poderão fechar todas as detecções de risco para um usuário com uma redefinição de senha manual.

Os administradores recebem duas opções ao redefinir uma senha para seus usuários:

Gerar uma senha temporária – ao gerar uma senha temporária, você pode imediatamente deixar uma identidade em um estado seguro novamente. Esse método requer interação com os usuários afetados, pois eles precisarão saber qual é a senha temporária. Como a senha é temporária, o usuário é solicitado a alterar a senha para algo novo durante a próxima entrada.

Exigir que o usuário redefina a senha – exigir que os usuários redefinam senhas permite a autorrecuperação sem entrar em contato com o suporte técnico nem com o administrador. Esse método só se aplica aos usuários registrados para MFA e SSPR. Essa opção não está disponível para usuários que não estão registrados.

Ignorar o risco de usuário

Se uma redefinição de senha não for uma opção para você porque, por exemplo, o usuário foi excluído, você poderá optar por ignorar as detecções de risco do usuário.

Quando você selecionar Ignorar risco do usuário, todos os eventos serão fechados e o usuário afetado não estará mais em risco. No entanto, como esse método não tem um impacto sobre a senha existente, ele não deixa a identidade relacionada em um estado seguro novamente.

Fechar detecções de risco individuais manualmente

Ao fechar eventos de risco manualmente, você pode diminuir o nível de risco do usuário. Normalmente, as detecções de risco são fechadas manualmente em resposta a uma investigação relacionada, por exemplo, quando conversar com um usuário revela que uma detecção de risco ativa não é mais necessária.

Ao fechar as detecções de risco manualmente, você pode optar por executar qualquer uma das seguintes ações para alterar o status de uma detecção de risco:

  • Confirmar usuário comprometido.
  • Ignorar o risco de usuário.
  • Confirmar entrada segura.
  • Confirmar entrada comprometida.

Desbloqueando usuários

Um administrador opta por bloquear uma entrada com base em suas investigações ou políticas de risco. Um bloco ocorre com base no risco de entrada ou de usuário.

Desbloqueio com base no risco do usuário

Para desbloquear uma conta bloqueada devido ao risco do usuário, os administradores têm as seguintes opções:

  • Redefinir senha - você pode redefinir a senha do usuário.
  • Ignorar risco do usuário – a política de risco do usuário bloqueia um usuário se o nível de risco do usuário configurado para bloquear o acesso tiver sido atingido. Você pode reduzir o nível de risco de um usuário ignorando o risco do usuário ou fechando manualmente as detecções de risco relatadas.
  • Excluir o usuário da política – se você acredita que a configuração atual da sua política de entrada está causando problemas para usuários específicos, você pode excluir os usuários dele.
  • Desabilitar política - se você achar que sua configuração de política está causando problemas para todos os usuários, poderá desabilitar a política.

Desbloqueio com base no risco de entrada

Para desbloquear uma conta baseada em risco de entrada, os administradores têm as seguintes opções:

  • Entrada de um local ou dispositivo familiar – uma razão comum para entradas suspeitas bloqueadas são as tentativas de entrada de locais ou de dispositivos desconhecidos. Os usuários podem determinar rapidamente se esse é o motivo do bloqueio, ao tentar entrar de um dispositivo ou local familiar.
  • Excluir o usuário da política – se você acredita que a configuração atual da sua política de entrada está causando problemas para usuários específicos, você pode excluir os usuários dele.
  • Desabilitar política - se você achar que sua configuração de política está causando problemas para todos os usuários, poderá desabilitar a política.

PowerShell (versão prévia)

Ao usar o módulo de versão prévia do SDK do Microsoft Graph PowerShell, as organizações podem gerenciar riscos usando o PowerShell. Os módulos de visualização e o código de exemplo estão localizados no repositório GitHub do Azure.

Usar a API do Microsoft Graph

O Microsoft Graph é o ponto de extremidade de API unificado da Microsoft e a base das APIs do Microsoft Entra Identity Protection. Há três APIs que expõem informações sobre entradas e usuários arriscados: riskDetection, riskyUsers, and signIn.

riskDetection permite que você consulte o Microsoft Graph para obter uma lista de detecções de risco vinculadas de usuários e de entrada e as informações associadas sobre a detecção.

riskyUsers permite que você consulte o Microsoft Graph para obter informações sobre os usuários que o Identity Protection detectou como suspeitos.

signIn permite que você consulte o Microsoft Graph para obter informações sobre as entradas do Microsoft Entra ID com propriedades específicas relacionadas ao estado de risco, aos detalhes e ao nível.

Este artigo é uma introdução para conectar o Microsoft Graph e consultar essas APIs. Para obter uma introdução detalhada, documentação completa e acesso ao Explorador do Graph, confira o site do Microsoft Graph (https://graph.microsoft.io/) ou a documentação de referência específica para as APIs de riskDetection, riskyUsers, and signIn.

Conectar o Microsoft Graph

Há quatro etapas para acessar dados do Identity Protection por meio de Microsoft Graph: recuperar seu nome de domínio, criar um novo registro de aplicativo, configurar permissões de API e configurar uma credencial válida.

Recuperar seu nome de domínio

  1. Entre no Centro de administração do Microsoft Entra.
  2. Navegue até Identidade, abra Configurações e selecione Nomes de domínio.
  3. Anote o domínio .onmicrosoft.com. Você precisará dessas informações em uma etapa posterior.

Criar um novo registro de aplicativo

  1. No centro de administração do Microsoft Entra, navegue até Identidade e aplicativos e, em seguida, Registros de aplicativo.

  2. Selecione Novo registro.

  3. Na página Criar, siga as seguintes etapas:

    1. Na caixa de texto Nome, digite um nome para seu aplicativo (por exemplo: API de detecção de risco do Microsoft Entra).
    2. Em Tipos de conta com suporte, selecione o tipo de contas que usarão as APIs.
    3. Selecione Registrar.

  4. Copie a ID do aplicativo.

Configure as permissões da API

  1. No aplicativo que você criou, selecione permissões de API.

  2. Na página Permissões configuradas, na barra de ferramentas na parte superior, selecione Adicionar uma permissão.

  3. Na página Adicionar acesso à API, escolha Selecionar uma API.

  4. Na página Selecionar uma API, selecione Microsoft Graph e, então, selecione Selecionar.

  5. Na página Solicitar permissões de API:

    1. Selecione Permissões de aplicativo.
    2. Marque as caixas de seleção ao lado de IdentityRiskEvent.Read.All e IdentityRiskyUser.Read.All.
    3. Selecione Adicionar Permissões.

  6. Selecione Fornecer o consentimento do administrador para domínio.

Configure uma credencial válida

  1. Do Aplicativo que você criou, selecione Certificados e segredos.

  2. Em Segredos do cliente, selecione Novo segredo do cliente.

    1. Dê uma Descrição ao segredo do cliente e defina o período de expiração de acordo com as políticas organizacionais.

    2. Selecione Adicionar.

      Observação

      Se você perder esta chave, precisará retornar a esta seção e criar uma chave. Mantenha essa chave em segredo: qualquer pessoa que a tenha poderá acessar seus dados.

Autenticar-se no Microsoft Graph e consultar a API de detecção do risco do Identity Protection

Neste ponto, você deve ter:

  • O nome do domínio do locatário
  • A ID do cliente do aplicativo
  • O segredo ou certificado do cliente

Para autenticar, envie uma solicitação post para https://login.microsoft.com com os seguintes parâmetros no corpo:

  • grant_type: client_credentials
  • resource: https://graph.microsoft.com
  • client_id:
  • client_secret:

Se for bem-sucedida, essa solicitação retornará um token de autenticação. Para chamar a API, crie um cabeçalho com o seguinte parâmetro:

Authorization`="<token_type> <access_token>"

Durante a autenticação, você poderá encontrar o tipo de token e o token de acesso no token retornado.

Envie este cabeçalho como uma solicitação para a seguinte URL de API: https://graph.microsoft.com/v1.0/identityProtection/riskDetections.

A resposta, se for bem-sucedida, é um conjunto de detecções de risco de identidade e dados associados no formato OData JSON, que pode ser analisado e manipulado da maneira que você achar adequado.

Amostra

Este exemplo mostra o uso de um segredo compartilhado para autenticar. Em um ambiente de produção, o armazenamento de segredos no código geralmente é triste. As organizações podem usar identidades gerenciadas para recursos do Azure para proteger essas credenciais.

Veja um código de exemplo para autenticação e chamada da API usando o PowerShell. Basta adicionar sua ID do cliente, a chave secreta e o domínio do locatário.

    $ClientID      = "<your client ID here>"        # Should be a ~36 hex character string; insert your info here

    $ClientSecret  = "<your client secret here>"    # Should be a ~44 character string; insert your info here

    $tenantdomain  = "<your tenant domain here>"    # For example, contoso.onmicrosoft.com

    $loginURL      = "https://login.microsoft.com"

    $resource      = "https://graph.microsoft.com"

    $body          = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}

    $oauth        = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body

    Write-Output $oauth

    if ($oauth.access_token -ne $null) {

        $headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}

        $url = "https://graph.microsoft.com/v1.0/identityProtection/riskDetections"

        Write-Output $url

        $myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)

        foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {

            Write-Output $event

        }

    } else {

        Write-Host "ERROR: No Access Token"

    }

Obter todas as detecções de riscos offline (API riskDetection)

Com as políticas de risco de entrada do Identity Protection, você pode aplicar condições quando o risco for detectado em tempo real. Mas e quanto às detecções descobertas offline? Para entender quais detecções ocorreram offline e, portanto, não teriam disparado a política de risco de entrada, você pode consultar a API riskDetection.

GET https://graph.microsoft.com/v1.0/identityProtection/riskDetections?$filter=detectionTimingType eq 'offline'

Obter todos os usuários que concluíram com êxito um desafio MFA disparado por uma política de entradas arriscadas (API riskyUsers)

Para reconhecer o impacto que as políticas baseadas em risco do Identity Protection têm em sua organização, você pode consultar todos os usuários que concluíram com êxito um desafio MFA disparado por uma política de entrada suspeita. Essas informações podem ajudar você a entender quais usuários o Identity Protection detectou falsamente como um risco e quais dos usuários legítimos estão executando ações que a IA considera arriscadas.

GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers?$filter=riskDetail eq 'userPassedMFADrivenByRiskBasedPolicy'