---
title: Active Directory 権限設計ポイント
tags: 
author: [Fumiya Okazaki](https://www.docswell.com/user/FumiyaOkazaki)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LELMVDW97R.jpg?width=480
description: Active Directory 権限設計ポイントです。
published: September 07, 26
canonical: https://www.docswell.com/s/FumiyaOkazaki/KQ24DJ-2026-09-07-022824
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LELMVDW97R.jpg)

ADセキュリティ＆権限設計ナレッジ
Active Directory 権限設計ガイド
特権管理・OU構造とランサムウェア対抗策
20年変わらない設計原則とアクセス委任による堅牢なガバナンス構築
岡崎 文哉
LOG Sprout合同会社


# Page. 2

![Page Image](https://bcdn.docswell.com/page/4JMYGP9VJW.jpg)

LOG Sprout合同会社のご紹介
Mission
「想いを形に、未来を紡ぐ。」
人の多様な経験からなる小さな気づきを記録（LOG）し、積み上
げ、芽開く（Sprout）。
インフラ・ID基盤の設計から運用定着まで、組織のセキュリティ
と自走化を伴走支援します。
© LOG Sprout G.K. All rights reserved.
会社概要
商号: LOG Sprout合同会社
ミッション: チーム伴走型ITイノベーションの推進
事業内容:
Active Directory / IdP 統合・セキュリティ基盤構築支援
Jira / Confluence活用定着・業務改善伴走コンサルティング
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PJR9Z1GW79.jpg)

ADを取り巻く最新環境と20年変わらない設計原則
Windows Server 2025でも変わらない本質
リソースキットの教えが参考になる理由
しかし、アクセス制御、OU構造、権限委任の「設計思想」そのも
のは、20年以上前から基本的に変わっていません。
ビルトイン特権グループ（Domain Admins等）の日常使用の回避
GPO適用と管理境界（Delegation）に合致させたOU設計
AGDLPモデルに基づく階層型グループ運用
最新のWindows Server 2025では、内部処理の高速化や古い暗号
化方式の廃止などセキュリティ強化が進んでいます。
Windows Server 2008等の時代に確立された「Resource Kit」のベ
ストプラクティスは現代も有効です。
📌 本資料の適用前提: 本設計原則は、比較的シンプルな「シングルフォレスト・シングルドメイン」を基本的なベースとして記述しています。
© LOG Sprout G.K. All rights reserved.
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/PEXQ9YXVJX.jpg)

ランサムウェア時代における「特権奪取」の脅威
オンプレミスActive Directoryの特権が奪取されると、全社インフラが一瞬で全滅する危機に直面します。
端末のウイルス感染
（フィッシング・端末脆弱性）
➔
横移動（ラテラルムーブ）
ADの特権（Domain Admins）奪取
➔
全社へ一斉展開
ドメイン全端末の暗号化被害
⚠️ 脆弱な権限設計が壊滅的被害を引き起こす
日常のPCサポートやサービスアカウントに「Domain Admins」などの強力な特権を安易に付与していると、攻撃者に認証キャッシュ（LSASS）を盗み取
られた瞬間に、全社ADのコントロールを掌握されます。
💡 防御の第一歩：検知ツール導入前に「20年前からの基本プラクティス」を徹底する
Microsoft Defender for Identity等の高度な検知ソリューション導入も有効です。しかし高額ツールに頼る前に、まずは20年前から不変の基本プラクティス（特権常
用廃止・適切な権限委任）で防げる土台を整えることが、防御の強固な第一歩となります。
© LOG Sprout G.K. All rights reserved.
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/3EK9P3W5ED.jpg)

ビルトイン特権グループの脱却と「最小権限」原則
危険な「特権グループ」の常用
`Domain Admins` / `Enterprise Admins`:
ドメイン全体の最高権限。日常作業やシステム連携での利用は厳
禁。
`Account Operators`:
一見制限されているように見えて、自ら権限昇格を行える穴が存在
するため非推奨。
`Server Operators` / `Backup Operators`:
DCへの不正ログインや改ざんが可能なため、実質的に最高特権と同
等。
© LOG Sprout G.K. All rights reserved.
【対策】管理操作の「権限委任」へシフト
強大なビルトイングループに頼るのをやめ、必要な操作だけに限定
した権限を切り出します。
パスワードリセット専用アカウント/グループの作成
特定OU配下の端末ドメイン参加権限のみを付与
作業完了後に自動で失効する一時特権（JIT管理）
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/L73WXG1175.jpg)

GPO適用と管理境界を考慮した「OU（組織単位）構造設計」
⚠️ やりがちな「NGなOU設計」
会社の「組織図（営業部・人事部など）」をそのままOU階層として作成してし
まう設計。
補記（一概に組織図分割が不可なわけではない）:
「1. 管理境界（Delegation）」に照らした際、人事システム連携でユーザー作成が自動
化され、端末も情シスが一律管理している場合、細かい部署OU分割は組織変更時の移
動コストを生み、デメリットがメリットを大幅に上回ります。
💡 組織階層を表現・管理したい場合のベストプラクティス:
OU階層で表現するのではなく、配布グループやセキュリティグループの階層構造、あ
るいはExchangeの「階層型アドレス帳（HAB）」を活用するのが適しています。権限
構造やGPO継承を汚さずに柔軟な組織ツリー表現が可能です。
【推奨】3つの軸に基づく「美しいOU構造」
1. 管理境界（Delegation）:
「誰がどのオブジェクトを管理するか」の委任単位で分ける
2. セキュリティポリシー（GPO）:
「どのセキュリティ設定を適用するか」の単位（例: 役員PC / 一般PC / サー
バー）
3. オブジェクト種別:
`Users`, `Workstations`, `Servers` を最上位で明確分離
🌐 上位階層（フォレスト/ドメイン/サイト）で管理委任が定義されている場合:
意図を持って上位のフォレスト・ドメイン分割や物理配置に基づくサイト設計で管理委任が行われている環境では、OU単位での分割粒度についてもその管理境界に合わせて見
直す設計余地が存在します。
© LOG Sprout G.K. All rights reserved.
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/87DK21XKJG.jpg)

サードパーティツール連携の罠 と「権限委任」の本質
⚠️ 外部ツール手順書に潜む2大過剰権限リスク
💡 ADの「権限委任（Delegation）」解体新書
「Domain Admins 付与」の要求:
ベンダーが設定の簡略化のため、ツール用アカウントにドメイン最高権限を
要求するケース。
OUルートへの「フルコントロール」付与:
委任設定自体は行っているものの、対象を絞らずドメインやOUのルート（最
上位）に対して広大なフルコントロール権限を安易に設定してしまうケー
ス。
【権限委任を成功させる3要素】
1. 範囲（Where）: 特定のOU以下に厳格限定（ドメイン/OUルートへの広
大権限付与を絶対回避）
2. 主体（Who）: 権限を受ける専用セキュリティグループ（★個人アカウン
ト直指定不可）
3. 操作（What）: 許可する具体的アクション（例: 属性の読み書き・パス
ワードリセットのみ）
サードパーティ製品導入時、マニュアルの指示通りに設定した結果、過剰
なアクセス権が設定される例が多発しています。
© LOG Sprout G.K. All rights reserved.
権限委任とは、Domain Adminsやルート権限に頼らず「特定のOU以下に
対象範囲を絞って」、特定の操作権限だけを安全に切り出す仕組みです。
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/VJPK1QP3E8.jpg)

「アクセス権の委任」ユースケース と 運用の「適切な塩梅」
1. サードパーティ連携
【実務ユースケース】最小権限の原則（Least Privilege）に基づいたACL付与パターン
範囲: `OU=Users`（限定）
主体: `g-svc-idm-sync`
`department` 属性の読み書き
`telephoneNumber` の更新
パスワード変更・全削除は遮断
2. ヘルプデスク運用
範囲: `OU=Users`（限定）
主体: `g-delegation-helpdesk`
ユーザーのパスワードリセット
次回ログイン時の変更強制
アカウントのロック解除のみ許可
3. PCキッティング
範囲: `OU=Workstations`
主体: `g-svc-kitting`
コンピュータオブジェクト作成
端末のドメイン参加/離脱権限
ユーザーOUへのアクセス権なし
⚖️ 最小権限の原則（Least Privilege）における「運用の塩梅」と多層防御の総合検討
最小権限を追求しすぎて属性単位や操作ごとにACEを過度に細分化すると、ACLの可視性が失われ運用の形骸化を招きます。「どの粒度まで権限を絞り込み、どこで共通化する
か」の塩梅は企業の管理実態に応じた判断が必要です。
🛡️ 権限の細分化だけに頼らず、以下のセキュリティ対策とトータルで組み合わせた設計が極めて効果的です：
監査ログの取得・監視: 委任グループやサービスアカウントの不審な操作・変更をリアルタイム検知
ログオンホストの制限（Logon Workstations）: 管理者・サービスアカウントの利用端末を限定し横移動を遮断
多要素認証（MFA）等による認証強度の向上: 管理作業や特権操作における認証ハードルの多層化
© LOG Sprout G.K. All rights reserved.
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/2EVVY52NEQ.jpg)

セキュリティグループ設計原則（AGDLPモデル）
アクセス権管理の黄金律「AGDLP」
グループの入れ子構造とスコープ（グローバル / ドメインローカル）を
正しく使い分ける設計手法です。
グループが乱立・複雑化するのを防ぎ、マルチドメイン拡張や監査にも
耐えうる保守性を実現します。
© LOG Sprout G.K. All rights reserved.
AGDLPの構成要素
A (Account):
個人のユーザーアカウント
G (Global Group):
「役割・属性」を表すグループ（例: `g-sales-dept`）
DL (Domain Local Group):
「リソースのアクセス権」を表すグループ（例: `dl-folder-sales-read`）
P (Permissions):
ファイル共有やOUのアクセス許可設定（ACL）
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/57GL96R5EL.jpg)

横移動（ラテラルムーブメント）を防ぐ「Tier管理モデル」
Tier 0（最高機密）
アイデンティティ制御基盤
ドメインコントローラー、PKI、IdP
`Domain Admins` 専用端末のみ許可
下位Tierへのログインは完全遮断
Tier 1（サーバー層）
社内サーバー ＆ クラウドアプリ
ファイルサーバー、DB、Webサーバー
サーバー管理者権限（Server Admins）
Tier 2端末の認証情報を残さない
🛡️ GPOによる認証遮断ルール（Logon Denied）の徹底
Tier 2（エンドポイント）
一般PC ＆ モバイル端末
社内一般ユーザー端末、プリンタ
ヘルプデスク管理者権限
Tier 0 / Tier 1 管理者はログイン禁止
下位Tierで奪取された認証情報で上位Tier（DC等）へログインされるのを防ぐため、GPOで「ネットワーク経由の拒否」「ローカルログオン拒否」を明示的に強制配
置します。
© LOG Sprout G.K. All rights reserved.
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EQYW4VLJP.jpg)

GPO（グループポリシー）ガバナンスと継承設計
⚠️ GPO設計の2大アンチパターン
「巨大ごちゃ混ぜGPO」の作成:
1つのGPO内にセキュリティ、壁紙、ネットワーク等を無関係に詰め込
み、影響範囲を不可視化する。
「過度な細分化」によるGPO数の激増:
1設定ごとにGPOを分離しすぎ、ログオン処理遅延や評価順序の混乱を
招く。
「継承ブロック」「強制」の乱用:
ポリシーの上書き合戦が起き、障害時の原因究明を極めて困難にする。
💡 健全なGPO管理の3大原則
1. 適切な機能・目的単位での設計（塩梅の維持）:
ごちゃ混ぜにせず、細分化しすぎないカテゴリ単位（例: LAPS用、BitLocker
用）で作成
2. OU構造に沿った素直な上から下への継承:
ドメインルート ➔ 親OU ➔ 子OU へと自然にポリシーを透過させる
3. セキュリティフィルタリングの活用:
特定グループのみにGPOを適用させたい場合はグループで制御
🔄 特殊ポリシー（ループバック処理等）の特性理解と命名管理ルール:
VDIや共有端末等で「ログオン先PCに基づいてユーザー設定を適用する」ループバック処理（Loopback Processing）は、通常と評価順序が異なり混乱を招きやすい設定です。
「どのような特性のポリシーか」が第三者にも即座に判別できるよう、GPO名に明示的な識別子を設ける命名ルール（例: GPO_Computer_Loopback_VDI_UserSetting ）を徹底し、ブ
ラックボックス化を防ぎます。
© LOG Sprout G.K. All rights reserved.
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/KJ4WKQM571.jpg)

企業の現実（As-Is）を踏まえた「段階的是正ロードマップ」
⚠️ 一足飛びの是正は不可能（As-Isの複雑さ）
💡 ギャップ分析と「リスク順是正」
企業固有の制約の存在:
事業部ごとの独立採算、海外ブランチのローカル運用、法規制・データ
主権（GDPR等）による権限分離の要求。
サードパーティ設定の形骸化:
導入手順書通りに設定された過剰権限やドメインルートへのフルコント
ロール権限の放置。
1. 【最優先・即時】特権常用・ツール過剰権限の排除:
長年運用されてきたAD環境を突然理想型（To-Be）へ全変更すること
は運用破綻を招きます。
© LOG Sprout G.K. All rights reserved.
現状（As-Is）とあるべき姿（To-Be）のギャップを抽出し、優先度を
つけて段階的に是正します。
Domain Admins常用アカウント剥奪とサービス用権限の切り出し
2. 【中長期】Tier階層化と委任（Delegation）グループ化:
ヘルプデスク・サードパーティツールの特定OU限定ACL設定
3. 【恒久】OU再構造化とAGDLPモデルへの適用:
事業部・海外拠点の管理境界の見直しとグループ再設計
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LE1YXP827G.jpg)

まとめ：堅牢なActive Directoryを維持する3つの鉄則
特権管理とOU・グループ設計の最適化で堅牢な全社ID基盤を構築する
1. Domain Admins等のビルトイン特権常用を即時排除し、最小権限の委任（Delegation）を行う
（サードパーティツールの手順書を鵜呑みにせず、特定OU限定×専用グループ×限定アクションのACLに留める）
2. 管理境界（Delegation）・GPO単位のOU構造とAGDLPモデルを貫く
（過度な細分化を避け、監査ログ・ログオンホスト制限・多要素認証などの多層防御と併せて適切な塩梅を見極める）
3. 企業の現状（事業部・海外ブランチ・法規制）に即して優先度付き是正を行う
（一足飛びの変更を避け、ギャップ分析に基づく段階的な是正とTierモデル適用でランサムウェア耐性を着実に高める）
© LOG Sprout G.K. All rights reserved.
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GEWGN2Z2J2.jpg)

ご清聴ありがとうございました。
© LOG Sprout G.K. All rights reserved.
14