Microsoft Entraでグループの特権アクセスを管理するなら、最初に確認すべき答えはシンプルです。PIM for Groupsに取り込むべきなのは、Microsoft Entraロール、Azureロール、重要なSaaSや運用グループへのアクセスを間接的に付与するグループです。2026年4月に更新されたMicrosoft公式ドキュメントでは、グループをPrivileged Identity Management（PIM）の管理対象に入れ、メンバーシップまたは所有権をJust-In-Timeで管理する考え方と手順が整理されています。(Microsoft Learn)
今回の更新は、PIM for Groupsの新機能発表というより、security admins、identity teams、compliance teamsが運用前に見落としやすい条件を再確認するための実務向けアップデートとして読むべきです。特に重要なのは、動的グループやオンプレミス同期グループはPIM for Groupsで管理できないこと、必要な管理権限がグループ種別によって異なること、そして一度PIM管理対象にしたグループは管理対象から外せないことです。(Microsoft Learn)
Microsoft Entraの最新動向: Bring groups into Privileged Identity Managementで何が変わったか
Microsoft LearnのGitHub履歴を見ると、2026年4月24日に対象記事へ「Customer Intent」の追加と、ms.dateの更新が行われています。つまり、今回の更新ポイントは「機能仕様が大きく変わった」というより、管理者が何のためにこの手順を実行するのかが明確化された点にあります。具体的には、管理者がグループをPIM管理へオンボードし、そのグループのJust-In-Timeメンバーシップと所有権を制御する、という意図がドキュメント上で明示されています。(GitHub)
PIM for Groupsは、ユーザーに常時高い権限を持たせるのではなく、必要なタイミングだけグループメンバーまたはグループ所有者として有効化させる仕組みです。Microsoft Entra ID Governanceの文脈では、特権アクセスの最小化、承認フロー、監査、アクセスレビューと組み合わせて使うことで効果が出ます。PIM自体は、重要なリソースへのアクセスを管理、制御、監視するためのMicrosoft Entra IDの機能として説明されています。(Microsoft Learn)
PIM for Groupsとは何か
PIM for Groupsは、Microsoft Entra IDのグループに対して、メンバー権限または所有者権限を一時的に有効化する仕組みです。対象グループをMicrosoft Entraロール、Azureロール、Microsoft 365やその他業務システムへのアクセス制御に使っている場合、グループのメンバーになること自体が特権アクセスになります。
たとえば、次のようなグループはPIM for Groupsの候補になります。
| グループの用途 | PIM for Groupsを使う理由 |
|---|---|
| Microsoft Entraロールを割り当てるグループ | 管理者ロールを常時保持させず、作業時だけ有効化できる |
| Azureサブスクリプションやリソースグループの権限グループ | 本番環境への変更権限を必要な時間だけ付与できる |
| SharePoint、Teams、業務アプリの管理者グループ | 情報漏えいや誤操作のリスクを下げられる |
| インシデント対応用の緊急アクセスグループ | 通常時は無効、対応時だけ承認付きで有効化できる |
| 外部委託先やグローバル運用チーム向けの特権グループ | タイムゾーンをまたぐ運用でも証跡を残しやすい |
重要なのは、PIM for Groupsを「グループ管理の便利機能」としてではなく、特権アクセスの入口を制御する仕組みとして扱うことです。特権ロールそのものだけでなく、特権ロールへつながるグループも管理対象にしないと、最小特権の設計に抜け穴が残ります。
2026年4月更新で確認すべき実務ポイント
今回の公式ドキュメントを読むうえで、現場が特に確認すべきポイントは次の4つです。
| 確認ポイント | 実務での意味 |
|---|---|
| PIM管理の対象にするには明示的な取り込みが必要 | グループを作成しただけではPIM管理されない |
| 動的グループとオンプレミス同期グループは対象外 | ハイブリッドID環境では事前の棚卸しが必須 |
| 取り込みに必要な権限がグループ種別で異なる | role-assignable groupと通常グループで担当者を分ける必要がある |
| 一度PIM管理対象にすると外せない | 事前承認、影響確認、変更記録が重要 |
Microsoft公式ドキュメントでは、PIMでグループを管理するには、対象グループをPIM管理下に置く必要があると説明されています。また、Microsoft Entra Security groupまたはMicrosoft 365 groupが前提であり、動的グループとオンプレミス環境から同期されたグループはPIM for Groupsで管理できないと明記されています。(Microsoft Learn)
この点は、特にグローバル企業やハイブリッドID環境で重要です。オンプレミスActive Directoryから同期している管理用グループをそのままPIM化しようとしても、対象外であれば設計変更が必要になります。PIM for Groupsを導入する前に、「クラウド専用グループへ移行するか」「別のアクセス制御で補完するか」を決めておくべきです。
PIM管理に取り込むべきグループの判断基準
すべてのグループをPIM for Groupsに入れる必要はありません。対象を広げすぎると、承認作業や通知が増え、現場が回らなくなります。判断基準は、そのグループに入ることで何ができるようになるかです。
優先度が高いグループ
最優先で検討すべきなのは、メンバーになるだけで管理操作や機密情報へのアクセスが可能になるグループです。
具体例としては、次のようなものがあります。
- グローバル管理者、特権ロール管理者、セキュリティ管理者などに関連するグループ
- Azure本番環境のOwner、Contributor、User Access Administratorに相当するグループ
- Microsoft 365管理センター、Exchange、SharePoint、Teamsの管理権限につながるグループ
- セキュリティ運用、監査ログ、DLP、条件付きアクセス設定を変更できるグループ
- 本番データ、顧客情報、財務情報へアクセスできるアプリケーショングループ
これらは、攻撃者に奪われた場合の影響が大きく、内部不正や誤操作のリスクも高い領域です。常時メンバーを置くのではなく、必要なユーザーをEligible assignmentにして、作業時だけ有効化する設計が適しています。
優先度が中程度のグループ
次に検討したいのは、直接の管理者権限ではないものの、業務上重要なデータや設定にアクセスできるグループです。
たとえば、役員資料を保管するSharePointサイト、監査対応用の証跡保管場所、開発環境のシークレット管理画面、顧客サポート用の管理ポータルなどです。これらは日常的なアクセスが必要な場合もあるため、PIM化するかどうかは業務頻度とリスクのバランスで判断します。
PIM化しなくてもよいグループ
一般的な配布リスト、社内ポータル閲覧用グループ、低リスクな情報共有グループまでPIM管理に入れると、運用負荷が増えます。PIM for Groupsは「重要なアクセスを一時化する」ための仕組みです。低リスクなグループは、通常のグループ管理やアクセスレビューで十分な場合があります。
取り込み前に確認すべき前提条件
PIM for Groupsを設定する前に、次の条件を確認してください。
| 確認項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| グループ種別 | Microsoft Entra Security groupまたはMicrosoft 365 groupか | 動的グループや同期グループを対象にしようとする |
| 権限 | 実行者が必要な管理ロールまたはグループ所有者か | Administrative unitスコープの権限だけで実行しようとする |
| ライセンス | PIM利用者、承認者、レビュー担当者に必要なライセンスがあるか | 対象ユーザーだけでなく承認者のライセンスを見落とす |
| 影響範囲 | グループに紐づくロール、アプリ、リソースを把握しているか | グループ名だけで判断し、実際の権限を確認しない |
| 運用設計 | 承認者、最大有効化時間、通知先を決めているか | 取り込んだ後に設定方針が決まっていない |
PIMの利用にはライセンスが必要です。Microsoft公式のライセンス資料では、PIMとその設定を使用するにはMicrosoft Entra ID GovernanceまたはMicrosoft Entra ID P2ライセンスが必要と説明されています。また、PIMで管理されるロールやグループの有資格割り当て、承認者、アクセスレビュー担当者などにもライセンス要件が関係します。(Microsoft Learn)
必要な権限はグループ種別で変わる
Microsoft公式ドキュメントでは、role-assignable groupをPIM管理に取り込む場合、少なくともPrivileged Role Administratorロールを持つか、そのグループのOwnerである必要があるとされています。一方、role-assignableではないグループでは、Directory Writer、Groups Administrator、Identity Governance Administrator、User Administratorのいずれか、またはグループOwnerであることが条件です。管理者ロールの割り当ては、administrative unitレベルではなくディレクトリレベルのスコープが推奨されています。(Microsoft Learn)
ここで注意したいのは、「グループを管理できる権限」と「PIMの意図どおりに安全に管理できる権限」は同じではないことです。公式ドキュメントでは、Exchange Administratorsなど別のグループ管理権限を持つロールや、administrative unitスコープの管理者がGroups APIやUXを通じてグループを管理し、PIM側の変更を上書きできる可能性にも触れています。(Microsoft Learn)
つまり、PIM for Groupsを導入するときは、PIM側の設定だけでなく、通常のグループ管理権限を誰が持っているかも棚卸しする必要があります。
管理対象に取り込む基本手順
Microsoft Entra admin centerでの基本的な流れは次のとおりです。
| 手順 | 操作 |
|---|---|
| 1 | Microsoft Entra admin centerに必要な権限でサインインする |
| 2 | ID Governance > Privileged Identity Management > Groups に移動する |
| 3 | すでにPIM for Groupsが有効化されているグループを確認する |
| 4 | Discover groups を選択し、PIM管理に取り込むグループを選ぶ |
| 5 | Manage groups を選択し、確認画面でOKする |
| 6 | Groups に戻り、対象グループが表示されるか確認する |
公式ドキュメントでは、Discover groupsから対象グループを選択してManage groupsを実行する方法に加え、GroupsペインからPrivileged Identity Managementにグループを取り込む方法も案内されています。(Microsoft Learn)
実務では、手順そのものよりも「どのグループを選ぶか」のほうが重要です。作業前にグループID、表示名、所有者、現在のメンバー、紐づくロールやアプリ、運用責任者を一覧化してから取り込むと、後から混乱しにくくなります。
一度取り込むと管理対象から外せない点に注意
PIM for Groupsで最も見落としやすい注意点は、一度グループをPIM管理対象にすると、管理対象から外せないことです。公式ドキュメントでは、これは別のリソース管理者がPIM設定を削除してしまうことを防ぐための設計だと説明されています。また、グループをMicrosoft Entra IDから削除した場合、PIM for Groupsの選択肢から削除されるまで最大24時間かかる可能性があります。(Microsoft Learn)
この仕様を踏まえると、PIM管理へ取り込む前に次の確認を必ず行うべきです。
| 事前確認 | 理由 |
|---|---|
| 対象グループが本当に特権アクセスに使われているか | 不要なグループをPIM化すると運用負荷が増える |
| グループ名と用途が明確か | 承認者や監査担当者が判断しやすくなる |
| 所有者が適切か | 退職者や一時担当者がOwnerに残っていると管理が不安定になる |
| 承認者が複数いるか | 休暇、時差、インシデント時の承認遅延を防ぐ |
| 変更管理チケットに記録しているか | 後から「誰がなぜPIM化したか」を説明できる |
特にcompliance teamsにとっては、「PIM化したかどうか」だけでなく、「なぜそのグループをPIM化したか」「誰が承認したか」「どの設定で運用しているか」が監査証跡になります。
取り込み後に設定すべきPIM for Groupsの項目
グループをPIM管理に取り込んだだけでは、運用設計は完成しません。次に、メンバーと所有者それぞれのロール設定を確認します。PIM for Groupsの設定では、アクティブ化時のMFA、承認要件、最大有効化時間、割り当て期間、通知などを構成できます。設定はグループごと、さらにMemberとOwnerごとに独立して定義されます。(Microsoft Learn)
最大有効化時間
Activation maximum durationは、アクティブ化要求が有効なまま残る最大時間を設定する項目です。公式ドキュメントでは、1時間から24時間の範囲で設定できると説明されています。(Microsoft Learn)
実務では、次のように決めると運用しやすくなります。
| 用途 | 推奨される考え方 |
|---|---|
| 日常的な管理作業 | 1〜4時間程度を基本にする |
| 変更作業やメンテナンス | 変更ウィンドウに合わせて設定する |
| インシデント対応 | 長すぎる常時権限にならない範囲で調整する |
| グローバル運用 | 時差対応を考慮しつつ、承認履歴を残す |
「念のため24時間」にすると、JITの効果が薄れます。作業内容ごとに必要な時間を見積もり、短めに設定するのが基本です。
MFAと条件付きアクセス
PIM for Groupsでは、対象ユーザーが有資格ロールをアクティブ化する際にMFAを要求できます。さらに、条件付きアクセスの認証コンテキストを使うことで、特定の認証強度、Intune準拠デバイス、利用規約への同意などを要求できます。(Microsoft Learn)
ただし、条件付きアクセスを使う場合は設計に注意が必要です。公式ドキュメントでは、条件付きアクセスのスコープを「認証コンテキスト」と「グループ」に同時に設定しないよう説明されています。アクティブ化前のユーザーはまだそのグループのメンバーではないため、グループを条件にしたポリシーが適用されない可能性があるためです。(Microsoft Learn)
これは現場で起きやすいミスです。「この特権グループのメンバーにだけ条件付きアクセスをかける」と考えてしまうと、アクティブ化前の段階では期待どおりに制御できない場合があります。PIM有資格者を対象にした条件付きアクセス設計を別途検討しましょう。
承認と理由の入力
PIM for Groupsでは、アクティブ化時に業務上の理由やチケット情報を求める設定、承認を必須にする設定ができます。承認を必須にする場合、承認者はグループメンバーや所有者である必要はありませんが、少なくとも1人の承認者を選ぶ必要があり、公式ドキュメントでは少なくとも2人の承認者を選ぶことが推奨されています。(Microsoft Learn)
セキュリティ上重要なグループでは、次の組み合わせが実用的です。
| 項目 | 推奨設定 |
|---|---|
| 業務理由 | 必須 |
| チケット番号 | 変更管理やインシデント管理を使う組織では必須 |
| 承認 | 本番環境、管理者ロール、機密データ系は必須 |
| 承認者 | 最低2名。運用チームとセキュリティチームから分ける |
| 通知 | 管理者、承認者、監査用メールボックスへ送信 |
チケット番号は情報入力フィールドであり、外部のチケットシステムとの相関が自動的に強制されるわけではありません。運用ルールとして「チケットURLまたは番号がない申請は却下する」と決めておくと、監査時に説明しやすくなります。(Microsoft Learn)
Eligible assignmentとActive assignmentの使い分け
PIM for Groupsでは、メンバーまたは所有者の割り当てにEligibleとActiveがあります。Eligible assignmentは、ユーザーがアクティブ化して初めて権限を使える割り当てです。Active assignmentは、アクティブ化なしで常に権限を使える割り当てです。Microsoft公式ドキュメントでも、EligibleはMFA、業務理由、承認などを要求できる一方、Activeは常時その権限を持つ割り当てとして説明されています。(Microsoft Learn)
| 割り当て | 向いているケース | 注意点 |
|---|---|---|
| Eligible | 管理作業、変更作業、緊急対応、監査対象の権限 | 承認フローや有効化手順を利用者に教育する必要がある |
| Active | 常時必要な運用アカウント、例外的なブレークグラス用途 | 常時権限になるため、対象を最小限にする |
| Permanently eligible | 長期的に担当する管理者が、必要時だけ有効化する | 定期的なアクセスレビューが必要 |
| Time-bound eligible | プロジェクト、移行作業、期間限定の委託業務 | 終了日を明確にして棚卸し漏れを防ぐ |
本番環境や高権限グループでは、原則としてEligibleを使います。Activeは「常時必要である理由」が明確な場合に限定し、定期的に見直すべきです。
Microsoftが警告するセキュリティリスク
Microsoft公式ドキュメントでは、Microsoft Entraロールへの昇格に使われるグループについて、Eligible member assignmentに承認プロセスを要求することが推奨されています。承認なしでアクティブ化できる割り当ては、別の管理者が有資格ユーザーのパスワードをリセットできる場合にセキュリティリスクとなる可能性があるためです。(Microsoft Learn)
これは非常に重要です。PIMを導入しても、承認なし・弱い認証・長すぎる有効化時間のままでは、攻撃者や内部関係者が権限を取りやすい状態が残ります。
特に次の条件に当てはまる場合は、承認を必須にすべきです。
- グループ経由でMicrosoft Entra管理者ロールに昇格できる
- Azure本番環境のOwnerやContributorに昇格できる
- 条件付きアクセス、MFA、ID保護、監査ログに影響する操作ができる
- ユーザーのパスワードリセットや認証方法の変更ができる
- 顧客データ、個人情報、財務情報にアクセスできる
「MFAがあるから承認は不要」と考えるのは危険です。MFAは本人確認を強化しますが、その作業が正当かどうかを判断するものではありません。高権限グループでは、MFA、業務理由、チケット番号、承認を組み合わせるのが現実的です。
グローバル運用での設計ポイント
PIM for Groupsは、グローバル読者向けにも重要なテーマです。多国籍企業では、同じMicrosoft Entraテナントを複数リージョンの運用チームが使い、時差をまたいで特権アクセスを有効化します。
この場合、次の設計が有効です。
| 課題 | 対策 |
|---|---|
| 承認者が勤務時間外で対応できない | 地域別またはFollow-the-sun体制で承認者を複数配置する |
| 申請理由が言語や粒度でばらつく | 理由欄のテンプレートを決める |
| 監査ログを後から読みにくい | チケット番号、作業対象、作業時間を必須化する |
| 地域ごとに権限設計が違う | グローバル標準とローカル例外を分ける |
| 緊急時に承認が詰まる | ブレークグラス手順をPIMとは別に文書化する |
理由欄のテンプレート例は、次のように具体的にすると監査しやすくなります。
Purpose: Production incident investigation
Ticket: INC-123456
Target: Azure subscription / resource group name
Planned actions: Review logs and restart affected service
Expected duration: 2 hours
Approver: Security operations lead日本語運用でも、グローバル監査を意識するなら英語テンプレートを併用すると、海外拠点や外部監査人が読みやすくなります。
security adminsが取るべき対応
security adminsは、PIM for Groupsを「管理者体験」ではなく「攻撃面の削減」として設計する必要があります。
まず、特権アクセスにつながるグループを棚卸しします。グループ名だけで判断せず、どのロール、アプリ、Azureリソース、Microsoft 365サービスに紐づいているかを確認します。次に、常時メンバーを削減し、Eligible assignmentへ移行します。
特に優先すべき対応は次のとおりです。
- Microsoft Entraロールに使うrole-assignable groupを洗い出す
- 本番AzureリソースへのOwner、Contributor権限を持つグループを洗い出す
- 承認なしで昇格できる高権限グループをなくす
- 有効化時にMFAまたは条件付きアクセス認証コンテキストを要求する
- アクティブ化最大時間を業務実態に合わせて短くする
- 通知先にセキュリティ監視用メールボックスを追加する
identity teamsが取るべき対応
identity teamsは、PIM for Groupsの導入対象とID基盤の整合性を確認します。
特に、動的グループやオンプレミス同期グループはPIM for Groupsで管理できないため、対象外グループが多い環境では設計変更が必要です。Microsoft Entra ConnectやCloud Syncを使っている組織では、クラウド専用グループへの移行、グループの再作成、アクセス権の再割り当てが必要になる場合があります。
identity teamsが確認すべき項目は次のとおりです。
- 対象グループがPIM for Groupsで管理可能な種類か
- グループ所有者が現役の担当者か
- role-assignable groupの作成・管理ルールがあるか
- 管理者ロールがディレクトリスコープで適切に割り当てられているか
- Administrative unitスコープの管理者がPIM設定を迂回できる可能性がないか
- ライセンス対象者に漏れがないか
compliance teamsが取るべき対応
compliance teamsは、PIM for Groupsを監査証跡と統制の観点で確認します。重要なのは、単に「PIMを導入した」と記録することではありません。どのグループを、どのリスクに対応するために、どの設定で管理しているかを説明できる状態にすることです。
監査で確認されやすいポイントは次のとおりです。
| 監査観点 | 確認すべき内容 |
|---|---|
| 最小特権 | 常時メンバーが必要最小限か |
| 承認統制 | 高権限グループの有効化に承認が必要か |
| 証跡 | 理由、チケット番号、承認者、時間が記録されているか |
| 定期レビュー | EligibleとActiveの割り当てを定期的に見直しているか |
| 例外管理 | Active assignmentや緊急アクセスの理由が文書化されているか |
MicrosoftのPIM概要では、PIMが時間ベースおよび承認ベースのロールアクティブ化を提供し、過剰、不要、誤用されるアクセス許可のリスク低減に役立つと説明されています。また、アクセスレビューや監査履歴のダウンロードも主要機能として挙げられています。(Microsoft Learn)
よくある失敗と回避策
PIM for Groupsの導入では、次のような失敗が起きやすくなります。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| 対象グループがDiscover groupsに出てこない | 動的グループ、同期グループ、権限不足など | グループ種別と実行者権限を事前確認する |
| PIM化後に戻せず困る | 不可逆であることを理解せず取り込んだ | 変更管理プロセスで事前承認を取る |
| 承認者が1人で申請が止まる | 休暇、退職、時差を考慮していない | 最低2名以上の承認者を設定する |
| 承認なしで高権限に昇格できる | 利便性を優先しすぎた | 高権限グループは承認必須にする |
| 有効化時間が長すぎる | 作業時間の見積もりがない | 用途別に1〜4時間など基準を決める |
| PIM設定を別の管理者が上書きする | Groups API/UX側の権限棚卸し不足 | 通常のグループ管理権限も監査する |
| チケット番号が形だけになる | 外部チケットシステムと突合していない | 承認ルールにチケット確認を組み込む |
特に「PIM管理にしたから安全」と考えるのは危険です。PIMは設計と運用ルールがあって初めて効果を発揮します。承認者、通知、MFA、条件付きアクセス、アクセスレビューを組み合わせて、実際の権限利用を制御する必要があります。
導入前チェックリスト
PIM for Groupsを有効化する前に、次のチェックリストを使ってください。
| チェック | 内容 |
|---|---|
| 対象グループの用途を文書化した | グループ名、ID、所有者、用途、関連リソースを記録する |
| グループ種別を確認した | 動的グループやオンプレミス同期グループではないことを確認する |
| 実行者権限を確認した | role-assignable groupかどうかで必要権限を確認する |
| ライセンスを確認した | 対象者、承認者、レビュー担当者に必要なライセンスを確認する |
| 取り込みの不可逆性を承認した | 一度PIM管理にすると外せない点を関係者に共有する |
| 承認者を2名以上決めた | 時差、休暇、退職リスクを考慮する |
| 有効化時間を決めた | 作業種別ごとに標準時間を定義する |
| MFAまたは条件付きアクセスを設計した | 認証強度や準拠デバイス要件を検討する |
| 通知先を決めた | 承認者、管理者、監査用メールボックスを整理する |
| アクセスレビュー方針を決めた | EligibleとActiveの棚卸し周期を決める |
まず着手すべき次のアクション
最初にやるべきことは、PIM for Groupsの設定画面を開くことではありません。特権グループの棚卸しです。
まず、Microsoft Entraロール、Azureロール、本番環境、機密データに紐づくグループを一覧化してください。そのうえで、常時メンバーが必要なグループと、Eligible assignmentへ移行できるグループを分けます。次に、対象グループがPIM for Groupsで管理可能か、実行者権限とライセンスが足りているかを確認します。
PIM for Groupsは、正しく使えば「誰が、いつ、なぜ、どの特権グループに入ったのか」を説明できる強力な仕組みです。一方で、対象グループの選定を誤ると、不可逆な設定や承認負荷によって運用が複雑になります。2026年4月更新の公式ドキュメントをきっかけに、security admins、identity teams、compliance teamsで特権グループの棚卸しとPIM管理方針を見直すことが、最も実務的な対応です。
コメント