Windows Server 2003 セキュリティ ガイド

トピック

	概要
	セキュリティの構成ウィザードを使用したセキュリティ強化
	Active Directory グループ ポリシーによるサーバーのセキュリティ強化
	プロセスの概要
	まとめ

概要

この章では、Microsoft® Windows Server™ 2003 に対するセキュリティ設定の導入に使用できるメカニズムについて説明します。Windows Server 2003 Service Pack 1 (SP1) には、役割ベースの新しいツールであるセキュリティの構成ウィザード (SCW) が用意されており、サーバーのセキュリティ向上に役立てることができます。これをグループ ポリシー オブジェクト (GPO) と組み合わせることで、セキュリティ強化プロセスの制御性、柔軟性、および整合性を向上させることができます。

この章では、次のトピックについて説明します。

この情報は、ドメイン インフラストラクチャ内のレガシ クライアント (LC) 環境をセキュリティ強化 - 機能制限 (SSLF) 環境に引き上げる方法の基礎およびビジョンとなります。

ページのトップへ

セキュリティの構成ウィザードを使用したセキュリティ強化

SCW の目的は、Windows Server 2003 SP1 を実行しているサーバーの攻撃対象を減らすための処理の柔軟性を高め、順を追って処理をできるようにすることです。SCW は、実際には XML ルール データベースと組み合わせて使用するツールの集合です。その目的は、管理者が、個々のサーバーが果たす役割に必要な最小限の機能を迅速かつ正確に特定できるよう支援することです。

SCW を使用することで、管理者は不要な機能をすべて無効にするセキュリティ ポリシーを作成、テスト、トラブルシューティング、および展開できます。また、SCW にはセキュリティ ポリシーをロールバックする機能も用意されています。SCW は、単一サーバーのセキュリティ ポリシー管理と、関連機能を共有するサーバーのグループをサポートします。

SCW は、次のタスクの実施に役立つ包括的なツールです。

SCW のインストール、使用、およびトラブルシューティングの詳細な手順については、http://www.microsoft.com/downloads/details.aspx?FamilyID=903fd496-9eb9-4a45-aa00-3f2f20fd6171&displaylang=en にある、ダウンロード版の文書『Security Configuration Wizard』(英語情報) を参照してください。

注 : SCW を使用できるのは、Windows Server2003 SP1 についてのみです。Windows 2000 Server、Windows XP、または Windows Small Business Server 2003 のポリシーの作成には使用できません。これらのオペレーティング システムを実行する多数のコンピュータのセキュリティを強化するには、この章で後述するグループ ポリシー ベースのセキュリティ強化メカニズムを採用する必要があります。

ポリシーの作成とテスト

SCW を使用すると、複数のサーバーまたはサーバーのグループのセキュリティ ポリシーを、1 台のコンピュータから短時間で作成およびテストできます。これにより、企業全体のポリシーを一元管理できます。ポリシーを使用することで、組織内の各サーバーの役割に適した、一貫性のあるセキュリティ強化手段が実現されます。ポリシーの作成とテストに SCW を使用する場合は、対象となるサーバーすべてに SCW を導入する必要があります。ポリシーの作成は管理ステーションで行いますが、SCW は、対象となるサーバーと通信して各構成を調査し、調査結果をもとにポリシーを微調整します。

SCW は IPsec サブシステムおよび Windows ファイアウォール サブシステムと統合されており、これらの設定を適宜変更します。SCW は、禁止されない限り、オペレーティング システムおよびリッスン中のアプリケーションに必要な重要ポートへの受信ネットワーク トラフィックを許可するように Windows ファイアウォールを構成します。追加のポート フィルタが必要な場合、SCW を使用して作成できます。その結果、SCW によって作成されるポリシーは、不要なトラフィックをブロックするために、カスタム スクリプトが IPsec フィルタの設定または修正を行う必要性を満たすことができます。この機能により、ネットワークのセキュリティ強化管理が簡略化されます。RPC または動的ポートを使用するサービスに対するネットワーク フィルタの構成も簡略化されます。

SCW を使用すると、作成するポリシーを大幅にカスタマイズできます。この柔軟性により、必要な機能を許可するだけではなく、セキュリティ リスクの低減にも役立つ構成を作成できます。ベースラインの動作および設定の他に、以下についても SCW による指定をオーバーライドできます。

SCW は管理者に対し、最も重要なレジストリ設定のついて支援情報を通知します。通知の対象は、ツールが複雑にならないよう、セキュリティに対する影響が大きい設定だけになっています。なお、このガイドでは、それ以外の数多くのレジストリ設定についても説明しています。SCW の機能を強化するため、SCW による生成物をセキュリティ テンプレートと組み合わせると、より完成度の高い構成を作成することができます。

SCW を使用して新しいポリシーを作成する場合、SCW は初期構成としてサーバーの現在の構成を使用します。したがって、サーバーの役割の構成を正確に記述できるよう、対象とするサーバーをポリシーの展開するサーバーと同じ種類にしてください。SCW のグラフィカル ユーザー インターフェイス (GUI) を使用して新しいポリシーを作成すると、SCW により XML ファイルが生成され、既定では %systemdir%\security\msscw\Policies フォルダに保存されます。ポリシーを作成したら、SCW GUI または Scwcmd コマンド ライン ツールを使用して、ポリシーをテスト サーバーに適用できます。

ポリシーをテストする際には、展開済みのポリシーを削除する必要があります。サーバーまたはサーバーのグループに最後に適用したポリシーは、GUI またはコマンド ライン ツールを使用してロールバックできます。SCW は、以前の構成設定を XML ファイルに保存します。

セキュリティ構成の設計とテストに使用できるリソースに制限がある組織では、SCW で十分です。このようなリソース不足の組織では、作業により予期しない問題が発生して生産性が損なわれる場合が多く、サーバーのセキュリティを強化することは危険です。所属する組織にこのような問題に対処する専門家がおらず、時間もない場合は、アプリケーションやオペレーティング システムの最新版へのアップグレードや更新管理など、その他の重要なセキュリティ強化活動に焦点を当てる方が得策です。

ポリシーを展開する

ポリシーの展開には次の 3 つの方法を使用できます。

それぞれの方法に利点と欠点があり、以下のサブセクションで説明します。

SCW GUI を使用してポリシーを適用する

SCW GUI を使用する方法の主な利点は簡略化です。GUI を使用することで、定義済みのポリシーを選択して 1 台のコンピュータに適用することが簡単になります。

SCW GUI を使用する方法の欠点は、一度に 1 台のコンピュータにしかポリシーを適用できないことです。この方法は、大規模な環境には応用できないので、このガイドでは使用しません。

Scwcmd コマンド ライン ツールを使用してポリシーを適用する。

SCW 独自のポリシーを複数のコンピュータに Active Directory を使用しないで適用する方法の 1 つは、Scwcmd ツールを使用することです。また、Scwcmd をスクリプト テクノロジと組み合わせて使用することで、ポリシーの展開をある程度、自動化することができます。この自動化は、サーバーの構築と展開に使用する既存のプロセスの一部などとしてポリシーを展開する場合が考えられます。

Scwcmd を使用する方法の主な欠点は、完全には自動化できないことです。ポリシーと対象サーバーは、手動で、または何らかのスクリプト ソリューションを使用して指定する必要があります。つまり、誤ったポリシーを不適切なコンピュータに適用してしまう可能性がいくつも存在します。グループ内に構成が少しずつ異なるサーバーが複数台ある場合、各コンピュータに専用のポリシーを作成し、個別に適用する必要があります。この制限により、このガイドではこの方法は使用しません。

SCW ポリシーをグループ ポリシー オブジェクトに変換する

SCW ポリシー展開の 3 番目の方法は、Scwcmd ツールを使用して、XML ベースのポリシーをグループ ポリシー オブジェクト (GPO) に変換することです。初めはこの変換が不要の手順に思えるかもしれませんが、次のような長所があります。

ページのトップへ

Active Directory グループ ポリシーによるサーバーのセキュリティ強化

Active Directory を使用すると、アプリケーションから、分散コンピューティング環境のディレクトリ リソースを検索、使用、管理することができます。Active Directory インフラストラクチャの設計方法を詳細に記述すると本一冊分になるため、ここでは、このガイドの以降の内容の背景となる概念について簡単に説明します。組織のドメイン、ドメイン コントローラ、および個々のサーバーの役割を安全に管理する、グループ ポリシーの使用について理解するために、この設計情報が必要になります。Active Directory 設計を既に行っている場合でも、この章の説明を参照することで、Active Directory のセキュリティ上の利点や発生し得る問題点について、正確で深い知識が得られます。

このガイドでは、Active Directory データベースをセキュリティ保護する方法については特に説明しません。これに関する説明については、この章の最後の「関連情報」に記載している文書『Best Practice Guide for Securing Active Directory Installations』(英語情報) を参照してください。

Active Directory インフラストラクチャを作成する際には、その環境のセキュリティの範囲を慎重に検討する必要があります。セキュリティの委任と実装スケジュールを入念に計画することで、その組織における Active Directory 設計の安全性がさらに高まります。買収、組織の再編成など、環境の大規模な変更を対象にした設計の再構築だけが必要になります。

Active Directory 境界

Active Directory 内には数種類の境界があります。これらの境界によりフォレスト、ドメイン、サイト トポロジ、および権限の委任が定義され、Active Directory のインストール時に自動的に確立されます。ただし、権限の境界に組織の要件とポリシーが組み込まれていることを確認する必要があります。さまざまな組織の要件に適合させるために、管理権限の委任に柔軟性を持たせることができます。たとえば、セキュリティと管理機能のバランスを適切に維持するために、権限の委任境界をセキュリティ境界と管理境界に分割するなどが可能です。

セキュリティ境界

セキュリティ境界は、組織内の各グループの独立性 (分離性) を定義するときに使用します。組織で確立されているビジネス境界に基づく万全なセキュリティの確保と、基本機能の一貫性とを、バランスよく実現するのは難しい課題です。両者のバランスが適切に保たれた環境を実現するには、管理権限の委任などの、環境のネットワーク アーキテクチャに関連する選択肢が、セキュリティに及ぼす影響を基に、組織に対する脅威を比較検討する必要があります。

ネットワーク環境の真のセキュリティ境界は、フォレストです。個別のフォレストを作成することで、他のドメインの管理者から侵害される可能性から環境を守ることをお勧めします。このアプローチにより、1 つのフォレストが侵害を受けても、企業全体の侵害には必ずしもつながらなくなります。

ドメインは、Active Directory の管理境界であって、セキュリティ境界ではありません。組織内のすべてのユーザーが善意ある人であれば、ドメイン境界を使用して、各ドメイン内のサービスとデータを自律的に管理できます。しかし、セキュリティという観点からは、分離の実現はそれほど単純ではありません。たとえば、悪意のあるドメイン管理者がいた場合、その管理者の攻撃からドメインを完全に守ることはできません。このような攻撃に対処できる分離レベルはフォレスト レベルだけです。

ドメイン内では、組織単位 (OU) が別のレベルの管理境界を提供します。ドメイン全体を管理する権限を与えずに、関連リソースをグループ化して適切な担当者に管理アクセスを委任する方法として、OU は柔軟な手段です。ドメインと同様、OU も真のセキュリティ境界ではありません。OU にアクセス許可を割り当てることはできますが、同じドメインに属するすべての OU が、ドメイン リソースとフォレスト リソースに対するリソース認証を行います。それでも、OU が階層的に適切に設計されている場合、その OU は効果的なセキュリティ対策の開発、展開、および管理に役立ちます。

組織は、現在の Active Directory 設計の範囲内で、管理者によるサービスとデータの制御の分割を検討する必要があります。効果的な Active Directory を設計するには、サービスの自律性と分離、およびデータの自律性と分離に関する組織の要件を十分に把握している必要があります。

管理境界

サービスとデータを分割する要求は潜在的に存在するので、必要な管理レベルをいくつか定義する必要があります。このガイドでは、組織固有の各サービスを実行する管理者に加えて、次の種類の管理者を設定することをお勧めします。

サービス管理者

Active Directory サービス管理者は、ディレクトリ サービスの構成と運用を担当します。たとえば、ドメイン コントローラ サーバーの管理、ディレクトリ全体に適用される設定の制御、サービスの可用性の維持などを行います。組織の Active Directory 管理者は、サービス管理者であると考えてください。

Active Directory サービス構成は、多くの場合、属性値として指定します。これらの属性値は、ディレクトリに格納されている各オブジェクトの設定に対応しています。つまり、Active Directory のサービス管理者はデータ管理者でもあります。組織では、Active Directory サービス設計にその他のサービス管理者グループを含めることを検討する必要がある場合があります。そのための方法の例を、次にいくつか紹介します。

データ管理者

Active Directory のデータ管理者は、Active Directory に格納されているデータ、または Active Directory に参加しているコンピュータ上のデータを管理します。ただし、ディレクトリ サービスの構成や運用を制御することはできません。データ管理者は、組織で作成するセキュリティ グループのメンバです。Windows の既定のセキュリティ グループでは、組織のすべての状況に対応できない場合があります。そのため、組織ごとの環境の基準と要件に合わせ、最適なセキュリティ グループを独自に作成できるようになっています。データ管理者の日常的な作業は次のとおりです。

注 :多くの場合、ディレクトリに保存されているオブジェクトの属性値によって、そのディレクトリのサービス構成が決まります。

つまり、Active Directory サービスとディレクトリ構造の所有者をフォレストまたはドメイン インフラストラクチャに参加させる前に、対象となるフォレストおよび全ドメインのすべてのサービス管理者が信頼できることを確認する必要があります。また企業のセキュリティ プログラムとして、管理者に適性チェックを行う際の標準のポリシーおよび手順を作成する必要があります。このセキュリティ ガイドでは、サービス管理者を信頼するとは、以下のことを意味します。

組織によっては、危険性のある管理者や不正を強いられた管理者が組織内の別のセクションに存在し、それらの管理者によるセキュリティ侵害が予想される場合でも、こうしたリスクを容認することがあります。このような組織では、共有インフラストラクチャがもたらすコラボレーション環境とコスト削減効果が、それに伴うリスクよりも重要であると判断しています。一方、セキュリティ侵害が重大な結果を招く可能性があることから、そうしたリスクを容認しない組織もあります。

Active Directory とグループ ポリシー

OU を使用すると、コンピュータ、ユーザー、グループ、およびその他のセキュリティ プリンシパルを簡単にグループ化できると同時に、管理境界を効率的に分割できます。OU はグループ ポリシー オブジェクト (GPO) を展開するうえで基礎的な構造となります。GPO を使用すると、セキュリティのニーズ別にリソースを分割し、OU ごとに異なるセキュリティを実現できます。OU を使用して、セキュリティ ポリシーをサーバーの役割に基づいて管理し割り当てることは、組織の全体的なセキュリティ アーキテクチャに欠かせない要素です。

管理の委任とグループ ポリシーの適用

OU は、ドメインのディレクトリ構造内のコンテナです。このコンテナには、ドメイン内の任意のセキュリティ プリンシパルを保持できますが、通常は、特定の種類のオブジェクトの保持に使用します。グループまたは個々のユーザーに対する OU アクセス許可の付与または削除を行うために、目的の OU 専用のアクセス制御リスト (ACL) を設定して、アクセス許可を OU 内のすべてのオブジェクトに継承します。

OU を使用することで、役割ベースの管理機能を実現できます。たとえば、ある管理者グループがユーザーとグループの OU を担当し、別のグループがサーバーを含む OU の管理を担当することなどが可能です。また、制御を委任するプロセスを通じて、他のユーザーが管理するリソース サーバー グループの OU を作成することもできます。このようにすると、委任されたグループは、特定の OU に対する制御が自律的になりますが、ドメインの残りの部分から分離はされません。

通常、各 OU の管理を委任するのはサービス管理者です。サービス管理者よりも低い権限で各 OU を管理するユーザーはデータ管理者です。

管理グループ

管理者は、管理グループを作成して、ユーザー、セキュリティ グループ、またはサーバーのクラスタをコンテナに分配し、それらを自律的に管理できます。

たとえば、ドメイン内に配置されているインフラストラクチャ サーバーの場合を考えてみましょう。インフラストラクチャ サーバーには、WINS サービスや DHCP サービスなどの基本的なネットワーク サービスを実行する、ドメイン コントローラ以外のすべてのサーバーが含まれます。通常は、運用グループまたはインフラストラクチャ管理グループがこれらのサーバーを管理します。OU を使用すると、これらのサーバーに管理機能を簡単に提供できます。

次の図は、このような OU 構成の概要を示しています。

図 2.1 組織単位の管理の委任

Infrastructure Admin グループがインフラストラクチャの管理を委任された場合、このグループのメンバには、そのインフラストラクチャ OU とその OU 内のすべてのサーバーおよびオブジェクトのフル コントロールが与えられます。これにより、このグループのメンバは、グループ ポリシーを使用してサーバーの役割のセキュリティを保護できます。

これは、OU を使用して管理を分割する唯一の方法です。より複雑な組織での管理の委任については、この章の最後の「関連情報」に記載されている情報を参照してください。

注 :Active Directory は DNS に大きく依存しているので、DNS サービスはドメイン コントローラ上で実行するのが一般的です。ドメイン コントローラは、既定で、ビルトイン ドメイン コントローラ OU に配置されています。このガイドでの例もこれに従っているので、インフラストラクチャ サーバーの役割は DNS サービスには含まれていません。

グループ ポリシーの適用

特定の設定、権利、および動作を OU 内のすべてのサーバーに適用するには、グループ ポリシーを使用して、管理を委任します。手動で操作する代わりにグループ ポリシーを使用すると、将来変更が必要になった場合でも、複数のサーバーを簡単に更新できます。

グループ ポリシーは階層構造になっており、次の図に示す順序で適用されます。

図 2.2 GPO 適用の階層構造
画像を画面全体に表示

上図のとおりに、ポリシーはまずコンピュータのローカル レベルのポリシーに適用されます。その後、サイト レベル、ドメイン レベルの順序で GPO が適用されます。サーバーが複数の OU にネストされている場合は、最上位レベルの OU の GPO が最初に適用されます。さらに、OU 階層の上位から下位に向かって GPO が順に適用されます。最後に、サーバー オブジェクトが格納されている子 OU レベルに最後の GPO が適用されます。グループ ポリシーの処理は、最上位の OU (ユーザー アカウントまたはコンピュータ アカウントから最も離れた OU) から最下位の OU (ユーザー アカウントまたはコンピュータ アカウントが格納されている OU) へという順序で実行されます。

グループ ポリシーを適用する際には、以下の基本的な考慮事項に注意してください。

時刻の構成

多くのセキュリティ サービス、特に認証は、ジョブの実行にコンピュータのクロックの正確さに依存しています。コンピュータの時刻が正確であり、組織内のすべてのサーバーが同じタイム ソースを使用していることを確認する必要があります。Windows Server 2003 W32Time サービスは、Active Directory ドメインを実行している Windows Server 2003 コンピュータと Microsoft Windows XP ベースのコンピュータの時刻を同期します。

W32Time サービスは、Windows Server 2003 ベースのコンピュータのクロックをドメイン内のドメイン コントローラと同期します。この同期は、Kerberos プロトコルなど認証プロトコルが正常に動作するのに必要です。正常に機能させるためには、すべての Windows Server ファミリ コンポーネントが、同期されている正確な時刻に基づいて動作している必要があります。クライアントのクロックが同期されていない場合には、Kerberos 認証プロトコルによりユーザーに対するアクセスが拒否されることがあります。

時刻の同期によるもう 1 つの重要な利点は、企業内すべてのクライアントでイベントを関連付けられることです。環境内でクライアントのクロックが同期されていると、組織内のクライアント上で決まった順番で発生するイベントを正しく分析できます。

W32Time サービスは、Network Time Protocol (NTP) を使用して、Windows Server 2003 を実行しているコンピュータのクロックを同期します。Windows Server 2003 フォレストの場合、時刻は既定で次の方法で同期されます。

時刻を正確に設定するため、フォレスト ルート ドメインの PDC エミュレータは、信頼できる NTP ソースやネットワーク内に存在する精度の高いクロックなどの信頼性の高いタイム ソースと同期できます。NTP 同期では、UDP ポート 123 トラフィックが使用されます。外部のサーバーと同期する前に、このポートを開くことによって獲得する利点と潜在的なセキュリティ リスクのどちらを重要視するか検討してください。

また、制御対象でない外部サーバーと同期した場合には、サーバーに不正確な時間を設定するリスクを負うことになります。外部サーバーが攻撃者により悪用または偽装され、コンピュータのクロックを不正に操作される可能性があります。前述のように、Kerberos 認証プロトコルでは、コンピュータのクロックが同期されていることが前提となっています。同期されていない場合、サービス拒否が発生することがあります。

セキュリティ テンプレートの管理

セキュリティ テンプレートはテキスト ベースのファイルで、セキュリティ構成をコンピュータに適用する際に使用できます。セキュリティ テンプレートの変更には、Microsoft 管理コンソール (MMC) の [セキュリティ テンプレート] スナップイン、またはメモ帳などのテキスト エディタを使用できます。テンプレート ファイルの一部のセクションには、セキュリティ記述子定義言語 (SDDL) で記述された固有の ACL が含まれています。セキュリティ テンプレートおよび SDDL の編集については、Microsoft MSDN® (http://msdn2.microsoft.com/en-us/library/aa379567.aspx) の「Security Descriptor Definition Language」ページ (英語情報) を参照してください。

既定では、グループ ポリシー オブジェクト内の設定すべての読み取り許可が認証ユーザーに与えられます。したがって、運用環境で使用するセキュリティ テンプレートは、グループ ポリシーを実装する管理者だけがアクセスできる安全な場所に保管しておく必要があります。目的は、*.inf ファイルを表示できないようにすることではなく、オリジナルのセキュリティ テンプレートが不正に変更されるのを防ぐことにあります。

Windows Server 2003 を実行しているすべてのコンピュータのローカルの %SystemRoot%\security\templates フォルダに、セキュリティ テンプレートが格納されています。このフォルダはドメイン コントローラ間で複製されないので、セキュリティ テンプレートのマスタ コピーを格納する場所を 1 箇所決めて、テンプレートのバージョン管理に問題が発生しないようにする必要があります。一元管理されているテンプレートを変更したら、それを該当するコンピュータに再展開します。こうすることによって、修正対象が常にテンプレートのマスタ コピーになります。

GPO 適用成功イベント

管理者は、すべての設定を手動でチェックすることで、設定が組織内のサーバーに正しく適用されていることを確認できますが、イベント ログに記録されたイベントを参照することによって、ドメイン ポリシーが各サーバーに正常にダウンロードされたことを確認できます。アプリケーション ログには、以下のようなイベント情報が一意なイベント ID 番号と共に表示されます。

種類 :情報

ソース ID:SceCli

イベント ID:1704

説明 :グループ ポリシー オブジェクトのセキュリティ ポリシーは正しく適用されました。

既定では、ワークステーションまたはサーバー上ではセキュリティ設定が 90 分ごとに更新され、ドメイン コントローラ上では 5 分ごとに更新されます。この時間内にセキュリティ設定が変更された場合に、このようなイベントが発生します。また、新たな変更があったかどうかにかかわらず、セキュリティ設定は 16 時間ごとに更新されます。この章で後述する手順を使用して、手動でグループ ポリシー設定の更新を強制することもできます。

サーバーの役割組織単位

前述の例では、組織のインフラストラクチャ サーバーを管理する方法について説明しました。この方法を拡張して、組織内の他のサーバーおよびサービスも管理することができます。目的は、すべてのサーバーを対象とするシームレスなグループ ポリシーを作成し、Active Directory 内に配置されているサーバーがその環境のセキュリティ基準を満たすようにすることです。

この種類のグループ ポリシーは、組織内のすべてのサーバーに対する標準設定の一貫性のあるベースラインを形成します。また、OU 構造を作成し、グループ ポリシーを適用することによって、組織内のサーバーの種類ごとに必要なセキュリティを設定します。たとえば、独自のグループ ポリシーが必要となるサーバーの役割としては、インターネット インフォメーション サーバー (IIS)、ファイル サーバー、プリント サーバー、インターネット認証サーバー (IAS)、証明書サービス サーバーなどがあります。

重要 :わかりやすくなるように、この章の例ではエンタープライズ クライアント環境の使用を想定して説明します。他の 2 つの環境のいずれかを使用する場合は、ファイル名を適宜読み替えてください。この 3 種類の環境とそれぞれの機能の違いについては、「第 1 章 Windows Server 2003 セキュリティ ガイドの概要」を参照してください。

メンバ サーバー ベースライン ポリシー

サーバーの役割 OU を作成するには、最初にベースライン ポリシーを作成します。ベースライン ポリシーを作成するには、SCW を標準メンバ サーバーで使用して、Member Servers Baseline.xml ファイルを作成します。XML の作成において、SCW を使用して、提供されている Member Server Baseline セキュリティ テンプレートのどれか (LC-Member Server Baseline.inf、EC-Member Server Baseline.inf、または SSLF-Member Server Baseline.inf) を含めます。

SCW ポリシーは生成後に GPO に変換され、メンバ サーバー OU にリンクされます。この新しいベースライン GPO により、ベースライン グループ ポリシーの設定が、メンバ サーバー OU および子 OU 内のすべてのサーバーに適用されます。メンバ サーバー ベースライン ポリシーの詳細については、「第 4 章 メンバ サーバー ベースライン ポリシー」を参照してください。

組織内のほとんどのサーバーに必要な設定は、ベースライン グループ ポリシーに定義してください。ベースライン ポリシーを受信する必要がないサーバーが存在する場合もありますが、多くはありません。独自のベースライン グループ ポリシーを作成する場合は、できるだけ制限を厳しくし、そのポリシー以外のポリシーを必要とするサーバーは別のサーバー専用 OU に分けてください。

サーバーの役割の種類と組織単位

個々のサーバーの役割には、ベースライン OU の他に、SCW ポリシー、セキュリティ テンプレート、および OU を追加する必要があります。この方法を採用することによって、各役割に必要となった変更分だけのポリシーを個別に作成できるようになります。

前述の例では、インフラストラクチャ サーバーを、メンバ サーバー OU の子であるインフラストラクチャ OU に配置しています。次の手順では、これらのサーバーに適切な構成を適用します。このソリューションには、セキュリティ環境ごとにセキュリティ テンプレート (LC-Infrastructure Server.inf、EC-Infrastructure Server.inf、SSLF-Infrastructure Server.inf) が用意されています。これらのセキュリティ テンプレートを SCW と組み合わせて使用することで、DHCP および WINS のそれぞれに必要な調整を含むセキュリティ ポリシーを作成できます。組み合わせたポリシーは、新しい GPO に変換され、インフラストラクチャ OU にリンクされます。

この GPO では、[制限されたグループ] 設定が使用され、インフラストラクチャ OU の全サーバーの Local Administrators グループに次の 3 つのグループが追加されます。

この章で前述したように、この方法は GPO の展開に使用できる OU 構造を作成する数多くの方法の 1 つです。グループ ポリシーの実装に使用する OU の作成については、「Designing the Active Directory Structure」 (英語情報) および http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgbd_ads_heqs.mspx?mfr=true の関連トピック (英語情報) を参照してください。

次の表は、Windows Server 2003 のサーバーの役割と、このガイドで定義されている対応するテンプレート ファイルの一覧です。セキュリティ テンプレート ファイル名には接頭辞として <Env> 変数が付加されており、必要に応じて LC (レガシ クライアント)、EC (エンタープライズ クライアント)、または SSLF (セキュリティ強化 – 機能制限) に置き換えてください。

表 2.1 Windows Server 2003 のサーバーの役割

要塞ホスト サーバー用を除き、テンプレート ファイルはすべて、対応する子 OU に適用されます。これらの子 OU ごとに、特定の構成を適用して、組織内の各コンピュータが果たす役割を定義する必要があります。

セキュリティ要件はサーバーの役割によって異なります。それぞれの役割に適したセキュリティ設定については、後述の章で詳しく説明します。役割によっては、テンプレートが用意されていない環境があります。たとえば、要塞ホストの役割は、SSLF 環境内に存在すると常に見なされます。

重要 :このガイドでは、Windows Server 2003 を実行しているコンピュータが、それぞれ固有に定義された役割を実行することを前提としています。組織内のサーバーがここで説明している役割に適合していない場合、または多目的サーバーを設置している場合は、ここで定義されている設定を参考にして、独自のセキュリティ テンプレートを作成してください。その際、サーバーで実行する機能が多くなるほど、攻撃に弱くなることに注意してください。

次の図は、EC 環境で定義されたサーバーの役割をサポートするための最終的な OU 設計を示しています。

図 2.3 OU 設計の例
画像を画面全体に表示

OU、GPO、およびグループの設計

前のセクションで説明した推奨の OU およびグループ ポリシーを使用すると、Windows Server 2003 を実行しているコンピュータを対象とする、組織の既存 OU の構造を変えるベースラインの環境または新しい環境が作成されます。管理者は、事前定義された管理境界を使用して、対応する管理グループを作成します。次の表は、これらのグループとその管理対象である OU との関係の例を示しています。

表 2.2 OU と管理グループ

各管理グループは、ドメイン内のグローバル グループとして、Active Directory のインフラストラクチャとセキュリティを担当する Domain Engineering メンバによって作成されます。Domain Engineering メンバは、対応する GPO を使用して、各管理グループを適切な制限されたグループに追加できます。上の表に一覧されている管理グループがメンバになるのは、各業務に関連するコンピュータが属する OU に配置されているコンピュータの Local Administrators グループだけです。

最後に、Domain Engineering メンバは、Domain Engineering グループの管理者だけが編集できるようなアクセス許可を各 GPO に設定します。

これらのグループの作成と構成は、Active Directory の設計および実装全体としてのプロセスの一部であることに注意してください。これについては、このガイドの範囲外です。

ページのトップへ

プロセスの概要

このガイドでは、SCW ベースの方法とグループ ポリシー ベースの方法の強みを組み合わせます。方法を組み合わせることで、セキュリティ構成の作成とテストが簡単になり、大規模な Windows ネットワークに必要な柔軟性と拡張性も提供されます。

ポリシーの作成、テスト、および展開のプロセスは次のとおりです。

各手順の詳細については、以降で説明します。

注 :わかりやすくなるように、このセクションの例ではエンタープライズ クライアント (EC) 環境の使用を想定して説明します。他の 2 つの環境のいずれかを使用する場合は、ファイル名を適宜読み替えてください。この 3 種類の環境とそれぞれの機能の違いについては、「第 1 章 Windows Server 2003 セキュリティ ガイドの概要」を参照してください。

Active Directory 環境を作成する

セキュリティ強化プロセスを開始する前に、適切な Active Directory ドメインと OU 構造が編成されている必要があります。次に示す手順に従って、このガイドで使用する OU とグループを作成し、適切な管理アクセスを構成します。

時刻の同期を構成する

ドメイン コントローラとメンバ サーバーを外部タイム ソースと同期させるには、次の手順に従います。同期させることにより、Kerberos 認証が正常に動作し、Active Directory ドメインと外部コンピュータとの同期を維持できるようになります。

w32tm /config /syncfromflags:manual /manualpeerlist:<PeerList>

w32tm /config /update

このプロシージャの最も一般的な用途は、内部ネットワークの信頼できるタイム ソースと、外部の正確なタイム ソースとの同期です。この手順は、Windows XP、または Windows Server 2003 ファミリのメンバを実行しているコンピュータでも実施できます。すべてのサーバーのクロックが同一の内部ソースと同期している場合には、外部ソースと同期する必要は通常ありません。既定では、メンバ コンピュータのクロックは常にドメイン コントローラと同期します。

注 :ログを正確に分析するには、Windows 以外のオペレーティング システムを実行しているネットワーク コンピュータのクロックも、Windows Server 2003 PDC エミュレータまたはそのサーバーの同一タイム ソースに同期する必要があります。

ドメイン ポリシーを構成する

次の手順に従って、ドメイン レベルのポリシー用としてこのガイドに付属しているセキュリティ テンプレートをインポートします。このポリシーがセキュリティ テンプレートとして用意されているのは、SCW がドメイン レベルのポリシーに対応していないからです。次の手順を実行する前に、指定のポリシー ファイル (.inf) をコンピュータ上に用意しておく必要があります。

警告 :このガイドのセキュリティ テンプレートは、環境内のセキュリティを強化することを目的に設計されています。インストールすることにより、環境の一部の機能が失われたり、基幹アプリケーションに障害が発生する可能性があります。

したがって、運用環境に展開する前に、設定を十分テストすることが不可欠となります。新しいセキュリティ設定を適用する前に、環境内のすべてのドメイン コントローラとサーバーのバックアップを作成してください。その際、システム状態も含めてバックアップを作成し、必要に応じてレジストリ設定やとActive Directory オブジェクトを復元できるようにしてください。

ドメイン ポリシーのセキュリティ テンプレートをインポートするには

警告 :EC-Domain Policy を作成する場合は、[上書き禁止] オプションを必ず有効にして、このポリシーがドメイン全体で実行されるようにしてください。このガイドで [上書き禁止] オプションを有効にする必要があるのは、このグループ ポリシーだけです。このガイドで指定されているその他のグループ ポリシーでは、[上書き禁止] オプションを有効にしないでください。また、既定の設定に戻す必要が生じた場合に備え、Windows Server 2003 の既定のドメイン ポリシーは変更しないでください。

既定のポリシーより優先されるようにするため、この新しいポリシーは GPO リンクの一番上に配置してください。

重要 :このグループ ポリシーを組織内のすべての追加ドメインにインポートして、パスワード ポリシーが一貫して適用されるようにしてください。ただし、環境によっては、ルート ドメインに他のドメインより厳しいパスワード ポリシーが設定されている場合があります。同じポリシーを使用する他のすべてのドメインについて、ビジネス要件が同じかどうかを確認してください。パスワード ポリシーはドメイン レベルでしか設定できないため、特定のグループにより厳密なパスワード ポリシーを適用するためだけに一部のユーザーを別のドメインに分離する、ビジネスまたは法律上の要件が存在する場合があります。

継承可能なアクセス許可のオプションをオフするには

既定では、新しい OU 構造は、その親コンテナから多くのセキュリティ設定を継承します。各OU の [親からの継承可能なアクセス許可をこのオブジェクトと子オブジェクトすべてに伝達できるようにし、それらをここで明示的に定義されているものに含める] チェック ボックスをオフにします。

管理者が以前に追加した不要なグループを削除し、各サーバーの役割 OU に対応するドメイン グループを追加します。Domain Administrators グループの [フル コントロール] 設定は変更しません。

ベースライン ポリシーを SCW を使用して手動で作成する

次の手順に従って、SCW を使用して、メンバ サーバー ベースライン ポリシーを作成します。

構成作業を始める際には、オペレーティング システムの新規インストールを使用することをお勧めします。こうすることにより、以前の構成の古い設定やソフトウェアが残っていないことが保証されます。可能であれば、展開に使用するものと同様のハードウェアを使用することをお勧めします。これにより、互換性が向上します。このような新規インストールを参照コンピュータと呼びます。

メンバ サーバー ベースライン ポリシー (MSBP) の作成手順で、検出された役割の一覧からファイル サーバーの役割を削除することに注意してください。この役割は、それを必要としないサーバーに構成されていることが多く、セキュリティ リスクになる可能性があります。ファイル サーバーの役割が必要なサーバーでそれを有効にするには、このプロセスの後半で別のポリシーを適用します。

メンバ サーバー ベースライン ポリシーを作成するには

ドメイン コントローラのポリシーを作成するには

ドメイン コントローラのポリシーを作成するには、ドメイン コントローラとして構成されているコンピュータを使用する必要があります。既存のドメイン コントローラを使用するか、参照コンピュータを作成し Dcpromo を使用してそのコンピュータをドメイン コントローラにします。ただし、セキュリティ ポリシーに違反する可能性があるため、ほとんどの組織では、ドメイン コントローラを運用環境に追加するとことは望ましくありません。既存のドメイン コントローラを使用する場合、SCW を使用して設定を適用したり、構成を変更したりしないよう、十分注意してください。

ベースライン ポリシーを SCW を使用してテストする

ベースライン ポリシーを作成したら、テスト環境に展開することを強くお勧めします。テスト サーバーが運用サーバーと同じハードウェアおよびソフトウェア構成であることが理想的です。こうすることで、特定のハードウェア デバイスに予期しないサービスが必要になった場合などの、潜在的な問題を検出して解決できるようになります。

ポリシーのテストには、2 つの方法があります。SCW 独自の展開機能を使用する方法と、GPO を使用してポリシーを展開する方法です。

ポリシーの作成をこれから始める場合には、SCW 独自の展開機能を使用することを検討してください。SCW を使用して、ポリシーをサーバーごとにプッシュするか、Scwcmd を使用してポリシーをサーバーのグループにプッシュします。この展開方法には、SCW から展開したポリシーを簡単にロールバックできるという利点があります。この機能は、テスト プロセスでポリシーの変更を複数行う場合に便利です。

ポリシーをテストする目的は、対象サーバーにポリシーを適用したことにより重要な機能に悪影響が及ばないことを確認することです。構成の変更を適用したら、コンピュータの主要な機能を検証する必要あります。たとえば、証明機関 (CA) として構成されているサーバーの場合は、クライアントが証明書を要求して取得できること、証明書失効リストをダウンロードできることなどを確認します。

ポリシーの構成に問題がないことを確認したら、次に示す手順に従って、Scwcmd を使用して、ポリシーを GPO に変換します。

SCW ポリシーのテストの詳細については、http://technet2.microsoft.com/windowsserver/en/library/5254f8cd-143e-4559-a299-9c723b3669461033.mspx の「Deployment Guide for the Security Configuration Wizard」(英語情報) および http://go.microsoft.com/fwlink/?linkid=43450 の「Security Configuration Wizard Documentation」(英語情報) のダウンロード バージョンを参照してください。

ベースライン ポリシーを GPO に変換する

ベースライン ポリシーのテストが完了したら、次の手順に従って、ベースライン ポリシーを GPO に変換し、適切な OU にリンクします。

scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName>

scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Infrastructure.xml" /g:"Infrastructure Policy"

SCW セキュリティ ポリシー ファイルに Windows ファイアウォールの設定が含まれている場合、この手順を正常に完了するには、ローカル コンピュータで Windows ファイアウォールが有効になっている必要があります。Windows ファイアウォールが有効であることを確認するには、[コントロール パネル] を開き、[Windows ファイアウォール] をダブルクリックします。

次に、最後のテストを実行して、GPO により意図した設定が適用されることを確認します。この手順を完了させるために、設定が適切であること、機能がその影響を受けないことを確認します。

SCW を使用して役割ポリシーを作成する

次の手順に従って、SCW を使用して、サーバーの役割ごとに役割ポリシーを作成します。

役割ごとのポリシーを作成する手順は、MSBP を作成したときの手順と同様です。ここでも、参照コンピュータを使用して、以前の構成の設定やソフトウェアが残っていないことを確認します。

役割ポリシーを作成するには

SCW を使用して役割ポリシーをテストする

ベースライン ポリシーの場合と同様、ポリシーのテストにも 2 つの方法があります。SCW 独自の展開機能を使用する方法と、GPO を使用してポリシーを展開する方法です。ここでも、役割ポリシーを運用環境で使用する前に、テスト環境に展開することを強くお勧めします。そうすることで、運用環境のダウンタイムとエラーを最小限に抑えることに役立ちます。新しい構成のテストが完了したら、次の手順に従って、ポリシーを GPO に変換し、適切な OU に適用します。

役割ポリシーを GPO に変換する

役割ポリシーのテストが完了したら、次の手順に従って、役割ポリシーを GPO に変換し、適切な OU にリンクします。

scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName>

scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Infrastructure.xml" /g:"Infrastructure Policy"

SCW セキュリティ ポリシー ファイルに Windows ファイアウォールの設定が含まれている場合、この手順を正常に完了するには、ローカル コンピュータで Windows ファイアウォールが有効になっている必要があります。Windows ファイアウォールが有効であることを確認するには、[コントロール パネル] を開き、[Windows ファイアウォール] をダブルクリックします。

ページのトップへ

まとめ

セキュリティ管理者は、担当する環境に適した方法を選択できるように、従来のポリシー ベースのセキュリティ強化方法と比較したときの SCW の長所と欠点を把握しておく必要があります。SCW とグループ ポリシーを組み合わせて使用することで、SCW で一貫性のあるポリシーのプロトタイプを迅速に作成できるようになります。また、SCW のグループ ポリシーの展開機能と管理機能の拡張性が高くなります。

環境のセキュリティ向上を目的としてフォレスト、ドメイン、および OU の設計を見直す上で、設計上の考慮事項がいくつかあります。

まず、組織内での独立化要件および分離要件を調査し、それらを文書としてまとめることが重要です。複雑なフォレスト設計では、管理上の自治単位、運用上の分離、法律や規制に関する分離などを検討する必要があります。

サービス管理者を管理する方法を理解することが重要です。悪意のあるサービス管理者は、組織を大きな危険にさらす可能性があります。下位レベルで、悪意のあるドメイン管理者は、フォレストのすべてのドメインのデータにアクセスできます。

組織のフォレスト設計やドメイン設計を変更するのは簡単ではありませんが、セキュリティ リスクには対処しなければなりません。また、組織に OU を展開するときに、サービス管理者やデータ管理者のニーズに対応できるよう計画することが重要です。この章では、組織内のさまざまなサーバーの役割を継続的に管理することを目的とした、GPO の使用をサポートする OU モデルの作成方法について詳しく説明しました。

関連情報

Windows Server 2003 SP1 を実行するサーバーのセキュリティ強化に関する詳細情報は、以下のリンクから参照できます。

ページのトップへ

3 of 19