Deployment of Active Directory 2... NTドメインの再設計
セキュリティ設計
●リソースへのアクセス制御
Windows 2000は，Windows NT 4.0と同様に，ファイルやプリンタなどのリソースに対するアクセス制御にACL（Access Control List）を利用する。ACLとは，特定のリソースに対して「誰の」「どのような操作を」「許可または拒否するのか」を定義したACE（Access Control Entry）の列挙である。
ACEの「誰の」という部分を定義するときには，セキュリティプリンシパルを用いる。Windows 2000におけるセキュリティプリンシパルには，ユーザーオブジェクト，グループオブジェクト，コンピュータオブジェクトの3種類がある。一般的には，ユーザーオブジェクトやグループオブジェクトを用いることが多いと思われるが，直接ユーザーオブジェクトを指定するよりも，グループオブジェクトを用いて抽象化したほうが柔軟に管理できる場面は多い。たとえば，職種や部署などの属性に応じてグループオブジェクトを作成しておけば，人事異動などによってユーザーオブジェクトを移動する際にも，適切なセキュリティを保つことができる。
Windows 2000のグループアカウントは，「グループタイプ」と「グループスコープ」の2種類で分類することができる。Windows NT 4.0におけるグループは，グループタイプはセキュリティグループのみであったため，その分類はグループスコープだけであった。しかしWindows 2000では，グループタイプが複数存在するため，より柔軟にセキュリティを設定できるようになっている。
○グループタイプ
グループタイプとは，グループを目的別に分類したものである。グループタイプには，「セキュリティグループ」と「配布グループ」の2種類がある（Table 1）。Windows NT 4.0はメッセージングシステムを考慮して設計されていなかったので，配付グループに相当する概念は用意されていなかった。しかしWindows 2000では，セキュリティグループを電子メールの宛先として利用できるようになったので，グループオブジェクトの利用範囲が広がった。たとえば，あるプロジェクトチームを表すセキュリティグループを作成すれば，そのグループオブジェクトを利用してファイルなどのアクセス権限を設定できるほか，電子メールの宛先に使うこともできる。一方、配布グループをセキュリティ設定に用いることはできないので，うっかり不要なアクセス権限を設定してしまうという事故を防ぐこともできる。
Table 1 グループタイプの違い
| セキュリティ設定 | メールの配布先 | 概要 | |
|---|---|---|---|
| セキュリティグループ | ○ | ○ | アクセス権限（Permission）やユーザーの権利（User Rights）などのセキュリティを設定するためのグループオブジェクト。配布グループとして用いることもできる |
| 配布グループ | × | ○ | 電子メールの宛先として利用するグループオブジェクト。一般的な電子メールシステムでは「配付リスト」と呼ばれることもある。セキュリティ設定に利用することはできない |
○グループスコープ
グループスコープとは，グループオブジェクトの有効範囲と設定可能なメンバによる分類である。Windows 2000のグループスコープには，「ドメインローカル」，「グローバル」，「ユニバーサル」，「ローカル」という4種類がある。このうちローカルグループはActive Directoryに格納されるわけではないので，Active Directoryのグループスコープという観点では3種類である。
3種類のグループスコープで利用できる機能は，Active Directoryドメインがネイティブモードであるか混在モードであるかによって若干異なる（Table 2）。たとえば，混在モードにおけるユニバーサルグループは，セキュリティグループとして作成することはできず，配布グループとしてしか作成できない。
Windows 2000のドメインコントローラでは，ローカルグループが廃止された。ただし，ビルトインローカルグループだけは以前と同じように用意されているので，見かけ上の変化はない。ビルトインローカルグループは，ドメインコントローラ間だけで有効であり，新規に作成することはできない。また，メンバサーバーやスタンドアロンサーバーにおけるローカルグループはWindows NT 4.0と同じものである。
Table 2 グループスコープ
| 範囲 | 目的 | メンバ | 混在モードでの制限 | |
|---|---|---|---|---|
| ドメインローカルグループ | そのドメイン内のみ | セキュリティ設定 | フォレスト内の任意のドメインに登録されたユーザーとグループ | ユーザーとグローバルグループのみメンバにできる |
| グローバルグループ | ドメインフォレスト全体 | アカウントの組織的な分類 | そのドメイン内のユーザーとグループ | グループをメンバにすることはできない |
| ユニバーサルグループ | ドメインフォレスト全体 | アカウントの組織的な分類 | フォレスト内の任意のドメインに登録されたユーザーとグループ | 配付グループとしてしか作成できない |
| ローカルグループ | そのコンピュータのみ | メンバサーバーやスタンドアロンサーバー，ワークステーションにおけるセキュリティ設定 | フォレスト内の任意のドメインに登録されたユーザーとグループ | Active Directoryの影響は受けない |
- ドメインローカルグループ
- ドメインローカルグループは，Windows NT 4.0におけるローカルグループに相当する。ただし，Windows NT 4.0とは異なり，メンバサーバーやワークステーションでもドメインローカルグループを利用できるので，ドメインのリソース管理者は，どのドメインの，どの人に，どのようなアクセス権限を与えるのかをドメインローカルグループを用いて設定できる。
Windows NT 4.0では，特定のメンバサーバーで共有リソースを独自に管理するため，ローカルグループを利用してきた。しかし，複数のメンバサーバーのリソースを管理する場合には，ローカルグループを個別に設定しなければならず，非常に不便だった。この問題を解決するため，Windows NT 4.0では，便宜的にグローバルグループを使ってアクセス権限を管理したり，わざわざドメインコントローラをファイルサーバーとして利用したりすることもあったのである。
しかしWindows 2000では，ドメインローカルグループで複数のサーバーに共通のグループを定義できる一方，メンバサーバーなどではローカルグループを利用して個別にリソースを管理することもできる。なお，同一のドメイン内でサーバーをいくつかのグループに分類したいときには，OUを作成すればよい。
- グローバルグループ
- Windows 2000におけるグローバルグループは，Windows NT 4.0におけるグローバルグループに相当する。つまり、そのドメイン内のユーザーを組織的に分類し，そのドメイン自身，あるいは別のドメインにおけるセキュリティ管理に利用する。
また，グローバルグループは，あるドメインのメンバにどのような属性があるのかを，そのドメインで責任を持って分類するために存在する。各ドメインのリソース管理者は，グローバルグループによってユーザーの属性を知り，ドメインローカルグループのメンバに登録すべきかどうかを判断する。
- ユニバーサルグループ
- ユニバーサルグループも，グローバルグループと同様に，ユーザーの組織的な分類に利用する。ただし，グローバルグループとは異なり，別ドメインのユーザーやグループをメンバにすることもできる。
グローバルグループは，あるドメインの管理者がそのドメインの管理下にあるユーザーの属性を設定したものといえる。しかし運用上は，組織を越えた分類が必要になることも多い。このような場合には，ユニバーサルグループを使う。つまり，会社の指揮系統（組織構成）を反映するようなグループを作成するときにはグローバルグループが向いているが，各部門から選ばれた代表者で一時的なプロジェクトチームを構成するようなときにはユニバーサルグループが向いている。
- ローカルグループ
- メンバサーバーやスタンドアロンサーバー，ワークステーションでは，Windows NT 4.0と同様のローカルグループを使用できる。ローカルグループは，ローカルユーザーと同様に，そのコンピュータ独自のアカウントとしてリソース管理に利用できる。
○アクセス権限の適用
以上の特性を考慮して，オブジェクトへのセキュリティは次のような手順で設定する。このような設定方法のことを，「AGLPポリシー」と呼ぶ。
- Account：ユーザーオブジェクトを作成する。
- Global Group：グローバルグループを作成し，ユーザーオブジェクトを分類する。別ドメインのユーザーオブジェクトやグループオブジェクトを使用する（クロスドメインメンバシップを構成する）場合は，ユニバーサルグループを使う。
- （Domain）Local Group：ローカルグループ（またはドメインローカルグループ）を作成し，メンバとしてグローバルグループ（またはユニバーサルグループ）を追加する。
- Permission：ローカルグループにアクセス権限を割り当てる。
AGLPポリシーに従うと，共有リソースの管理者は独自の判断でアクセス権限を自由に設定できるようになる。また，アカウント管理者はアクセス権限を何ら気にすることなく，純粋にアカウントの属性としてグループを作ることができる（Fig.16）。
Fig.16 AGLPポリシー（クリックで拡大可能）
●ディレクトリへのアクセス制御
ディレクトリサービス上のオブジェクトにアクセス権限を設定するときには，セキュリティプリンシパルを用いる。一般的には，セキュリティグループを用いることが多いだろう。
注意してほしい点は，ディレクトリサービスを経由することなく，UNCなどを使用して直接共有リソースを利用した場合，ディレクトリサービスのACLは無視されるということである。したがって，リソースへのアクセス権限は，必ずリソースそのものに設定しなければならない。なぜなら，ディレクトリのACLとは，あくまでも「ディレクトリオブジェクトの参照を許すかどうか」あるいは「ディレクトリオブジェクトのプロパティを設定できるかどうか」などを制御するものであって，リソースそのもののアクセスを制御するものではないからである。
 |
Deployment of AD−Part1 14/17 |  |
