トピック概要『Windows Server 2003 セキュリティ ガイド』は、さまざまな環境で Microsoft® Windows Server™ 2003 Service Pack 1 (SP1) を実行するコンピュータのセキュリティを強化することを目的とした、検証済みで繰り返し利用できる設定ガイダンスとなるよう構成されています。 『Windows Server 2003 セキュリティ ガイド』は、ラボ環境でのテストを通じて、ガイダンスに従うことで目的の効果が得られることが確認されました。『Windows Server 2003 セキュリティ ガイド』のテスト チームにより、この文書の整合性が確認され、すべての推奨手順がテストされています。テストは機能の検証を目的として実施されましたが、このガイドを使用して独自の実装を構築してテストする場合に必要なリソースを減らすことにも貢献しています。 範囲『Windows Server 2003 セキュリティ ガイド』は、レガシ クライアント (LC)、エンタープライズ クライアント (EC)、セキュリティ強化 – 機能制限 (SSLF) の 3 つの異なるセキュリティ環境をシミュレーションするラボ環境でテストされました。各環境については、「第 1 章 Windows Server 2003 セキュリティ ガイドの概要」を参照してください。テストは、後述の「テストの目的」で説明する基準に基づいて実施されました。 『Windows Server 2003 セキュリティ ガイド』のソリューションのセキュリティ保護に使用されたテスト ラボ環境の脆弱性調査は、テスト チームによるテストの対象にはなっていません。 テストの目的『Windows Server 2003 セキュリティ ガイド』テスト チームによるテストの目的は次のとおりです。 | • | このガイドで定義されている 3 つのセキュリティ レベルでのセキュリティ設定の推奨変更の検証。変更理由は次のとおりです。 | • | Windows Server 2003 の SP1 のリリースに伴う変更。 | | • | SP1 で新たに導入されたセキュリティの構成ウィザード (SCW) ツール、および Windows ファイアウォールなどの新機能の使用。 | | • | 旧版のガイドに対する内外からのフィードバック。 |
| | • | このガイドで推奨しているセキュリティ設定や構成変更が、LC、EC、および SSLF 環境の要件を満たしていることの確認。 | | • | 強化されたドメイン メンバ サーバーが、それぞれの役割のタスクを正常に実行できることの確認。 | | • | クライアント コンピュータとドメイン コントローラとの通信に悪影響がないことの確認。 | | • | 手順に関するすべてのガイダンスが明解、完全、かつ技術的に正しいことの確認。 |
このガイダンスの最終的な目的は、2 年以上の実務経験を持つ Microsoft Certified Systems Engineer (MSCE) が繰り返し、確実に使用できることです。 テスト環境このガイドをテストするために開発されたテスト ラボ ネットワークは、このガイドの旧版で使用されたものと同様です。3 つの独立した類似ネットワークが、定義されたそれぞれの環境に応じて開発されました。 各テスト ネットワークは、Windows Server 2003 SP1 Active Directory® ディレクトリ サービス フォレスト、ドメイン コントローラ、DNS、WINS サービス、および DHCP サービスを提供するインフラストラクチャ サーバーの役割のコンピュータ、ファイル、プリント、Web の各サービスを提供するアプリケーション サーバーの役割のコンピュータで構成されました。EC ネットワークには、証明書サービス サーバーの役割と IAS サーバーの役割のコンピュータが接続され、SSLF ネットワークには、要塞ホスト (BH) サーバーの役割のコンピュータが接続されました。また、EC ネットワークと SSLF ネットワークには、Microsoft Operations Manager (MOM) 2005 および Systems Management Server (SMS) 2003 が含まれており、ドメイン メンバ サーバーとクライアント コンピュータを管理および監視しました。これらのネットワークには、電子メール サービス用に Microsoft Exchange Server 2003 も含まれました。 別のネットワークに存在するクライアント コンピュータには、Windows XP Professional SP2 と Windows 2000 Professional SP4 が使用されました。LC ネットワークには、Windows 98 SR2 や Windows NT® 4.0 workstation SP6a オペレーティング システムを実行するクライアント コンピュータも接続されました。 次の図に、EC 環境用に開発されたテスト ラボ ネットワークを示します。 強化されたドメイン コントローラ間でのレプリケーションの状況を確認するため、Active Directory フォレストは 2 つのサイトで構成されました。片方はメイン オフィス サイトで、空のルート ドメインと前述のサーバーおよびクライアント コンピュータで構成される子ドメインとで構成されました。もう片方のサイトは、子ドメインの別のドメイン コントローラが 1 台あるだけです。 次の図に、SSLF 環境用に開発されたテスト ラボ ネットワークを示します。 テスト方法ここでは、『Windows Server 2003 セキュリティ ガイド』をテストするために実施された手順について説明します。 テスト チームは、前述の 3 つのネットワークを装備したラボを設置しました。最初に簡単な機能検証 (POC) テスト パスを 1 回行い、次により堅牢なテスト サイクルを 2 回行いました。各テストでは、ソリューションを安定させることを目指しました。 テスト サイクルは、次の フェーズの連続として定義されました。 1. | セキュリティ構成構築フェーズ | • | 手動構成フェーズ | | • | グループ ポリシー構成フェーズ |
| 2. | テスト実行フェーズ |
各フェーズの詳細については、次の「テスト パスのフェーズ」で説明します。「テスト準備フェーズ」では、3 つの環境が最初の 2 つの段階的な構築フェーズにより強化された後に、実際のテスト結果の解釈に誤解が生じる可能性のある問題がラボ環境にないことを保証するために実行された手順について説明します。これは、「ベースライン」状態とも呼ばれます。 テスト パスのフェーズここでは、テスト パスの各フェーズについて説明します。テスト チームは、構築フェーズで見つかった重要な問題をすべてバグと認識し、そのフェーズで問題を解決してから、テスト実行フェーズに移行しました。これにより、適切なセキュリティ構成がネットワークに実装されていることが保証され、得られるテスト結果が正確であることが検証されました。 テスト準備フェーズこのフェーズでは、セキュリティ構成構築フェーズでソリューションに適用されるベースライン構成を設定しました。LC、EC、SSLF の 3 つの環境それぞれに、次の手順が実行されました。 テスト準備フェーズを実行するには 1. | ネットワーク図に示されているとおりにコンピュータを接続し、すべてのサーバーおよびクライアント コンピュータに適切なバージョンの Windows オペレーティング システムをインストールします。 | 2. | ドメイン、ドメイン コントローラ、および 2 つのサイトを作成し、構成します。 | 3. | 各メンバ サーバーと管理サーバーを参加させ、構成します。また、クライアント コンピュータをドメインに参加させます。 | 4. | 各サーバーの役割に関する簡単な検証テストを実施し、ネットワークとアプリケーションの構成が適切であることを確認します。 | 5. | ネットワークの各メンバ サーバーのイベント ログを確認し、アプリケーションまたはシステム レベルにエラーがないことを確認します。 | 6. | クライアント コンピュータから、ドメイン コントローラおよびメンバ サーバーが提供するサービス (DNS、DHCP、CA、ファイル、印刷、Web、および電子メール) にアクセスできるようにします。クライアント コンピュータのイベント ログを確認し、エラーがないことを確認します。 | 7. | 必要なすべてのアプリケーション、サービス、およびエージェントが各ドメイン メンバにインストールされていることを確認します。たとえば、MOM サーバーが管理するすべてのサーバーに MOM エージェントがインストールされていることを確認します。 | 8. | 上記の手順が完了したら、各コンピュータのイメージ バックアップを作成します。このバックアップ イメージは、テスト パスを新たに開始する際に、ネットワークをベースライン構成にロールバックするために使用します。 |
セキュリティ構成構築フェーズこのフェーズの目的は、このガイドの手順に従ってドメイン、ドメイン コントローラ、およびメンバ サーバーを構成し、ベースライン構成よりセキュリティ レベルを上げることです。 手動構成フェーズこのフェーズは通常、最初のセキュリティ構築フェーズになります。各章で説明している手動による推奨強化がこのフェーズで実施されます。 注 :現実のネットワークでは、手順の一部を適用できたりできなかったりすることが考えられます。各手順を慎重に検討し、対象となるネットワークに対する影響を把握してください。 構成フェーズで手動で実行するには 1. | Microsoft 管理コンソール (MMC) の [コンピュータの管理] スナップインを使用して、各メンバ コンピュータに規定されているポリシー設定 (ローカル管理者アカウントとパスワードなど) を変更します。次の手順を実行して、ドメイン アカウントをセキュリティ保護します。 1. | ビルトイン ローカル Administrator アカウントについて、パスワードが複雑であること、アカウント名が変更されていること、および既定のアカウントの説明が削除されていることを確認します。 | 2. | ホストで Guest アカウントの名前を変更し、無効にします。 | 3. | ドメイン アカウントのセキュリティを高める方法としてガイドでこの他に推奨されている事項を実施します。 |
| 2. | 該当する章で説明しているように、ユーザー権利の設定に一意のセキュリティ グループまたはアカウントを追加します。 | 3. | 各章で規定されている、該当する他のすべての手動によるセキュリティ強化手順を実行します。たとえば、手動メモリ ダンプやエラー レポートの構成を有効にします。 |
グループ ポリシー構成フェーズこのフェーズの目的は、グループ ポリシー オブジェクト (GPO) をドメインおよび組織単位 (OU) レベルで作成し、適用することです。GPO は、「第 2 章 Windows Server 2003 のセキュリティ強化メカニズム」での推奨に基づいて、さまざまな OU に適用します。 Windows Server 2003 の Service Pack 1 には新しいツールと機能が導入されており、グループ ポリシー実装設計が以前のバージョンから変更されています。 SCW は攻撃の対象領域を小さくするツールで、このガイドで説明しているサーバーの役割ごとに、必要なセキュリティ ポリシーのセットを作成するために使用します。SCW の導入により、グループ ポリシー構成フェーズに次の 2 つの大きな変更が生じました。 | • | このガイドの旧版で提供されている IPsec フィルタは、SCW で作成された Windows ファイアウォール ポート構成に置き換えられました。 | | • | このガイドに付属するセキュリティ テンプレートを SCW と組み合わせて使用することで、XML セキュリティ テンプレート ファイルを作成できます。作成したテンプレートは、Scwcmd コマンド ライン ツールを使用して、対応する GPO に変換します。 |
次の手順は、3 つのセキュリティ環境ごとに実施されました。 グループ ポリシー オブジェクトを作成するには 1. | 必要なすべてのアプリケーション、サービス、およびエージェントがベースライン ネットワークの各ドメイン メンバにインストールされていることを確認します。たとえば、MOM が管理するすべてのドメイン メンバ サーバーに MOM エージェントがインストールされていることを確認します。 | 2. | MMC の [Active Directory ユーザーとコンピュータ] スナップインを使用して、記述されている OU 構造を作成します。 | 3. | Domain Policy GPO を .inf セキュリティ テンプレートを使用して作成します。この手順で SCW を使用する必要はありません。 | 4. | SCW ツールを使用して、このガイドに記載されているサーバーの役割ごとに、XML ベースのセキュリティ テンプレートを作成します。規範的な手順については、「第 2 章 Windows Server 2003 の強化メカニズム」と各サーバーの役割に関する章を参照してください。この手順を実行する際、サーバーの役割に適した .inf セキュリティ テンプレートを使用してください。テンプレート ファイルは、このガイドのダウンロード バージョンに付属しています。 | 5. | Scwcmd コマンド ライン ツールを使用して、前の手順で作成した XML セキュリティ テンプレートを GPO に変換します。 | 6. | 要塞ホスト サーバーで手順 4 を繰り返して、要塞ホスト XML セキュリティ テンプレートを作成し、SCW を再び使用して、それを変換してローカル GPO に適用します。 |
GPO が正常に作成された後、該当する章のガイダンスと設定を比較し、不正な構成がないかどうかを確認します。 この段階で、すべてのドメイン メンバ サーバーが Computers OU に存在します。これらのサーバーは、Member Server OU の下の該当する OU に移動されます。 次のタスク (詳細は次の手順を参照) は、各 GPO をそれぞれの OU に適用することです。GPO と OU とのリンクには、グループ ポリシー管理コンソール (GPMC) ツールが使用されました。Domain Controller Policy GPO は、最後にリンクされました。 次の手順は、セキュリティ構成構築フェーズの残りの部分を完了するために実行されました。 グループ ポリシー オブジェクトを適用するには 1. | Domain Policy GPO をドメイン オブジェクトにリンクします。 注 : 既定の GPO リンクが既に存在する場合、または複数の GPO が存在する場合、優先リストで GPO リンクの優先度を上げる必要が生じることがあります。 | 2. | グループ ポリシー管理コンソール ツールを使用して、Member Server Baseline Policy GPO を Member Servers OU にリンクします (この手順は、MMC の [Active Directory ユーザーとコンピュータ] スナップインでも実行できます)。 | 3. | 各サーバーの役割 GPO を適切なサーバーの役割 OU にリンクします。 | 4. | Domain Controller Policy GPO を Domain Controller OU にリンクします。 | 5. | 最新のグループ ポリシー設定の適用を確実にするため、すべてのドメイン コントローラにおいてコマンド プロンプトで gpudpate /force を実行します。その後、すべてのドメイン コントローラを 1 つずつ再起動し、プライマリ ドメイン コントローラを開始します。Active Directory がサイト間の変更をレプリケートできるだけの十分な時間をとります。 重要 : Domain Controllers Policy GPO を適用したらドメイン コントローラを再起動することが非常に重要です。この手順を実行しなかった場合、イベント ビューアのディレクトリ サービス フォルダに複製エラーが表示されたり、アプリケーション フォルダに Userenv エラーが表示されたりすることがあります。 | 6. | すべてのドメイン メンバ サーバーで手順 5 を繰り返します。 | 7. | エラーがないかどうかをイベント ビューアで確認します。エラー ログを確認し、障害があった場合はトラブルシューティングして、解決します。 | 8. | 要塞ホスト サーバーで SCW のツールを使用して、サーバーの Local GPO に要塞ホスト XML セキュリティ テンプレートを適用します。 |
メンバ サーバー コンピュータのグループ ポリシー ダウンロードを確認する前述の手順では、GPO を作成し、それらを OU に適用して、該当 OU に属するコンピュータを構成しました。次の手順を実行して、グルーブ ポリシーがドメイン コントローラからメンバ サーバー コンピュータへ正常にダウンロードされたことを確認します (GPO が OU にリンクされた後、メンバ サーバー コンピュータが再起動されていることが前提)。 メンバ サーバー コンピュータのグループ ポリシー ダウンロードを確認するには 1. | メンバ サーバー コンピュータにログオンします。 | 2. | [スタート]、[ファイル名を指定して実行] の順にクリックし、「rsop.msc」と入力してから、Enter キーを押します。 | 3. | [ポリシーの結果セット] コンソールで、 [コンソール ルート] を展開し、 [コンピュータの構成] を参照します。 | 4. | [コンピュータの構成] を右クリックし、 [プロパティ] をクリックします。 GPO の一覧が [コンピュータの構成プロパティ] パネルに表示されます。正常な場合、OU に適用された GPO が一覧で使用可能になり、関連エラーはありません。 |
テスト実行フェーズこのフェーズでは、テスト チームによって開発されたテスト ケースを実行します。テスト実行フェーズでは、次の事項がないかどうかを確認します。 | • | ドメイン、ドメイン コントローラ、メンバ サーバー、または要塞ホスト サーバーの強化に使用されたプロセスにより生じた、アプリケーション、セキュリティ、またはシステムに関する潜在的な障害イベント。 | | • | ネットワーク内のサーバーのセキュリティ構成を変更したことによる、サービスまたは機能の可用性の低下。 | | • | 各章での記載内容とテスト ラボでの物理的な実装との間の技術的な矛盾。 |
テスト チームは、\Windows Server 2003 Security Guide\Tools and Templates\Test Guide フォルダに含まれている一連のテスト ケースを実行しました (ツールとテンプレートはこのガイドのダウンロード バージョンに付属しています)。これらのテストが、3 つの異なるネットワークそれぞれについて実行されました。ただし、EC 環境でのみ使用できる証明書サービスなど、特定のネットワークでのみ使用できるコンポーネントのテストは、該当するネットワークでのみ実行されました。これらのテスト ケースの他に、イベント ビューアのログを定期的に確認したり、このガイドの以前のバージョンで見つかった懸案事項を確認したりするなど、さまざまなタイミングで手動テストが実施されました。見つかったすべての懸案事項はデータベースに記録され、解決するまで開発チームのメンバが担当しました。 実行されたさまざまなテストの種類については、次の項で詳しく説明します。 テストの種類テスト チームは、セキュリティ保護されたドメイン、ドメイン コントローラ、およびメンバ サーバーに深刻な機能喪失が生じないことを確認するため、テストフェーズにおいて次の種類のテストを実行しました。このガイドのダウンロード バージョンの \Windows Server 2003 Security Guide\Tools and Templates\Test Guide フォルダの中にある Excel ワークブックに、SP1 を適用した Windows Server 2003 を実行するドメイン ベース サーバーおよびスタンドアロン サーバーで実行されたすべてのテスト ケースの一覧が記載されています。テストの計画、実行手順、予期される結果などの詳細も記載されています。 これらのテストは、複数回実行されました。さらに重要なのが、これらのテストがこのガイドに記載されているセキュリティ設定を実装する前と後に実行されたことです。このアプローチは、記載されているサーバーの役割に関する潜在的なエラーと機能のバリエーションを特定することに役立ちました。 クライアント側のテスト次のテスト ケースは、ネットワーク内のクライアント コンピュータに対して実行されました。主な目的は、ネットワーク サーバーの強化後に、ドメイン サービス (認証、アクセス権限、名前の解決など) やアプリケーション ベースのサービス (ファイル、プリント、Web など) がクライアント コンピュータで使用できることを確認することです。LC 環境では、これらのテストにより、Windows NT 4.0 SP6a や Windows 98 を実行するクライアント コンピュータを Windows Server 2003 Active Directory ドメインで認証できることが確認されました。 記載内容テスト記載内容テストでは、実装ガイダンス内の説明、手順、および機能の記述が、正確、明確、および完全であることを検証します。これらのテストについては、個別にテスト ケースを記述していません。 スクリプト テストクライアント テスト手順の一部は、VBScript でスクリプト化されています。これらのテスト ケースで主に検証するのは、ドメイン ログオン、パスワードの変更、プリント サーバーへのアクセスなどのネットワーク ベースのサービスを使用する Windows XP クライアント コンピュータが適切に機能するかどうかです。これらのテスト ケースの VBScript ファイルは、このガイドのダウンロード バージョンの \Windows Server 2003 Security Guide\Tools and Templates\Test Guide フォルダの中にあります。 サーバー側のテスト以下のテスト ケースは、このガイドの推奨事項に従ってセキュリティ保護されている Windows Server 2003 SP1 サーバーの機能と構築手順の効果とを検証するために開発されました。このガイドで説明されているすべてのサーバーの役割がテストされました。また、Exchange、MOM、SMS など、テスト ネットワークに接続されたサーバーの役割もテストされました。 合格と不合格の基準不具合の防止とバグの解決を確実に行うため、テストを実行する前に以下の基準が定義されました。 | • | すべてのテスト ケースは、個々のテスト ケースのスプレッドシートに記述されている、予測される結果で合格する必要があります。 | | • | テスト ケースは、実際の結果が、予測された結果と同じである場合に合格と見なします。実際の結果が、予測された結果と異なる場合は、不合格として扱い、バグを報告し、その深刻度の評価を割り当てました。 | | • | テスト ケースが不合格の場合、その原因がソリューション ガイダンスの欠陥にあるとは結論付けませんでした。たとえば、製品文書の間違った解釈、または不完全または不正確な記載内容なども不合格の原因になります。それぞれの不合格ケースは、実際の結果と、プロジェクト文書に記述されている結果に基づいて分析することで、その原因を究明しました。また、不合格ケースは、該当する Microsoft 製品の適切な所有者に報告しました。 |
リリース条件『Windows Server 2003 セキュリティ ガイド』の主なリリース条件は、未解決バグの深刻度に関連しています。ただし、バグとして追跡していなかった他の問題についても検討しました。リリース条件は、次のとおりです。 | • | 深刻度 1 および 2 の未解決バグがない。 | | • | 指導チームによってすべての未解決バグに優先順位が付けられ、その影響が完全に把握されている。 | | • | ソリューション ガイドに、コメントや変更履歴のマークがない。 | | • | テスト ラボ環境でソリューションがすべてのテスト ケースに合格した。 | | • | ソリューション コンテンツに矛盾する記述がない。 |
バグの分類バグの深刻度評価を次の表に示します。深刻度は 1 ～ 4 の尺度で表します。深刻度が最も高いのが 1、最も低いのが 4 です。 表 D.1 バグの深刻度の分類 1 | – バグにより、テストの構築または続行が妨げられた。
– バグにより、ユーザー アクセスが予期しない状態になった。
– ドキュメントに記載されている手順が明確でない。
– 機能または手順が予期した結果 (機能仕様の記載) と矛盾する。
– セキュリティ テンプレート ファイルと機能仕様とに大きな不一致がある。 | – ソリューションが機能しなかった。
– ユーザーがほとんどのコンピュータまたはネットワークを使用できなかった。
– ユーザーに本来許可されないアクセス権限が与えられた。
– ユーザーにアクセスが許可されるべき特定のサーバーへのアクセスが拒否された。
– 予期された結果が得られなかった。
– 介入なしにはテストを続行できなかった。 | 2 | – ガイドに定義されている手順が明確でない。
– 記載されている機能がない (この場合、テストの続行が妨げられる)。
– 記載漏れがある。または、不適切な記載がある。
– セキュリティ テンプレート ファイルとガイドの記載内容とに矛盾があるが、セキュリティ テンプレート ファイルは機能仕様に準拠している。 | – ユーザーが状況を改善するための簡単な回避策がない。
– ユーザーが回避策を見つけるのが容易でない。
– コンピュータまたはネットワークが主要なビジネス要件を満たしていない。 | 3 | – ドキュメントの書式に問題がある。
– ドキュメントの目立たない間違いや不正確な記述。
– テキストの誤字、脱字。 | – ユーザーが状況を改善できる簡単な回避策がある。
– ユーザーが回避策を簡単に見つけることができる。
– バグによりユーザーに望ましくない状況が生じない。
– 主要ビジネス要件は一応満たされている。 | 4 | – 推奨事項である。
– 今後改善の必要がある機能が存在する。 | – 明らかに現在のバージョンに関係がない。 |
まとめこの付録を参照することで、『Windows Server 2003 セキュリティ ガイド』を使用する組織は、テスト ラボ環境でソリューションの実装のテストに使用された手順が理解しやすくなります。この付録には、テスト環境、テストの種類、リリース基準、バグ分類の詳細に関する説明など、『Windows Server 2003 セキュリティ ガイド』テスト チームが実際に経験したことが盛り込まれています。 テスト チームが実行したすべてのテスト ケースは、予測された結果で合格しました。テスト チームは、定義された環境に『Windows Server 2003 セキュリティ ガイド』の推奨事項を適用した結果、必須機能が使用可能であることを確認しています。
| 
