Verhoogde riskante gebruikers bewaken, onderzoeken en herstellen

  • 16 minuten

Risico onderzoeken

Identity Protection biedt organisaties drie rapporten die ze kunnen gebruiken om identiteitsrisico's in hun omgeving te onderzoeken: riskante gebruikers, riskante aanmeldingen en risicodetecties. Het onderzoeken van gebeurtenissen is essentieel om eventuele zwakke punten in uw beveiligingsstrategie beter te begrijpen en te identificeren.

Met alle drie de rapporten kunt u gebeurtenissen in CSV-indeling downloaden voor verdere analyse buiten Azure Portal. De riskante gebruikers en riskante aanmeldingsrapporten maken het downloaden van de meest recente 2500 vermeldingen mogelijk, terwijl in het rapport risicodetecties de meest recente 5000 records kunnen worden gedownload.

Organisaties kunnen profiteren van de Microsoft Graph API-integraties om gegevens samen te voegen met andere bronnen waar ze toegang toe hebben als organisatie.

U vindt de drie rapporten in het Microsoft Entra-beheercentrum, vervolgens Identity en vervolgens Protection - Identity Protection.

Elk rapport begint met een lijst met alle detecties voor de periode die boven aan het rapport wordt weergegeven. In elk rapport kunnen kolommen worden toegevoegd of verwijderd op basis van beheerdersvoorkeur. Beheerders kunnen ervoor kiezen om de gegevens te downloaden in CSV- of JSON-indeling. Rapporten kunnen worden gefilterd met behulp van de filters bovenaan het rapport.

Als u afzonderlijke vermeldingen selecteert, worden extra vermeldingen boven aan het rapport ingeschakeld, zoals de mogelijkheid om een aanmelding te bevestigen als gecompromitteerd of veilig, een gebruiker te bevestigen als gecompromitteerd of gebruikersrisico te negeren.

Als u afzonderlijke vermeldingen selecteert, wordt een detailvenster onder de detecties uitgevouwen. Met de detailweergave kunnen beheerders acties voor elke detectie onderzoeken en uitvoeren.

Schermopname van het Rapport Identity Protection met riskante aanmeldingen en details.

Riskante gebruikers

Met de verstrekte informatie in het rapport met riskante gebruikers kunnen beheerders het volgende vinden:

  • Welke gebruikers lopen risico, hebben risico's gehad die zijn opgelost of hebben risico's gehad die zijn gesloten?
  • Details over detecties.
  • Geschiedenis van alle riskante aanmeldingen.
  • Risicogeschiedenis.

Beheerders kunnen er vervolgens voor kiezen om actie te ondernemen voor deze gebeurtenissen. Hij heeft de volgende keuzen:

  • Stel het gebruikerswachtwoord opnieuw in.
  • Bevestig inbreuk op de gebruiker.
  • Het gebruikersrisico negeren.
  • Blokkeren dat de gebruiker zich aanmeldt.
  • Onderzoek verder met behulp van Azure ATP.

Riskante aanmeldingen

Het rapport met riskante aanmeldingen bevat te filteren gegevens voor de afgelopen 30 dagen (één maand).

Met de verstrekte informatie in het rapport met riskante aanmeldingen kunnen beheerders het volgende vinden:

  • Welke aanmeldingen zijn geclassificeerd als riskant, bevestigd gecompromitteerd, bevestigd veilig, gesloten of opgelost.
  • Realtime- en aggregatierisiconiveaus die zijn gekoppeld aan aanmeldingspogingen.
  • Detectietypen geactiveerd.
  • Beleid voor voorwaardelijke toegang toegepast.
  • MFA-details.
  • Apparaatgegevens.
  • Toepassingsgegevens.
  • Locatiegegevens.

Beheerders kunnen er vervolgens voor kiezen om actie te ondernemen voor deze gebeurtenissen. Beheerders kunnen kiezen voor het volgende:

  • Bevestig aanmeldingscompromitt.
  • Bevestig het aanmelden veilig.

Risicodetectie

Het rapport met risicodetecties bevat filterbare gegevens voor de afgelopen 90 dagen (drie maanden).

Met de verstrekte informatie in het rapport met riskante risicodetecties kunnen beheerders het volgende vinden:

  • Informatie over elke risicodetectie, inclusief het type.
  • Andere risico's die tegelijkertijd worden geactiveerd.
  • Locatie van aanmeldingspoging.

Beheerders kunnen er vervolgens voor kiezen om terug te keren naar het risico- of aanmeldingsrapport van de gebruiker om actie te ondernemen op basis van verzamelde gegevens.

Het rapport over risicodetectie biedt ook een klikbare koppeling naar de detectie in de MDCA-portal (Microsoft Defender voor Cloud Apps), waar u extra logboeken en waarschuwingen kunt bekijken.

Notitie

Ons systeem detecteert dat de risicogebeurtenis die heeft bijgedragen aan de risicoscore van de gebruiker een fout-positief is of dat het gebruikersrisico is hersteld met het afdwingen van beleid, zoals het voltooien van een MFA-prompt of een veilige wachtwoordwijziging. Daarom zal ons systeem de risicostatus negeren en zal een risicodetail van 'AI bevestigd aanmeldingsveilig' opduiken en niet langer bijdragen aan het risico van de gebruiker.

Risico's herstellen en gebruikers deblokkeren

Nadat u uw onderzoek hebt voltooid, moet u actie ondernemen om het risico te verhelpen of de blokkering van gebruikers op te heffen. Organisaties hebben ook de mogelijkheid om geautomatiseerd herstel in te stellen met behulp van hun risicobeleid. Organisaties moeten proberen alle risicodetecties te sluiten waarmee ze worden gepresenteerd in een bepaalde periode waarmee uw organisatie vertrouwd is. Microsoft raadt aan gebeurtenissen zo snel mogelijk te sluiten omdat snelheid belangrijk is bij het werken met risico's.

Herstel

Alle actieve risicodetecties dragen bij aan de berekening van een waarde met de naam gebruikersrisiconiveau. Het risiconiveau van de gebruiker is een indicator (laag, gemiddeld, hoog) voor de waarschijnlijkheid dat een account is aangetast. Als beheerder wilt u alle risicodetecties sluiten, zodat de betrokken gebruikers geen risico meer lopen.

Sommige risicodetecties worden gemarkeerd door Identity Protection als 'Gesloten (systeem)' omdat de gebeurtenissen niet langer riskant zijn.

Beheerders hebben de volgende opties om te herstellen:

  • Zelfherstel met risicobeleid.
  • Handmatig wachtwoord opnieuw instellen.
  • Het gebruikersrisico negeren.
  • Sluit afzonderlijke risicodetecties handmatig.

Zelfherstel met risicobeleid

Als u gebruikers toestaat om zelf te herstellen, met meervoudige verificatie (MFA) en selfservice voor wachtwoordherstel (SSPR) in uw risicobeleid, kunnen ze zichzelf deblokkeren wanneer er risico's worden gedetecteerd. Deze detecties worden vervolgens als gesloten beschouwd. Gebruikers moeten zich eerder hebben geregistreerd voor MFA en SSPR om te kunnen gebruiken wanneer er risico's worden gedetecteerd.

Sommige detecties veroorzaken geen risico op het niveau waarop een gebruiker zelfherstel vereist is, maar beheerders moeten deze detecties nog steeds evalueren. Beheerders bepalen dat er aanvullende maatregelen nodig zijn, zoals het blokkeren van de toegang vanaf locaties of het verlagen van het acceptabele risico in hun beleid.

Handmatig wachtwoord opnieuw instellen

Als het vereisen van wachtwoordherstel met een beleid voor gebruikersrisico's geen optie is, kunnen beheerders alle risicodetecties voor een gebruiker sluiten met een handmatig wachtwoord opnieuw instellen.

Beheerders krijgen twee opties bij het opnieuw instellen van een wachtwoord voor hun gebruikers:

Een tijdelijk wachtwoord genereren: door een tijdelijk wachtwoord te genereren, kunt u onmiddellijk een identiteit weer in een veilige status brengen. Voor deze methode moet contact worden opgenomen met de betrokken gebruikers, omdat ze moeten weten wat het tijdelijke wachtwoord is. Omdat het wachtwoord tijdelijk is, wordt de gebruiker gevraagd het wachtwoord te wijzigen in iets nieuws tijdens de volgende aanmelding.

Vereisen dat de gebruiker het wachtwoord opnieuw instelt: de gebruikers verplichten om wachtwoorden opnieuw in te stellen, maakt zelfherstel mogelijk zonder contact op te leggen met de helpdesk of een beheerder. Deze methode is alleen van toepassing op gebruikers die zijn geregistreerd voor MFA en SSPR. Voor gebruikers die niet zijn geregistreerd, is deze optie niet beschikbaar.

Gebruikersrisico negeren

Als het opnieuw instellen van een wachtwoord geen optie voor u is, omdat de gebruiker bijvoorbeeld is verwijderd, kunt u ervoor kiezen om detecties van gebruikersrisico's te negeren.

Wanneer u Gebruikersrisico negeren selecteert, worden alle gebeurtenissen gesloten en loopt de betrokken gebruiker geen risico meer. Omdat deze methode echter geen invloed heeft op het bestaande wachtwoord, wordt de gerelateerde identiteit niet weer in een veilige status gebracht.

Afzonderlijke risicodetecties handmatig sluiten

Door afzonderlijke risicodetecties handmatig te sluiten, kunt u het risiconiveau van de gebruiker verlagen. Risicodetecties worden doorgaans handmatig gesloten als reactie op een gerelateerd onderzoek, zoals wanneer u met een gebruiker praat, blijkt dat een actieve risicodetectie niet meer vereist is.

Wanneer u risicodetecties handmatig sluit, kunt u ervoor kiezen om een van de volgende acties uit te voeren om de status van een risicodetectie te wijzigen:

  • Bevestig dat de gebruiker is gecompromitteerd.
  • Het gebruikersrisico negeren.
  • Bevestig het aanmelden veilig.
  • Bevestig dat aanmelding is gecompromitteerd.

Gebruikers deblokkeren

Een beheerder kiest ervoor om een aanmelding te blokkeren op basis van hun risicobeleid of onderzoek. Er treedt een blok op op basis van aanmeldings- of gebruikersrisico's.

Deblokkeren op basis van gebruikersrisico

Beheerders hebben de volgende opties om de blokkering van een account te deblokkeren vanwege gebruikersrisico's:

  • Wachtwoord opnieuw instellen: u kunt het wachtwoord van de gebruiker opnieuw instellen.
  • Gebruikersrisico sluiten : het beleid voor gebruikersrisico's blokkeert een gebruiker als het geconfigureerde gebruikersrisiconiveau voor het blokkeren van toegang is bereikt. U kunt het risiconiveau van een gebruiker verminderen door gebruikersrisico's te sluiten of gerapporteerde risicodetecties handmatig te sluiten.
  • Sluit de gebruiker uit van beleid: als u denkt dat de huidige configuratie van uw aanmeldingsbeleid problemen veroorzaakt voor specifieke gebruikers, kunt u de gebruikers hiervan uitsluiten.
  • Beleid uitschakelen: als u denkt dat uw beleidsconfiguratie problemen veroorzaakt voor al uw gebruikers, kunt u het beleid uitschakelen.

Blokkering opheffen op basis van aanmeldingsrisico

Beheerders hebben de volgende opties om een account te deblokkeren dat is geblokkeerd vanwege een aanmeldingsrisico:

  • Aanmelden vanaf een vertrouwde locatie of apparaat: een veelvoorkomende reden voor geblokkeerde verdachte aanmeldingen zijn aanmeldingspogingen vanaf onbekende locaties of apparaten. Uw gebruikers kunnen snel bepalen of dit de blokkeringsreden is door zich aan te melden vanaf een vertrouwde locatie of apparaat.
  • Sluit de gebruiker uit van beleid: als u denkt dat de huidige configuratie van uw aanmeldingsbeleid problemen veroorzaakt voor specifieke gebruikers, kunt u de gebruikers hiervan uitsluiten.
  • Beleid uitschakelen: als u denkt dat uw beleidsconfiguratie problemen veroorzaakt voor al uw gebruikers, kunt u het beleid uitschakelen.

PowerShell Preview

Met behulp van de Microsoft Graph PowerShell SDK Preview-module kunnen organisaties risico's beheren met behulp van PowerShell. De preview-modules en voorbeeldcode bevinden zich in de Azure GitHub-opslagplaats.

De Microsoft Graph API gebruiken

Microsoft Graph is het geïntegreerde API-eindpunt van Microsoft en de startpagina van Microsoft Entra Identity Protection-API's. Er zijn drie API's die informatie beschikbaar maken over riskante gebruikers en aanmeldingen: riskDetection, riskyUsers, and signIn.

riskDetectionhiermee kunt u een query uitvoeren op Microsoft Graph voor een lijst met zowel gebruikers- als aanmeldingsdetecties voor gekoppelde risico's en bijbehorende informatie over de detectie.

riskyUsershiermee kunt u microsoft Graph opvragen voor informatie over gebruikers die Identity Protection heeft gedetecteerd als riskant.

signIn hiermee kunt u query's uitvoeren op Microsoft Graph voor informatie over aanmeldingen met Microsoft Entra-id's met specifieke eigenschappen met betrekking tot de risicostatus, detail en niveau.

In deze sectie gaat u aan de slag met het maken van verbinding met Microsoft Graph en het uitvoeren van query's op deze API's. Zie de Microsoft Graph-site (https://graph.microsoft.io/) of de specifieke referentiedocumentatie voor de API's voor een uitgebreide inleiding, volledige documentatie en toegang tot Graph riskDetection, riskyUsers, and signIn Explorer.

Verbinding maken met Microsoft Graph

Er zijn vier stappen voor toegang tot Identity Protection-gegevens via Microsoft Graph: haal uw domeinnaam op, maak een nieuwe app-registratie, configureer API-machtigingen en configureer een geldige referentie.

Uw domeinnaam ophalen

  1. Meld u aan bij het Microsoft Entra-beheercentrum.
  2. Blader naar Identiteit, open Instellingen en selecteer Domeinnamen.
  3. Noteer het domein .onmicrosoft.com. U hebt deze informatie nodig in een latere stap.

Een nieuwe app-registratie maken

  1. Blader in het Microsoft Entra-beheercentrum naar Identiteit en toepassingen en App-registraties.

  2. Selecteer Nieuwe registratie.

  3. Voer op de pagina Maken de volgende stappen uit:

    1. Typ in het tekstvak Naam een naam voor uw toepassing (bijvoorbeeld: Microsoft Entra Risk Detection-API).
    2. Selecteer onder Ondersteunde accounttypen het type accounts dat de API's gebruikt.
    3. Selecteer Registreren.

  4. Kopieer de Toepassings-id.

API-machtigingen configureren

  1. Selecteer API-machtigingen in de toepassing die u hebt gemaakt.

  2. Selecteer een machtiging toevoegen op de pagina Geconfigureerde machtigingen op de werkbalk bovenaan.

  3. Kies een API selecteren op de pagina API-toegang toevoegen.

  4. Selecteer Microsoft Graph op de pagina Een API selecteren en selecteer vervolgens Selecteren.

  5. Op de pagina Api-machtigingen aanvragen:

    1. Selecteer Toepassingstoestemming.
    2. Schakel de selectievakjes naast IdentityRiskEvent.Read.All en IdentityRiskyUser.Read.All in.
    3. Selecteer Machtigingen toevoegen.

  6. Selecteer Beheerderstoestemming verlenen voor domein.

Een geldige referentie configureren

  1. Selecteer Certificaten en geheimen in de toepassing die u hebt gemaakt.

  2. Selecteer onder Clientgeheimen het nieuwe clientgeheim.

    1. Geef het clientgeheim een beschrijving en stel de verloopperiode in op basis van het beleid van uw organisatie.

    2. Selecteer Toevoegen.

      Notitie

      Als u deze sleutel kwijtraakt, moet u terugkeren naar deze sectie en een nieuwe sleutel maken. Bewaar deze sleutel een geheim: iedereen die deze heeft, heeft toegang tot uw gegevens.

Verifiëren bij Microsoft Graph en query's uitvoeren op de Identity Protection-risicodetectie-API

Op dit moment hebt u het volgende nodig:

  • De naam van het domein van uw tenant
  • De toepassings-id (client)
  • Het clientgeheim of -certificaat

Als u wilt verifiëren, verzendt u een postaanvraag naar https://login.microsoft.com met de volgende parameters in de hoofdtekst:

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

Als dit lukt, retourneert deze aanvraag een verificatietoken. Als u de API wilt aanroepen, maakt u een header met de volgende parameter:

Authorization`="<token_type> <access_token>"

Bij het verifiëren vindt u het tokentype en het toegangstoken in het geretourneerde token.

Verzend deze header als een aanvraag naar de volgende API-URL: https://graph.microsoft.com/v1.0/identityProtection/riskDetections.

Het antwoord, indien geslaagd, is een verzameling identiteitsrisicodetecties en bijbehorende gegevens in de OData JSON-indeling, die naar wens kan worden geparseerd en verwerkt.

Voorbeeld

In dit voorbeeld ziet u het gebruik van een gedeeld geheim om te verifiëren. In een productieomgeving wordt het opslaan van geheimen in code over het algemeen afgeslagen. Organisaties kunnen beheerde identiteiten voor Azure-resources gebruiken om deze referenties te beveiligen.

Hier volgt voorbeeldcode voor het verifiëren en aanroepen van de API met behulp van PowerShell. Voeg uw client-id, de geheime sleutel en het tenantdomein toe.

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

    }

Alle offline risicodetecties ophalen (riskDetection-API)

Met het beleid voor aanmeldingsrisico's van Identity Protection kunt u voorwaarden toepassen wanneer risico's in realtime worden gedetecteerd. Maar hoe zit het met detecties die offline worden gedetecteerd? Als u wilt weten welke detecties offline zijn opgetreden en dus het beleid voor aanmeldingsrisico's niet heeft geactiveerd, kunt u een query uitvoeren op de riskDetection API.

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

Haal alle gebruikers op die een MFA-uitdaging hebben doorstaan, geactiveerd door riskante aanmeldingsbeleid (riskante Gebruikers-API)

Als u wilt weten wat het risicobeleid op basis van identiteitsbeveiliging voor uw organisatie is, kunt u een query uitvoeren op alle gebruikers die een MFA-uitdaging hebben doorgegeven die is geactiveerd door een beleid voor riskante aanmeldingen. Deze informatie kan u helpen te begrijpen welke gebruikers Identity Protection onwaar heeft gedetecteerd als een risico en welke van uw legitieme gebruikers acties uitvoeren die de AI riskant acht.

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