脅威とその対策
脅威とその対策
最終更新日: 2006年8月14日
ダウンロード
ドメイン レベルで適用されるグループ ポリシー設定について説明します。組み込みの既定のドメイン コントローラ ポリシーには、これらのポリシーの既定の設定値が含まれ、これらはまとめてアカウント ポリシーと呼ばれています。
トピック
アカウント ポリシー
アカウント ポリシーには、パスワード ポリシー、アカウント ロックアウト ポリシー、Kerberos 認証プロトコル ポリシーの 3 種類の異なるタイプがあります。1 つの Microsoft Windows Server™ 2003 ドメイは、これらのポリシーのいずれか 1 つを持つことができます。Active Directory の別のレベルでこれらのポリシーを設定しても、影響を受けるのはメンバ サーバー上のローカル アカウントのみです。
注:ドメイン アカウントについては、アカウント ポリシーはドメインごとに 1 つのみ定義されます。アカウント ポリシーは、既定のドメイン ポリシーまたは新規ポリシーで定義します。新規ポリシーは、ドメインのルートにリンクされ、既定のドメイン ポリシーよりも高い優先度を与えられている必要があります。ドメイン ポリシーは、そのドメインを構成するドメイン コントローラによって適用されます。ドメイン コントローラでは、そのドメイン コントローラが属す OU に異なるアカウント ポリシーが適用されている場合も、常にドメインのルートのアカウント ポリシーが使用されます。"ドメイン" のルートは、そのドメインの最上位コンテナです。フォレスト内の "ルート ドメイン" と混同しないようにしてください。フォレスト内のルート ドメインは、そのフォレスト内の最上位ドメインです。
アカウント ポリシーのグループ ポリシーの設定はすべて、ドメイン レベルで適用されます。パスワード ポリシー、アカウント ロックアウト ポリシー、および Kerberos ポリシーの組み込みの既定のドメイン コントローラ ポリシーに、既定値が設定されています。Active Directory® ディレクトリ サービスでこれらのポリシーを設定する場合、Microsoft® Windows® では、ドメイン ツリーのルート ドメインに適用される、1 つのドメイン アカウント ポリシーのみが許可されます。ドメイン アカウント ポリシーは、ドメインのメンバである Windows コンピュータの既定のアカウント ポリシーになります。
この規則の唯一の例外は、別のアカウント ポリシーが組織単位 (OU) に対して定義されている場合です。OU のアカウント ポリシーの設定は、OU に属すコンピュータのローカル ポリシーに影響します。たとえば、OU のポリシーがドメイン レベルのアカウント ポリシーとは異なるパスワードの最大有効期間を定義する場合、OU のポリシーはユーザーがローカルのコンピュータにログオンする場合にのみ適用されます。OU のアカウント ポリシーもドメイン ポリシーも適用されないワークグループまたはドメインのコンピュータには、既定のローカル コンピュータ ポリシーだけが適用されます。
この章では、それぞれの種類のポリシーの設定について説明します。
パスワード ポリシー
Windows およびその他の多くのオペレーティング システムでは、ユーザー ID を認証する最も一般的な方法は、秘密パス フレーズまたはパスワードの使用です。セキュリティ保護されたネットワーク環境では、すべてのユーザーが強力なパスワード (10 文字以上で構成され、文字と数字と記号を組み合わせたもの) を使用する必要があります。これらのパスワードは、手動または自動化された方法で脆弱なパスワードを推測する不正なユーザーによって、ユーザー アカウントや管理者アカウントが侵害されるのを防ぐのに役立ちます。強力なパスワードを使用し、そのパスワードを定期的に変更することで、パスワード攻撃の可能性を低減することができます。強力なパスワードの詳細については、この章で後述する「パスワードは複雑さの要件を満たす必要がある」を参照してください。
適切なパスワード ポリシーによって、強力なパスワードの使用を強制することができます。パスワード ポリシーの設定では、パスワードの複雑さと有効期限を定義します。ここでは、具体的なパスワード ポリシーのアカウント設定について説明します。このガイドには、既定の設定が記載された「Windows Default Security and Services Configuration」という Microsoft Excel ブックも付属しています。
パスワード ポリシー設定は、グループ ポリシー オブジェクト エディタ内の次の場所で構成できます。
コンピュータの構成\Windows の設定\セキュリティの設定\アカウント ポリシー\パスワードのポリシー
別のパスワード ポリシーを必要とするグループがある場合は、それらのグループを追加要件に基づいて他のドメインまたはフォレストに分割してください。
パスワードの履歴を記録する
このポリシー設定では、古いパスワードを再利用できるようになるまでユーザー アカウントに関連付けておく必要がある一意の新規パスワードの個数を指定します。
[パスワードの履歴を記録する] で設定できる値は、次のとおりです。
0 ～ 24 のユーザー指定値
未定義
脆弱性
パスワードの再使用は、どの組織にとっても重要な問題です。多くのユーザーは、自分のアカウントで同じパスワードを長期間にわたり使用または再使用することを望みます。1 つのアカウントで同じパスワードを長期間使用するほど、攻撃者が総当たり攻撃でパスワードを盗む確率が高まります。また、侵害された可能性のあるアカウントは、パスワードを変更しないままでいる限り、攻撃される可能性があります。パスワードの変更が必要で、パスワードの再使用が禁じられていない場合、またはユーザーが少数のパスワードを継続的に再使用できる場合、有効なパスワード ポリシーの効果は大幅に減少します。
このポリシーの設定値を低くすると、ユーザーは少数の同じパスワードを繰り返し再使用できるようになります。[パスワードの変更禁止期間] を設定を許可しない場合も、元のパスワードを使用できるようになるまで、ユーザーはパスワードを繰り返し変更できます。
対策
[パスワードの履歴を記録する] の設定を最大設定の [24] にして、パスワードの再使用によって発生する脆弱性の数を最小にします。
組織内でこの設定の有効性を高めるには、[パスワードの変更禁止期間] を設定するときに、パスワードをあまり短期間で変更できないようにしてください。この [パスワードの履歴を記録する] の値は、組織内の全ユーザーに対するパスワードの妥当な有効期間と変更間隔の要件を考慮したレベルに設定する必要があります。
考えられる影響
この設定による大きな影響は、ユーザーがパスワードを変更するたびに新しいパスワードを考えなければならないということです。ユーザーに新しい一意のパスワードへの変更を要求すると、パスワードを忘れないように書き留めておくユーザーが現れる危険性が高まります。ユーザーが犯すおそれのあるもう 1 つのリスクは、覚えやすいように段階的に変わるパスワード (たとえば、password01、password02 など) を作る可能性があることです。また、[パスワードの変更禁止期間] の値が小さすぎても、パスワードを忘れたユーザーがヘルプ デスクにパスワードをリセットしてくれるように支援を求めるため、管理のオーバーヘッドが増える可能性があります。
パスワードの有効期間
このポリシー設定では、1 つのパスワードの最大使用日数を指定します。この日数が経過すると、ユーザーはパスワードを変更しなければなりません。
[パスワードの有効期間] で設定できる値は、次のとおりです。
0 ～ 999 のユーザー指定日数
未定義
脆弱性
どんなパスワードでも (きわめて複雑なパスワードであっても)、攻撃者に十分な時間とコンピュータの処理能力があれば、推測 (あるいは解読) できます。次のようにポリシーを設定すると、短時間でパスワードを解読しにくくなります。ユーザーに頻繁にパスワードの変更を要求すると、有効なパスワードが解読されるリスクは小さくなり、また不正にパスワードを取得したユーザーによる不正なログオンのリスクも小さくなります。[パスワードの有効期間] の設定は、ユーザーがパスワードを変更しなくて済むように設定することもできますが、これはセキュリティ上の大きなリスクとなります。
対策
[パスワードの有効期間] の設定を、組織のビジネス要件に適した値に設定してください。Microsoft では、ほとんどの組織の場合、90 日間に設定することを推奨しています。推奨はできませんが、[パスワードの有効期間] を 0 に設定して、パスワードが失効しないようにすることもできます。
考えられる影響
[パスワードの有効期間] の値が小さすぎると、ユーザーは頻繁にパスワードの変更を要求されます。このような設定の場合、ユーザーが忘れないようにパスワードをどこかに書き留め、その情報を安全でない場所に放置したり紛失したりする可能性が高くなるため、実際には組織のセキュリティが低下する場合があります。このポリシー設定の値を高くしすぎると、攻撃者がユーザーのパスワードを解読したり、悪用されたアカウントを使用する時間が長くなる場合があるため、組織内のセキュリティのレベルが低下します。
パスワードの変更禁止期間
このポリシー設定では、1 つのパスワードの最低使用日数を指定します。この日数が経過した後でなければ、ユーザーはパスワードを変更できません。[パスワードの変更禁止期間] の値は、[パスワードの有効期間] の値よりも小さくなければなりません。
[パスワードの履歴を記録する] の設定の有効性を高めるには、このポリシー設定の値を 0 よりも大きい数字にします。[パスワードの履歴を記録する] の設定を 0 にすると、パスワードの変更を求められたときに新しい一意のパスワードを選択する必要がありません。パスワードの履歴を使用すると、ユーザーはパスワードを変更するときに新しい一意のパスワードを入力しなければならなくなります。
[パスワードの変更禁止期間] で設定できる値は、次のとおりです。
0 ～ 998 のユーザー指定日数
未定義
脆弱性
好みのパスワードを繰り返して再使用できるようになっている場合は、ユーザーにパスワードの定期的な変更を要求しても無駄です。古いパスワードの再使用を防ぐには、[パスワードの履歴を記録する] も同時に設定します。たとえば、[パスワードの履歴を記録する] を過去 12 回までのパスワードを再使用できないように設定した場合、[パスワードの変更禁止期間] を 0 よりも大きな数字に設定しておかないと、ユーザーが数分の間に 13 回パスワードを変更して、最初のパスワードを再使用する可能性があります。[パスワードの履歴を記録する] の設定の有効性を高めるには、このポリシー設定の値を 0 よりも大きい数字にする必要があります。
対策
[パスワードの変更禁止期間] 設定の値を 2 日以上に設定します。日数を 0 に設定すると、パスワードをすぐに変更できますが、お勧めできません。
考えられる影響
[パスワードの変更禁止期間] を 0 よりも大きな数値に設定することに関しては、小さな問題が 1 つあります。管理者がユーザーのパスワードを設定して、ユーザーが最初にログオンしたときにユーザーにパスワードを変更させるには、管理者は [ユーザーは次回のログオン時にパスワード変更が必要] チェック ボックスをオンにする必要があります。そうしないと、ユーザーは次の日までパスワードを変更できなくなります。
最小パスワード長
このポリシー設定では、ユーザー アカウントのパスワードを構成する最小の文字数を設定します。組織における最適のパスワード長の決定方法に関してはさまざまな考え方がありますが、"パスワード" というよりも "パス フレーズ" という方が適切と思われます。Microsoft Windows 2000 およびそれ以降のバージョンでは、かなり長いパス フレーズの指定も可能で、スペース、カンマとピリオド、および Unicode 文字を含めることもできます。このため、「I want to drink a $5 beverage!」のようなフレーズは有効なパス フレーズになります。このようなフレーズは、ランダムな数字や文字を組み合わせた 8 ～ 10 文字の文字列よりはかなり強力になり、しかも覚えやすくなります。
[最小パスワード長] で設定できる値は、次のとおりです。
0 ～ 14 のユーザー指定数値
未定義
脆弱性
ユーザー アカウントのパスワードを取得するために仕掛けられる可能性のあるパスワード攻撃には、いくつかの種類があります。たとえば、辞書攻撃 (一般的な単語や語句を使用しようとする) や、ブルート フォース攻撃 (考えられるあらゆる文字の組み合わせを試す) があります。また、攻撃者がアカウント データベースを取得して、ユーティリティを使用してアカウントとパスワードを解読できるようにしようとする場合があります。
対策
[最小パスワード長] 設定の値を 8 文字以上に設定します。文字数を 0 にすると、パスワードは不要になります。
ほとんどの環境では、8 文字のパスワードを使用するようお勧めします。8 文字であれば、十分にセキュリティを確保でき、覚えておくのもそれほど難しくありません。この設定で、ブルート フォース攻撃を十分に防ぐことができます。また、さらに複雑なパスワードを使用すると、辞書攻撃の可能性を低くできます。複雑さに関する要件については、次の章で詳しく説明します。また、国によっては、パスワードの長さについて法的な要件がある場合があるため、注意してください。
考えられる影響
極端に長いパスワードを要求すると、ユーザーが忘れないようにパスワードをどこかに書き留め、その情報を安全でない場所に放置したり、紛失したりする可能性が高くなるため、実際には組織のセキュリティが低下する場合があります。しかし、ユーザーに前述のパスフレーズを使用できることを教えれば、簡単に覚えることができるはずです。
短いパスワードを許可した場合、辞書攻撃やブルート フォース攻撃を実行するツールで簡単に解読できるため、セキュリティが低下します。非常に長いパスワードを使わなければならないようにすると、パスワードのタイプミスが発生し、アカウントのロックアウトを引き起こすことがあります。そのため、ヘルプ デスクに支援を依頼する回数が増えることになります。
Windows 98 や Windows NT® 4.0 のような古いバージョンの Windows では、14 文字よりも長いパスワードはサポートしません。こうした古いオペレーティング システムで動作するコンピュータは、長いパスワードが必要なアカウントを使用するコンピュータやドメインを認証できなくなります。
パスワードは、複雑さの要件を満たす必要がある
このポリシー設定では、強いパスワードにするために重要な一連のガイドラインをパスワードが満たしていなければならないかどうかを設定します。
このポリシー設定が有効な場合、パスワードは次に示す要件を満たす必要があります。
パスワードは 6 文字以上の長さになっている。
パスワードは、次の 4 つのカテゴリのうち、いずれか 3 つのカテゴリの文字を含む。
大文字 (A、B、C、...)
小文字 (a、b、c、...)
数字 (0、1、2、3、4、5、6、7、8、9)
英数字以外の文字および Unicode 文字 (( ) ` ~ ! @ # $ % ^ & * - + = | \ { } [ ] : ; " ' < > , . ? / € Γ ƒ λ およびスペース)
パスワードには、ユーザーのアカウント名または表示名を構成する 3 つ以上の連続文字を含めない。アカウント名の長さが 2 文字以下の場合は、パスワードの拒否率が高くなるため、このチェックは実行されません。ユーザーの氏名に対してチェックを実行するときは、次の文字が、名前を個々のトークンに分ける区切り文字とみなされます。カンマ、ピリオド、ダッシュ/ハイフン、アンダスコア、スペース、ポンド記号、タブ。3 文字以上の各トークンに対して、パスワード内にそのトークンが含まれているかチェックされ、含まれている場合、そのパスワードの変更は拒否されます。
たとえば、氏名「Erin M. Hagens」は、「Erin」、「M」、「Hagens」の 3 つのトークンに分離されます。2 番目のトークンは 1 文字しかないため、無視されます。したがって、このユーザーは "erin" または "hagens" がどこかに含まれるパスワードを使用できません。これらのチェックでは、すべて大文字と小文字が区別されません。
パスワードの変更、または新規パスワードの作成の際には、これらの複雑さの要件を満たす必要があります。
Windows Server 2003 ポリシーで定義されている規則は、直接は修正できません。ただし、新しい Passfilt.dll ファイルを作成して、別のルール セットを適用することは可能です。パスワード フィルタの作成方法の詳細については、https://msdn.microsoft.com/library/en-us/secmgmt/security/password_filters.asp の、MSDN® の Windows Platform software development kit (SDK) の中にある「Password Filters」(英語情報) という文書を参照してください。
[パスワードは、複雑さの要件を満たす必要がある] で設定できる値は次のとおりです。
有効
無効
未定義
脆弱性
英数字のみを含むパスワードは、公開されている複数のユーティリティを使用して、きわめて簡単に解読できます。パスワードが解読されるのを防ぐには、広範囲の文字を含める必要があります。
対策
[パスワードは要求する複雑さを満たす] を [有効] に設定します。
[最小パスワード長] を 8 文字に設定して、このポリシーを設定すると、1 つのパスワードに対して考えられるパスワードの数が非常に大きくなり、ブルート フォース攻撃の成功が難しくなります (ただし、不可能ではありません)。攻撃者は、毎秒 100 万個のパスワードのテストが可能な場合、このようなパスワードを約 1 週間で解読できます。[最小パスワード長] の設定を大きくすると、攻撃の成功に必要な平均時間も増えます。
考えられる影響
既定のパスワードの複雑さ設定を維持する場合、ユーザーがアルファベット以外の文字を含むパスワードに慣れないため、ヘルプ デスクにアカウントのロックアウトについて支援を求める電話が増える可能性があります。しかし、すべてのユーザーが手間をかけずに、複雑さの要件を満たすことができなければなりません。
組織にさらに厳格なセキュリティ要件がある場合、カスタム バージョンの Passfilt.dll ** ファイル** を作成して、任意の複雑さを持つパスワード強度ルールを使用できます。たとえば、カスタム パスワード フィルタで、キーの上部にある記号文字を使用しないように要求できます(上部の記号文字とは、Shift キーを押したまま、0 ～ 9 の数字キーを押して入力する文字です)。カスタム パスワード フィルタで辞書をチェックして、提示されたパスワードが一般的な辞書の用語やその断片を含んでいないことをチェックする場合もあります。
さらに、Alt キーとの文字の組み合わせを使用すると、パスワードの複雑さが大幅に増します。ただし、このように非常に厳格なパスワード要件によって、ユーザーの負担や、ヘルプ デスクへの問い合わせが増える可能性があります。代わりに、すべての管理者パスワードに 0128 ～ 0159 の範囲の ALT 文字を含めるように要求することを検討することもできます(この範囲外の Alt 文字は、パスワードの複雑さを増すことがない標準の英数字を表している可能性があります)。
暗号化を元に戻せる状態でパスワードを保存する
このポリシー設定により、Microsoft Windows Server 2003、Windows 2000 Server、Windows 2000 Professional、および Windows XP Professional で、パスワードを保存するときに元に戻せる暗号化を使用するかどうかを決めます。
[暗号化を元に戻せる状態でパスワードを保存する] 設定により、認証目的でユーザーのパスワードに関する知識を必要とするアプリケーション プロトコルがサポートされます。しかし、元に戻せる状態で保存された暗号化パスワードは、暗号化解除できます。攻撃者がこの暗号化を破ることができれば、不正に取得したアカウントを使用してネットワーク資源にログオンできます。
注 :パスワード情報の保護よりもビジネスの要件が優先される場合を除き、このポリシー設定を決して有効にしないでください。
リモート アクセスまたはインターネット認証サービス (IAS) サービスを介して CHAP (Challenge Handshake Authentication Protocol) 認証を使用するには、このポリシー設定を有効にする必要があります。CHAP は、Microsoft リモート アクセスおよびネットワーク接続で使用できる認証プロトコルです。
[暗号化を元に戻せる状態でパスワードを保存する] 設定で使用できる値は次のとおりです。
有効
無効
未定義
脆弱性
Windows Server 2003 では、このポリシー設定を有効にすると、攻撃を受けやすい脆弱なパスワードが保存されることになります。
対策
[暗号化を元に戻せる状態でパスワードを保存する] の値を [無効] に設定します。
考えられる影響
組織でリモート アクセスまたは IAS サービスによる CHAP 認証プロトコルまたは IIS のダイジェスト認証を使用している場合、このポリシー設定を [有効] に設定する必要があります。ユーザー別グループ ポリシーで使用する場合、これはきわめて危険な設定です。[Microsoft Management Console (MMC) Active Directory ユーザーとコンピュータ] スナップインで目的のユーザー アカウント オブジェクトを開くよう要求するからです。
アカウント ロックアウトのポリシー
コンピュータにログオンしようとしてパスワードの入力に何回も失敗しているような場合は、攻撃者が試行錯誤しながらアカウント パスワードを突き止めようとしていると考えられます。Windows Server 2003 SP1 ではログオン試行を追跡し、オペレーティング システムを設定して、ログオン試行が指定した回数失敗した後、事前に設定した期間だけアカウントを無効にすることができます。[アカウント ロックアウトのポリシー] で、このような対応に対するしきい値と、しきい値に達した場合の処理を設定します。このガイドには、既定の設定が記載された「Windows Default Security and Services Configuration」という Microsoft Excel ブックが付属しています。
[アカウントのロックアウト ポリシー] 設定は、グループ ポリシー オブジェクト エディタ内の次の場所で構成できます。
コンピュータの構成\Windows の設定\セキュリティの設定\アカウント ポリシー\アカウント ロックアウトのポリシー
ロックアウト期間
このポリシー設定では、アカウントのロックアウトが自動的に解除されるまでの、ロックアウト状態になっている時間 (分) を設定します。有効な値の範囲は、1 ～ 99,999 分です。管理者がロックを手動で解除しない限りアカウントがロックアウトされるように指定するには、値を 0 に設定します。アカウントのロックアウトのしきい値が定義されている場合、ロックアウト期間はリセット時間以上でなければなりません。
[ロックアウト期間] で設定できる値は、次のとおりです。
0 ～ 99,999 のユーザー定義値 (分)
未定義
脆弱性
攻撃者が [アカウントのロックアウトのしきい値] の値を悪用し、特定のアカウントへのログインを繰り返し試みた場合に、サービス拒否 (DoS) 状態が発生することがあります。[アカウントのロックアウトのしきい値] 設定が構成されている場合、ログインの試行が指定された回数だけ失敗すると、アカウントはロックアウトされます。[ロックアウト期間] を 0 に設定した場合、管理者が手動でロックを解除するまでアカウントはロックアウトされます。
対策
[ロックアウト期間] の設定を環境に適した値に設定します。管理者がロックを手動で解除しない限りアカウントがロックアウトされるように指定するには、値を 0 に設定します。[ロックアウト期間] 設定が 0 以外の値に設定されている場合、アカウントのパスワードを自動的に推測する試行は、この期間の間待機しないと、特定のアカウントへの試行を再開できません。この設定を [アカウントのロックアウトのしきい値] 設定と組み合わせて使用すれば、このような自動化されたパスワード推測試行は困難または無効になります。
考えられる影響
この値を自動ロック解除が実行されないように設定するのは有効であるように思われますが、組織のヘルプ デスクに誤ってロックしてしまったアカウントのロック解除の依頼件数が増えるおそれがあります。
アカウントのロックアウトのしきい値
このポリシー設定では、ログオンが何回失敗したらユーザー アカウントがロックアウトされるかを設定します。ロックアウトされたアカウントは、管理者がリセットするまで、またはアカウントのロックアウト期間の期限が切れるまで使用できません。ログオン試行の失敗回数を最大 999 までで指定できます。値を 0 に設定すると、アカウントはロックアウトされません。アカウントのロックアウトのしきい値を定義する場合、[ロックアウト期間] はリセット時間以上でなければなりません。
ロックされているワークステーションまたはメンバ サーバーで、Ctrl + Alt + Del キーを押して表示される画面でのパスワード入力、またはパスワードで保護されたスクリーン セーバーが起動している状態でのパスワード入力に失敗した場合は、ポリシー設定 [対話型ログオン: workstation のロック解除にドメイン コントローラの認証を必要とする] が有効になっていない限り、ログオンの失敗とは見なされません。このポリシー設定が有効になっている場合、ワークステーションをロック解除するパスワード試行失敗の繰り返し回数が、アカウントのロックアウトのしきい値に対してカウントされます。
[アカウントのロックアウトのしきい値] で設定できる値は、次のとおりです。
0 ～ 999 のユーザー定義値
未定義
脆弱性
パスワード攻撃では、あらゆるユーザー アカウントについて、数千、または数百万ものパスワードの組み合わせを自動的に試行します。実行できる失敗ログオンの回数を制限すれば、このような攻撃の効果をほとんどなくすことができます。
ただし、DoS 攻撃はアカウントのロックアウトのしきい値が設定されているドメイン上で実行できることに注意してください。悪意ある攻撃者がプログラムを使用して、組織内のすべてのユーザーに対して一連のパスワード攻撃を試みることもあります。ログオンの試行回数がアカウントのロックアウトのしきい値よりも大きい場合、攻撃者によりすべてのアカウントがロックアウトされる可能性があります。
対策
この値が設定されているかどうかにかかわらず脆弱性が存在する可能性があるため、2 つの異なる対策を定めています。組織では、認識された脅威と軽減する必要のあるリスクに応じて、これら 2 つのいずれの対策を講じるかを決める必要があります。2 つの対策は次のとおりです。
[アカウントのロックアウトのしきい値] 設定の値を 0 に設定します。この設定により、アカウントがロックアウトされ、すべてのアカウントまたは特定のアカウントを意図的にロックアウトしようとする DoS 攻撃を防ぎます。また、ユーザーが自分のアカウントを間違ってロックしてしまうことがないので、ヘルプ デスクへの問い合わせ件数が減少します。
ただし、ブルート フォース攻撃は防ぐことはできないので、以下の基準が両方とも満たされている場合に限り、この設定を選択してください。
すべてのユーザーが 8 文字以上の複雑なパスワードを使用することがセキュリティ ポリシーで要求されている。
ログオンが何回か連続して失敗したときに、堅牢な監査メカニズムから管理者への警告が行われる。
組織で上記の基準を満たせない場合、[アカウントのロックアウトのしきい値] を十分に高い値に設定し、ユーザーが何回かパスワードの入力を誤っても、アカウントがロックアウトされないようにします。ただし、ブルート フォース パスワード攻撃を受けた場合は、アカウントがロックアウトされる可能性があるので注意してください。このような設定の場合、無効なログオン試行の回数を 50 回に設定することを推奨します。これによって、間違ってアカウントをロックアウトしてしまうのを防ぎ、ヘルプ デスクへの問い合わせが減りますが、前述のように DoS 攻撃は防止されません。
考えられる影響
このポリシー設定を有効にすると、ロックアウトされたアカウントは、管理者がリセットするまで、またはアカウントのロックアウト期間の期限が切れるまで使用できません。この設定では、ヘルプ デスクへの支援の依頼回数が増える可能性があります。実際に、多くの組織では、アカウントのロックに関するヘルプ デスクへの支援の依頼回数が最も多くなっています。
アカウントのロックアウトのしきい値が 0 に設定されている場合、強固な監査メカニズムが設定されていないと、攻撃者によるブルート フォース パスワード攻撃のパスワード解読の試行を検知できない可能性があります。
ロックアウト カウンタのリセット
このポリシー設定では、失敗したログオン試行を追跡し、アカウントのロックアウトをトリガするカウンタが 0 にリセットされるまでに経過する時間 (分) を指定します。[アカウントのロックアウトのしきい値] が定義されている場合、このリセット時間は [ロックアウト期間] 設定の値以下でなければなりません。
[ロックアウト カウンタのリセット] で設定できる値は、次のとおりです。
1 ～ 99,999 のユーザー定義値 (分)
未定義
脆弱性
ユーザーがパスワードを何回か誤って入力した場合、アカウントがロックアウトされる可能性があります。このような間違いによるロックアウトが起きる可能性を低くするために、[ロックアウト カウンタのリセット] で、ログオン試行が失敗してから、失敗したログオン試行を追跡し、ロックアウトをトリガするカウンタが 0 にリセットされるまでに必要な経過時間 (分) を設定します。
対策
[ロックアウト カウンタのリセット] の値を [30 分] に設定します。
考えられる影響
このポリシー設定を設定しない場合、または設定している間隔の値が大きすぎる場合、DoS 攻撃が発生する可能性があります。前述のように攻撃者が各ユーザーのアカウントにログオン試行を何回も行ない、アカウントをロックアウトさせる可能性があります。[アカウントのロックアウトをリセットする] 設定をしない場合は、すべてのアカウントを管理者が手動でロックを解除する必要があります。このポリシー設定を妥当な値に設定した場合、ユーザーは一定期間ロックアウトされ、その後、アカウントが自動的にロック解除されます。このポリシー設定に使用した値をユーザーに知らせて、ユーザーがヘルプ デスクにログオンできないことを連絡する前に、ロックアウト タイマが切れるまで待つようにします。
Kerberos ポリシー
Windows Server 2003 では、Kerberos 5 認証プロトコルがドメインの既定の認証サービスとして使用され、ユーザーがリソースにアクセスしてそのリソースに対するタスクを実行するのに必要な認証データが提供されます。Kerberos チケットの有効期間を短くすると、正規ユーザーの資格情報が攻撃者によって盗まれて使われてしまう危険性が少なくなります。しかし、認証のオーバーヘッドは増加します。
ほとんどの環境では、Kerberos ポリシー設定を変更する必要はありません。これらのポリシー設定はドメイン レベルで適用され、既定値は、既定インストールの Windows 2000 または Windows Server 2003 の Active Directory ドメインの、既定のドメイン ポリシー GPO で設定されます。このガイドには、既定の設定が記載された「Windows Default Security and Services Configuration」という Microsoft Excel ブックが付属しています。
[Kerberos ポリシー] 設定は、グループ ポリシー オブジェクト エディタ内の次の場所で構成できます。
コンピュータの構成\Windows の設定\セキュリティの設定\アカウント ポリシー\Kerberos ポリシー
ユーザー ログオンの制限を強制する
このポリシー設定では、キー配布センター (KDC) で、すべてのセッション チケットの要求について、ユーザー アカウントのユーザー権利ポリシーに適合していることを検証するかどうかを指定します。各セッション チケットの要求の検証は、任意で設定します。必要な処理の数が増えると、時間も余計にかかり、ネットワーク経由でのサービスへのアクセスが遅くなることがあるからです。
[ユーザー ログオンの制限を強制する] で設定できる値は、次のとおりです。
有効
無効
未定義
脆弱性
このポリシー設定を無効にした場合、ユーザーがログオンした後に権限が削除されたために使用する権限がなくなったサービスのセッション チケットを受け取る可能性があります。
対策
[ユーザー ログオンの制限を強制する] を [有効] に設定します。
考えられる影響
なし。これは既定の構成です。
サービス チケットの最長有効期間
このポリシー設定では、与えられたセッション チケットを特定のサービスにアクセスするために使用できる最長時間 (分) を指定します。この設定は、10 分以上で、[チケットの最長有効期間] の設定値以下でなければなりません。
クライアントがサーバーへ接続を要求するときに期限切れのセッション チケットを提示すると、サーバーからエラー メッセージが返され、クライアントは KDC に新しいセッション チケットを要求する必要があります。接続が認証されると、セッション チケットが有効かどうかは問題でなくなります。セッション チケットは、サーバーとの新しい接続を認証する場合にのみ使用されます。接続を認証したセッション チケットが接続中に期限切れになっても、操作は中断されません。
[サービス チケットの最長有効期間] で設定できる値は、次のとおりです。
10 ～ 99,999、または 0 のユーザー定義値 (分)。このポリシー設定を 0 に設定すると、サービス チケットは期限切れになりません。
未定義
脆弱性
[サービス チケットの最長有効期間] の設定値が高すぎる場合、ユーザーがログオン時間外にネットワーク リソースにアクセスできる可能性があります。また、アカウントが無効になっているユーザーがアカウントが無効になる前に発効された有効なサービス チケットで、ネットワーク サービスにアクセスを継続できる可能性があります。
対策
[サービス チケットの最長有効期間] を [600 分] に設定します。
考えられる影響
なし。これは既定の構成です。
チケットの最長有効期間
このポリシー設定では、ユーザーのチケット付与チケット (TGT) の最長有効時間 (分) を指定します。ユーザーの TGT が期限切れになったときには、新規 TGT を要求するか、既存の TGT を更新する必要があります。
[チケットの最長有効期間] で設定できる値は、次のとおりです。
0 ～ 99,999 のユーザー定義値 (時間)。既定値は 10 時間です。
未定義
脆弱性
[チケットの最長有効期間] の設定値が高すぎる場合、ユーザーがログオン時間外にネットワーク リソースにアクセスできる可能性があります。また、アカウントが無効になっているユーザーがアカウントが無効になる前に発効された有効なサービス チケットで、ネットワーク サービスにアクセスを継続できる可能性があります。
対策
[チケットの最長有効期間] を [10 時間] に設定します。
考えられる影響
なし。これは既定の構成です。
ユーザー チケットを更新できる最長有効期間
このポリシー設定では、ユーザーのチケット付与チケット (TGT) を更新できる期間 (日数) を指定します。
[ユーザー チケットを更新できる最長有効期間] で設定できる値は、次のとおりです。
0 ～ 99,999 のユーザー定義値 (分)
未定義
脆弱性
[ユーザー チケットを更新できる最長有効期間] の設定値が大きすぎると、ユーザーが非常に古いユーザー チケットを更新できるようになる可能性があります。
対策
[ユーザー チケットを更新できる最長有効期間] を [10080 分] (7 日間) に設定します。
考えられる影響
なし。これは既定の構成です。
コンピュータの時計の同期の最長トレランス
このポリシー設定では、Kerberos プロトコルで許容される、コンピュータのクロックの時刻と Kerberos 認証を行う Windows Server 2003 ベースのドメイン コントローラの時刻との最大時間差 (分) を指定します。
[コンピュータの時計の同期の最長トレランス] で設定できる値は、次のとおりです。
1 ～ 99,999 のユーザー定義値 (分)
未定義
脆弱性
"反射攻撃" を防ぐには、Kerberos 認証プロトコルでタイム スタンプをプロトコル定義の一部として使用します。タイム スタンプが正常に機能するためには、クライアントのクロックとドメイン コントローラのクロックが可能な限り同期している必要があります。2 台のコンピュータのクロックは同期していない場合が多いため、管理者はこのポリシーを使用して、その時間内に Kerberos ネゴシエーションが完了する最大経過時間を確立できます。経過時間は、タイム スタンプから計算されます。この設定の値によって、ドメイン コントローラとクライアント コンピュータ間で許容できる最大時間の違いが制限されます。
対策
[コンピュータの時計の同期の最長トレランス] を [5 分] に設定します。
考えられる影響
なし。これは既定の構成です。
関連情報
以下のリンクでは、Windows Server 2003 SP1 を実行するドメイン コントローラの強化に関する詳細情報を提供しています。
パスワードの複雑さが Windows でどのように機能するか、および覚えやすく強力なパスワードの作り方の詳細な説明については、「安全なパスワードを選択する」を参照してください
Microsoft が提供する信頼できるセキュリティ ガイダンスについては、www.microsoft.com/technet/security/secnews/articles/enterprisesecbp.mspx の「「Enterprise Security Best Practices」(英語情報) を参照してください。
レジストリに保存され、各バージョンの Windows で利用できるすべての設定のパスと値のリストも含めたグループ ポリシーの詳細については、www.microsoft.com/downloads/details.aspx?FamilyId=7821C32F-DA15-438D-8E48-45915CD2BC14 の「「Group Policy Settings Reference for Windows Server 2003 with Service Pack 1」(英語情報) を参照してください。