Övervaka, undersöka och åtgärda förhöjda riskfyllda användare

  • 16 minuter

Undersöka risk

Identity Protection ger organisationer tre rapporter som de kan använda för att undersöka identitetsrisker i sin miljö: riskfyllda användare, riskfyllda inloggningar och riskidentifieringar. Att undersöka händelser är nyckeln till att bättre förstå och identifiera eventuella svaga punkter i din säkerhetsstrategi.

Alla tre rapporterna tillåter nedladdning av händelser i . CSV-format för ytterligare analys utanför Azure Portal. Riskfyllda användare och riskfyllda inloggningsrapporter tillåter nedladdning av de senaste 2 500 posterna, medan riskidentifieringsrapporten tillåter nedladdning av de senaste 5 000 posterna.

Organisationer kan dra nytta av Microsoft Graph API-integreringar för att aggregera data med andra källor som de har åtkomst till som organisation.

Du hittar de tre rapporterna i administrationscentret för Microsoft Entra, sedan Identity och sedan Protection – Identity Protection.

Varje rapport startas med en lista över alla identifieringar för perioden som visas överst i rapporten. Varje rapport tillåter tillägg eller borttagning av kolumner baserat på administratörsinställningar. Administratörer kan välja att ladda ned data i . CSV eller . JSON-format. Rapporter kan filtreras med hjälp av filtren överst i rapporten.

Om du väljer enskilda poster kan du välja ytterligare poster överst i rapporten, till exempel möjligheten att bekräfta en inloggning som komprometterad eller säker, bekräfta en användare som komprometterad eller avvisa användarrisk.

Om du väljer enskilda poster expanderas ett informationsfönster under identifieringarna. Med informationsvyn kan administratörer undersöka och utföra åtgärder för varje identifiering.

Skärmbild av identitetsskyddsrapporten som visar riskfyllda inloggningar och information.

Riskfyllda användare

Med den information som tillhandahålls av rapporten över riskfyllda användare kan administratörer hitta:

  • Vilka användare är i riskzonen, har fått risk reparerad eller har fått risken avvisad?
  • Information om identifieringar.
  • Historik över alla riskfyllda inloggningar.
  • Riskhistorik.

Administratörer kan sedan välja att vidta åtgärder för dessa händelser. De kan välja att:

  • Återställ användarlösenordet.
  • Bekräfta att användaren har komprometterats.
  • Ignorera användarrisken.
  • Blockera användaren från att logga in.
  • Undersök ytterligare med Hjälp av Azure ATP.

Riskfyllda inloggningar

Rapporten riskfyllda inloggningar innehåller filterbara data i upp till de senaste 30 dagarna (en månad).

Med den information som tillhandahålls av rapporten över riskfyllda inloggningar kan administratörer hitta:

  • Vilka inloggningar klassificeras som riskfyllda, bekräftade komprometterade, bekräftade säkra, avvisade eller reparerade.
  • Realtids- och aggregerade risknivåer som är associerade med inloggningsförsök.
  • Identifieringstyper utlöses.
  • Principer för villkorsstyrd åtkomst tillämpas.
  • MFA-information.
  • Enhetsinformation.
  • Programinformation.
  • Platsinformation.

Administratörer kan sedan välja att vidta åtgärder för dessa händelser. Administratörer kan välja att:

  • Bekräfta inloggningskompromissen.
  • Bekräfta inloggningssäkert.

Riskidentifieringar

Rapporten för riskidentifiering innehåller filterbara data i upp till de senaste 90 dagarna (tre månader).

Med den information som tillhandahålls av riskidentifieringsrapporten kan administratörer hitta:

  • Information om varje riskidentifiering, inklusive typ.
  • Andra risker som utlöses samtidigt.
  • Inloggningsförsöksplats.

Administratörer kan sedan välja att återgå till användarens risk- eller inloggningsrapport för att vidta åtgärder baserat på insamlad information.

Rapporten för riskidentifiering innehåller också en klickbar länk till identifieringen i portalen Microsoft Defender för molnet Apps (MDCA) där du kan visa ytterligare loggar och aviseringar.

Kommentar

Vårt system upptäcker att den riskhändelse som bidrog till riskanvändarriskpoängen var en falsk positiv eller att användarrisken åtgärdades med principframtvingande, till exempel slutföra en MFA-prompt eller säker lösenordsändring. Därför kommer vårt system att avfärda risktillståndet, och en riskinformation om "AI-bekräftad inloggningssäker" kommer att dyka upp och bidrar inte längre till användarens risk.

Åtgärda risker och avblockera användare

När du har slutfört undersökningen vill du vidta åtgärder för att åtgärda risken eller avblockera användare. Organisationer har också möjlighet att aktivera automatiserad reparation med hjälp av sina riskprinciper. Organisationer bör försöka stänga alla riskidentifieringar som de presenteras med under en tidsperiod som din organisation är bekväm med. Microsoft rekommenderar att du stänger händelser så snart som möjligt eftersom tiden är viktig när man arbetar med risker.

Åtgärder

Alla aktiva riskidentifieringar bidrar till beräkningen av ett värde som kallas användarrisknivå. Användarrisknivån är en indikator (låg, medelhög, hög) för sannolikheten att ett konto har komprometterats. Som administratör vill du att alla riskidentifieringar ska stängas så att de berörda användarna inte längre är i riskzonen.

Vissa riskidentifieringar markeras av Identity Protection som "Stängd (system)" eftersom händelserna inte längre bedömdes vara riskfyllda.

Administratörer har följande alternativ att åtgärda:

  • Självreparation med riskprincip.
  • Manuell lösenordsåterställning.
  • Ignorera användarrisken.
  • Stäng enskilda riskidentifieringar manuellt.

Självreparation med riskprincip

Om du tillåter användare att självreparera, med multifaktorautentisering (MFA) och självbetjäning av lösenordsåterställning (SSPR) i dina riskprinciper, kan de avblockera sig själva när risken identifieras. Dessa identifieringar anses sedan vara stängda. Användare måste tidigare ha registrerat sig för MFA och SSPR för att kunna använda när risken identifieras.

Vissa identifieringar ökar inte risken till den nivå där en användares självreparation skulle krävas, men administratörer bör fortfarande utvärdera dessa identifieringar. Administratörer fastställer att ytterligare åtgärder krävs, till exempel att blockera åtkomst från platser eller minska den godkända risken i deras principer.

Manuell lösenordsåterställning

Om det inte är ett alternativ att kräva en lösenordsåterställning med en användarriskprincip kan administratörer stänga alla riskidentifieringar för en användare med en manuell lösenordsåterställning.

Administratörer får två alternativ när de återställer ett lösenord för sina användare:

Generera ett tillfälligt lösenord – Genom att generera ett tillfälligt lösenord kan du omedelbart återställa en identitet till ett säkert tillstånd. Den här metoden kräver att du kontaktar de berörda användarna eftersom de behöver veta vad det tillfälliga lösenordet är. Eftersom lösenordet är tillfälligt uppmanas användaren att ändra lösenordet till något nytt vid nästa inloggning.

Kräv att användaren återställer lösenordet – Att kräva att användarna återställer lösenord möjliggör självåterställning utan att kontakta supportavdelningen eller en administratör. Den här metoden gäller endast för användare som är registrerade för MFA och SSPR. För användare som inte har registrerats är det här alternativet inte tillgängligt.

Ignorera användarrisken

Om en lösenordsåterställning inte är ett alternativ för dig, till exempel eftersom användaren har tagits bort, kan du välja att stänga identifieringar av användarrisk.

När du väljer Ignorera användarrisk stängs alla händelser och den berörda användaren är inte längre utsatt för risker. Men eftersom den här metoden inte påverkar det befintliga lösenordet förs inte den relaterade identiteten tillbaka till ett säkert tillstånd.

Stänga enskilda riskidentifieringar manuellt

Genom att stänga enskilda riskidentifieringar manuellt kan du sänka användarrisknivån. Vanligtvis stängs riskidentifieringar manuellt som svar på en relaterad undersökning, till exempel när du pratar med en användare visar att en aktiv riskidentifiering inte längre krävs.

När du stänger riskidentifieringar manuellt kan du välja att vidta någon av följande åtgärder för att ändra statusen för en riskidentifiering:

  • Bekräfta att användaren har komprometterats.
  • Ignorera användarrisken.
  • Bekräfta inloggningssäkert.
  • Bekräfta att inloggningen har komprometterats.

Avblockera användare

En administratör väljer att blockera en inloggning baserat på deras riskprincip eller undersökningar. Ett block inträffar baserat på antingen inloggning eller användarrisk.

Avblockering baserat på användarrisk

Administratörer har följande alternativ för att avblockera ett konto som blockerats på grund av användarrisker:

  • Återställ lösenord – Du kan återställa användarens lösenord.
  • Stäng användarrisk – Principen för användarrisk blockerar en användare om den konfigurerade användarrisknivån för att blockera åtkomst har nåtts. Du kan minska en användares risknivå genom att stänga användarrisken eller manuellt stänga rapporterade riskidentifieringar.
  • Undanta användaren från policyn – Om du tycker att den aktuella konfigurationen av inloggningspolicyn leder till problem för specifika användare kan du utesluta användarna från den.
  • Inaktivera policy – Om du tycker att policykonfiguration leder till problem för alla användare kan du inaktivera policyn.

Avblockering baserat på inloggningsrisk

Administratörer kan avblockera ett konto som blockerats på grund av inloggningsrisk på följande sätt:

  • Logga in från en känd plats eller enhet – En vanlig anledning bakom blockeringar av misstänkta inloggningar är inloggningsförsök från okända platser eller enheter. Användarna kan snabbt avgöra om detta är orsaken bakom en blockering genom att försöka logga in från en känd plats eller enhet.
  • Undanta användaren från policyn – Om du tycker att den aktuella konfigurationen av inloggningspolicyn leder till problem för specifika användare kan du utesluta användarna från den.
  • Inaktivera policy – Om du tycker att policykonfiguration leder till problem för alla användare kan du inaktivera policyn.

Förhandsversion av PowerShell

Med förhandsversionen av Microsoft Graph PowerShell SDK kan organisationer hantera risker med hjälp av PowerShell. Förhandsgranskningsmodulerna och exempelkoden finns på Azure GitHub-lagringsplatsen.

Använda Microsoft Graph API

Microsoft Graph är Microsofts enhetliga API-slutpunkt och hem för API:er för Microsoft Entra Identity Protection. Det finns tre API:er som visar information om riskfyllda användare och inloggningar: riskDetection, riskyUsers, and signIn.

riskDetectiongör att du kan fråga Microsoft Graph om en lista över både användare och inloggningslänkade riskidentifieringar och tillhörande information om identifieringen.

riskyUsersgör att du kan fråga Microsoft Graph efter information om användare som Identity Protection har identifierat som riskfyllda.

signIn gör att du kan fråga Microsoft Graph om information om Inloggningar med Microsoft Entra-ID med specifika egenskaper som rör risktillstånd, information och nivå.

I det här avsnittet kommer du igång med att ansluta till Microsoft Graph och köra frågor mot dessa API:er. En djupgående introduktion, fullständig dokumentation och åtkomst till Graph Explorer finns på Microsoft Graph-webbplatsen (https://graph.microsoft.io/) eller den specifika referensdokumentationen för API:erna riskDetection, riskyUsers, and signIn .

Ansluta till Microsoft Graph

Det finns fyra steg för att komma åt Identity Protection-data via Microsoft Graph: hämta domännamnet, skapa en ny appregistrering, konfigurera API-behörigheter och konfigurera en giltig autentiseringsuppgift.

Hämta domännamnet

  1. Logga in på administrationscentret för Microsoft Entra.
  2. Bläddra till Identitet, öppna sedan Inställningar och välj Domännamn.
  3. Anteckna domänen .onmicrosoft.com. Du behöver den här informationen i ett senare steg.

Skapa en ny appregistrering

  1. I administrationscentret för Microsoft Entra bläddrar du till Identitet och Program och Appregistreringar sedan.

  2. Välj Ny registrering.

  3. Utför följande steg på sidan Skapa :

    1. I textrutan Namn skriver du ett namn för ditt program (till exempel Microsoft Entra Risk Detection API).
    2. Under Kontotyper som stöds väljer du den typ av konton som ska använda API:erna.
    3. Välj Registrera.

  4. Kopiera App-ID.

Konfigurera API-behörigheter

  1. Välj API-behörigheter i programmet som du skapade.

  2. På sidan Konfigurerade behörigheter går du till verktygsfältet längst upp och väljer Lägg till en behörighet.

  3. På sidan Lägg till API-åtkomst väljer du Välj ett API.

  4. På sidan Välj ett API väljer du Microsoft Graph och sedan Välj.

  5. På sidan API-behörigheter för begäran:

    1. Välj Programbehörigheter.
    2. Markera kryssrutorna bredvid IdentityRiskEvent.Read.All och IdentityRiskyUser.Read.All.
    3. Välj Lägg till behörigheter.

  6. Välj Bevilja administratörsmedgivande för domän.

Konfigurera en giltig autentiseringsuppgift

  1. I programmet som du skapade väljer du Certifikat och hemligheter.

  2. Under Klienthemligheter väljer du Ny klienthemlighet.

    1. Ge klienthemligheten en Beskrivning och ange förfallotiden enligt organisationens principer.

    2. Markera Lägga till.

      Kommentar

      Om du förlorar den här nyckeln måste du gå tillbaka till det här avsnittet och skapa en ny nyckel. Behåll den här nyckeln som en hemlighet: Alla som har den kan komma åt dina data.

Autentisera till Microsoft Graph och fråga Identity Protection-riskidentifierings-API:et

Nu bör du ha:

  • Namnet på klientorganisationens domän
  • Program-ID :t (klient)
  • Klienthemligheten eller certifikatet

För att autentisera skickar du en postbegäran till https://login.microsoft.com med följande parametrar i brödtexten:

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

Om det lyckas returnerar den här begäran en autentiseringstoken. Om du vill anropa API:et skapar du en rubrik med följande parameter:

Authorization`="<token_type> <access_token>"

När du autentiserar kan du hitta tokentypen och åtkomsttoken i den returnerade token.

Skicka det här huvudet som en begäran till följande API-URL: https://graph.microsoft.com/v1.0/identityProtection/riskDetections.

Svaret, om det lyckas, är en samling identitetsriskidentifieringar och associerade data i OData JSON-format, som kan parsas och hanteras som du vill.

Exempel

Det här exemplet visar användningen av en delad hemlighet för att autentisera. I en produktionsmiljö är lagring av hemligheter i kod vanligtvis rynkade på pannan. Organisationer kan använda hanterade identiteter för Azure-resurser för att skydda dessa autentiseringsuppgifter.

Här är exempelkoden för att autentisera och anropa API:et med hjälp av PowerShell. Lägg bara till ditt klient-ID, den hemliga nyckeln och klientdomänen.

    $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"

    }

Hämta alla offlineriskidentifieringar (riskDetection API)

Med principer för inloggningsrisk i Identity Protection kan du tillämpa villkor när risker identifieras i realtid. Men hur är det med identifieringar som identifieras offline? För att förstå vilka identifieringar som inträffade offline och därför inte skulle ha utlöst inloggningsriskprincipen kan du fråga API:et riskDetection .

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

Hämta alla användare som har klarat en MFA-utmaning som utlöses av en riskfylld inloggningsprincip (riskyUsers API)

För att förstå värdet Identity Protection riskbaserade principer för din organisation kan du fråga alla användare som har klarat en MFA-utmaning som utlöses av en riskfylld inloggningsprincip. Den här informationen kan hjälpa dig att förstå vilka användare Identity Protection felaktigt har identifierat som en risk och vilka av dina legitima användare som utför åtgärder som AI:n anser vara riskfyllda.

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