リスクの高いユーザーを監視、調査、および修復する

16 分

リスクの調査

Identity Protection を使用すると、お使いの環境のリスクを調査するために使用できる、[危険なユーザー]、[危険なサインイン]、および [リスク検出] の 3 種類のレポートが組織に提供されます。イベントの調査は、セキュリティ戦略の弱点を理解して識別するための鍵です。

3 つのレポートは、Azure portal の外部で詳細な分析を行うために、どれもイベントを .CSV 形式でダウンロードできます。危険なユーザーレポートと危険なサインインレポートでは、最新の 2,500 項目をダウンロードできます。一方、リスク検出レポートでは、最新の 5,000 レコードをダウンロードできます。

組織は、Microsoft Graph API 統合を利用して、組織としてアクセスできる他のソースを使用してデータを集約できます。

[Microsoft Entra 管理センター]、[ID]、[保護 - Identity Protection] の順で 3 つのレポートを確認できます。

レポート内の移動

各レポートは、レポートの上部に表示されている期間のすべての検出の一覧と共に起動します。各レポートでは、管理者の設定に基づいて列を追加または削除できます。管理者は、データを .CSV または .JSON 形式でダウンロードすることを選択できます。レポートは、レポートの上部にあるフィルターを使用してフィルター処理できます。

個々のエントリを選択すると、レポートの上部の追加エントリが有効になります (サインインが侵害されているまたは安全であると確認する、ユーザーが侵害されていると確認する、ユーザーリスクを無視する機能など)。

個々のエントリを選択すると、検出の下に [詳細] ウィンドウが展開されます。詳細ビューで、管理者は、各検出を調査してアクションを実行できます。

危険なサインインと詳細を示す Identity Protection レポートのスクリーンショット。

危険なユーザー

危険なユーザーレポートによって提供される情報を使用して、管理者は、以下を見つけることができます。

どのユーザーにリスクがあり、リスクが修復されたか無視されたか
検出の詳細。
すべての危険なサインインの履歴。
リスクの履歴。

管理者は、これらのイベントに対してアクションを実行することを選択できます。学生は次のいずれかを選択できます。

ユーザーパスワードをリセットする。
ユーザーの侵害を確認する。
ユーザーリスクを無視する。
ユーザーによるサインインをブロックする。
Azure ATP を使用してさらに調査する。

リスクの高いサインイン

危険なサインインレポートには、最長で過去 30 日間 (1 か月) のフィルター可能なデータが含まれています。

危険なサインインレポートによって提供される情報を使用して、管理者は、以下を見つけることができます。

どのサインインが、危険である、侵害が確認された、安全であると確認された、無視された、または修復されたと分類されているか
サインイン試行に関連付けられ、リアルタイムで集計されたリスクレベル
トリガーされた検出の種類。
適用された条件付きアクセスポリシー。
MFA の詳細。
デバイス情報。
アプリケーション情報。
場所情報。

管理者は、これらのイベントに対してアクションを実行することを選択できます。管理者は、以下を実行することを選択できます。

サインインを侵害ありと確認。
サインインを安全と確認。

リスク検出

リスク検出レポートには、最長で過去 90 日間 (3 か月) のフィルター可能なデータが含まれています。

リスク検出レポートによって提供される情報を使用して、管理者は、以下を見つけることができます。

各リスク検出についての種類を含む情報
同時にトリガーされたその他のリスク。
サインインが試行された場所。

管理者は、ユーザーのリスクレポートまたはサインインレポートに戻り、収集された情報に基づいてアクションを実行できます。

また、リスク検出レポートには、追加のログとアラートを表示できる Microsoft Defender for Cloud Apps (MDCA) ポータルの検出へのクリック可能なリンクも提供されています。

Note

このシステムは、リスクユーザーのリスクスコアに影響を与えたリスクイベントが擬陽性であったことや、ユーザーリスクがポリシーの適用 (MFA プロンプトの完了や安全なパスワードへの変更など) によって修復されたことを検出します。その場合、リスクの状態は無視され、「AI によってサインインが安全であることが確認されました」というリスクの詳細が表示されます。また、ユーザーのリスクには影響しなくなります。

リスクを修復してユーザーをブロック解除する

調査が完了したら、リスクを修復するか、ユーザーをブロック解除するアクションを実行できます。組織には、リスクポリシーを使用して、自動修復を有効にするというオプションもあります。組織は、組織が適切と考える期間内に、提示されたすべてのリスク検出をクローズするよう試みる必要があります。 Microsoft では、リスクの処理では時間が重要であるため、できるだけ早くイベントをクローズすることをお勧めしています。

Remediation

すべてのアクティブなリスク検出は、"ユーザーのリスクレベル" と呼ばれる値の計算に影響します。ユーザーのリスクレベルは、アカウントが侵害されている確率のインジケーター (低、中、高) です。管理者は、すべてのリスク検出をクローズして、影響を受けるユーザーが危険な状態ではなくなるようにします。

イベントが危険と判断されなくなったため、Identity Protection によって "クローズ (システム)" としてマークされるリスク検出もあります。

管理者には、修復するための次のオプションがあります。

リスクポリシーを使用した自己修復。
パスワードの手動リセット。
ユーザーリスクを無視する。
個々のリスク検出を手動でクローズする。

リスクポリシーを使用した自己修復

リスクポリシー内の多要素認証 (MFA) とセルフサービスパスワードリセット (SSPR) を使用して、ユーザーが自己修復することを許可すると、リスクが検出されたときに、ユーザーは自分自身でブロック解除を行えます。これらの検出は、クローズされたとみなされます。リスクが検出されたときに使用するためには、ユーザーは MFA と SSPR に事前に登録しておく必要があります。

一部の検出は、ユーザーの自己修復が要求されるほど高いレベルのリスクとはなりませんが、管理者はこれらの検出も評価する必要があります。管理者は、いくつかの場所からのアクセスのブロックやポリシー内で許容されるリスクのレベルを下げるなどの追加の対策が必要であると判断します。

パスワードの手動リセット

ユーザーリスクポリシーを使用したパスワードリセットの要求を選択しない場合、管理者は、手動によるパスワードのリセットを使用して、ユーザーのすべてのリスク検出をクローズすることができます。

管理者には、ユーザーのパスワードをリセットするときに 2 つのオプションがあります。

一時パスワードを生成する - 一時パスワードを生成することによって、ID をすぐに安全な状態に戻すことができます。この方法では、影響を受けるユーザーが一時的なパスワードを知る必要があるために、ユーザーと接触する必要があります。パスワードは一時的なので、ユーザーは次回サインイン時にパスワードを何か新しいものに変更することを求められます。

ユーザーにパスワードをリセットするよう要求する - ユーザーにパスワードをリセットするよう要求すると、ヘルプデスクや管理者に連絡せずに自己復旧することができます。この方法は、MFA と SSPR に登録されているユーザーにのみ適用されます。まだ登録されていないユーザーの場合、このオプションは使用できません。

ユーザーリスクを無視する

ユーザーが削除されているなどの理由でパスワードのリセットを選択できない場合は、ユーザーリスク検出を無視することを選択できます。

[ユーザーリスクを無視する] を選択すると、すべてのイベントがクローズされ、影響を受けるユーザーは危険な状態ではなくなります。ただし、この方法は既存のパスワードには影響しないため、関連する ID は安全な状態に戻りません。

個々のリスク検出を手動でクローズする

個々のリスク検出を手動でクローズすることで、ユーザーのリスクレベルを低くすることができます。通常、リスク検出は、関連する調査に応じて (ユーザーとの通信時にアクティブなリスク検出が不要であることが判明した場合などに) 手動でクローズします。

リスク検出を手動でクローズする場合は、リスク検出の状態を変更する次のいずれかの操作を実行できます。

ユーザーの侵害を確認。
ユーザーリスクを無視する。
サインインを安全と確認。
サインインを侵害ありと確認。

ユーザーのブロック解除

管理者は、リスクポリシーまたは調査に基づいて、サインインをブロックすることを選択します。ブロックは、サインインリスクまたはユーザーリスクに基づいて発生します。

ユーザーリスクに基づくブロック解除

ユーザーリスクによってブロックされたアカウントをブロック解除する場合、管理者には、次のオプションがあります。

パスワードをリセットする - ユーザーのパスワードをリセットすることができます。
ユーザーリスクを無視する - アクセスをブロックするために構成されたユーザーリスクレベルに到達した場合、ユーザーリスクポリシーによってユーザーがブロックされます。ユーザーリスクを無視するか、報告されたリスク検出を手動でクローズすることで、ユーザーのリスクレベルを下げることができます。
ポリシーからユーザーを除外する - サインインポリシーの現在の構成が原因で特定のユーザーに問題が発生していると考えられる場合は、そのポリシーからユーザーを除外できます。
ポリシーを無効にする - ポリシーの構成が原因ですべてのユーザーに問題が発生していると考えられる場合は、ポリシーを無効にすることができます。

サインインリスクに基づいてアカウントをブロック解除する場合、管理者には、次のオプションがあります。

よく使用する場所やデバイスからサインインする - 不審なサインインがブロックされる一般的な理由は、使用頻度の低い場所やデバイスからのサインイン試行にあります。ユーザーは、よく使用する場所やデバイスからのサインインを試みることで、この理由がブロックの理由であるかどうかをすぐに確認できます。
ポリシーからユーザーを除外する - サインインポリシーの現在の構成が原因で特定のユーザーに問題が発生していると考えられる場合は、そのポリシーからユーザーを除外できます。
ポリシーを無効にする - ポリシーの構成が原因ですべてのユーザーに問題が発生していると考えられる場合は、ポリシーを無効にすることができます。

PowerShell プレビュー

Microsoft Graph PowerShell SDK プレビューモジュールを使用することにより、組織は PowerShell を使ってリスクを管理できます。プレビューモジュールとサンプルコードは、Azure GitHub リポジトリにあります。

Microsoft Graph API を使用する

Microsoft Graph は Microsoft 統合 API エンドポイントであり、Microsoft Entra Identity Protection API のホームです。危険なユーザーとサインインに関する情報を明らかにする API は 3 つあります。riskDetection, riskyUsers, and signIn です。

riskDetection を使用すると、Microsoft Graph に対して、ユーザーやサインインに結び付いているリスク検出とその検出に関連する情報の一覧のクエリを実行できます。

riskyUsers を使用すると、Microsoft Graph に対して、リスクとして検出されたユーザーの Identity Protection に関する情報のクエリを実行できます。

signIn を使用すると、Microsoft Graph に対して、リスク状態、詳細、レベルに関連する特定のプロパティを使用して、Microsoft Entra ID サインインに関する情報のクエリを実行できます。

このセクションでは、Microsoft Graph に接続し、これらの API に対してクエリを実行する方法について説明します。さらに踏み込んだ概要や詳しい解説、Graph Explorer の利用については、Microsoft Graph サイト (https://graph.microsoft.io/) または riskDetection, riskyUsers, and signIn API に関する特定のリファレンスドキュメントを参照してください。

Microsoft Graph に接続する

Microsoft Graph を使用して Identity Protection データにアクセスするには、ドメイン名の取得、新しいアプリの登録の作成、API アクセス許可の構成、および有効な資格情報の構成という 4 つの手順を実行します。

ドメイン名の取得

Microsoft Entra 管理センターにサインインします。
[ID] に移動した後、[設定] を開き、[ドメイン名] を選択します。
.onmicrosoft.com ドメインをメモしておきます。この情報は後の手順で必要になります。

新しいアプリ登録の作成

Microsoft Entra 管理センターで、[ID とアプリケーション]、[アプリの登録] の順に移動します。
[新規登録] を選択します。
[作成] ページで、以下の手順を実行します。
1. [名前] テキストボックスにアプリケーションの名前を入力します (例:Microsoft Entra リスク検出 API)。
2. [サポートされているアカウントの種類] で、その API を使用するアカウントの種類を選択します。
3. [登録] を選択します。
[アプリケーション ID] をコピーします。

API のアクセス許可を構成する

作成したアプリケーションから、 [API のアクセス許可] を選択します。
[構成されたアクセス許可] ページで、上部ツールバーの [アクセス許可の追加] を選択します。
[API アクセスの追加] ページで、[API を選択します] を選択します。
[API を選択します] ページで、[Microsoft Graph] を選んで、[選択] を選択します。
[API アクセス許可の要求] ページで、以下を実行します。
1. [アプリケーションのアクセス許可] を選択します。
2. IdentityRiskEvent.Read.All と IdentityRiskyUser.Read.All の横にあるチェックボックスをオンにします。
3. [アクセス許可の追加] を選択します.
[Grant admin consent for domain](ドメインに管理者の同意を与えます) を選択します。

有効な資格情報を構成する

作成したアプリケーションから、[証明書とシークレット] を選択します。
[クライアントシークレット] で、 [新しいクライアントシークレット] を選択します。
1. クライアントシークレットの [説明] を入力し、組織のポリシーに従って有効期限を設定します。
2. [追加] を選択します。
  
  注意
  
  このキーを紛失した場合、このセクションに戻って新しいキーを作成する必要があります。このキーはだれにも渡さないように注意してください。このキーがあれば、だれでもデータにアクセスすることができます。

Microsoft Graph に対して認証を行って Identity Protection リスク検出 API のクエリを実行する

この時点で次の情報が揃っている必要があります。

テナントのドメインの名前
アプリケーション (クライアント) ID
クライアントシークレットまたは証明書

本人確認を行うために、post 要求を https://login.microsoft.com に送信します。要求本文に次のパラメーターを指定してください。

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

成功すると、この要求では認証トークンが返されます。 API を呼び出すためには、次のパラメーターを持つヘッダーを作成します。

Authorization`="<token_type> <access_token>"

トークンの種類とアクセストークンは、認証時に返されたトークンで確認できます。

このヘッダーは、API URL (https://graph.microsoft.com/v1.0/identityProtection/riskDetections) に対する要求として送信します。

成功した場合の応答は、OData JSON 形式の ID リスク検出とその関連データのコレクションです。必要に応じてこのデータを解析し、処理できます。

サンプル

このサンプルでは、共有シークレットを使用して認証を行う方法を示します。運用環境では、コードにシークレットを格納することは一般的に好ましくありません。組織では、Azure リソース用マネージド ID を使用して、これらの資格情報をセキュリティで保護することができます。

以下に示したコードは、PowerShell を使って認証と API 呼び出しを行う例です。該当するクライアント ID、秘密キー、テナントのドメインを追加してください。

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

    }

すべてのオフラインリスク検出を取得する (riskDetection API)

Identity Protection サインインリスクポリシーを使用すると、リスクがリアルタイムで検出されたときに条件を適用できます。オフラインで検出された場合はどうなるのでしょうか。オフラインで発生したためにサインインリスクポリシーをトリガーしなかった検出を理解するには、riskDetection API に対してクエリを実行できます。

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

危険なサインインポリシー (riskyUsers API) によってトリガーされた MFA チャレンジに合格したすべてのユーザーを取得する

Identity Protection のリスクベースのポリシーが組織に与える価値を把握するには、危険なサインインポリシーによってトリガーされた MFA チャレンジに合格したすべてのユーザーのクエリを実行します。この情報は、Identity Protection がどのユーザーをリスクとして誤検出したのかや、正当なユーザーの中のどのユーザーが AI が危険と見なすアクションを実行しているのかを把握するのに役立つ可能性があります。

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