【クラウド法務】PIM 承認フロー設計でトラブルになりやすい3つのポイント— Entra ID PIM の一時権限を“監査で通る運用”にするために、承認設計で先に決めるべき契約・責任範囲 —
- 山崎行政書士事務所
- 2025年12月12日
- 読了時間: 7分
導入：PIMは入れた。でも「誰が承認するのか」が曖昧で運用が崩れる
Entra ID PIM（Privileged Identity Management）は、管理者権限を必要なときだけ付与できるため、ゼロトラスト運用の要になります。設定自体はドキュメントも多く、Eligible化してActivateするところまでは進みます。しかし全国の情シス・IT部門の方から相談を受けていると、次のような声を非常によく耳にします。
「PIMは導入したが、承認フローが現場に合わず“例外”が増えている」「承認者が形骸化し、結局いつも同じ人が雑に承認してしまっている」「監査・親会社から“その昇格は誰が何を根拠に承認した？”と聞かれ、証跡が出せず困った」
本記事では、**「PIM 承認フロー 設計 × クラウド法務」**という視点から、よくある落とし穴と、実務で使える整理方法をご紹介します。
1. PIM 承認フロー設計で、現場が実際に組む構成イメージ（技術の“事実整理”）
まずは「技術構成として何が起きているか」を揃えます。多くの企業での PIM 導入は、ざっくり次のような形です。
1-1. 典型構成（テキスト簡易アーキテクチャ）
ID基盤：Entra ID（旧 Azure AD）
特権管理：Entra ID PIM
ロールを Active（常時）→ Eligible（候補） に切替
必要時に Activate（昇格）、時間経過で自動解除（JIT）
承認フロー（よくある設計）
Activate時：MFA必須
申請理由（Justification）必須
重要ロールは承認（Approval）必須
変更管理チケット番号を理由欄に入力（手動運用が多い）
対象ロール例
Entra ID：Global Admin / Privileged Role Admin / Security Admin
Azure RBAC：Owner / Contributor
M365：Exchange / SharePoint / Teams 管理ロール
監査・ログ
PIM昇格履歴（誰が・いつ・何のロール・理由・承認者）
Entra ID Audit logs（ロール割当変更、設定変更）
SIEM/Log保存は企業により差（保持期間もバラつき）
ここまでは技術の話として筋が通っています。
しかし現場で詰まるのは、ここからです。
ここまでは技術の話。ここからが法務。「その承認は、誰がどの責任で行い、監査にどう説明するのか」という“運用の設計図”がないまま進むケースがほとんどです。
2. 全国の案件で見えてきた「PIM 承認フロー設計」の落とし穴3選
代表的なものを3つだけ挙げると、次のようなパターンです。
① 承認者が“名義だけ”になり、実態はノールック承認
技術的にはOK
PIMで承認必須にしている
Activateの履歴も残っている
法務・監査的にはNGになりうる点
承認者が「内容を見ずに承認」してしまい、統制として機能していない
理由欄が「作業のため」「障害対応」など曖昧で、後追い説明できない
監査から見ると「承認がある＝統制がある」ではなく、承認プロセスの実効性が問われる
② 承認フローが現場に合わず、“例外”と“常時権限”が復活する
技術的にはOK
全ロールを厳格に承認必須に設定
夜間も同じ承認要件
法務・実務的にはNGになりうる点
夜間・休日の障害対応で承認が詰まり、復旧が遅れる
「緊急だから」の名目でBreak-glassや常時管理者が復活し、PIMの意味が薄れる
結果として“本番ではPIMが守れない”状態になり、監査で一番嫌われる**「平常時だけ統制」**に陥る
③ ベンダー・委託先・海外拠点が絡むと、責任分界が崩れる
技術的にはOK
ベンダーにも必要最小限のロールをEligible付与
申請→承認→作業の流れはある
契約・責任分界的にはNGになりうる点
「誰が承認するのか（自社？ベンダー？海外責任者？）」が曖昧
ベンダーが昇格した際のログ提出、再委託、作業時間帯、終了時剥奪が契約とつながっていない
インシデント時に「その昇格は正当だったか」「承認は適切だったか」の説明責任が宙に浮く
3. PIM 承認フロー設計で、まず押さえるべき3つの整理軸
技術設定をいじる前に、最低限、次の3つを紙に落としておくと、その後のベンダー調整・社内説明・監査対応が格段に楽になります。
① 「承認の責任分界」を先に決める（誰が何を担保するか）
承認フローは“ワークフロー”ではなく、責任分界です。最低限、以下を明確にします。
最終責任者（Accountable）：自社のセキュリティ責任者／情シス責任者のどちらか（または共同）
承認実務者（Approver）：日常の承認を回す人（当番・代理含む）
申請者（Requester）：管理作業をする人（自社／ベンダー／海外）
変更の正当性の説明者（Owner）：システムオーナー／事業部門（特に業務影響がある設定変更）
ログ保全・監査提出担当（Evidence Owner）：監査に出す責任者を固定
ポイントは、「承認者＝責任者」ではないことを明文化することです。承認は“押印”ではなく、どのリスクを取ったかの意思決定になります。
② ロールを「階層化」して、承認条件を設計する
すべてを同じ承認ルールにすると運用が崩れます。監査に耐えつつ現場が回る設計のコツは、ロールを段階分けすることです。
Tier 0（最重要：ID基盤の根）
例：Global Admin / Privileged Role Admin
ルール例：
承認必須（2名承認や二重統制も検討）
有効時間は短め（例：1時間）
理由は具体必須＋チケット番号必須
利用後レビュー（事後確認）必須
Tier 1（セキュリティ・重要設定）
例：Security Admin / Conditional Access Administrator
ルール例：
承認必須（当番承認＋代理）
有効時間は業務実態に合わせる（例：2〜4時間）
変更管理チケット必須
Tier 2（運用系・限定範囲）
例：特定サブスクのContributor、限定的なM365管理ロール
ルール例：
承認不要にする代わりに、理由・チケット必須＋アラート監視強化
もしくは「一定回数以上は承認必須」など
加えて、緊急時ルールを別枠で用意します。
夜間・障害時の承認者が応答しない場合のエスカレーション
Break-glassの発動条件と、利用後の“戻し”（例外解除・証跡提出）
“緊急だから”を免罪符にしないための事後レビュー
③ 監査で出せる「証跡パック」を先に作る
承認フローは「ログがある」だけでは弱いです。監査で刺さるのは、提出できる形で揃っていることです。
提出できる一覧
期間：直近3〜6か月（監査要求に合わせる）
内容：昇格日時／申請者／ロール／理由／承認者／有効時間／チケット番号
例外の記録
Break-glass利用
承認なしで運用した例（やむを得ないケース）と、その是正
棚卸し記録
Eligibleロール保持者の定期棚卸し（四半期・半期など）
ベンダー／退職者／異動者の剥奪確認
保持期間
規程・監査・取引先要件に合わせ、ログの長期保管（SIEM等）を含めて設計
“承認フローの設計”は、最終的に「監査でこれを出せます」という形に落とすのがゴールです。
4. ケーススタディ：製造業A社（売上800億、拠点8カ国）の場合
実際に当事務所でご相談を受けた事例の一つをご紹介します（業種等は匿名化しています）。
業種：製造業
売上規模：約800億円
拠点：日本＋欧州＋アジア（8カ国）
テーマ：Entra ID PIM 導入後の「承認フロー設計」と監査対応の整備
課題の整理
PIMは導入済みだが、承認者が固定化しノールック承認になりがち
夜間障害時に承認が詰まり、結局“常時管理者”を復活させる流れが発生
ベンダー作業で昇格が必要なのに、契約・責任分界・ログ提出が曖昧で監査が不安
当事務所の支援内容（抜粋）
PIM設定（対象ロール、承認、理由必須、時間）と運用実態の棚卸し
ロールをTier分けし、承認条件（承認要否、有効時間、チケット必須）を再設計
夜間・緊急時の承認ルートとBreak-glass運用を、規程・手順として明文化
委託先の昇格について、作業範囲・ログ提出・終了時剥奪を契約・運用に接続
結果として
「承認がある」ではなく「承認が統制として機能している」状態になり、監査対応が安定
緊急時の例外も“想定内”として扱えるようになり、常時権限の復活を抑制
情シス・セキュリティ・ベンダーの役割が揃い、説明責任のストーリーが作れた…といった声をいただいています。
5. PIM 承認フロー設計で、今すぐ確認しておきたいチェックリスト
□ PIM対象ロールが一覧化され、対象外ロールの理由も説明できる
□ ロールがTier分けされ、承認要否・有効時間・必須入力（理由/チケット）が整理されている
□ 承認者・代理承認者・夜間当番のルールが明文化されている
□ “緊急時”の例外手順（エスカレーション、Break-glass、事後レビュー）がある
□ ベンダーが昇格する場合、作業範囲・ログ提出・再委託・終了時剥奪が契約と運用に落ちている
□ 監査提出用の「昇格一覧」「例外記録」「棚卸し記録」を出せる
□ 理由（Justification）が形骸化しないよう、テンプレ禁止や記載要件が決まっている
□ “承認が遅くて業務が止まる”を理由に常時権限に戻る運用になっていない
「すべて自信を持ってYESと言える企業は、全国的に見てもまだ多くありません。」
6. 全国からのご相談について
山崎行政書士事務所では、**Entra ID / PIM の技術構成と、運用規程・委託契約・監査対応をセットで整理する「クラウド法務支援」**を行っています。
PIMは入れたが、承認フローが現場に合わず形骸化している
監査・親会社から「承認の根拠」「例外の扱い」を問われ、説明が苦しい
委託先・海外拠点を含め、責任分界と証跡設計を作り直したい
といったお悩みがあれば、**オンライン（全国対応）**にて初回のご相談を承っております。
👉 ご相談フォームはこちら
👉 お問い合わせの際に、「PIM 承認フロー 設計の記事を見た」 と書いていただけるとスムーズです。
コメント