ADのユーザーとグループ管理｜最小権限を実現する設計パターン

「田中さんに共有フォルダへのアクセス権を付けておいてください」
この依頼を受けて、田中さんのユーザーアカウントに直接アクセス権を設定するのは得策ではありません

その方法でも問題なく動きます。しかし田中さんが異動したとき、退職したとき、同じ業務をする山田さんが入社したとき、そのたびに個別の設定変更が発生し、気づいたときには「誰がどこにアクセスできるか誰も把握していない」状態になります。

ADのグループ管理は「便利な機能」ではなく「権限管理を破綻させないための設計思想」です。この記事では、ユーザーとグループをどう設計・運用するかを実務パターンとともに解説します。

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

「ユーザーに直接権限を付与する」運用が招く問題

ユーザーアカウントに直接権限を付与する運用は、短期的には問題なく動きます。しかし時間が経つほど、次の問題が積み上がります。

• 誰が何にアクセスできるか、全体像を把握できなくなる（1件ずつ確認するしかなく、100人規模では現実的に不可能）
• 異動・退職対応が属人化する（「田中さんがアクセスできる全リソース」を洗い出す手段がなく、対応漏れが発生する）
• 監査に耐えられない（「なぜこの社員はこのリソースにアクセスできるのか」を説明できない）

異動・退職時に権限が残り続けるリスクについては「IDライフサイクル管理とは？入社・異動・退職で権限を正しく管理する方法」で詳しく解説しています。グループ設計を正しく行うことで、これらの問題をすべて防ぐことができます。

参考：Active Directory のセキュリティグループ | Microsoft Learn

ADのユーザー管理の基本

ユーザーアカウントの種類（一般・管理者・サービスアカウント）

ADで管理するユーザーアカウントは大きく3種類です。

一般ユーザーアカウント
日常業務に使用するアカウント。最小権限の原則に基づき、業務に必要な権限のみを付与する。

管理者アカウント
ADやサーバの管理操作に使用する専用アカウント。一般ユーザーアカウントとは別に作成し、日常業務では使用しない。

サービスアカウント
アプリケーションや自動処理がシステムへアクセスするための専用アカウント。人が操作しないため管理が見落とされやすい。

この3種類を混在させず、それぞれ専用のOUに分離して管理することが重要です。特に管理者アカウントを日常業務で使用することは、侵害時の被害を最大化する原因になります。サービスアカウントの設計については「サービスアカウントの権限設計｜最小権限を守るためのパターンと実務ガイド」で詳しく解説しています。

命名規則を統一する理由

アカウントの命名規則を統一することで、一覧を見ただけでアカウントの種類・所属・用途が把握できる状態になります。

命名規則の例：

種類	命名パターン	例
一般ユーザー	名前のローマ字	t.tanaka
管理者アカウント	adm_名前のローマ字	adm_t.tanaka
サービスアカウント	svc_サービス名	svc_backup

管理者アカウントに adm_ プレフィックスを付けることで、ログを見たときに「これは管理者操作だ」と一目でわかります。命名規則がないと監査・インシデント対応時のログ分析が困難になります。

アカウントの無効化と削除の違い

退職者対応でよく混乱するポイントです。

アカウントの無効化
ログインできない状態にするが、ADオブジェクトとして残す。グループ所属・権限設定がそのまま保持される。退職直後の一時的な措置として使用。

アカウントの削除
ADオブジェクトごと削除する。一度削除すると復元が困難なため、無効化後に一定期間（30〜90日）経過してから実施する。

退職時は即削除ではなく「無効化→一定期間後に削除」という2段階の手順を踏むことを推奨します。退職後に「あのファイルへのアクセス履歴を確認したい」という場面で、アカウント情報が必要になるケースがあるためです。

グループの種類と使い分け

セキュリティグループとディストリビューショングループ

セキュリティグループ
アクセス権の付与・GPOの適用対象の指定に使用するグループ。AD権限管理の中心。

ディストリビューショングループ
メール配信リストとして使用するグループ。アクセス権の付与には使用できない。

権限管理に使用するのはセキュリティグループのみです。ディストリビューショングループを誤って権限付与に使おうとしても機能しません。混乱を避けるため「権限管理＝セキュリティグループ」と覚えておいてください。

グループのスコープ（ドメインローカル・グローバル・ユニバーサル）

グループには3つのスコープ（適用範囲）があります。

スコープ	メンバーの範囲	権限付与の範囲	主な用途
ドメインローカル	任意のドメイン	同一ドメイン内のみ	リソースへのアクセス権付与
グローバル	同一ドメインのみ	任意のドメイン	ユーザーをまとめる役割グループ
ユニバーサル	任意のドメイン	任意のドメイン	フォレスト横断の管理（大規模環境）

シングルドメイン環境ではグローバルグループとドメインローカルグループの組み合わせが基本です。次のAGDLPモデルで具体的な使い方を説明します。

AGDLPモデルというグループ設計パターン

AGDLP（Account→Global→DomainLocal→Permission）
ADのグループ設計における推奨パターン。ユーザーアカウントをグローバルグループに入れ、そのグローバルグループをドメインローカルグループに入れ、ドメインローカルグループにアクセス権を付与する。

AGDLPは以下の4層で構成されます。

A（Account）         ← ユーザーアカウント（例：t.tanaka）
  ↓ 所属
G（Global Group）    ← 役割グループ（例：GG_営業部）
  ↓ 所属
DL（DomainLocal）    ← リソースグループ（例：DL_営業フォルダ_読取）
  ↓ 権限付与
P（Permission）      ← リソースへのアクセス権（例：営業フォルダの読取権限）

AGDLPのメリットは「役割」と「リソース」を分離できる点です。田中さんが営業部から開発部に異動した場合、GG_営業部 から外して GG_開発部 に追加するだけで、関連するすべてのリソースへのアクセス権が自動的に切り替わります。リソースごとに個別設定を変更する必要はありません。

参考：Active Directory グループの種類とスコープ | Microsoft Learn

AGDLPは仕組みとして理解しても、実際の組織でグループをどう命名し、どう運用ルールに落とし込むかで迷う方が多い設計です。実務の型をもっと詳しく知りたい方は、こちらの一冊も参考になります。

実務で使えるグループ設計の型

役割ベースで設計する（RBACの視点）

グループ設計の基本は「人ではなく役割で考える」ことです。この考え方はクラウドのRBACと全く同じ思想です。

役割ベースアクセス制御（RBAC）
ユーザー個人ではなく「役割（ロール）」に対して権限を定義し、その役割にユーザーを所属させることでアクセス権を管理する仕組み。

クラウド環境でのRBACについては「RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説」で詳しく解説しています。オンプレのADグループ設計とクラウドのRBACは同じ設計思想で統一できます。

実務での設計手順は以下の通りです。

1. 組織内の業務役割をリストアップする（「営業担当」「開発エンジニア」「経理担当」「システム管理者」など）
2. 役割ごとにグローバルグループを作成する（GG_営業部 GG_開発部 GG_経理部 のように命名）
3. リソースごとにドメインローカルグループを作成する（DL_営業フォルダ_読取 DL_開発サーバ_変更 のように「リソース名＋権限」で命名）
4. ドメインローカルグループにリソースのアクセス権を付与する
5. グローバルグループをドメインローカルグループに追加する（GG_営業部 を DL_営業フォルダ_読取 に追加）

最小権限の原則に基づいたアクセス権の設計については「最小権限の原則とは？実務での考え方と設計例」も参照してください。

ネスト（入れ子）の使い方と落とし穴

グループのネスト（入れ子）
グループの中に別のグループを所属させること。AGDLPモデルでグローバルグループをドメインローカルグループに入れるのがその例。

ネストは適切に使えば管理を効率化できますが、乱用すると「なぜこのユーザーがこのリソースにアクセスできるのか」の追跡が困難になります。

ネストは2層までを原則にしてください。グループの中にグループが3層・4層と続くと、権限の棚卸し・トラブルシューティングが実質不可能になります。

ファイルサーバ権限管理への適用例

AGDLPモデルをファイルサーバの権限管理に適用した具体例です。

営業共有フォルダ（\\fileserver\sales）
├── DL_Sales_Read（読取権限）
│   └── GG_営業部（営業部全員）
│   └── GG_営業部長（部長も読取可）
└── DL_Sales_Write（書込権限）
    └── GG_営業部長（部長のみ書込可）

このような設計にすることで、人事異動時は GG_営業部 の所属変更だけで対応でき、リソース側の設定は一切変更不要になります。

よくある失敗パターン

ユーザーに直接権限を付与している

前述の通り、最も多い失敗です。「急ぎだから」「グループを作るのが面倒だから」という理由で始まった直接付与が積み重なり、管理不能な状態になります。1人でもグループ管理に移行を始めることで、少しずつ改善できます。

グループの目的が曖昧で肥大化している

GG_全員 DL_なんでもアクセス のような汎用的なグループを作ってしまうケースです。最初は便利に見えますが、気づいたときには「このグループを削除したら何が壊れるかわからない」状態になります。グループは作成時に「何の目的で・誰が所属し・何にアクセスできるか」を明確に定義してください。

退職・異動後もグループ所属が残り続ける

人事異動のたびにグループ所属の変更が漏れると、権限のスプロールが発生します。

権限スプロール（Permission Sprawl）
不要になった権限が削除されずに蓄積し、ユーザーが過剰な権限を持ち続ける状態。異動・退職対応の漏れが主な原因。

IDライフサイクル管理の観点での対応については「IDライフサイクル管理とは？入社・異動・退職で権限を正しく管理する方法」を参照してください。定期的なグループ所属の棚卸しを仕組みとして組み込むことが重要です。

グループのネストが深すぎて追跡できない

グループの中にグループが5層・6層と続く状態は、権限の棚卸しを実質不可能にします。「なぜこのユーザーがこのリソースにアクセスできるのか」を追跡するために、グループのメンバーシップを何層もたどる必要があるためです。AGDLPモデルを守り、ネストは2層以内に抑えてください。

参考：Active Directory のベスト プラクティス | Microsoft Learn

ユーザー・グループ管理チェックリスト

ユーザー管理

• [ ] 一般・管理者・サービスアカウントが分離されているか
• [ ] アカウントの命名規則が統一されているか
• [ ] 管理者アカウントを日常業務で使用していないか
• [ ] 退職者アカウントの無効化・削除手順が定められているか

グループ設計

• [ ] ユーザーに直接権限を付与していないか
• [ ] AGDLPモデルに基づいたグループ設計になっているか
• [ ] グループのネストは2層以内に収まっているか
• [ ] 各グループの目的・所属条件が明文化されているか

運用

• [ ] 異動・退職時のグループ所属変更手順が定められているか
• [ ] 定期的なグループ所属の棚卸しルールがあるか
• [ ] 不要なグループの削除基準が定められているか

グループ設計はIAMとADをつなぐ設計思想

ADのグループ管理は、オンプレミスにおけるIAMの実装です。「誰が・何に・どこまでアクセスできるか」を管理するという点で、クラウドのRBACとまったく同じ設計思想です。

AGDLPモデルを守り、役割ベースでグループを設計することで、異動・退職対応がシンプルになり、監査に耐えられる状態が維持できます。

現在の環境でユーザーアカウントに直接権限が付与されていないか、まず確認してください。そこから改善を始めることがグループ設計の第一歩になります。

ここまで読んで「実際に手を動かしてみたい」と思った方へ。AD環境の構築から、OU・GPO・グループ設計、Tierモデルによる防御、そして実際の攻撃までを段階を踏んで体験できる演習シリーズを公開しています。

あわせてご覧ください

• Active Directoryとは？Windows認証基盤の仕組みと設計の基本
• ADのドメインとOU設計｜組織構造をActive Directoryに落とし込む実務ガイド
• グループポリシー（GPO）設計入門｜セキュリティ設定をADで一括管理する方法
• AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務
• ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド
• 【ハンズオン】VirtualBoxでActive Directory環境を ゼロから構築する演習コンテンツを公開しました
• RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説
• 最小権限の原則とは？実務での考え方と設計例
• IDライフサイクル管理とは？入社・異動・退職で権限を正しく管理する方法
• サービスアカウントの権限設計｜最小権限を守るためのパターンと実務ガイド