【クラウド法務】PIM 一時権限（JIT）運用でトラブルになりやすい3つのポイント— Entra ID PIM × 監査対応： “一時権限を入れたのに指摘される会社” がハマる落とし穴と解決策（PIM 一時権限 監査）—

導入：PIMは入れた。でも「監査で説明できる運用」になっていない

Entra ID（旧 Azure AD）の PIM（Privileged Identity Management）は、管理者権限を“必要なときだけ”付与できるため、ゼロトラスト運用の要になります。技術的な手順はドキュメントも多く、「Eligible（候補）にして、必要なときにActivateする」までは比較的スムーズに進みます。

しかし、全国の情シス・IT部門の方から相談を受けていると、次のような声を非常によく耳にします。

• 「PIMで一時権限にしたが、監査で“運用統制”を突っ込まれて説明が詰まった」

• 「承認・理由・チケット番号など、証跡の取り方が属人化している」

• 「ベンダーや海外拠点も絡み、誰が最終責任者で、誰が証跡を出すのか曖昧」

本記事では、「PIM 一時権限 監査 × クラウド法務」 という視点から、全国の案件で実際に見えてきた“よくある落とし穴”と、実務で使える整理方法をご紹介します。

1. PIM 一時権限運用で、現場が実際に組んでいる構成イメージ（技術の“事実整理”）

まずは「技術として何をやっているか」を揃えます。多くの企業での PIM 運用は、ざっくり次のような全体像です。

1-1. 典型構成（テキスト簡易アーキテクチャ）

• テナント：Entra ID（M365 / Azure / 各SaaSの入口）

• 特権管理：Entra ID PIM

  • 管理者ロールを Active（常時付与） ではなく Eligible（候補） にする

  • 必要時に Activate（昇格） して、一定時間で自動解除（JIT）

• 統制オプション（企業によりバラつく）

  • MFA必須（Activation時）

  • 申請理由（Justification）必須

  • 承認（Approval）必須（セキュリティ責任者など）

  • チケット番号連携（手動入力 or 運用ルール）

• 対象ロール例

  • Entra ID：Global Admin / Privileged Role Admin / Security Admin など

  • Azure RBAC：Owner / Contributor など（サブスク単位）

  • M365系：Exchange / SharePoint 管理ロール 等

• ログ・監査

  • PIMのアクティビティ（誰がいつ昇格したか、承認は誰か、理由は何か）

  • Entra IDの監査ログ（ロール割当・変更）

  • SIEM（Sentinel/外部SIEM）へ転送して長期保管している会社も

ここまでは“技術構成”として整理できていることが多いです。

ただし、ここで必ず出てくるのが次のギャップです。

ここまでは技術の話。ここからが法務。「監査で聞かれる “統制の説明” を、誰が何の資料で答えるか」 が決まっていない。

PIMは「設定した」だけでは、監査的には“統制”と認められないことがあります。承認ルール・例外運用・証跡の出し方・委託先管理までセットで初めて強い運用になります。

2. 全国の案件で見えてきた「PIM 一時権限 × 監査」の落とし穴3選

① PIMを入れたのに、実態として“常時管理者”が残っている

• 技術的にはOK一部の管理者はEligible化され、昇格の仕組みは動いている。

• 監査・統制的にはNGになりうる点

  • 重要ロール（例：Global Admin）が「例外」として常時付与のまま

  • ベンダー用・運用用の強権限が固定化されている

  • “緊急用”のつもりで作ったアカウントが、実態として常用されている→ 監査から見ると「PIMは入れたが統制の中心が残っている」状態に見えやすい

② 承認・理由・チケットなどの“監査証跡”が揃わない

• 技術的にはOK昇格履歴（誰がいつActivateしたか）はログで追える。

• 監査的にはNGになりうる点

  • 「なぜその昇格が必要だったか」が、ログ上の理由欄が空・雑・運用任せ

  • 承認が不要設定になっている／承認者が実態とズレている

  • チケット番号と紐づかず、後追いで説明できない→ “不正があったか”以前に、「統制プロセスが回っていない」と評価されやすい

③ 例外運用（夜間・障害・委託先）が責任分界と結び付いていない

• 技術的にはOK平常時のPIM運用は回っている。

• 法務・実務的にはNGになりうる点

  • 夜間障害で「誰が承認するのか」「承認できない場合どうするのか」が未定義

  • 委託先（運用ベンダー）が昇格する場合の範囲・手順・ログ提出が契約に落ちていない

  • 事故が起きたとき、Microsoft／ベンダー／自社（情シス・セキュリティ・事業部） のどこが説明責任を負うか曖昧→ 結果として「緊急時だけ統制が崩れる」＝監査で一番嫌われる状態になりがちです

  • 
    

3. PIM 一時権限を“監査で強い運用”にする整理のフレーム3つ

技術構成を変える前に、最低限この3点を紙に落とすと、ベンダー調整・社内説明が一気に楽になります。

① 役割と責任を「平常時／緊急時／監査対応」で分けて責任分界表にする

PIMは“設定する人”と“責任を負う人”がズレやすいので、最初に整理します。

• クラウド事業者（Microsoft）サービス提供・SLA範囲・ログ仕様

• 構築ベンダー（SI）PIM設計（承認・時間・対象ロール）／導入成果物（設計書・手順書）

• 運用ベンダー（MSP）監視・一次対応・定常変更（ただし最終判断は誰か）

• 自社 情シス／セキュリティ最終方針、例外承認、監査回答の責任者

• 事業部門／システムオーナー変更の正当性（なぜ必要か）、業務影響判断

特に監査で揉めやすいのはここです：

• 「証跡を出すのは誰か」

• 「承認者は誰か（代理は誰か）」

• 「例外を許す判断は誰か」

これを一枚に落とすだけで、“監査の質問に誰が答えるか”がブレにくくなります。

② 一時権限（JIT）の“標準ルール”と“例外ルール”を分けて規程化する

PIMで監査に強い運用にするなら、最低限この要素を標準化します。

• 対象ロールの定義（何をPIM管理対象にするか）

  • “全ロール対象”が理想ですが、現実は段階導入が多い

  • ただし「なぜ対象外なのか」の説明は必要

• Activation ルール

  • 最大有効時間（例：1時間／4時間など。組織の実態に合わせる）

  • MFA必須

  • 理由（Justification）必須（テンプレ語禁止：具体性が重要）

• 承認ルール

  • 高権限は承認必須（承認者・代理・夜間の扱いまで）

  • 低権限は承認不要でも、理由・チケット連携は必須…などの設計

• 例外ルール（ここが肝）

  • 障害時に承認ができない場合の代替手順（当番・エスカレーション）

  • Break-glass（緊急用）アカウントはPIMと別枠で規程化（混ぜない）

  • 委託先が昇格する場合の条件・操作範囲・ログ提出

監査で強いのは「例外がない運用」ではなく、例外があっても “統制された手順で説明できる運用” です。

③ 監査で出せる「証跡パック」を先に決める

PIMはログが取れていても、“提出できる形”になっていないと詰まります。次を先に決めておくと強いです。

• 提出対象の証跡

  • 直近◯ヶ月のロール昇格一覧（誰が・いつ・どのロール・理由・承認者）

  • ロール割当変更（Eligible付与／剥奪）の履歴

  • 例外（Break-glass利用、緊急時のルール逸脱）の記録と再発防止

• 保持期間

  • 監査・規程・取引先要件に合わせた保持期間（年単位になりがち）

  • 「PIMログは短く、SIEMに長期保存」など設計の一貫性が重要

• 棚卸し

  • 管理者（Eligible含む）の定期棚卸し（四半期・半期など）

  • 承認者・代理者・当番の見直し

“監査で聞かれる質問”はだいたい固定です。先に答えを用意しておくのが勝ち筋です。

4. ケーススタディ：製造業A社（売上900億、拠点7カ国）の場合

実際に当事務所でご相談を受けた事例の一つをご紹介します（業種等は匿名化しています）。

• 業種：製造業

• 売上規模：約900億円

• 拠点：日本＋欧州＋アジア（7カ国）

• テーマ：Entra ID PIM（管理者一時権限）導入後の監査指摘を潰す

課題の整理

• PIMは導入済みだが、監査で

  • 「承認は？」「なぜ必要だった？」「例外はどう管理している？」の質問に回答がバラバラ

• “運用ベンダーが作業するため”という理由で、強権限が一部常時付与のまま

• 夜間障害時の承認ルートが曖昧で、「緊急時だけ統制が外れる」懸念があった

当事務所の支援内容（抜粋）

• PIM設定と運用実態（承認・理由・チケット・例外）を棚卸し

• 責任分界マトリクス作成（平常時／緊急時／監査対応で役割を分解）

• PIM運用規程（ドラフト）整備

  • 標準ルール／例外ルール／Break-glass運用を分けて明文化

• 委託先の関与がある箇所について、運用委託契約・SLA条項の論点整理（ログ提出・作業範囲など）

結果として

• 監査・親会社からの質問に、「設定」ではなく「運用規程＋証跡」で一貫して回答できるようになった

• ベンダー強権限の恒久化が減り、PIMの“狙い”が運用に落ちた

• 緊急時の手順も明確になり、「動けるが説明できない」状態から脱却できた…といった声をいただいています。

• 
  

5. PIM 一時権限（JIT）運用の監査チェックリスト

ブクマ用に、今すぐ確認できる形でまとめます。

• □ PIM対象ロール（高権限・Azure RBAC等）の一覧があり、対象外は理由が説明できる

• □ Activate時に MFA必須／理由必須／（必要に応じて）承認必須 が設計されている

• □ 理由（Justification）が形骸化せず、チケットや変更管理と紐づく運用になっている

• □ 管理者（Eligible含む）の棚卸しが定期的に行われ、結果が記録されている

• □ 夜間・障害時の承認ルート（代理・当番・エスカレーション）が文章化されている

• □ Break-glass（緊急用）はPIMと別枠で、保管・開封・使用・復旧後まで規程化されている

• □ 委託先が昇格する場合、作業範囲・ログ提出・契約終了時剥奪が契約と運用に落ちている

• □ 監査提出用に、昇格履歴・承認履歴・例外記録を“出せる形”で保全できる

「すべて自信を持ってYESと言える企業は、全国的に見てもまだ多くありません。」

6. 全国からのご相談について

山崎行政書士事務所では、Entra ID / PIM / ゼロトラストの技術構成と、運用規程・委託契約・監査対応をセットで整理する「クラウド法務支援」 を行っています。

• PIMは入れたが、監査で説明できる運用になっていない

• 承認・例外・委託先関与が混線し、責任分界が曖昧

• 監査・親会社・取引先からの質問に、一貫したストーリーで答えられるようにしたい

といったお悩みがあれば、**オンライン（全国対応）**にて初回のご相談を承っております。

👉 ご相談フォームはこちら

👉 お問い合わせの際に、「PIM 一時権限 監査の記事を見た」 と書いていただけるとスムーズです。