トピック概要この章では、環境内で Microsoft® Windows Server™ 2003 Service Pack 1 (SP1) と Microsoft 証明書サービスを実行するサーバーのセキュリティ強化に役立つ指針を説明します。この章では、このようなサーバーのセキュリティ保護に必要な情報についてすべて説明していますが、環境内でセキュリティ保護された証明書サービスを作成する方法や証明機関 (CA) を展開する方法については説明していません。これらのトピックについては、Windows Server2003 の製品ドキュメントを参照してください。また、これらのトピックは、Windows Server 2003 リソース キット、Microsoft の Web サイトから入手できるホワイト ペーパーでも説明されています。詳細情報については、http://go.microsoft.com/fwlink/?LinkId=14843 の関連ガイド『証明書サービスを使用してワイヤレス LAN のセキュリティを保護する』を参照してください。 この章で説明しているほとんどの設定は、グループ ポリシーを使用して構成および適用されています。CA サーバーの役割に必要なセキュリティ設定を変更するには、メンバ サーバー ベースライン ポリシー (MSBP) を補うグループ ポリシー オブジェクト (GPO) を、CA サーバーを含む適切な組織単位 (OU) にリンクします。この章では、MSBP とは異なるポリシー設定についてのみ説明します。 これらの設定は、CA サーバー OU に適用される付加的なグループ ポリシー テンプレートに、可能な限りまとめられています。この章で説明している設定の一部は、グループ ポリシーを使用して構成することができません。このような設定を手動で構成する方法についても、詳しく説明します。 EC 環境向けの CA サーバー セキュリティ テンプレートの名前は EC-CA Server.inf です。このテンプレートには、付加的な CA サーバー テンプレート用の設定が用意されており、これを使用して、CA サーバー OU にリンクする新しい GPO を作成します。OU とグループ ポリシーを作成し、適切なセキュリティ テンプレートを各 GPO にインポートする手順の詳細については、「第 2 章 Windows Server 2003 のセキュリティ強化メカニズム」を参照してください。 MSBP の設定の詳細については、「第 4 章 メンバ サーバー ベースライン ポリシー」を参照してください。すべての既定の設定の詳細については、http://go.microsoft.com/fwlink/?LinkId=15159 の関連ガイド『脅威とその対策 : Windows Server 2003 と Windows XP のセキュリティ設定』を参照してください。 注 :証明書サービス サーバーの役割のポリシーの推奨設定は、エンタープライズ クライアント環境でのみテストされています。このため、このガイドでその他ほとんどのサーバーの役割で記載されているサービス拒否 (DoS) 攻撃に関する詳細については、この章では説明していません。 環境内の証明書サービス サーバーで証明機関 (CA) の証明書と証明書失効リスト (CRL) を配布できるようにするには、証明書サービス サーバーの一部に Microsoft インターネット インフォメーション サービス (IIS) をインストールする必要が生じる場合があります。IIS は、証明書サービス サーバーの Web 登録ページのホストにも使用できます。これにより、非 Microsoft Windows® クライアントが証明書を登録できるようになります。この章で説明している情報に基づいて作業を行う前に、このガイドの「第 9 章 Web サーバーの役割」で説明している、IIS のセキュリティ保護されたインストール方法を理解しておいてください。IIS を CA にインストールする場合、この章で説明している規定の設定を構成する前に、第 9 章で作成しているセキュリティ構成テンプレートを証明書サービス サーバーに適用する必要があります。 注 :単純な環境では、発行側の CA サーバーを使用して、Web サーバー、CA 証明書、および CRL ダウンロード ポイントをホストできます。ただし、現在の環境に別の Web サーバーを使用して CA のセキュリティを強化する方法も検討してください。 IIS は、証明書サーバー登録ページをホスティングすること、および、Windows 以外のクライアントに対して CA 証明書と CRL のダウンロード ポイントを配布することに使用します。IIS は、ルート CA サーバーにはインストールしないことをお勧めします。環境内の発行 CA または中間 CA で IIS を実行することは、できる限り避けてください。CA サーバー自体よりも別のサーバーで CA 証明書や CRL の Web ダウンロード ポイントをホストする方が安全です。CRL または CA チェーン情報を必要とする証明書ユーザーは内外に多数いますが、すべてのユーザーに CA へのアクセスを許可する必要は必ずしもありません。ただし、ダウンロード ポイントを CA でホストする場合は、CA はユーザーからアクセスできるようにする必要があります。 監査ポリシーの設定エンタープライズ クライアント環境では、証明書サービス サーバーの監査ポリシー設定は、MSBP を使用して設定します。MSBP の詳細については、「第 4 章 メンバ サーバー ベースライン ポリシー」を参照してください。MSBP の設定によって、関連するすべてのセキュリティ監査情報がすべての証明書サービス サーバーにも記録されます。 ユーザー権利の割り当てエンタープライズ クライアント環境では、証明書サービス サーバーのユーザー権利の割り当ても、MSBP を使用して設定します。MSBP の詳細については、「第 4 章 メンバ サーバー ベースライン ポリシー」を参照してください。MSBP で設定すると、証明書サービス サーバーへの適切なアクセスは、企業内で一律に設定されます。 セキュリティ オプショングループ ポリシーのセキュリティ オプション セクションを使用すると、データのデジタル署名、Administrator や Guest のアカウント名、フロッピー ディスク ドライブや CD-ROM ドライブへのアクセス、ドライバのインストール時の動作、ログオン プロンプトなどのコンピュータのセキュリティ設定を有効または無効にすることができます。 セキュリティ オプションの設定は、Windows Server 2003 では、グループ ポリシー オブジェクト エディタを使用して、次の場所で構成できます。 コンピュータの構成\Windows の設定\セキュリティの設定\ローカル ポリシー \セキュリティ オプション 次の表には、エンタープライズ クライアント環境での証明書サービス サーバーの役割のセキュリティ オプションの推奨設定が示されています。各設定の詳細情報については、表に続いて説明します。 表 11.1 セキュリティ オプションの推奨設定 システム暗号化:暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使う | 有効 |
システム暗号化:暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使うこのポリシー設定では、TLS/SSL (Transport Layer Security/Secure Sockets Layer) セキュリティ プロバイダが TLS_RSA_WITH_3DES_EDE_CBC_SHA 暗号スイートだけをサポートするかどうかを指定します。この暗号スイートをサポートするということは、実際には、プロバイダがクライアントとサーバー (該当する場合) として TLS プロトコルだけをサポートすることを意味します。 TLS/SSL セキュリティ プロバイダは、以下のアルゴリズムを使用します。 | • | TLS トラフィックの暗号化のための Triple Data Encryption Standard (3DES) 暗号化アルゴリズム | | • | TLS キー交換および認証のための Rivest, Shamir, and Adelman (RSA) 公開キー アルゴリズム(RSA は RSA Data Security, Inc. によって開発された公開キー暗号化技術) | | • | TLS ハッシュ要件のための SHA-1 ハッシュ アルゴリズム |
Encrypting File System Service (EFS) の場合、TLS/SSL セキュリティ プロバイダは、3DES 暗号化アルゴリズムだけをサポートして、Windows NTFS ファイル システムに保存されているファイル データを暗号化します。EFS は既定では DESX アルゴリズムを使用してファイル データを暗号化します。 このポリシー設定を有効にすると、環境でこのサーバーの役割を実行しているコンピュータで、デジタル暗号化、ハッシュ、および署名に対して利用可能な最も強力なアルゴリズムが使用されます。できるだけ強力なアルゴリズムを使用することで、承認されていないユーザーがデジタルで暗号化または署名されたデータを改ざんすることが難しくなり、リスクが最小限に抑えられます。 このため、エンタープライズ クライアント環境では、[システム暗号化: 暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使う] は [有効] に設定されます。 注 :このポリシー設定が有効になっているクライアント コンピュータは、これらのアルゴリズムをサポートしないサーバーと、デジタルで暗号化または署名されたプロトコルを使用して通信することはできません。また、これらのアルゴリズムをサポートしていないネットワーク クライアント コンピュータは、これらのアルゴリズムをネットワーク通信に必要とするサーバーを使用できません。たとえば、多くの Apache ベースの Web サーバーは、TLS をサポートするようには設定されていません。 この設定を有効にする場合、TLS を使用できるように Internet Explorer も構成する必要があります。構成するには、Internet Explorer の [ツール] メニューから [インターネット オプション] を選択します。[インターネット オプション] ダイアログ ボックスで [詳細設定] タブをクリックし、[設定] リストを下へスクロールして、[TLS 1.0 を使用する] チェック ボックスをオンにします。この構成を行うには、グループ ポリシーまたは Internet Explorer Administrators Kit も使用できます。 イベント ログの設定エンタープライズ クライアント環境では、証明書サービス サーバーのイベント ログ設定も、MSBP を使用して設定します。MSBP の詳細については、「第 4 章 メンバ サーバー ベースライン ポリシー」を参照してください。 追加のレジストリ エントリ追加レジストリ エントリが、EC-CA Server.inf テンプレート ファイル向けに作成されています。これらのエントリは、このガイドで定義しているエンタープライズ クライアント環境用の管理用テンプレート (.adm) ファイルには定義されていません。.adm ファイルには、Windows Server2003 SP1 用のデスクトップ、シェル、およびセキュリティ設定のためのシステム ポリシーと制限が定義されています。 追加のレジストリ エントリはセキュリティ テンプレートに設定されており、自動的に実装されるようになっています。この環境用の付加的な証明書サービス グループ ポリシーが削除された場合、設定は自動的には削除されないので、Regedt32.exe などのレジストリ編集ツールを使用して手動で変更する必要があります。 レジストリ エントリは、Windows Server 2003 の場合、グループ ポリシー オブジェクト エディタを使用して、次の場所で指定できます。 MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration 追加のセキュリティ設定次の ACL は推奨 ACL であり、グループ ポリシーで割り当てることができます。ただし、これらの ACL はこのガイドに付属のセキュリティ テンプレートには含まれていません。データベースとログのパスがサーバーによって異なるためです。たとえば、証明書サービス サーバーであっても、C:\、D:\、E:\ などのドライブがあるからです。これらのポリシー設定を手動で実装する方法について、以下に説明します。 ファイル システム ACLアクセス制御リスト (ACL) で保護されないファイルは、そのファイルにローカルまたはネットワーク経由でアクセスできる承認されていないユーザーによって、容易に参照、変更、および削除される可能性があります。ACL はファイルの保護に役立ちますが、ファイルを暗号化するとセキュリティがさらに強化され、ファイルへのアクセスを 1 人のユーザーのみに制限することもできます。 次の表は、エンタープライズ クライアント環境における、Windows Server2003 ベースの証明書サービス サーバー向けのファイル システム ACL を示しています。この環境では、証明書サービス サーバーは、証明書データベース ディレクトリとして D:\CertSrv を使用し、データベース ログは既定のフォルダ %SystemRoot%\system32\CertLog に保存します。また、ログは、システム ドライブとは物理的に別のミラー ドライブ (E:\CertLog など) に移動することもできます。セキュリティを考慮するうえで、データベースとログを別の物理ディスク ドライブに分ける必要はありませんが、ディスク障害から保護し、パフォーマンスを向上させるため、このように構成することをお勧めします。証明書サービスの既定のインストール フォルダである %SystemRoot%\system32\CertLog と %SystemRoot%\system32\CertSrv には、次の表に示すように適正な ACL が既定で付与されています。 表 11.2 ファイル システム ACL %SystemRoot%\system32\CertLog (すべてのサブフォルダに適用) | Administrators (フル コントロール) SYSTEM (フル コントロール) | %SystemRoot%\system32\CertSrv (すべてのサブフォルダに適用) | Administrators (フル コントロール) SYSTEM (フル コントロール) Users (読み取りと実行、フォルダの内容の一覧表示、および読み取り) | D:\CertLog | Administrators (フル コントロール) SYSTEM (フル コントロール) | D:\CertSrv | Administrators (フル コントロール) SYSTEM (フル コントロール) Users (読み取りと実行、フォルダの内容の一覧表示、および読み取り) |
CA のセキュリティは厳重にする必要があるため、上記の表に記載した証明書サービス フォルダではファイル監査が有効にされています。監査エントリは、次の表のように設定されています。 表 11.3 証明書サービス ファイルとレジストリ監査の設定 %SystemRoot%\system32\CertLog | 失敗 | Everyone (フル コントロール) | %SystemRoot%\system32\CertSrv | 成功 | Everyone (変更) | D:\CertSrv | 成功 | Everyone (変更) | D:\CertLog | 成功 | Everyone (変更) |
上記のポリシー設定により、任意のユーザーによる失敗アクセス (読み取りまたは変更) のあらゆる種類が監査されます。また、任意のユーザーによる成功の変更も監査されます。 既知のアカウントを保護するWindows Server 2003 SP1 には、削除できず、名前だけ変更できるビルトイン ユーザー アカウントがいくつかあります。Windows Server 2003 の最もよく知られているビルトイン アカウントは、Guest と Administrator です。 既定では、Guest アカウントはメンバ サーバーとドメイン コントローラでは無効になっています。この設定は変更しないでください。悪意のあるコードの多くは、サーバーへの侵入で最初の試みとしてビルトイン Administrator アカウントを使用します。このため、ビルトイン Administrator アカウントの名前は変更され、説明も変更されて、攻撃者がよく知られているアカウントを使用してリモート サーバーへ侵入するのを防止しています。 ビルトイン Administrator アカウントのセキュリティ識別子 (SID) を指定し、その本当の名前を調べてサーバーに侵入しようとする攻撃ツールが出現して以来、この構成変更の価値はここ数年間で減少しています。SID は、各ユーザー、グループ、コンピュータ アカウント、およびネットワークのログオン セッションをそれぞれ識別する値です。このビルトイン アカウントの SID を変更することはできません。ただし、Administrator アカウント名を一意の名前に変更すると、運用グループが Administrator アカウントに対する攻撃を簡単に監視できるようになります。 CA サーバーのよく知られたアカウントをセキュリティで保護するには | • | すべてのドメインやサーバーで、Administrator アカウントと Guest アカウントの名前を変更し、パスワードを長く複雑な値に変更します。 | | • | 各サーバーで異なる名前とパスワードを使用します。すべてのドメインとサーバーで同じアカウント名とパスワードを使用する場合、攻撃者があるメンバ サーバーへのアクセスに成功した場合に、他のすべてのサーバーにもアクセスできるようになってしまいます。 | | • | アカウントを容易に識別できないように、アカウントの説明を既定以外に変更します。 | | • | これらの変更を安全な場所に記録します。 注 :ビルトイン Administrator アカウントの名前は、グループ ポリシーを使用して変更できます。このアカウントには各組織が固有の名前を指定する必要があるので、このガイドに付属のセキュリティ テンプレートではこのポリシー設定は構成していません。ただし、EC 環境では、[アカウント: Administrator アカウント名の変更] 設定を使用して、Administrator アカウント名を変更できます。このポリシー設定は、GPO のセキュリティ オプション設定に含まれています。 |
サービス アカウントをセキュリティ保護する避けられない場合を除いて、ドメイン アカウントのセキュリティ コンテキストでサービスを実行するようには構成しないでください。サーバーに物理的にアクセスされた場合、LSA シークレットをダンプすることで、ドメイン アカウントのパスワードが容易に取得されます。サービス アカウントのセキュリティを保護する方法の詳細については、http://www.microsoft.com/japan/technet/security/topics/serversecurity/serviceaccount/default.mspx の「サービスおよびサービス アカウントのセキュリティ計画ガイド」を参照してください。 SCW を使用してポリシーを作成する必要なセキュリティ設定を展開するには、セキュリティの構成ウィザード (SCW) と、このガイドのダウンロード バージョンに付属のセキュリティ テンプレートの両方を使用して、サーバー ポリシーを作成する必要があります。 独自のポリシーを作成する場合は、[レジストリ設定] セクションと [監査ポリシー] セクションをスキップします。これらの設定は、選択した環境のセキュリティ テンプレートで提供されます。この方法は、テンプレートのポリシー要素が SCW によって構成されるポリシー要素より優先されるようにするために必要です。 構成作業を始める際には、オペレーティング システムの新規インストールを使用することをお勧めします。こうすることにより、以前の構成の古い設定やソフトウェアが残っていないことが保証されます。可能であれば、展開に使用するものと同様のハードウェアを使用することをお勧めします。これにより、互換性が向上します。このような新規インストールを参照コンピュータと呼びます。 サーバー ポリシーの作成手順で、検出された役割の一覧からファイル サーバーの役割を削除することに注意してください。この役割は、それを必要としないサーバーに構成されていることが多く、セキュリティ リスクになる可能性があります。ファイル サーバーの役割が必要なサーバーでそれを有効にするには、このプロセスの後半で別のポリシーを適用します。 証明書サービス サーバー ポリシーを作成するには 1. | Windows Server 2003 SP1 の新しいインストールを新しい参照コンピュータに作成します。 | 2. | [コントロール パネル]、[アプリケーションの追加と削除]、[Windows コンポーネントの追加と削除] の順に選択して、セキュリティの構成ウィザードのコンポーネントをコンピュータにインストールします。 | 3. | コンピュータをドメインに参加させます。これにより、親 OU からすべてのセキュリティ設定が適用されます。 | 4. | この役割を共有するすべてのサーバーに必要な必須アプリケーションのみをインストールし、構成します。たとえば、役割固有のサービス、ソフトウェア エージェント、管理エージェント、テープ バックアップ エージェント、ウイルス対策ユーティリティ、スパイウェア対策ユーティリティなどが該当します。 | 5. | SCW GUI を起動し、[新しいセキュリティ ポリシーの作成] を選択して、参照コンピュータを指定します。 | 6. | 証明書サービス サーバーの役割など、検出されたサーバーの役割が環境に適していることを確認します。 | 7. | 検出されたクライアント機能が環境に適していることを確認します。 | 8. | 検出された管理オプションが環境に適していることを確認します。 | 9. | ベースラインに必要な追加サービス、たとえばバックアップ エージェントやウイルス対策ソフトウェアが検出されていることを確認します。 | 10. | 環境で指定されていないサービスの扱いを決定します。セキュリティをさらに向上させるため、このポリシー設定を [無効] にします。この設定は、運用ネットワークに展開する前にテストしてください。運用サーバーが、参照コンピュータに複製されていない追加サービスを実行する場合に、問題が発生することがあります。 | 11. | [ネットワーク セキュリティ] セクションで [このセクションをスキップする] チェック ボックスがオフであることを確認し、[次へ] をクリックします。前の手順で特定した適切なポートとアプリケーションが、Windows ファイアウォールの例外として構成されます。 | 12. | [レジストリの設定] セクションで、[このセクションをスキップする] チェック ボックスをオンにし、[次へ] をクリックします。これらのポリシー設定は、付属の INF ファイルからインポートされます。 | 13. | [監査ポリシー] セクションで、[このセクションをスキップする] チェック ボックスをオンにし、[次へ] をクリックします。これらのポリシー設定は、付属の INF ファイルからインポートされます。 | 14. | 適切なセキュリティ テンプレート (EC-CA Server.inf など) を含めます。 | 15. | ポリシーを適切な名前 (Certificate Services.xml など) で保存します。 |
SCW を使用してポリシーをテストするポリシーを作成して保存したら、テスト環境に展開することを強くお勧めします。テスト サーバーが運用サーバーと同じハードウェアおよびソフトウェア構成であることが理想的です。こうすることで、特定のハードウェア デバイスに予期しないサービスが必要になった場合などの、潜在的な問題を検出して解決できるようになります。 ポリシーのテストには、2 つの方法があります。SCW 独自の展開機能を使用する方法と、GPO を使用してポリシーを展開する方法です。 ポリシーの作成をこれから始める場合には、SCW 独自の展開機能を使用することを検討してください。SCW を使用して、ポリシーをサーバーごとにプッシュするか、Scwcmd を使用してポリシーをサーバーのグループにプッシュします。この展開方法を使用すると、SCW から展開したポリシーを簡単にロールバックできます。この機能は、テスト プロセスでポリシーの変更を複数行う場合に便利です。 ポリシーをテストする目的は、そのポリシーを対象サーバーに適用しても重要な機能に悪影響が及ばないことを確認することです。構成の変更を適用したら、コンピュータの主要な機能を検証する必要があります。たとえば、証明機関 (CA) として構成されているサーバーの場合は、クライアントが証明書を要求して取得できること、証明書失効リストをダウンロードできることなどを確認します。 ポリシーの構成に問題がないことを確認したら、次に示す手順に従って、Scwcmd を使用して、ポリシーを GPO に変換します。 SCW ポリシーのテスト方法の詳細については、http://technet2.microsoft.com/WindowsServer/ja/Library/5254f8cd-143e-4559-a299-9c723b3669461041.mspx?mfr=true の『セキュリティの構成ウィザードの展開ガイド』および http://go.microsoft.com/fwlink/?linkid=43450 の「Security Configuration Wizard Documentation」(英語情報) を参照してください。
ポリシーを変換して展開するポリシーを徹底的にテストした後、次の手順を実行して、ポリシーを GPO に変換して、展開します。 1. | コマンド プロンプトで、次のコマンドを入力します。 scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> Enter キーを押します。次にその例を示します。 scwcmd transform /p:"C:\Windows\Security\msscw\Policies\ Certificate Services.xml" /g:"Certificate Services Policy" 注 :コマンド プロンプトに入力する情報が、表示の制限により複数行にわたって表示されることがあります。この情報は、すべて 1 行に入力してください。 | 2. | グループ ポリシー管理コンソールを使用して、新しく作成した GPO を適切な OU にリンクします。 |
SCW セキュリティ ポリシー ファイルに Windows ファイアウォールの設定が含まれている場合、この手順を正常に完了するには、ローカル コンピュータで Windows ファイアウォールが有効になっている必要があります。Windows ファイアウォールが有効であることを確認するには、[コントロール パネル] を開き、[Windows ファイアウォール] をダブルクリックします。 次に、最後のテストを実行して、GPO により意図した設定が適用されることを確認します。この手順を完了させるために、設定が適切であること、機能がその影響を受けないことを確認します。 まとめこの章では、このガイドで定義しているエンタープライズ クライアント環境で、Windows Server 2003 SP1 を実行する証明書サービス サーバーのセキュリティ強化に使用できるポリシー設定について説明しました。各設定は、MSBP を補うグループ ポリシー オブジェクト (GPO) を通じて適用されます。GPO は、証明書サービス サーバーを含む適切な組織単位 (OU) にリンクして、セキュリティをさらに向上させることができます。 関連情報Windows Server 2003 SP1 と証明書サービスを実行するサーバーのセキュリティ強化に関する詳細情報は、以下のリンクから参照できます。 | • | 公開キー基盤 (PKI) の概念と Windows 2000 証明書サービスの概要については、http://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/evaluate/featfunc/pkiintro.mspx の「Windows 2000 の公開キー基盤の概要」を参照してください。 | | • | Windows Server 2003 および Windows XP における PKI の機能の詳細については、http://www.microsoft.com/japan/technet/prodtechnol/winxppro/plan/pkienh.mspx の「Windows XP Professional と Windows Server 2003 の PKI 拡張機能」を参照してください。 | | • | PKI の主要概念の背景情報については、http://technet2.microsoft.com/windowsserver/en/library/32aacfe8-83af-4676-a45c-75483545a9781033.mspx の「公開キー基盤」ページを参照してください。
|
|