マイクロソフトの Securing Windows 2000 Server ソリューション : 第 5 章 ‐ ドメイン インフラストラクチャをセキュリティで保護する
トピック
第 4 章「セキュリティ リスク管理の統制を適用する」では、セキュリティ リスク管理統制 (Security Risk Management Discipline: SRMD) を使用して、Contoso, Ltd 固有セキュリティ リスクを特定しました。ここで特定されたリスクの緩和、または解決措置については、本章より後の章で取り上げます。
この章では、ドメインのレベルでの脆弱性に焦点を絞ります。Microsoft Active Directory サービスの設計、組織単位 (OU) の設計、およびドメイン ポリシーなどを高度なレベルで解説します。それに加えて、Contoso. Ltd. が実施した具体的なドメイン ポリシーについても詳細を説明します。
Active Directory の設計
Active Directory の構成の設計を詳しく説明すると、1 冊の本が書けるくらいです。Active Directory は Active Platform の一部を構成するマイクロソフトのテクノロジです。Active Directory は、分散コンピューティング環境において、アプリケーションがディレクトリ リソースを検索、使用、および管理できるように設計されています。ここでは、この章の他の関連する情報について共通の理解が得られるように、Active Directory の基本概念について説明します。
Active Directory アーキテクチャを構築する際に考慮すべき最も重要な点の 1 つに、組織に適用するセキュリティの境界があります。組織内でセキュリティを施行および委任する方法を適切に計画する時間を取ることにより、最終的な Active Directory 設計のセキュリティは非常に高くなります。そのために、組織の環境を再構成する必要はありません。ただし、企業買収や組織の再編成など、ビジネスに大きな変更があった場合には、再構成する必要があります。
既に 組織内で Active Directory の設計が行われている場合、セキュリティの観点から自社環境に固有の設計上の利点や潜在的な問題について、この章から何らかのヒントを得る可能性があります。
Active Directory の境界の設定
Active Directory の境界は何種類かあります。Active Directory の境界には、フォレスト、ドメイン、サイト トポロジ、およびアクセス許可の委任などが含まれます。
Active Directory の境界の多くは、Active Directory のインストール時に設定します。環境内でのアクセス許可の委任の設計には、セキュリティと管理機能とのバランスを適切に保つために、組織の要件を含める必要があります。管理者のアクセス許可の委任は、組織の要件に応じて、きわめて柔軟に行うことができます。委任の境界はさらにセキュリティの境界と管理の境界に分割することができます。
セキュリティの境界
セキュリティの境界は組織内のいろいろなグループの自治を定義するのに役立ちます。設定されたセキュリティの境界に基づいて適切なセキュリティを保つことと、基本的な機能を確実に提供し続けることの、利害のバランスを取ることは困難です。
セキュリティの境界と機能の適切なバランスは、組織に危険を及ぼす脅威を十分に理解し、次に管理の委任によるセキュリティ上の意味とこの評価を比較するか、または使用している環境のネットワーク アーキテクチャで他の選択をすることにより、実現することができます。
セキュリティの境界としてのフォレスト
Microsoftｮ Windowsｮ 2000 Server がリリースされた際、大部分のサポート文書ではドメインがセキュリティの境界として定義されました。しかし最近では、フォレストが真のセキュリティの境界として定義されています。実際の境界は、この両者の中間にあります。
ドメインは間違いなく Active Directory の管理の境界です。善意ある個人からなる組織では、組織の各ドメイン内でドメインの境界がサービスとデータを自治管理します。
セキュリティに関して解説していますが、残念ながらセキュリティの実現はそう簡単ではありません。たとえば、悪意あるドメイン管理者が行うと考えられる攻撃を、ドメインは完全に遮断することができません。完全な遮断はフォレスト レベルでのみ実現できます。
このような理由から、現在の設計でのサービスとデータの管理および制御の分割を、組織は検討する必要があります。データの自治および隔離に加えて、サービスの自治および隔離に関する組織のニーズを全面的に理解することにより、自社環境用の Active Directory の設計が強固なものとなります。
管理の境界
サービスとデータのセグメント化を行う必要性が考えられるため、異なるレベルの管理を定義する必要があります。
サービス管理者
Active Directory サービス管理者はディレクトリ サービスの構成と実施を担当します。たとえば、サービス管理者はドメイン コントローラ (DC) サーバーを維持管理し、ディレクトリ全般にわたる構成を設定し、サービスの可用性を保証します。
多くの場合、Active Directory サービスの構成は、ディレクトリに収められた各オブジェクトの設定に対応する属性値によって決まります。したがって、Active Directory においては、サービス管理者はデータ管理者の役割も果たします。サービス管理者には次のような種類があります。
フォレストの管理を担当する管理者のグループ
ドメインの管理を担当する管理者のグループ
ドメイン ネーム システム (DNS) の管理を担当する管理者のグループ
OU の管理を担当する管理者のグループ
インフラストラクチャ サーバーの管理を担当する管理者のグループ
フォレストの管理グループは、ネットワークへのディレクトリ サービスの提供を担当します。フォレストの管理グループは、非常に高い信頼を常に得る必要があります。フォレスト管理チームはフォレスト ルート Domain Admins、Enterprise Admins、および Schema Admins の各グループからフォレストを制御します。
ドメインの管理グループは主としてディレクトリ サービスを担当します。フォレスト管理者は各ドメインの管理グループを選定します。ドメイン管理者には非常に高いレベルのアクセス許可が与えられるので、信頼性の高い人物を選任する必要があります。ドメイン管理を実行するグループは、Domain Admins グループおよびその他のシステムに組み込まれたグループから、ドメインを制御します。
DNS 管理グループは DNS の設計および DNS インフラストラクチャの管理を担当します。DNS 管理者は DNSAdmins グループから DSN のインフラストラクチャを管理します。
OU 管理者は各 OU の管理者としてグループまたは個人を任命します。各 OU 管理者は割り当てられた Active Directory OU 内に格納されたデータの管理を担当します。OU の管理グループは、担当する OU における管理の委任方法およびポリシーの適用方法を制御できます。それに加えて、OU 管理者は新しいサブツリーを作成して、担当 OU の管理を委任することもできます。
インフラストラクチャ サーバーの管理グループは Windows インターネット ネーム サービス (WINS)、動的ホスト構成プロトコル (DHCP)、および潜在的に DNS インフラストラクチャの管理を担当します。場合によっては、ドメイン管理の担当グループが DSN のインフラストラクチャを管理することがあります。これは、Active Directory が DNS と統合されており、ドメイン コントローラ上に格納および管理される場合です。
データ管理者
Active Directory のデータ管理者は Active Directory 内または Active Directory に参加しているコンピュータ上に格納されているデータの管理を担当します。データ管理者はディレクトリ サービスの構成や提供は制御できません。データ管理者には次の種類があります。
ディレクトリ内のオブジェクトのサブセットを制御する管理者。継承可能な属性レベルのアクセス制御を通じて、データ管理者はディレクトリの非常に特定の部分を制御できます。しかし、サービスの構成自体は制御できません。
ディレクトリに参加しているメンバ コンピュータおよびそれらのコンピュータに格納されたデータを管理する管理者。
注 多くの場合、ディレクトリのサービスの構成は、ディレクトリに格納されたオブジェクトの属性値によって決まります。
要約すると、Active Directory サービス構造の考えられる結果、そしてディレクトリ構造の所有者により、フォレストまたはドメインのインフラストラクチャに参加する組織は、信頼できる人物をフォレストと全ドメイン内のすべてのサービス管理者に選ぶことが必要になります。サービス管理者への信頼とは、次を意味します。
サービス管理者が組織の最善の利益のために努力すると一般的に信じられること。フォレストまたはドメインの所有者が組織に対して悪質な行動を取ると思われる正当な理由がある場合、フォレストまたはドメインへの参加を取りやめます。
サービス管理者は最善策に従い、ドメイン コントローラへの物理的なアクセスを制限するものと一般的に信じられること。
「悪質な管理者」および「強引な管理者」が組織に関わる場合のリスクを理解して受け入れること。
悪質な管理者 — 信頼していた管理者が悪質な管理者に変身して、システムに関わる強力な権利を乱用する可能性は常にあります。
強引な管理者 — 信頼していた管理者がシステムのセキュリティに違反する操作を強引にまたは強制的に実行する可能性があります。
組織の中には、他の部署の悪質な管理者や強引な管理者によって、セキュリティ違反が生じるリスクを受け入れているところがあります。こうした組織では、共有インフラストラクチャに参加することの協調面およびコスト削減面の利益の方が、このリスクよりも大きいと判断しているのかもしれません。しかし、セキュリティ違反が発生した場合、非常に深刻な結果を招く可能性があるとして、このリスクを許容しない組織もあります。
セキュリティをサポートする OU の設計
本書は Active Directory の設計に重点を置いていません。しかし、ここではドメイン、ドメイン コントローラ、および特定のサーバーの役割を安全に管理するにあたって、グループ ポリシー使用への理解を深めるのに必要な設計情報を一部示します。
OU はユーザーと他のセキュリティ プリンシパルをグループ化する簡単な方法です。同時に、OU は管理の境界をセグメント化する有効な仕組みにもなります。
それに加えて、OU を使用してサーバーの役割に基づく種々のグループ ポリシー オブジェクト (GPO) を提供することは、組織のセキュリティ アーキテクチャ全体にとって不可欠な事項です。
管理の委任
OU はドメイン内のコンテナにすぎません。そのためには、各コンテナにアクセス制御リスト (ACL) を具体的に設定して、OU 制御をグループまたは個人に委任することができます。
Microsoftｮ Windows NTｮ 4.0 のリソース ドメインと同様の管理機能を提供するために、OU を使用することがよくあります。また、他のユーザーに管理してもらうリソース サーバーのグループを収めるために、OU を作成することもできます。この他のユーザーのグループは、特定の OU を自治管理できますが、ドメインの他の部分から隔離されません。
特定の OU の制御を委任する管理者が、サービス管理者となる可能性が高いです。権限の低いレベルで、OU を制御するユーザーは通常データ管理者です。
管理グループ
管理グループを作成すると、管理者はユーザー、グループ、またはサーバーを、自治管理するコンテナにセグメント化することができます。
たとえば、ドメイン内に常駐するインフラストラクチャ サーバーを考えてみます。インフラストラクチャ サーバーには、DNS、WINS、DHCP の各サービスなど基本的なネットワーク サービスを行っている、ドメイン コントローラ以外のものがすべて含まれます。
通常、これらのサーバーは運用グループまたはインフラストラクチャ管理グループによって維持されます。OU を使って、これらのサーバーに管理機能を容易に持たせることができます。
そのための最初のステップでは、インフラストラクチャ サーバーという OU を作成します。そこにすべての DNS サーバー、WINS サーバー、および DHCP サーバーを移動できます。Infrastructure Admins というグローバル セキュリティ グループを作成して、それに適切なドメイン アカウントを与えることができます。最後に、オブジェクト制御の委任ウィザードを実行して、Infrastructure Admins グループに OU に対するフル コントロールを与えます。こうした OU の上位レベルの概観を下図に示します。
.gif)
図 5.1: OU 管理の委任
これは組織単位を基に管理をセグメント化する、数多くの方法の 1 つにすぎません。組織がより複雑な場合、この章の最後で紹介するその他の参考資料を参照してください。
上記の手順に従うと、インフラストラクチャ サーバー OU およびこの OU 内のすべてのサーバーとオブジェクトに対し、Infrastructure Admins グループはフル コントロールを持つことになります。この結果、次のフェーズであるグループ ポリシーによるサーバーの役割のセキュリティ保護に進む準備が整います。
グループ ポリシーの適用
管理の委任と同時にグループ ポリシーを使用して、OU 内のすべてのサーバーに特定の設定、権利、および動作を確実に適用できます。手動のステップではなくグループ ポリシーを使用することにより、将来必要な追加変更を多数のサーバーに簡単に更新できます。
グループ ポリシーは下図に示す順序で累積および適用されます。
.gif)
図 5.2: GPO 適用階層
上記のとおり、ポリシーはコンピュータのローカル ポリシーから最初に適用されます。その後サイト レベル、ドメイン レベルの順で適用されます。いくつかのサーバーが複数の OU 内で階層になっている場合、最高レベルの OU に存在する GPO が最初に適用されます。GPO を適用するプロセスは、OU の階層を下って続けられます。最後に適用される GPO は、サーバー オブジェクトがあるローカル OU となります。
このモデルに関して、留意事項がいくつかあります。
上記の任意のグループ ポリシー レベルで複数の GPO が定義されている場合、この適用順序は管理者が設定します。複数のポリシーに同じオプションが指定されている場合、最後に適用されたものが優先します。
グループ ポリシーは上書き禁止オプションを設定して構成できます。このオプションを選択すると、他の GPO がこのポリシーの一環として構成された設定を上書きすることを禁止します。
セキュリティ テンプレート
グループ ポリシー テンプレートはテキスト ベースのファイルです。これらのファイルの変更は、Microsoft 管理コンソール (MMC) のセキュリティ テンプレート スナップインまたはメモ帳のようなテキスト エディタを使用します。テンプレート ファイルのセクションの中には、SDDL (Security Descriptor Definition Language) によって定義された ACL を含むものがあります。セキュリティ テンプレートの編集および SDDL の詳細は、Microsoftｮ MSDNｮ を参照してください。
テンプレートの集中化
本稼働用に使用するセキュリティ テンプレートは、自社環境内の安全な場所に保存することが非常に重要です。ここにアクセスできるのは、グループ ポリシーの施行を担当する管理者だけです。既定では、セキュリティ テンプレートはすべての Windows 2000 コンピュータの %SystemRoot%\security\templates フォルダに保存されます。
このフォルダが複数の DC 上で複製されることはありません。したがって、セキュリティ テンプレートのマスタ コピーを含む DC を選択する必要があります。これにより、セキュリティ テンプレートのバージョン管理の問題が発生することを防ぐことができます。また、常に同一のセキュリティ テンプレートのコピーを修正することができます。
時刻の構成
システム時刻が正確であり、すべてのサーバーが同一ソースの時刻を使用することは、非常に重要です。Windows 2000 W32Time サービスは、Active Directory ドメイン内で稼働している Microsoftｮ Windowsｮ 2000 および Microsoftｮ Windowsｮ XP ベースのコンピュータの時刻の同期を取ります。
W32Time サービスを利用することにより、Windows 2000 ベース コンピュータのクライアントのクロックはドメイン内の DC と同期を確実に取ることができます。これは、Kerberos バージョン 5 認証プロトコルが正しく機能するために必要です。時刻の同期化は、イベント ログの分析にも役に立ちます。
Kerberos は MIT が開発したネットワーク認証プロトコルです。Kerberos はネットワークにログオンしようとするユーザーの身元を認証し、秘密キー暗号化方式によって通信内容を暗号化します。
W32Time サービスは、RFC 1769 で説明されるとおり、簡易ネットワーク時刻プロトコル (SNTP) を使用して、クロックの同期を取ります。Windows 2000 Server では、次の方法で時刻の同期を取ります。
フォレストのルート ドメインにあるプライマリ ドメイン コントローラ (PDC) エミュレータ操作マスタは組織の権限を持つ時間ソースとなります。
フォレスト内の他のドメインにあるすべての PDC 操作マスタは、時間の同期元となる PDC エミュレータを選択するときドメインの階層に従います。
ドメイン内のすべての DC は、インバウンド タイム パートナーとしてドメイン内の PDC エミュレータ 操作マスタの時間と同期を取ります。
すべてのメンバ サーバーおよびクライアント デスクトップ コンピュータは認証を行う DC をインバウンド タイム パートナーとして使用します。
時刻の精度を確実にするため、フォレストのルート ドメインの PDC エミュレータは外部の SNTP タイム サーバーと同期を取ることができます。しかしそれを行うには、ファイアウォール上にポートを開くことが必要になります。実施する前に、これらの構成を変更する潜在的なセキュリティ リスクと利益を比較検討します。
多くの場合、すべてのサーバーが外部の時刻ソースと同期を取る必要はありません。組織のネットワーク内で同一の時刻ソースと同期が取れていれば十分です。
ネットワーク上のコンピュータで、Microsoftｮ Windowsｮ 95 または Microsoftｮ Windowsｮ 98 オペレーティング システムが稼働している場合、ログオン スクリプトで次のコマンドを使用して、これらのコンピュータのクロックの同期を取ります。ここで、 <timecomputer> はネットワーク上のドメイン コントローラを指します。
このコマンドを実行することにより、これらのコンピュータのクロックはドメインの他のコンピュータと同じ時刻を示すようになります。
注 Windows 以外のオペレーティング システムが稼働しているネットワーク コンピュータも、Windows 2000 ドメインの PDC エミュレータに対してクロックの同期を取り、同一の時刻に基づいてイベントのログを記録できるようにします。
サーバーの役割を示す組織単位
組織のインフラストラクチャ サーバーの管理に先に使用した例を、Contoso のシナリオに合わせて拡張することもできます。この目標は、Active Directory 内にあるサーバーが自社環境のセキュリティ基準を確実に満たす一方で、すべてのサーバーをカバーするシームレスなグループ ポリシーを作成することにあります。
ドメイン ポリシー
このプロセスの最初のステップは、新しいドメイン レベルのポリシーを作成することです。その理由は、Windows 2000 の既定のドメイン ポリシーのセキュリティをさらに高める必要があるからです。管理者は新しいポリシーを作成して、それをドメイン GPO にリンクさせます。既定のポリシーに対するこの新しいポリシーの優先性を確実にするために、新しいポリシーを移動して、GPO リンクで最高の優先度を付けます。
既定のポリシーを直接修正して、新しいセキュリティ構成を作成することもできます。しかし、新しいポリシーを作成することの利点は、新しいポリシーに問題があった場合には、それを容易に無効にすることができ、既定のポリシーを復活させて管理を再開できることです。
ベースライン ポリシー
2 番目のステップは、ベースライン ポリシーを作成することです。そのためには、ベースライン セキュリティ テンプレートを作成して、ポリシーにインポートします。この機能を提供するために、このソリューションには MSS Baseline.inf が含められています。この GPO ソリューション テンプレートをメンバ サーバー OU にリンクさせます。MSS Baseline.inf セキュリティ テンプレートはベースライン ポリシーの設定をメンバ サーバー OU 内の任意のサーバーならびに子 OU 内の任意のサーバーに適用します。
ベースライン ポリシーには、組織全体のすべてのサーバーにとって望ましい設定を選択します。また、ベースライン ポリシーは可能な限り限定的にします。そして、ベースライン ポリシーとは異なるポリシーが必要なサーバーがある場合、インフラストラクチャ サーバー OU などそのサーバーに固有な OU としてセグメント化します。
サーバーの役割を示す組織単位
上の例を続ける際、インフラストラクチャ サーバー ポリシーに対する変更の増分に別のポリシーを作成します。インフラストラクチャ サービスの機能を確実にするために必要で、ネットワーク上でアクセス可能な設定を、MSS Infrastructure Role.inf と呼ばれるセキュリティ テンプレートに含ませることができます。
この GPO インフラストラクチャ テンプレートをインフラストラクチャ OU にリンクさせます。最後に、制限されたグループの設定を使用して、次の 3 つのグループをインフラストラクチャ ポリシー GPO 内のローカル管理者グループに追加します。追加する具体的なグループは、ドメイン管理者、エンタープライズ管理者、およびインフラストラクチャ管理者の 3 つです。
このプロセスを下図に示します。
.gif)
図 5.3: 増分グループ ポリシーの構成
前述のとおり、これは GPO の展開に組織単位の構造を作成する、数多くの可能な方法の 1 つにすぎません。グループ ポリシー実施のための OU 作成の詳細は、Microsoftｮ TechNet の記事「Best Practice Active Directory Design for Managing Windows Networks」を参照してください (https://technet.microsoft.com/ja-jp/library/bb727085.aspx)。
本書では、いくつかのサーバーの役割を定義します。上記のプロセスに基づき、これらの役割のセキュリティを高めるため、次のようなセキュリティ テンプレートの表を作成しました。
表 5.1 Windows 2000 サーバーの役割
| サーバーの役割 | 説明 | セキュリティ テンプレート |
|---|---|---|
| Windows 2000 ドメイン コントローラ | Active Directory ドメイン コントローラを含むグループ。 | MSS DCBaseline.inf |
| Windows 2000 メンバ サーバー | ドメインのメンバであるすべてのサーバーであり、メンバ サーバー OU 内またはその下に常駐。 | MSS Baseline.inf |
| Windows 2000 ファイル サーバーとプリント サーバー | ロックされたファイル サーバーおよびプリント サーバーを含むグループ。 | MSS FilePrint Role.inf |
| Windows 2000 インフラストラクチャ サーバー | ロックされた DNS、WINS、および DHCP の各サーバーを含むグループ。 | MSS Infrastructure Role.inf |
| Windows 2000 IIS サーバー | ロックされた IIS サーバーを含むグループ。 | MSS IIS Role.inf |
すべての増分テンプレート ファイルは、メンバ サーバー OU の下の OU に適用されることが前提です。そのため、組織内で下位レベルの各 OU が果たす役割を定義するには、MSS Baseline.inf とそれぞれの増分ファイルの両方を適用する必要があります。
これらの各役割のセキュリティ要件は異なります。各役割に適切なセキュリティ設定は、第 7 章「特定サーバーの役割のハードニング」で詳細を説明します。
重要 このガイドでは、Windows 2000 サーバーは特定の定義された役割を実行するものと想定しています。自社組織のサーバーの役割がこれに合致しない場合、または多目的なサーバーを使用している場合は、ここに定義されている設定をガイドラインとして使用して、独自のセキュリティ テンプレートを作成してください。しかし、各サーバーが果たす機能が多ければ多いほど、攻撃を受けたときの脆弱性が高くなることに留意してください。
これらの定義されているサーバーの役割をサポートする、最終的な OU 設計を下図に示します。
.gif)
図 5.4: OU 設計の例
Contoso の OU、GPO、および管理グループの設計
Contoso は 上記の推奨事項を応用して、自社 Windows 2000 サーバーの既存の OU 構造を再構築しました。それに加えて、Contoso の管理者はあらかじめ定義された管理の境界を使って、自社の管理グループを作成しました。これらのグループとグループが管理する OU との相互関係を下表に示します。
表 5.2 Contoso の OU と管理グループ
| OU 名 | 管理グループ |
|---|---|
| ドメイン コントローラ | ドメイン技術 |
| メンバ サーバー | ドメイン技術 |
| インフラストラクチャ | 運用 |
| ファイルとプリント | 運用 |
| Web | Web サービス |
Contoso では、各管理グループは北米子ドメインのグローバル グループとして作成されました。
Contoso は、制限された各グループに対応する GPO を使用して、これらの各管理グループを制限された適切なグループに追加しました。先に作成した管理グループは、OU 内にあるコンピュータのローカル管理者グループだけのメンバになります。この OU には、ジョブ機能に関連するコンピュータだけが含まれます。
最後にContoso は各 GPO にアクセス許可を設定して、ドメイン技術グループの管理者だけが、それらを変更できるようにしました。
既定では、新しい OU 構造はセキュリティ設定の多くを親のコンテナから継承します。各 OU の [継承可能なアクセス許可を親からこのオブジェクトに継承できるようにする] チェック ボックスをオフにします。管理者によって以前に追加されたと思われる不要なグループはすべて削除し、各サーバーの役割を表す OU に対応するドメイン グループだけを追加します。ドメイン管理者グループには [フル コントロール] の設定を維持します。
これらの OU の設定に必要なタスクを、特定の順序で遂行する必要はありません。しかし、ある程度の依存関係があることは明らかです。たとえば、別の OU の制御をドメイン グループに委任するには、委任先のドメイン グループが存在していることが必要です。これらのタスクの遂行に推奨される順序を次の一覧に示します。
OU 構造を作成します。
コンピュータを適切な OU に移します。
管理グループを作成します。
管理グループに適切なドメイン アカウントを追加します。
各 OU の管理を適切なドメイン グループに委任します。
グループ ポリシーを適用先の OU に作成します。
必要に応じて、各グループ ポリシーを任意の追加 OU にリンクさせます。
適切なセキュリティ テンプレートを各 GPO にインポートします。
各 GPO にアクセス許可を設定して、適切なドメイン グループがその GPO を管理できるようにします。
各 GPO の制限されたグループに適切なドメイン グループを追加します。
グループ ポリシーをテストして調整します。
ドメイン ポリシー
グループ ポリシーによるセキュリティの設定は組織内の種々のレベルに適用されます。Contoso はグループ ポリシーを使用して、次の 3 つのレベルにセキュリティ設定の適用を決定しました。
ドメイン レベル — すべてのサーバーで強制されるアカウント ポリシーなど、共通のセキュリティ要件に対処する。
ベースライン レベル — ネットワーク内のすべてのサーバーに共通の、サーバー セキュリティに固有の要件に対処する。
役割に固有 — 役割に固有のセキュリティ要件に対処する。たとえば、インフラストラクチャ サーバーとインターネット インフォメーション サービス (IIS) を実行しているサーバーとでは、セキュリティ要件は異なります。
セキュリティ監査の観点から、IIS はログ ファイルを作成して、Web、ファイル転送プロトコル (FTP)、ネットワーク ニュース トランスポート プロトコル (NNTP)、および簡易メール転送プロトコル (SMTP) の各サービスへの接続の試みを追跡します。
ドメイン ポリシーの概要
グループ ポリシーはネットワーク上のすべてのコンピュータに標準の構成を適用できるため、非常に強力です。ドメインまたはそのサブセット内のすべてのコンピュータにセキュリティ上の変更を同時に実施する手段を管理者に提供するため、GPO はあらゆる企業の構成管理ソリューションの相当な部分を占めます。
グループ ポリシー経由で同時に適用できるセキュリティの変更には、次のものがあります。
ファイル システムのアクセス許可の変更
レジストリ オブジェクトのアクセス許可の変更
レジストリ内の設定の変更
ユーザー権利の割り当ての変更
システム サービスの構成
監査およびイベント ログの構成
アカウント ポリシーおよびパスワード ポリシーの設定
これらのセキュリティの変更に影響するグループ ポリシーの設定は、Windows 2000 Server コンピュータ ポリシーの複数のセクションに分けられます。
表 5.3 Windows 2000 Server コンピュータ ポリシーのセクション
| UI 内のポリシー セクション名 | 説明 |
|---|---|
| アカウント ポリシー\パスワードのポリシー | パスワードの期間、長さ、および複雑さを構成します。 |
| アカウント ポリシー\アカウント ロックアウトのポリシー | ロックアウトの期間、しきい値、およびリセット カウンタを構成します。 |
| アカウント ポリシー\Kerberos ポリシー | チケットの有効期間を構成します。 |
| ローカル ポリシー\監査ポリシー | 特定のイベントの記録を有効または無効にします。 |
| ローカル ポリシー\ユーザー権利の割り当て | ローカル ログオンやネットワーク アクセスなど権利を定義します。 |
| ローカル ポリシー\セキュリティ オプション | 特定のセキュリティに関するレジストリ値を修正します。 |
| イベント ログ | 成功および失敗の監視を有効にします。 |
| 制限されたグループ | 誰が特定のグループに所属するかを管理者が制御します。 |
| システム サービス | 各サービスの起動モードを制御します。 |
| レジストリ | レジストリ キーに関するアクセス許可および監査を構成します。 |
| ファイル システム | フォルダ、サブフォルダ、およびファイルに関するアクセス許可および監査を構成します。 |
すべてのコンピュータにあらかじめローカル ポリシーが定義されています。Active Directory ドメインが最初に作成されるときに、既定のドメイン ポリシーおよびドメイン コントローラ ポリシーも作成されます。既定のポリシーを修正する代わりに、新しいポリシーを作成してドメインにリンクさせます。これにより、任意の設定により環境内で原因不明の問題が発生した際に、すばやくロールバックできます。既定の変更を修正する場合は、修正前の内容を記録しておくことが重要です。これにより、問題が発生した場合、以前の状態に容易に戻すことができます。
.gif)
図 5.5: ドメイン ポリシーの適用
次に、ドメイン レベルで検討および文書化する設定を説明します。
アカウント ポリシー
アカウント ポリシーはドメイン レベルで施行します。Windows 2000 Server ドメインには、そのドメインに単一のパスワード ポリシー、アカウント ロックアウト ポリシー、および Kerberos バージョン 5 ポリシーが必要です。これらのポリシーを Active Directory の任意の他のレベルに設定した場合、メンバ サーバー上のローカル アカウントだけが影響を受けます。別々のパスワード ポリシーを必要とする複数のグループがある場合、その他の要件に基づいて、これらのグループを別々のドメインまたはフォレストにセグメント化します。
パスワードのポリシー
Windows 2000 Server でユーザーの身元確認を行う最も一般的な方法は、秘密のユーザー パスワードを使用する方法です。身元が確認および認証されると、ユーザーは許可されている任意のタスクを実行し、許可されている任意のリソースにアクセスできます。
自社環境の Active Directory をセキュリティで保護するには、すべてのユーザーが強力なパスワードを使用することが必要です。これにより、許可されていないユーザーが手動またはツールを使って弱いパスワードを推測し、解読されたユーザー アカウントの資格情報を取得する危険を防ぐことに役立ちます。管理アカウントについて、このことは特に重要です。
定期的なパスワードの変更は、パスワード攻撃が成功する可能性を低下させます。パスワード ポリシーの設定は、パスワードの複雑さ、および有効期間を制御します。パスワード ポリシーの個々の設定事項について、次に説明します。
次の値は、下記の場所にあるドメイン グループ ポリシーの設定で構成できます。
コンピュータの構成\Windows の設定\セキュリティの設定\アカウント ポリシー\パスワードのポリシー
パスワードの履歴を記録する
脆弱性
パスワードの再使用はどんな組織においても大きな懸案事項です。この脆弱性を裏づけするパスワード再使用の問題点は、少なくとも 3 つあります。
組織内の複数のアカウントへのパスワードの再使用。ユーザーや管理者が別々のドメインに複数のアカウントを持っている場合、または単一のドメインに複数の機能があるため複数のアカウントを持っている場合によく見られます。複数のアカウントに同一のパスワードを共有します。
任意のアカウントへの長期間にわたる同一パスワードの使用または再使用。ユーザーがパスワードの変更を要求されても、古いパスワードの使用を防止する仕組みがなかったり、少数のパスワードを繰り返し再使用することが可能である場合、強いパスワード ポリシーの有効性は大幅に低下します。
複数のサービス アカウントへの同一パスワードの再使用。組織が複数のサービス アカウントを使用する必要がある場合、基本的なパスワード要件を超える一意のパスワードを各アカウントに割り当て、パスワードの割り出しがきわめて困難になるようにします。
パスワードの履歴を記録する設定では、任意のユーザー アカウントの古いパスワードが再使用可能となるために、必要とされる新しい一意のパスワード数を指定します。
この設定に低い値を指定すると、ユーザーは同じ少数のパスワードを繰り返し継続して利用できます。またパスワードの変更禁止期間を指定しないと、ユーザーは必要に応じて何回でも続けてパスワードを変更して、元のパスワードを再使用することができます。
パスワードの履歴を記録する設定を組織で有効にするために、パスワードの変更禁止期間を指定して、パスワードを即座に変更できないようにします。
対策
[パスワードの履歴を記録する] の値を「24」に設定します。ここで設定できる値は 0 ～ 24 パスワードです。この設定は既定ドメイン コントローラ GPO に定義されており、ワークステーションおよびサーバーのローカル セキュリティ ポリシーには値が 1 に設定されています。この値を最大に設定すると、パスワードの再使用による脆弱性を最小にすることができます。
潜在的な影響
この設定がもたらす大きな影響は、古いパスワードの変更を求められると、ユーザーは毎回新しいパスワードの使用が必要になることです。新しい一意の値にパスワードを変更することをユーザーに求めるため、忘れたときに備えてパスワードをメモに書き留めるユーザーが出てくるリスクが増大します。
この値は、組織内のすべてのユーザーに適切なパスワード変更間隔の要件とパスワードの有効期間を考慮して設定します。
Contoso のシナリオ
Contoso のシナリオでは、[パスワードの履歴を記録する] の値を「24」に設定しました。
パスワードの有効期間
脆弱性
どんなパスワードも割り出される可能性があります。現在のコンピュータの能力があれば、時間と労力次第で最も複雑なパスワードでも割り出すことができます。次に記述する設定のいくつかを採用すると、順当な時間内でのパスワードの割り出しを困難にすることができます。環境内でのユーザー パスワードの頻繁な変更は、有効なパスワードが割り出されるリスクの低下につながるとともに、不当に取得されたパスワードが使用されるリスクの緩和に役立つ可能性もあります。
パスワードの有効期間の設定では、ユーザーがパスワードの変更を求められるまでに、1 つのパスワードを使用できる日数を指定します。ユーザーがパスワードをまったく変更しなくてもよいように、パスワードの有効期間を設定できます。しかしその結果、重大なセキュリティ リスクを招くことになります。
対策
[パスワードの有効期間] を 30 ～ 60 日に設定します。パスワードの有効期間は 1 ～ 999 日後に失効するように設定できます。または、日数の値を 0 にすると、有効期間を無限に設定できます。この設定は既定ドメイン コントローラ GPO に定義されており、ワークステーションおよびサーバーのローカル セキュリティ ポリシーには値が 42 日に設定されています。
潜在的な影響
パスワードの有効期間の日数を低すぎる値に設定すると、ユーザーは非常に頻繁にパスワードの変更を要求されます。これにより、忘れたときに備えてユーザーがパスワードをメモに書き留める可能性が増えるため、実際には組織のセキュリティが低下する可能性があります。
高すぎる値に設定すると、潜在的な攻撃者がユーザーのパスワードを割り出すチャンスは大きくなるため、組織のセキュリティの水準が低下する可能性があります。
Contoso のシナリオ
Contoso のシナリオでは、[パスワードの有効期間] を既定値の「42 日」に設定しました。この結果、ユーザーは頻繁にパスワードの変更を要求されますが、高すぎる頻度には設定していないためユーザーの手間は最小限になり、Contoso のセキュリティは向上しました。
パスワードの変更禁止期間
脆弱性
任意のパスワードの再使用を希望するユーザーは、定期的にパスワードを変更する必要があります。過去の 12 パスワードを再使用できないようにパスワード ポリシーが設定されている場合、ユーザーはパスワードを 13 回連続して変更した後、最初に使ったパスワードを再使用できます。
パスワードの変更禁止期間の設定では、パスワードの変更が可能になるまでに、ユーザーが 1 つのパスワードを使用しなくてはならない日数を指定します。パスワードの変更禁止期間の値はパスワードの有効期間の値よりも小さくなければなりません。
前述のとおり、パスワードの変更を記録する設定を有効にするためには、パスワードの変更禁止期間を 0 よりも大きい値で設定する必要があります。パスワードの変更禁止期間を設定しないと、ユーザーはパスワードを立て続けに変更して所定の変更回数をすぐに消化して、古いお気に入りのパスワードを再使用できるようになってしまいます。
対策
[パスワードの変更禁止期間] の値を「2 日」に設定します。この値は 1 ～998 日のいずれかに設定できます。この日数を 0 に設定すると、直ちにパスワードを変更することが可能になるため、お勧めできません。既定ドメイン コントローラ GPO にはこの設定は定義されていないので、ワークステーションおよびサーバーのローカル セキュリティ ポリシーではパスワードを直ちに変更することが可能です。
潜在的な影響
パスワードの変更禁止期間の日数を 0 よりも大きく設定することに、些細な問題が 1 つあります。管理者がユーザーのパスワードを設定し、管理者によって定義されたパスワードをそのユーザーに変更してもらうとします。その場合、管理者は [ユーザーは次回ログオン時にパスワード変更が必要] チェック ボックスをオンにする必要があります。そうしないと、ユーザーは翌日までパスワードを変更できません。
Contoso のシナリオ
Contoso のシナリオでは、 [パスワードの変更禁止期間] の値を 「2 日」に設定しました。ユーザーが必要な回数のパスワード変更を即座に行って、古いパスワードを再使用するのを抑制するためです。
パスワードの長さ
脆弱性
特定のユーザー アカウントのパスワードを入手するために行われるパスワード攻撃は何種類かあります。その中には、一般的な語句を使用する辞書攻撃や数字と文字の可能なすべての組み合わせを試してみるブルートフォース攻撃があります。それに加えて、LM パスワード ハッシュを入手し、ユーティリティを使用してハッシュを解読してパスワードを入手する攻撃もあります。
パスワードの長さはユーザー アカウントのパスワードを構成する最小の文字数を示します。組織にとって最善のパスワードの長さを決定する説は数多くあります。
対策
[パスワードの長さ] の値を少なくとも「8」に設定します。この値には 1 ～14 文字のどれかを指定できます。文字数を 0 に設定した場合は、パスワードは不要です。この設定は既定ドメイン コントローラ GPO に定義されており、ワークステーションおよびサーバーのローカル セキュリティ ポリシーには値が 0 に設定されています。
ほとんどの環境において、8 文字以上のパスワードが推奨されています。適切なセキュリティを図るために十分な長さであり，ユーザーが比較的容易に覚えられる短さであるからです。この設定はブルートフォース攻撃に対する適切な防御策となります。複雑さの要件を追加すると、辞書攻撃に屈する可能性を低くする役に立ちます。複雑さの要件については、次項で説明します。
パスワード ハッシュに対する攻撃については、第 6 章「Base Windows 2000 Server のハードニング」で詳細を説明します。
潜在的な影響
要求するパスワードが短すぎると、セキュリティは低下します。短いパスワードは、パスワードに対して辞書攻撃またはブルート フォース攻撃を実行するツールを使用して、容易に割り出すことができるためです。要求するパスワードが長すぎると、パスワードの入力ミスを招くことになります。これによりアカウントのロックアウトが生じ、結果としてヘルプ デスクへの電話件数が増大する可能性があります。
要求するパスワードがあまりにも長すぎると、実際には組織のセキュリティが低下します。これは、忘れることを恐れたユーザーが、パスワードをメモに書き留める可能性が高くなるからです。
Contoso のシナリオ
Contoso のシナリオでは、[パスワードの長さ] の値を「8」に設定しました。
パスワードは要求する複雑さを満たす
脆弱性
英数字だけで構成されるパスワードは、一般に入手可能ないくつかのユーティリティを使用して、きわめて容易に割り出すことができます。これを防止するためには、パスワードに記号や要件を追加する必要があります。
[パスワードは要求する複雑さを満たす] 設定では、強いパスワードに重要であると考えられる一連のガイドラインを、パスワードが満たす必要があるかどうかを指定します。
このポリシーが有効に設定されている場合、パスワードは次の要件を満たす必要があります。
パスワードにユーザー アカウント名の全体または一部が含まれていない
パスワードの長さは少なくとも 6 文字である
パスワードに、次の 4 カテゴリのうち 3 種類が含まれている
英語のアルファベットの大文字 (A - Z)
英語のアルファベットの小文字 (a - z)
10 進数の数字 (0 - 9)
記号 (たとえば、!、$、#、% など)
これらの複雑さの要件はパスワードの変更または新しいパスワードの作成の際に適用されます。
Windows 2000 Server のポリシーに含まれているルールを直接修正することはできません。しかし、passfilt.dll の新しいバージョンを作成して、別の一連のルールを適用することができます。passfilt.dll のソース コードはマイクロソフト サポート技術情報 (KB) の記事151082「[HOWTO] Windows NT でのパスワード変更のフィルタリングと通知」に収録されています。
対策
[パスワードは要求する複雑さを満たす] の値を [有効] に設定します。既定ドメイン コントローラ GPO、ワークステーションおよびサーバーのローカル セキュリティ ポリシーにおいては、これは無効に設定されています。
この設定と最低限 8 文字のパスワードの長さを組み合わせると、単一のパスワードに少なくとも 218,340,105,584,896 通りの組み合わせがあることになります。したがって、不可能ではないまでも、ブルートフォース攻撃を行うことが非常に困難になります。
潜在的な影響
既定の passfilt.dll を有効にすると、アカウントがロックアウトされたユーザーからヘルプ デスクにかかってくる電話の件数が増える可能性があります。これは、ユーザーは英数字以外が含まれるパスワードに慣れていない可能性があるためです。しかし、この設定は順当であり、多少練習するだけで、すべてのユーザーはこの要件を満たせるようになります。
カスタム passfilt.dll に含めることができる追加の設定に、上段文字を使用することがあります。上段文字とは、SHIFT キーを押しながら、1-10 の数字をタイプして入力する文字です。
また ALT キーと文字とを組み合わせると、パスワードの複雑さは大幅に増大します。しかし、組織内のすべてのユーザーにそのような厳密なパスワード要件の遵守を求めると、ユーザーは混乱してヘルプ デスクに問い合わせが殺到する可能性があります。すべての管理者のパスワードの一部として、 0128 ～ 0159 の範囲の ALT 文字を使用するという要件の施行を検討してみてください。この範囲外の ALT 文字は標準の英数字を表し、パスワードに複雑さを追加することにはなりません。
Contoso のシナリオ
Contoso のシナリオでは、[パスワードは要求する複雑さを満たす] の値を [有効] に設定しました。
暗号化を元に戻せる状態でドメインのすべてのユーザーのパスワードを保存する
脆弱性
アプリケーションの中には、追加の機能を提供するために、ユーザー パスワードへのアクセスを要求するものがあります。このため「元に戻せる暗号化フォーマット」でパスワードを保存することがよくありますが、これは安全ではありません。
[暗号化を元に戻せる状態でドメインのすべてのユーザーのパスワードを保存する] の設定では、Windows 2000 Server が平文を使用するのと同等の、非常に弱いフォーマットでパスワードを保存するかどうかを指定します。この設定を使用すると、環境内のパスワードは弱くなります。平文のメッセージは暗号化されません。平文のメッセージは単純テキスト メッセージとも言われます。
潜在的な影響
このポリシーが必要なのは、リモート アクセスを通じて CHAP プロトコルを使用する場合、またはインターネット認証サービス (IAS) のサービスを使用する場合です。IIS でダイジェスト認証を使用する場合にも、このポリシーは必要です。この設定は、グループ ポリシーを使用してユーザーごとに適用するには、非常に危険です。これは、Active Directory のユーザーおよびコンピュータ管理コンソールで、適切なユーザー アカウント オブジェクトを開くことを必要とするためです。
警告 このポリシーはアプリケーションの要件がパスワード情報を保護する必要性よりもはるかに高くならない限り、決して有効にしないでください。
対策
[暗号化を元に戻せる状態でドメインのすべてのユーザーのパスワードを保存する] の値を必ず [無効] に設定します。既定ドメイン コントローラ GPO、ワークステーションおよびサーバーのローカル セキュリティ ポリシーでは、この設定は無効になっています。
Contoso のシナリオ
Contoso のシナリオでは、[暗号化を元に戻せる状態でドメインのすべてのユーザーのパスワードを保存する] は [無効] の設定のままです。
パスワード ポリシーの要約
どのドメイン ポリシーが設定されていても、[ユーザーは次回のログオン時にパスワード変更が必要]、[ユーザーはパスワードを変更できない]、[パスワードを無期限にする]、[暗号化を元に戻せる状態でパスワードを保存する] の各設定を、任意の個人ユーザーに構成することができます。ユーザーの [プロパティ] ダイアログ ボックスの [アカウント] タブにアクセスして、これを実行します。ここで設定した個人ユーザーのパスワード ポリシーは、ドメイン ポリシーよりも優先されます。
Contoso のパスワード ポリシーの設定を要約して下表に示します。
表 5.4 Contoso のパスワード ポリシー
| UI 内でのパスワード ポリシー名 | 設定 |
|---|---|
| パスワードの履歴を記録する | 24 パスワードを記憶 |
| パスワードの有効期間 | 42 日 |
| パスワードの変更禁止期間 | 2 日 |
| パスワードの長さ | 8 文字 |
| パスワードは要求する複雑さを満たす | 有効 |
| 暗号化を元に戻せる状態でドメインのすべてのユーザーのパスワードを保存する | 無効 |
アカウント ロックアウトのポリシー
システムにログオンしようとて間違ったパスワードが数回以上、入力される場合、攻撃者がアカウントのパスワードを割り出そうとして試行錯誤している可能性があります。Windows 2000 Server はログオンを記録しているので、事前に設定された期間このアカウントを無効にすることで、この種の潜在的な攻撃に対処するようにオペレーティング システムを構成できます。
アカウント ロックアウト ポリシーの設定では、この対応のしきい値、およびしきい値に達した場合に取る措置を指定します。
ロックアウト期間
脆弱性
攻撃者がアカウント ロックアウトのしきい値を悪用して、アカウントへのログインを繰り返し試みると、サービス拒否 (DoS) となる可能性があります。アカウント ロックアウトのしきい値を設定すると、指定した回数以上ログインが失敗する場合に、そのアカウントはロックアウトされます。
[ロックアウト期間] の設定では、ロックアウトされたアカウントが使用できなくなる分数を指定します。
対策
[ロックアウト期間] の値を「30 分」に設定します。ロックアウト期間に設定できる値は 1 ～ 99,999 分のどれかです。アカウントが決してロックアウトされないように指定するには、値を 0 に設定します。この設定は既定ドメイン コントローラ GPO、ワークステーションやサーバーのローカル セキュリティ ポリシーには定義されていません。
潜在的な影響
ロックが決して自動解除しないようにこの設定の値を構成することは、良いアイデアだと思えます。しかしこの結果、誤ってロックされてしまったアカウントのロック解除を依頼する電話がヘルプ デスクにかかってくる件数が増える可能性があります。
Contoso のシナリオ
Contoso のシナリオでは、[ロックアウト期間] を「30 分」に設定しました。ユーザーが自分のアカウントからロックアウトされたため、ヘルプ デスクに依頼するサポートの電話件数を減らすのに役立ちました。
アカウントのロックアウトのしきい値
脆弱性
パスワード攻撃には、任意またはすべてのユーザー アカウントに対して、数千ものパスワードの組み合わせを自動的に試みる方法が使用されることがあります。ログオンの失敗回数を制限することにより、こうした攻撃の有効性をほとんどゼロにすることができます。
しかし、ロックアウトのしきい値が構成されているドメインに対して、DoS 攻撃が可能になることに注意してください。悪意のある攻撃者は、組織内のすべてのユーザーに対して、パスワード攻撃をプログラムで試みることができます。ログオンの回数がロックアウトのしきい値よりも大きい場合には、攻撃者はすべてのアカウントをロックアウトする可能性があります。
ロックアウトのしきい値の設定では、ユーザー アカウントのロックアウトを引き起こす、ログオンの失敗回数を指定します。[アカウントのロックアウトのしきい値] を定義した場合、[ロックアウト期間] はリセット時間以上でなければなりません。
対策
既定では、このポリシーは既定ドメイン コントローラ GPO、ワークステーションやサーバーのローカル セキュリティ ポリシーでは値が 0 に設定されています。アカウントのロックアウトのしきい値の最大値は 999 です。
この値が設定されている場合でも、設定されていない場合でも、共に脆弱性は存在します。したがって、2 通りの対策が定義されています。どの組織も、特定の脅威や緩和するリスクに基づいて、2 つの選択肢を比較してみます。この設定に、検討する選択肢は 2 つあります。
[アカウントのロックアウトのしきい値] を「0」に設定します。この場合、アカウントがロックアウトされることはありません。この設定は、すべて (または一部) のアカウントを意図的にロックアウトする DoS 攻撃を防止する役に立ちます。それに加えて、ユーザーが誤って自分のアカウントからロックアウトされることがないため、ヘルプ デスクへの問い合わせ件数を減らす効果があります。ただし、この設定では、ブルートフォース攻撃を防ぐことはできません。したがって、以下の 2 つの基準が確実に満たされる場合にのみ、この設定を選択します。
すべてのユーザーが 8 文字以上の複雑なパスワードを使用するように、パスワード ポリシーが確立されている。
強力な監査機構が設置されており、環境内で一連のアカウントのロックアウトが発生している場合、管理者に警告される。
上記の基準が満たされない場合、[アカウントのロックアウトのしきい値] を高めに設定します。この値は、ユーザーがパスワードを誤って入力した場合でも、すぐにはアカウントがロックアウトされることはないが、ブルートフォース攻撃があった場合にはアカウントがロックアウトされる程度にします。この場合、この値を非常に大きくして、たとえば無効なログオンの試みが 50 回あった場合にアカウントをロックアウトすることをお勧めします。この結果、誤ってアカウントがロックアウトされることはなくなり、ヘルプ デスクへの問い合わせ件数は減りますが、上述の DoS 攻撃を防止することはできません。
潜在的な影響
ロックアウトのしきい値を設定した場合、ロックアウトされたアカウントは、管理者がそのアカウントをリセットするか、ロックアウト期間が経過するまで使用できなくなります。この設定を行うと、ヘルプ デスクへの問い合わせ件数が増える可能性があります。
ロックアウトのしきい値を 0 に設定した場合、ブルートフォース攻撃を加えてパスワードを割り出そうとする攻撃者の試みを検出できない可能性があります。
Contoso のシナリオ
Contoso のシナリオでは、[アカウントのロックアウトのしきい値] の無効なログオン回数を「50」回としました。この値に設定すると、ユーザーが誤って自分のアカウントからロックアウトされることがなく、また脆弱性の自動スキャン ツールによってユーザーがロックアウトされることもありません。しかしブルートフォース攻撃を確実に防止します。
ロックアウト カウントのリセット
脆弱性
ユーザーが何回かパスワードの入力を誤ると、誤って自分のアカウントからロックアウトされてしまうことがあります。この確率を下げるため、[ロックアウト カウントのリセット] を設定して、ログオンが失敗してから無効なログオン カウンタを 0 にリセットするまでに必要な経過時間を指定します。
[アカウントのロックアウトのしきい値] を定義する場合、このリセット時間は [ロックアウト期間] 以下であることが必要です。
対策
[ロックアウト カウントのリセット] の値を「30 分」に設定します。この設定に指定できる値の範囲は 1 ～ 99,999 分のいずれかです。この設定は既定ドメイン コントローラ GPO またはワークステーションやサーバーのローカル セキュリティ ポリシーには定義されていません。
潜在的な影響
この値を設定しない、または長すぎる間隔を設定すると、DoS 攻撃を受ける可能性があります。攻撃者は組織内のすべてのユーザーに対して意図的に無効なログオンの試みを繰り返し実行します。すると、上述のとおり、これらのユーザー アカウントはロックアウトされてしまいます。ロックアウトされたアカウントをリセットするポリシーが設定されていないと、管理者がすべてのアカウントのロックを手動で解除する必要があります。適切な値を設定すれば、ユーザーはしばらくロックアウトされますが、この期間が過ぎればアカウントは自動的にロック解除されます。
Contoso のシナリオ
Contoso のシナリオでは、[ロックアウト カウントのリセット] の値を「30 分」に設定して、ブルートフォース攻撃に対するセキュリティのレベルを高めました。
アカウント ロックアウト ポリシーの要約
一般に、組織内のセキュリティを高めるためには、ロックアウト期間の設定値を大きくし、ロックアウトのしきい値の設定を小さくします。Contoso におけるアカウント ロックアウト ポリシーの設定を要約して下の表に示します。
表 5.5 Contoso におけるアカウント ロックアウト ポリシーの設定
| UI 内のアカウント ロックアウト ポリシー名 | 設定 |
|---|---|
| ロックアウト期間 | 30 分 |
| ロックアウトのしきい値 | 50 回の無効なログオンの試行 |
| ロックアウト カウントのリセット | 30 分 |
Contoso の設定では、30 分間に無効なログオンを 50 回行うと、ユーザーは自分のアカウントからロックアウトされます。30 分経つと、アカウントは自動的にリセットされます。30 分経たないうちにアカウントをリセットする必要がある場合には、アカウントの管理者が手動で処理する必要があります。
Kerberos ポリシー
Windows 2000 Server では、Kerberos バージョン 5 が既定の認証プロトコルになっています。このプロトコルにより、ユーザーがリソースにアクセスし、そのリソース上でタスクを実行するために必要なサービスおよびデータを認証します。Kerberos チケットの有効期間を短くすることにより、攻撃者が適正なユーザーの資格情報を盗み、悪用してしまうリスクは減少します。しかし、認証のオーバヘッドは増加します。
ほとんどの環境においては、この設定を変更する必要はありません。
Kerberos ポリシーの要約
Contoso は、自社の Kerberos バージョン 5 のポリシーの既定の設定をそのまま維持することに決定しました。その設定を要約して下の表に示します。
表 5.6 Kerberos ポリシーの設定
| UI 内の Kerberos ポリシー名 | 設定 |
|---|---|
| ユーザー ログオンの制限を強制する | 有効 |
| サービス チケットの最長有効期間 | 600 分 |
| チケットの最長有効期間 | 10 時間 |
| ユーザー チケットを更新できる最長有効期間 | 7 日 |
| コンピュータの時計の同期の最長トレランス | 5 分 |
Kerberos ポリシーの設定は既定値のままです。そのため、Contoso の環境または、このソリューションに関連するジョブ エイドに含まれている MSS Domain.inf ファイルでは、Kerberos ポリシーの設定は特に定義されていません。
その他のポリシー
その他にも、Contoso のすべてのメンバ サーバーのベースライン ポリシーとして構成される数多くの追加ポリシーがあります。また、具体的なサーバーの役割の多くに行う追加の設定も数多くあります。この詳細は、第 6 章「Base Windows 2000 Server のハードニング」および第 7 章「特定サーバーの役割のハードニング」で説明します。
ポリシーの管理
セキュリティ テンプレートのインポート
次に、このガイドに付属のセキュリティ テンプレートをこの章で示した OU 構造にインポートする手順を示します。ドメイン コントローラ上で次の手順を実施する前に、自社環境の Windows 2000 Server 上に特定のポリシー (.inf) ファイルを配置する必要があります。
警告 このガイドに付属のセキュリティ テンプレートは、使用環境のセキュリティを高めるように設計されています。このセキュリティ テンプレートをインストールすることにより、組織環境の一部の機能が失われることがあります。失われる機能の中には、ミッション クリティカルなアプリケーションが含まれることもあります。
したがって、これらのセキュリティ テンプレートを本稼働に移す前に、十分にテストを行うことが不可欠です。何らかの新しいセキュリティの設定を適用する前に、環境内の各 DC およびサーバーのバックアップを取ってください。バックアップにはシステムの状態も含めて、レジストリの設定または Active Directory オブジェクトを復元できるようにしておいてください。
セキュリティ テンプレートをインポートする手順を進める前に、環境内のサーバーが少なくとも本書推奨の Windows 2000 SP3 を実行していない場合、サポート技術情報 (KB) 295444「SCE がサービスのレジストリ キーにあるサービスの SACL エントリを変更できない」に説明されている修正プログラムを適用してください。
この修正プログラムを適用しないと、グループ ポリシー テンプレートはどのサービスでも無効にできません。修正プログラムは、製品の障害対処に使用される 1 つ以上のファイルで構成される、単一の累積的なパッケージです。修正プログラムは特定のお客様の状況に対処するものであり、お客様の組織の外には通常は配布されません。ただし、マイクロソフトから文書による正式な同意を得た場合には、その限りではありません。QFE、パッチ、およびアップデートという用語も修正プログラムと同じ意味で使用されています。
ドメイン ポリシーのインポート
[Active Directory ユーザーとコンピュータ] 内の [ドメイン] を右クリックし、それから [プロパティ] を選択します。
新しい GPO を追加するために、[グループ ポリシー] タブの [新規作成] をクリックします。
[Domain Security Policy] と入力して、Enter キーを押します。
[Domain Security Policy] を右クリックして、[上書きなし] を選択します。
[Domain Security Policy] を選択して、[編集] をクリックします。
[グループ ポリシー] ウィンドウ内で、コンピュータの構成\Windows の設定をクリックします。[セキュリティの設定] を右クリックし、[ポリシーのインポート] を選択します。
[ポリシーのインポート] ダイアログ ボックス内で \SCI\ Security Templates に移動して、MSS Domain.inf をダブルクリックします。
修正の済んだ [グループ ポリシー] を閉じます。
[ドメインのプロパティ] ウィンドウを閉じます。
ドメイン コントローラ間で複製を行います。これにより次の方法で、すべての DC がポリシーを持つようにします。
コマンド プロンプトを開き、Secedit.exe コマンド ライン ツールを使用します。次のコマンドを発行して、 DC のドメイン ポリシーをリフレッシュします。
secedit /refreshpolicy machine_policy /enforce
ポリシーが正常にダウンロードされ、サーバーがドメイン内の他の DC と通信できることを [イベント ログ] で検証します。
Secedit.exe はコマンド ライン ツールで、バッチ ファイルまたは自動タスク スケジューラから呼び出された場合、テンプレートを自動的に生成および適用し、システム セキュリティを分析することができます。Secedit.exe はコマンド ラインから動的に実行することもできます。
組織のすべての追加ドメインにこのポリシーをインポートすることは非常に重要です。しかし、ルート ドメインのパスワード ポリシーが、他のいかなるドメインよりもはるかに厳しい環境は珍しいものではありません。それに加えて、同一のパスワード ポリシーを使用する他のいかなるドメインも、ビジネス要件が同じであることを必ず確認します。パスワード ポリシーはドメイン レベルでのみ設定することができるので、そのグループでより厳しいパスワード ポリシーを適用するためだけに、一定のユーザーを異なるドメインにセグメント化することが、ビジネスまたは法的に必要な場合があります。
Contoso はルート ドメインと子ドメインとに同じパスワード ポリシーを適用し、それぞれの施行に同一の MSS Domain.inf を使用することを選択しました。
ベースライン ポリシーおよび増分ポリシーに、これに続くすべてのテンプレートを適用する場合も、上記と同様の手順に従います。
正常な GPO アプリケーション イベント
すべての設定を手動でチェックして、組織内のサーバーに設定が適切に適用されたことを確認します。その他に、ドメイン ポリシーが正常にダウンロードされたことを管理者に知らせるイベントがイベント ログに記録されます。アプリケーション ログに一意のイベント ID 番号と共に、次のイベント情報が表示されます。
種類: 情報
ソース ID: SceCli
イベント ID: 1704
説明: グループ ポリシー オブジェクト セキュリティ ポリシーは正しく適用されました。
ポリシー適用後、数分間経ってもこのメッセージが表示されない場合、Secedit.exe コマンド ライン ツールを再実行してドメイン ポリシーを適用してください。そしてサーバーを再起動して、ドメイン ポリシーを強制的にダウンロードしてください。
既定では、セキュリティの設定はワークステーションやサーバーでは 90 分ごとに、ドメイン コントローラでは 5 分ごとにリフレッシュされます。この時間内になんらかの変更が行われた場合に、このイベントが発生します。それに加えて、変更の有無にかかわらず、16 時間ごとに設定がリフレッシュされます。
まとめ
セキュリティを考慮してフォレスト、ドメイン、および組織単位 (OU) の設計をレビューするときに、設計上検討する事項がいくつかあります。
自社組織に何らか特定の自治または隔離の要件があるかを、調査して文書化します。政治的な自治、運用の隔離、および法規的な隔離はすべて、複雑なフォレスト設計を検討する理由として有効です。
サービス管理者を制御する能力を理解します。悪意のあるサービス管理者は組織にとって大きなリスクとなります。下位レベルでは、悪意のあるドメイン管理者は、フォレスト内の任意のドメインにあるデータにアクセスできます。
組織内のフォレストまたはドメインの設計を変更することは容易ではありませんが、企業にとって何らかのセキュリティ リスクを解決するためには必要な場合があります。
サービス管理者およびデータ管理者のニーズに応じて、組織内での OU の展開を計画します。企業内の異なるサーバーの役割の継続管理を、グループ ポリシー オブジェクト (GPO) を使用してサポートする OU モデルを作成します。
最後に、組織内のドメイン全体にわたるすべての設定をレビューします。1 つのドメインには、1 組のパスワード ポリシー、アカウント ポリシー、ロックアウト ポリシー、Kerberos バージョン 5 認証プロトコル ポリシーだけを構成することができます。パスワードおよびアカウント ロックアウトに関するその他の設定は、メンバ サーバー上のローカル アカウントにのみ影響を及ぼします。ドメイン内のすべてのメンバ サーバーに適用される設定を構成するように計画します。そして、その設定が組織全体にわたって適切なレベルのセキュリティを確実に提供するようにします。
関連情報
マイクロソフトのセキュリティとプライバシの詳細は、次のサイトを参照してください。
https://www.microsoft.com/security/
「セキュリティに関する 10 の鉄則」 の詳細は、次のサイトを参照してください。
https://www.microsoft.com/japan/technet/archive/community/columns/security/essays/10imlaws.mspx
「Active Directory における管理の委任に関する設計上の考慮事項」 (英語) の詳細は、次のサイトを参照してください。
https://technet.corp.microsoft.com/ja-jp/library/bb727032.aspx
タイム サーバーの構成の詳細は、次のサイトを参照してください。
マイクロソフトのサポート技術情報 (KB) の記事 216734 「権限のあるタイム サーバーの Windows での構成方法」
目次
第 5 章 ‐ ドメイン インフラストラクチャをセキュリティで保護する
付録 E ‐ セキュリティで保護された LDAP および SMTP 複製を行うためのドメイン コントローラでのデジタル証明書の構成