メンテナンスのたびに管理者権限を使っている環境、意外と多いですよね。
特権アカウントは攻撃者にとって最大のターゲットです。Owner権限やグローバル管理者を常時持っているアカウントが1つ侵害されれば、リソースの削除、設定の改ざん、ログの消去、新しい管理者アカウントの作成まで、すべてが攻撃者の手に渡ります。
問題は「管理者権限を持っていること」ではありません。「常に」持っていることです。この発想の転換を実現するのがAzure PIM（Privileged Identity Management）です。
RBACの基本的な権限設計（ロール・スコープ・継承）については「RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説」を先にご確認ください。本記事はその特権管理の深掘りです。
常時特権が危険な理由
特権アカウント（Privileged Account）
システム設定の変更・ユーザー管理・リソース削除など、通常より強い操作権限を持つ管理者レベルのアカウント。
Azureにおける特権ロール（Owner・グローバル管理者など）を常時付与している環境で、実際に何度も見てきたリスクは大きく3つです。
侵害された瞬間に最大被害が確定すること。パスワードを盗まれた、フィッシングに引っかかった、セッションを乗っ取られた——その瞬間、攻撃者は何でもできる状態になります。一般権限のアカウントが侵害された場合とは被害の広がり方がまったく違います。
日常業務で使うほど侵害リスクが上がること。メール確認・Web閲覧・ファイル操作を管理者権限のアカウントで行うほど、フィッシングやマルウェアに接触する機会が増えます。特権は日常業務に持ち込まない、というのが基本です。
そして「いつ・誰が・何をしたか」が追跡しにくくなること。常時有効な特権アカウントは監査が難しく、通常業務と不正操作の区別がつきにくいため、インシデント時の原因特定を困難にします。
このリスクをコントロールする考え方がJIT（Just-In-Time）権限です。
JIT（Just-In-Time）権限
必要なときだけ一時的に強い権限を付与し、終わったら自動的に失効させるという考え方。常時特権をなくすことで侵害時の被害範囲を大幅に限定できる。
最小権限の原則をJITの観点で実践する方法については「最小権限の原則とは？実務での考え方と設計例」でも解説しています。
参考：特権アクセスのセキュリティ保護 | Microsoft Learn
PIMという発想
PIM（Privileged Identity Management）
Microsoft Entra IDが提供する特権アクセス管理機能。期限付き権限付与・承認ワークフロー・MFA強制・監査ログ取得を一元管理できる。
PIMは、JITという設計思想を、Azureの管理画面上で実際に運用できる形にしたものです。「理想はわかるけど、どうやって実現するの？」という問いへの答えがPIMです。
JITを実現する方法自体は複数あります（スクリプトでの自動付与・削除なども理論上は可能です）が、Azureの標準的な選択肢はPIMになります。
PIMでできることは大きく4つです。
| 機能 | 内容 |
|---|---|
| 期限付き権限付与 | 有効化時間（1時間など）を設定し、期限後は自動失効 |
| 承認ワークフロー | 特権有効化に上長や別管理者の承認を必須にできる |
| MFA強制 | 権限有効化のタイミングでMFA認証を必須にできる |
| 監査ログ | 誰がいつどの権限を有効化・使用したかを記録する |
ここで混乱しやすいのが、RBACとの役割分担です。
RBACは「何ができるか」を定義する仕組みで、Owner・Contributor・Readerのようにロールを設計し、誰にどのスコープで付与するかを決めます。
一方PIMは「いつ使えるか」を管理する仕組みで、RBACで定義したロールを常時有効にするのではなく、必要なときだけ一時的に有効化できる状態に変えます。
つまり両者は競合せず、RBACで設計した権限をPIMで安全に運用する、という組み合わせになります。
参考：Privileged Identity Management（PIM）とは | Microsoft Learn
申請から失効までの流れ
PIMを使った特権利用は、次のように進みます。
まずユーザーがPIM画面から「このロールを〇時間有効にしたい」と申請します。理由の入力が必須になっている場合はその記載も行います。次に、設定によっては承認者（上長・別の管理者）に通知が届き、承認・却下が行われます。承認不要にすることも可能ですが、高権限ロールほど承認を必須にする設計が推奨されます。
承認後（または承認不要の設定の場合は申請直後）、MFA認証が求められることがあります。これにより「パスワードだけで特権を取れる」状態をなくせます。MFAの仕組みについては「MFAとは？多要素認証の仕組みと実務での導入・運用ガイド」を参照してください。
そして設定した時間だけロールが有効になり、この間だけ特権操作が可能になります。有効化時間が終了すると自動的にロールが無効化されますが、手動での失効も可能です。
Eligible と Active、現場で一番間違えるところ
PIMを設定する際に最も重要な概念が、EligibleとActiveの違いです。現場での誤設定の大半は、ここの理解不足から生まれます。
Eligible（対象）
「有効化を申請できる状態」のこと。権限は持っていないが、申請すれば一時的に使える。PIMの基本的な使い方。
Active（有効）
「常時その権限を持っている状態」のこと。PIMを設定していても、Activeにすれば従来通り常時有効になってしまう。
| 設定 | 状態 | PIMを使っているか |
|---|---|---|
| Eligible | 申請して初めて使える | JITが機能している |
| Active（期限あり） | 一定期間は常時有効 | 緊急時などの一時利用に限定すべき |
| Active（期限なし） | 常時有効 | PIMの意味がない |
一番よく見る誤設定は、PIMを導入したにもかかわらず全員をActiveのままにしてしまうケースです。見た目はPIMが動いていますが、JITとして機能していません。基本はEligible、やむを得ない場合のみ期限付きActiveとする設計を徹底してください。
承認の要否も、ロールの強度に応じて設計します。
| ロール例 | 推奨設定 |
|---|---|
| Owner / グローバル管理者 | 承認必須・MFA強制・最大1〜2時間 |
| Contributor | 承認必須 or 自己承認・MFA強制・最大4〜8時間 |
| Reader相当 | 承認不要でも可 |
承認者は1名ではなく複数名設定することをおすすめします。承認者が1名だと、その人が不在・退職した際に特権が使えなくなるリスクがあります。
有効化時間の上限は、業務内容によって変わりますが、考え方の型はシンプルです。「その作業は何時間で完了するか」を基準にして、それより少し長い時間（バッファ込み）を上限にします。定期メンテナンスが2時間なら3時間、緊急対応でも1営業日（8時間）を超えることはほぼないはずです。「とりあえず24時間」は常時有効と変わらず、JITの意味をなしません。
参考：PIM で Azure リソース ロールを設定する | Microsoft Learn
監査ログ、入れただけで終わっていないか
PIMの導入で見落とされがちなのが、監査ログの活用です。PIMを入れた後にログを誰も確認していない状態は、「証拠は残っているが誰も見ていない」という状況にほかなりません。
PIMの監査ログでは、誰がいつどのロールの有効化を申請したか、承認・却下された記録、有効化中にどのリソースへどの操作を行ったか、有効化が失効したタイミングを確認できます。この記録を定期的にレビューすることで、不審な特権利用の早期発見、想定外のロール有効化パターンの検出、監査・コンプライアンス対応の証跡確保ができます。
実務での組み込み方としては、月次レビューをルール化することをおすすめします。「誰がOwnerを何回有効化したか」「深夜・休日の有効化がないか」を月1回確認するだけで、異常の早期検出につながります。大規模環境では、PIMのログをSIEMに転送し、アラートを自動化することで見逃しを防げます。
SIEM（Security Information and Event Management）
複数システムのセキュリティログを収集・分析し、異常を検知・アラートする仕組み。Microsoft SentinelはAzureネイティブのSIEM。
参考：PIM の監査履歴を表示する | Microsoft Learn
見てきた運用の崩れ方
PIMを導入した現場で、実際によく見る崩れ方が3つあります。
1つ目は、全員をActiveのままにしてしまうケースです。「業務が止まると困る」という理由で、導入したはずのPIMが実質機能していない状態になります。まず1つのロール・1人の管理者から試験的にEligibleに切り替え、運用フローを確認しながら段階的に展開する方法が現実的です。
2つ目は、有効化時間を長く設定しすぎるケースです。「念のため72時間」のような設定は、常時有効と変わりません。作業時間から逆算して上限を決める習慣をつけてください。緊急時用であれば「最大8時間・承認必須」という設計が現実的な上限の目安です。
3つ目は、PIMを入れたが監査ログを誰も見ていないケースです。最も多い運用の形骸化パターンで、ログは残っているが誰もレビューしない状態では、インシデント発生後に「ログはありました」という後追いにしかなりません。月次レビューの担当者と確認項目を明文化し、組織のルールとして定着させることが重要です。
これらの失敗パターンはAzure RBAC設計全般の失敗とも共通する部分があります。詳しくは「Azure RBAC設計でよくある失敗6選と対策」も合わせて参照してください。
今日確認すること
設計面
- [ ] 特権ロール（Owner・グローバル管理者等）をEligibleに設定しているか
- [ ] 有効化時間の上限が業務時間に基づいて設定されているか
- [ ] 高権限ロールに承認ワークフローを設定しているか
- [ ] 有効化時にMFA認証を必須にしているか
- [ ] 承認者が複数名設定されているか
運用面
- [ ] 月次で監査ログをレビューする担当者が決まっているか
- [ ] 深夜・休日の不審な有効化を検知する仕組みがあるか
- [ ] 緊急時の特権利用フロー（誰が承認するか）が定められているか
- [ ] Activeに設定しているロールが最小限になっているか
IAM設計全体の抜け漏れ確認は「クラウドIAM設計チェックリスト｜抜け漏れを防ぐ実践ガイド」もあわせてご活用ください。
一番最初にやってほしいのは、自分の環境でOwnerやグローバル管理者のロールがActiveで常時付与されていないかを確認することです。そこから始めるだけで、最悪の侵害シナリオのリスクを大きく下げられます。「管理者権限は常に持っておくものだ」という前提を疑うところから、PIM導入は始まります。
認証・権限設計・特権管理がひとつながりで機能することで、IAMは「守れる設計」になります。IAMの全体像については「IAMとは？認証と認可の違いから学ぶアクセス管理の基本」を参照してください。
コメント