特権IDは王国の鍵-Googleが特権アカウント監視ガイドを公表|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2025年10月31日更新日時: 2025年10月31日

Google傘下のMandiantが公開した「Keys to the Kingdom: A Defender’s Guide to Privileged Account Monitoring」は、特権IDの防御を「予防」「検知」「対応」の3本柱で整理しています

1 要点
2 IDと権限が分散・重複する理由
3 特権の定義を作り直す（人・非人・経路まで）
4 カテゴリ別の考え方（人間ID／非人間ID）
5 PAMの成熟度ロードマップ（4段階）
6 製品導入で終わらせないPAM運用
7 経路と端末のハードニング（横移動対策の本丸）
8 認証情報居場所と寿命を短くする
9 JIT/JEA/ZSPで必要な時だけ最小権限
10 監視と自動応答（許可済みだが異常を捕まえる）
11 運用にそのまま使える検知サンプル
12 自社での手作りPAMを選ぶ場合の落とし穴
13 インシデント発生時の対応骨子
14 バックアップと仮想化基盤の防御（復旧の生命線）
15 まず何から始めるか（短期アクション10）

要点

要点は次のとおりです。

特権の定義を拡張し、人間以外のID（サービス・アプリ・API）とアクセス経路（PAW/ジャンプ/管理ネットワーク）を含めて管理する。
「Privileged Access Management（特権アクセス管理）は製品導入ではなく運用プログラム。台帳・ロール設計・JIT/JEA・監査・自動ローテーションまで一体で回す。
監視は許可済みだが異常を炙り出すことに重心を置き、セッション記録や行動分析、自動封じ込めまで含める。

IDと権限が分散・重複する理由

IDと権限が分散・重複し、恒常的な管理者権限（Standing Privilege）が各所に残りがちです。

特権の通り道（RDP/WinRM/SSH、ジャンプ、管理ネットワーク、バックアップ基盤、仮想化基盤）が十分に分離されていないと、踏み台化して被害半径が一気に広がります。サービスアカウントやAPIキーは監視・棚卸しが遅れやすく、攻撃者にとって静かな抜け道になりやすいのが実情です。

特権の定義を作り直す（人・非人・経路まで）

特権＝「誤用時に資産へ重大影響を与える権限」と定義します。人間IDだけでなく、サービス／アプリIDやAPIキーを同じレンズで評価し、次を単一台帳で管理します。

所有者・用途・到達先資産・許可アクション・Tier（T0/T1/T2）
許可経路（PAW/ジャンプ/管理ネットワーク）
SoD（職務分掌）制約
この台帳は四半期ごとに再認定し、シャドー管理者（リソースACLやSaaS管理権限で実質フル権限）も洗い出して是正します。

カテゴリ別の考え方（人間ID／非人間ID）

人間ID：ドメイン管理者、ローカル管理者、SaaS/クラウドの全体管理者、開発者、高感度データに触れる業務ユーザ。
非人間ID：サービス/アプリアカウント、CI/CD用トークン、APIキー。
いずれもどこで使えるか（Residency）を厳密に定義し、対話・RDP・ネットワークログオンの可否、利用ホスト、時間帯などを制約します。

PAMの成熟度ロードマップ（4段階）

Uninitiated：共有ID・台帳はスプレッドシート、MFA不徹底、退職者権限が残りがち。
Ad-Hoc：一部の共有IDを金庫化、だが運用は点在。
Repeatable：RBAC標準化、全管理経路MFA、LAPS、PAW導入、JIT/JEAの試行、台帳の定期認定。
Iterative Optimization：自動化前提。発行→承認/JIT→セッション監視→自動ローテ→廃止まで一気通貫。特権ゼロ常設（ZSP）に近づけ、検知とSOARで自動封じ込め。

製品導入で終わらせないPAM運用

専用PAM（例：CyberArk、BeyondTrust、Delinea等）は中核ですが、次を運用設計に落とし込まないと金庫に入れただけで終わります。

台帳とTier設計に基づくポリシー（ローテ周期、JIT/JEA、承認フロー、経路制限、セッション録画）。
リソース側の実効権限（ACL、DBロール、SaaSスコープ、クラウドIAM）の定期クロールと差分是正。
IGA/CIEMやネイティブ出力でのシャドー権限検知と、PAM台帳へのフィードバック。

経路と端末のハードニング（横移動対策の本丸）

直通禁止：RDP/SSHのインターネット露出禁止。PAW/ジャンプ経由＋MFA＋記録で集約。
ネットワーク分離：管理ネットワークはユーザLANから閉域化。PAWとPAMセッションマネージャのみ到達可。
プロトコル衛生：SMB署名、Kerberos優先、NTLM縮退、管理共有の無効化。WinRMは暗号化強制、HTTPS優先。RDPはNLA必須。
端末統制：アプリ許可制（WDAC/AppLocker等）、PowerShell制限・スクリプトログ、Credential Guard/LSA保護、EDR常時監視。
Tier運用：PAW/ジャンプはT0/T1として強化プロファイルを適用。

認証情報居場所と寿命を短くする

再利用ブロック：管理者IDは一般端末にログオン不可。ローカル管理者は端末単位で一意＋自動ローテ（LAPS等）。
サービスアカウント最適化：gMSA/マネージドIDを優先し、取得可能ホストを制限。対話/RDPは禁止。委任は制約付きのみ。
メモリ/キャッシュ対策：平文キャッシュ無効化、パスザハッシュ・チケット再利用を困難化。
シークレット管理：Key Vault系に集約し、HSM連携、二人承認、完全監査、自動ローテ、冗長構成、セキュアバックアップを前提化。

JIT/JEA/ZSPで必要な時だけ最小権限

JEA：コマンド単位で最小権限。ヘルプデスクにアカウントロック解除だけを公開など。
JIT：時間制御の昇格。承認後に短時間だけ付与し、自動失効。
ZSP：恒常管理者権限を原則ゼロに。昇格はJIT＋二要素＋セッション録画が標準。

監視と自動応答（許可済みだが異常を捕まえる）

可観測性の粒度：PAMのチェックアウト・承認・セッション記録、IdPサインイン、PAW姿勢、EDRプロセス、ネットワーク、変更履歴、チケット情報を一つの時間軸で相関。
高優先度の具体例：
- 新規ジオからの特権ログイン、短時間での失敗連打→成功。
- T0アカウントでのロール変更、トークン/キー作成、ポリシー変更。
- GPO改変（既定ドメインポリシー等）、仮想基盤の権限変更/ISOマウント/スナップショット、バックアップ保持期間の短縮。
自動封じ込め：しきい値超過でセッション強制終了、トークン失効、シークレット即時ローテ、アカウント一時停止まで自動化。

運用にそのまま使える検知サンプル

アノマリーログイン：特権IDの新規デバイス/地域。
高インパクト・ブルートフォース：短時間の連続失敗からT0での成功。
資格情報露出兆候：意図しないパスワードリセット、回復用連絡先の変更。
GPO変更：既定ポリシーの編集、スケジュールタスク追加。
サービスアカウント逸脱：定義外ホスト・時間での使用、想定外システムへのアクセス。
信頼サービス基盤：資産/パッチ管理、仮想化、セキュリティツールでの異常操作。

自社での手作りPAMを選ぶ場合の落とし穴

自動探索がないと在庫管理は手作業で破綻しやすく、統一ポリシーの徹底も困難です。ログが分散して相関ができず、対応の遅れや抜け漏れが増えます。監査対応も記録不足で負荷が高止まりします。開始の選択肢としてはあり得ますが、リスクと人手コストが相応に上がる点は理解しておくべきです。

インシデント発生時の対応骨子

即時隔離：疑わしい管理端末を切り離し、クラウドはアクティブセッションとリフレッシュトークンを失効。
証跡強化：Vault/PAM/IdP/OS/EDRの監査レベルを引き上げて証拠を確保。
一斉ローテ（EPR）：ドメイン/ローカル/サービス/アプリ/クラウド/APIキー/連携まで段階計画で一気通貫。KRBTGT二重ローテの計画も含める。
ブレークグラス運用：オフライン保管・二人承認で使用し、使用後は即ローテーション。
復旧順序：T0（IdP、Vault、PAM、仮想化、バックアップ）→T1（基幹）→T2（端末）。隔離環境での検証復旧で再汚染を防止。

バックアップと仮想化基盤の防御（復旧の生命線）

仮想化：管理プレーンをT0扱い。専用ID、MFA、ネットワーク分離、RBAC、ホストのLockdown、有事の直コンソールはブレークグラスのみ。
バックアップ：3-2-1原則、WORM/イミュータブル、隔離復元環境。バックアップ管理者のIDは一次IdPと分離し、承認制とセッション記録を必須化。保持/削除ポリシー変更はクリティカルアラート。