Freigeben über


Identifizieren und Beheben von Risiken mithilfe von Identity Protection-APIs

Microsoft Entra ID Protection bietet Organisationen Einblicke in identitätsbasierte Risiken und Methoden, um diese Risiken zu untersuchen und automatisch zu beheben. Dieses Tutorial führt Sie durch die Verwendung von ID-Schutz-APIs, um Risiken zu identifizieren und Workflows zum Bestätigen von Kompromittierungen oder Aktivieren von Korrekturen einzurichten.

In diesem Tutorial erfahren Sie, wie Sie ID-Schutz-APIs für Folgendes verwenden:

  • Generieren Sie eine riskante Anmeldung.
  • Ermöglichen Sie Benutzern mit riskanten Anmeldungen, das Risiko status mit einer Richtlinie für bedingten Zugriff zu beheben, die mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) erfordert.
  • Blockieren der Anmeldung eines Benutzers mithilfe einer Richtlinie für bedingten Zugriff.
  • Schließen Sie ein Benutzerrisiko.

Voraussetzungen

Stellen Sie für dieses Tutorial Folgendes sicher:

  • Ein Microsoft Entra Mandant mit einer Microsoft Entra ID P1- oder P2-Lizenz.
  • Zugriff auf einen API-Client wie Graph Explorer, der mit einem Konto angemeldet ist, das über die Rolle "Administrator für bedingten Zugriff" verfügt.
  • Die folgenden delegierten Berechtigungen: IdentityRiskEvent.Read.All, IdentityRiskyUser.ReadWrite.All, Policy.Read.All, Policy.ReadWrite.ConditionalAccess und User.ReadWrite.All.
  • Ein Testbenutzerkonto zum Anmelden bei einer anonymen Sitzung, um eine Risikoerkennung auszulösen. Verwenden Sie eine private Browsersitzung oder den Tor-Browser. In diesem Tutorial lautet der E-Mail-Spitzname des Testbenutzers MyTestUser1.

Schritt 1: Auslösen einer Risikoerkennung

Melden Sie sich in der anonymen Browsersitzung beim Microsoft Entra Admin Center als MyTestUser1an.

Schritt 2: Auflisten von Risikoerkennungen

Als Sich MyTestUser1 mit dem anonymen Browser beim Microsoft Entra Admin Center angemeldet hat, wurde ein anonymizedIPAddress Risikoereignis erkannt. Sie können den $filter Abfrageparameter verwenden, um nur die Risikoerkennungen abzurufen, die dem Benutzerkonto MyTestUser1 zugeordnet sind. Es kann einige Minuten dauern, bis das Ereignis zurückgegeben wird.

Anforderung

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

Antwort

HTTP/1.1 20O OK
Content-type: application/json

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#riskDetections",
  "value": [
    {
      "id": "d52a631815aaa527bf642b196715da5cf0f35b6879204ea5b5c99b21bd4c16f4",
      "requestId": "06f7fd18-b8f1-407d-86a3-f6cbe3a4be00",
      "correlationId": "2a38abff-5701-4073-a81e-fd3aac09cba3",
      "riskType": "anonymizedIPAddress",
      "riskEventType": "anonymizedIPAddress",
      "riskState": "atRisk",
      "riskLevel": "medium",
      "riskDetail": "none",
      "source": "IdentityProtection",
      "detectionTimingType": "realtime",
      "activity": "signin",
      "tokenIssuerType": "AzureAD",
      "ipAddress": "178.17.170.23",
      "activityDateTime": "2020-11-03T20:51:34.6245276Z",
      "detectedDateTime": "2020-11-03T20:51:34.6245276Z",
      "lastUpdatedDateTime": "2020-11-03T20:53:12.1984203Z",
      "userId": "4628e7df-dff3-407c-a08f-75f08c0806dc",
      "userDisplayName": "MyTestUser1",
      "userPrincipalName": "MyTestUser1@contoso.com",
      "additionalInfo": "[{\"Key\":\"userAgent\",\"Value\":\"Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0\"}]",
      "location": {
        "city": "Chisinau",
        "state": "Chisinau",
        "countryOrRegion": "MD",
        "geoCoordinates": {
          "latitude": 47.0269,
          "longitude": 28.8416
        }
      }
    }
  ]
}

Schritt 3: Erstellen einer Richtlinie für bedingten Zugriff

Richtlinien für bedingten Zugriff ermöglichen Es Benutzern, sich selbst zu beheben, wenn ein Risiko erkannt wird, sodass sie nach Abschluss der Richtlinienaufforderung sicher auf Ressourcen zugreifen können. In diesem Schritt erstellen Sie eine Richtlinie für bedingten Zugriff, die erfordert, dass sich Benutzer mit MFA anmelden, wenn eine Erkennung mit mittlerem oder hohem Risiko auftritt.

Einrichten der mehrstufigen Authentifizierung

Wählen Sie beim Einrichten eines Kontos für MFA die beste Authentifizierungsmethode für Ihre Situation aus.

  1. Melden Sie sich mit dem Konto MyTestUser1 bei der Website für die Sicherheit Ihres Kontos an.
  2. Führen Sie das MFA-Setupverfahren mit der für Ihre Situation geeigneten Methode aus, z. B. mit der Microsoft Authenticator-App.

Erstellen der Richtlinie für bedingten Zugriff

Mit der Richtlinie für bedingten Zugriff können Sie Bedingungen festlegen, um Anmelderisikostufen zu identifizieren. Risikostufen können , medium, highoder noneseinlow. Das folgende Beispiel zeigt, wie MFA für Anmeldungen mit mittleren und hohen Risikostufen erforderlich ist.

Anforderung

POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies 
Content-type: application/json
 
{ 
  "displayName": "Policy for risky sign-in", 
  "state": "enabled", 
  "conditions": { 
    "signInRiskLevels": [ 
      "high", 
      "medium" 
    ], 
    "applications": { 
      "includeApplications": ["All"]
    }, 
    "users": { 
      "includeUsers": [ 
        "4628e7df-dff3-407c-a08f-75f08c0806dc" 
      ] 
    } 
  }, 
  "grantControls": { 
    "operator": "OR", 
    "builtInControls": [ 
      "mfa" 
    ] 
  } 
} 

Antwort

HTTP/1.1 201 Created
Content-type: application/json

{ 
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#identity/conditionalAccess/policies/$entity", 
  "id": "9ad78153-b1f8-4714-adc1-1445727678a8", 
  "displayName": "Policy for risky sign-in", 
  "createdDateTime": "2020-11-03T20:56:38.6210843Z", 
  "modifiedDateTime": null, 
  "state": "enabled", 
  "sessionControls": null, 
  "conditions": { 
    "signInRiskLevels": [ 
      "high", 
      "medium" 
    ], 
    "clientAppTypes": [  
      "all"  
    ], 
    "platforms": null, 
    "locations": null, 
    "applications": { 
      "includeApplications": [ 
        "All" 
      ], 
      "excludeApplications": [], 
      "includeUserActions": [] 
    }, 
    "users": { 
      "includeUsers": [ 
        "4628e7df-dff3-407c-a08f-75f08c0806dc" 
      ], 
      "excludeUsers": [], 
      "includeGroups": [], 
      "excludeGroups": [], 
      "includeRoles": [], 
      "excludeRoles": [] 
    } 
  }, 
  "grantControls": { 
    "operator": "OR", 
    "builtInControls": [ 
      "mfa" 
    ], 
    "customAuthenticationFactors": [], 
    "termsOfUse": [] 
  } 
} 

Schritt 4: Auslösen einer weiteren riskanten Anmeldung, aber vollständige mehrstufige Authentifizierung

Durch die Anmeldung beim anonymen Browser wird ein Risiko erkannt, aber Sie beheben es, indem Sie MFA abschließen.

Melden Sie sich mit dem Konto MyTestUser1 bei entra.microsoft.com an, und schließen Sie den MFA-Prozess ab.

Schritt 5: Auflisten von Risikoerkennungen

Führen Sie die Anforderung in Schritt 2 erneut aus, um die neueste Risikoerkennung für das Benutzerkonto MyTestUser1 zu erhalten. Da MFA in Schritt 4 abgeschlossen wurde, lautet riskState für dieses letzte Anmeldeereignis jetzt remediated.

[Optional] Blockieren der Benutzeranmeldung

Wenn Sie es vorziehen, Benutzer zu blockieren, die riskanten Anmeldungen zugeordnet sind, anstatt eine Selbstwartung zuzulassen, erstellen Sie eine neue Richtlinie für bedingten Zugriff. Diese Richtlinie blockiert die Anmeldung von Benutzern, wenn eine Erkennung mit mittlerem oder hohem Risiko auftritt. Der Hauptunterschied zur Richtlinie in Schritt 3 besteht darin, dass builtInControls jetzt auf blockfestgelegt ist.

Anforderung

POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies
Content-type: application/json

{
  "displayName": "Policy for risky sign-in block access",
  "state": "enabled",
  "conditions": {
    "signInRiskLevels": [
      "high",
      "medium"
    ],
    "applications": {
      "includeApplications": ["All"]
    },
    "users": {
      "includeUsers": [
        "4628e7df-dff3-407c-a08f-75f08c0806dc"
      ]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": [
      "block"
    ]
  }
}

Antwort

HTTP/1.1 201 Created
Content-type: application/json

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#identity/conditionalAccess/policies/$entity",
  "id": "9ad78153-b1f8-4714-adc1-1445727678a8",
  "displayName": "Policy for risky sign-in block access",
  "createdDateTime": "2020-11-03T20:56:38.6210843Z",
  "modifiedDateTime": null,
  "state": "enabled",
  "sessionControls": null,
  "conditions": {
    "signInRiskLevels": [
      "high",
      "medium"
    ],
    "clientAppTypes": [ 
      "all" 
    ],
    "platforms": null,
    "locations": null,
    "applications": {
      "includeApplications": [
        "All"
      ],
      "excludeApplications": [],
      "includeUserActions": []
    },
    "users": {
      "includeUsers": [
        "4628e7df-dff3-407c-a08f-75f08c0806dc"
      ],
      "excludeUsers": [],
      "includeGroups": [],
      "excludeGroups": [],
      "includeRoles": [],
      "excludeRoles": []
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": [
      "block"
    ],
    "customAuthenticationFactors": [],
    "termsOfUse": []
  }
}

Mit dieser Richtlinie für bedingten Zugriff kann sich das Konto MyTestUser1 aufgrund eines mittleren oder hohen Anmelderisikos nicht mehr anmelden.

Blockierte Anmeldung

Schritt 6: Verwerfen riskanter Benutzer

Wenn Sie der Meinung sind, dass der Benutzer nicht gefährdet ist und keine Richtlinie für bedingten Zugriff erzwingen möchten, schließen Sie den risikobehafteten Benutzer manuell, wie in der folgenden Anforderung gezeigt. Die Anforderung gibt eine 204 No Content Antwort zurück.

Anforderung

POST https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/dismiss
Content-Type: application/json

{
  "userIds": [
    "4628e7df-dff3-407c-a08f-75f08c0806dc"
  ]
}

Nachdem Sie den Risikobenutzer verworfen haben, können Sie die Anforderung in Schritt 2 erneut ausführen und feststellen, dass das Benutzerkonto MyTestUser1 jetzt die Risikostufe none und den riskState von aufweist dismissed.

Schritt 7: Ressourcen bereinigen

Löschen Sie in diesem Schritt die beiden richtlinien für bedingten Zugriff, die Sie erstellt haben. Die Anforderung gibt eine 204 No Content Antwort zurück.

DELETE https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/9ad78153-b1f8-4714-adc1-1445727678a8