Identity Protection のデプロイを計画する

Microsoft Entra ID Protection では、ID ベースのリスクを検出して報告し、管理者がこれらのリスクを調査および修復して、組織の安全とセキュリティを維持できるようにします。 これらのリスクを条件付きアクセスなどのツールに送信して、アクセスに関する決定を行うことができます。また、セキュリティ情報とイベント管理 (SIEM) ツールに送り戻して、詳細な調査を行うこともできます。

Screenshot showing the Identity Protection Overview page showing some risky users and sign-ins.

このデプロイ計画は、条件付きアクセス デプロイ計画で導入された概念を拡張するものです。

前提条件

適切な関係者を関わらせる

テクノロジ プロジェクトが失敗した場合、通常、その原因は影響、結果、責任に対する想定の不一致です。 これらの落とし穴を回避するには、適切な利害関係者を関与させ、利害関係者およびそのプロジェクトでの入力と説明責任を文書化することで、プロジェクトでの利害関係者の役割をよく理解させます。

変更の連絡

コミュニケーションは、新しい機能の成功に必要不可欠です。 ユーザー エクスペリエンスがどのように変わるのか、いつ変わるのか、および問題が発生したときにサポートを受ける方法について、ユーザーに事前に連絡する必要があります。

手順 1: 既存のレポートの確認

リスクベースの条件付きアクセス ポリシーをデプロイする前に、Identity Protection レポートを確認することが重要です。 この確認により、見逃した可能性のある既存の疑わしい動作を調査し、リスクがないと判断した場合にこれらのユーザーを安全として無視または確認することができます。

効率を高めるために、手順 3 で説明されているポリシーを使用してユーザーが自己修復できるようにすることをお勧めします。

手順 2: 条件付きアクセス リスク ポリシーの計画

Identity Protection では、条件付きアクセスにリスク シグナルを送信して決定を行い、多要素認証やパスワード変更の要求などの組織ポリシーを適用します。 組織がポリシーを作成する前に、計画する必要のある項目がいくつかあります。

ポリシーの除外

条件付きアクセス ポリシーは強力なツールであり、次のアカウントをポリシーから除外することをお勧めします。

  • 緊急アクセス用アカウントまたは非常用アカウント。テナント全体でアカウントがロックアウトされるのを防ぎます。 発生する可能性は低いシナリオですが、すべての管理者がテナントからロックアウトされた場合に、ご自身の緊急アクセス用管理アカウントを使用してテナントにログインし、アクセスの復旧手順を実行できます。
  • サービス アカウントサービス プリンシパル (Microsoft Entra Connect 同期アカウントなど)。 サービス アカウントは、特定のユーザーに関連付けられていない非対話型のアカウントです。 これらは通常、アプリケーションへのプログラムによるアクセスを可能にするバックエンド サービスによって使用されますが、管理目的でシステムにサインインする場合にも使用されます。 プログラムでは MFA を完了できないため、このようなサービス アカウントは対象外とする必要があります。 サービス プリンシパルによる呼び出しは、ユーザーをスコープとする条件付きアクセス ポリシーではブロックされません。 ワークロード ID の条件付きアクセスを使用して、サービス プリンシパルを対象とするポリシーを定義します。
    • 組織のスクリプトまたはコードでこれらのアカウントが使用されている場合は、それをマネージド ID に置き換えることを検討してください。 これらの特定のアカウントは、一時的な回避策として、ベースライン ポリシーの対象外にすることができます。

多要素認証

ただし、ユーザーがリスクを自己修復するには、リスクが生じる前に Microsoft Entra 多要素認証に登録する必要があります。 詳細については、「Microsoft Entra 多要素認証の展開を計画する」の記事をご覧ください。

認識されたネットワークの場所

条件付きアクセスで名前付きの場所を構成し、Defender for Cloud Apps に VPN 範囲を追加することが重要です。 信頼済みまたは既知としてマークされた名前付きの場所からのサインインにより、Microsoft Entra ID Protection のリスク計算の精度が向上します。 これらのサインインにより、信頼済みまたは既知としてマークされた場所から認証を受けると、ユーザーのリスクが低下します。 これにより、環境内の一部の検出で誤検知が減少します。

レポート専用モード

レポート専用モードは、条件付きアクセス ポリシーの状態です。このモードを使うと、管理者が環境で条件付きアクセス ポリシーを適用する前に、その影響を評価することができます。

手順 3: ポリシーの構成

Identity Protection MFA 登録ポリシー

Identity Protection 多要素認証登録ポリシーを使用して、ユーザーが Microsoft Entra 多要素認証を使用する前に登録できるようにします。 このポリシーを有効にするには、記事「方法: Microsoft Entra 多要素認証登録ポリシーを構成する」の手順に従います。

条件付きアクセス ポリシー

サインイン リスク - ほとんどのユーザーは、追跡できる正常な動作をしています。この規範から外れた場合は、そのユーザーにサインインを許可すると危険である可能性があります。 そのユーザーをブロックしたり、多要素認証を実行してユーザーが本人であることを証明するように求めたりすることが必要な場合もあります。 まず、これらのポリシーのスコープを管理者のみに設定することをお勧めします。

ユーザー リスク - Microsoft では、研究者、法執行機関、Microsoft のさまざまなセキュリティ チーム、その他の信頼できる情報源と協力して、漏洩したユーザー名とパスワードのペアを調査しています。 これらの脆弱なユーザーが検出された場合は、多要素認証を実行してからパスワードをリセットすることをユーザーに要求することをお勧めします。

記事「リスク ポリシーの構成と有効化」では、これらのリスクに対処する条件付きアクセス ポリシーを作成するためのガイダンスを提供します。

手順 4: 監視と継続的な運用ニーズ

メール通知

ユーザーにリスクのフラグが設定されたときに応答できるよう通知を有効にして、すぐに調査を開始できるようにします。 また、週単位のダイジェスト メールを設定して、その週のリスクの概要を確認することもできます。

監視と調査

Identity Protection ブックは、テナント内のパターンを監視および検索するのに役立ちます。 このブックで傾向、および条件付きアクセス レポート専用モードの結果を監視して、行うべき変更 (名前付きの場所への追加など) があるかどうかを確認します。

Microsoft Defender for Cloud Apps では、組織が出発点として使用できる調査フレームワークが提供されます。 詳細については、記事「異常検出アラートを調査する方法」を参照してください。

また、Identity Protection API を使用して他のツールにリスク情報をエクスポートすることで、セキュリティ チームがリスク イベントを監視してアラートを生成できるようにすることもできます。

テスト中に、いくつかの脅威をシミュレートして調査プロセスをテストすることをお勧めします。

次のステップ

リスクとは