副題：経路を見つけて、制御点で断つ
想定読者：CISO、IAM/PAM担当、SOC、Active Directory管理者
第2回で認証の入口を固めました。しかし、それでも侵害は起こります。委託先の端末から、パッチの当たっていない社内サーバから、あるいは回復経路の隙から。
そのとき問題になるのは、入られた場所から特権までの距離です。一般利用者のアカウント1つが奪われたときに、そこから数ステップでドメイン管理者に到達できるのか、それとも複数の制御点に阻まれるのか。この差が被害の規模を決めます。
1. Attack Pathは設定ミスではなく、運用の堆積物である
Attack Pathとは、あるアカウントから別のアカウント・システムへ到達できる権限の連鎖のことです。Active DirectoryやEntra IDの権限関係を有向グラフとして表現すると、経路として可視化できます。
重要なのは、こうした経路の大半が正規の設定の結果だという点です。
- ヘルプデスクにパスワードリセット権限を委任した
- プロジェクトのために一時的に権限を付与し、終了後も残っている
- 運用を簡単にするため、サービスアカウントに広い権限を与えた
- 特権アカウントで一般端末にログオンし、資格情報が端末上に残った
一つひとつは合理的な判断でした。しかし10年分が積み重なると、誰も全体像を把握していない権限のネットワークができあがります。設定ミスを探しても見つかりません。正しい設定の組み合わせが、意図しない経路を作っているからです。
2. 経路を洗い出す6つの観点
専用ツールがなくても、次の観点で棚卸しすれば主要な経路は見えてきます。
観点 | 何を見るか | 典型的に見つかるもの |
|---|---|---|
特権グループの実効メンバー | 入れ子のグループを展開した最終的な人数 | 「Domain Adminsは3人」のはずが、入れ子を展開すると数十人 |
権限の委任とACL | OU単位の委任、オブジェクトのACL（パスワードリセット、グループ書き込み） | ヘルプデスクから特権アカウントのパスワードを変更できる |
サービスアカウント | 権限の範囲、パスワードの更新頻度、対話ログオンの可否 | 管理者権限を持ち、パスワードが数年変わっていないアカウント |
資格情報の残存 | 特権アカウントがどの端末・サーバにログオンしているか | 一般端末に残った特権の資格情報（T1550.002／T1550.003の起点） |
ハイブリッド連携 | オンプレADとEntra IDの同期アカウント、同期サーバの権限 | オンプレ側の侵害がクラウド側の管理権限に波及する経路 |
クラウド側のロールとアプリ権限 | ディレクトリロールの保有者、アプリケーションに付与された権限 | 強い権限を持つアプリの資格情報（ユーザー認証を経ずに使える） |
最後の2つは見落とされがちです。オンプレミスの特権管理を厳格にしていても、ハイブリッド連携の経路が開いていれば、そこを迂回されます。オンプレとクラウドを別々に評価しないことが重要です。
3. ITDRは何を検知するのか
ITDR（Identity Threat Detection and Response）は、EDRがエンドポイントを見るのと同じように、ID基盤そのものを対象にした検知・対応の考え方です。第1回で挙げた「認証の文脈」の監視に加えて、ID基盤の構成変化を見ます。
検知すべき代表的な事象
- 特権グループへのメンバー追加：特に業務時間外、または普段その操作をしない者による実行
- 権限委任・ACLの変更：特権オブジェクトに対する書き込み権限の付与
- MFA認証器の登録・変更：第1回で触れた永続化の典型
- 同期設定・フェデレーション設定の変更：信頼関係そのものへの介入
- サービスアカウントの異常な利用：普段接続しないシステムへの接続、対話ログオン
- 資格情報の窃取を示す挙動：ドメインコントローラへの異常なレプリケーション要求など
これらに共通するのは、攻撃者が権限を維持・拡大するために必ず通る操作だという点です。初期侵入の検知は難しくても、ここは検知の余地があります。
4. 制御点で断つ
経路が見えたら、次はどこで断つかです。すべての経路を消すことはできないので、通らざるを得ない場所に制御点を置くという考え方をとります。
制御点 | 断つもの | 実装の例 |
|---|---|---|
特権の常時保有をなくす | 奪われたときに即座に使える権限 | 必要なときだけ昇格させる（Just-In-Time）、承認と時間制限、作業目的の記録 |
特権作業の経路を限定する | 一般端末経由での特権利用 | 専用の管理端末・踏み台からのみ特権操作を許可し、一般端末からの特権ログオンを禁止 |
階層を分離する | 下位層から上位層への資格情報の流出 | Tier 0（ID基盤）／Tier 1（業務サーバ）／Tier 2（クライアント）を定義し、上位の資格情報を下位で使わせない |
認証の強度で分ける | パスワードのみで通る特権操作 | 特権操作にデバイス束縛型のフィッシング耐性認証を要求（第2回の使い分け） |
サービスアカウントを管理下に置く | 更新されない資格情報 | パスワードの自動管理、対話ログオンの禁止、接続元の制限 |
アプリ権限を絞る | ユーザー認証を経ない経路 | アプリへの権限付与を承認制にし、強い権限を持つアプリを定期的に棚卸し |
このうち階層の分離が最も効果が大きく、最も手間がかかります。既存環境への適用は段階的にならざるを得ないため、Tier 0（ドメインコントローラ、ID同期サーバ、PKI、特権管理基盤）の保護から着手するのが現実的です。
5. 運用に乗せる
一度きりの棚卸しで終わらせないために、指標と周期を決めます。
- 実効的な特権保有者数：入れ子を展開した実数。四半期ごとに測定し、増加を説明できるようにする
- 常時特権を保有するアカウント数：Just-In-Timeへの移行が進んでいるかを見る
- Tier 0資産への非準拠アクセス件数：専用端末以外からの特権操作
- 特権到達までの最短ステップ数：主要な一般アカウントから特権までの距離。改善が数値で見える
- 棚卸しから是正までの平均日数：見つけた経路を実際に閉じているか
そして年1回、ID侵害を前提とした演習を行います。「一般利用者のアカウントが1つ侵害された」という前提から、どこまで到達できるか、どこで検知できるかを机上または実機で確認します。Series 07で扱うPurple Teamの考え方と同じで、防御の有効性は測定して初めて分かります。
設計チェックリスト（10項目）
- 特権グループの実効メンバーを入れ子込みで把握しているか
- 権限委任とACLを棚卸しし、特権への書き込み経路を特定したか
- サービスアカウントの権限・更新頻度・対話ログオン可否を把握しているか
- 特権の資格情報が一般端末に残らない運用になっているか
- オンプレADとクラウドIDを1つの経路として評価したか
- 強い権限を持つアプリケーションを棚卸ししたか
- 特権グループ変更・委任変更・MFA登録をリアルタイムに検知できるか
- 常時特権をなくし、時間制限付きの昇格に移行しているか
- Tier 0資産への操作を専用端末に限定しているか
- 特権到達までの最短ステップ数を定期的に測定しているか
シリーズのまとめ
3回を通じて扱ってきたのは、IDが境界になった環境での防御の組み立て方です。
第1回で、攻撃が正規の仕組みをそのまま使うこと。第2回で、認証の結果を横取りされない方式があること。第3回で、それでも入られたときに特権までの距離を長くしておくこと。
この3つは順番に効きます。認証を固めずに経路だけ整理しても入口は開いたままですし、認証だけ固めても侵入後の被害は変わりません。入口と経路の両方を、同じ計画の中で設計することが、ID起点の攻撃に対する現実的な答えだと考えています。
主要出典
- MITRE ATT&CK「T1078 Valid Accounts」
- MITRE ATT&CK「T1550 Use Alternate Authentication Material」（T1550.002 Pass the Hash／T1550.003 Pass the Ticket）
- NIST SP 800-63B-4「Digital Identity Guidelines: Authentication and Authenticator Management」（2025年8月26日）
- 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（2024年10月、2025年7月一部改正）
- NIST「Cybersecurity Framework (CSF) 2.0」（2024年2月）
本記事は公開情報に基づく一般的な解説です。製品固有の実装に依存しない形で記載しています。