セキュリティ構成ガイダンスのサポート

Microsoft Corporation

Microsoft では、独自のオペレーティング システムをセキュリティで保護する方法に関するガイダンスを提供しています。 次の 3 つのレベルのセキュリティ設定を開発しました。

• Enterpriseクライアント (EC)

• Stand-Alone (SA)

• 特殊なセキュリティ – 制限付き機能 (SSLF)

多くのお客様のシナリオで使用するために、このガイダンスを徹底的にテストしました。 このガイダンスは、ユーザーベースのコンピューターをセキュリティで保護する必要があるWindowsに適しています。

これらのガイドでは、アプリケーションの互換性に関する調査で実施した広範なテストのために、ガイドを完全にサポートしています。 ガイドをダウンロードするには、次の Microsoft Web サイトを参照してください。

• WindowsVista セキュリティ ガイド:
  

  http://technet.microsoft.com/en-us/library/bb629420.aspx

• WindowsXP セキュリティ ベースライン:

  http://go.microsoft.com/fwlink/?LinkId=14839

• WindowsServer 2003 セキュリティ ベースライン:

  http://go.microsoft.com/fwlink/?linkid=14845

• Windows 2000 セキュリティ強化ガイド:
  

  http://go.microsoft.com/fwlink/?LinkId=28591

Microsoft セキュリティ ガイドを実装した後に問題が発生した場合、またはコメントがある場合は、 にメール メッセージを送信してフィードバックsecwish@microsoft.com。



Windows 用、Internet Explorer 用、および Office 生産性向上スイート用のセキュリティ構成ガイダンスについては、「Microsoft Security Compliance Manager: http://technet.microsoft.com/en-us/library/cc677002.aspx」を参照してください。

インターネット セキュリティセンター

CIS は、組織が特定の利用可能なセキュリティの選択に関する情報に基づいた意思決定を行うのに役立つ情報を提供するベンチマークを開発しました。 CIS には、次の 3 つのレベルのセキュリティ ベンチマークが用意されています。

• レガシ

• Enterprise

• 高いセキュリティ

CIS ベンチマーク設定を実装した後に問題が発生した場合、またはコメントがある場合は、 に電子メール メッセージを送信して CISに win2k-feedback@cisecurity.org。

CIS のガイダンスは、最初にこの記事を公開して以来変更されています (2004 年 11 月 3 日)。 CIS の現在のガイダンスは、Microsoft が提供するガイダンスに似たものです。 Microsoft が提供するガイダンスの詳細については、この記事の前の「Microsoft Corporation」セクションを参照してください。

The National Institute of Standards and Technology

NIST は、米国連邦政府のセキュリティ ガイダンスを作成する責任を負います。 NIST は、米国連邦機関、プライベート組織、および公的組織によって使用される 4 つのレベルのセキュリティ ガイダンスを作成しました。

• SoHo

• レガシ

• Enterprise

• 特殊なセキュリティ – 制限付き機能

NIST セキュリティ テンプレートを実装した後に問題が発生した場合、またはコメントがある場合は、 にメール メッセージを送信して NIST に連絡 itsec@nist.gov。

NIST のガイダンスは、最初にこの記事を公開して以来変更されています (2004 年 11 月 3 日)。 NIST の現在のガイダンスは、Microsoft が提供するガイダンスに似たものです。 Microsoft が提供するガイダンスの詳細については、この記事の前の「Microsoft Corporation」セクションを参照してください。

国防情報システム局

DISA は、米国国防総省 (DOD) で使用するために特別にガイダンスを作成します。 DISA 構成ガイダンスを実装した後に問題が発生した、またはコメントがある米国 DOD ユーザーは、 に電子メール メッセージを送信することでフィードバックfso_spt@ritchie.disa.mil。

注意 DISA のガイダンスは、最初にこの記事を公開して以来変更されました (2004 年 11 月 3 日)。 DISA の現在のガイダンスは、Microsoft が提供するガイダンスと似ているか、同じです。 Microsoft が提供するガイダンスの詳細については、この記事の前の「Microsoft Corporation」セクションを参照してください。

National Security Agency (NSA)

NSA は、米国国防総省 (DOD) で危険度の高いコンピューターをセキュリティで保護するためのガイダンスを生成しました。 NSA は、他の組織によって生成される高セキュリティ レベルにほぼ対応する単一レベルのガイダンスを開発しました。

Windows XP の NSA セキュリティ ガイドを実装した後に問題が発生した場合、またはコメントがある場合は、メール メッセージを XPGuides@nsa.gov に送信してフィードバックを提供できます。 Windows 2000 ガイドに関するフィードバックを提供するには、 にメールメッセージをw2kguides@nsa.gov。

注意 NSA のガイダンスは、最初にこの記事を公開して以来変更されました (2004 年 11 月 3 日)。 NSA の現在のガイダンスは、Microsoft が提供するガイダンスと似ているか、同じです。 Microsoft が提供するガイダンスの詳細については、この記事の前の「Microsoft Corporation」セクションを参照してください。

ファイル システムとレジストリのアクセス制御リストの変更

WindowsXP 以降のバージョンの Windowsシステム全体でアクセス許可が大幅に強化されています。 そのため、既定のアクセス許可を広範囲に変更する必要はありません。 

追加の任意アクセス制御リスト (DACL) の変更により、Microsoft によって実行されるアプリケーション互換性テストのすべてまたは大部分が無効になる可能性があります。 多くの場合、このような変更は、Microsoft が他の設定で実行した徹底的なテストを受け取っていません。 サポート ケースとフィールド エクスペリエンスでは、DACL の編集によってオペレーティング システムの基本的な動作が変更され、意図しない方法で頻繁に変更される可能性が示されています。 これらの変更は、パフォーマンスと機能の両方に関して、アプリケーションの互換性と安定性に影響を与え、機能を低下させます。

これらの変更のため、運用システムのオペレーティング システムに含まれているファイルのファイル システム DACLs を変更することをお勧めしません。 既知の脅威に対する追加の ACL の変更を評価して、変更が特定の構成に与える可能性がある潜在的な利点を理解することをお勧めします。 これらの理由から、ガイドでは DACL の変更を最小限に抑え、2000 年Windowsします。 2000 Windows、いくつかの小さな変更が必要です。 これらの変更については、「Windows セキュリティ強化ガイド」を参照してください。

レジストリとファイル システム全体に反映される広範なアクセス許可の変更を元に戻すことはできません。 オペレーティング システムの元のインストール時に存在しないユーザー プロファイル フォルダーなどの新しいフォルダーが影響を受ける可能性があります。 そのため、DACL の変更を実行するグループ ポリシー設定を削除した場合、またはシステムの既定値を適用した場合は、元の DACL をロールバックできません。 

%SystemDrive% フォルダーの DACL を変更すると、次のシナリオが発生する可能性があります。

• ごみ箱は設計通り機能しなくなったので、ファイルを回復することはできません。

• 管理者以外のユーザーが管理者のごみ箱の内容を表示できるセキュリティの削減。

• ユーザー プロファイルが期待通り機能しなきエラー。

• システム上の一部またはすべてのユーザー プロファイルへの読み取りアクセスを対話型ユーザーに提供するセキュリティの削減。

• 多くの DACL 編集がグループ ポリシー オブジェクトに読み込まれ、長いログオン時間やターゲット システムの繰り返しの再起動が含まれる場合のパフォーマンスの問題。

• グループ ポリシーの設定が再適用される場合、システムの速度低下などのパフォーマンスの問題が 16 時間おきに発生します。

• アプリケーションの互換性の問題またはアプリケーションのクラッシュ。

このようなファイルとレジストリのアクセス許可の最悪の結果を削除するために、Microsoft は、お客様のサポート契約に沿って、商業的に妥当な努力を行います。 ただし、現在、これらの変更をロールバックすることはできません。 ハード ディスク ドライブを再フォーマットし、オペレーティング システムを再インストールすることで、推奨される既定の設定に戻り得る保証のみを行います。

たとえば、レジストリ DACLs の変更はレジストリ ハイブの大部分に影響を与え、システムが期待通り機能しなくなる可能性があります。 1 つのレジストリ キーで DACLs を変更すると、多くのシステムで問題が発生する可能性が低い。 ただし、これらの変更を実装する前に慎重に検討し、テストすることをお勧めします。 繰り返しになりますが、オペレーティング システムを再フォーマットして再インストールする場合は、推奨される標準設定に戻る可能性があります。

Microsoft ネットワーク クライアント: デジタル署名通信 (常に)

この設定を有効にすると、クライアントは SMB 署名を必要としないサーバーに接続するときに、サーバー メッセージ ブロック (SMB) トラフィックに署名する必要があります。 これにより、クライアントはセッション ハイジャック攻撃に対して脆弱になります。 これは大きな価値を提供しますが、Microsoft ネットワーク サーバーで同様の変更を有効にすることなく、デジタル署名通信 (常時) または Microsoft ネットワーク クライアント: デジタル署名通信 (クライアントが同意した場合 )は、クライアントがサーバーと正常に通信できません。

ネットワーク セキュリティ: 次回のパスワード変更時に LAN Manager ハッシュ値を格納しない

この設定を有効にすると、パスワードが変更された場合、新しいパスワードの LAN Manager (LM) ハッシュ値は保存されません。 LM ハッシュは比較的弱く、暗号化が強い Microsoft ハッシュと比較して攻撃Windows NTがあります。 この設定は、多くの一般的なパスワード クラッキング ユーティリティを防止することで、システムに広範なセキュリティを提供しますが、一部のアプリケーションが正常に起動または実行されるのを防ぐ可能性があります。

システム暗号化: 暗号化、ハッシュ、署名に FIPS に準拠したアルゴリズムを使用する

この設定を有効にすると、インターネット インフォメーション サービス (IIS) と Microsoft Internet Explorer トランスポート層セキュリティ (TLS) 1.0 プロトコルのみを使用できます。 IIS を実行しているサーバーでこの設定が有効になっている場合は、TLS 1.0 をサポートする Web ブラウザーだけが接続できます。 この設定が Web クライアントで有効になっている場合、クライアントは TLS 1.0 プロトコルをサポートするサーバーにのみ接続できます。 この要件は、クライアントが WEB サイト (SSL) を使用する Web サイトにアクセスSecure Sockets Layer影響する可能性があります。詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を表示します。

811834 FIPS に準拠した暗号化を有効にした後に SSL サイトにアクセスできない さらに、ターミナル サービスを使用するサーバーでこの設定を有効にすると、クライアントは RDP クライアント 5.2 以降のバージョンを使用して接続することを強制されます。


詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を表示します。

811833 Windows XP 以降のバージョンでは、"システム暗号化: 暗号化、ハッシュ、署名に FIPS 準拠アルゴリズムを使用する" セキュリティ設定を有効にしたWindows

自動更新サービスまたはバックグラウンド インテリジェント転送サービス (BITS) が無効になっている

Microsoft セキュリティ戦略の重要な柱の 1 つは、システムが更新プログラムに最新の状態を維持する方法です。 この戦略の重要なコンポーネントは、自動更新サービスです。 更新Windowsソフトウェア更新プログラム サービスの両方で、自動更新サービスを使用します。 自動更新サービスは、バックグラウンド インテリジェント転送サービス (BITS) に依存します。 これらのサービスが無効になっている場合、コンピューターは、Windows Update から自動更新、ソフトウェア更新サービス (SUS)、または一部の Microsoft Systems Management Server (携帯ショートメール) インストールから更新プログラムを受信できなくなります。 これらのサービスは、BITS に依存しない有効な更新配布システムがあるシステムでのみ無効にする必要があります。

NetLogon サービスが無効になっている

NetLogon サービスを無効にすると、ワークステーションはドメイン メンバーとして確実に機能しなくなりました。 この設定は、ドメインに参加していない一部のコンピューターに適している場合があります。 ただし、デプロイ前に慎重に評価する必要があります。

NoNameReleaseOnDemand

この設定により、ネットワーク上の別のコンピューターと競合する場合、サーバーは NetBIOS 名を削除できません。 この設定は、ネーム サーバーや他の非常に重要なサーバー ロールに対するサービス拒否攻撃の予防策として有効です。

ワークステーションでこの設定を有効にすると、ドメイン コントローラーなどのより重要なシステムの名前と名前が競合する場合でも、ワークステーションは NetBIOS 名の削除を拒否します。 このシナリオでは、重要なドメイン機能を無効にできます。 Microsoft は、高いセキュリティ領域での展開を対象としたセキュリティ ガイダンスを提供する業界の取り組みを強くサポートしています。 ただし、このガイダンスはターゲット環境で徹底的にテストする必要があります。 既定の設定を超えて追加のセキュリティ設定を必要とするシステム管理者は、Microsoft が発行したガイドを組織の要件の開始点として使用することを強くお勧めします。 サード パーティのガイドに関するサポートや質問については、ガイダンスを発行した組織にお問い合わせください。