Active Directory の委任に関するベストプラクティス
Active Directory の委任では、特権グループへの所属ではなく、OU（組織単位）レベルでタスクに応じた権限を付与します。これにより、各ロールは実際に必要な業務範囲に正確に絞り込まれます。正式な委任モデルを省略すると、未記録のアクセス制御エントリが蓄積され、レビューから外れていきます。その結果、誰も Domain Admins に触れないままでも悪用可能な状態になり得ます。機能するモデルには、ロール、範囲を限定した OU、そして継続的なレビューが必要です。
侵害の約 30% は、有効なアカウントの悪用から始まると The IBM X-Force 2025 Threat Intelligence Index が述べています。Active Directory の組み込みの特権グループは、そこに含まれるすべてのアカウントに対してドメイン全体の読み取り・書き込み権限を付与するため、資格情報の危険性を不釣り合いなほど高めてしまいます。
日常的なパスワード再設定のために Domain Admins に追加されたヘルプデスク担当者は、実際の業務内容が何であっても、AD インフラを保守するエンジニアと同じアクセス権を持ってしまいます。
Active Directory の委任は、特権グループのメンバーシップを通じて権限を付与するのではなく、OU（組織単位）のレベルでタスク固有の権限を割り当てることで、その不一致を解消します。
このガイドでは、AD の委任モデルを構築する方法、Delegation of Control Wizard（委任コントロール ウィザード）を使って委任された権限を適用する方法、そして、委任された権限が管理されないアクセスとして蓄積していかないように維持する運用上の実践を扱います。
Active Directory の委任とは何ですか？
Active Directory の委任では、管理者がユーザーやグループを Domain Admins や Account Operators のような特権グループに追加することなく、タスク固有の昇格権限をユーザーやグループに付与できます。
これらのグループはドメイン全体に対する完全な権限を持ちます。つまり、Domain Admins に含まれるアカウントであれば、実際の業務要件がどれほど狭いものであっても、ディレクトリ内のすべてのオブジェクトを読み取りおよび書き込みできます。
Active Directory の委任 特定の組織単位（OU）またはオブジェクト クラスにアクセス制御エントリ（ACE）を適用し、権限を役割に必要な範囲に正確に限定します。
ある OU でパスワードをリセットするように委任されたヘルプデスクの担当者は、その権限をそのスコープ内でのみ得ます。権限は他の OU には及ばず、またそのアカウントはどの特権グループにも表示されません。
AD の委任モデルを作成する方法
委任モデルでは、環境内の管理者ロール、各ロールが保持する権限、そしてそれらの権限をスコープする OU 構造を定義します。これがないと、委任された権限が非公式に積み重なっていき、監査が不可能になります。
ステップ 1：ロールを作成する
まず、2つの階層の administrator roles：service admins と data admins から始めます。
- Service admins は Active Directory のインフラそのものを管理します。この階層には、Enterprise Admins、Domain Admins、および AD レプリケーション、ドメイン サービス、または重要なシステムで使用されるサービス アカウントを維持する任意のアカウントが含まれます。この階層のすべてのメンバーはドメイン内のあらゆるオブジェクトに影響を与え得るため、環境で許される範囲でできるだけ小さく保ってください。
- Data admins は、基盤となるインフラに触れることなく、ディレクトリ内のオブジェクトを管理します。この階層はスコープ別に整理してください：
- Tier 1 (Regional Admins)： 定義された地理的リージョンまたは事業部内で、ユーザーおよびグループ オブジェクトを管理します。
- Tier 2 (Departmental Admins)： 特定の部門または機能内でユーザー アカウントを管理します。
- Tier 3（ヘルプデスク）： 指定された OU の範囲内で、パスワードのリセットやアカウントのロック解除などの限定的な操作を実施します。
役割の数は少なく保ちましょう。役割を追加するたびに、文書化・割り当て・レビューが必要な権限セットが作成されます。役割の増殖は、成熟した AD 環境において管理されないアクセスが蓄積する主な原因です。
ステップ 2：責任を割り当てる
各ロールごとに、どの権限が適用されるか、どのオブジェクトクラスに適用されるか、そしてどの OU で適用されるかを文書化します。各割り当てを 3 つの次元でマッピングしてください：
- 頻度：そのロールがタスクを実行する頻度。この値により、レビューの間隔（スケジュール）や、自動化ツールが必要かどうかが決まります。
- 重要度：そのタスクが業務上の重要なものか、日常的な管理作業かによって、最初の付与（初回付与）に対する承認の基準（しきい値）が変わります。
- 難易度：そのタスクに高度な技術的判断が必要か、それとも一般的な担当者（ジェネラリスト）が実施できるかによって、研修やオンボーディング要件が決まります。
一般的な操作には標準の Active Directory のアクセス制御リスト（ACL）を使用し、Force Change Password や Apply Group Policy のような操作には拡張権限（Extended Rights）を使用します。委任（delegation）の時点で、すべての割り当てを文書化してください。文書化されていない権限は、アクセスレビューや監査では見えなくなります。
ステップ 3：OU のセキュリティモデルを定義する
いかなる権限も適用する前に、委任（delegation）の境界を反映した OU 階層を設計します。特権アカウントおよび管理アカウントは、それらが管理するオブジェクトとは別の OU に配置してください。たとえば、管理対象のユーザーと同じ OU に保存された Domain Admin アカウントは、OU レベルの privilege escalation を通じて狙われる可能性があります。
最上位レベルでは、地理、組織、機能のいずれであっても、管理モデルに合わせて OU を作成します。各最上位 OU の中に、データ管理スコープに対応するサブ OU を作成してください。
各スコープごとに専用のセキュリティ グループを作成し、権限の委任は個々のアカウントではなく、そのグループに対して行ってください。
この構成により、継承に基づく権限昇格が制限されます。サブ OU レベルで委任された管理者は、当該レベルで権限が明示的に付与されていない限り、親 OU または同じ階層（兄弟）の OU 内のオブジェクトに影響を与えることはできません。組織モデルが変更されるたびに OU 構成を見直してください。
Netwrix Auditor は、ハイブリッド Microsoft 環境全体でのアクセスおよび変更イベントの「変更前」と「変更後」の値を記録します。デモを依頼してください。
Active Directory で制御を委任する方法
Active Directory Users and Computers (ADUC) の Delegation of Control Wizard は、委任された権限を適用するための主要なツールです。選択した OU またはコンテナーに ACL エントリを直接書き込み、後でその OU の Security タブから確認できる権限割り当てを作成します。
手順 1：Delegation of Control Wizard を開く
ADUC で、View メニュー配下の Advanced Features がまだ有効になっていない場合は有効化します。委任を適用したい OU に移動し、右クリックして "Delegate Control" を選択します。ウィザードは、選択した OU とその中身にのみ権限を適用します。親 OU は影響を受けません。
手順 2：ユーザーまたはグループを選択する
Users or Groups のペインで、委任された権限を受け取る管理者ロールを表す security group を追加します。
グループベースの割り当てにより、OU の ACL を直接変更するのではなく、メンバーシップを変更することでアクセスを追加または削除できます。これにより、権限構造を監査可能で元に戻せる状態に保ちます。
個々のアカウントに割り当てられた権限は ACE を作成し、誰かが手動で削除しない限り、役割の変更や退職（offboarding）の後も残り続けます。
ステップ 3：委任するタスクを選択
ユーザー アカウントの作成または削除、パスワードのリセット、ユーザー情報の読み取り、グループ メンバーシップの管理などの標準的な操作には、「次の一般的なタスクを委任」を選択します。
Force Change Password や Apply Group Policy などの拡張権限を含め、あらかじめ用意された一覧にない権限については、「委任するカスタム タスクを作成」を選択します。
ステップ 4: 委任のスコープを指定する
カスタム タスクの場合、委任が適用されるオブジェクト クラス（ユーザー オブジェクト、コンピューター オブジェクト、またはグループ オブジェクト）を定義し、権限が OU 自体に適用されるのか、OU 内のオブジェクトに適用されるのか、または両方に適用されるのかを指定します。範囲は、役割の文書化された責任が要求する範囲内でできるだけ厳密に制限してください。
ステップ 5: 完了して確認する
ウィザードが完了したら、ADUC で OU を右クリックし、「プロパティ」を選択して「セキュリティ」タブを開き、結果を確認します。期待する ACE が正しい権限とスコープで一覧に表示されていることを確認してください。
委任されたグループのメンバーとしてログインし、許可された操作と除外された操作の両方を試して、委任が意図どおりに正確に機能していることを確認します。
Active Directory の委任（delegation）に関するベストプラクティス
委任（delegation）モデルと Delegation of Control Wizard が、技術的な基盤を提供します。これらの実践により、環境や組織が変化しても、その基盤のセキュリティが維持されます。
割り当ての時点で、すべての委任を記録する
各 Delegation of Control Wizard を実行した後、そのアクセスを使用する前に、集中アクセス登録簿に OU、権限を受け取るグループ、付与された具体的な権限、および業務上の正当性を記録してください。
このウィザードは独自のログを生成しません。ウィザードは、操作内容、承認者、または付与の根拠を記録することなく、OU のセキュリティ記述子に ACE を適用します。記録されていない ACE は、アクセスレビューや監査の際に見えなくなり、担当者が入れ替わった後は、唯一の文脈の手掛かりを失ってしまいます。
スプレッドシート、ITSM チケット、または専用の IAM システムのいずれも目的を果たせます。重要なのは、アクセスが使用される前に文書が存在し、技術的な範囲だけでなく業務上の正当性も含めていることです。
委任された権限は個々のアカウントではなく、セキュリティ グループに割り当てる
権限を個々のアカウントに割り当てると、その人が組織を離れたり、役割を変更したり、アカウントが無効化された後も、権限は OU の ACL に残り続けます。
ACE はアカウントの SID に紐づいたままで、標準の offboarding（退職・離任）手順の一部として自動的にはクリアされません。
セキュリティ グループに割り当てられた権限は、offboarding（退職・離任）の際にアカウントをグループから削除することで取り消されます。これにより標準的な IAM のワークフローに適合し、明確な監査証跡が作成でき、チームが成長したり変化したりしてもスケールします。
グループ メンバーシップの変更は Security ログにイベントを生成します。一方、OU に対して ACE を直接変更する場合は、同等の証拠を得るために特定の監査ポリシー設定が必要です。
すべての委任に最小特権の原則を適用する
各ロールが文書化されたタスクを実行するために必要な権限だけを付与します。最も狭い OU スコープを使用し、作業に必要な最も具体的な権限セットを選択してください。
委任に適用される principle of least privilege とは、権限を親 OU ではなく該当するサブ OU にスコープ設定し、広い書き込みアクセスではなく特定の拡張権限を選択することを意味します。また、複数のケースをカバーするためにより広い権限を付与するのではなく、複合的なタスクを個別の委任に分割することも含まれます。
委任を適用した後は、委任されたグループのメンバーとしてログインし、意図した操作だけが成功し、除外された操作は失敗することを確認してテストします。
委任された権限は少なくとも四半期ごとに見直す
定期的なアクセスレビューを計画し、重要な OU 上の ACE を列挙して、各エントリが現在の業務要件をまだ反映していることを確認します。
対象 OU で「セキュリティ(Security)」タブを開きます（ADUC で「高度な機能（Advanced Features）」が有効になっている場合にのみ表示されます）。明示的エントリと継承されたエントリの両方を確認してください。アクティブなメンバーや文書化された目的がないグループに属する ACE は削除します。
Active Directory で委任された権限を検出する 大規模に対応するには PowerShell または目的に合わせて作られたツールが必要です。ネイティブの ADUC インターフェイスは現在の権限状態は表示しますが、ACE がいつ作成されたか、誰が作成したかについては何も記録しません。
四半期ごとの見直しで、権限のドリフトが積み重なって、監査しにくい未文書化のアクセス滞留にまで発展する前に食い止められます。
特権操作には別々のアカウントを使用する
管理者が委任されたタスクを実行する際は、電子メールや日常業務に使用するアカウントとは別の専用の管理者アカウントを使用することを求めます。
標準アカウントは日常的な活動を担当し、通常のユーザー資格情報と同等のリスク特性を持ちます。管理者アカウントは、権限の昇格が必要な高権限操作を行うときだけ有効化されるべきで、電子メール、Web閲覧、または信頼できないコンテンツを扱ういかなるワークステーションにもアクセスできないようにします。
privileged account management 戦略では、管理者アカウントを日常使用の資格情報から分離することで、資格情報に基づく横方向への移動（lateral movement）に対する最も効果的な対策の1つになります。
権限スコープの分離（isolation）により、攻撃者が単一の資格情報を侵害した場合に得られる範囲が制限され、特権アカウントのアクティビティを日常のユーザー行動とは切り離して監査可能にします。
高い特権を委任する権限には、just-in-time アクセスへ移行する
最上位の特権ロールでは、常設の委任アクセスを完全に排除し、just-in-time access に置き換えます。承認されたタスクの実行中のみ権限を付与し、タスク終了と同時に自動で権限を取り消します。
常設の委任アクセスとは、たとえそのアカウントが実際にほとんど使われないとしても、その権限を持つすべてのアカウントが、資格情報の盗難、フィッシング、または横方向への移動によって常に永続的にさらされることを意味します。
just-in-time アクセスは、侵害された資格情報が委任された権限を悪用できる“期間”を縮小し、四半期ごとのレビューでカバーすべき ACE の影響範囲を減らし、承認とセッションの記録を生成して、規制環境における監査エビデンスを強化します。
Netwrix Privilege Secure は、常設の管理者アカウントを just-in-time の特権セッションに置き換えます。セッションは自動で取り消されます。デモを依頼してください。
特定の権限を委任するときの考慮事項
以下の各権限タイプには、Delegation of Control Wizardでは明示されないセキュリティ上の影響があります。
パスワードのリセットとアカウントのロック解除
まず OU の境界を確認してください。Domain Admin アカウント、または サービスアカウント が含まれる OU でパスワードをリセットするよう委任されたロールは、tier-zero へのアクセスにつながる認証情報のリセット経路を持っている可能性があります。権限スコープは技術的には正しいものの、OU スコープは正しくありません。委任を適用する前に、その OU に標準ユーザーアカウントのみが含まれていることを確認してください。
グループ メンバーシップの管理
この委任を適用する前に、保護対象メンバー（Domain Admins、Enterprise Admins、Account Operators）に適用範囲となるグループを監査してください。
Active Directory の SDProp プロセスは、60 分ごとにこれらのアカウントへ AdminSDHolder の ACE を再適用し、カスタムの委任を静かに上書きします。
これらのアカウントに適用された委任は保持されず、適用を試みるだけでも調査すべき兆候です。
グループ ポリシー オブジェクト（Group Policy Object）のアクセス許可
グループ ポリシーの委任は3つの権限（作成、編集、リンク）に分割されており、既定ではリンク権を他の権限と一緒に付与すべきではありません。
GPO をリンクすると、その設定は対象の OU とその子（配下）のすべてのオブジェクトに直ちに適用されます。リンク権は、独立した昇格（特権）の付与として扱い、必ずそれ自体の承認を取得してください。
コンピューター アカウントの管理
コンピューター アカウントの管理を委任する前に、ms-DS-MachineAccountQuota を 0 に設定します。既定値が 10 の場合、委任がまったくなくても、認証済みの任意のユーザーがドメインにコンピューターを参加させることができます。
また、標準のコンピューター アカウント委任には SPN の書き込みアクセスが含まれる点にも注意してください。役割が特に必要としていない限り、この権限は付与から外してください。SPN の書き込みアクセスは Kerberoasting の露出（リスク）を生みます。
Kerberos 認証の委任設定
Kerberos の委任は、Active Directory における制御の委任とは別の属性です。Delegation of Control Wizard では設定できず、委任のレビュー中に見落としやすい点があります。
委任されたアカウントを監査する際は、それらのアカウントに unconstrained Kerberos delegation（非制約の Kerberos 委任）が付与されていないか確認してください。付与されている場合は、そのアカウントを所属 OU に関係なく Tier 0 として扱います。なぜなら、unconstrained delegation が有効な状態で侵害されたサービスは、ドメイン コントローラーがそのサービスに渡したすべての TGT を公開してしまうためです。
Netwrix が Active Directory の委任をどのように支援するか
Active Directory の委任は制御を環境全体に分散します。分散された権限は、レビューされず、またドキュメント化されていないまま放置されると、潜在的なギャップ（抜け）になり得ます。
役割は時間の経過とともに権限が積み上がり、グループは本来保持すべきでないメンバーを引き受けるようになり、特定のプロジェクトのために適用された ACE は、そのプロジェクトが終了した後も OU に長く残り続けます。
権限の変更を継続的に可視化できない場合、セキュリティチームは、委任モデルが強制すべきアクセスの態勢を維持できません。
委任されたアクセスを統制するには、権限の変更をリアルタイムで検知し、悪用可能になる前にドリフトを特定し、アクセスレビューやコンプライアンス監査のために、防御可能な根拠（エビデンス）を作成する必要があります。
Netwrix Auditor は、AD の権限変更をリアルタイムで監視し、アクセスレビューや規制上のエビデンスを支える「変更前・変更後」の監査トレイルを作成します。
Netwrix Access Analyzer ネストされたグループと OU の継承を通じて有効なアクセスをマッピングし、監査での指摘事項になる前に、過剰または古い（形骸化した）委任権限を可視化します。
これらを組み合わせることで、セキュリティチームは「何が変わっているのか」と「その変更によってどのようなアクセス状態が生じるのか」を継続的に可視化できます。
デモをリクエスト Netwrix が Active Directory の委任（delegation）を統制し、権限のドリフト（permission drift）を検出し、防御可能な監査証跡（audit trail）を維持するのにどのように役立つかをご確認ください。
Active Directory デリゲーションのベストプラクティスに関するよくある質問
共有する