次の方法で共有

ID 保護のデプロイを計画する

  • [アーティクル]

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

この展開計画は、条件付きアクセスの展開計画で導入された概念を拡張します。

前提条件

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

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

変更の連絡

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

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

リスクベースの条件付きアクセス ポリシーを展開する前に、ID 保護レポートを確認することが重要です。 このレビューは、既存の疑わしい動作を調査する機会をもたらします。 リスクでないと判断した場合は、そのリスクを無視するか、これらのユーザーが安全であることを確認することができます。

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

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

ID 保護によりリスク シグナルが条件付きアクセスに送信され、決定が下されて組織のポリシーが適用されます。 このポリシーでは、ユーザーが多要素認証またはセキュリティで保護されたパスワード変更を実行する必要があったりします。 組織がポリシーを作成する前に計画する必要のある項目がいくつかあります。

ポリシーの除外

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

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

多要素認証

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

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

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

レポート専用モード

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

手順 3: ポリシーの構成

ID 保護 MFA 登録ポリシー

ID 保護の多要素認証登録ポリシーを使用すると、ユーザーが Microsoft Entra 多要素認証の使用が必要になる前にその認証に登録されるようにすることができます。 「Microsoft Entra 多要素認証登録ポリシーを構成する方法」の記事の手順に従い、このポリシーを有効にします。

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

ログイン リスク - ほとんどのユーザーは、追跡できる正常な行動をします。この規範から逸脱た場合、そのユーザーのログインを許可するだけでも危険である可能性があります。 そのユーザーをブロックしたり、多要素認証を実行してユーザーが本人であることを証明するように求めたりすることができます。 まず、これらのポリシーをユーザーのサブセットにスコープします。

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

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

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

メール通知

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

監視と調査

リスクベースのアクセス ポリシーの影響分析ブックは、管理者がリスクベースの条件付きアクセス ポリシーを作成する前にユーザーへの影響を把握するのに役立ちます。

ID 保護ブックは、テナント内のパターンを監視するおよび探すのに役立ちます。 ブックで動向と条件付きアクセス レポート専用モードの結果を監視し、行うべき変更 (たとえば、ネーム ドロケーションの追加など) があるかどうかを確認します。

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

ID 保護 API を使用して他のツールにリスク情報をエクスポートすることにより、セキュリティ チームがリスク イベントを監視してアラートを出せるようします。

テスト中、いくつかの脅威をシミュレーションして調査プロセスをテストすることができます。

次のステップ

リスクとは