Identity Protection のデプロイを計画する
Microsoft Entra ID Protection では、ID ベースのリスクを検出して報告し、管理者がこれらのリスクを調査および修復して、組織の安全とセキュリティを維持できるようにします。 これらのリスクを条件付きアクセスなどのツールに送信して、アクセスに関する決定を行うことができます。また、セキュリティ情報とイベント管理 (SIEM) ツールに送り戻して、詳細な調査を行うこともできます。
このデプロイ計画は、条件付きアクセス デプロイ計画で導入された概念を拡張するものです。
前提条件
- Microsoft Entra ID P2 か試用版のライセンスが有効になっている稼働中の Microsoft Entra テナント。 必要に応じて、無料で作成できます。
- 条件付きアクセス ポリシーに Identity Protection のリスクを含めるには、Microsoft Entra ID P2 が必要です。
- Identity Protection を操作する管理者は、実行しているタスクに応じて、次のロールの割り当てを 1 つ以上持っている必要があります。 最小特権のゼロ トラスト原則に従う場合は、Privileged Identity Management (PIM) を使用して、Just-In-Time で特権ロールの割り当てをアクティブ化することを検討してください。
- Identity Protection と条件付きアクセスのポリシーおよび構成を読み取る
- Identity Protection を管理する
- 条件付きアクセス ポリシーを作成または変更する
- 実際のユーザーにデプロイする前に、ポリシーが期待どおりに機能することを確認できるテスト ユーザー (管理者以外)。 ユーザーを作成する必要がある場合は、クイックスタート: Microsoft Entra ID への新しいユーザーの追加に関する記事を参照してください。
- 管理者以外のユーザーが所属するグループ。 グループを作成する必要がある場合は、「Microsoft Entra ID でグループを作成してメンバーを追加する」をご覧ください。
適切な関係者を関わらせる
テクノロジ プロジェクトが失敗した場合、通常、その原因は影響、結果、責任に対する想定の不一致です。 これらの落とし穴を回避するには、適切な利害関係者を関与させ、利害関係者およびそのプロジェクトでの入力と説明責任を文書化することで、プロジェクトでの利害関係者の役割をよく理解させます。
変更の連絡
コミュニケーションは、新しい機能の成功に必要不可欠です。 ユーザー エクスペリエンスがどのように変わるのか、いつ変わるのか、および問題が発生したときにサポートを受ける方法について、ユーザーに事前に連絡する必要があります。
手順 1: 既存のレポートの確認
リスクベースの条件付きアクセス ポリシーをデプロイする前に、Identity Protection レポートを確認することが重要です。 この確認により、見逃した可能性のある既存の疑わしい動作を調査し、リスクがないと判断した場合にこれらのユーザーを安全として無視または確認することができます。
効率を高めるために、手順 3 で説明されているポリシーを使用してユーザーが自己修復できるようにすることをお勧めします。
手順 2: 条件付きアクセス リスク ポリシーの計画
Identity Protection では、条件付きアクセスにリスク シグナルを送信して決定を行い、多要素認証やパスワード変更の要求などの組織ポリシーを適用します。 組織がポリシーを作成する前に、計画する必要のある項目がいくつかあります。
ポリシーの除外
条件付きアクセス ポリシーは強力なツールであり、次のアカウントをポリシーから除外することをお勧めします。
- 緊急アクセス用アカウントまたは非常用アカウント。テナント全体でアカウントがロックアウトされるのを防ぎます。 発生する可能性は低いシナリオですが、すべての管理者がテナントからロックアウトされた場合に、ご自身の緊急アクセス用管理アカウントを使用してテナントにログインし、アクセスの復旧手順を実行できます。
- 詳しくは、「Microsoft Entra ID で緊急アクセス用管アカウントを管理する」をご覧ください。
- サービス アカウントとサービス プリンシパル (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 を使用して他のツールにリスク情報をエクスポートすることで、セキュリティ チームがリスク イベントを監視してアラートを生成できるようにすることもできます。
テスト中に、いくつかの脅威をシミュレートして調査プロセスをテストすることをお勧めします。