第 5 章 : セキュリティ オプション
最終更新日: 2006年8月14日
ダウンロード
『脅威とその対策ガイド』のダウンロード
グループ ポリシーのセキュリティ オプション セクションでは、デジタル データ署名、Administrator アカウント名と Guest アカウント名、フロッピー ディスク ドライブおよび CD-ROM ドライブへのアクセス、ドライバのインストール時の動作、ログオン画面などのコンピュータのセキュリティ設定を有効または無効にすることができます。このガイドのダウンロード バージョンに付属の「Windows Default Security and Services Configuration」という Microsoft® Excel® ブックに、既定の設定が記載されています。
トピック
セキュリティ オプションの設定
関連情報
セキュリティ オプションの設定
セキュリティ オプション設定は、グループ ポリシー オブジェクト エディタ内の次の場所で構成できます。
Computer Configuration\Windows Settings\Security Settings\
Local Policies\Security Options
アカウント : Administrator アカウントの状態
このポリシー設定は、通常の運用条件での Administrator アカウントを有効または無効にします。セーフ モードでコンピュータを起動した場合は、このポリシー設定の構成にかかわらず、常に Administrator アカウントが有効となります。
[アカウント : Administrator アカウントの状態] で設定できる値は、次のとおりです。
脆弱性
組織によっては、ローカル アカウントのパスワードを定期的に変更するために一定のスケジュールを維持することは、管理上、困難な場合があります。その場合、攻撃者から保護するために、定期的なパスワードの変更に依存する代わり、ビルトイン Administrator アカウントを無効にすることができます。このビルトイン アカウントを無効にする別の理由は、このアカウントは何度ログオンに失敗してもロックアウトされないため、パスワードを盗もうとするブルート フォース攻撃の格好のターゲットになってしまうことです。さらに、このアカウントのセキュリティ ID (SID) はよく知られており、アカウント名ではなく SID を指定して認証できるサード パーティのツールがあります。つまり、Administrator アカウントの名前を変えても、攻撃者は SID を使ってログオンすることによってブルート フォース攻撃を仕掛けることができます。
対策
[アカウント : Administrator アカウントの状態] を [無効] に設定し、通常のシステム起動時にビルトイン Administrator アカウントを使用不可能にします。
考えられる影響
Administrator アカウントを無効にすると、特定の状況下でメンテナンスの問題が発生する場合があります。たとえば、ドメイン環境で、メンバ コンピュータとドメイン コントローラ間のセキュリティ チャネルが何かの理由で失敗し、他にローカルの Administrator アカウントがない場合、セーフモードでコンピュータを再起動して、セキュリティで保護されたチャネルを無効にした問題を修正する必要があります。
現在の Administrator のパスワードが、パスワード要件を満たさない場合、無効になった後の Administrator アカウントを再び有効にすることはできません。この場合、Administrator グループの別のメンバが、ローカル ユーザーとグループ ツールを使って、この Administrator アカウントのパスワードを設定する必要があります。
アカウント : Guest アカウントの状態
このポリシー設定は、Guest アカウントを有効にするか無効にするかを決定します。
[アカウント : Guest アカウントの状態] で設定できる値は、次のとおりです。
脆弱性
既定の Guest アカウントは、認証されていないネットワーク ユーザーにも Guest としてパスワードなしでログオンすることを許可します。認証されていないユーザーは、ネットワーク上で Guest アカウントがアクセスできる、どのリソースにもアクセスできます。つまり、Guest アカウント、Guests グループ、または Everyone グループにアクセスを許可する承認のあるネットワーク共有には、すべてネットワークを介してアクセスすることができ、このことは、データの露出または破損を招く可能性があります。
対策
[アカウント : Guest アカウント状態] を [無効] にして、ビルトイン Guest アカウントを使用不可能にします。
考えられる影響
すべてのネットワーク ユーザーは、共有リソースにアクセスするには、認証される必要があります。Guest アカウントを無効にして、[ネットワーク アクセス : 共有とセキュリティ モデル] オプションが [Guest のみ] に設定されている場合、Microsoft Network Server (SMB サービス) によって実行されるログインなどのネットワーク ログインは失敗します。このポリシー設定は、Microsoft Windows® 2000、Windows XP、および Windows Server™ 2003 では既定の設定なので、大部分の組織において、影響はほとんどありません。
アカウント : ローカル アカウントの空のパスワードの使用をコンソール ログオンのみに制限する
このポリシー設定は、ターミナル サービス、Telnet、およびファイル転送プロトコル (FTP) などのネットワーク サービスによるリモートで対話的なログオンを、空のパスワードを持つローカルのアカウントに許可するかどうかを決定します。このポリシー設定を有効にすると、ローカルのアカウントがリモート クライアントから対話的なログオンまたはネットワーク ログオンを実行するには、何らかのパスワードが必要です。
[アカウント : ローカル アカウントの空のパスワードの使用をコンソール ログオンのみに制限する] で設定できる値は、次のとおりです。
注 : このポリシー設定は、ドメイン アカウントを使うコンソールやログオンで物理的に実行される、対話的なログオンには影響がありません。
注 : リモートで対話的なログオンを使うサード パーティのアプリケーションは、このポリシー設定をバイパスする可能性があります。
脆弱性
空のパスワードは、コンピュータのセキュリティにとって深刻な脅威なので、組織のポリシーおよび適切な技術対策の両方において、禁止してください。実際、Windows Server 2003 Active Directory® ディレクトリ サービス ドメインの既定の設定では、最低 7 文字の複雑なパスワードが要求されます。ただし、新しいアカウントを作成できるユーザーが、ドメインベースのパスワード ポリシーをバイパスする場合は、空のパスワードを持ったアカウントを作成することができます。たとえば、ユーザーはスタンドアロンのコンピュータを構築し、空のパスワードを持つアカウントを 1 つまたは複数作成して、コンピュータをドメインに参加させることができます。ローカル アカウントのパスワードが空でも機能します。保護されていないアカウントの名前の 1 つを知っているユーザーはすべて、それを使ってログオンできます。
対策
[アカウント : ローカル アカウントの空のパスワードの使用をコンソール ログオンのみに制限する] 設定を有効にします。
考えられる影響
なし。これは既定の構成です。
アカウント : Administrator アカウント名の変更
このポリシー設定は、異なるアカウント名が Administrator アカウントの SID と関連するかどうかを判断します。
[アカウント : Administrator アカウント名の変更] で設定できる値は、次のとおりです。
脆弱性
Administrator アカウントは、Windows 2000、Windows Server 2003、または Windows XP Professional のオペレーティング システムを実行しているすべてのコンピュータ上にあります。このアカウント名を変更すると、承認されていないユーザーが権限を持つユーザーの名前とパスワードの組み合わせを推測することが多少困難になります。
ビルトイン Administrator アカウントは、攻撃者が間違ったパスワードを何度使ってもロックアウトされません。このため、パスワードを盗もうとするブルート フォース攻撃の格好のターゲットになります。このアカウントのセキュリティ ID (SID) はよく知られており、アカウント名ではなく SID を指定して認証できるサード パーティのツールがあるため、この対策の価値は薄れています。そのため、Administrator アカウントの名前を変えても、攻撃者は SID を使ってログオンすることによってブルート フォース攻撃を仕掛けることができます。
対策
[アカウント : Administrator アカウント名の変更] 設定で新しい名前を指定し、Administrator アカウント名を変更します。
注 : 後半の章で、このポリシー設定はセキュリティ テンプレートで構成されていないこと、また本ガイドで推奨するアカウントの新しいユーザー名ではないことを説明します。テンプレートでこのポリシー設定が省略されているのは、このガイドを使用する多くの組織が、ぞれぞれの環境で同一の新しい名前を実装しないようにという配慮からです。
考えられる影響
承認されたユーザーに、このアカウントを新しいアカウント名で使用するように通知する必要があります (この設定のガイダンスは、この章の前半で推奨されているように、Administrator アカウントが無効になっていないことを前提としています)。
アカウント : Guest アカウント名の変更
[アカウント : Guest アカウント名の変更] 設定では、異なるアカウント名が Guest アカウントの SID と関連するかどうかを決定します。
このグループ ポリシーで設定できる値は、次のとおりです。
脆弱性
Guest アカウントは、Windows 2000、Windows Server 2003、または Windows XP Professional のオペレーティング システムを実行しているすべてのコンピュータ上にあります。このアカウント名を変更すると、承認されていないユーザーが権限を持つユーザーの名前とパスワードの組み合わせを推測することが多少困難になります。
対策
[アカウント : Guest アカウント名の変更] 設定で新しい名前を指定し、Guest アカウント名を変更します。
注 : 後半の章で、このポリシー設定はセキュリティ テンプレートで構成されていないこと、また本ガイドで推奨するアカウントの新しいユーザー名ではないことを説明します。テンプレートでこのポリシー設定が省略されているのは、このガイドを使用する多くの組織が、ぞれぞれの環境で同一の新しい名前を実装しないようにという配慮からです。
考えられる影響
Guest アカウントは、Windows 2000、Windows XP、および Windows Server 2003 では既定で無効になっているので、影響はほとんどありません。
監査 : グローバル システム オブジェクトへのアクセスを監査する。
このポリシー設定を有効にすると、コンピュータがミューテックス、イベント、セマフォ、MS-DOS® デバイスなどのシステム オブジェクトを作成すると、既定のシステム アクセス制御リスト (SACL) が適用されます。また、このガイドの第 3 章で説明しているように、[オブジェクト アクセスの監査] 設定も有効にすると、これらのシステム オブジェクトへのアクセスが監査されます。
グローバル システム オブジェクトは、"ベース システム オブジェクト" または "ベース名オブジェクト" とも呼ばれる一時的なカーネル オブジェクトで、このオブジェクトを作成したアプリケーションまたはシステム コンポーネントによって、名前を割り当てられています。これらのオブジェクトは、複数のアプリケーションや複雑なアプリケーションの複数のパーツの同期を図るときに使用するのが最も一般的です。名前を持つため、スコープ内でグローバルとなり、システム上のすべてのプロセスに表示されます。また、これらのオブジェクトにはすべてセキュリティ記述子がありますが、通常は NULL SACL です。起動時にこのポリシー設定を有効にすると、オブジェクト作成時に、カーネルによりオブジェクトに SACL が割り当てられます。
[監査 : グローバル システム オブジェクトへのアクセスを監査する] で設定できる値は、次のとおりです。
脆弱性
セキュリティ保護が不適切な場合、グローバルに見える名前のオブジェクトは、そのオブジェクト名を知っている不正なプログラムに動作を左右されるおそれがあります。たとえば、ミューテックスなどの同期オブジェクトが、不十分な DACL (Discretionary Access Control List) を持つ場合、不正プログラムは名前からミューテックスにアクセスしてプログラムの誤動作を引き起こします。しかし、これが発生する危険性はほとんどありません。
対策
[監査 : グローバル システム オブジェクトへのアクセスを監査する] 設定を有効にします。
考えられる影響
[監査 : グローバル システム オブジェクトへのアクセスを監査する] 設定を有効にすると、特にビジーなドメイン コントローラとアプリケーション サーバーにおいて、大量のセキュリティ イベントが生成される可能性があります。これにより、サーバーの応答が遅くなったり、セキュリティ イベント ログが重要度の低い大量のイベントを強制的に記録することがあります。このポリシー設定は有効または無効にできるだけで、記録するイベントや記録しないイベントをフィルタリングする方法はありません。このポリシー設定を使用して生成されたイベントを分析するリソースのある組織でも、名前の付けられた各オブジェクトが何に使われるかがわかるソース コードや説明が手元にある可能性は低いといえます。このため多くの組織では、このポリシー設定を [有効] に設定しても利点がありません。
監査 : バックアップと復元の特権の使用を監査する
このポリシー設定は、[特権使用の監査] 設定が有効である場合に、バックアップと復元を含むすべてのユーザー特権の使用を監査するかどうかを決定します。両方のポリシーを有効にした場合、バックアップまたは復元されるファイルごとに監査イベントが生成されます。
[特権使用の監査] 設定と併せてこのポリシー設定を有効にすると、セキュリティ ログにおけるすべてのユーザー権利の実行が記録されます。このポリシー設定を無効にすると、[特権使用の監査] を有効にしている場合でも、バックアップまたは復元の権限を持つユーザーのアクションは監査されません。
[監査 : バックアップと復元の特権の使用を監査する] で設定できる値は、次のとおりです。
脆弱性
[特権使用の監査] 設定が有効の際に、このオプションを有効にすると、バックアップまたは復元されるすべてのファイルの監査イベントが生成されます。この情報は、承認されていない方法で誤ってまたは不正にデータを復元するのに使用されたアカウントを特定するのに役立ちます。
対策
[バックアップと復元の特権の使用を監査する] 設定を有効にします。または、AutoBackupLogFiles レジストリ キーを構成することによって、自動ログ バックアップを実行します。この方法は、マイクロソフト サポート技術情報の記事 http://support.microsoft.com/default.aspx?kbid=312571 の「イベント ログが最大ログ サイズに達する前に、イベントの出力が停止する」で説明されています。
考えられる影響
このポリシー設定を有効にすると、大量のセキュリティ イベントが生成される可能性があります。これにより、サーバーの応答が遅くなったり、セキュリティ イベント ログが重要度の低い大量のイベントを強制的に記録することがあります。システム シャットダウンの可能性を減らすためにセキュリティ ログ サイズを増やす場合、極端に大きなログ ファイルは、システムのパフォーマンスに影響を与える場合があります。
監査 : セキュリティ監査のログを記録できない場合は直ちにシステムをシャットダウンする
このポリシー設定は、セキュリティ イベントのログを記録できない場合に、コンピュータをシャットダウンするかどうかを決定します。TCSEC (Trusted Computer System Evaluation Criteria) の C2 および Common Criteria 証明書の要件で、監査システムがイベントを記録できない場合、監査可能なイベントが発生することを禁止します。監査システムにエラーが生じた際には、コンピュータを停止して STOP メッセージを表示することで、この要件は満たされます。このポリシー設定を有効にすると、セキュリティ監査が何らかの理由で記録できない場合、コンピュータを停止します。通常、セキュリティ イベント ログがいっぱいで、指定した保存方法が [イベントを上書きしない] または [指定した日数を過ぎたら上書きする] の場合、イベントは記録されません。
このポリシー設定が有効の場合、セキュリティ ログがいっぱいで、かつ既存のエントリが上書きできない場合、次の [停止] メッセージが表示されます。
STOP: C0000244 {監査の失敗}
セキュリティ監査の生成に失敗しました。
回復するには、管理者がログオンし、必要に応じてログをアーカイブしてから消去し、このオプションを無効にしてコンピュータを再起動します。このとき、このポリシー設定 を [有効] にする前に、手動でセキュリティ イベント ログをクリアする必要がある場合があります。
[監査 : セキュリティ監査のログを記録できない場合は直ちにシステムをシャットダウンする] で設定できる値は、次のとおりです。
脆弱性
コンピュータがイベントをセキュリティ ログに記録できない場合、セキュリティ インシデントが生じた後で、重要な証拠やトラブルシューティングの情報を参照できないことがあります。また、攻撃者が、故意にボリュームの大きいセキュリティ イベント ログを生成して、コンピュータを強制的にシャットダウンさせる可能性もあります。
対策
[セキュリティ監査のログを記録できない場合は直ちにシステムをシャットダウンする] 設定を有効にします。
考えられる影響
このポリシー設定を有効にすると、管理上の負荷は、特に [セキュリティ ログの保存方法] を [イベントを上書きしない (手動でログを消去)] に設定している場合、大きくなります。この設定によって、履行拒否の脅威 (バックアップ オペレータは、バックアップまたは復元されたデータを拒否できます) がサービス拒否 (DoS) の脆弱性となります。これはセキュリティ ログに書き込まれたログオン イベントや、その他のセキュリティ イベントが負担になり、サーバーが強制終了することがあるためです。また、シャットダウンは手荒な動作であるため、オペレーティング システム、アプリケーション、またはデータに修復不可能な損傷が生じる可能性があります。NTFS ファイル システム (NTFS) は、手荒なシステムのシャットダウンを行う際、ファイル システムの統合性が維持されることを保証しますが、各アプリケーションの各データ ファイルが、システムの再起動時に使用可能な形式となることは保証できません。
DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ アクセス制限
このポリシー設定では、コンピュータ上のすべての DCOM (Distributed Component Object Model) ベースのアプリケーションのアクセスを管理する、コンピュータ全体の追加のアクセス制御を定義できます。これらの制御は、コンピュータ上の呼び出し、アクティブ化、または起動の要求を制限します。これらのアクセス制御は、簡単に言うと、コンピュータ上のすべての COM サーバーの呼び出し、アクティブ化、または起動に対して、コンピュータ全体のアクセス制御リスト (ACL) へのチェックを実行する追加のアクセス チェック呼び出しのことです。アクセス チェックに失敗した場合、その呼び出し、アクティブ化、または起動の要求は拒否されます (このチェックは、サーバー固有の ACL に対して実行されるすべてのアクセス チェックに加えて実行されます)。実際には、コンピュータ上のいずれの COM サーバーにアクセスする場合にも満たす必要のある、最低限の承認基準を提供します。[DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ アクセス制限] 設定は、呼び出し権利に対するアクセス権限を制御します。
これらのコンピュータ全体の ACL を使用すると、CoInitializeSecurity により特定のアプリケーションで指定される脆弱なセキュリティ設定や、アプリケーション固有のセキュリティ設定を上書きすることができます。特定のサーバーの設定に関係なく、満たす必要がある最低限のセキュリティ基準を提供します。
これらの ACL により、管理者は、コンピュータ上のすべての COM サーバーに適用される全般的な承認ポリシーを一元的に設定できます。
[DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ アクセス制限] 設定では、2 つの方法で ACL を指定できます。セキュリティ記述子に SDDL で入力するか、またはユーザーおよびグループを選択して、ローカル アクセスまたはリモート アクセスを許可または拒否します。Microsoft では、ビルトイン ユーザー インターフェイスを使用して、この設定を適用する ACL の内容を指定することをお勧めします。
脆弱性
多くの COM アプリケーションには、何らかのセキュリティ固有のコード (CoInitializeSecurity の呼び出しなど) が含まれていますが、脆弱な設定が使用されているために、プロセスへの認証されていないアクセスが許可されてしまうことがよくあります。旧バージョンの Windows では、管理者は、アプリケーションを変更せずにこれらの設定をより強力なセキュリティで上書きすることはできません。攻撃者は、COM 呼び出しを介して、個々のアプリケーションの脆弱なセキュリティに対して攻撃をしかけることができます。
また、COM インフラストラクチャには、コンピュータの起動時から継続的に実行されるシステム サービス RPCSS が含まれています。このサービスは、COM オブジェクトのアクティブ化および実行中のオブジェクト テーブルを管理し、DCOM リモート処理にヘルパ サービスを提供します。これによって、リモートで呼び出せる RPC インターフェイスが公開されます。一部の COM サーバーは、前のセクションで説明したとおり、認証されていないリモート アクセスを許可するため、これらのインターフェイスは、認証されていないユーザーも含めてだれもが呼び出すことができます。そのため、RPCSS は、認証されていないリモート コンピュータを使用する悪質なユーザーによって攻撃されるおそれがあります。
対策
個々の COM ベースのアプリケーションまたはサービスを保護するには、適切なコンピュータ全体の ACL に [DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ アクセス制限] を設定します。
考えられる影響
Windows XP SP2 と Windows Server2003 SP1 では、それぞれのドキュメントに記述されているように、既定の COM ACL が実装されます。COM サーバーを実装し、既定のセキュリティ設定を上書きする場合は、アプリケーション固有の呼び出し許可の ACL が、適切なユーザーに正しい許可を割り当てることを確認します。割り当てない場合は、DCOM を使用するアプリケーションおよび Windows コンポーネントが正常に動作するように、アプリケーション固有の許可の ACL を変更して適切なユーザーにアクティブ化の権限を与える必要があります。
注 : Windows XP SP2 に適用される既定の COM コンピュータ アクセス制限に関する詳細については、http://www.microsoft.com/japan/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngsecps.mspx の「グループ ポリシーを使用した Windows XP Service Pack 2 の機能の管理」を参照してください。Windows Server 2003 SP1 に適用される制限に関する詳細については、「Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1」ガイドの
「DCOM Security Enhancements」(英語情報) を参照してください。起動許可の詳細については、Microsoft MSDN® の Web サイト http://go.microsoft.com/fwlink/?LinkId=20924 の「LaunchPermission」ページ (英語情報) を参照してください。
DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ起動制限
このポリシー設定は、[DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ アクセス制限] 設定と、コンピュータ上のすべての DCOM ベースのアプリケーションへのアクセスを管理する、コンピュータ全体の追加のアクセス制御を、管理者が定義するという意味においては似ています。ただし、このポリシー設定で指定される ACL は、コンピュータ上のローカルおよびリモートの COM の (アクセス要求ではなく) 起動要求を制御します。このアクセス制御は、簡単に言うと、コンピュータ上のすべての COM サーバーの起動に対して、コンピュータ全体のアクセス制御リスト (ACL) へのチェックを実行する追加のアクセス チェック呼び出しのことです。アクセス チェックに失敗した場合、その呼び出し、アクティブ化、または起動の要求は拒否されます (このチェックは、サーバー固有の ACL に対して実行されるすべてのアクセス チェックに加えて実行されます)。実際には、コンピュータ上のいずれの COM サーバーを起動する場合にも満たす必要のある、最低限の承認基準を提供します。前述のポリシー設定との違いは、前述のポリシー設定は、起動済みの COM サーバーへのアクセスを試みたときに適用される最低限のアクセス チェックだということです。
これらのコンピュータ全体の ACL を使用すると、CoInitializeSecurity により特定のアプリケーションで指定される脆弱なセキュリティ設定や、アプリケーション固有のセキュリティ設定を上書きすることができます。特定の COM サーバーの設定に関係なく、満たす必要がある最低限のセキュリティ基準を提供します。これらの ACL により、管理者は、コンピュータ上のすべての COM サーバーに適用される全般的な承認ポリシーを一元的に設定できます。
[DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ起動制限] 設定では、2 つの方法で ACL を指定できます。セキュリティ記述子に SDDL で入力するか、またはユーザーおよびグループを選択して、ローカル アクセスまたはリモート アクセスを許可または拒否します。Microsoft では、ビルトイン ユーザー インターフェイスを使用して、この設定を適用する ACL の内容を指定することをお勧めします。
脆弱性
多くの COM アプリケーションには、何らかのセキュリティ固有のコード (CoInitializeSecurity の呼び出しなど) が含まれていますが、脆弱な設定が使用されているために、プロセスへの認証されていないアクセスが許可されてしまうことがよくあります。旧バージョンの Windows では、管理者は、アプリケーションを変更せずにこれらの設定をより強力なセキュリティで上書きすることはできません。攻撃者は、COM 呼び出しを介して、個々のアプリケーションの脆弱なセキュリティに対して攻撃をしかけることができます。
また、COM インフラストラクチャには、コンピュータの起動時から継続的に実行されるシステム サービス RPCSS が含まれています。このサービスは、COM オブジェクトのアクティブ化および実行中のオブジェクト テーブルを管理し、DCOM リモート処理にヘルパ サービスを提供します。これによって、リモートで呼び出せる RPC インターフェイスが公開されます。一部の COM サーバーは、前のセクションで説明したとおり、認証されていないリモート コンポーネントのアクティブ化を許可するため、これらのインターフェイスは、認証されていないユーザーも含めてだれもが呼び出すことができます。そのため、RPCSS は、認証されていないリモート コンピュータを使用する悪質なユーザーによって攻撃されるおそれがあります。
対策
個々の COM ベースのアプリケーションまたはサービスを保護するには、適切なコンピュータ全体の ACL に [DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ起動制限] を設定します。
考えられる影響
Windows XP SP2 と Windows Server2003 SP1 では、それぞれのドキュメントに記述されているように、既定の COM ACL が実装されます。COM サーバーを実装し、既定のセキュリティ設定を上書きする場合は、アプリケーション固有の起動許可の ACL が、適切なユーザーにアクティブ化許可を割り当てることを確認します。割り当てない場合は、DCOM を使用するアプリケーションおよび Windows コンポーネントが正常に動作するように、アプリケーション固有の起動許可の ACL を変更して適切なユーザーにアクティブ化の権限を与える必要があります。
注 : Windows XP SP2 に適用される既定の COM コンピュータ起動制限に関する詳細については、http://www.microsoft.com/japan/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngsecps.mspx の「グループ ポリシーを使用した Windows XP Service Pack 2 の機能の管理」を参照してください。Windows Server 2003 SP1 に適用される制限に関する詳細については、「Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1」ガイドの
「DCOM Security Enhancements」(英語情報) を参照してください。起動許可の詳細については、MSDN の Web サイト http://go.microsoft.com/fwlink/?LinkId=20924 の「LaunchPermission」(英語情報) を参照してください。
デバイス : ログオンなしの装着解除を許可する
このポリシー設定は、ドッキング ステーションからポータブル コンピュータの装着を解除する許可を要求するために、ユーザーがログオンする必要があるかどうかを決定します。このポリシー設定を有効にすると、ユーザーはドックされているポータブル コンピュータの物理イジェクト ボタンを押し、安全にコンピュータの装着を解除できます。このポリシー設定を無効にすると、ユーザーはコンピュータの装着を解除するために、ログオンして許可を得なければなりません。[ドッキング ステーションからコンピュータを削除] の権限を持つユーザーのみが、この許可を得ることができます。
注 : このポリシー設定は、機械的に装着解除できないポータブル コンピュータでのみ無効にします。機械的に装着解除できるコンピュータは、ユーザーが Windows の装着解除機能を使用するかどうかにかかわらず、物理的に装着解除できます。
[デバイス : ログオンなしの装着解除を許可する] で設定できる値は、次のとおりです。
脆弱性
このポリシー設定を有効にすると、ドッキング ステーションにあるポータブル コンピュータに物理的にアクセスできる人はだれでもコンピュータを装着解除でき、場合によっては不正に変更することも可能です。ドッキング ステーションのないコンピュータの場合、このポリシー設定による影響はありません。
対策
[デバイス : ログオンなしの装着解除を許可する] 設定を無効にします。
考えられる影響
コンピュータをドックしているユーザーは、ローカルのコンソールにログオンしてから、コンピュータを装着解除する必要があります。
デバイス : リムーバブル メディアを取り出すのを許可する
このポリシー設定は、リムーバブル メディアのフォーマットと取り出しを行う権限を持つユーザーを決定します。
[デバイス : リムーバブル メディアを取り出すのを許可する] で設定できる値は、次のとおりです。
脆弱性
ユーザーがリムーバブル ディスクのデータを、自分が管理権限を持つ別のコンピュータへ移動する可能性があります。その際、ユーザーが任意のファイルの所有権を取得し、フル コントロールを獲得して、ファイルの参照や変更を行うことも考えられます。ほとんどのリムーバブル ストレージ デバイスでは、機械のボタンを押してメディアを取り出せるので、このポリシー設定の長所はあまりありません。
対策
[Administrators] に [リムーバブル メディアを取り出すのを許可する] を設定します。
考えられる影響
NTFS でフォーマットされたリムーバブル メディアを取り出すことができるのは、Administrators のみになります。
デバイス : ユーザーがプリンタ ドライバをインストールできないようにする
ネットワーク プリンタに印刷するコンピュータの場合、ネットワーク プリンタのドライバをローカル コンピュータにインストールする必要があります。[デバイス : ユーザーがプリンタ ドライバをインストールできないようにする] 設定では、ネットワーク プリンタを追加する際に、だれがプリンタ ドライバをインストールできるかを決定します。このポリシー設定を有効にすると、ネットワーク プリンタを追加する際、プリンタ ドライバのインストールが Administrators グループと Power Users グループのメンバにのみ許可されます。このポリシー設定を無効にすると、ネットワーク プリンタを追加する際、すべてのユーザーがプリンタ ドライバをインストールできます。このポリシー設定は、一般的なユーザーが、信頼されていないプリンタ ドライバをダウンロードしたり、インストールすることを禁止します。
注 : 管理者が、ドライバのダウンロード用に信頼されたパスを設定している場合、このポリシー設定による影響はまったくありません。信頼されたパスを使用する場合、プリント サブシステムはドライバのダウンロードに信頼されたパスの使用を試みます。信頼されたパスのダウンロードが成功すると、任意のユーザーに代わってドライバがインストールされます。信頼されたパスのダウンロードが失敗すると、ドライバはインストールされず、ネットワーク プリンタは追加されません。
[デバイス : ユーザーがプリンタ ドライバをインストールできないようにする] で設定できる値は、次のとおりです。
脆弱性
組織によっては、ユーザーに、自身が使用するワークステーションにプリンタ ドライバをインストールすることを許可したほうが望ましい場合があります。ただし、これはサーバーにはあてはまりません。サーバー上にプリンタ ドライバをインストールすると、意図せずにコンピュータが不安定になることがあります。Administrators のみが、サーバー上でこの権限を持つようにします。悪質なユーザーがコンピュータを破損しようとして、意図的に不適切なプリンタ ドライバをインストールする可能性があります。また、ユーザーが、プリンタ ドライバに見せかけて動作する悪質なコードを、誤ってインストールする可能性もあります。
対策
[デバイス : ユーザーがプリンタ ドライバをインストールできないようにする] を [有効] に設定します。
考えられる影響
Administrative、Power User、または Server Operator の特権を持つユーザーのみが、サーバー上でプリンタをインストールすることができるようになります。このポリシー設定が有効で、ネットワーク プリンタのドライバがローカル コンピュータに既にある場合、ユーザーはネットワーク プリンタを追加できます。
デバイス : CD-ROM へのアクセスを、ローカル ログオン ユーザーだけに制限する
このポリシー設定は、ローカル ユーザーとリモート ユーザーの両方が同時に CD-ROM にアクセスできるようにするかどうかを決定します。このポリシー設定を有効にすると、対話型でログオンしたユーザーに対してのみ、リムーバル CD-ROM メディアへのアクセスが許可されます。このポリシー設定が有効でも、対話的にログオンするユーザーがいない場合は、CD-ROM にネットワーク上でアクセスできます。
[デバイス : CD-ROM へのアクセスを、ローカル ログオン ユーザーだけに制限する] で設定できる値は、次のとおりです。
脆弱性
リモート ユーザーは、機密情報を含んだマウントされた CD-ROM にアクセスできる可能性があります。このリスクは小さいものです。CD-ROM ドライブは自動的にネットワークの共有として使用可能にならないので、管理者がドライブの共有を意図的に選択する必要があるからです。ただし、管理者は、ネットワーク ユーザーがサーバー上のリムーバブル メディアからデータを表示したりアプリケーションを実行したりできないようにする必要がある場合があります。
対策
[CD-ROMへのアクセスを、ローカル ログオン ユーザーだけに制限する] 設定を有効にします。
考えられる影響
ネットワーク上でサーバーに接続するユーザーは、サーバーのローカル コンソールにログオンするユーザーがいる場合は必ず、サーバーにインストールされた CD-ROM ドライブを使用できなくなります。CD-ROM ドライブへのアクセスが必要なシステム ツールは、処理に失敗します。たとえば、ボリューム シャドウ コピー サービスは初期化の際、コンピュータ上にあるすべての CD-ROM ドライブおよびフロッピー ディスク ドライブへのアクセスを試みます。これらのドライブのうち 1 つでもアクセスできない場合、初期化に失敗します。この状態により、ボリュームのシャドウ コピーがバックアップ ジョブに指定されていた場合、Windows のバックアップ ユーティリティは処理に失敗します。また、ボリューム シャドウ コピーを使用するサードパーティ バックアップ製品はすべて処理に失敗します。このポリシー設定は、コンピュータがネットワーク ユーザーの CD ジュークボックスとして動作する場合には不適切です。
デバイス : フロッピーへのアクセスを、ローカル ログオン ユーザーだけに制限する
このポリシー設定は、ローカル ユーザーとリモート ユーザーの両方が同時にリムーバル フロッピー メディアにアクセスできるようにするかどうかを決定します。このポリシー設定を有効にすると、対話型でログオンしたユーザーに対してのみ、リムーバル フロッピー メディアへのアクセスが許可されます。このポリシー設定が有効でも、対話的にログオンするユーザーがいない場合は、フロッピーにネットワーク上でアクセスできます。
[デバイス : フロッピーへのアクセスを、ローカル ログオン ユーザーだけに制限する] で設定できる値は、次のとおりです。
脆弱性
リモート ユーザーは、機密情報を含んだマウントされたフロッピーにアクセスできる可能性があります。このリスクは小さいものです。フロッピー ドライブは自動的にネットワークの共有として使用可能にならないので、管理者がドライブの共有を意図的に選択する必要があるからです。ただし、管理者は、ネットワーク ユーザーがサーバー上のリムーバブル メディアからデータを表示したりアプリケーションを実行したりできないようにする必要がある場合があります。
対策
[フロッピーへのアクセスをローカル ログオン ユーザーだけに制限する] 設定を有効にします。
考えられる影響
ネットワーク上でサーバーに接続するユーザーは、サーバーのローカル コンソールにログオンするユーザーがいる場合は必ず、サーバーにインストールされたフロッピー ディスク ドライブを使用できなくなります。フロッピー ドライブへのアクセスを必要とするシステム ツールは、処理に失敗します。たとえば、ボリューム シャドウ コピー サービスは初期化の際、コンピュータ上にあるすべての CD-ROM ドライブおよびフロッピー ディスク ドライブへのアクセスを試みます。これらのドライブのうち 1 つでもアクセスできない場合、初期化に失敗します。この状態により、ボリュームのシャドウ コピーがバックアップ ジョブに指定されていた場合、Windows のバックアップ ユーティリティは処理に失敗します。また、ボリューム シャドウ コピーを使用するサードパーティ バックアップ製品はすべて処理に失敗します。
デバイス : 署名されていないドライバのインストール時の動作
このポリシー設定は、Setup アプリケーション プログラミング インターフェイス (API) によって、WHQL (Windows Hardware Quality Lab) による認証も署名もないデバイス ドライバのインストールが試みられた場合、どう対処するかを決定します。
[デバイス : 署名されていないドライバのインストール時の動作] で設定できる値は、次のとおりです。
-
警告なしで許可する
-
警告するがインストールは許可する
-
インストールを許可しない
-
未定義
脆弱性
このポリシー設定は、未署名のドライバのインストールを防止したり、未署名のドライバのソフトウェアがインストールされることを管理者に警告します。これにより、Setup API を使用した、Windows XP または Windows Server 2003 での実行が認証されていないドライバのインストールを防止できます。ただし、このポリシー設定は、悪質な .sys ファイルをコピーおよび登録してシステム サービスとして起動する、一部の攻撃ツールによる攻撃を防止するものではありません。
対策
[デバイス : 署名されていないドライバのインストール時の動作] を [警告するがインストールは許可する] に設定します。これは、Windows XP SP2 の既定の構成です。Windows Server 2003 の既定の構成は、[未定義] です。
考えられる影響
デバイス ドライバをインストールするのに十分な特権を持つユーザーは、未署名のデバイス ドライバをインストールできるようになります。しかし、これによりサーバーに安定性の問題が生じることがあります。[警告するがインストールは許可する] に設定した場合に考えられるもう 1 つの問題は、無人インストールのスクリプトが未署名のドライバをインストールしようとすると失敗することです。
ドメイン コントローラ : サーバー オペレータがタスクのスケジュールを割り当てるのを許可する
このポリシー設定は、AT スケジュール機能を使用したジョブの送信をサーバー オペレータに許可するかどうかを決定します。
注 : このセキュリティ オプションの設定は、AT スケジュール機能にのみ影響します。タスク スケジューラ機能には影響しません。
[ドメイン コントローラ : サーバー オペレータがタスクのスケジュールを割り当てるのを許可する] で設定できる値は、次のとおりです。
脆弱性
このポリシー設定を有効にすると、AT サービスからサーバー オペレータが作り出したジョブは、サービスを実行するアカウントのコンテキストで実行されます。既定では、ローカルの SYSTEM アカウントに設定されています。このポリシー設定を有効にすると、SYSTEM では実行可能でも、サーバー オペレータでは通常は実行できないはずの、アカウントをローカルの Administrators グループに追加するなどのタスクも実行できるようになります。
対策
[ドメイン コントローラ : サーバー オペレータがタスクのスケジュールを割り当てるのを許可する] 設定を無効にします。
考えられる影響
ほとんどの組織において、影響はあまりありません。Server Operators グループのユーザーを含むユーザーは、タスク スケジューラ ウィザード でジョブを作成することができます。ただし、これらのジョブは、ユーザーがジョブを設定したときに認証されるアカウントのコンテキストで実行されます。
ドメイン コントローラ : LDAP サーバー署名必須
このポリシー設定は、LDAP (Lightweight Directory Access Protocol) サーバーで、LDAP クライアントにデータ署名のネゴシエートを要求するかどうかを決定します。
[ドメイン コントローラ : LDAP サーバー署名必須] で設定できる値は、次のとおりです。
脆弱性
署名されていないネットワークのトラフィックは、仲介者攻撃に対して脆弱です。仲介者攻撃では、攻撃者はサーバーとクライアント間のパケットを取り込み、クライアントへの転送前にこれに変更を加えます。LDAP サーバーの場合、攻撃者はクライアントに LDAP ディレクトリからの間違ったレコードに基づいて意思決定させることが可能です。企業ネットワークにおけるこのリスクを軽減するには、強固で物理的なセキュリティ対策を実行し、ネットワーク インフラストラクチャを保護します。さらに、インターネット プロトコル セキュリティ (IP Sec) の認証ヘッダー モード (AH) (IP トラフィック の相互認証とパケットの統合を実行します) を実装することで、あらゆる種類の仲介者攻撃を困難にすることができます。
対策
[ドメイン コントローラ : LDAP サーバー署名必須] を [署名属性の要求] に設定します。
考えられる影響
LDAP 署名をサポートしないクライアントは、ドメイン コントローラに対する LDAP クエリを実行できなくなります。Windows Server 2003 またはWindows XP ベースの コンピュータで管理され、Windows NT® Challenge/Response (NTLM) 認証を使用する、組織内のすべての Windows 2000 ベースのコンピュータには、Windows 2000 Service Pack 3 (SP3) がインストールされている必要があります。または、マイクロソフト サポート技術情報の記事 Q325465 http://support.microsoft.com/default.aspx?scid=325465 の「Windows Server 2003 管理ツールを使用する場合、Windows 2000 ドメイン コントローラは SP3 またはそれ以降のサービスパックが必要」の説明に基づき、レジストリを変更する必要があります。また、一部のサードパーティのオペレーティング システムは、LDAP 署名をサポートしません。このポリシー設定を有効にすると、それらのオペレーティング システムを使用するクライアント コンピュータがドメインのリソースにアクセスできない場合があります。
ドメイン コントローラ : コンピュータ アカウントのパスワードの変更を拒否する
このポリシー設定は、ドメイン コントローラがコンピュータ アカウントのパスワード変更要求を承認するかどうかを決定します。
[ドメイン コントローラ : コンピュータ アカウントのパスワードの変更を拒否する] で設定できる値は、次のとおりです。
脆弱性
ドメインのすべてのドメイン コントローラでこのポリシー設定を有効にすると、ドメイン メンバはコンピュータ アカウント パスワードを変更することができなくなり、パスワードが攻撃に対してより脆弱になります。
対策
[ドメイン コントローラ : コンピュータ アカウントのパスワードの変更を拒否する] 設定を無効にします。
考えられる影響
なし。これは既定の構成です。
ドメイン メンバ : セキュリティ チャネルのデータをデジタル的に暗号化または署名する (複数の関連した設定)
次のポリシー設定では、セキュリティ チャネルのトラフィックに対して署名または暗号化できないドメイン コントローラで、セキュリティ チャネルを設定できるかどうかを決定します。
-
ドメイン メンバ : 常にセキュリティ チャネルのデータをデジタル的に暗号化または署名する
-
ドメイン メンバ : 可能な場合、セキュリティ チャネルのデータをデジタル的に暗号化する
-
ドメイン メンバ : 可能な場合、セキュリティ チャネルのデータをデジタル的に署名する
[ドメイン メンバ : 常にセキュリティ チャネルのデータをデジタル的に暗号化または署名する] 設定を有効にすると、すべてのセキュリティ チャネル データに対して署名または暗号化できないドメイン コントローラでは、セキュリティ チャネルを確立できません。
仲介者攻撃、リプレイ攻撃、およびその他のネットワーク攻撃から認証トラフィックを保護するため、Windows ベースのコンピュータではセキュリティ チャネルと呼ばれる、NetLogon による通信チャネルが作成されます。これらのチャネルは、コンピュータ アカウントを認証します。また、リモート ユーザーがネットワーク リソースに接続し、そのユーザー アカウントが信頼されたドメインにある場合、ユーザー アカウントを認証します。この認証はパススルー認証と呼ばれ、ドメインに参加したコンピュータが、そのドメインや別の信頼されるドメインで、ユーザー アカウント データベースにアクセスすることを許可します。
注 : [ドメイン メンバ : 常にセキュリティ チャネルのデータをデジタル的に暗号化または署名する] 設定をメンバのワークステーションやサーバーで有効にするには、メンバが所属するドメインのすべてのドメイン コントローラで、あらゆるセキュリティ チャネル データに対して署名または暗号化できることが必要です。それには、こうしたドメイン コントローラがすべて、Windows NT 4.0 Service Pack 6a 以降の Windows オペレーティング システムを実行している必要があります。
[ドメイン メンバ : 常にセキュリティ チャネルのデータをデジタル的に暗号化または署名する] 設定を有効にすると、[ドメイン メンバ : 可能な場合、セキュリティ チャネルのデータをデジタル的に署名する] 設定が自動的に有効になります。
このポリシーで設定できる値は、次のとおりです。
脆弱性
Windows Server 2003、Windows XP、Windows 2000 または Windows NT コンピュータがドメインに参加すると、コンピュータ アカウントが作成されます。ドメイン参加後、このコンピュータはそのアカウントのパスワードを使用して、再起動時に毎回そのドメインのドメイン コントローラでセキュリティ チャネルを作成します。セキュリティ チャネルに関して送られた要求が認証され、パスワードなどのデリケートな情報が暗号化されます。しかし、チャネルには統合性のチェックはなく、情報がすべて暗号化されるとは限りません。コンピュータが、セキュリティで保護されたチャネル データに対して常に暗号化または署名を行うように構成されていても、ドメイン コントローラがそれらのデータのどのような部分に対しても署名または暗号化できない場合、コンピュータとドメイン コントローラはセキュリティで保護されたチャネルを確立できません。コンピュータが、可能な場合にセキュリティ チャネルを暗号化または署名するように構成されている場合、セキュリティ チャネルは設定されますが、暗号化や署名のレベルはネゴシエートされます。
対策
-
[ドメイン メンバ : 常にセキュリティ チャネルのデータをデジタル的に暗号化または署名する] の値を [有効] に設定します。
-
[ドメイン メンバ : 可能な場合、セキュリティ チャネルのデータをデジタル的に暗号化する] を [有効] に設定します。
-
[ドメイン メンバ : 可能な場合、セキュリティ チャネルのデータをデジタル的に署名する] を [有効] に設定します。
考えられる影響
"セキュリティ チャネル" のデジタル的な暗号化や署名は、サポートされている場合には良い方法だといえます。セキュリティ チャネルは、ドメインの資格情報がドメイン コントローラに送られる際に保護します。ただし、Windows NT 4.0 Service Pack 6a (SP6a) 以降の Windows オペレーティング システムのみが、セキュリティ チャネルのデジタル的な暗号化や署名をサポートします。Windows 98 Second Edition のクライアントはこれをサポートしません (Dsclient がインストールされている場合を除きます)。このため、[ドメイン メンバ : 常にセキュリティ チャネルのデータをデジタル的に暗号化または署名する] 設定は、ドメイン メンバとして Windows 98 クライアントをサポートするドメイン コントローラ上では、有効にできません。考えられる影響には、次のようなものがあります。
-
ダウンレベル信頼関係の作成または削除機能が無効になります。
-
ダウンレベル クライアントからのログオンが無効になります。
-
ダウンレベルの信頼されたドメインの他のドメイン ユーザーを認証できなくなります。
ドメインからすべての Windows 9x クライアントを排除して、すべての Windows NT 4.0 サーバーとドメイン コントローラを信頼された、または信頼するドメインから、Windows NT 4.0 SP6a にアップグレードすると、このポリシー設定を有効にできます。他の 2 つの設定、[ドメイン メンバ : 可能な場合、セキュリティ チャネルのデータをデジタル的に暗号化する] と [ドメイン メンバ : 可能な場合、セキュリティ チャネルのデータをデジタル的に署名する] は、これらの設定をサポートするドメイン内のすべてのコンピュータで有効にできます。ダウンレベルのクライアントやアプリケーションに影響はありません。
ドメイン メンバ : コンピュータ アカウント パスワード : 定期的な変更を無効にする
このポリシー設定は、ドメイン メンバがコンピュータ アカウント パスワードを定期的に変更できるかどうかを決定します。このポリシー設定を有効にすると、ドメイン メンバはコンピュータ アカウント パスワードを変更できません。このポリシー設定を無効にすると、ドメイン メンバは、[ドメイン メンバ : 最大コンピュータ アカウントのパスワードの有効期間] 設定で指定されたとおりに、コンピュータ アカウント パスワードを変更することができます。既定では、30 日ごとに設定されています。
注 : このポリシー設定は有効にしないでください。コンピュータ アカウント パスワードは、メンバとドメイン コントローラ間、ドメイン内、ドメイン コントローラ間でのセキュリティ チャネルの通信の確立に使用されます。そのような通信が確立されると、セキュリティ チャネルは認証や承認の決定に必要な機密情報を転送します。
同一のコンピュータ アカウントを使うデュアルブートのシナリオ サポートに、このポリシー設定を使用しないでください。同じドメインに参加する 2 つのインストールでこのシナリオをサポートする場合、2 つのインストールに異なるコンピュータ名を使用してください。このポリシー設定は、数か月後に生産活動に入るあらかじめ構築されたコンピュータの備蓄を持つ組織の作業を、より簡素化するために Windows に追加されました。これらのコンピュータは、ドメインに参加し直す必要はありません。また、このポリシー設定は、イメージ化されたコンピュータ、またはハードウェアやソフトウェア レベルの変更が防止されているコンピュータとともに使用されることがあります。イメージ化の正しいプロシージャでは、イメージ化されたコンピュータに対してこのポリシーを使用する必要はありません。
[ドメイン メンバ : コンピュータ アカウント パスワード : 定期的な変更を無効にする] で設定できる値は、次のとおりです。
脆弱性
ドメインに属する Windows Server 2003 ベースのコンピュータの既定の構成では、30 日ごとにアカウント パスワードの変更が自動的に要求されます。このポリシー設定を無効にすると、Windows Server 2003 を実行するコンピュータは、コンピュータ アカウントと同じパスワードを保持します。このため、アカウント パスワードを自動変更できないコンピュータから、攻撃者がコンピュータのドメイン アカウントのパスワードを割り出すおそれがあります。
対策
[ドメイン メンバ : コンピュータ アカウント パスワード : 定期的な変更を無効にする] が [無効] に設定されていることを確認します。
考えられる影響
なし。これは既定の構成です。
ドメイン メンバ : 最大コンピュータ アカウントのパスワードの有効期間
このポリシー設定は、コンピュータ アカウント パスワードの最長有効期間を決定します。この設定は Windows 2000 コンピュータにも適用されますが、Windows 2000 マシンの Security Configuration Manager ツールからは使用できません。
[ドメイン メンバ : 最大コンピュータ アカウントのパスワードの有効期間] で設定できる値は、次のとおりです。
脆弱性
Active Directory ベースのドメインでは、各ユーザーと同様、各コンピュータはアカウントとパスワードを持っています。既定では、ドメイン メンバはドメイン パスワードを、30 日ごとに自動的に変更します。この間隔を大幅に延ばすか、またはこの設定を 0 にして、コンピュータのパスワードを変更しないようにすると、攻撃者がいずれかのコンピュータ アカウントのパスワードを推測するブルート フォース攻撃を仕掛ける期間がより長くなります。
対策
[ドメイン メンバ : 最大コンピュータ アカウントのパスワードの有効期間] を 30 日 に設定します。
考えられる影響
なし。これは既定の構成です。
ドメイン メンバ : 強力な (Windows 2000 かそれ以降のバージョン) セッション キーを必要とする
このポリシー設定は、セキュリティ チャネル トラフィックを強力な 128 ビットのセッション キーで暗号化できないドメイン コントローラで、セキュリティ チャネルを確立できるかどうかを決定します。このポリシー設定を有効にすると、強力なキーでセキュリティ チャネル データを暗号化できないドメイン コントローラでは、セキュリティ チャネルを確立できなくなります。このポリシー設定を無効にすると、64 ビット セッション キーが許可されます。
注 : このポリシー設定をメンバ ワークステーションやサーバーで有効にするには、メンバが所属するドメインの全ドメイン コントローラで、強力な 128 ビット キーを使ってセキュリティ チャネルを暗号化できる必要があります。つまり、すべてのドメイン コントローラが、Windows 2000 またはそれ以降のバージョンの Windows オペレーティング システムを実行している必要があります。
[ドメイン メンバ : 強力な (Windows 2000 かそれ以降のバージョン) セッション キーを必要とする] で設定できる値は、次のとおりです。
脆弱性
Windows 2000 では、ドメイン コントローラとメンバ コンピュータ間でセキュリティで保護されたチャネル通信を確立するために使用されるセッション キーは、以前の Microsoft オペレーティング システムのセッション キーよりも強力になっています。
可能な限り、これらの強力なセッション キーを活用して、ネットワーク セッションのハイジャックや盗聴などの攻撃から、セキュリティ チャネル通信を保護する必要があります (盗聴は、転送中にネットワーク データを読み込んだり、変更するハッキングの一形態です。データは送信者を非表示にしたり変更したりするために変更されます。また、リダイレクトされることもあります)。
対策
[ドメイン メンバ : 強力な (Windows2000 かそれ以降のバージョン) セッション キーを必要とする] を [有効] に設定します。
このポリシー設定を有効にすると、セキュリティで保護されたチャネルを通じて発信されるトラフィックにはすべて、強力な Windows 2000 またはそれ以降の暗号化キーが必要となります。このポリシー設定を無効にすると、キーの強度がネゴシエートされます。すべての信頼されるドメインのドメイン コントローラが、強力なキーをサポートする場合のみ、このオプションを有効にしてください。既定では、このポリシー設定は無効になっています。
考えられる影響
このポリシー設定が有効のコンピュータは、Windows NT 4.0 ドメインに参加できません。また、Active Directory ドメインと Windows NT 形式のドメインとの間の信頼関係が正常に動作しない可能性があります。また、このポリシー設定をサポートしないコンピュータは、このポリシー設定が有効なドメイン コントローラのあるドメインに参加できません。
対話型ログオン : 最後のユーザー名を表示しない
このポリシー設定は、コンピュータに最後にログオンしたユーザー名を [Windows へログオン] ダイアログ ボックスに表示させるかどうかを決定します。このポリシー設定を有効にすると、最後に正常にログオンしたユーザー名は表示されません。このポリシー設定を無効にすると、最後にログオンしたユーザー名が表示されます。
[対話型ログオン : 最後のユーザー名を表示しない] で設定できる値は、次のとおりです。
脆弱性
物理的にアクセスできたり、ターミナル サービスからサーバーに接続できるなど、コンソールにアクセスできる攻撃者は、サーバーに最後にログオンしたユーザー名を参照することができます。そして、パスワードを推測したり、辞書を使用したり、ブルート フォース攻撃をしかけて、ログオンしようと試みます。
対策
[ログオン画面に最後のユーザー名を表示しない] を [有効] に設定します。
考えられる影響
サーバーにログオンする際に、ユーザーは毎回ユーザー名をタイプする必要があります。
対話型ログオン : Ctrl + Alt + Del を必要としない
このポリシー設定は、ユーザーがログオンする前に Ctrl + Alt + Del キーを押す必要があるかどうかを決定します。このポリシー設定を有効にすると、ユーザーはこのキーの組み合わせを押さなくてもログオンできます。このポリシー設定を無効にすると、ユーザーは、Windows にログオンする前に必ず Ctrl + Alt + Del キーを押す必要があります。ただし、スマート カードを使用して Windows にログオンする場合は例外です。スマート カードは、セキュリティ情報を格納する不正防止デバイスです。
[対話型ログオン : Ctrl + Alt + Del を必要としない] で設定できる値は、次のとおりです。
脆弱性
Microsoft は、身体に何らかの障害のあるユーザーが、Windows を実行するコンピュータへのログオンをより簡単に行えるように、この機能を開発しました。Ctrl + Alt + Del キーを押すことが要求されない場合、パスワードを入手しようとする攻撃に対して、ユーザーは脆弱になります。ログオンに Ctrl + Alt + Del キーが必要な場合、ユーザー パスワードは信頼されたパスを使って通信されます。
攻撃者は、標準の Windows のログオン ダイアログ ボックスに類似したトロイの木馬プログラムをインストールして、ユーザーのパスワードを取り込むことができます。そして、そのユーザーが持つレベルの特権を使って、侵入したアカウントにログオンできます。
対策
[ログオンに Ctrl + Alt + Del を必要としない] を [無効] に設定します。
考えられる影響
スマート カードを使ってログオンする場合を除き、ログオン ダイアログ ボックスが表示される前に、ユーザーは 3 つのキーを同時に押す必要があります。
対話型ログオン : ログオン時のユーザーへのメッセージのテキスト
[対話型ログオン : ログオン時のユーザーへのメッセージのテキスト] と [対話型ログオン : ログオン時のユーザーへのメッセージのタイトル] 設定は、密接な関係にあります。前者のポリシー設定は、ユーザーがログオンするときに表示されるテキスト メッセージを指定し、後者のポリシー設定はテキスト メッセージを含むウィンドウのタイトル バーに表示されるタイトルを指定します。多くの組織では、企業情報の誤用による影響についてユーザーに警告する場合や、ユーザーのアクションが監査される可能性を警告する場合など、法的な理由でこのテキストを使用します。
注 : Windows XP Professional では、512 文字を超え、キャリッジ リターン、ライン フィードのシーケンスを含めることができるログオン バナーのサポートを追加しています。ただし、Windows 2000 クライアントは、これらのメッセージを解釈して表示することができません。Windows 2000 コンピュータを使って、Windows 2000 マシンに適用するログオン メセージ ポリシーを作成する必要があります。誤って Windows XP Professional コンピュータでログオン メッセージを作成してしまい、Windows 2000 コンピュータではメッセージが適切に表示されない場合は、次を実行してください。
Windows XP Professional で定義された ログオン メッセージ設定を Windows 2000 コンピュータで変更する場合、最初に、設定を [未定義] に再構成する必要があります。
これらのポリシーで設定できる値は、次のとおりです。
脆弱性
ログオンの前にメッセージを表示して、攻撃者による攻撃を警告することは、攻撃を未然に防ぐのに役立つ可能性があります。また、ログオン プロセス中に従業員に適切なポリシーを通知することは、企業ポリシーを強化することにもつながります。
対策
[ログオン時のユーザーへのメッセージのテキスト] と [ログオン時のユーザーへのメッセージのタイトル] 設定を組織に適した値に構成します。
注 : 表示する警告はすべて、組織の法務担当者と人事担当者の承認を受ける必要があります。
考えられる影響
サーバー コンソールにログオンする前に、ユーザーにメッセージの入ったダイアログ ボックスが表示されます。
対話型ログオン : ドメイン コントローラが利用できない場合に使用する、前回ログオンのキャッシュ数
このポリシー設定は、キャッシュ内のアカウント情報を使用して Windows ドメインにログオンできる一意のユーザーの数を決定します。ドメイン アカウントのログオン情報は、ローカルにキャッシュできるので、ドメイン コントローラがその直後のログオンに接続できない場合でも、ユーザーはログオンできます。このポリシー設定で、ログオン情報がローカルにキャッシュされる、一意のユーザーの数を決定します。
ドメイン コントローラが使用できず、ユーザーのログオン情報がキャッシュされる場合、ユーザーには次のメッセージが表示されます。
このドメインのドメイン コントローラにアクセスできませんでした。キャッシュされているアカウント情報を使ってログオンしています。前回のログオン後にプロファイルに加えた変更は反映されない場合があります。
ドメイン コントローラが使用できず、ユーザーのログオン情報がキャッシュされない場合、ユーザーにはこのメッセージが表示されます。
ログオンできません。ログオン先ドメイン <ドメイン名> は利用できません。
[対話型ログオン : ドメイン コントローラが利用できない場合に使用する、前回ログオンのキャッシュ数] で設定できる値は、次のとおりです。
脆弱性
このポリシー設定に割り当てる数字は、ログオン情報がサーバーにローカルでキャッシュされるユーザーの数を指します。この数字が 10 の場合、ユーザー 10 人のログオン情報が、サーバーにキャッシュされます。11 番目のユーザーがコンピュータにログオンすると、サーバーは最初にキャッシュされたログオン セッションを上書きします。
サーバー コンソールにアクセスするユーザーは、そのサーバーでキャッシュされるログオンの資格情報を有します。サーバーのファイル システムにアクセスできる攻撃者は、キャッシュされた情報を見つけ出し、ブルート フォース攻撃でユーザー パスワードを割り出そうとします。
この種の攻撃を減らすために、Windows では情報が暗号化され、その物理的な場所をわかりにくくします。
対策
[対話型ログオン : コントローラが利用できない場合に使用する、前回ログオンのキャッシュ数] を 0 に設定します。これにより、ログオン情報のローカルなキャッシングが無効になります。この他の対策としては、強力なパスワード ポリシーの適用や、コンピュータを物理的に安全な場所で保管することなどが挙げられます。
考えられる影響
ユーザーを認証できるドメイン コントローラがない場合、ユーザーはどのコンピュータにもログオンできなくなります。エンドユーザーのコンピュータ、特にモバイル ユーザーのコンピュータに対しては、これ 2 に設定することが必要な場合があります。この値を 2 に設定すると、IT 部門のスタッフが最近コンピュータにログオンして、システム メンテナンスを実行した場合でも、ユーザーのログオン情報はキャッシュに保存されます。この方法により、ユーザーは組織のネットワークに接続していなくても、コンピュータにログオンすることができます。
対話型ログオン : パスワードが無効になる前にユーザーに変更を促す
このポリシー設定は、パスワードが無効になる何日前に、ユーザーに警告を出すかを決定します。このように事前に警告されることで、ユーザーは相当強固なパスワードを作る時間を得ることができます。
[対話型ログオン : パスワードが無効になる前にユーザーに変更を促す] で設定できる値は、次のとおりです。
脆弱性
ユーザー パスワードは、定期的に無効になるように構成することをお勧めします。その場合、パスワードの期限が切れる前にユーザーに警告を出す必要があります。パスワードの期限が切れてしまうと、コンピュータからロックアウトされることがあります。この状況になると、ローカルでネットワークにアクセスするユーザーが混乱したり、ユーザーがダイアルアップ接続または仮想プライベートネットワーク (VPN) 接続で組織のネットワークにアクセスできなくなる場合があります。
対策
[対話型ログオン : [パスワードが無効になる前にユーザーに変更を促す] を 14 日に設定します。
考えられる影響
パスワードの有効期限が 14 日後、またはそれ以前になると、ユーザーがドメインにログオンするたびに、パスワードの変更を促すダイアログ ボックスが表示されます。
対話型ログオン : workstation のロック解除にドメイン コントローラの認証を必要とする
ロックされたコンピュータのロックを解除するには、ログオン情報が必要です。ドメイン アカウントの場合、[対話型ログオン : workstation のロック解除にドメイン コントローラの認証を必要とする] 設定は、コンピュータをロック解除するのにドメイン コントローラに接続する必要があるかどうかを決定します。この設定を有効にすると、コンピュータをロック解除するには、ドメイン コントローラが使用中のドメイン アカウントを認証する必要があります。この設定を無効にすると、ドメイン コントローラによるログオン情報の確認なしで、コンピュータをロック解除できます。ただし、[対話型ログオン : ドメイン コントローラが利用できない場合に使用する、前回ログオンのキャッシュ数] に 1 以上の値を設定している場合は、ユーザーのキャッシュされた資格情報を使用して、コンピュータがロック解除されます。
注 : この設定は Windows 2000 コンピュータに適用されますが、Windows 2000 マシンの Security Configuration Manager ツールからは使用できません。
[対話型ログオン : workstation のロック解除にドメイン コントローラの認証を必要とする] で設定できる値は、次のとおりです。
脆弱性
既定では、ローカルに認証されたあらゆるユーザーの資格情報がメモリにキャッシュされます。コンピュータは、これらのキャッシュされた資格情報を使って、コンソールをロック解除しようとするユーザーを認証します。キャッシュされた資格情報を使う場合、ユーザー権利の割り当て、アカウントのロックアウト、無効になったアカウントなどの、アカウントに加えられた最新の変更は、アカウントの認証後は考慮または適用されません。ユーザー特権が更新されないだけではなく、無効なアカウントからでもコンピュータのコンソールをロック解除できます。
対策
[対話型ログオン : workstation のロック解除にドメイン コントローラの認証を必要とする] を [有効] に設定し、[対話型ログオン : ドメイン コントローラが利用できない場合に使用する、前回ログオンのキャッシュ数] を 0 に設定します。
考えられる影響
コンピュータのコンソールがロックされているときに、ユーザーがドメイン コントローラを再認証できる場合、このユーザーによって、またはスクリーン セーバーのタイムアウトで自動的に、コンソールのロック解除のみを行うことができます。ドメイン コントローラが使用できない場合、ユーザーはワークステーションをロック解除できません。[対話型ログオン : コントローラが利用できない場合に使用する、前回ログオンのキャッシュ数] を 0 に設定すると、ドメイン コントローラが使用できないユーザー (モバイル ユーザーやリモート ユーザー) はログオンできません。
対話型ログオン : スマート カードが必要
このポリシー設定では、ユーザーはスマート カードを使ってコンピュータにログオンする必要があります。
注 : この設定は Windows 2000 コンピュータに適用されますが、Windows 2000 マシンの Security Configuration Manager ツールからは使用できません。
[対話型ログオン : スマート カードが必要] で設定できる値は、次のとおりです。
脆弱性
認証に長く複雑なパスワードを要求することは、特にユーザーに定期的なパスワードの変更を義務付ける場合、ネットワークのセキュリティを高めます。これにより、攻撃者がブルート フォース攻撃でユーザーのパスワードを推測できる可能性が減ります。ただし、ユーザーに強固なパスワードの選択を徹底させるのは難しく、攻撃者に十分な時間とリソースがある場合は、強固なパスワードでもブルート フォース攻撃に対して脆弱です。認証にパスワードではなくスマート カードを使用することで、セキュリティが大幅に向上します。現在の技術では、攻撃者が別のユーザーに偽装することがほとんど不可能だからです。暗証番号 (PIN) を必要とするスマート カードでは、2 つの要素による認証を提供します。つまり、ユーザーはスマート カードを所持し、なおかつその PIN を知っている必要があります。ユーザーのコンピュータとドメイン コントローラ間の認証トラフィックを取り込む攻撃者にとって、トラフィックの解読は困難になります。解読した場合でも、ユーザーがネットワークに次回ログオンする際には、ユーザーとドメイン コントローラ間のトラフィックを暗号化する、新しいセッション キーが生成されます。
対策
機密性の高いアカウントでは、ユーザーにスマート カードを発行し、[対話型ログオン : スマート カードが必要] を [有効] に設定します。
考えられる影響
すべてのユーザーはスマート カードを使って、ネットワークにログオンする必要があります。つまり、組織は信頼できる公開キーのインフラストラクチャ (PKI) を配備し、スマート カード、スマート カード リーダーを全ユーザーに配布する必要があります。これらの要件は、テクノロジの計画と実装に専門知識とリソースを要するため、大きな課題になります。しかし、Windows Server 2003 には、証明書の実装と管理を行う高度なサービスである、証明書サービスが搭載されています。証明書サービスを Windows XP と併せて使用すると、ユーザーやコンピュータを自動的に登録および更新する機能などが使用できるようになります。
対話型ログオン : スマート カード取り出し時の動作
このポリシー設定は、ログオンしたユーザーのスマート カードをスマート カード読み取り装置から取り出したときの動作を決定します。
[対話型ログオン : スマート カード取り出し時の動作] で設定できる値は、次のとおりです。
-
何もしない
-
ワークステーションをロックする
-
ログオフを強制する
-
未定義
脆弱性
認証にスマート カードを使用する場合、カードが取り出されると、コンピュータは自動的にロックします。この方法によって、ユーザーが手動でワークステーションをロックするのを忘れてコンピュータを離れた場合でも、悪意のあるユーザーがこのコンピュータにアクセスすることはできません。
対策
[スマート カード取り出し時の動作] を [ワークステーションをロックする] に設定します。
このポリシー設定の [プロパティ] ダイアログ ボックスで [ワークステーション] を選択した場合、スマート カードが取り出されると、ワークステーションがロックされます。ユーザーはスマート カードを取り出して、それを持って席を離れても、保護されたセッションが保持されます。
このポリシーの [プロパティ] ダイアログ ボックスで [ログオフを強制する] を選択した場合、スマート カードが取り出されると、ユーザーは自動的にログオフします。
考えられる影響
ユーザーがワークステーションに戻ってきた際に、再度スマート カードを挿入して PIN を入力する必要があります。
Microsoft ネットワーク クライアントとサーバー : 通信にデジタル署名を行う (4 つの関連する設定)
SMB (Server Message Block) 通信のデジタル署名に関連する設定は次の 4 つです。
-
Microsoft ネットワーク クライアント : 常に通信にデジタル署名を行う
-
Microsoft ネットワーク サーバー : 常に通信にデジタル署名を行う
-
Microsoft ネットワーク クライアント : サーバーが同意すれば、通信にデジタル署名を行う
-
Microsoft ネットワーク サーバー : クライアントが同意すれば、通信にデジタル署名を行う
これらのポリシーで設定できる値は、次のとおりです。
脆弱性
高度なセキュリティ ネットワークでデジタル署名を実装することは、クライアントやサーバーの偽装を防ぐのに役立ちます。この種の偽装は、セッション ハイジャックと呼ばれています。セッション ハイジャックのツールを使って、クライアントまたはサーバーとして同じネットワークにアクセスした攻撃者は、実行中のセッションの妨害、終了または盗難を実行できます。攻撃者は、未署名の SMB パケットを妨害および改ざんする可能性があります。トラフィックを改ざんして転送することで、サーバーが好ましくない行動を取る場合があります。また、正式な認証後に攻撃者がサーバーまたはクライアントとして振る舞い、データに未承認のアクセスを行うことがあります。
SMB は、多くの Microsoft オペレーティング システムでサポートされるリソース共有のプロトコルです。NetBIOS やその他多くのプロトコルに基づいています。SMB の署名は、データをホストするユーザーとサーバーの両方を認証します。このいずれかで認証プロセスに失敗すると、データは転送されません。
注 : すべてのネットワーク トラフィックを保護するその他の対策としては、IPsec を使ったデジタル署名の実装があります。IPsec の暗号化と署名用にハードウェアベースのアクセラレータがあります。これを使って、サーバー CPU への影響を最小限に抑えることができます。SMB 署名には、このようなアクセラレータはありません。
対策
設定を次のように構成します。
-
[Microsoft ネットワーク クライアント : 常に通信にデジタル署名を行う] を [無効] に設定します。
-
[Microsoft ネットワーク サーバー : 常に通信にデジタル署名を行う] を [無効] に設定します。
-
[Microsoft ネットワーク クライアント : サーバーが同意すれば、通信にデジタル署名を行う] を [有効] に設定します。
-
[Microsoft ネットワーク サーバー : クライアントが同意すれば、通信にデジタル署名を行う] を [有効] に設定します。
リソースによっては、これらの設定をすべて [有効] に構成することが推奨されます。ただし、設定を有効にすることで、クライアント コンピュータのパフォーマンスが遅くなる場合があります。また、レガシ SMB アプリケーションやオペレーティング システムと通信できなくなります。
考えられる影響
Windows 2000 Server、Windows 2000 Professional、Windows Server 2003、および Windows XP Professional のファイルと印刷の共有プロトコル SMB は、相互認証をサポートします。相互認証は、セッション ハイジャック攻撃を阻止し、メッセージの認証をサポートして仲介者攻撃を防ぎます。SMB 署名は、各 SMB にデジタル署名を行うことで、これを認証します。その後、この認証はクライアントとサーバーの両方で、検証されます。SMB 署名を実装すると、各パケットは署名および確認を必要とするため、パフォーマンスに悪影響を及ぼす可能性があります。コンピュータが、署名のない SMB 通信をすべて無視するように構成されている場合、レガシー アプリケーションおよびレガシー オペレーティング システムは接続できません。すべての SMB 署名を完全に無効にすると、コンピュータはセッション ハイジャック攻撃に対して脆弱になります。
Microsoft ネットワーク クライアント : サード パーティ製の SMB サーバーへのパスワードを、暗号化しないで送信する
このポリシー設定を使うと、SMB リダイレクタは、認証中のパスワード暗号化をサポートしない非 Microsoft SMB サーバーへ、プレーンテキストのパスワードを送信できます。
[Microsoft ネットワーク クライアント : サード パーティ製の SMB サーバーへのパスワードを、暗号化しないで送信する] で設定できる値は、次のとおりです。
脆弱性
このポリシー設定を有効にすると、サーバーは、SMB サービスを持つネットワーク上の他のコンピュータへ、パスワードをプレーンテキストで転送できます。これらのコンピュータは、Windows Server 2003 に含まれる SMB セキュリティのメカニズムを、まったく使用しない可能性があります。
対策
[Microsoft ネットワーク クライアント : サード パーティ製の SMB サーバーへのパスワードを、暗号化しないで送信する] を [無効] に設定します。
考えられる影響
MS-DOS、Windows for Workgroups 3.11 および Windows 95a など、古いアプリケーションやオペレーティング システムの場合、SMB プロトコル経由で組織のサーバーと通信できない可能性があります。
Microsoft ネットワーク サーバー : セッションを中断する前に、ある一定のアイドル時間を必要とする
このポリシー設定は、SMB セッションのアイドル状態が何分続いたら、セッションを非アクティブとみなして中断するかを決定します。管理者はこのポリシー設定を使用して、コンピュータが非アクティブな SMB セッションを中断するタイミングを制御できます。クライアントのアクティビティが再開すると、セッションは自動的に再度確立されます。値が 0 のときは、アイドル状態のセッションができるだけ早く中断されます。最大値は 99999 で 208 日間です。事実上、この値は設定を無効にします。
[Microsoft ネットワーク サーバー : セッションを中断する前に、ある一定のアイドル時間を必要とする] で設定できる値は、次のとおりです。
脆弱性
各 SMB セッションがサーバーのリソースを消費します。また、多数の NULL セッションによってサーバーの速度が低下し、場合によってはサーバーがダウンします。サーバーの SMB サービスが減速するか、応答不能になるまで、攻撃者は繰り返し SMB セッションを確立することができます。
対策
[Microsoft ネットワーク サーバー : セッションを中断する前に、ある一定のアイドル時間を必要とする] を 15 分に設定します。
考えられる影響
クライアントがアクティビティを再開すると自動的に SMB セッションは再度確立されるので、影響はほとんどありません。
Microsoft ネットワーク サーバー : ログオン時間の有効期間が切れるとクライアントを切断する
このポリシー設定は、ローカル コンピュータに接続しているユーザーのログオン時間がユーザー アカウントの制限時間に達したとき、強制的にそのユーザーを切断するかどうかを決定します。これは、SMB コンポーネントに影響します。このポリシー設定を有効にすると、SMB サービスを使用するクライアント セッションは、そのクライアントのログオン時間の有効期間が過ぎると強制的に切断されます。このポリシー設定を無効にすると、確立されたクライアント セッションは、そのクライアントのログオン時間の有効期間が切れても維持されます。このポリシー設定を有効にした場合、[ネットワーク セキュリティ : ログオン時間を経過した場合はユーザーを強制的にログオフさせる] も有効にする必要があります。
[Microsoft ネットワーク サーバー : ログオン時間の有効期間が切れるとクライアントを切断する] で設定できる値は、次のとおりです。
脆弱性
組織でユーザーのログオン時間が決められている場合には、このポリシー設定を有効にします。この設定を有効にしないと、ログオン時間の有効期間が過ぎるとネットワーク リソースへのアクセスを拒否されるべきユーザーであっても、アクセス時間内に確立されたセッションを通じてネットワーク リソースを引き続き使用できることになります。
対策
[Microsoft ネットワーク サーバー : ログオン時間の有効期間が切れるとクライアントを切断する] 設定を有効にします。
考えられる影響
組織でログオン時間を定義していない場合は、このポリシー設定を有効にしても何も実行されません。ログオン時間を定義している場合は、ユーザーのログオンが制限時間に達した時点で、そのユーザー セッションが強制的に終了されます。
ネットワーク アクセス : 匿名の SID と名前の変換を許可する
このポリシー設定は、匿名ユーザーが別のユーザーの SID 属性を要求できるかどうかを決定します。
[ネットワーク アクセス : 匿名の SID と名前の変換を許可する] で設定できる値は、次のとおりです。
脆弱性
このポリシー設定が有効な場合、ローカルにアクセスしているユーザーは、アカウントの名前が変更されている場合でも、一般的な Administrators SID を使って、ビルトイン Administrator アカウントの本当の名前を取得することができます。さらに、そのユーザーは、取得したアカウント名を使用してパスワード推測攻撃を開始することができます。
対策
[ネットワーク アクセス : 匿名の SID と名前の変換を許可する] を [無効] に設定します。
考えられる影響
メンバ コンピュータでは、このポリシー設定が既定で [無効] に設定されているので影響はありません。ドメイン コントローラの既定の設定は、[有効] です。ドメイン コントローラでこのポリシー設定を無効にすると、レガシ コンピュータが Windows Server 2003 ベースのドメインと通信できない場合があります。たとえば、次のコンピュータは動作しない場合があります。
-
Windows NT 4.0 ベースのリモート アクセス サービス サーバー
-
Windows NT 3.x ベースまたは Windows NT 4.0 ベースのコンピュータで実行される Microsoft SQL Server™
-
Windows NT 3.x ドメインまたは Windows NT 4.0 ドメインにある、Windows 2000 ベースのコンピュータで実行中のリモート アクセス サービスまたは Microsoft SQL Server
ネットワーク アクセス : SAM アカウントの匿名の列挙を許可しない
このポリシー設定は、コンピュータへの匿名の接続に追加で与える権限を決定します。Windows では、匿名のユーザーは、ドメイン アカウントやネットワーク共有の名前の列挙など、一定のアクティビティを実行できます。この設定は、たとえば、相互信頼のない信頼されたドメインで、管理者がユーザーにアクセス権限を付与する場合に便利です。ただし、この設定を有効にした場合でも、匿名ユーザーが、特殊ビルトイン グループ ANONYMOUS LOGON を明示的に含むアクセス許可を持つリソースにアクセスすることは可能です。
Windows 2000 では、[匿名接続の追加を制限する] と呼ばれる同様のポリシー設定が、HKLM\SYSTEM\CurrentControlSet\Control\LSA レジストリ キーの RestrictAnonymous というレジストリ値を管理していました。Windows Server 2003 では、ポリシー設定 [ネットワーク アクセス : SAM アカウントの匿名の列挙を許可しない] と [ネットワーク アクセス : SAM アカウントおよび共有の匿名の列挙を許可しない] が Windows 2000 のポリシー設定に置き換わっています。両者はそれぞれ、HKLM\System\CurrentControlSet\Control\Lsa\ レジストリ キーにある、レジストリ値 RestrictAnonymousSAM と RestrictAnonymous を管理します。
[ネットワーク アクセス : SAM アカウントの匿名の列挙を許可しない] で設定できる値は、次のとおりです。
脆弱性
未承認のユーザーでも、匿名でアカウント名をリストし、その情報を使って、ソーシャル エンジニアリング攻撃を実行したり、パスワードの推測攻撃を試みたりできます (ソーシャル エンジニアリング攻撃とは、何らかの方法でユーザーをだまして、パスワードや何らかの形式のセキュリティ情報を取得しようとするものです)。
対策
[ネットワーク アクセス : SAM アカウントの匿名の列挙を許可しない] を [有効] に設定します。
考えられる影響
Windows NT 4.0 ベースのドメインで信頼を確立することができなくなります。また、Windows NT 3.51 や Windows 95 など、古いバージョンの Windows オペレーティング システムを実行するクライアント コンピュータでサーバー上のリソースを使用する際に、問題が発生します。
ネットワーク アクセス : SAM アカウントおよび共有の匿名の列挙を許可しない
このポリシー設定は、セキュリティ アカウント マネージャ (SAM) アカウントと共有の匿名の列挙を許可するかどうかを決定します。前のセクションで説明したとおり、Windows では、匿名のユーザーは、ドメイン アカウントやネットワーク共有の名前の列挙など、一定のアクティビティを実行できます。この設定は、たとえば、相互信頼のない信頼されたドメインで、管理者がユーザーにアクセス権限を付与する場合に便利です。SAM アカウントと共有の匿名の列挙を許可しない場合、このポリシー設定を有効にしてください。ただし、この設定を有効にした場合でも、匿名ユーザーが、特殊ビルトイン グループ ANONYMOUS LOGON を明示的に含むアクセス許可を持つリソースにアクセスすることは可能です。
Windows 2000 では、[匿名接続の追加を制限する] と呼ばれる同様のポリシー設定が、HKLM\SYSTEM\CurrentControlSet\Control\LSA レジストリ キーの RestrictAnonymous というレジストリ値を管理していました。Windows Server 2003 では、ポリシー設定 [ネットワーク アクセス : SAM アカウントの匿名の列挙を許可しない] と [ネットワーク アクセス : SAM アカウントおよび共有の匿名の列挙を許可しない] が Windows 2000 のポリシー設定に置き換わっています。両者はそれぞれ、HKLM\System\CurrentControlSet\Control\Lsa\ レジストリ キーにある、レジストリ値 RestrictAnonymousSAM と RestrictAnonymous を管理します。
[ネットワーク アクセス : SAM アカウントおよび共有の匿名の列挙を許可しない] で設定できる値は、次のとおりです。
脆弱性
未承認のユーザーは、匿名でアカウント名や共有リソースをリストし、その情報を使って、パスワードの推測攻撃を試みたり、ソーシャル エンジニアリング攻撃を実行することができます。
対策
[ネットワーク アクセス : SAM アカウントおよび共有の匿名の列挙を許可しない] を [有効] に設定します。
考えられる影響
一方向の信頼で別のドメイン ユーザーにアクセスを付与することができなくなります。これは、信頼するドメインの管理者が、他のドメインのアカウント リストを列挙できなくなるためです。ファイル サーバーとプリント サーバーに匿名でアクセスするユーザーは、これらのサーバーの共有ネットワーク リソースをリストできなくなります。共有フォルダや共有プリンタのリストを参照する前に、ユーザーの認証が必要になります。
ネットワーク アクセス : ネットワーク認証のために資格情報または .NET Passport を保存することを許可しない
このポリシー設定は、ドメインの認証を得る際、ユーザー名およびパスワードの保存機能で、パスワードまたは資格情報を後で使用するために保存するかどうかを決定します。このポリシー設定を有効にすると、Windows のユーザー名とパスワードの保存機能でパスワードと資格情報を保存できなくなります。
[ネットワーク アクセス : ネットワーク認証のために資格情報または .NET Passport を保存することを許可しない] で設定できる値は、次のとおりです。
脆弱性
ユーザーはログオン時に、キャッシュされたパスワードへアクセスできます。パスワードを読み取って、これを別の未承認のユーザーへ転送する悪質なコードを、ユーザーが知らずに実行した場合に問題が発生します。
注 : 適切なソフトウェアの制限ポリシーと併せて、企業のアンチウイルス ソリューションを効果的に実装および管理する組織では、このような悪質なコードが実行されるチャンスは大幅に減少します。ソフトウェアの制限ポリシーに関する詳細は、「第 8 章 ソフトウェア制限ポリシー」を参照してください。
対策
[ネットワーク アクセス : ネットワーク認証のために資格情報または .NET Passport を保存することを許可しない] を [有効] に設定します。
考えられる影響
ユーザーが Passport アカウント、またはユーザーのドメイン アカウントへのアクセスがない他のネットワーク リソースにログオンするときは、毎回パスワードの入力を求められます。このポリシー設定では、Active Directory ベースのドメイン アカウントへのアクセスを許可するように構成されたネットワーク リソースにアクセスするユーザーへの影響はありません。
ネットワーク アクセス : Everyone のアクセス許可を匿名ユーザーに適用する
このポリシー設定は、コンピュータへの匿名の接続に追加で与える権限を決定します。このポリシー設定を有効にすると、匿名ユーザーは、ドメイン アカウントとネットワーク共有の名前の列挙、および他の一定のアクティビティを実行できます。この設定は、たとえば、相互信頼のない信頼されたドメインで、管理者がユーザーにアクセス権限を付与する場合に便利です。
既定では、匿名の接続に作成されるトークンは、Everyone SID を含みません。このため、Everyone グループに付与される権限は、匿名のユーザーには適用されません。このポリシー設定を有効にすると、匿名の接続に作成されるトークンに Everyone SID が追加され、匿名ユーザーは Everyone グループにアクセスが許可されたすべてのリソースにアクセスできます。
[ネットワーク アクセス : Everyone のアクセス許可を匿名ユーザーに適用する] で設定できる値は、次のとおりです。
脆弱性
未承認のユーザーは、匿名でアカウント名や共有リソースをリストし、その情報を使って、パスワードの推測攻撃を試みたり、ソーシャル エンジニアリング攻撃を実行したり、DoS 攻撃をしかけることができます。
対策
[ネットワーク アクセス : Everyone のアクセス許可を匿名ユーザーに適用する] を [無効] に設定します。
考えられる影響
なし。これは既定の構成です。
ネットワーク アクセス : リモートからアクセスできる名前付きパイプ
このポリシー設定は、匿名でアクセスできる属性および許可を付与する通信セッションまたはパイプを決定します。
[ネットワーク アクセス : リモートからアクセスできる名前付きパイプ] で設定できる値は、次のとおりです。
このポリシー設定を有効にするには、[ネットワーク アクセス : 名前付きパイプと共有への匿名のアクセスを制限する] 設定も有効にする必要があります。
脆弱性
COMNAP や LOCATOR など、名前付きパイプのアクセスを制限することは、ネットワークへの未承認のアクセスを防ぐのに役立ちます。既定の名前付きパイプとその目的を次の表に示します。
表 5.1 : 匿名でアクセスできる既定の名前付きパイプ
|
名前付きパイプ
|
目的
|
|---|
|
COMNAP
|
SNABase 名前付きパイプ。システム ネットワーク アーキテクチャ (SNA) は、もともと IBM のメインフレーム コンピュータ向けに開発された、ネットワーク プロトコルのコレクションです。
|
|
COMNODE
|
SNA Server 名前付きパイプ
|
|
SQL\QUERY
|
SQL Server の既定の名前付きパイプ
|
|
SPOOLSS
|
Print Spooler サービスの名前付きパイプ
|
|
EPMAPPER
|
エンド ポイント マッパーの名前付きパイプ
|
|
LOCATOR
|
Remote Procedure Call Locator サービスの名前付きパイプ
|
|
TrkWks
|
Distributed Link Tracking Client の名前付きパイプ
|
|
TrkSvr
|
Distributed Link Tracking Server の名前付きパイプ
|
対策
[ネットワーク アクセス : リモートからアクセスできる名前付きパイプ] 設定の値を NULL にします (この設定は有効にしますが、テキスト ボックスに名前付きパイプを入力しません)。
考えられる影響
この構成により、名前付きパイプと名前付きアプリケーションの NULL セッションのアクセスは無効になります。そのため、この機能または民称されていない名前付きパイプへのアクセスに依存するアプリケーションは機能しなくなります。たとえば、Microsoft Commercial Internet System 1.0 が適用されたインターネット メール サービスは、Inetinfo プロセスで実行されます。Inetinfo はシステム アカウントと関連して起動します。インターネット メール サービスが、Microsoft SQL Server データベースの照会を必要とする場合、SQL Server を実行するコンピュータの SQL パイプに NULL の資格情報で アクセスするシステム アカウントを使用します。
この問題を回避する方法については、マイクロソフト サポート技術情報の記事 http://support.microsoft.com/default.aspx?scid=207671 の「IIS からネットワーク ファイルへのアクセス方法」を参照してください。
ネットワーク アクセス : リモートからアクセスできるレジストリのパス
このポリシー設定は、アプリケーションまたはプロセスが WinReg キーを参照してアクセス権限を決定するとき、どのレジストリ パスをアクセス可能にするかを決定します。
[ネットワーク アクセス : リモートからアクセスできるレジストリのパス] で設定できる値は、次のとおりです。
脆弱性
レジストリは、コンピュータの構成情報を含むデータベースで、情報の多くは機密性の高いものです。攻撃者はこの情報を使って、未承認のアクティビティを促すことができます。そのような攻撃のリスクを軽減するため、適切な ACL をレジストリ中に割り当て、未承認ユーザーのアクセスを防ぐのに役立てます。
対策
[ネットワーク アクセス : リモートからアクセスできるレジストリのパス] の値を NULL に設定します (この設定は有効にしますが、テキスト ボックスにはどのパスも入力しません)。
考えられる影響
Microsoft Baseline Security Analyzer や Microsoft System Management Server などのリモート管理ツールは、これらのコンピュータを正しく監視および管理するためにレジストリへのリモート アクセスを要求します。既定のレジストリ パスをアクセス可能なパスのリストから削除すると、こうした管理ツールによる処理が失敗する可能性があります。
注 : リモート アクセスを許可する場合、リモート レジストリ サービスも有効にする必要があります。
ネットワーク アクセス : リモートからアクセスできるレジストリのパスおよびサブパス
このポリシー設定は、アプリケーションまたはプロセスが WinReg キーを参照してアクセス権限を決定するとき、どのレジストリ パスおよびサブパスをアクセス可能にするかを決定します。
[ネットワーク アクセス : リモートからアクセスできるレジストリのパスおよびサブパス] で設定できる値は、次のとおりです。
脆弱性
前述のように、レジストリには機密性の高いコンピュータの構成情報が含まれており、攻撃者がこれを使うと未承認のアクティビティを容易に実行できるようになります。レジストリに割り当てられる既定の ACL に多くの制限を加え、未承認ユーザーによるアクセスを防ぐことで、こうした攻撃に対するリスクが軽減されます。
対策
[ネットワーク アクセス : リモートからアクセスできるレジストリのパスおよびサブパス] の値を NULL に設定します (この設定は有効にしますが、テキスト ボックスにはどのパスも入力しません)。
考えられる影響
Microsoft Baseline Security Analyzer や Microsoft System Management Server などのリモート管理ツールは、これらのコンピュータを正しく監視および管理するためにレジストリへのリモート アクセスを要求します。既定のレジストリ パスをアクセス可能なパスのリストから削除すると、こうした管理ツールによる処理が失敗する可能性があります。
注 : リモート アクセスを許可する場合、リモート レジストリ サービスも有効にする必要があります。
ネットワーク アクセス : 名前付きパイプと共有への匿名のアクセスを制限する
このポリシー設定を有効にすると、[ネットワーク アクセス : リモートからアクセスできる名前付きパイプ] および [ネットワーク アクセス: 匿名でアクセスできる共有] で設定された共有とパイプへの匿名のアクセスのみを制限します。このポリシー設定は、HKLM\System\CurrentControlSet\Services\LanManServer\Parameters レジストリ キーの値に 1 を持つ RestrictNullSessAccess を追加することによって、使用しているコンピュータの共有への NULL セッション アクセスを制御します。このレジストリ キーの値は、NULL セッションの共有のオン/オフを切り替えることにより、サーバー サービスが未承認のクライアントによる名前の付いたリソースへのアクセスを制限するかどうかを制御します。
[ネットワーク アクセス : 名前付きパイプと共有への匿名のアクセスを制限する] で設定できる値は、次のとおりです。
脆弱性
NULL セッションには、自社環境のコンピュータ上にある、既定の共有を含むさまざまな共有が利用されるという弱点があります。
対策
[ネットワーク アクセス : 名前付きパイプと共有への匿名のアクセスを制限する] を [有効] に設定します。
考えられる影響
このポリシー設定を有効にすると、未承認のユーザーの NULL セッション アクセスを、NullSessionPipes と NullSessionShares エントリにリストされているものを除くすべてのサーバー パイプと共有に制限できます。
ネットワーク アクセス : 匿名でアクセスできる共有
このポリシー設定は、匿名ユーザーがアクセスできるネットワーク共有を決定します。
[ネットワーク アクセス : 匿名でアクセスできる共有] で設定できる値は、次のとおりです。
脆弱性
この設定を有効にするのは危険です。ネットワーク ユーザーはだれでも一覧に表示されたすべての共有にアクセスできるということは、機密データの露出または破損につながる可能性があります。
対策
[ネットワーク アクセス : 匿名でアクセスできる共有] の値を NULL に設定します。
考えられる影響
これは既定の構成なので、影響はほとんどありません。認証されたユーザーだけが、サーバーの共有リソースへアクセスできます。
ネットワーク アクセス : ローカル アカウントの共有とセキュリティ モデル
このポリシー設定は、ローカル アカウントを使用するネットワーク ログオンの認証方法を決定します。このポリシー設定を [クラシック] にすると、ローカル アカウントの資格情報を使用するネットワーク ログオンは、これらの資格情報を使用して認証します。この設定を [Guest のみ] に設定すると、ローカル アカウントを使うネットワーク ログオンは、自動的に Guest アカウントにマップされます。クラシック モデルは、リソースへのアクセスを厳密に制御し、同一のリソースに対してユーザーごとに個別のアクセスを付与できます。反対に、Guest のみのモデルでは、すべてのユーザーは Guest ユーザー アカウントとして認証され、特定のリソースに対して同じレベルのアクセスを付与されます。アクセス レベルは、読み取り専用または変更のどちらかです。
スタンドアロンの Windows XP Professional の既定の構成は、[Guest のみ] です。ドメインに参加するWindows XP コンピュータ、および Windows Server 2003 コンピュータの既定は、[クラシック] です。
注 : このポリシー設定は、ドメイン アカウントを使うネットワーク ログオンには影響を与えません。また、Telnet やターミナル サービスなどのサービスを使ってリモートに実行される対話的なログオンにも影響はありません。
コンピュータがドメインに参加していない場合、このポリシー設定は、Windows エクスプローラの [共有] タブおよび [セキュリティ] タブを調整して、使用されている共有およびセキュリティ モデルに対応します。
この設定による、Windows 2000 コンピュータへの影響はありません。
[ネットワーク アクセス : ローカル アカウントの共有とセキュリティ モデル] で設定できる値は、次のとおりです。
脆弱性
Guest のみのモデルの場合、お使いのコンピュータをネットワーク経由で認証できるすべてのユーザーは、ゲストの特権で認証します。この場合、おそらくこれらのユーザーにはそのコンピュータの共有リソースへの書き込みアクセス権限は与えられません。この制限によりセキュリティが向上するものの、認証されたユーザーがこれらのコンピュータの共有リソースにアクセスするのがより困難になります。これらのリソースの ACL に Guest アカウントのアクセス制御エントリ (ACE) が含まれている必要があるからです。クラシック モデルでは、ローカル アカウントはパスワードで保護されている必要があります。パスワードで保護されていない場合、Guest アクセスが有効のときは、だれでもそれらのユーザー アカウントを使用して、共有システム リソースにアクセスできます。
対策
ネットワーク サーバーの場合、[ネットワーク アクセス : ローカル アカウントの共有とセキュリティ モデル] 設定を [クラシック - ローカル ユーザーがローカル ユーザーとして認証する] に構成します。エンドユーザーのコンピュータでは、このポリシー設定を [Guest のみ – ローカル ユーザーが Guest として認証する] に構成します。
考えられる影響
なし。これは既定の構成です。
ネットワーク セキュリティ : 次のパスワードの変更で LAN Manager のハッシュの値を保存しない
このポリシー設定は、次のパスワード変更時に、LAN Manager が新しいパスワードのハッシュ値を格納できるかどうかを決定します。
[ネットワーク セキュリティ : 次のパスワードの変更で LAN Manager のハッシュの値を保存しない] で設定できる値は、次のとおりです。
脆弱性
SAM ファイルは、ユーザー名およびパスワードのハッシュ値へのアクセスを試みる攻撃者のターゲットになることがあります。そのような攻撃は、特別なツールを使ってパスワードを解読し、ユーザーを偽装してネットワーク上のリソースにアクセスします。このポリシー設定を有効にした場合、このような攻撃を回避することはできませんが、攻撃の成功率は低くなります。
対策
[ネットワーク セキュリティ : 次のパスワードの変更で LAN Manager のハッシュの値を保存しない] を [有効] に設定します。すべてのユーザーは、次回のドメインへのログオン時も、新しいパスワードを設定するよう要求されます。これにより、LAN Manager のハッシュは削除されます。
考えられる影響
Windows 95、Windows 98 および Windows ME などの以前のオペレーティング システム、およびサードパーティ アプリケーションの一部は処理に失敗します。
ネットワーク セキュリティ : ログオン時間を経過した場合はユーザーを強制的にログオフさせる
このポリシー設定は、ローカル コンピュータに接続しているユーザーのログオン時間がユーザー アカウントの制限時間に達したとき、強制的にそのユーザーを切断するかどうかを決定します。これは、SMB コンポーネントに影響します。このポリシー設定を有効にすると、SMB サーバーを使用するクライアント セッションは、そのクライアントのログオン時間の有効期間が過ぎると切断されます。このポリシー設定を無効にすると、確立されたクライアント セッションは、そのクライアントのログオン時間の有効期間が切れても維持されます。
[ネットワーク セキュリティ : ログオン時間を経過した場合はユーザーを強制的にログオフさせる] で設定できる値は、次のとおりです。
脆弱性
このポリシー設定を無効にすると、ユーザーは割り当てられたログオン時間が経過しても、コンピュータに接続することができます。
対策
[ネットワーク セキュリティ : ログオン時間を経過した場合はユーザーを強制的にログオフさせる] を [有効] に設定します。このポリシー設定は、管理者のアカウントには適用されません。
考えられる影響
ユーザーのログオン時間が経過すると、SMB セッションが終了します。ユーザーは、次にスケジュールされたアクセス時間が来るまで、コンピュータにログオンできなくなります。
ネットワーク セキュリティ : LAN Manager 認証レベル
LM (LAN Manager) は、初期の Microsoft クライアント/サーバー ソフトウェア ファミリで、これを使うと、単一のネットワーク上に個人のコンピュータをリンクすることができます。ネットワーク機能には、透過的なファイルと印刷の共有、ユーザーのセキュリティ機能、およびネットワーク管理ツールなどがあります。Active Directory ドメインでは、Kerberos プロトコルが既定の認証プロトコルです。ただし、Kerberos プロトコルが何らかの理由でネゴシエートされない場合、Active Directory は LM、NTLM、または NTLMv2 を使用します。
LAN Manager 認証には、LM、NTLM および NTLM Version 2 (NTLMv2) の変数が含まれ、次のような操作を行うすべての Windows クライアントの認証に使用されるプロトコルです。
[ネットワーク セキュリティ : LAN Manager 認証レベル] で設定できる値は、次のとおりです。
-
LM と NTLM 応答を送信する
-
LM と NTLM 応答を送信する - ネゴシエーションの場合、NTLMv2 セッション セキュリティを使う
-
NTLM 応答のみ送信する
-
NTLMv2 応答のみ送信する
-
NTLMｖ2 応答のみを送信 (LM を拒否する)
-
NTLMｖ2 応答のみを送信 (LM と NTLM を拒否する)
-
未定義
[ネットワーク セキュリティ : LAN Manager 認証レベル] 設定では、ネットワーク ログオンに、どのチャレンジ/レスポンス認証プロトコルを使うかを決定します。この選択は、次のようなクライアントが使う認証プロトコル レベル、コンピュータがネゴシエートするセッションのセキュリティ レベル、およびサーバーが承認する認証レベルに影響します。
-
LM と NTLM 応答を送信する : クライアントは LM および NTLM の認証を使用しますが、NTLMv2 セッション セキュリティは使用しません。ドメイン コントローラは、LM、NTLM および NTLMv2 の認証を承認します。
-
LM と NTLM 応答を送信する - ネゴシエーションの場合、NTLMv2 セッション セキュリティを使う : クライアントは LM と NTLM 認証を使います。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使います。ドメイン コントローラは、LM、NTLM および NTLMv2 の認証を承認します。
-
NTLM 応答のみ送信する : クライアントは NTLM 認証のみを使用します。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使います。ドメイン コントローラは、LM、NTLM および NTLMv2 の認証を承認します。
-
NTLMv2 応答のみ送信する : クライアントは NTLMv2 認証のみを使用します。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使います。ドメイン コントローラは、LM、NTLM および NTLMv2 の認証を承認します。
-
NTLMv2 応答のみ送信 (LM を拒否する) : クライアントは NTLMv2 認証のみを使用します。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使います。ドメイン コントローラは、LM を拒否します (NTLM および NTLMv2 の認証のみを承認します)。
-
NTLMv2 応答のみ送信 (LM と NTLM を拒否する) : クライアントは NTLMv2 認証のみを使用します。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使います。ドメイン コントローラは、LM と NTLM を拒否します (NTLMv2 の認証のみを承認します)。
これらの設定は、以下のとおり、他のマイクロソフト ドキュメントで説明されるレベルに対応しています。
-
レベル 0 – LM と NTLM 応答を送信する。NTLMv2 セッション セキュリティを決して使用しない : クライアントは LM および NTLM の認証を使用しますが、NTLMv2 セッション セキュリティは使用しません。ドメイン コントローラは、LM、NTLM および NTLMv2 の認証を承認します。
-
レベル 1 – ネゴシエーションの場合、NTLMv2 セッション セキュリティを使用する : クライアントは LM と NTLM 認証を使います。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使います。ドメイン コントローラは、LM、NTLM および NTLMv2 の認証を承認します。
-
レベル 2 – NTLM 応答のみ送信する : クライアントは NTLM 認証のみを使用します。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使用します。ドメイン コントローラは、LM、NTLM および NTLMv2 の認証を承認します。
-
レベル 3 – NTLMv2 応答のみ送信する : クライアントは NTLMv2 認証を使用します。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使用します。ドメイン コントローラは、LM、NTLM および NTLMv2 の認証を承認します。
-
レベル 4 – ドメイン コントローラは、LM 応答を拒否する : クライアントは NTLMv2 認証を使用します。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使用します。ドメイン コントローラは、LM 認証を拒否します。つまり NTLM および NTLMv2 の認証を承認します。
-
レベル 5 – ドメイン コントローラは、LM と NTLM 応答を拒否する (NTLMv2 のみ承認) : クライアントは NTLMv2 認証を使用します。サーバーがサポートする場合、NTLMv2 セッション セキュリティを使用します。ドメイン コントローラは、LM と NTLM の認証を拒否します (NTLMv2 の認証のみを承認します)。
脆弱性
Windows 2000、Windows Server 2003、および Windows XP クライアントは、既定で LM と NTLM 認証の応答を送信するよう構成されています (Windows 9 x クライアントは LM のみを送信します)。サーバーの既定の設定では、すべてのクライアントはサーバーを使って認証し、リソースを使用することができます。しかし、これは、認証応答の最も弱い形態である LM 応答が、ネットワーク上で送信されることを意味します。攻撃者がこのトラフィックを検知して、ユーザーのパスワードをより簡単に再生成する可能性があります。
Windows 9x オペレーティング システムと Windows NT オペレーティング システムは、認証に Kerberos 5 プロトコルを使用できません。このため、Windows Server 2003 ドメインでは、これらのコンピュータはネットワークの認証に、既定で LM と NTLM の両方のプロトコルを使用します。NTLMv2 を使用して、Windows 9x および Windows NT により安全な認証プロトコルを強制することができます。ログオン プロセスでは、NTLMv2 はセキュリティ チャネルを使って、認証プロセスを保護します。レガシ クライアントやレガシ サーバーに NTLMv2 を使う場合でも、ドメインのメンバである Windows ベースのクライアントやサーバーは、Kerberos 認証プロトコルを使用して Windows 2003 ドメイン コントローラを認証します。
NTLMv2 を有効にする方法の詳細については、マイクロソフト サポート技術情報の記事 http://support.microsoft.com/default.aspx?scid=239869 の「NTLM 2 認証を有効にする方法」を参照してください。Microsoft Windows NT 4.0 で NTLMv2 をサポートするには、Service Pack 4 (SP4) が必要です。また、Windows 9 x プラットフォームで NTLMv2 をサポートするには、ディレクトリ サービス クライアントがインストールされている必要があります。
対策
[ネットワーク セキュリティ : LAN Manager 認証レベル] を [NTLMv2 応答のみ送信する] に設定します。すべてのクライアントが NTLMv2 をサポートする場合、Microsoft および多くの独立した組織では、この認証レベルを強く推奨しています。
考えられる影響
NTLMv2 認証をサポートしないクライアントは、ドメインで認証することができません。また、LM や NTLM を使って、ドメイン リソースにアクセスすることもできません。
注 : Windows 2000、Windows XP、Windows Server 2003、Windows NT 4.0 コンピュータが含まれたネットワークでこの設定を機能させるためのホットフィックスの詳細については、マイクロソフト サポート技術情報の記事 http://support.microsoft.com/default.aspx?scid=305379 の「Windows NT 4.0 のドメインで NTLM 2 のレベル 2 より上を使用する Windows 2000 の認証問題」を参照してください。
ネットワーク セキュリティ : 必須の署名をしている LDAP クライアント
このポリシー設定では、LDAP BIND リクエストを発行するクライアントに代わって、要求されるデータ署名のレベルを次のとおり決定します。
-
なし : LDAP BIND 要求は、呼び出し元が特定するオプションで発行されます。
-
ネゴシエーション署名 : TLS/SSL (Transport Layer Security/Secure Sockets Layer) が起動していない場合、LDAP BIND 要求は、呼び出し元特定のオプションと LDAP データ署名オプション セットにより開始されます。TLS/SSL が起動している場合、LDAP BIND 要求は、呼び出し元特定のオプションで開始されます。
-
署名属性の要求 : これは、[ネゴシエーション署名] と同じです。ただし、LDAP サーバーの中間 saslBindInProgress 応答が、LDAP トラフィック署名の要求を示さない場合、呼び出し元は LDAP BIND のコマンド要求が失敗したことを通知されます。
注 : このポリシー設定は、ldap_simple_bind または ldap_simple_bind_s には影響を与えません。Windows XP Professional に含まれる Microsoft LDAP クライアントが、ドメイン コントローラとの通信に、ldap_simple_bind または ldap_simple_bind_s を使用することはありません。
[ネットワーク セキュリティ : 必須の署名をしている LDAP クライアント] で設定できる値は、次のとおりです。
-
なし
-
ネゴシエーション署名
-
署名属性の要求
-
未定義
脆弱性
署名されていないネットワークのトラフィックは、攻撃者がサーバーとクライアント間のパケットを取り込み、サーバーへの転送前に改ざんを加える仲介者攻撃に対して脆弱です。LDAP サーバーの場合、この脆弱性により、攻撃者はサーバーに LDAP クエリからの虚偽のデータまたは改ざんされたデータに基づいて意思決定させることが可能です。ネットワークにおけるこのリスクを軽減するには、強固で物理的なセキュリティ対策を実行し、ネットワーク インフラストラクチャを保護します。また、IPSec 認証ヘッダーによって、すべてのネットワーク パケットにデジタル署名を要求することで、あらゆる種類の仲介者攻撃を困難にすることができます。
対策
[ネットワーク セキュリティ : LDAP サーバー署名必須] を [署名属性の要求] に設定します。
考えられる影響
LDAP 属性署名を要求するようにサーバーを構成する場合、クライアントも構成する必要があります。クライアントを構成しない場合、クライアントはサーバーと通信できず、ユーザー認証、グループ ポリシー、ログオン スクリプトなど多くの機能が処理に失敗します。
ネットワーク セキュリティ : セキュア RPC を含む NTLM SSP ベースのクライアントの最小のセッション セキュリティ
このポリシー設定により、クライアント コンピュータはメッセージの機密性 (暗号化)、メッセージの保全性、128 ビット暗号化、または NTLMv2 セッション セキュリティのネゴシエーションを要求できます。これらの値は、LAN Manager 認証レベルのポリシー設定により異なります。
[ネットワーク セキュリティ : セキュア RPC を含む NTLM SSP ベースのクライアントの最小のセッション セキュリティ] で設定できる値は、次のとおりです。
-
メッセージの機密性が必要 : 暗号化がネゴシエートされない場合、接続は失敗します。暗号化は、解読されるまで読み取り不可能な形式にデータを変換します。
-
メッセージの整合性が必要 : メッセージの整合性がネゴシエートされない場合、接続は失敗します。メッセージの整合性は、メッセージの署名から評価できます。メッセージの署名は、暗号の署名を添付することで、メッセージが改ざんされていないことを証明するものです。暗号の署名は、送信者を識別して、メッセージの内容を数値で示します。
-
128 ビット暗号化が必要 : 強固な暗号化 (128 ビット) がネゴシエートされない場合、接続は失敗します。
-
NTLMv2 セッション セキュリティが必要 : NTLMv2 プロトコルがネゴシエートされない場合、接続は失敗します。
-
未定義
脆弱性
このポリシー設定のオプションをすべて有効にすると、NTLM セキュリティ サポート プロバイダ (NTLM SSP) を使用するネットワーク トラフィックが、そのネットワークへのアクセスを取得した攻撃者の攻撃にさらされたり、不正操作されたりするのを防ぎます。つまり、このオプションは、仲介者攻撃を防ぐのに役に立ちます。
対策
[ネットワーク セキュリティ : セキュア RPC を含むクライアント ベースの NTLM SSP 最小のセッション セキュリティ] ポリシー設定で、利用可能な4 つのオプションをすべて有効にします。
考えられる影響
これらの設定を強制するクライアント コンピュータは、この設定をサポートしない古いサーバーと通信できなくなります。
ネットワーク セキュリティ : セキュア RPC を含む NTLM SSP ベースのサーバーの最小のセッション セキュリティ
このポリシー設定により、サーバーはメッセージの機密性 (暗号化)、メッセージの保全性、128 ビット暗号化、または NTLMv2 セッション セキュリティのネゴシエーションを要求できます。これらの値は、LAN Manager 認証レベルのセキュリティ設定により異なります。
[ネットワーク セキュリティ : セキュア RPC を含む NTLM SSP ベースのサーバーの最小のセッション セキュリティ] で設定できる値は、次のとおりです。
-
メッセージの機密性が必要 : 暗号化がネゴシエートされない場合、接続は失敗します。暗号化は、解読されるまで読み取り不可能な形式にデータを変換します。
-
メッセージの整合性が必要 : メッセージの整合性がネゴシエートされない場合、接続は失敗します。メッセージの整合性は、メッセージの署名から評価できます。メッセージの署名は、暗号の署名を添付することで、メッセージが改ざんされていないことを証明するものです。暗号の署名は、送信者を識別して、メッセージの内容を数値で示します。
-
128 ビット暗号化が必要 : 強固な暗号化 (128 ビット) がネゴシエートされない場合、接続は失敗します。
-
NTLMv2 セッション セキュリティが必要 : NTLMv2 プロトコルがネゴシエートされない場合、接続は失敗します。
-
未定義
脆弱性
このポリシー設定のオプションをすべて有効にすると、NTLM セキュリティ サポート プロバイダ (NTLM SSP) を使用するネットワーク トラフィックが、そのネットワークへのアクセスを取得した攻撃者の攻撃にさらされたり、不正操作されたりするのを防ぎます。つまり、このオプションは、仲介者攻撃を防ぐのに役に立ちます。
対策
[ネットワーク セキュリティ : セキュア RPC を含むサーバー ベースの NTLM SSP 最小のセッション セキュリティ] ポリシーで、利用可能なすべてのオプションを有効にします。
考えられる影響
これらのセキュリティ設定をサポートしない古いクライアントは、コンピュータと通信できなくなります。
回復コンソール : 自動管理ログオンを許可する
このポリシー設定は、コンピュータへのアクセスが許可される前に、Administrator アカウントのパスワードを取得しておく必要があるかどうかを決定します。この設定を有効にすると、Administrator アカウントは回復コンソールで自動的にコンピュータにログオンします。パスワードは必要ありません。
[回復コンソール : 自動管理ログオンを許可する] で設定できる値は、次のとおりです。
脆弱性
起動しないコンピュータをトラブルシューティングして修復する必要があるとき、回復コンソールが役に立つ場合があります。ただし、コンソールへの自動ログオンを許可するのは危険です。だれでもサーバーにアクセスし、電源を切断してシャットダウンおよび再起動し、[再起動] メニューから [回復コンソール] を選択し、サーバーを完全にコントロールすることができます。
対策
[回復コンソール : 自動管理ログオンを許可する] を [無効] に設定します。
考えられる影響
ユーザーは、ユーザー名とパスワードを入力して、回復コンソールにアクセスする必要があります。
回復コンソール : すべてのドライブとフォルダに、フロッピーのコピーとアクセスを許可する
このポリシー設定を有効にすると、回復コンソールの SET コマンドを使用できます。このコマンドを使って、次の回復コンソールの環境変数を設定できます。
-
AllowWildCards : DEL コマンドなど一部のコマンドで、ワイルドカード文字を使用できるようにします。
-
AllowAllPaths : コンピュータ上のすべてのファイルとフォルダにアクセスできるようにします。
-
AllowRemovableMedia : ファイルを、フロッピー ディスクなどのリムーバブル メディアにコピーできるようにします。
-
NoCopyPrompt : 既存のファイルが上書きされる前に通常表示されるプロンプトを表示しません。
[回復コンソール : すべてのドライブとフォルダに、フロッピーのコピーとアクセスを許可する] で設定できる値は、次のとおりです。
脆弱性
システムの回復コンソールへの再起動を実行できる攻撃者は、監査やアクセス記録をまったく残さないで機密データを盗むことが可能です。
対策
[回復コンソール : すべてのドライブとフォルダに、フロッピーのコピーとアクセスを許可する] を [無効] に設定します。
考えられる影響
回復コンソールからサーバーを起動して、ビルドイン Administrator アカウントにログオンしているユーザーは、ファイルやフォルダをフロッピー ディスクにコピーできなくなります。
シャットダウン : システムをシャットダウンするのにログオンを必要としない
このポリシー設定は、Windows にログオンせずにコンピュータをシャットダウンできるかどうかを決定します。このポリシー設定を有効にすると、Windows のログオン画面で [シャットダウン] コマンドを使用できます。このポリシー設定を無効にすると、Windows のログオン画面から [シャットダウン] オプションが削除されます。この構成では、ユーザーがコンピュータをシャットダウンするには、ユーザーがコンピュータに正しくログオンすることができ、[システムのシャットダウン] ユーザー権利を持っている必要があります。
[シャットダウン : システムをシャットダウンするのにログオンを必要としない] で設定できる値は、次のとおりです。
脆弱性
コンソールにローカルにアクセスできるユーザーは、コンピュータをシャットダウンできます。
攻撃者は、ローカル コンソールに入り込み、サーバーを再起動して、DoS 状況を一時的に作り出すことができます。また、サーバーをシャットダウンして、すべてのアプリケーションとサービスを使用不可能にすることもできます。
対策
[システムをシャットダウンするのにログオンを必要としない] を [無効] に設定します。
考えられる影響
担当者はサーバーにログオンして、これをシャットダウンするか再起動する必要があります。
シャットダウン : 仮想メモリのページ ファイルをクリアする
このポリシー設定は、コンピュータをシャットダウンする際に、仮想メモリのページ ファイルをクリアするかどうかを決定します。仮想メモリ サポートは、システムのページ ファイルを使って、メモリのページが使用されていないときに、これをディスクにスワップします。実行中のコンピュータでは、オペレーティング システムがこのページ ファイルを排他的に開くため、十分に保護されています。ただし、他のオペレーティング システムによる起動を許可するように構成されたコンピュータでは、このコンピュータをシャットダウンする際に、システムのページ ファイルを必ずクリアする必要があります。これにより、シャットダウン後に未承認ユーザーがページ ファイルに直接アクセスできた場合でも、ページ ファイルに残る可能性があるプロセス メモリの機密性の高い情報を使用できなくなります。
このポリシー設定を有効にすると、システム ページ ファイルはクリーンなシャットダウンによりクリアされます。また、ポータブル コンピュータで休止状態が無効のとき、休止ファイル (Hiberfil.sys) がクリアされます。
[シャットダウン : 仮想メモリのページ ファイルをクリアする] で設定できる値は、次のとおりです。
脆弱性
実際のメモリに保存される機密性の高い情報は、Windows Server 2003 でマルチタスク機能を処理しやすいように、定期的にページ ファイルへ書き出されることがあります。シャットダウンされたサーバーに物理的にアクセスできる攻撃者は、ページング ファイルの内容を参照することができます。攻撃者はシステムのボリュームを別のコンピュータに移して、ページング ファイルの内容を分析することができます。これは時間のかかるプロセスですが、ランダム アクセス メモリ (RAM) からページング ファイルへキャッシュされるデータが漏洩する可能性があります。
注 : サーバーに物理的にアクセスできる攻撃者は、サーバーの電源を切断するだけで、この対策を回避することができます。
対策
[システムのシャットダウン時に仮想メモリのページ ファイルをクリアする] を [有効] に設定します。この構成では、コンピュータのシャットダウン時に Windows Server 2003 はページ ファイルをクリアします。このプロセスを完了するのに必要な時間は、ページ ファイルのサイズによって異なります。コンピュータが完全にシャットダウンするまでに、数分かかる場合があります。
考えられる影響
大きなページング ファイルを持つサーバーの場合は特に、サーバーのシャットダウンおよび再起動に時間がかかります。2 GB の RAM に 2 GB のページング ファイルを搭載したサーバーの場合、このポリシー設定によりシャットダウンのプロセスが、20 ～ 30 分以上余計にかかることがあります。組織によっては、このダウンタイムが内部サービス レベルの契約に違反することがあります。このため、自社環境にこの対策を実装する際には注意してください。
システム暗号化 : コンピュータに保存されているユーザー キーに強力なキー保護を強制する
このポリシー設定は、ユーザーがパスワードを使わないで、S/MIME キーなどの秘密キーを使えるかどうかを決定します。
[システム暗号化 : コンピュータに保存されているユーザー キーに強力なキー保護を強制する] で設定できる値は、次のとおりです。
-
新しいキーが保存されて使用されるときには、ユーザー入力は必要ありません
-
最初にキーが使用されるときには、ユーザーに要求する
-
ユーザーがキーを使うときにはパスワードの入力が必要
-
未定義
脆弱性
このポリシー設定を使用すると、キーを使用するたびにドメイン パスワードとは異なるパスワードをユーザーに要求することができます。この構成では、攻撃者がユーザーのコンピュータを制御してログオン パスワードを割り出したとしても、ローカルに保存されたユーザー キーにアクセスすることは難しくなります。
対策
[システム暗号化 : コンピュータに保存されているユーザー キーに強力なキー保護を強制する] を [ユーザーがキーを使うときにはパスワードの入力が必要] に設定します。
考えられる影響
ユーザーは、コンピュータに保存されたキーにアクセスするたびに、パスワードの入力を要求されます。たとえば、S-MIME 証明書を使って電子メールにデジタル的に署名する場合、ユーザーは署名入りの電子メールを送るたびにこの証明書のパスワードの入力を要求されます。組織によっては、この構成に関連する負荷が大きすぎる場合があります。最低限として、[最初にキーが使用されるときには、ユーザーに要求する] に設定してください。
システム暗号化 : 暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使う
このポリシー設定は、TLS/SSL セキュリティ プロバイダが TLS_RSA_WITH_3DES_EDE_CBC_SHA として知られる強力な暗号スイートだけをサポートするかどうか、つまり、プロバイダがクライアントとサーバー (該当する場合) として TLS プロトコルだけをサポートするかどうかを決定します。TLS のトラフィック暗号化には、DES (Triple Data Encryption Standard) 暗号化アルゴリズムのみが使用されます。TLS キーの交換と認証には、RSA (Rivest-Shamir-Adleman) 公開キー アルゴリズムのみが、また、TLS のハッシュ要求には、Secure Hash Algorithm Version 1 (SHA-1) ハッシュ アルゴリズムのみが使用されます。
この設定を有効にすると、暗号化ファイル システム サービス (EFS) では、ファイル データの暗号化に Triple DES 暗号化アルゴリズムのみをサポートします。既定では、Windows Server 2003 に実装された EFS は、256 ビット キーを使用した AES (Advanced Encryption Standard) を使用します。Windows XP では、DESX を使用します。
[システム暗号化 : 暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使う] で設定できる値は、次のとおりです。
脆弱性
このポリシー設定を有効にすると、コンピュータでは、デジタルによる暗号化、ハッシュおよび署名に、最も強力なアルゴリズムが必ず使用されます。これらのアルゴリズムの使用は、デジタル暗号化またはデジタル署名されたデータが、承認されていないユーザーによって侵害されるリスクを、最小限に抑えます。
対策
[システム暗号化 : 暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使う] を [有効] に設定します。
考えられる影響
このポリシー設定が有効なクライアント コンピュータは、これらのアルゴリズムをサポートしないサーバーと、デジタル暗号化またはデジタル署名されたプロトコルで通信することができません。また、これらのアルゴリズムをサポートしていないネットワーク クライアントは、これらのアルゴリズムを通信ネットワークに必要とするサーバーを使用できません。たとえば、多くの Apache ベースの Web サーバーは、TLS をサポートするように設定されていません。この設定を有効にする場合、TLS を使用できるように Internet Explorer も構成する必要があります。このポリシー設定は、RDP (Remote Desktop Protocol) に使用される暗号化レベルに影響します。リモート デスクトップ接続ツールは、RDP プロトコルを使って、ターミナル サービスを実行するサーバーおよびリモート制御用に構成されたクライアント コンピュータと通信します。両コンピュータが同じ暗号化アルゴリズムを使用するように構成されていない場合は、RDP 接続に失敗します。
Internet Explorer で TLS を使用するには
-
Internet Explorer の [ツール] メニューで、[インターネット オプション] ダイアログ ボックスを開きます。
-
[詳細設定] タブをクリックします。
-
[TLS 1.0 を使用する] チェック ボックスをオンにします。
このポリシー設定は、グループ ポリシーから、または Internet Explorer 管理者キットを使って構成することもできます。
システム オブジェクト : Administrators グループのメンバによって作成されたオブジェクトの既定の所有者
このポリシー設定は、Administrators グループまたは Object Creator を、任意の作成されたシステム オブジェクトの既定の所有者にするかどうかを決定します。
[システム オブジェクト : Administrators グループのメンバによって作成されたオブジェクトの既定の所有者] で設定できる値は、次のとおりです。
-
Administrators グループ
-
Object creator
-
未定義
脆弱性
このポリシー設定を [Administrators グループ] に構成すると、新しいシステム オブジェクトの作成に個人が責任を負うことができなくなります。
対策
[システム オブジェクト : Administrators グループのメンバによって作成されたオブジェクトの既定の所有者] 設定を [Object creator] に設定します。
考えられる影響
システム オブジェクトが作成されると、所有権がより一般的な Administrators グループではなく、そのオブジェクトが作成されたアカウントで示されるようになります。このポリシー設定では、ユーザー アカウントが削除された場合、オブジェクトは孤立します。たとえば、情報テクノロジ グループのメンバが離れると、そのメンバがドメインのどこかで作成したオブジェクトには所有者がいなくなります。この状況では、孤立したオブジェクトの権限を更新するには、管理者は手動で所有権を取得しなければならないので、管理的な負担となります。この負担を軽減するには、 Domain Admins などのドメイン グループの新しいオブジェクトには常にフル コントロールを割り当てます。
システム オブジェクト : Windows システムではないサブシステムのための大文字と小文字の区別をしないことが必須
このポリシー設定は、すべてのサブシステムで大文字と小文字を区別しないかどうかを決定します。Microsoft Win32® サブシステムでは、大文字と小文字を区別しません。ただし、カーネルは POSIX (Portable Operating System Interface for UNIX) などの他のサブシステムに対して大文字と小文字を区別します。この設定を有効にすると、すべてのディレクトリ オブジェクト、シンボリック リンク、IO、およびファイル オブジェクトについて、大文字と小文字を区別しません。この設定を無効にしても、Win32 サブシステムは、大文字と小文字を区別しません。
[システム オブジェクト : Windows システムではないサブシステムのための大文字と小文字の区別をしないことが必須] で設定できる値は、次のとおりです。
脆弱性
Windows は大文字と小文字を区別しませんが、POSIX サブシステムは区別をサポートするため、このポリシー設定を有効にしない場合、POSIX サブシステムのユーザーが大文字と小文字の組み合わせが異なるが別のファイルと同じ名前のファイルを作成することが可能になります。この場合、ユーザーが通常の Win32 ツールからそのようなファイルにアクセスしようとすると、それらのファイルのうち 1 つしか使用できないため、混乱を招くことがあります。
対策
[システム オブジェクト : Windows システムではないサブシステムのための大文字と小文字の区別をしないことが必須] [有効] に設定します。
考えられる影響
すべてのサブシステムでは、大文字と小文字を区別しないことを強制監視します。この構成は、大文字と小文字が区別される UNIX ベースのいずれかのオペレーティング システムに慣れているユーザーには混乱を招く可能性があります。
システム オブジェクト : 内部のシステム オブジェクトの既定のアクセス許可を強化する (例 : シンボリック リンク)
このポリシー設定では、オブジェクトの既定の DACL の強度を決定します。Windows では、プロセス間のオブジェクトの検索や共有が可能になるよう、共有のコンピュータ リソース (MS-DOS デバイス名、ミューテックス、セマフォなど) のグローバル リストが保持されます。
[システム オブジェクト : 内部のシステム オブジェクトの既定のアクセス許可を強化する (例 : シンボリック リンク)] で設定できる値は、次のとおりです。
脆弱性
この設定では、オブジェクトの既定の DACL の強度を決定します。Windows Server 2003 では、プロセス間でのオブジェクトの検索や共有が可能になるよう、共有のコンピュータ リソースのグローバル一覧が保持されます。オブジェクトの各タイプは、オブジェクトにアクセスできるユーザーとそのユーザーに必要な権限を特定する、既定の DACL で作成されます。この設定を有効にすると、既定の DACL が強化されます。これは、管理者以外のユーザーは共有オブジェクトの読み取りは許可されますが、他のユーザーが作成した共有オブジェクトの変更は禁止されるからです。
対策
[システム オブジェクト : グローバル システム オブジェクトの既定のアクセス許可を強化する (例 : シンボリック リンク)] を [有効] に設定します。
考えられる影響
なし。これは既定の構成です。
システム設定 : オプション サブシステム
このポリシー設定は、アプリケーションのサポートに使用されるサブシステムを決定します。このセキュリティ設定では、使用環境の必要に応じて、任意の数のサブシステムを指定することができます。
[システム設定 : オプション サブシステム] で設定できる値は、次のとおりです。
脆弱性
POSIX サブシステムは、オペレーティング システム サービスを定義する、米国電気電子学会 (IEEE) の標準です。サーバーが、POSIX サブシステムを使用するアプリケーションをサポートする場合、POSIX サブシステムが必要です。
POSIX サブシステムでは、ログイン処理において継続する可能性があるプロセスに関連したセキュリティ リスクが生じます。ユーザーがプロセスを開始し、その後ログアウトした場合、次にそのシステムにログオンするユーザーが、前のユーザーのプロセスにアクセスできる可能性があります。2 番目のユーザーがそのプロセスで実行することは、すべて最初のユーザーの特権で行われるため、これはリスクの大きい問題です。
対策
[システム設定 : オプション サブシステム] を、NULL に設定します。既定の値は、[POSIX] です。
考えられる影響
POSIX サブシステムに依存するアプリケーションを実行できなくなります。たとえば、Microsoft Services for Unix (SFU) では、必要な POSIX サブシステムの最新バージョンがインストールされます。そのため、SFU を使うすべてのサーバーには、グループ ポリシーでこの設定を再構成する必要があります。
システム設定 : ソフトウェア制限のポリシーのために Windows 実行可能ファイルに対して証明書の規則を使用する
このポリシー設定は、ソフトウェア制限ポリシーが有効で、ユーザーまたはプロセスが .exe ファイル名拡張子を持つソフトウェアを実行しようとした際、デジタル証明書を処理するかどうかを決定します。このセキュリティ設定では、証明書のルール (ソフトウェアの制限ポリシー ルールの一種) を有効または無効にします。ソフトウェア制限ポリシーを使用すると、証明書の規則を作成し、Authenticode® 署名があるソフトウェアの実行を、そのソフトウェアに関連付けられているデジタル証明書に基づいて許可または拒否することができます。ソフトウェア制限ポリシーで証明書の規則を適用するには、このセキュリティ設定を有効にする必要があります。
[システム設定 : ソフトウェア制限のポリシーのために Windows 実行可能ファイルに対して証明書の規則を使用する] で設定できる値は、次のとおりです。
脆弱性
ソフトウェアの制限ポリシーは、ウイルスやトロイの木馬などの未承認のコードの実行を防ぐので、ユーザーとコンピュータを保護するのに役立ちます。
対策
[システム設定 : ソフトウェア制限のポリシーのために Windows 実行可能ファイルに対して証明書の規則を使用する] を [有効] に設定します。
考えられる影響
証明書ルールを有効にすると、ソフトウェア制限ポリシーは、証明書失効リスト (CRL) をチェックしてソフトウェアの証明書と署名が有効であることを確認します。証明書付きのプログラムを起動した際、このチェック プロセスによってパフォーマンスが低下する場合があります。この機能を無効にするには、目的の GPO のソフトウェア制限ポリシーを編集します。[信頼された発行者のプロパティ] ダイアログ ボックスで、[発行者] および [タイムスタンプ] チェック ボックスをオフにしてください。
関連情報
次のリンクは、Windows Server 2003 と Windows XP でのセキュリティ オプションの追加情報を提供しています。
目次