JIT Access / PIM導入時に決めるべき対象ロール、承認者、MFA、理由入力、期限、監査ログ、break glassとの違いを整理。情シス・SaaS管理者が一時権限を安全に運用するための実務チェックリスト。導入前確認、初動設計、エスカレーション判断まで解説。
冒頭要約
JIT Access（Just-in-Time Access）やPIM（Privileged Identity Management）は、管理者権限を「常に持つ」状態から「必要な時だけ、理由と期限つきで有効化する」状態へ変える運用です。Microsoft Entra、Google Cloud、クラウド管理基盤、SaaS管理画面で、恒久的な管理者を減らすために使われます。
重要なのは、ツールを有効化することではありません。どのロールを対象にするか、誰が承認するか、何分だけ有効にするか、どのログを残すか、例外をどう扱うかを先に決めないと、PIMは「承認ボタンが増えただけ」の仕組みになります。
この記事では、情シス、IdP管理者、SaaS管理者、開発組織の管理者向けに、JIT Access / PIM導入時の確認順序、初動設計、判断基準、よくある誤解を整理します。攻撃手順、認証回避、侵入再現、悪用コードは扱いません。
JIT Access / PIMは、強い権限を安全に使うための運用設計です。すべての権限を一律に厳しくするのではなく、影響が大きい管理者ロールから、理由・承認・期限・監査ログをセットで管理します。
読者別の影響：誰が何を決めるか
PIM導入はIdP担当だけでは完結しません。承認者、業務オーナー、CSIRT、監査担当、開発組織がそれぞれ別の観点を持ちます。
| 読者・担当者 | 決めること | 放置したときの問題 |
|---|---|---|
| 情シス・IdP管理者 | 対象ロール、MFA、承認、期限、通知、監査ログ | 恒久管理者が残り、権限付与の理由を追えない |
| SaaS管理者 | SaaS側の管理者ロール、外部ユーザー、OAuthアプリとの関係 | IdPは制御できてもSaaS側の管理者が残る |
| 開発者・DevOps | クラウドOwner、GitHub管理者、CI/CD管理者の一時化 | 本番・リリース・Secretへの強い権限が常設される |
| CSIRT・SOC | 有効化ログ、操作ログ、アラート、エスカレーション条件 | 権限昇格が正当か不審か判断できない |
| 管理部門・監査担当 | 承認者、証跡、例外期限、再レビュー | 監査時に「誰がなぜ許可したか」を説明できない |
PAMやJIT Accessの導入は、最小権限の原則を実務に落とす手段です。ただし、対象ロールの整理、承認者の設計、失効後の確認がないと、恒久管理者を別の形で残すだけになります。
JIT Access / PIMとは：恒久管理者を減らすための仕組み
JIT Accessは、必要な時だけ一時的に権限を有効化する考え方です。Microsoft Entra PIMでは、ユーザーを「eligible（必要時に有効化できる）」にし、MFA、理由入力、承認、時間制限などを経て「active（有効）」にします。Google Cloud Privileged Access Managerでも、申請者、理由、ロール、最大期間、承認、通知、監査ログを含む一時的な権限昇格を扱います。
実務上は、次の違いを分けて理解すると運用しやすくなります。
| 状態 | 意味 | 典型的な使い方 |
|---|---|---|
| 恒久active | いつでも権限を使える | 最小限の通常管理者、または避けたい状態 |
| eligible | 必要時に有効化できる | 通常時は権限を持たず、作業時だけ申請する |
| time-bound active | 指定期間だけ権限を使える | 障害対応、移行作業、委託先作業 |
| break glass | 通常のPIMやIdPが使えない時の非常用 | 最後の復旧経路。日常作業には使わない |
ここでのゴールは、すべての作業を遅くすることではありません。強い権限を、作業目的・時間・承認者・証跡と結びつけることです。Zero Standing Privilegeの考え方に近づけるには、単に「管理者を減らす」だけでなく、「必要な時に安全に有効化できる」状態が必要です。
まず確認すること：導入前チェックリスト
PIMを有効化する前に、次の項目を決めます。ここが曖昧なまま進めると、承認待ちで業務が止まる、例外が増える、ログを見ても判断できない、という状態になりやすいです。
| 確認項目 | 見るポイント |
|---|---|
| 1. 対象ロール | Global Administrator、Security Administrator、Organization owner、クラウドOwnerなど影響が大きい順に並べる |
| 2. 対象者 | 社員、委託先、外部ユーザー、サービスアカウント、開発者、運用担当を分ける |
| 3. 有効化条件 | MFA、端末条件、場所条件、チケット番号、理由入力、承認の要否を決める |
| 4. 承認者 | 直属上長だけでなく、システムオーナー、セキュリティ担当、当番者を含めるか決める |
| 5. 最大利用時間 | 30分、2時間、8時間、作業日単位など、作業種別ごとに分ける |
| 6. 通知先 | 申請者、承認者、SOC、システムオーナー、監査担当の誰へ通知するか決める |
| 7. 監査ログ | 有効化、承認、拒否、延長、失効、実施操作をどこで確認するか決める |
| 8. 失効後確認 | 作業後に外部共有、OAuth同意、トークン発行、設定変更が残っていないか見る |
| 9. 例外運用 | 障害、夜間対応、承認者不在、委託先作業、緊急作業をどう扱うか決める |
| 10. break glass | PIMが使えない時だけ使う非常用経路として、保管・通知・訓練を分ける |
導入の最初は、すべてのロールを対象にしようとしない方が現実的です。まずは、全体設定を変えられるロール、監査ログやセキュリティ設定に触れるロール、クラウドの課金・ネットワーク・本番環境に触れるロールから始めます。
初動設計：やること、やらないこと、記録すること
やること
- 既存の管理者ロールを棚卸しし、恒久active、eligible、break glass、廃止候補に分類する。
- 重要ロールごとに、最大利用時間、承認者、理由入力、MFA、通知先を決める。
- パイロット対象を少数の管理者と代表ロールに絞り、実際に有効化、承認、失効、ログ確認まで試す。
- 申請理由には「作業内容」「チケット番号」「対象システム」「想定終了時刻」を含める。
- 失効後に、設定変更、トークン発行、外部共有、追加ユーザーが残っていないか確認する。
- 承認者不在、IdP障害、MFA障害に備えて、Break Glass Accountを別管理にする。
やらないこと
- 全ロールを一度にPIM化して、業務影響を把握しないまま本番化しない。
- 承認者を1人だけにして、夜間・休日・休暇で承認不能にしない。
- 「承認済みだから安全」と見なし、実際の操作ログ確認を省略しない。
- break glassアカウントを日常作業や便利な迂回経路として使わない。
- PIM対象外のSaaS管理者、外部ユーザー、OAuthアプリ、APIトークンを放置しない。
記録すること
| 記録項目 | 例 |
|---|---|
| 対象ロール | Global Administrator、Security Administrator、Cloud Owner、Billing Admin |
| 有効化条件 | MFA必須、理由入力必須、承認必須、最大2時間 |
| 承認者 | システムオーナー、セキュリティ当番、委託先管理者 |
| 申請理由 | チケット番号、作業目的、対象環境、想定終了時刻 |
| 有効化ログ | 申請、承認、拒否、開始、終了、延長、失効 |
| 失効後確認 | 追加ユーザー、OAuth同意、外部共有、トークン、ログ設定変更 |
この記録は、管理者権限が急に付与された時の初動対応や漏えい疑い初動テンプレートにそのまま接続できます。PIMは平時の設計ですが、説明できない有効化が見つかった場合は初動対応へ切り替えます。
判断基準：どのロールからPIM化するか
優先順位は、ロール名の強さだけでは決めません。影響範囲、操作可能なデータ、ログやセキュリティ設定への影響、外部ユーザーの有無、代替経路の有無で判断します。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | Global Administrator、Privileged Role Administrator、Security Administrator | テナント全体、管理者権限、セキュリティ設定へ影響する |
| 高 | クラウドOwner、Subscription Owner、Project Owner | 本番環境、ネットワーク、鍵、課金、ログへ影響する |
| 高 | GitHub Organization owner、CI/CD管理者、Secret管理者 | コード、リリース、シークレット、サプライチェーンへ影響する |
| 高 | 監査ログ・DLP・EDR・SIEMの管理者 | 検知・証跡・データ保護を無効化できる可能性がある |
| 中 | 請求、ユーザー管理、外部共有管理、グループ管理 | 直接の侵害範囲は限定的でも横展開の足場になる |
| 中 | 委託先・外部ユーザーの管理者権限 | 契約期限、作業範囲、承認者を説明しにくい |
| 低 | 読み取り専用、監査閲覧、限定スコープの運用ロール | 監査目的なら恒久付与も許容される場合がある |
「高」から順にすべて承認必須にすればよい、という意味ではありません。障害対応で待てないロールは、短い有効時間、通知、事後レビューを厚くする方が現実的な場合があります。一方で、定型変更や計画作業は承認とチケット連携を強くした方が監査しやすくなります。
よくある誤解
「PIMを入れれば管理者権限の問題は解決する」
PIMは強い仕組みですが、対象外のSaaS管理者、グループ経由の権限、OAuth同意、APIトークン、委託先アカウントが残れば、別経路で強い権限が残ります。SaaS権限棚卸しチェックリストと合わせて見る必要があります。
「承認があるからログ確認はいらない」
承認は作業前の判断です。実際に何をしたかは、監査ログやSaaS操作ログで確認します。承認理由と実施操作がずれていれば、設定ミス、作業逸脱、侵害疑いとして扱います。
「break glassもPIMで管理すればよい」
break glassは、PIM、IdP、MFA、条件付きアクセスが使えない時の最後の復旧経路です。通常のJIT経路と混ぜると、障害時に復旧できない、または日常作業の迂回路になる可能性があります。緊急用管理者アカウントの棚卸しで別枠として確認します。
「短時間なら高権限でも安全」
短時間でも、外部共有、トークン発行、OAuth同意、ログ設定変更、管理者追加は残ることがあります。時間制限は重要ですが、作業内容の記録と失効後確認がなければ不十分です。
関連用語・関連ページ
| 目的 | ページ |
|---|---|
| 実務チェックへ落とす | SaaS権限棚卸しチェックリスト、管理者権限付与の初動対応 |
| 例外運用を整理する | セキュリティ例外申請テンプレート、条件付きアクセス例外の棚卸し |
| 非常用経路を分ける | 緊急用管理者アカウントの棚卸し |
| 基礎概念を確認する | PAM、JIT Access、Zero Standing Privilege、Access Review |
| 権限判断の土台 | 認証と認可の違い、ゼロトラストアーキテクチャ |
| 手を動かして学ぶ | 認証・認可ミニCTF、アクセスログ解析ミニCTF |
公式情報・参考情報
- Microsoft Learn: What is Microsoft Entra Privileged Identity Management? — PIMのJIT、時間ベース、承認、MFA、理由入力、通知、アクセスレビュー、監査履歴の考え方を確認できる。
- Microsoft Learn: Plan a Privileged Identity Management deployment — 導入計画、対象ロール、パイロット、テスト、最小権限、緊急用アカウントとの関係を確認できる。
- Google Cloud: Privileged Access Manager overview — 一時的な権限昇格、申請者、理由、ロール、最大期間、承認、通知、監査ログの設計を確認できる。
- NIST: Zero Trust Architecture — 暗黙の信頼に依存せず、資源アクセス前に認証と認可を評価する考え方を確認できる。
まとめ
JIT Access / PIMは、管理者権限を減らすための単発設定ではありません。対象ロール、対象者、承認者、最大利用時間、理由入力、MFA、通知、監査ログ、失効後確認を合わせて設計する運用です。
最初は、Global Administrator、Security Administrator、クラウドOwner、GitHub Organization owner、監査ログやDLPを操作できるロールから始めます。パイロットで有効化、承認、失効、ログ確認まで試し、承認者不在や障害時の例外も先に決めます。
次に実務へ落とすなら、SaaS権限棚卸しチェックリストに「PIM対象ロール」「eligible/active分類」「最大利用時間」「承認者」「失効後確認」を追加し、四半期レビューで見直します。もし説明できない権限付与や不審な有効化が見つかった場合は、管理者権限付与の初動対応へ進み、証跡保全と関連SaaS確認を行います。
