PIMとは？Azure特権アクセス管理の実務ガイド

「メンテナンスのたびに管理者権限を使っている」——その運用、侵害されたら環境全体が終わりです。

特権アカウントは攻撃者にとって最大のターゲットです。Owner権限やグローバル管理者を常時持っているアカウントが1つ侵害されれば、リソースの削除、設定の改ざん、ログの消去、新しい管理者アカウントの作成まで——すべてが攻撃者の手に渡ります。

問題は「管理者権限を持っていること」ではありません。「常に持っていること」です。

この発想の転換を実現するのが Azure PIM（Privileged Identity Management） です。特権を「持つもの」から「必要なときだけ使うもの」に変える仕組みについて、設計・設定・運用の実務レベルで解説します。

RBACの基本的な権限設計（ロール・スコープ・継承）については「RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説」を先にご確認ください。本記事はその特権管理の深掘りです。

管理者権限を「常に持つ」ことのリスク

特権アカウント（Privileged Account） システム設定の変更・ユーザー管理・リソース削除など、通常ユーザーより強い操作権限を持つ管理者レベルのアカウント。

Azureにおける特権ロール（Owner・グローバル管理者など）を常時付与している状態では、次のリスクが常に存在します。

侵害された瞬間に最大被害が確定する。 パスワードを盗まれた、フィッシングに引っかかった、セッションを乗っ取られた——その瞬間、攻撃者は何でもできる状態になります。一般権限のアカウントが侵害された場合とは被害の広がり方がまったく異なります。

日常業務で使うほど侵害リスクが上がる。 メール確認・Web閲覧・ファイル操作を管理者権限のアカウントで行うほど、フィッシングやマルウェアに接触する機会が増えます。特権は日常業務に持ち込まない、というのが基本的な考え方です。

「いつ・誰が・何をしたか」が追跡しにくくなる。 常時有効な特権アカウントは監査が難しくなります。どの操作が通常業務でどれが不正なのかの区別がつきにくく、インシデント発生時の原因特定を困難にします。

このリスクをコントロールする考え方が JIT（Just-In-Time）権限 です。

JIT（Just-In-Time）権限 「必要なときだけ一時的に強い権限を付与し、終わったら自動的に失効させる」という設計思想。常時特権をなくすことで侵害時の被害範囲を大幅に限定できる。

最小権限の原則をJITの観点で実践する方法については「最小権限の原則とは？実務での考え方と設計例」でも解説しています。

参考：特権アクセスのセキュリティ保護 | Microsoft Learn

PIMとは何か——JITを実現するAzureの仕組み

PIM（Privileged Identity Management） Microsoft Entra IDが提供する特権アクセス管理機能。期限付き権限付与・承認ワークフロー・MFA強制・監査ログ取得を一元管理できる。

PIMはJITという考え方を、Azureの管理画面上で実際に運用できる形にした機能です。「理想はわかるけど、どうやって実現するの？」という問いへの答えがPIMです。

JITとPIMの関係

JITは設計思想、PIMはその実装手段です。JITを実現する方法は複数ありますが（スクリプトでの自動付与・削除なども含む）、AzureではPIMが標準的な選択肢になっています。

PIMでできる4つのこと

RBACとPIMの役割分担

混乱しやすいポイントなので整理します。

RBACは「何ができるか」を定義する仕組みです。Owner・Contributor・Readerのようにロールを設計し、誰にどのスコープで付与するかを決めます。

PIMは「いつ使えるか」を管理する仕組みです。RBACで定義したロールを、常時有効にするのではなく「必要なときだけ一時的に有効化できる状態」に変えます。

つまりRBACとPIMは競合しません。RBACで設計した権限をPIMで安全に運用する、という組み合わせです。

参考：Privileged Identity Management（PIM）とは | Microsoft Learn

PIMの動作フロー——有効化から作業完了まで

PIMを使った特権利用の流れは次の通りです。

① 申請 — ユーザーがPIM画面から「このロールを〇時間有効にしたい」と申請します。理由の入力が必須になっている場合はその記載も行います。

② 承認（設定による）— 承認者（上長・別の管理者）に通知が届き、承認・却下を行います。承認不要の設定にすることも可能ですが、高権限ロールほど承認を必須にする設計が推奨されます。

③ MFA認証 — PIMで設定している場合、有効化のタイミングでMFA認証が求められます。これにより「パスワードだけで特権を取れる」状態をなくせます。MFAの仕組みについては「MFAとは？多要素認証の仕組みと実務での導入・運用ガイド」を参照してください。

④ 有効化・作業 — 設定した時間だけロールが有効になります。この間だけ特権操作が可能です。

⑤ 失効 — 有効化時間が終了すると自動的にロールが無効化されます。手動での失効も可能です。

Azure PIMの設定：対象ロールと承認フローの組み方

対象（Eligible）と有効（Active）の違い

PIMを設定する際に最も重要な概念がこの2つです。現場での誤設定の大半はここの理解不足から生まれます。

Eligible（対象） 「有効化を申請できる状態」のこと。権限は持っていないが、申請すれば一時的に使える。PIMの基本的な使い方。

Active（有効） 「常時その権限を持っている状態」のこと。PIMを設定していても、Activeにすれば従来通り常時有効になる。

整理すると次の通りです。

よくある誤設定は、PIMを導入したにもかかわらず全員をActiveのままにしてしまうケースです。見た目はPIMが動いていますが、JITとして機能していません。基本はEligible、やむを得ない場合のみ期限付きActiveとする設計を徹底してください。

承認ワークフローの設計

承認の要否はロールの強度に応じて設計します。

承認者は1名ではなく複数名設定することを推奨します。承認者が1名だと、その人が不在・退職した際に特権が使えなくなるリスクがあります。

有効化時間の上限をどう決めるか

「何時間にすればいいか」は業務内容によりますが、考え方の型があります。

「その作業は何時間で完了するか」を基準にして、それより少し長い時間（バッファ込み）を上限にします。定期メンテナンスが2時間なら3時間、緊急対応でも1営業日（8時間）を超えることはほぼないはずです。「とりあえず24時間」は常時有効と変わらず、JITの意味をなしません。

参考：PIM で Azure リソース ロールを設定する | Microsoft Learn

PIMの監査ログをどう使うか——証跡を設計に組み込む

PIMの導入で見落とされがちなのが、監査ログの活用です。PIMを入れた後にログを誰も確認していない状態は、「証拠は残っているが誰も見ていない」という状況です。

PIMの監査ログでは次の情報が確認できます。

• 誰がいつどのロールの有効化を申請したか
• 承認・却下された記録
• 有効化中にどのリソースへどの操作を行ったか
• 有効化が失効したタイミング

この記録を定期的にレビューすることで、不審な特権利用の早期発見、想定外のロール有効化パターンの検出、監査・コンプライアンス対応の証跡確保ができます。

実務での組み込み方として推奨するのは次の2点です。

月次レビューをルール化する。 「誰がOwnerを何回有効化したか」「深夜・休日の有効化がないか」を月1回確認するだけで、異常の早期検出につながります。

Microsoft Sentinelと連携する。 大規模環境ではPIMのログをSIEM（セキュリティ情報・イベント管理）ツールに転送し、アラートを自動化することで見逃しを防げます。

SIEM（Security Information and Event Management） 複数のシステムからセキュリティログを収集・分析し、異常を検知・アラートする仕組み。Microsoft SentinelはAzureネイティブのSIEM。

参考：PIM の監査履歴を表示する | Microsoft Learn

実務でよくある失敗と対策

① 全員をActive（常時有効）のままにしてしまう

PIMを導入したが「業務が止まると困る」という理由で全員をActiveのままにしているケースです。これはPIMを入れていないのと実質同じです。まず1つのロール・1人の管理者から試験的にEligibleに切り替えて、運用フローを確認しながら段階的に展開する方法が現実的です。

② 有効化時間を長く設定しすぎる

「念のため72時間」のような設定は常時有効と変わりません。作業時間から逆算して上限を決める習慣をつけてください。緊急時用であれば「最大8時間・承認必須」という設計が現実的な上限の目安です。

③ PIMを入れたが監査ログを誰も見ていない

最も多い運用の形骸化パターンです。ログは残っているが誰もレビューしない状態では、インシデント発生後に「ログはありました」という後追いにしかなりません。月次レビューの担当者と確認項目を明文化し、組織のルールとして定着させることが重要です。

これらの失敗パターンはAzure RBAC設計全般の失敗とも共通する部分があります。詳しくは「Azure RBAC設計でよくある失敗6選と対策」も合わせて参照してください。

PIM導入チェックリスト

設計面

• 特権ロール（Owner・グローバル管理者等）をEligibleに設定しているか
• 有効化時間の上限が業務時間に基づいて設定されているか
• 高権限ロールに承認ワークフローを設定しているか
• 有効化時にMFA認証を必須にしているか
• 承認者が複数名設定されているか

運用面

• 月次で監査ログをレビューする担当者が決まっているか
• 深夜・休日の不審な有効化を検知する仕組みがあるか
• 緊急時の特権利用フロー（誰が承認するか）が定められているか
• Activeに設定しているロールが最小限になっているか

IAM設計全体の抜け漏れ確認は「クラウドIAM設計チェックリスト｜抜け漏れを防ぐ実践ガイド」もあわせてご活用ください。

まとめ——特権は「持つもの」から「使うもの」へ

PIMの本質は技術的な機能の話ではありません。特権に対する考え方を変えることです。

「管理者権限は常に持っておくものだ」という前提を「特権は必要なときだけ使うものだ」に変える——この意識の転換がPIM導入の最大の効果です。

まず今日確認すべきことは1つ。自分の環境でOwnerやグローバル管理者のロールがActiveで常時付与されていないかを確認してください。そこから始めるだけで、最悪の侵害シナリオのリスクを大きく下げられます。

認証・権限設計・特権管理がひとつながりで機能することで、IAMは「守れる設計」になります。IAMの全体像については「IAMとは？認証と認可の違いから学ぶアクセス管理の基本」を参照してください。

あわせてご覧ください

• RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説
• Azure RBAC設計でよくある失敗6選と対策
• MFAとは？多要素認証の仕組みと実務での導入・運用ガイド
• 最小権限の原則とは？実務での考え方と設計例
• IAMとは？認証と認可の違いから学ぶアクセス管理の基本