セキュリティの迅速な近代化計画
この迅速な近代化計画 (RAMP) は、Microsoft の推奨される 特権アクセス戦略を迅速に導入するのに役立ちます。
このロードマップは、 特権アクセスのデプロイ ガイダンスで確立された技術的な制御に基づいています。 これらの手順を完了し、この RAMP に記載されている手順を使用して、組織の統制を構成します。
Note
組織は、既に展開または構成されているアカウントのセキュリティ上のリスクを持つことが多いため、これらの手順の多くには動的な緑色/ブラウンフィールドがあります。 このロードマップでは、最初に新しいセキュリティ上のリスクの蓄積しないようにし、その後、既に蓄積されている残りの項目をクリーンアップします。
ロードマップを進める過程で、Microsoft セキュア スコアを利用して、時間の経過と共にジャーニーの中でさまざまな項目を追跡し、類似の組織の他のユーザーと比較することができます。 Microsoft セキュア スコアの詳細については、記事「セキュア スコアの概要」を参照してください。
この RAMP の各項目は、目標とキーの結果 (OKR) の手法を基にして構築される形式を使用して追跡および管理されるイニシアチブとして構成されています。 各項目には、何を(目標)、なぜ、誰が、そどうやって、そしてどのように測定するか (主要な結果) が含まれています。 一部の項目では、プロセスとユーザーの知識やスキルを変更する必要がありますが、他の項目はより単純なテクノロジ変更です。 これらのイニシアティブの多くには従来の IT 部門外のメンバーが含まれており、彼らをこれらの変更の意思決定と実装に組み入れて、組織内に確実に統合されるようにする必要があります。
組織として連携し、パートナーシップを作り上げて、従来はこのプロセスの一部ではなかったユーザーを教育することが重要です。 組織全体で同意を形成して維持することが非常に重要です。それがなければ多くのプロジェクトは失敗します。
特権アカウントの分離と管理
緊急アクセス アカウント
- 何を: 緊急時に Microsoft Entra 組織から誤ってロックアウトされないようにします。
- なぜ: 緊急時のアクセス アカウントは、滅多に使われず、侵害されると組織に大きな損害を与えるものですが、同時に、それを組織で使用できることは、それが必要になる少数のシナリオにおいて非常に重要です。 予想されるイベントと予想されないイベントの両方に対応する、アクセスの継続性に関する計画があることを確認します。
- 誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- スポンサーシップ: このイニシアティブは通常、CISO、CIO、または ID 担当部長によって後援されます
- 実行: このイニシアティブは次のことを含む共同作業です。
- ポリシーと標準 チームのドキュメントの明確な要件と標準
- 変化を実装するためのID とキーの管理または中央 IT 運用
- コンプライアンスを確保するためのセキュリティ コンプライアンス管理による監視
- どうやって: Microsoft Entra ID での緊急アクセス アカウントの管理に関するガイドに従ってください。
- 主要な結果を測定する:
- 確立済みの緊急アクセス プロセスは、組織のニーズを満たす Microsoft のガイダンスに基づいて設計されています
- メンテナンスされた緊急アクセスは過去 90 日以内にレビューおよびテストされています
Microsoft Entra Privileged Identity Management を有効にします。
- 何を: Microsoft Entra 運用環境で Microsoft Entra Privileged Identity Management (PIM) を使用して、特権アカウントを検出してセキュリティで保護する
- なぜ: Privileged Identity Management では、時間ベースおよび承認ベースのロールのアクティブ化を提供して、過剰、不要、または誤用であるアクセス許可のリスクを軽減します。
- 誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- スポンサーシップ: このイニシアティブは通常、CISO、CIO、または ID 担当部長によって後援されます
- 実行: このイニシアティブは次のことを含む共同作業です。
- ポリシーと標準 チームのドキュメントの明確な要件と標準 (このガイダンスに基づく)
- 変化を実装するためのID とキーの管理または中央 IT 運用
- コンプライアンスを確保するためのセキュリティ コンプライアンス管理による監視
- 方法: 記事「Microsoft Entra Privileged Identity Management (PIM) のデプロイ」のガイダンスに従って Microsoft Entra Privileged Identity Management をデプロイおよび構成します。
- 主要な結果を測定する: 適用可能な特権アクセス ロールの100% が Microsoft Entra PIM を使用しています
特権アカウントの識別と分類 (Microsoft Entra ID)
何を:特権セキュリティ レベルを必要とする、ビジネスに大きな影響を与えるすべてのロールとグループを識別します (即座または時間の経過と共に)。 これらの管理者には、後の手順「特権アクセスの管理」で個別のアカウントが必要になります。
なぜ: この手順は、個別のアカウントと特権アクセスの保護を必要とする人数を識別して最小限に抑えるために必要です。
誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- スポンサーシップ: このイニシアティブは通常、CISO、CIO、または ID 担当部長によって後援されます
- 実行: このイニシアティブは次のことを含む共同作業です。
- ポリシーと標準 チームのドキュメントの明確な要件と標準 (このガイダンスに基づく)
- 変化を実装するためのID とキーの管理または中央 IT 運用
- コンプライアンスを確保するためのセキュリティ コンプライアンス管理による監視
どうやって: Microsoft Entra Privileged Identity Management を有効にした後、少なくとも組織のリスク ポリシーに基づいて、次の Microsoft Entra の役割に属しているユーザーを表示します。
- グローバル管理者
- 特権ロール管理者
- Exchange 管理者
- SharePoint 管理者
すべての管理者ロールの一覧については、「Microsoft Entra ID での管理者ロールのアクセス許可」をご覧ください。
このようなロールの不要になったアカウントがあれば削除します。 次に、管理者ロールに割り当てられている残りのアカウントを分類します。
- 管理ユーザーに割り当てられますが、電子メールの読み取りや応答など、管理者以外の生産性を確保するためにも使用されます。
- 管理ユーザーに割り当てられ、管理目的にのみ使用されている
- 複数のユーザー間で共有される
- 非常時の緊急アクセス シナリオ用
- 自動スクリプト用
- 外部ユーザー用
Microsoft Entra Privileged Identity Management が組織内にない場合は、PowerShell API を使用できます。 組織がサブスクライブしているすべてのクラウド サービスで同じアクセス許可を持っているため、グローバル管理者ロールから始めます。 これらのアクセス許可は、Microsoft 365 管理センター、Azure portal、または Microsoft PowerShell の Azure AD モジュールのいずれで割り当てられた場合でも付与されます。
- 主要な結果を測定する: 過去 90 日以内に特権アクセス ロールのレビューと ID の確認が完了しました
個別のアカウント (オンプレミスの AD アカウント)
何を: まだ行っていない場合は、オンプレミスの特権管理者アカウントをセキュリティで保護する この段階には次のものが含まれます。
- オンプレミスの管理タスクを実行する必要があるユーザー用に個別の管理者アカウントを作成する
- Active Directory 管理者向けの特権アクセス ワークステーションを配置する
- ワークステーションとサーバーに対して一意のローカル管理者パスワードを作成する
なぜ: 管理タスクに使用されるアカウントのセキュリティ強化。 管理者アカウントでメールを無効にし、個人の Microsoft アカウントを許可しないようにする必要があります。
誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- スポンサーシップ: このイニシアティブは通常、CISO、CIO、または ID 担当部長によって後援されます
- 実行: このイニシアティブは次のことを含む共同作業です。
- ポリシーと標準 チームのドキュメントの明確な要件と標準 (このガイダンスに基づく)
- 変化を実装するためのID とキーの管理または中央 IT 運用
- コンプライアンスを確保するためのセキュリティ コンプライアンス管理による監視
どうやって:管理特権が承認されたすべてのユーザーは、ユーザー アカウントとは別に、管理機能を実行するための個別のアカウントを持っている必要があります。 これらのアカウントをユーザー間で共有しないでください。
- 標準ユーザー アカウント: 電子メール、Web 閲覧、基幹業務アプリケーションの使用など、標準ユーザー タスクを実行するための標準ユーザー権限が付与されます。 これらのアカウントには管理者特権は付与されません。
- 管理者アカウント: 適切な管理者特権が割り当てられている担当者用に作成された個別のアカウントです。
主要な結果を測定する: オンプレミスの特権を持つユーザーの100% が個別の専用アカウントを持ちます
Microsoft Defender for Identity
何を: Microsoft Defender for Identity は、オンプレミスの信号とクラウド インサイトを組み合わせて、イベントの監視、保護、および調査を簡略化された形式で行います。これにより、セキュリティ チームは、次の機能を備えた ID インフラストラクチャに対する高度な攻撃を検出できます。
- 学習ベースの分析を使用してユーザー、エンティティの動作、アクティビティを監視します
- Active Directory に格納されているユーザー ID と資格情報を保護します
- ユーザーの疑わしいアクティビティおよび kill チェーン全体での高度な攻撃を識別して調査します
- 高速なトリアージのためにシンプルなタイムラインで明確なインシデント情報を提供します
なぜ: 現代の攻撃者が長期間にわたって検出されない可能性があります。 多くの脅威は、ID 環境全体を密接に把握せずに見つけるのは困難です。
誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- スポンサーシップ: このイニシアティブは通常、CISO、CIO、または ID 担当部長によって後援されます
- 実行: このイニシアティブは次のことを含む共同作業です。
- ポリシーと標準 チームのドキュメントの明確な要件と標準 (このガイダンスに基づく)
- 変化を実装するためのID とキーの管理または中央 IT 運用
- コンプライアンスを確保するためのセキュリティ コンプライアンス管理による監視
方法: Microsoft Defender for Identity を展開して有効にし、開いているアラートをレビューします。
主要な結果を測定する: すべての開いているアラートが適切なチームによってレビューされ、軽減されます。
資格情報管理エクスペリエンスの向上
セルフサービス パスワード リセットと統合されたセキュリティ情報の登録の実装と文書化
- 何を: 組織でセルフサービス パスワード リセット (SSPR) を有効にして構成し、統合されたセキュリティ情報の登録エクスペリエンスを有効にします。
- なぜ: 登録後、ユーザーは自分のパスワードをリセットできます。 統合されたセキュリティ情報の登録エクスペリエンスにより、ユーザー エクスペリエンスが向上し、Microsoft Entra 多要素認証 およびセルフサービス パスワード リセットを登録できるようになります。 これらのツールを一緒に使用することで、ヘルプデスクのコストを削減し、ユーザーの満足度を高めることができます。
- 誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- スポンサーシップ: このイニシアティブは通常、CISO、CIO、または ID 担当部長によって後援されます
- 実行: このイニシアティブは次のことを含む共同作業です。
- ポリシーと標準 チームのドキュメントの明確な要件と標準 (このガイダンスに基づく)
- 変化を実装するためのID とキーの管理または中央 IT 運用
- コンプライアンスを確保するためのセキュリティ コンプライアンス管理による監視
- 中央 IT 運用 ヘルプデスクのプロセスが更新され、担当者がトレーニングを行っています
- どうやって: SSPR を有効にして展開する方法については、「Microsoft Entra のセルフサービス パスワード リセットの展開を計画する」を参照してください。
- 主要な結果を測定する: セルフサービス パスワード リセットが完全に構成され、組織で使用できます
管理者アカウントを保護する - Microsoft Entra ID の特権を持つユーザーに対して MFA/パスワードレスを有効にし、要求する
何を: 強力な多要素認証を使用するには、Microsoft Entra ID のすべての特権アカウントが必要です。
なぜ: Microsoft 365 のデータとサービスへのアクセスを保護します。
誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
どうやって: Microsoft Entra 多要素認証 (MFA) を有効にし、その他のすべての高度な特権を持つシングル ユーザー非フェデレーション管理者アカウントを登録します。 1 つまたは複数の Microsoft Entra 管理者ロールに永続的に割り当てられているすべての個人ユーザーには、サインイン時に多要素認証を要求します。
管理者は、一意で長kう複雑なパスワードと組み合わせて、FIDO2 セキュリティ キーや Windows Hello for Business などのパスワードレス サインイン方式を使用する必要があります。 組織のポリシー ドキュメントを使用して、この変更を適用します。
次の記事「Microsoft Entra 多要素認証の展開を計画」および「Microsoft Entra ID でパスワードレス認証の展開を計画」のガイダンスに従います。
- 主要な結果を測定する: 特権を持つユーザーの 100% が、すべてのログオンにパスワードレス認証または強力な多要素認証方式を使用しています。 多要素認証の説明については、「特権アクセス アカウント」を参照してください。
特権ユーザー アカウントのレガシ認証プロトコルをブロックする
何を: 特権ユーザー アカウントのレガシ認証プロトコルをブロックする
なぜ: 組織は、これらのレガシ認証プロトコルをブロックする必要があります。これらには多要素認証を適用できないためです。 レガシ認証プロトコルを有効にしたままにすると、攻撃者のエントリポイントを作ることになります。 レガシ アプリケーションによっては、これらのプロトコルに依存している場合があります。また、組織は特定のアカウントに固有の例外を設けることもできます。 これらの例外は、追跡し、より細かい監視コントロールを実装する必要があります。
誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- スポンサーシップ: このイニシアティブは通常、CISO、CIO、または ID 担当部長によって後援されます
- 実行: このイニシアティブは次のことを含む共同作業です。
- ポリシーと標準: 明確な要件を確立する
- ID とキーの管理または中央 IT 運用中央 IT 運用によるポリシーの実装
- コンプライアンスを確保するためのセキュリティ コンプライアンス管理による監視
方法: 組織内のレガシ認証プロトコルをブロックするには、「方法: 条件付きアクセスを使用して Microsoft Entra ID へのレガシ認証をブロックする」のガイダンスに従ってください。
主要な結果を測定する:
- ブロックされているレガシ プロトコル:すべてのレガシ プロトコルは、承認された例外のみを含むすべてのユーザーに対してブロックされます。
- 例外 は90 日ごとにレビューされ、1 年以内に完全に期限切れとなります。 アプリケーションの所有者は、最初の例外の承認の 1 年以内にすべての例外を修正する必要があります
アプリケーションへの同意プロセス
- 何を: エンドユーザーによる Microsoft Entra アプリケーションへのエンドユーザー同意を無効にする
Note
この変更により、組織のセキュリティと ID 管理チームの意思決定プロセスを一元化する必要があります。
- 何を: 組織のデータに故意にアクセスできるアプリに同意することで、ユーザーが誤って組織のリスクを作成する可能性があります。
- 誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- どうやって: 記事「アプリケーションに対する同意の管理と同意要求の評価」のガイダンスに従って、データへのアクセス権を持つアプリケーションの一元的な可視性と制御を維持するための、一元化された同意プロセスを確立します。
- 主要な結果を測定する: エンド ユーザーが Microsoft Entra アプリケーションへのアクセスに同意できない
アカウントとサインインのリスクをクリーンアップする
- 何を: Microsoft Entra ID 保護 を有効にし、検出されたリスクをすべてクリーンアップします。
- なぜ: 危険なユーザーとサインインの動作が組織に対する攻撃の原因になる可能性があります。
- 誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- スポンサーシップ: このイニシアティブは通常、CISO、CIO、または ID 担当部長によって後援されます
- 実行: このイニシアティブは次のことを含む共同作業です。
- ポリシーと標準 チームのドキュメントの明確な要件と標準 (このガイダンスに基づく)
- 変化を実装するためのID とキーの管理または中央 IT 運用
- コンプライアンスを確保するためのセキュリティ コンプライアンス管理による監視
- 中央 IT 運用 関連するサポートの呼び出しのためにヘルプデスクのプロセスが更新されており、担当者がトレーニングを行っています
- どうやって: ユーザーとサインインのリスクを監視および管理するプロセスを作成します。 Microsoft Entra 多要素認証と SSPR を使用して修復を自動化するか、またはブロックして管理者の介入を必要とするかを決定します。 記事「方法: リスク ポリシーを構成して有効にする」のガイダンスに従います。
- 主要な結果を測定する: 宛先指定されないユーザーとサインインのリスクがゼロになっています。
Note
新しいサインイン リスクの発生をブロックするには、条件付きアクセス ポリシーが必要です。 「特権アクセスのデプロイ」の「条件付きアクセス」セクションを参照してください。
管理ワークステーションの初期展開
- 何を: Microsoft Entra ID を管理しているアカウントなどの特権アカウントには、管理タスクを実行する専用のワークステーションがあります。
- なぜ: 特権管理タスクが完了したデバイスは、攻撃者の対象です。 アカウントだけでなく、これらのアセットは、攻撃対象エリアを小さくするために重要です。 この分離により、電子メールや Web 閲覧などの生産性に関連するタスクに対する一般的な攻撃に晒されにくくなります。
- 誰が: 通常イニシアティブは、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。
- どうやって: 最初のデプロイは、「特権アクセスのデプロイ」の説明に従って、エンタープライズ レベルにする必要があります。
- 主要な結果を測定する: すべての特権アカウントには、重要なタスクを実行する専用のワークステーションがあります。
Note
この手順により、セキュリティ ベースラインが迅速に確立され、できるだけ早く専門レベルおよび特権レベルに上げる必要があります。