AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務

「ADの管理、Domain Adminsでやってます」——現場でこれを聞いたとき、何が問題なのか説明できますか？

Domain Adminsは「ドメイン全体を支配できる鍵」です。このアカウントで日常業務をこなしている状態は、マスターキーを首から下げたまま街を歩いているのと同じことです。盗まれた瞬間、すべてが終わります。

ADの特権アカウント管理は「誰が使えるか」ではなく、「どう設計するか」で安全水準が決まります。この記事では、Tierモデル・PAW・JITという3つの考え方をもとに、特権アカウントの実務設計パターンを解説します。

ADの全体像については「Active Directoryとは？Windows認証基盤の仕組みと設計の基本」を先にご覧ください。管理者OUの分離設計については「ADのドメインとOU設計｜組織構造をActive Directoryに落とし込む実務ガイド」も合わせて参照してください。

Domain Adminsを日常的に使うと何が起きるか
特権アカウントの設計に必要な3つの考え方
Tier 0アカウントの設計——ドメイン管理者をどう守るか
1. Tier 0アカウントの命名・配置・ログオン制限
2. 緊急アクセスアカウント（Break Glass）——忘れがちな設計
PAW——特権操作を専用端末に閉じ込める
1. なぜ一般PCからの管理操作が危険なのか
2. PAWに設定すべき制限の実務パターン
JITアクセス——常時特権をやめる運用設計
1. オンプレでJITを実現する2つの方法
よくある失敗パターン
特権アカウント設計チェックリスト
まとめ——特権設計は「絞る・隔離する・記録する」の3原則

Domain Adminsを日常的に使うと何が起きるか

Domain Adminsアカウントでメールを読み、Webを閲覧し、ファイルを操作する——この運用が危険な理由は2つあります。

1つ目は侵害時の被害が最大化することです。そのPCにマルウェアが侵入した瞬間、攻撃者はドメイン管理者権限を手に入れます。パスワードリセット・全ユーザーの資格情報奪取・DCへのアクセスまで、すべてが攻撃者の手中に入ります。

2つ目は資格情報が端末に残り続けることです。Windowsは認証済みの資格情報をメモリ上にキャッシュします。Domain Adminsで一度でもログインした端末には、そのハッシュ値が残ります。Pass-the-Hash攻撃はこの仕組みを悪用します。

Pass-the-Hash（PtH） パスワードの平文を知らなくても、盗んだハッシュ値を使ってネットワーク認証を突破する攻撃手法。資格情報がキャッシュされた端末が侵害されると連鎖的に拡大する。

「動く」設計と「守れる」設計の違いはここにあります。Domain Adminsが存在するだけでは問題ありません。それを「いつ・どこで・誰が使えるか」を設計できているかどうかが、セキュリティの分かれ目です。

最小権限の考え方の基礎については「最小権限の原則とは？実務での考え方と設計例」で解説しています。

特権アカウントの設計に必要な3つの考え方

特権アカウントを安全に管理するには、Tierモデル・PAW・JITという3つの考え方を組み合わせます。それぞれ「誰が使えるか（アカウント）」「どこから使うか（端末）」「いつ使えるか（時間）」という異なる軸をカバーする多層防御として機能します。

Tierモデル——特権を3層に分けて管理する

Tierモデル（Tier Model） ADの管理対象を重要度に応じてTier 0・1・2に分け、各Tierに専用の管理アカウントを割り当てる設計思想。異なるTier間での認証情報の流用を防ぐことが目的。Microsoftが推奨するAD保護モデル。

Tier	管理対象	代表的なアカウント
Tier 0	ドメインコントローラー・ADそのもの	Domain Admins、Enterprise Admins
Tier 1	メンバーサーバー・業務アプリ	サーバー管理者アカウント
Tier 2	クライアントPC・ヘルプデスク業務	PC管理者、ヘルプデスクアカウント

設計の核心は「上位TierのアカウントをTierをまたいで使ってはいけない」という原則です。Tier 0のDomain Adminsで一般PCにログインすれば、その端末が侵害されたとき資格情報が流出します。逆にTier 2のヘルプデスクアカウントがDCに触れる状態も同様に危険です。

参考：エンタープライズアクセスモデル | Microsoft Learn

PAW——特権操作は専用端末から行う

PAW（Privileged Access Workstation：特権アクセスワークステーション） 特権操作専用に構成・管理されたPC。インターネット閲覧・メール受信などの操作を制限し、特権アカウントの資格情報が一般端末に流出しないよう隔離する。

Tierモデルでアカウントを分けても、操作する端末が一般PCのままでは意味がありません。PAWの詳細は後のセクションで解説します。

JIT——使うときだけ権限を与える

JIT（Just-In-Time Access） 必要なときだけ・必要な時間だけ特権を付与し、作業完了後に自動で権限を剥奪する仕組み。常時特権を保持しないことで、資格情報が漏洩しても悪用できる時間窓を最小化する。

PAWで端末を隔離しても、管理者アカウントがDomain Adminsに常時所属していれば「資格情報が漏洩したとき、攻撃者はいつでも最高権限で動ける」というリスクが残ります。JITの詳細は後のセクションで解説します。

Tier 0アカウントの設計——ドメイン管理者をどう守るか

Tier 0アカウントの命名・配置・ログオン制限

Tier 0アカウントには3点を必ず設計に組み込みます。まずその前提として、特権アカウントは用途ごとに3種類を別々に作成します。1人の管理者が3つのアカウントを使い分けることになります。

一般ユーザーアカウント（例：t.tanaka） メール・Web閲覧・日常業務に使うアカウント。管理権限は一切持たせない。

管理者アカウント（例：adm_t.tanaka） ADやサーバの管理操作専用アカウント。管理作業のときだけ使い、作業が終わったらログオフする。

緊急アクセスアカウント（例：break-glass-01） Entra IDやMFAシステムが使えなくなった際の最終手段。通常はロックされており、使用時は必ずアラートが飛ぶ設定にする。

この3種類をOU設計上も明確に分離することが重要です。管理者OUに OU=Admin を設ける設計は「ADのドメインとOU設計」で解説した通りです。

その上で、Tier 0アカウントには以下の3点を必ず設計に組み込みます。

命名規則 adm_t.tanaka のように adm_ プレフィックスを付け、管理者操作のログを見たときに一目でわかる状態にします。命名規則の詳細は「ADのユーザーとグループ管理」でも解説しています。

配置OU OU=Admin 配下に集約します。一般ユーザーOUと混在させると、GPO適用・棚卸し・監査の3つすべてが困難になります。

ログオン先の制限（GPOで設定） GPOの「ユーザー権利の割り当て」で、Tier 0アカウントがログオンできる端末をDCとPAWのみに絞ります。

# GPO設定パス（参考）
コンピューターの構成
└── Windowsの設定
    └── セキュリティの設定
        └── ローカルポリシー
            └── ユーザー権利の割り当て
                ├── ローカルログオンを許可　← Tier 0管理者のみに絞る
                └── ネットワーク経由のアクセスを拒否　← 一般端末からのアクセスを遮断

GPO設計の基礎については「グループポリシー（GPO）設計入門｜セキュリティ設定を一括管理する方法」を参照してください。

緊急アクセスアカウント（Break Glass）——忘れがちな設計

Break Glassアカウント 通常の認証・承認フローが使えなくなった緊急時のみ使用する特権アカウント。「非常口の鍵」にあたる存在で、封印した状態で保管し、使用時は即座にアラートが発報される設計にする。

設計時に見落とされやすいのがBreak Glassアカウントです。「MFAシステムが障害を起こした」「AD管理者が全員連絡不通になった」といった非常時に、ドメインに入れる最後の手段として機能します。

実務での設計ポイントは3つです。

MFAをあえて除外する（MFAシステム自体が障害対象になるため）
アカウント名を推測されにくい名前にする（break-glass-01 など）
使用されたことを検知するアラートをイベントログと連携して設定する

参考：緊急アクセス管理アカウント | Microsoft Learn

PAW——特権操作を専用端末に閉じ込める

なぜ一般PCからの管理操作が危険なのか

一般業務PCでは毎日、メール・Webブラウジング・ファイルのダウンロードが行われます。これらはすべてマルウェア感染の経路です。そのPCで管理者アカウントを使うと、感染したマルウェアが資格情報をキャプチャしてドメイン全体への侵入口を開きます。

PAWに設定すべき制限の実務パターン

設定項目	内容
インターネットアクセス	管理用URL以外はファイアウォール・プロキシでブロック
メールクライアント	インストール禁止（GPOで制御）
USBポート	無効化、または許可リスト制限
ログオン可能ユーザー	Tier 0管理者アカウントのみ
Windows Update	最優先・自動適用
スクリーンセーバー	5分でロック（一般PCより短め）

物理PAWを用意できない場合は、Hyper-VのVMを分離する暫定構成も選択肢に入ります。ただしホストOSが侵害されるとVMも影響を受けます。完璧を待つより段階的に始めることが重要で、まずはログオン制限GPO＋VM分離から着手するのが現実的な進め方です。

参考：特権アクセスワークステーション | Microsoft Learn

JITアクセス——常時特権をやめる運用設計

Tierモデル・PAWを整えた上で、管理者アカウントがDomain Adminsに常時所属している状態を解消するのがJITです。JITの考え方はAzure AD PIMと同じです。PIMの詳細は「PIMとは？Azure特権アクセス管理の実務ガイド」で解説しています。

オンプレでJITを実現する2つの方法

方法①：グループへの一時追加（手動SLA運用）

作業時のみDomain Adminsグループに追加し、完了後に除外します。シンプルですが「除外忘れ」が最大のリスクです。「追加後24時間以内に必ず除外する」「追加・除外をチケット管理する」などのSLAを設定することが最低条件になります。

SLA（Service Level Agreement） サービス提供における品質・手順の合意文書。ここでは「操作後○時間以内に権限を除外する」という内部ルールを指す。

powershell

# グループ追加（作業前）
Add-ADGroupMember -Identity "Domain Admins" -Members "adm_t.tanaka"

# グループ除外（作業後・必須）
Remove-ADGroupMember -Identity "Domain Admins" -Members "adm_t.tanaka"

ADのイベントログでグループの追加・除外を記録・監視することも合わせて設定します。ログ設計については「ADイベントログ監査」で解説します。

方法②：Entra ID PIM経由のハイブリッド運用

Entra ID（旧Azure AD）と連携した環境では、PIMを使った申請→承認→一定時間後に自動失効というワークフローがシステムで担保されます。手動SLAに依存しないため、運用ミスのリスクが大幅に下がります。

オンプレADとEntra IDの連携設計については「Entra IDとオンプレAD連携」で詳しく解説します。

参考：Microsoft Entra PIM の概要 | Microsoft Learn

よくある失敗パターン

① Domain Adminsのメンバーが増え続けている

「作業があるたびに追加して、そのまま放置」を繰り返した結果、Domain Adminsに10人以上が常時所属している状態になります。棚卸しの機会がなく、退職者や異動者のアカウントも混在します。Domain Adminsの直接メンバーは原則5名以下に絞り、定期的なレビューをスケジュール化してください。

② 管理者アカウントと一般アカウントを同じPCで使っている

「切り替えが面倒」という理由で、同じPCで t.tanaka（一般）と adm_t.tanaka（管理者）を使い分けているケースです。PAWの分離を行わない限り、アカウントを分けた意味がほぼなくなります。ログオン先制限（GPO）をかけるだけでも一定の抑止効果があります。

③ Built-in Administratorが有効なまま放置されている