次の方法で共有


ID 保護 API を使用してリスクを特定して修復する

Microsoft Entra ID 保護は、ID ベースのリスクと、これらのリスクを調査して自動的に修復する方法に関する分析情報を組織に提供します。 このチュートリアルでは、ID Protection API を使用してリスクを特定し、侵害を確認したり修復を有効にするためのワークフローを設定したりする方法について説明します。

このチュートリアルでは、ID Protection API を使用して次の操作を行う方法について説明します。

  • 危険なサインインを生成します。
  • 危険なサインインを持つユーザーが、多要素認証 (MFA) を必要とする条件付きアクセス ポリシーを使用してリスクの状態を修復できるようにします。
  • 条件付きアクセス ポリシーを使用してユーザーがサインインできないようにブロックします。
  • ユーザー リスクを無視します。

前提条件

このチュートリアルを完了するには、次のことを確認します。

  • Microsoft Entra ID P1 または P2 ライセンスを持つMicrosoft Entra テナント。
  • 条件付きアクセス管理者ロールを持つアカウントでサインインした Graph エクスプローラーなどの API クライアントへのアクセス。
  • 委任されたアクセス許可: IdentityRiskEvent.Read.AllIdentityRiskyUser.ReadWrite.AllPolicy.Read.AllPolicy.ReadWrite.ConditionalAccessUser.ReadWrite.All
  • リスク検出をトリガーするために匿名セッションにサインインするテスト ユーザー アカウント。 プライベート閲覧セッションまたは Tor ブラウザーを使用します。 このチュートリアルでは、テスト ユーザーメールのニックネームを MyTestUser1

手順 1: リスク検出をトリガーする

匿名ブラウザー セッションで、MyTestUser1としてMicrosoft Entra管理センターにサインインします。

手順 2: リスク検出を一覧表示する

MyTestUser1 が匿名ブラウザーを使用してMicrosoft Entra 管理センターにサインインすると、anonymizedIPAddress リスク イベントが検出されました。 $filter クエリ パラメーターを使用して、MyTestUser1 ユーザー アカウントに関連付けられているリスク検出のみを取得できます。 イベントが返されるまでに数分かかる場合があります。

要求

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

応答

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
        }
      }
    }
  ]
}

手順 3: 条件付きアクセス ポリシーを作成する

条件付きアクセス ポリシーを使用すると、ユーザーはリスクが検出されたときに自己修復でき、ポリシー プロンプトが完了した後にリソースに安全にアクセスできるようになります。 この手順では、中または高リスクの検出が発生した場合にユーザーが MFA を使用してサインインすることを要求する条件付きアクセス ポリシーを作成します。

多要素認証を設定する

MFA のアカウントを設定する場合は、状況に最適な認証方法を選択します。

  1. MyTestUser1アカウントを使用してアカウントのセキュリティ保護を維持するサイトにサインインします。
  2. Microsoft Authenticator アプリの使用など、状況に応じた適切な方法を使用して MFA のセットアップ手順を完了します。

条件付きアクセス ポリシーを作成する

条件付きアクセス ポリシーを使用すると、サインイン リスク レベルを識別する条件を設定できます。 リスク レベルは、 lowmediumhigh、または noneできます。 次の例は、中リスクレベルと高リスク レベルのサインインに MFA を要求する方法を示しています。

要求

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" 
    ] 
  } 
} 

応答

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": [] 
  } 
} 

手順 4: 別の危険なサインインをトリガーするが、多要素認証を完了する

匿名ブラウザーにサインインすると、リスクが検出されますが、MFA を完了して修復します。

MyTestUser1 アカウントを使用して entra.microsoft.com にサインインし、MFA プロセスを完了します。

手順 5: リスク検出を一覧表示する

手順 2 で要求を再実行して、 MyTestUser1 ユーザー アカウントの最新のリスク検出を取得します。 手順 4 で MFA が完了したため、この最新のサインイン イベントの riskStateremediatedになりました。

[省略可能]ユーザーのサインインをブロックする

自己修復を許可するのではなく、危険なサインインに関連付けられているユーザーをブロックする場合は、新しい条件付きアクセス ポリシーを作成します。 このポリシーは、中または高リスクの検出が発生した場合に、ユーザーのサインインをブロックします。 手順 3 のポリシーとの主な違いは、 builtInControlsblock に設定されていることです。

要求

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"
    ]
  }
}

応答

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": []
  }
}

この条件付きアクセス ポリシーを設定すると、 MyTestUser1 アカウントは、中または高のサインイン リスク レベルのためにサインインがブロックされるようになりました。

ブロックされたサインイン

手順 6: 危険なユーザーを無視する

ユーザーが危険にさらされていないと考え、条件付きアクセス ポリシーを適用したくない場合は、次の要求に示すように、危険なユーザーを手動で無視します。 要求は、 204 No Content 応答を返します。

要求

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

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

リスク ユーザーを無視した後、手順 2 で要求を再実行すると、 MyTestUser1 ユーザー アカウントにリスク レベルの none と riskState の dismissedが表示されます。

手順 7: リソースをクリーンアップする

この手順では、作成した 2 つの条件付きアクセス ポリシーを削除します。 要求は、 204 No Content 応答を返します。

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