次の方法で共有

ID 保護の展開の計画

  • [アーティクル]

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

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

前提条件

適切な利害関係者とやり取り

テクノロジ プロジェクトが失敗すると、通常はその影響、結果、責任に対する想定の不一致が原因になります。 これらの落とし穴を回避するには、適切な利害関係者とやり取りし、利害関係者、利害関係者のプロジェクトに対するインプット、責任を文書化することにより、プロジェクトで利害関係者の役割をよく理解されていることを確認します。

変更の連絡

コミュニケーションは、新しい機能の成功には必要不可欠です。 ユーザーのエクスペリエンスがどのように変化するか、変化するタイミング、問題が発生したときにサポートを求める方法について、ユーザーと積極的に連絡する必要があります。

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

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

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

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

ID 保護は、リスク信号を条件付きアクセスに送信し、意思決定をして組織方針を実施します。 このポリシーは、ユーザーが多要素認証または安全なパスワード変更の実行を求める場合があります。 組織がポリシーを作成する前に、計画する必要のある項目がいくつかあります。

ポリシーの除外

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

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

多要素認証

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

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

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

レポート専用モード

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

手順 3: ポリシーの構成

ID 保護の MFA 登録ポリシー

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

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

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

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

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

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

メール通知

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

監視と調査

リスクベースのアクセス ポリシーの影響分析ブックは、管理者がリスクベースの条件付きアクセス ポリシーを作成する前にユーザーへの影響を理解できるようにします。

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

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

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

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

次のステップ

リスクとは