次の方法で共有


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

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

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

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

前提条件

このチュートリアルを完了するには、次のリソースと特権が必要です。

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

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

匿名ブラウザー セッションで、 MyTestUser1 としてサインインして entra.microsoft.com します。

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

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

要求

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

応答

{
  "@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: 条件付きアクセス ポリシーを作成する

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

多要素認証を設定する

MFA のアカウントを設定する場合は、ユーザーを認証するためのいくつかの方法から選択できます。 このチュートリアルを完了するには、状況に最適な方法を選択してください。

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

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

条件付きアクセス ポリシーを使用すると、サインイン リスク レベルを識別するポリシーの条件を設定できます。 リスク レベルには、、、mediumhigh、 を指定lownoneできます。 次の例は、中リスクレベルと高リスク レベルのサインインに 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" 
    ] 
  } 
} 

応答

{ 
  "@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 が完了したため、この最新のサインイン イベントの riskState は になりました remediated

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

ユーザーが自己修復する機会を提供する代わりに、危険なサインインに関連付けられているユーザーのサインインをブロックできます。 この手順では、中または高リスクの検出が発生した場合にユーザーのサインインをブロックする新しい条件付きアクセス ポリシーを作成します。 このポリシーと手順 3 のプレビュー ポリシーの違いは、 builtInControls が に block設定されていることです。

要求

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

応答

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

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

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

手順 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