フェーズ 1 - ID コントロール プレーンをセキュリティで保護する

この記事は、「 特権アクセス アーキテクチャの実装 」ソリューション ガイドの一部です。

特権アクセスでは、ID システム、クラウドコントロール プレーン、ビジネスクリティカルな資産を直接制御できるため、ほとんどの組織で重大なセキュリティ リスクが発生します。

セキュリティで 保護された特権アクセス アーキテクチャ が、このリスクを軽減し、機密性の高いシステムに対する制御を強化することで、ビジネス シナリオ ( 重要なビジネス資産の保護 ) で重要な役割を果たすしくみについて説明します。

この記事は、「 特権アクセス アーキテクチャ の実装」ソリューションのフェーズ 1 の実装に役立ちます。 このフェーズでは、特権 ID、ロールの割り当て、および承認された昇格パスを定義して保護することで、ID コントロール プレーンをセキュリティで保護します。

最初にフェーズ 1 を実装することが重要です。 特権アクセス デバイスをセキュリティで保護し、条件付きアクセス ポリシーを適用し、特権アクセスを監視する後のフェーズは、クリーンで適切に管理された ID コントロール プレーンがあることによって異なります。

保護の目標

フェーズ 1 では、特権アクセスが次のことが保証されます。

  • 明示的: 定義された昇格パスを介してのみ特権を付与します。 暗黙的または偶発的にしないでください。
  • 一時的: 特権は自動的に期限切れになります。
  • 厳密に認証: 昇格には強力な認証が必要です。
  • 監査可能: すべての特権の変更と昇格をログに記録します。
  • 回復可能:制御を弱めることなく緊急アクセスを提供します。

保護スコープ

フェーズ 1 では、特権アクセスの 2 つの基本コンポーネントに重点を置いています。

  • 特権 ID: 次のような特権アクションを実行できる ID。

    • 専用の管理ユーザー アカウント
    • 管理グループ
    • サービス プリンシパルとマネージド ID
    • Azure RBAC ロール割り当て
    • 緊急時用(ブレークグラス)アクセス用アカウント(存在しない場合は)
  • 承認された昇格パス: 次のような特権のない状態にユーザーが移動できるようにするメカニズム。

    • - Privileged Identity Management (PIM) を使用したタイム バインド ロールのアクティブ化
    • 機密性の高いロールの承認ワークフロー
    • 明示的な管理セッション
  • 緊急回復アクセス: Break-glass アカウントがまだ存在しない場合は構成します。

これらのコンポーネントはコントロール プレーンで動作します。 侵害された場合、攻撃者はデバイスやアクセス ポリシーに触れることなく、自分自身に特権アクセスを許可できます。

軽減されたリスク

リスク 重要な理由 フェーズ 1 の軽減策
特権 ID の制御されていない作成 攻撃者は、気付かれないように新しい管理者アカウントまたはロールの割り当てを作成します。 権限のある特権 ID とロールを確立します。
ID システムを管理できるユーザーを制限します。
ID システムを特権資産として扱います。
気付かれない権限昇格 グループ、RBAC、または入れ子になった割り当てによって得られる特権。 ロールの合理化、グループベースの割り当ての使用、永続的なアクセスの削除。
永続的な(常時の)管理アクセス 盗まれた資格情報は永続的な特権を保持します。 永続的特権を期限付きの昇格に置き換えます。
弱い標高パスまたは暗黙的な標高パス 攻撃者は管理者と同じパスを使用します。 セキュリティで保護された、明示的で監査可能な昇格ワークフローを定義する
下流の保護機能の回避 デバイスまたはポリシーの適用前に取得された特権。 まず、IDコントロールプレーンを保護。
回復不可能な ID 侵害 コントロールを取り戻すための安全な方法はありません。 保護された緊急アクセス アカウントを作成します。
低いIDセキュリティ態勢 弱い ID コントロールは、それ以降のすべてのフェーズを損ないます。 ID システムを最高のセキュリティ レベルに引き上げます。

フェーズの結果

このフェーズを完了した後:

  • すべての特権アクセスは、既知の明示的な ID とロールに関連付けられます。
  • すべての特権は、一時的、監査可能、意図的です。
  • 永続的な管理アクセスは削除されます。
  • ID システムは特権資産として扱われます。
  • 制御を弱めることなく、ID 侵害からの復旧が可能です。
  • モダン化中に新しい特権リスクは導入されません。

このフェーズでは、監査と最新化を継続しながら、新しい特権リスクの作成も停止します。

前提条件

フェーズ 1 の構成を開始する前に、次の前提条件に注意してください。

ドキュメントを確認します。

組織内で:

  • 有効な、自分が所有する Microsoft Entra ID テナントを保有していることを確認してください。 特権 ID ガバナンス向けに Microsoft Entra ID P2 を推奨しました。
  • このソリューションでは、Microsoft 365 Enterprise E5 があることを前提としています。 詳細については、「Microsoft 365 Enterprise のライセンスを参照してください。
  • 少なくとも 2 つの 緊急アクセス アカウントが 定義されていることを確認します。
  • ID ガバナンスとロール管理の明確な責任所在
  • セキュリティで保護された管理者アカウントを作成すると、セットアップ時に使用されるワークステーションに公開されます。 既知の安全なデバイスから初期構成が実行されていることを確認します。

手順 1: 特権アクセスを監査する

特権 ID とアクセス パスの完全なインベントリを確立します。 次のソースを監査します。

Source 詳細情報
Microsoft Entra ディレクトリ ロール ID コントロール プレーンで ID、アクセス、または信頼の境界を変更することで、テナントの支配につながる可能性がある 特権ロール を直接または間接的に識別します。

各ロールについて:
- 直接割り当てとグループベースの割り当てを識別します。
- 永続的な割り当てと PIM の適格な割り当てを特定する
- 現在のアクティブ化状態をキャプチャします。
グループベースの特権 ユーザーだけを見ていると見逃してしまう、間接的に特権を付与されている対象を確認します。

- 入れ子グループのメンバーシップを確認する
- ユーザー、サービス プリンシパル、およびマネージド ID を識別する
- 特権の継承方法を記録します。
Azure RBAC ロール これらの特権 ID がディレクトリ自体の外部で実行できることを確認します。

管理グループ、サブスクリプション、およびリソース スコープでの割り当てを監査します。

広範なアクセス許可またはカスケードアクセス許可を持つ ID を識別します。
非人間のアイデンティティ 次のような、特権アクセス パスの一部である非人間 ID を確認します。

サービス プリンシパルとマネージド ID
自動化アカウントとスクリプト
テナントまたはリソース制御を使用したアプリケーションのアクセス許可。

その結果、権限のある特権 ID インベントリが生成されます。

ディレクトリ ロールを特定する

ID、認証、またはテナント全体の構成を変更できるユーザーを監査します。

  1. Microsoft Entra 管理センターで、Entra ID>Roles & Admins に移動します。

  2. [すべてのロール] を選択します。 このページには、グローバル管理者や特権ロール管理者などのテナント全体の管理者ロールを含む、すべての組み込みおよびカスタムのMicrosoft Entra ディレクトリ ロールが一覧表示されます。

    • 特権ロールとは、ロールの割り当て、セキュリティ/認証の変更、アプリ、デバイス、またはセキュリティ ポリシーの管理を行うことができるロールです。
    • 特権組み込みロールの完全な一覧も ドキュメントで入手できます。
  3. 各特権ロールについて、まず直接の割り当てを確認してください。 直接割り当てられたプリンシパル (ユーザー、グループ、またはサービス プリンシパル (アプリ/マネージド ID)) ごとに、ロールの付与方法と現在の状態を確認します。

    • 永続的な割り当ては、ロールが常にオンになっていることを意味します。 ID はサインインし、アクティブ (永続的) 状態で既に特権を持っています。 これは明らかに高リスクです。
    • PIM の適格な割り当てとは、そのロールは利用可能ではあるものの、有効化されるまではアクティブではないことを意味します。 ユーザーはロールをアクティブにする必要があります。 通常は時間制限があり、多くの場合、正当な理由が必要です。 ユーザーが特権を持つことができますが、現在アクティブ化されていない場合、状態は アクティブ または 有資格 になります。
  4. 次に、グループの割り当てに切り替えます。 これは、グループを介して間接的に割り当てられている特権をチェックするため、重要です。

  5. 特権ロールが割り当てられている各グループを開きます。

  6. グループ メンバーを展開し、入れ子になったグループを展開し、ユーザー、サービス プリンシパル、マネージド ID を記録します。

  7. 各 ID について、特権の保持方法を確認します。

    • ロールは、グループまたは入れ子になったグループを介して割り当てられますか?
    • このロールは恒久的ですか、それとも PIM の対象ですか。
    • 現在の状態は何ですか?

この手順を完了すると、ID コントロール プレーンがキャプチャされ、Microsoft Entraの権限のある特権 ID インベントリが作成されます。

Azure RBAC ロールを特定する

特権を持つ ID がわかったら、Microsoft Entra ディレクトリの外部で実行できることを確認しましょう。 他にどこを制御でき、どの範囲まで可能ですか?

  1. 特定した特権プリンシパルごとに、ロールを決定します。

  2. 最も高いスコープ (管理グループ) から開始します。

    1. Azure ポータル >管理グループで、**[アクセス制御 (IAM)] >ロール割り当てに移動します。
    2. Filter>割り当て先を使用して、プリンシパル名を検索します。
    3. ロール名やスコープなど、すべての結果を記録します。

    ここで ID が見つかった場合、それらは Azure に対する広範な制御権限を持っていることを示しています。これは、管理グループ スコープで割り当てられた Azure RBAC ロールが、すべての子サブスクリプションとリソースに継承されるためです。

  3. 次に、Azure portal >Subscriptions の場合と同じ手順に従います。

    サブスクリプション レベルで割り当てられたAzure RBAC ロールを持つ ID は特権を持ち、アクセス権を付与または委任できます。

  4. 管理グループまたはサブスクリプション レベルで ID が見つからなかった場合は、Azure ポータル >リソース グループで同じ手順でリソース グループ レベルで確認できます。

  5. また、プリンシパルが Key Vault、ストレージ アカウント、仮想マシン、Automation アカウントなどの戦略的な個々のリソースを制御できるかどうかを確認することもできます。 これを行うには、アクセス制御 (IAM)>個々のリソースごとに割り当てられていることを確認します。

結果を記録する

  1. 識別したアカウントごとに、マッピング テーブルに監査の詳細をキャプチャします。

  2. 広範な特権を持つリスクの高いアカウントを特定し、ロール スコープ (ブラスト半径) と作業の種類に関する情報を提供するマッピング テーブルを作成します。

    アカウント Entra ロール Azure RBAC ロール Scope 特権のある作業
    alice@contoso.com グローバル管理者 Owner Sub1、Sub2 ユーザー、ロール、サブスクリプションを管理します。
  3. アカウントの観察された動作の詳細を追加する場合は、次のことができます。

    1. アプリ、クライアント エンドポイント、認証フローに関する情報については、サインイン ログを確認してください。
    2. 情報を監査ログとアクティビティ ログに関連付けて、アカウントが使用されているかどうか、およびアカウントがポリシーを変更したか、リソース/サブスクリプションを変更したか、または他のアクティビティを実行したかを確認します。

手順 2: 既存の構成を評価する

インベントリを設定したら、ゼロ トラスト評価ツールを使用して、環境内での特権アクセスの構成方法を評価し、制御のギャップを特定できます。

評価ツールは完全なインベントリを置き換えるわけではありませんが、ロールとポリシーのデータを入力として使用して、次の内容を理解するのに役立ちます。

  • 特権ロールは保護されています (MFA、条件付きアクセス)。
  • 特権アクセスが管理されます (PIM、JIT/JEA パターン)。
  • ポリシーは一貫して適用されます。
  • ID、デバイス、アクセス ポリシー間にギャップが存在します。

ツールを使用した ID の評価の詳細について説明します。

手順 3: 専用の管理 ID を確立する

標準ユーザー アカウントから特権ロールを削除します。

専用の管理者アカウントを作成してください:

  • 特権タスクにのみ使用されます
  • 生産性向け機能(メール、Teams、Web 閲覧)へのアクセス権がない
  • PIM 経由の特権の対象であり、永続的に割り当てられない

標準ユーザー ID からすべての特権ロールの割り当てを削除します。

管理者アカウントを作成する

  1. Microsoft Entra管理センターで、Microsoft Entra ID>Users に移動します。
  2. [ 新しいユーザー ] を選択し、ユーザー設定を構成します。 次に、[作成] を選択します。
    • 名前: セキュリティで保護されたワークステーション管理者。
    • ユーザー プリンシパル名: secure-ws-admin@contoso.com
    • 認証方法: パスワード (一時的)。
    • ディレクトリ ロール: 割り当てないでください。
    • 使用場所: 運用場所に設定します。

これにより、特権のないクリーンな管理者 ID が提供されます。

手順 4: PAW の ID を作成する

後の手順では、特権管理者ワークステーション (PAW) を設定します。

PAW にアクセスできるが特権アクションを実行できない ID を定義する場合は、次のことができます。

  • PAW にのみサインインできる ID を作成します。
  • PAW へのサインインを許可するユーザーを制御するセキュリティ グループを作成します。
    • このグループは管理者権限を付与しません。 これは次の目的で使用されます。
      • 条件付きアクセス。たとえば、 セキュリティで保護されたワークステーション ユーザーのみが PAW にサインインし他のユーザーをブロックすることを許可します。
      • 特定のグループベースの PAW ライセンスの適用。
    • このグループの一般的なメンバーには、SOC アナリスト、オペレーター、および監査者が含まれます。

サインイン ID を作成する

  1. Microsoft Entra管理センターで、Microsoft Entra ID>Users に移動します。
  2. [ 新しいユーザー ] を選択し、ユーザー設定を構成します。 次に、[ 作成] を選択します。
    • 名前: セキュリティで保護されたワークステーション ユーザー
    • ユーザー プリンシパル名: secure-ws-user@contoso.com
    • ディレクトリ ロール: 割り当てない

PAW アクセス セキュリティ グループを作成する

PAW にサインインできるユーザーを制御するグループを構成する

  1. Microsoft Entra管理センターで、Microsoft Entra ID>Groups>New グループに移動します。

  2. グループ設定を構成し、[ 作成] を選択します。

    • [グループの種類]: セキュリティ
    • グループ名: セキュリティで保護されたワークステーション ユーザー
    • メンバーシップ: 割り当て済み
  3. 既定では管理者ではなく、PAW サインイン ID のみをグループに追加します。

手順 5: 管理コントロール グループを作成する

特権ロールの対象となるユーザーを定義するセキュリティ グループを作成します。 これらのグループ:

  • ロール割り当て可能としてマークされます
  • PIM を使用して管理される
  • メンバーシップのみで特権を付与しない
  • 昇格の承認境界として機能する

メンバーシップの変更は特権アクションとして扱われ、定期的に確認されます

  1. Microsoft Entra管理センターで、Microsoft Entra ID>Groups>New グループに移動します。

  2. グループ設定を構成し、[ 作成] を選択します。

    • グループの種類: セキュリティ
    • 名前: セキュリティで保護されたワークステーション管理者
    • メンバーシップの種類: 割り当て済み
  3. 専用の管理者 ID を追加します。 標準アカウントを使用せず、メンバーシップの変更を機密性の高いアカウントとして扱います。 定期的に確認します。

このグループは後で次のようになります。

  • ロール割り当て可能としてマークされる
  • PIM 経由で 有資格 (アクティブではない) として割り当てられたディレクトリ ロール
  • 特権アクセス ポリシーのプライマリ ターゲット メカニズムとして使用する

手順 6: PIM を構成する

Privileged Identity Managementがまだ有効になっていない場合は、今すぐ有効にします。

グローバル管理者または特権ロール管理者としてサインインしていることを確認します。

ディレクトリ ロールに対して PIM を有効にする

  1. Microsoft Entra管理センターで、ID ガバナンス>Privileged Identity Managementに移動します。
  2. Microsoft Entra ロール を選択します。

永続的なロールを削除する

  1. Microsoft Entra ロールで、[ロール] を選択します。

  2. 組織で識別された特権アクセス ロールを開きます。

    Microsoftで推奨される最小セットは次のとおりです。 - グローバル管理者 - 特権ロール管理者 - セキュリティ管理者 - Exchange管理者 - SharePoint管理者

  3. [割り当て] を選択します。

  4. アクティブ (永続的) 割り当てごとに、次の手順を実行します。

    • 永続的な割り当てを削除する
    • ユーザーまたはグループを 対象として再追加します。

この後、ユーザーはアクティブ化しない限り、管理者特権を持っていません。

アクティブ化設定を構成する

特権ロールごとに、次の操作を行います。

  1. PIM>Microsoft Entra ロールで、設定を選択します。

  2. ロール>編集を選択します。

  3. 設定の構成:

    • アクティベーションが必要
    • アクティブ化時に MFA を要求する
    • 正当な理由を要求する
    • 最大アクティブ化期間を設定する (影響の大きいロールの場合は 1 ~ 4 時間など)
    • 承認が必要 (グローバル管理者、特権ロール管理者、セキュリティ管理者)
    • 1 人以上の承認者を選択する
  4. [更新] を選択します。

グループベースのロールの割り当てを使用する

スケールとガバナンスのために、個々のユーザーではなくグループにロールを割り当てることをお勧めします。

ロール割り当て可能なセキュリティ グループを作成し、Entra ロール (管理者Exchangeなど) に割り当てます。 その後、ガバナンス プロセスを通じてメンバーシップ (ロールを取得できるユーザー) を管理し、必要に応じてグループの PIM を使用して管理します。

  1. このグループにロールを割り当てることができるMicrosoft Entra設定を有効にして、セキュリティ グループを作成します。
  2. PIM の >Microsoft Entra ロール で、[割り当ての追加] を選択します。
  3. グループをロールの 対象 として割り当てます。
  4. ロールの割り当てを直接変更するのではなく、グループにユーザーを追加または削除します。

このグループは、特権アクセスの承認境界になります。

手順 6 の完了時に、次の構成が行われます。

  • 永続的な管理アクセス権がない
  • 特権が要求、承認、期限付き、ログに記録される
  • 昇格パスは明示的で確認可能です

手順 7: 緊急アカウントを構成する

緊急アクセス用アカウントをまだ設定していない場合は、ここで構成します。 条件付きアクセス、MFA の停止、または構成の誤りによって発生する ID ロックアウト シナリオから回復する必要があります。

少なくとも 2 つの緊急アクセス アカウントを作成するには、グローバル管理者または特権ロール管理者としてサインインしていることを確認します。

  1. Microsoft Entra管理センターで、[ユーザー>すべてのユーザー] に移動します。
  2. [ 新しいユーザー] を選択し、クラウド専用ユーザーを作成します。
  • *.onmicrosoft.com ドメインを使用する
  • 推測されにくい名前を使用してください (「break glass」は避けてください)
  1. グローバル管理者ロールを割り当てます。
  • このロールを PIM の対象にしないでください。永続的である必要があります。
  • 強力な長いパスワードを使用して、安全にオフラインで保存します。
  • フィッシングに強い認証 (FIDO2/パスキー、証明書ベースの認証など) を構成する
  • MFA を個人の電話またはメール アドレスに関連付けないでください。

繰り返して、2 つ目の緊急アカウントを作成します。

条件付きアクセスから緊急アカウントを除外する

これにより、常に復旧が可能になります。

  1. Microsoft Entra管理センターで、[保護>Conditional Access] に移動します。

  2. すべてのポリシーについて:

    • 割り当てを編集します
    • 少なくとも 1 つの緊急アクセス アカウントを除外します。

通常の管理者アカウント (緊急アカウントのみ) を除外しないようにしてください。

緊急アカウントの使用状況を監視する

  1. アラートを有効にする:

    • 緊急アカウントによるサインイン
    • これらのアカウントに関連するロールの変更
  2. 事前に承認されていない限り、セキュリティ インシデントとして使用を扱います。

  3. 使用状況を定期的に確認します。

手順 7 の完了時に、次の構成が行われます。

  • ID コントロール プレーンは回復可能です
  • 後のフェーズ (PAW、条件付きアクセス) では、永続的なロックアウトのリスクはありません
  • 緊急アクセスが分離され、監視され、ほとんど使用されない

次のステップ

ID コントロール プレーンをセキュリティで保護した後、 セキュリティで保護された特権アクセス ワークステーション (PAW) を使用して特権を行使できる場所を制限します。