Identifizieren und Beheben von Risiken mithilfe von Identity Protection-APIs

Microsoft Entra ID Protection bietet Organisationen Einblicke in identitätsbasierte Risiken und verschiedene Möglichkeiten, Risiken zu untersuchen und automatisch zu beheben. Die in diesem Tutorial verwendeten Identity Protection-APIs können Ihnen helfen, Risiken zu identifizieren und einen Workflow zu konfigurieren, um die Kompromittierung zu bestätigen oder die Korrektur zu aktivieren.

In diesem Tutorial erfahren Sie, wie Sie Identity Protection-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

Für dieses Tutorial benötigen Sie die folgenden Ressourcen und Berechtigungen:

  • Ein funktionierender Microsoft Entra Mandant mit einer Microsoft Entra ID P1- oder P2-Lizenz.
  • Melden Sie sich bei einem API-Client wie Graph Explorer mit einem Konto an, das mindestens über die Rolle "Administrator für bedingten Zugriff" verfügt.
  • Gewähren Sie sich die folgenden delegierten Berechtigungen: IdentityRiskEvent.Read.All, IdentityRiskyUser.ReadWrite.All, Policy.Read.All, Policy.ReadWrite.ConditionalAccessund User.ReadWrite.All.
  • Ein Testbenutzerkonto, das Sie verwenden, um sich später bei einer anonymen Sitzung anzumelden, um eine Risikoerkennung auszulösen. Sie können eine private Browsersitzung oder den Tor-Browser verwenden. In diesem Tutorial lautet der E-Mail-Spitzname des Testbenutzers MyTestUser1.

Schritt 1: Auslösen einer Risikoerkennung

Melden Sie sich in der anonymen Browsersitzung als MyTestUser1 an, um entra.microsoft.com.

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

{
  "@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

Sie können Richtlinien für bedingten Zugriff in Ihrem organization verwenden, damit Benutzer sich selbst korrigieren können, wenn ein Risiko erkannt wird. Die Selbstwartung ermöglicht es Ihren Benutzern, die Blockierung für den sicheren Zugriff auf ihre Ressourcen nach Abschluss der Richtlinienaufforderung zu aufheben. In diesem Schritt erstellen Sie eine Richtlinie für bedingten Zugriff, die erfordert, dass sich der Benutzer mit MFA anmeldet, wenn ein mittleres oder hohes Risiko erkannt wird.

Einrichten der mehrstufigen Authentifizierung

Beim Einrichten eines Kontos für MFA können Sie aus mehreren Methoden zur Authentifizierung des Benutzers wählen. Wählen Sie die beste Methode für Ihre Situation aus, um dieses Tutorial abzuschließen.

  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 die Bedingungen der Richtlinie festlegen, um Anmelderisikostufen zu identifizieren. Die Risikostufen können low, medium, high, sein none. 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

{ 
  "@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 wurde ein Risiko erkannt, aber Sie haben es durch Abschließen der MFA behoben.

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

Anstatt dem Benutzer die Möglichkeit zu bieten, sich selbst zu korrigieren, können Sie die Anmeldung des Benutzers, der einer riskanten Anmeldung zugeordnet ist, blockieren. In diesem Schritt erstellen Sie eine neue Richtlinie für bedingten Zugriff, die den Benutzer daran hindert, sich anzumelden, wenn ein mittleres oder hohes Risiko erkannt wird. Der Unterschied zwischen dieser Richtlinie und der Vorschaurichtlinie 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

{
  "@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 wird das Konto MyTestUser1 jetzt für die Anmeldung blockiert, da die Anmelderisikostufe oder highistmedium.

Blockierte Anmeldung

Schritt 6: Verwerfen riskanter Benutzer

Wenn Sie der Meinung sind, dass der Benutzer nicht gefährdet ist und Sie keine Richtlinie für bedingten Zugriff erzwingen möchten, können Sie den risikobehafteten Benutzer manuell verwerfen. 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

In diesem Schritt löschen Sie 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