はじめに
第8回は、Windowsセキュリティ設計における最重要コンセプトの一つ、「特権の階層化（Tierモデル）」 を解説します。
Linuxエンジニアは、必要な時だけ sudo でroot権限を得る「時間軸の分離」には慣れていますが、Windows AD環境では 「ログインする場所の分離（空間軸の分離）」 が死活的に重要になります。なぜ「ドメイン管理者（Domain Admin）が一般ユーザーのPCにログインしてはいけない」のか、その真意に迫ります。
1. 特権の「汚染」を防ぐという考え方
Linuxでは、一般ユーザーのPCがマルウェアに感染しても、管理者がリモートでSSH（公開鍵認証）を使ってメンテナンスする分には、管理者の秘密鍵がそのPCに漏れることはまずありません。認証に使う秘密情報がクライアント側のメモリに残らないからです。
しかし、第5回・第6回で学んだ通り、Windowsの認証（NTLM/Kerberos）は、ログインした瞬間にパスワードハッシュやチケットがメモリ（LSASS）に保持される仕組みです。
リスク： 感染した一般PC（Tier 2）にドメイン管理者（Tier 0）がログインすると、攻撃者は Mimikatz 等のツールでメモリから管理者の認証情報を盗み出せます。その結果、ドメイン全体が乗っ取られます。これが 「側方移動（Lateral Movement）」 の典型的な手口であり、多くの実被害が報告されています。
Linuxとの本質的な違い
ssh -i ~/.ssh/id_rsa admin@server は、秘密鍵をサーバー側に送らない（送るのは公開鍵で署名したチャレンジレスポンスのみ）。一方、Windows のインタラクティブログオンは、認証情報の派生物をログオン先のメモリに置く。この違いが、「触れる場所を制限する」という発想の出発点です。
2. Tierモデルの三階層構造
Microsoftが提唱したTierモデル（現在はエンタープライズアクセスモデルとして進化していますが、階層分離の基本思想は同一です）では、資産とアカウントを以下の3つに厳格に分離します。
| 階層 | 対象となる資産 | 管理アカウントの例 |
|---|---|---|
| Tier 0 | ドメインコントローラー（DC）、AD DS、Azure AD、PKI基盤 |
DA_admin（ドメイン管理者専用アカウント） |
| Tier 1 | アプリケーションサーバー、DBサーバー、クラウド管理基盤 |
SRV_admin（サーバー管理専用アカウント） |
| Tier 2 | 一般ユーザーのPC、ノートパソコン |
HD_admin（ヘルプデスク専用アカウント） |
重要： 各Tierの管理者は「専用アカウント」を使います。ドメイン管理者が普段使いのアカウントで業務メールを読み、同じアカウントでDCにログインする、というのは厳禁です。
鉄の掟：上位アカウントは下位資産に触れない
- Tier 0 の管理アカウントは、Tier 1 や Tier 2 のマシンにログインしてはならない。
- Tier 1 の管理アカウントは、Tier 2 のマシンにログインしてはならない。
- 逆に、下位のアカウントが上位の資産を管理する権限を持ってはならない。
【汚染が伝播する例】
Tier 2 PC（感染済み）
↑ DA_admin がログイン（RDP or 物理）
→ LSASS に DA_admin の NTLM ハッシュが残る
→ 攻撃者が Pass-the-Hash でドメイン全体を掌握 ← Tier 0 陥落
3. どうやって「分離」を強制するか？
「気をつけましょう」という努力目標では不十分です。Windowsでは グループポリシー（GPO） を使って、物理的にログインを遮断します。
具体的な設定項目
Linuxの /etc/ssh/sshd_config における AllowUsers や DenyUsers の制限に近い感覚で、以下の「ユーザー権利の割り当て」を設定します。
| ポリシー名 | 目的 |
|---|---|
| ローカルログオンを拒否 | Tier 0 アカウントが一般PC（Tier 2）で物理的にログオンするのを防ぐ |
| ネットワーク経由でのこのコンピュータへのアクセスを拒否 | Tier 0 アカウントが一般PCの共有フォルダ等にアクセスするのを防ぐ |
| リモートデスクトップサービスを使ったログオンを拒否 | RDP経由の横方向移動（Lateral Movement）を遮断する |
GPO設定パス
[コンピューターの構成]
└─ [ポリシー]
└─ [Windowsの設定]
└─ [セキュリティの設定]
└─ [ローカルポリシー]
└─ [ユーザー権利の割り当て]
├─ [ローカルログオンを拒否] ← "Tier 0 Admins" グループを追加
└─ [リモートデスクトップサービスを
使ったログオンを拒否] ← "Tier 0 Admins" グループを追加
これにより、万が一一般PCが乗っ取られても、攻撃者はドメイン管理者をRDPで誘い込んでハッシュを盗むことができなくなります。
ADグループ設計のコツ
Domain Admins を直接ポリシーに追加するのではなく、専用の Tier0_Admins セキュリティグループを作成してポリシーに登録します。こうすることで、メンバー管理がグループの追加・削除だけで完結し、ポリシー自体を変更する必要がなくなります。
4. PAW（Privileged Access Workstation）の導入
Tier 0（ドメインコントローラー等）を管理するための端末は、専用の 「管理用端末（PAW: Privileged Access Workstation）」 でなければなりません。
Linuxエンジニアとの対比
| 概念 | Linux | Windows |
|---|---|---|
| 管理専用端末 | 踏み台サーバー（Bastion Host） | PAW |
| 一般業務との分離 | SSHポートのみ公開 | 物理・仮想の完全分離 |
| インターネットアクセス | 原則禁止 | 禁止（GPOで強制） |
PAWの必須要件
- インターネット閲覧：不可（Webフィルタリング or GPOで制限）
- メール使用：不可（フィッシング対策）
- 一般業務：不可（Officeでの文書作成等も禁止）
- Tier 0 専用のセグメント に配置（ファイアウォールでTier 2ネットワークからのアクセスをブロック）
- 物理端末または専用VM（Tier 2 のVMと同一ハイパーバイザーを共有しない）
「PAWは面倒だから仮想デスクトップで」の罠
一般業務用PCの上でHyper-VやVMwareを動かし、その中のVMをPAWとして使う構成は避けてください。ホストOS（Tier 2）が侵害されれば、ゲストVM（PAW）のメモリも読み取られる危険があります。
5. 実践まとめ：Tierモデル導入のステップ
- アカウント棚卸し — 現在の特権アカウントをリストアップし、Tier分類する
-
専用管理アカウントの作成 —
tier0_admin_[名前]、tier1_admin_[名前]のように命名規則を定める - GPOでログイン制限を強制 — 各TierのOU（組織単位）にリンクしたGPOで上記ポリシーを設定
- PAWの調達・構築 — Tier 0 管理用の専用端末を用意する
- 監査ログの有効化 — ログオン失敗イベント（イベントID: 4625）を監視し、Tier境界違反を検知する
おわりに
特権管理の要諦は「権限を最小化する（最小権限の原則）」ことだけでなく、「権限を使う場所を限定する（アクセスの空間的分離）」 ことにあります。ドメイン管理者は「全能」ですが、その力を振るって良いのは「聖域（Tier 0）」の中だけなのです。
今回の「エンジニアの知恵」
「プリンターが動かない」と言われたドメイン管理者が、親切心でユーザーのデスクまで行って自分の特権アカウントでログインして直してあげる——これは、Windowsセキュリティにおいては 「もっとも親切なセキュリティ事故」 と呼ばれます。
正しい対応は、Tier 2 専用のヘルプデスクアカウント（HD_admin）を持つ担当者がサポートに向かうか、リモートサポートツール（SCCM/Intuneのリモートコントロール等）を使うことです。ドメイン管理者は「その場所まで行かない」のが原則です。