PAMの誤設定が攻撃の橋になる理由:Microsoft Incident Responseが警告する特権アクセス管理の設計ミス

PAM(Privileged Access Management)は特権IDを守るための重要な仕組みですが、設計を誤ると「防御壁」ではなく攻撃者の橋になります。特に、Tier 0を管理するPAMサーバーやセッションホストがTier 1相当の環境に置かれている場合、攻撃者はPAM製品そのものの脆弱性を突かなくても、下位ティアからDomain Controllerや認証基盤へ到達できる可能性があります。

Microsoft Security Experts Blogは、2026年4月15日に公開した記事で、Microsoft Incident Response / DARTの現場経験として「PAMの配置ミスがティアリングモデルを壊す」ケースを取り上げました。要点はシンプルです。Tier 0を管理するPAMコンポーネントは、物理的な設置場所ではなく“管理対象の重要度”に合わせてTier 0として扱うべきです。(TECHCOMMUNITY.MICROSOFT.COM)

この記事では、Identity security architectsとincident responders向けに、なぜPAMが攻撃経路になるのか、どの設計が危険なのか、すぐ確認すべきチェックポイント、そして安全なPAMアーキテクチャの考え方を実務目線で整理します。

目次

Microsoft Incident Responseが警告する「PAMが攻撃の橋になる」問題

Microsoftの記事で重要なのは、「PAMが悪い」と言っているわけではない点です。問題はPAM製品ではなく、PAMをどのティアに置き、誰が管理でき、どのネットワークから到達できるかという設計です。

Microsoft Incident Response / DARTの事例では、攻撃者がゼロデイを使わず、侵害済みのヘルプデスク端末から組織のPAMサーバーを経由して、4時間未満でドメイン侵害に至ったケースが紹介されています。攻撃者は高度な暗号解読ではなく、組織自身が作った「Tier 1からTier 0への橋」を利用しました。(TECHCOMMUNITY.MICROSOFT.COM)

PAMは本来、特権認証情報の保管、セッション仲介、パスワードローテーション、監査ログ取得などを担います。しかし、Tier 0の資格情報やセッションを扱うPAMホストがTier 1管理者に制御されていると、Tier 1の侵害がそのままTier 0の侵害につながります。

まず押さえるべき結論

判断ポイント安全な考え方危険な考え方
PAM Vault / CoreTier 0資格情報を扱うならTier 0資産として管理するサーバーがTier 1ネットワークにあるのでTier 1扱いにする
PAM Session Host管理対象ティアごとに分離するすべての管理者が同じセッションホストを使う
サービスアカウント権限範囲ごとに分離し、Tier 0権限を持つものはTier 0基準で保護するパスワードリセット用の強力なアカウントを汎用サーバー上で動かす
管理元端末Tier 0管理はPAWなど専用端末からのみ許可する一般端末やヘルプデスク端末からPAMポータルへ到達できる
評価基準「何を管理するか」でティアを決める「どこに設置したか」でティアを決める

この表の中で最も重要なのは、PAMコンポーネントの格付けを「設置場所」ではなく「到達できる権限」で決めることです。

なぜPAMの誤設定はティアリングモデルを壊すのか

Active Directoryのティアリングモデルは、特権資格情報の露出を防ぐための設計です。一般的には、Domain Controller、PKI、認証基盤、これらを管理するIDがTier 0、アプリケーションサーバーや業務サーバーがTier 1、ユーザー端末がTier 2として扱われます。Microsoftの記事でも、Tier 0は認証プレーンを管理する制御基盤、Tier 1はアプリケーションとデータ、Tier 2はユーザー端末やインターネットに触れる高リスク環境として説明されています。(TECHCOMMUNITY.MICROSOFT.COM)

ティアリングの原則は、「上位ティアの管理者資格情報を下位ティアに露出させない」ことです。たとえば、Domain Adminが一般端末にログオンすれば、その端末が侵害された時点でTier 0の資格情報が危険にさらされます。

PAMの落とし穴は、PAMが管理者と対象システムの間に立つintermediary、つまり中継点になることです。Microsoft Learnでは、VPN、ジャンプサーバー、VDI、アクセスプロキシなど、ユーザーと対象リソースの間に入るものをintermediaryとして扱い、そのセキュリティがエンドツーエンドの信頼性に影響すると説明しています。(Microsoft Learn)

つまり、PAMセッションホストを通じてDomain Controllerを管理するなら、そのPAMセッションホスト自体もTier 0の一部として扱わなければなりません。PAMがTier 0への通路である以上、PAMの制御を奪われることは、Tier 0への通路を奪われることに近いからです。

典型的な攻撃シナリオ:共有セッションホストが「汚れた中継点」になる

最も分かりやすい危険パターンは、Tier 0管理者とTier 1管理者が同じPAMセッションホストを使っている構成です。Microsoftの記事では、このような共有中継点を「Shared」または「Dirty」Intermediaryとして説明しています。(TECHCOMMUNITY.MICROSOFT.COM)

攻撃の流れは次のようになります。

段階攻撃者の動き防御側の設計ミス
初期侵害フィッシングなどでTier 2端末を侵害する一般端末の侵害を前提にした分離が弱い
横展開ヘルプデスク権限や露出したサービスアカウントを悪用し、Tier 1管理者権限を得るTier 1の権限が広すぎる、監視が弱い
PAMホスト制御Tier 1上のPAM Session HostをOSレベルで制御するPAMホストをTier 1管理者が管理できる
Tier 0セッション待ちTier 0管理者がPAM経由でDomain Controllerへ接続するのを待つTier 0とTier 1が同じセッション基盤を共有している
ドメイン侵害セッションや資格情報を悪用してDomain Controllerへ到達するPAMの中継点がTier 0基準で保護されていない

ここで重要なのは、攻撃者がPAM製品の脆弱性を必ずしも必要としない点です。PAMホストのOSを制御できれば、設定変更、セキュリティ機能の無効化、監視回避、資格情報処理への干渉といった操作が可能になります。Microsoftの記事も、この問題はPAM製品の失敗ではなく、アーキテクチャ上の配置ミスだと説明しています。(TECHCOMMUNITY.MICROSOFT.COM)

もう一つの盲点:PAMサービスアカウントが「マスターキー」になる

PAMのリスクは、管理者セッションだけではありません。より静かで危険なのが、PAMサービスアカウントです。

多くのPAMは、特権アカウントのパスワードローテーションや自動注入を行います。この機能自体は有効ですが、Domain Admin相当のパスワードをリセットできるPAMサービスアカウントは、非常に強力な権限を持ちます。

Microsoftの記事では、PAM CoreやVaultがTier 1に置かれているにもかかわらずTier 0資格情報を管理している場合、実質的にTier 1資産へDomain Admin相当の権限を与えていることになると指摘しています。攻撃者がPAMサービスの稼働サーバーを侵害できれば、人間のTier 0管理者がログオンするのを待たずに、サービスアカウントを悪用してTier 0へ昇格できる可能性があります。(TECHCOMMUNITY.MICROSOFT.COM)

設計レビューで見るべきポイント

PAMサービスアカウントについては、次の観点で棚卸しします。

確認項目確認すべき内容危険な兆候
権限範囲どのアカウントやグループのパスワードを変更できるかDomain Admin、Enterprise Admin相当を広く変更できる
稼働場所サービスがどのサーバー、OU、ネットワークで動いているかTier 1 OU、汎用管理ネットワーク、共有仮想基盤に配置されている
管理者OS、PAMアプリ、DB、バックアップを誰が管理できるかTier 1管理者、仮想基盤管理者、バックアップ管理者が実質的に制御できる
認証情報保護シークレット、証明書、APIキーの保管とローテーション方法手動管理、共有パスワード、長期間未変更
監視利用、変更、失敗、権限昇格を検知できるかサービスアカウントの利用が通常運用ログに埋もれている

「PAMに入れているから安全」ではありません。PAMを動かすアカウントそのものがどこまで権限を持つかを見なければ、攻撃者にとっての最短経路を見落とします。

危険なPAM設計に共通するパターン

PAM misconfiguration storiesが実務者の関心を集める理由は、単なる設定ミスではなく、組織の設計思想の盲点を露出させるからです。特に次のような構成は、インシデント対応時に大きな問題になりやすいと考えるべきです。

すべての管理者が同じPAMポータルとセッションホストを使う

コストや運用効率を理由に、Tier 0、Tier 1、Tier 2の管理作業を同じPAM基盤に集約する構成はよくあります。監査ログも一元化でき、運用担当者にとっては便利です。

しかし、セッションホストや管理ポータルが共有されると、下位ティアの侵害が上位ティアへ波及します。特に、Tier 1管理者がPAMホストのOS管理権限を持っている場合、Tier 0管理セッションの安全性はTier 1の安全性に引き下げられます。

PAMサーバーが一般ユーザーネットワークから到達可能

PAMポータルが社内ネットワーク全体から開ける、VPN接続後に一般端末から到達できる、管理ゾーンとユーザーゾーンの境界が弱い、といった構成も危険です。

Microsoft Learnでは、オンプレミスやIaaS上のPIM/PAMサービスはインターネットに直接公開されていない場合でも、侵害された資格情報とVPNなどのリモートアクセス経路によって到達され得ると説明しています。(Microsoft Learn)

「インターネットに公開していないから安全」と判断するのは不十分です。攻撃者は、すでに社内に入った後の横展開先としてPAMを探します。

Tier 0とTier 1で同じ管理アカウントを使う

同じ「admin」アカウントや同じ個人特権IDでTier 0とTier 1の両方を管理している場合、資格情報の露出範囲が広がります。

たとえば、ある管理者がTier 1サーバーのトラブル対応でPAMへログオンし、同じアカウントでDomain Controller管理にも使える状態なら、Tier 1侵害時にTier 0への道が近くなります。アカウントは人単位ではなく、ティアと用途単位で分離するのが基本です。

仮想基盤・バックアップ・EDR管理者の権限を見落とす

PAMサーバーのOS管理者だけを見ても不十分です。実際には、次のような役割もPAM基盤を実質的に制御できる場合があります。

  • ハイパーバイザー管理者
  • ストレージ管理者
  • バックアップ管理者
  • EDR / AV管理者
  • ソフトウェア配布基盤の管理者
  • GPOを適用できるAD管理者
  • 証明書やシークレット管理基盤の管理者

PAMサーバーがTier 0を扱うなら、これらの周辺管理者もTier 0相当の影響を持ち得ます。ここを見落とすと、表面上は分離されていても、実際にはTier 1からTier 0へ操作できる隠れた橋が残ります。

すぐできるPAM露出チェックリスト

インシデント対応中や設計レビューの初期段階では、完璧なアーキテクチャ図を待つより、危険な橋を早く見つけることが重要です。Microsoftの記事でも、DARTがPAM展開をセキュリティ資産か負債か判断するためのチェック項目を示しています。(TECHCOMMUNITY.MICROSOFT.COM)

以下のチェックを使うと、現場で優先順位を付けやすくなります。

チェック項目質問「はい」なら疑うべきリスク
中継点Domain Controllerを管理するサーバーに、Tier 1サーバーや標準端末からRDP / SMB / 管理接続できるかティア間ブリッジ
ID分離Tier 0作業とTier 1作業で同じ管理アカウントを使っているか資格情報の横展開
到達性PAM Vault / Coreへ一般ユーザーネットワークから到達できるか社内侵害後の横展開先化
セッション分離Tier 0用Session HostとTier 1用Session Hostが分かれているか共有中継点による資格情報露出
管理権限Tier 1管理者がPAMホストのOS、GPO、EDR、バックアップ、仮想基盤を操作できるかOSレイヤーからの制御奪取
サービスアカウントPAMサービスアカウントがTier 0資格情報を変更・取得できるかマスターキー化
監視PAM基盤への管理操作、設定変更、サービス停止、EDR無効化を検知できるか攻撃準備の見逃し

このチェックで1つでも該当する場合、まず「PAMが突破されたら何ができるか」を図にします。対象がDomain Controller、認証局、Entra ID同期基盤、Privileged Role Administrator、Global Administratorなどに伸びているなら、Tier 0資産として扱う必要があります。

安全なPAMアーキテクチャの基本:管理対象のティアに合わせて分離する

Microsoftの記事が推奨している方向性は、PAMを捨てることではありません。PAMをEnterprise Access Modelやティアリングの考え方に合わせて配置し直すことです。Microsoft LearnのEnterprise access modelは、従来のADティアモデルを、オンプレミス、クラウド、複数環境を含む現代的なアクセス管理モデルへ拡張する考え方を示しています。(Microsoft Learn)

実務では、次のように考えると整理しやすくなります。

Tier 0を扱うPAM Core / VaultはTier 0として保護する

PAM Vault、Policy Manager、Credential Store、管理DB、暗号鍵、API連携基盤がTier 0資格情報を扱う場合、それらはTier 0です。

そのため、管理はTier 0管理者に限定し、管理端末もTier 0 PAWからに制限します。Tier 1管理者がOS更新やバックアップの名目で触れる構成は、例外ではなくリスクとして扱います。

Session Hostはティアごとに分ける

単一の「強化済みセッションホスト」を全ティアで共有する設計は避けるべきです。Microsoftの記事でも、DARTの経験として、単一の強化済みホストで全ティアを扱う考え方には否定的です。構成の強化は重要ですが、ネットワークティアを橋渡ししている時点で、侵害されたTier 1管理者がOSレベルの制御を得る可能性が残るためです。(TECHCOMMUNITY.MICROSOFT.COM)

推奨される考え方は次の通りです。

コンポーネント管理対象到達元到達先
Tier 0 Session HostDomain Controller、PKI、認証基盤、Entra ID制御プレーン関連Tier 0 PAWのみTier 0資産のみ
Tier 1 Session Hostアプリケーションサーバー、業務サーバー、データ基盤Tier 1管理端末または管理ゾーンTier 1資産のみ
Tier 2管理基盤ユーザー端末、ヘルプデスク作業ヘルプデスク端末または専用管理端末Tier 2資産のみ

ポイントは、「上位ティアを下位ティアの中継点から管理しない」ことです。

PAWを単なる端末配布で終わらせない

PAW(Privileged Access Workstation)は、特権作業専用の強化端末です。ただし、PAWを配布しただけでは不十分です。

次の条件がそろっていなければ、PAWの効果は限定的です。

  • Tier 0管理者はTier 0 PAWからしかPAMへログオンできない
  • Tier 0 PAWでメール閲覧やWebブラウジングをしない
  • PAWの管理者、更新基盤、EDR、証明書もTier 0基準で守る
  • 一般端末からTier 0 PAMポータルへ到達できない
  • 緊急時アカウントの利用も別途監視する

PAWは「安全な入口」です。入口の先にあるPAMが共有中継点になっていれば、全体としては安全になりません。

インシデントレスポンダーが見るべき調査ポイント

PAMが侵害経路になった疑いがある場合、incident respondersは通常の端末調査だけでなく、PAM基盤を「高価値な攻撃中継点」として扱う必要があります。

優先して確認するログと痕跡

対象確認内容
PAM監査ログ誰が、いつ、どの資産へ接続したか。通常と異なる接続元や時間帯がないか
OSイベントログローカル管理者追加、サービス作成、セキュリティログ消去、RDPログオン、PowerShell実行
ADログPAM関連アカウントのグループ変更、GPO変更、Kerberos関連イベント、パスワードリセット
EDRログCredential Guard無効化、LSASSアクセス、ドライバー追加、不審なプロセス注入
ネットワークログPAMホストからDomain Controller、PKI、管理ポートへの異常通信
バックアップ/仮想基盤ログスナップショット取得、ディスクマウント、コンソールアクセス、復元操作
PAM設定変更履歴セッション記録の無効化、承認フロー変更、権限追加、ローテーション設定変更

特に注意すべきは、「正規の管理ツールで行われた不正操作」です。攻撃者がTier 1管理者権限を得ている場合、GPO、ソフトウェア配布、EDR管理コンソール、仮想基盤の管理機能など、正規の手段でPAMホストを弱体化できます。

封じ込め時の注意点

PAMがTier 0侵害の橋になっている可能性がある場合、単純にPAMサーバーを停止すればよいとは限りません。運用に必要な特権作業が止まり、復旧を難しくする場合があります。

現実的には、次の順序で判断します。

優先順位対応目的
高PAM基盤への下位ティアからの到達を遮断する追加侵害の防止
高PAM関連サービスアカウントの権限と利用履歴を確認するマスターキー化の有無を把握
高Tier 0セッションホストを隔離し、既存セッションを確認する資格情報露出の可能性を下げる
中PAM管理者、OS管理者、仮想基盤管理者の権限を棚卸しする隠れた制御経路を特定
中Domain Controller、PKI、Entra ID同期基盤のログと変更を確認するTier 0到達後の行動を調査
低ではないが慎重にパスワードローテーション、証明書更新、キー再発行攻撃経路を理解せず実施すると再侵害の恐れがある

封じ込めでは、「PAMのパスワードを全部変える」より先に、PAMを誰が制御できるかを把握することが重要です。制御元が残ったまま資格情報だけを変更しても、攻撃者に再取得される可能性があります。

Identity security architects向けの設計原則

PAMを安全に使うには、製品選定より先にアーキテクチャ原則を決める必要があります。

原則:PAMは管理対象と同じティアで扱う

PAMコンポーネントのティアは、次のルールで決めます。

  • Tier 0を管理するならTier 0
  • Tier 1だけを管理するならTier 1
  • 複数ティアを管理するなら、最も高いティアに合わせる
  • 下位ティアから管理できるなら、上位ティア管理には使わない

この原則を明文化しないと、運用部門は「便利だから」「既存サーバーが空いているから」「監査ログを一元化したいから」という理由で共有化しがちです。

原則:設定の強化より、経路の分離を優先する

Credential Guard、アプリケーション制御、EDR、MFA、承認ワークフローは重要です。しかし、それらはティア分離の代わりにはなりません。

Microsoftの記事でも、アプリケーションレイヤーの強化はOSレイヤーの制御に敗れると説明されています。PAMホストがTier 1 OUにあり、Tier 1管理者がGPOやソフトウェア配布で制御できるなら、PAMベンダーのセッションホスト強化は無効化される可能性があります。(TECHCOMMUNITY.MICROSOFT.COM)

強化設定は「分離したうえで追加するもの」です。分離できていない環境で強化設定だけを積み上げると、見かけ上の安心感が増え、根本的な攻撃経路が放置されます。

原則:PAMの管理者を最小化する

PAM基盤には複数の管理面があります。

  • PAMアプリケーション管理者
  • PAMサーバーのOS管理者
  • データベース管理者
  • 暗号鍵・証明書管理者
  • バックアップ管理者
  • 仮想基盤管理者
  • ネットワーク管理者
  • EDR / 監視基盤管理者

これらのうち、Tier 0 PAMを制御できる役割はTier 0相当として扱います。組織図上の所属ではなく、技術的に何ができるかで判断します。

クラウドファースト環境やEntra IDでも同じ原則が必要

「うちはクラウドファーストなのでADティアリングは関係ない」と考えるのは危険です。Microsoftの記事でも、Entra ID環境ではラベルは変わっても原則は変わらず、Global Administrator、Privileged Role Administrator、Conditional Accessポリシーなどを含む制御プレーンを同じ分離規律で扱うべきだと説明されています。(TECHCOMMUNITY.MICROSOFT.COM)

クラウドやハイブリッド環境では、次のような資産がTier 0またはControl Plane相当になります。

環境Tier 0 / Control Plane相当の例
Active DirectoryDomain Controller、Enterprise Admins、Domain Admins、PKI、GPO制御
Microsoft Entra IDGlobal Administrator、Privileged Role Administrator、Conditional Access管理、認証方式管理
ハイブリッドIDMicrosoft Entra Connect、同期アカウント、フェデレーション基盤
PAM / PIMTier 0権限を付与・管理・仲介するVault、承認フロー、API、サービスアカウント

Microsoft Entra Connectについても、Microsoftのドキュメントでは重要なIDデータを含むため管理アクセスを適切に保護し、Tier 0コンポーネントとして扱うことが推奨されています。(Microsoft Learn)

ハイブリッド環境では、オンプレミスADとEntra IDのどちらか一方の侵害が、同期やフェデレーションを通じてもう一方に影響する可能性があります。PAMやPIMを導入する場合も、クラウド側の制御プレーンを管理するコンポーネントは、オンプレミスのDomain Controllerと同じくらい慎重に扱うべきです。

PAM設計レビューの実践手順

既存環境を見直す場合は、次の順序で進めると、机上の理想論ではなく実際のリスクに近づけます。

手順作業成果物
1PAMが管理する対象をすべて洗い出す対象システム、アカウント、権限一覧
2各対象をTier 0 / Tier 1 / Tier 2またはControl Plane / Management Plane / Data Planeに分類するティア分類表
3PAMコンポーネントを分解するVault、Core、Session Host、DB、API、サービスアカウント、管理端末
4各コンポーネントの管理者を洗い出すOS、AD、GPO、仮想基盤、バックアップ、EDR、DB管理者一覧
5到達経路を確認する接続元ネットワーク、VPN、PAW、管理ジャンプ経路
6下位ティアから上位ティアへ到達する橋を特定する是正対象リスト
7分離、権限削減、監視強化を優先順位付けする改善ロードマップ

最初から完璧な分離を目指すと進みません。まずは「Tier 0を扱うPAMに、Tier 1またはTier 2から到達・管理できる経路があるか」を見つけ、そこを優先して潰します。

よくある誤解と判断基準

「PAMを入れているからTieringは不要」は誤り

PAMは承認、記録、ローテーション、JITアクセスを強化します。一方、ティアリングは資格情報と管理経路の分離を担います。役割が違うため、PAMはティアリングの代替ではなく補完です。

「インターネット非公開なら安全」は不十分

攻撃者は外部から直接PAMへ入るとは限りません。フィッシングやVPN認証情報の窃取、一般端末侵害後の横展開で、内部からPAMへ到達する可能性があります。到達性は「外部公開の有無」だけでなく、「侵害済み端末から届くか」で判断します。

「強化済みセッションホストだから共有してよい」は危険

強化設定は有効ですが、管理権限の境界を超える設計を正当化するものではありません。Tier 1管理者がGPOやソフトウェア配布でそのホストを変更できるなら、Tier 0セッションを扱わせるべきではありません。

「PAM管理者は少人数だから問題ない」は不十分

人数だけではなく、その人たちがどの端末からログオンし、どの認証方式を使い、どのネットワークから到達でき、どの緊急手順で例外操作できるかを見る必要があります。少人数でも、一般端末から操作できるならリスクは高いままです。

まず着手すべき改善アクション

最後に、すぐ行動に移すための優先順位を整理します。

優先度アクション目的
最優先Tier 0を扱うPAMコンポーネントを特定する何を守るべきか明確にする
最優先Tier 1 / Tier 2からPAM Core、Vault、Tier 0 Session Hostへ到達できる経路を遮断する攻撃の橋を断つ
高Tier 0用とTier 1用のSession Hostを分離する共有中継点をなくす
高PAMサービスアカウントの権限を見直し、用途別に分離するマスターキー化を防ぐ
高Tier 0管理をPAWに限定する管理者資格情報の露出を減らす
中PAM基盤のOS、DB、仮想基盤、バックアップ管理者を棚卸しする隠れた制御経路を見つける
中PAM設定変更、EDR無効化、GPO変更、異常セッションを監視する侵害準備を早期検知する
中インシデント対応手順にPAM侵害時の封じ込めを追加する有事に迷わないようにする

PAMは、正しく設計すれば特権アクセス管理の強力な防御層になります。しかし、Tier 0を扱うPAMをTier 1資産として扱うと、攻撃者にとって最も信頼された近道になります。

次に取るべき行動は、PAM製品の機能比較ではありません。まず、自社のPAMが「どのティアを管理し、誰がPAM自体を管理でき、どの端末から到達できるか」を1枚の図にしてください。その図の中に、下位ティアから上位ティアへ伸びる線があれば、それが最初に閉じるべき攻撃の橋です。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次