ようこそ サインイン
MSDN
印刷用ページ      送信     
クリックして評価とフィードバックをお寄せください
MSDN
MSDN ライブラリ
テクニカルドキュメント
セキュリティ
 Web アプリケーション セキュリティ強化: 脅威とその対策
Web アプリケーション セキュリティ強化: 脅威とその対策

展開レビュー

公開日: 2004年9月7日 | 最終更新日: 2004年9月7日
トピック

モジュールの内容 モジュールの内容
目的 目的
適用対象 適用対象
モジュールの使用方法 モジュールの使用方法
概要 概要
Web サーバーの構成 Web サーバーの構成
IIS の構成 IIS の構成
Machine.Config Machine.Config
Web サービス Web サービス
Enterprise Services Enterprise Services
Remoting Remoting
データベース サーバーの構成 データベース サーバーの構成
ネットワークの構成 ネットワークの構成
要約 要約

モジュールの内容

稼動中のサーバーへ ASP.NET Web アプリケーションの展開が終了したら、最後に展開したものがセキュリティ保護されたこと、および Web アプリケーション環境が可能な限りセキュリティ保護され、またロックされていることを確認する必要があります。

設計面でも、既定の設定でも、また展開においてもセキュリティ保護された (つまり高度にセキュリティ保護され、ロックされたサーバー環境で稼動する) ASP.NET Web アプリケーションを作成しようとあらゆる努力を注いでも、アプリケーションがセキュリティ保護されておらず侵害されやすいインフラストラクチャを基にしている場合、保護されません。ネットワークやホスト構成の設定の短所は、悪用される可能性のある脆弱性の原因となります。

このモジュールには、ネットワークおよびホスト セキュリティの構成についての質問リストが含まれています。この質問リストを通じて、セキュリティ監査を行ううえで役立つ手法およびフレームワークが説明されています。

目的

このモジュールの目的は次のとおりです。

  • ASP.NET Web アプリケーションがセキュティ保護されて展開され、現在セキュリティ保護された環境にホストされていることを確認する。

  • 展開レビューとセキュリティ監査の手法およびフレームワークを作成する。

  • セキュリティに関する包括的な質問リストを使用して、セキュリティの問題を迅速に特定する。

  • ネットワークとホスト、ベースとなる Windows 2000、IIS と .NET Framework、Web アプリケーションと Web サービス、Enterprise Services、Remoting、および SQL Server について、展開後の構成をレビューする。

適用対象

このモジュールは、次の製品およびテクノロジに適用されます。

  • Microsoft® Windows 2000 Server

  • Microsoft .NET Framework 1.1 および ASP.NET 1.1

  • Microsoft SQL Server

モジュールの使用方法

このモジュールを使用して、ASP.NET Web アプリケーションがセキュティで保護されて展開され、ホスト環境がセキュリティで保護されていることを確認します。

このモジュールから最大限の成果を得るには、以下を参照してください。

  • モジュール 21「コード レビュー」を参照し、その手法に従って、対象 Web アプリケーションがセキュリティ保護されていることを確認します。

  • 構成カテゴリを使用します。このモジュールに示されているカテゴリを利用して、セキュリティ レビューの焦点を絞ります。

  • このガイドの第 4 部の、セキュリティ保護に関するモジュールも併せて使用してください。

    • モジュール 15「ネットワークをセキュリティ保護する」

    • モジュール 16「Web サーバーをセキュリティ保護する」

    • モジュール 17「アプリケーション サーバーをセキュリティ保護する」

    • モジュール 18「データベース サーバーをセキュリティ保護する」

    • モジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」

    • モジュール 20「複数の Web アプリケーションをホストする」

  • 以下の関連チェックリストを使用してください。

    • チェックリスト: ネットワークをセキュリティ保護する

    • チェックリスト: Web サーバーをセキュリティ保護する

    • チェックリスト: データベース サーバーをセキュリティ保護する

    • チェックリスト: マネージ コードのセキュリティ レビュー

概要

Web アプリケーションのセキュリティは、アプリケーションが展開されているインフラストラクチャのセキュリティに依存します。ネットワークやホスト構成の設定の短所は、悪用される可能性のある脆弱性の原因となります。このモジュールの展開レビューでは、ネットワークおよびホストの構成を検査します。ホストには Windows 2000 Server が含まれ、サーバー ロールによっては、IIS、Microsoft .NET Framework、Enterprise Services、SQL Server も含まれます。

展開レビュー プロセスの主な構成要素を図 22.1 に示します。

展開レビューの主な要素

図 22.1:
展開レビューの主な要素

Web サーバーの構成

レビューのこの段階での目標は、Web サーバーのベースとなるオペレーティング システム構成の脆弱性を識別することです。ここには、別個に扱う IIS の構成は含まれません。このセクションのレビュー項目で取り上げた事項の背景情報については、モジュール 16「Web サーバーをセキュリティ保護する」を参照してください。

レビュー プロセスに焦点を当てて構築できるように、レビュー項目は以下の構成カテゴリに分かれています。

  • 修正プログラムと更新

  • サービス

  • プロトコル

  • アカウント

  • ファイルとディレクトリ

  • 共有

  • ポート

  • レジストリ

  • 監査とログ記録

修正プログラムと更新

サーバーが最新の Service Pack およびソフトウェア修正プログラムで更新されていることを確認します。オペレーティング システム コンポーネントと .NET Framework のそれぞれについて確認する必要があります。次のレビュー項目を確認してください。

  • MBSA を実行しましたか。
    必ず MBSA ツールを実行して、一般的な Windows と IIS の脆弱性、および Service Pack と修正プログラムの不足について確認してください。

    MBSA の出力に応じて見つかった脆弱性を修正し、最新の修正プログラムや更新をインストールします。詳細については、モジュール 16「Web サーバーをセキュリティ保護する」の「手順 1: 修正プログラムと更新」を参照してください。

  • .NET Framework の更新をインストールしましたか。
    .NET Framework の現在のバージョンを確認するには、マイクロソフト サポート技術情報の 318785「[INFO] .NET Framework の Service Pack がインストール済みか確認する方法」を参照してください。次に、インストールした .NET Framework のバージョンを、現在の Service Pack と比較します。この比較には、マイクロソフト サポート技術情報の 318836「[INFO] 最新の .NET Framework Service Pack の入手方法」で .NET Frameworkのバージョン情報を使用してください。

サービス

必要なサービスのみが有効になっていることを確認します。サーバーの攻撃プロファイルを減らすため、他のサービスがすべて無効になっていることを確認します。[コンピュータの管理] の [サービスとアプリケーション] の Microsoft 管理コンソール (MMC) スナップインで、どのサービスが実行され、また有効になっているかを確認します。サービスを無効にする場合、そのサービスが停止され、[スタートアップの種類] が [手動] に設定されていることを確認します。

以下の質問を検討して、サービスの構成を確認してください。

  • 不要なサービスを実行していますか。
    サービス スナップインで実行中のサービスを確認し、すべてのサービスが必要であることを確認します。そのサービスが必要である理由と、どのソリューションに依存しているかを確認します。不要なサービスがすべて無効になっていることを確認します。

  • Telnet サービスを無効にしていますか。
    Telnet は多くの場合、リモート IIS 管理に使用されます。しかし、Telnet は攻撃を受けやすい、セキュリティ保護されていないプロトコルです。Telnet サービスが無効になっていることを確認します。管理ソリューションのセキュリティを強化するには、Terminal Services を使用してください。

  • FTP、SMTP、および NNTP サービスを無効にしていますか。
    これらのサービスはセキュリティ保護されたプロトコルではなく、既知の脆弱性があります。必要でない場合、これらを無効にしてください。これらのサービスを使用する場合、セキュリティ保護された別の方法を考えてください。これらのサービスはサービス MMC スナップインで FTP Publishing Service、Simple Mail Transport Protocol (SMTP)、および Network News Transport Protocol (NNTP) と表示されています。

    注: IISLockdown を使用すると、これらのサービスを無効にすることができます。

  • ASP .NET セッション状態サービスを使用していますか。
    アプリケーションの Web.config ファイルの <sessionState> 要素で、アプリケーションがこのサービスを使用しているかどうかを確認します。Web.config にこの要素がない場合は、Machine.config. ファイルの設定を確認します。mode 属性が "StateServer" に設定され、"stateConnectionString" が以下のように localhost アドレスなどのローカル マシンを指定している場合、Web サーバーにはセッション状態サービスが使用されています。

    <sessionState mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424" />

    Web サーバーでこのサービスを使用しない場合、無効にします。サービス MMC スナップインでは "ASP.NET State Service" と表示されています。

    ASP .NET セッション状態をセキュリティ保護する方法の詳細については、モジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」の「セッション状態」を参照してください。

プロトコル

サーバーで有効なプロトコルを確認して、不要なプロトコルが有効になっていないことを確認します。次の質問を使用して、サーバーのプロトコルを確認します。

  • WebDAV を使用していますか。
    WebDAV (Web Distributed Authoring and Versioning) を使用してコンテンツを発行している場合、コンテンツがセキュリティ保護されていることを確認してください。使用しない場合は、このプロトコルを無効にします。

    WebDAV をセキュリティ保護する方法については、マイクロソフト サポート技術情報の 323470「HOW TO: 安全な WebDAV 発行ディレクトリを作成します。」を参照してください。WebDAV を無効にする方法については、マイクロソフト サポート技術情報の 241520「[IIS] IIS 5.0 の WebDAV を無効にする方法」を参照してください。

  • TCP/IP スタックを強化しましたか。
    TCP/IP スタックが強化され、ネットワーク レベルの SYN フラッド攻撃などのサービス拒否 (DoS) 攻撃を防いでいることを確認します。サーバーのスタックが強化されているかどうかを確認するには、Regedt32.exe を使用して以下のレジストリ キーを調べます。

    HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    以下の子キーが存在する場合、TCP/IP スタックは強化されています: "SynAttackProtect、EnableICMPRedirect、および EnableDeadGWDetect"

    必要なキーおよび最大限にセキュリティを強化したスタックの適切なキー値の完全なリストについては、このガイドの「[HOWTO] TCP/IP スタックを強化する方法」を参照してください。

  • インターネットに接続されるネットワーク カードの NetBIOS および SMB を無効にしていますか。
    NetBIOS over TCP/IP、および SMB が無効になっており、ホストの列挙攻撃を防いでいることを確認します。詳細については、モジュール 16「Web サーバーをセキュリティ保護する」の「プロトコル」を参照してください。

アカウント

サーバー上のすべての Winodws アカウントの使用状況を確認し、不要なアカウントが存在しないこと、およびすべての必要なアカウントが最小限の権限と必要なアクセス権を付与されていることを確認します。次の質問は、アカウントの脆弱性を識別します。

  • 使用していないアカウントをすべて削除または無効にしていますか。
    監査を行って、すべてのアカウントが必要であり、使用されていることを検証します。不要なアカウントはすべて削除あるいは無効にします。ローカルの 管理者アカウントおよび "Guest" アカウントは削除することができません。"Guest" アカウントを無効にすること、および "Administrator" アカウントの名前を変更したうえで 管理者アカウントに強力なパスワードを付与する必要があります。

  • Guest アカウントを無効にしていますか。
    [コンピュータの管理] ツールの [ユーザー] フォルダを表示し、"Guest" アカウントの隣の"×"アイコンの有無で、"Guest" アカウントが無効になっているかどうかを確認します。Guest アカウントが無効になっていない場合、[プロパティ] ダイアログ ボックスを表示して [アカウントを無効にする] を選択します。

  • 既定の管理者アカウントの名前を変更しましたか。
    ローカルの既定の "Administrator" アカウントは、絶好の攻撃目標となります。"Administrator" アカウントの名前を変更し、強力なパスワードが設定されたことを確認します。

  • カスタムの匿名の Web アカウントを作成しましたか。
    "IUSR_MACHINE" アカウントが無効になっており、代わりに Web アプリケーション用の"匿名ユーザー" アカウントが構成されていることを確認します。

  • 強力なパスワード ポリシーを使用していますか。
    [ローカル セキュリティ設定] ツールで [パスワードのポリシー] を確認します。推奨されるパスワードのポリシーの詳細については、モジュール 16「Web サーバーをセキュリティ保護する」の「手順 5:アカウント」を参照してください。

  • リモート ログオンを制限していますか。
    [ローカル セキュリティ ポリシー] ツールの [ユーザー権利の割り当て] で、[ネットワーク経由でコンピュータへアクセス] が [Everyone] グループに設定されていないことを確認します。

  • NULL セッションを無効にしていますか。
    NULL セッションが無効になっており、匿名 (認証されていない) セッションがサーバーで作成されないようになっていることを確認します。これを確認するには、Regedt32.exe を実行して、"RestrictAnonymous" キーが以下に示すように 1 に設定されていることを確認します。

    HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

ファイルとディレクトリ

次の質問を検討し、NTFS アクセス許可が適切に使用され、匿名の Web ユーザー アカウントなどのアカウントをロックしていることを確認します。

  • IIS は NTFS ボリュームにインストールされていますか。
    NTFS ボリュームにインストールされている場合、NTFS を使用してアクセスを制限するようにリソースの ACL を構成できます。FAT パーティションを使用するサーバーを構築しないでください。

  • Everyone グループを制限していますか。
    エクスプローラで Everyone グループが以下のディレクトリのいずれにもアクセスしないことを確認します。

    • ルート ディレクトリ (:\)

    • システム ディレクトリ (\WINNT\system32)

    • Framework ツール ディレクトリ (\WINNT\Microsoft.NET\Framework\{version})

    • Web サイトのルート ディレクトリおよびすべてのコンテンツのディレクトリ (既定では\inetpub\*)

  • 匿名の Web ユーザー アカウントを制限していますか。
    匿名のインターネット ユーザー アカウントでは Web コンテンツのディレクトリへ書き込みできないことを確認します。エクスプローラで各コンテンツのディレクトリの ACL を表示します。%windir%\system32 ディレクトリの ACL についても、匿名のインターネット ユーザー アカウントがシステム ツールおよびシステム ユーティリティにアクセスできないことを確認してください。

    注: IISLockdown を使用すると、匿名の Web ユーザー グループおよび Web アプリケーション グループのアクセスを制限できます。既定では、匿名の Web ユーザー グループに IUSR アカウントが、Web アプリケーション グループにIWAM （Internet Web Application Manager） が含まれる設定になっています。管理の観点から見ると、1 つのグループにアクセスを制限する方が、個々のアカウントを制限するより好ましい方法です。

  • ユーティリティおよび SDK をセキュリティ保護または削除しましたか。
    ユーティリティまたはソフトウェア開発キット (SDK) がサーバーにないことを確認します。Visual Studio.NET と .NET Framework SDK のいずれもインストールされていないことを確認します。NTFS へのアクセス許可を、At.exe、Cmd.exe、Net.exe、Pathping.exe、Regedit.exe、Regedt32.exe、Runonce.exe、Runas.exe、Telnet.exe、および Tracert.exe などの強力なシステム ツールに制限していることも確認します。最後に、デバッグ ツールがサーバーにインストールされていないことを確認します。IISLockdown を実行すると、匿名の Web ユーザー グループおよび Web アプリケーション グループからシステム ツールへのアクセスを自動的に制限します。

  • 使用していない DSN を削除しましたか。
    DSN (Data Source Name) にはデータベース接続の詳細がクリア テキストで含まれている可能性があるため、使用していない DSN がすべてサーバーから削除されていることを確認してください。

共有

以下の質問を検討し、サーバーが共有ファイルの存在によって不必要に公開されないようにしてください。

  • サーバーで何が共有になっていますか。
    コンピュータの管理 MMC スナップインで [共有フォルダ] の下の [共有] を選択して、共有および関連アクセス許可を確認します。すべての共有が必要であることを確認します。不要な共有はすべて削除します。

  • Everyone グループが共有にアクセスできますか。
    Everyone グループは指定されない限り共有にアクセスできないこと、その代わりに特定の許可が設定されていることを確認します。

  • 管理用共有を削除しましたか。
    サーバーのリモート管理を許可していない場合は、C$ や IPC$ などの管理用共有が削除されていることを確認します。

ポート

サーバーでアクティブなポートを確認して、不要なポートが利用可能でないことを確認します。以下の "netstat" コマンドを実行して、リスン状態にあるポートを確認します。

netstat -n -a

このコマンドにより、以下が出力されます。

Netstat の出力

図 22.2:
Netstat の出力

この出力には、すべてのポートについて、アドレスおよび現在の状態が一覧表示されています。リスン状態の各ポートがどのサービスを公開するかを把握し、その各サービスが必要であることを確認します。使用していないサービスをすべて無効にします。

オペレーティング システムの findstr ツールと併用すると、netstat 出力の特定の文字列パターンをフィルタすることができます。次の例では、"リスン" 状態のポートに関する出力をフィルタしています。

netstat -n -a | findstr LISTENING

Portqry.exe コマンド ライン ユーティリティを使用して、TCP/IP ポートの状態を検証することもできます。ツールの詳細およびダウンロード方法については、マイクロソフト サポート技術情報の 310099「Portqry.exe コマンド ライン ユーティリティの説明」を参照してください。

次の項目についても検討します。

  • インターネットに接続されるポートは TCP 80 443 に制限されています。

  • イントラネットのトラフィックが制限または暗号化されています。

レジストリ

以下の質問を検討して、レジストリ構成のセキュリティを確認します。

  • リモート レジストリ管理を制限していますか。
    Regedt32.exe を使用して WinReg レジストリ キーの ACL を確認します。このレジストリ キーはそのレジストリにリモート アクセスできるかどうかを制御します。

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

    Windows 2000 の既定では、リモート レジストリ アクセスは "Administrators" および "Backup operators" グループのメンバに制限されます。空の随意アクセス制御リスト (DACL) を使用してレジストリへのすべてのリモート アクセスを制限し、最大限のセキュリティを確保してください。

    注: レジストリへのリモート アクセスが必要なサービスもあります。マイクロソフト サポート技術情報の 153183「リモート コンピュータからレジストリへのリモート アクセスを制限する方法」を参照して、シナリオに制限付きのリモート レジストリ アクセスが必要かどうかを確認してください。

  • SAM をセキュリティ保護していますか。
    この項目は、スタンドアロンのサーバーにのみ適用されます。以下に示すようにレジストリの キー (値ではありません) に "NoLMHash" を設定して、セキュリティ アカウント マネージャ (SAM) データベース内の LMHash ストレージを制限していることを確認します。

    HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

監査とログ記録

以下の質問を検討して、Windows 監査の使用について確認します。

  • 失敗したログオン試行のログをすべて記録していますか。
    [ローカル セキュリティ ポリシー] ツールでログオン試行の失敗を監査する設定になっていることを確認します。

  • ファイル システム全体の失敗したアクションすべてをログ記録する設定になっていますか。
    [ローカル セキュリティ ポリシー] ツールでオブジェクト アクセスの監査が有効になっていることを確認します。次に、ファイル システム全体の監査が有効になっていることを確認します。

IIS の構成

IIS の構成設定をレビューして改善すると、Web サーバーが攻撃を受ける危険性を実質的に軽減することができます。このセクションで取り上げたレビュー ポイントの詳細については、モジュール 16「Web サーバーをセキュリティ保護する」を参照してください。

このセクションのレビュー項目は、以下の構成カテゴリに基づいて構成されています。

  • IISLockdown

  • URLScan

  • サイトと仮想ディレクトリ

  • ISAPI フィルタ

  • IIS メタベース

  • サーバー証明書

IISLockdown

機能の識別や機能をオフにできる IISLockdown ツールを使用すると、IIS が攻撃を受ける危険性を軽減することができます。サーバーで IISLockdown が実行されているかどうかは、IISLockdown が生成する以下のレポートで確認します。

\WINNT\system32\inetsrv\oblt-rep.log

IISLockdown の詳細については、このガイドの「[HOWTO] IISLockdown.exe を使用する方法」を確認してください。

URLScan

URLScan は、IISLockdown と共にインストールされる ISAPI フィルタです。URLScan は、潜在的に有害な要求がサーバーに到達し、損害を発生させないように防御するうえで役立ちます。URLScan がインストールされており、適切に構成されていることを確認します。

  • 以下の手順で URLScan がインストールされているかどうかを確認します。

  1. [インターネット サービス マネージャ] を開始します。

  2. サーバー名 (Web サイトではありません) を右クリックし、次に [プロパティ] をクリックします。

  3. [マスタ プロパティ] の横の [編集] ボタンをクリックします。

  4. [ISAPI フィルタ] タブをクリックして URLScan がリストに表示されていることを確認します。

URLScan の構成を確認するために、メモ帳を使用して以下の URLScan 構成ファイルを編集します。

%WINDIR%\System32\Inetsrv\URLscan\Urlscan.ini

URLScan の詳細については、このガイドの「[HOWTO] URLScan を使用する方法」を参照してください。

サイトと仮想ディレクトリ

このセクションのレビュー項目は、Web サイトおよびアプリケーションの仮想ディレクトリの、特定の構成に関連しています。ここでは、以下のカテゴリをレビューします。

  • Web サイトの場所

  • スクリプト マッピング

  • 匿名のインターネット ユーザー アカウント

  • 監査とログ記録

  • Web アクセス許可

  • IP アドレスとドメイン名の制限

  • 認証

  • 親のパスの設定

  • Microsoft FrontPage® Server Extensions

Web サイトの場所

Web サイトのルート ディレクトリがシステム ボリューム以外の場所にインストールされていることを確認します。Web サイトのルート ディレクトリをシステム ボリューム以外の場所に移動することにより、ディレクトリ トラバーサル攻撃を使用する攻撃者がシステム ツールや Cmd.exe などの実行可能なファイルにアクセスすることを防ぐことができます。

スクリプト マッピング

IISLockdown を実行するとインストールされる 404.dll に、不要なファイル拡張子がすべてマップされていることを確認します。

  • スクリプト マッピングを以下の手順で確認します。

  1. [インターネット サービス マネージャ] を開始します。

  2. Web サイト名を右クリックして [プロパティ] をクリックします。

  3. [ホーム ディレクトリ] タブをクリックして、[アプリケーションの設定] グループの [構成] ボタンをクリックします。

匿名のインターネット ユーザー アカウント

アプリケーションが、既定以外の匿名のインターネット ユーザー アカウントを使用する構成になっていることを確認します。サーバーで複数の Web アプリケーションを使用する場合は、各アプリケーションが別個の匿名アカウントを使用する構成になっていることを確認します。このことにより、アクセス許可を構成し、各 Web アプリケーションごとにアクティビティを追跡することができます。

監査とログ記録

IIS 監査が、進行中の攻撃を検出し、攻撃の形跡を診断できる構成になっていることを確認します。以下のレビュー項目は、IIS 監査で脆弱性を識別するためのものです。

  • ログ ファイルは、システム以外のボリュームに、分かれて配置されていますか。
    IIS で Web サイト名を右クリックして [Web サイト] タブをクリックします。[プロパティ] ボタンをクリックして、ログ ファイルの場所を確認します。ログ ファイルが既定以外の場所、できればシステム ボリューム以外の場所に、既定ではない名前で保存されていることを確認します。

  • ログ ファイルへのアクセスを制限していますか。
    エクスプローラでログ ファイル ディレクトリの ACL を表示します。ACL が Administrators および System にはフル コントロールを与えていますが、他のユーザーにはアクセス許可を与えていないことを確認します。

Web アクセス許可

Web サイトおよび各仮想ディレクトリに設定されている、既定のアクセス許可を確認します。以下の条件をすべて満たしていることを確認します。

  • インクルード ディレクトリが読み取り許可を制限しています。

  • 匿名アクセスが許可されている仮想ディレクトリが、書き込みと実行のアクセス許可を制限する設定になっています。

  • 書き込み許可およびスクリプト ソースへのアクセス許可が、コンテンツをオーサリングできるコンテンツ フォルダにのみ付与されている。また、コンテンツをオーサリングできるフォルダが、認証および SSL (Secure Sockets Layer) 暗号化を要求することを確認する。

IP アドレスとドメイン名の制限

IP アドレスとドメイン名を制限して Web サーバーへのアクセスを制限していますか。制限している場合、IP スプーフィングの危険性を考慮していますか。

認証

Web サイトおよび仮想ディレクトリの認証設定を確認します。匿名アクセスが、サイトの外部からのアクセス可能な領域でのみサポートされていることを確認します。複数の認証オプションを選択している場合、アプリケーションへの影響と認証の優先順位を徹底的にテストします。

基本認証を選択している場合、SSL がサイト全体に使用され、資格情報を保護していることを確認します。

親のパスの設定

親のパスを無効にして、スクリプトでの ".." の使用、およびアプリケーションによる "MapPath" などの機能の呼び出しを防いでいることを確認します。これはディレクトリ トラバーサル攻撃を防ぐうえでも役立ちます。

  • 以下の手順で親のパスの設定を確認します。

  1. [インターネット サービス マネージャ] を開始します。

  2. Web サイト名を右クリックし、次に[プロパティ] をクリックします。

  3. [ホーム ディレクトリ] タブをクリックします。

  4. [構成] をクリックします。

  5. [アプリケーションのオプション] タブをクリックします。

  6. [親のパスを有効にする] チェックボックスをオフにします。

FrontPage Server Extensions (FPSE)

FrontPage Server Extensions は、FrontPage ベースの Web サイトに対するアクセス、オーサリング、および管理に使用します。これらの拡張機能の最新バージョンを使用して、セキュリティの脆弱性を回避してください。攻撃を受ける危険性を軽減するため、使用しない場合は FPSE を無効にします。

詳細については、モジュール 16「Web サーバーをセキュリティ保護する」の「手順 11: サイトと仮想ディレクトリ」を参照してください。

ISAPI フィルタ

フィルタの潜在的な脆弱性が危険にさらされることを防ぐため、使用していない ISAPI フィルタがインストールされていないことを確認します。

  • 以下の手順で ISAPI フィルタを確認します。

  1. [インターネット サービス マネージャ] を開始します。

  2. サーバー名 (Web サイトではありません) を右クリックし、次に[プロパティ] をクリックします。

  3. [マスタ プロパティ] の横の [編集] ボタンをクリックします。

  4. [ISAPI フィルタ] タブをクリックして インストールされているフィルタを表示します。

IIS メタベース

IIS メタベースには、IIS 構成の設定情報が含まれます。この多くは IIS 管理ツールで設定されたものですが、すべてが IIS 管理ツールで設定されている訳ではありません。ファイル自身が保護されている必要があります。また、IIS 構成ツールで維持できない特定の設定について確認する必要があります。以下の質問を検討して、メタベースが適切に構成されていることを確認します。

  • メタベースへのアクセスを制限していますか。
    メタベース ファイルの ACL が、フル コントロール アクセス許可をシステム アカウントと管理者のみに付与していることを確認します。これら以外のアカウントにはアクセス許可を設定しないでください。メタベース ファイルとその場所は次のとおりです。

    %windir%\system32\inetsrv\metabase.bin

  • 内部 IP アドレスを公開していますか。
    既定では、IIS はサーバーの内部 IP アドレスを HTTP 応答ヘッダーの Content-Location セクションに返す設定になっています。UseHostName メタベース プロパティを true に変更して、返さないように設定する必要があります。以下のコマンドを \inetpub\adminscripts から実行して、設定状態を確認します。

    adsutil GET w3svc/UseHostName

    プロパティ値が true に設定されていることを確認します。プロパティが true に設定されていない場合、このコマンドは [The parameter 'UseHostName' is not set at this node.] というメッセージを返します。詳細については、モジュール 16「Web サーバーをセキュリティ保護する」の「手順 14: IIS メタベース」を参照してください。

サーバー証明書

アプリケーションに SSL を使用する場合、Web サーバーに有効な証明書がインストールされていることを確認します。IIS で Web サイトの[プロパティ] ダイアログ ボックス、[ディレクトリ セキュリティ] ページ、[証明書の表示] の順にクリックして、サーバー証明書を表示します。次のレビュー項目を確認してください。

  • サーバー証明書は期限切れですか。

  • すべての公開キーが証明書チェーンの信頼されたルートまで有効になっていますか。

  • 証明書は失効していますか。

    証明書を発行したサーバーの証明書失効リスト (CRL) に、その証明書が含まれていないことを確認します。

Machine.Config

サーバーのすべてのアプリケーションの .NET Framework 構成は Machine.config でメンテナンスされます。セキュリティ レビューのため、ここでは Machine.config の設定を完全に検証し、セキュリティに関係する設定のみを検討します。

Web サービス構成および .NET Remoting 構成に見られる例外と共に、セキュリティ設定のほとんどは <system.web> 要素に含まれます。Web サービスと .NET Remoting の構成のレビューについては、このモジュールで後述します。

以下のレビュー項目で取り上げた問題の詳細および背景については、モジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」を参照してください。ここでは、次の要素をレビューします。

  • <trace>

  • <httpRunTime>

  • <compilation>

  • <pages>

  • <customErrors>

  • <authentication>

  • <identity>

  • <authorization>

  • <machineKey>

  • <trust>

  • <sessionState>

  • <httpHandlers>

  • <processModel>

<trace>

以下のように、トレースが無効に設定されていることを確認します。

<trace enabled="false" ... />

<httpRunTime>

<httpRunTime> 要素の maxRequestLength 属性の値を確認します。この値を使用して、ユーザーによる非常に大きいファイルのアップロードを防ぐことができます。最大値は 4 MB (メガバイト） です。

<compilation>

デバッグ用のバイナリ ファイルをコンパイルしないことを確認します。debug 属性が false に設定されていることを確認します。

<compilation debug="false" ... />

<pages>

<pages> 要素は既定のページ レベルの構成設定を制御します。セキュリティの観点から、ビュー ステートおよびセッション状態の設定を確認します。

  • ビュー ステートを使用していますか。
    enableViewState が true に設定されている場合、enableViewStateMac も true に設定され、ネットワークのビュー ステートを保護していることを確認します。また、<machineKey> 構成もレビューします。この構成は、関連するキーと共に使用される暗号化およびハッシュ アルゴリズムを指定します。

  • セッション状態を使用していますか。
    enableSessionState が true に設定されている場合、<sessionState> 要素の構成をレビューします。

<customErrors>

例外の情報がクライアントに公開されないように mode 属性が "On" に設定されていることを確認します。また、既定のエラー ページが defaultRedirect 属性によって指定されていることを確認します。

<customErrors mode="On" defaultRedirect="/apperrorpage.htm" />

<authentication>

この要素は、アプリケーションの認証メカニズムを制御します。mode 属性でどの認証メカニズムが構成されているかを確認します。次に実際に構成された認証モードに固有のレビュー項目を使用します。

<authentication mode="[Windows|Forms|Passport|None"] />
フォーム認証

以下の質問を検討して、フォーム認証の構成を確認します。

  • 認証 Cookie を暗号化していますか。
    Cookie はクロスサイト スクリプティング攻撃によって盗まれる可能性があるため、SSL チャネルを経由している場合でも、データの改ざんを検出できるように Cookie の暗号化および整合性チェックが必要です。<forms> 要素の protection 属性が All に設定されていることを確認します。

    <forms protection="All" .../>   All indicates encryption and verification

  • フォーム認証に SSL を使用していますか。
    SSL はセッション乗っ取り攻撃および Cookie を使用したリプレイ攻撃を防ぎます。<forms> 要素の requireSSL 属性を確認します。

    <forms requireSSL="true" ... />

  • 認証 Cookie の有効期限に期限を設けていますか。
    Cookie のタイムアウト時間を最小限にすると、攻撃者が Cookie を使用してアプリケーションにアクセスできる時間を制限することができます。<forms> 要素の timeout 属性を確認します。

    <forms timeout="10" ... />

  • 変化する有効期限を使用していますか。
    slidingExpiration 属性を確認します。slidingExpiration="true" は、Cookie の有効期限が最初の有効時間終了後一定の時間で切れることを意味します。タイムアウト時計はそれぞれの要求の後にリセットされません。Cookie を保護するためすべてのページで SSL を使用しないアプリケーションには、変化する有効期限の使用が特に推奨されます。

  • 一意の Cookie パスおよび Cookie 名を使用していますか。
    Web アプリケーションごとに個別の Cookie 名および Cookie パスを使用していることを確認します。このことにより、1 つのアプリケーションで認証されたユーザーが、同じ Web サーバーをホストとする別のアプリケーションを使用する際に認証済みとして扱われなくなります。<forms> 要素の path 属性および name 属性を確認します。

    <forms name=".ASPXAUTH" path="/" ... />

  • <credentials> 要素を使用していますか。
    運用サーバーで <credentials> 要素を使用しないでください。この要素は開発およびテスト目的にのみ使用します。資格情報は、Microsoft Active Directory® ディレクトリ サービスまたは SQL Server に格納してください。

  • 資格情報をどのように格納していますか。
    アプリケーションが Windows 認証を使用する場合、資格情報は Active Directory に格納されます。Active Directory は資格情報の管理事項を運用環境に渡します。アプリケーションがフォーム認証を使用する場合、SQL Server または Active Directory の資格情報ストアを使用することを確認します。

  • パスワード ハッシュを格納していますか。
    パスワードがデータベースに格納されないことを確認します。代わりに salt 値を適用したパスワード ハッシュを格納して、辞書攻撃に対抗します。

  • 強力なパスワードを使用していますか。
    アプリケーションで強力なパスワードが必ず使われるようにする必要があります。フォームのログオン ページに正規表現を使用することが良い方法です。

<identity>

以下の質問を検討して、<identity> 要素で指定された偽装構成を確認します。

  • オリジナルの呼び出し元を偽装していますか。
    impersonate 属性が true に設定され、username または password 属性を指定していない場合、匿名のインターネット ユーザー アカウントの可能性のある IIS 認証 ID を偽装しています。

    ACL が、アクセスを必要とするリソースにのみ偽装 ID がアクセスできるよう構成されていることを確認します。

  • 固定 ID を偽装していますか。
    偽装して userName および password 属性を設定している場合、固定 ID を偽装しています。この ID はリソースへのアクセスに使用されます。

    <identity> 要素にプレーンテキストの資格情報を指定していないことを確認します。代わりに、Aspnet_setreg.exe を使用して暗号化された資格情報をレジストリに格納します。

    Windows 2000 では [オペレーティング システムの一部として機能] ユーザー権利が ASP.NET プロセス アカウントに割り当てられてしまうため、この方法は推奨できません。代わりのアプローチについては、モジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」を参照してください。

<authorization>

この要素は、ASP.NET URL 承認、特に Web クライアントが特定のフォルダ、ページ、およびリソースにアクセスする機能を制御します。

  • ユーザー名およびロール名に正しい形式を使用していますか。
    <authentication mode="Windows" /> と指定すると、Windows のユーザーおよびグループ アカウントへのアクセスを承認することになります。

    ユーザー名の形式は DomainName\WindowsUserName です。ロール名の形式は DomainName\WindowsUserName です。

    注: ローカルの Administrators グループは [BUILTIN\Administrators] と記述されます。ローカルの Users グループは BUILTIN\Users と記述されます。

    <authentication mode="Forms" /> と指定すると、アプリケーションによって認証された ID に対して承認を行うことになります。通常、データベースから取得されたロールに対して承認を行います。ロール名はアプリケーションに固有です。

<machineKey>

この要素は、暗号化と検証キーの指定に使用され、アルゴリズムフォームは認証の Cookie およびページ レベルのビュー ステートの保護に使用されます。

  • 同じサーバーで複数のアプリケーションを実行しますか。
    実行する場合、"IsolateApps" 設定を使用してそれぞれの Web アプリケーションに対して別個のキーが生成されることを確認します。

    <machineKey validationKey="AutoGenerate,IsolateApps" 
decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>

  • Web ファームで実行しますか。
    Web ファームで実行する場合、特定のマシン キーを使用しており、ファームのサーバー キーのすべてを複製したことを確認します。

  • ビュー ステートを保護していますか。
    <pages> 要素で enableViewSetMac="true" と設定するなどしてビュー ステートを保護している場合、<machineKey> 要素の validation="SHA1" (セキュリティ保護されたハッシュ アルゴリズム) または "3DES" に設定します。<forms> 要素で protection="All" と設定してフォーム認証 Cookie も暗号化している場合は 3DES (Triple Data Encryption Standard) に設定する必要があります。

<trust>

<trust> 要素は、ASP.NET Web アプリケーションおよび Web サービスで実行されるコード アクセス セキュリティの信頼レベルを決定します。

  • .NET Framework のどのバージョンを実行しますか。
    .NET Framework 1.0 の場合、信頼レベルは "Full" に設定する必要があります。バージョンが 1.1 と同等以上の場合、次のいずれかに変更できます。

    <!--  level="[Full|High|Medium|Low|Minimal]" -->
<trust level="Full" originUrl=""/>

  • どの信頼レベルを使用しますか。
    セキュリティ ポリシーおよび開発チームとの合意に基づき、Web.config または Machine.config のいずれかについてアプリケーションの適切な信頼レベルを設定します。

<sessionState>

sessionState 要素は、アプリケーションでのユーザーのセッション状態管理を構成します。次のレビュー項目を確認してください。

  • リモートの状態ストアを使用していますか。
    mode 属性を調べて状態ストアを確認します。

    <sessionState mode="Off|Inproc|stateServer|SQLServer" ... />

    リモートの状態ストアを使用しており、mode 属性を "stateServer" または "SQLServer" に設定している場合、stateConnectionString および sqlConnectionString 属性をそれぞれ確認します。資格情報がデータベース接続文字列に含まれないようにするため、接続文字列が Aspnet_setreg.exe ツールで暗号化されてレジストリにセキュリティ保護されるか、あるいは Windows 認証を使用して SQL Server 状態ストアへ接続されることを確認します。

    以下の構成は、Aspnet_setreg.exe を使用してレジストリで文字列を暗号化した場合の "stateConnectionString" を示しています。

    <!-- aspnet_setreg.exe has been used to store encrypted details -->
<!-- in the registry. -->
<sessionState mode="StateServer"
stateConnectionString="registry:HKLM\SOFTWARE\YourSecureApp\
identity\ASPNET_SETREG,stateConnectionString" />

  • 状態データベースに Windows 認証を使用していますか。
    SQL Server 状態ストアを使用する場合、Windows 認証を使用して状態データベースに接続しているかどうかを確認します。接続している場合、資格情報が接続文字列に格納されていない、また資格情報がケーブルを介して送信されないことを意味します。

    SQL 認証を使用する必要がある場合、接続文字列がレジストリで暗号化され、サーバー証明書がデータベース サーバーにインストールされて、資格情報がケーブルを介して暗号化されるように設定します。

<httpHandlers>

この要素は、特定のファイルの種類に対する要求を処理する HTTP ハンドラを一覧表示します。使用していないファイルの種類がすべて無効になっていることを確認します。

使用していないファイルの種類を "System.Web.HttpForbiddenHandler" へマップして、その HTTP が取得されることを防ぎます。たとえば、アプリケーションが Web サービスを使用していない場合、拡張子の .asmx を次のようにマップします。

<httpHandlers>
<add verb="*" path="*.asmx" type="System.Web.HttpForbiddenHandler"/>
</httpHandlers>

<processModel>

ASP.NET ワーカー プロセスの実行に使用する ID は Machine.config の <processModel> 要素の設定により制御されます。以下のレビュー項目は、プロセス ID 設定を検証するためのものです。

  • どの ID を使用して ASP.NET を実行しますか。
    userName 属性および password 属性を確認します。理想的には、以下の設定を使用して、ASP.NET プロセスを最低限の権限を持つ ASPNET アカウントの下で実行します。

    <processModel userName="Machine" password="AutoGenerate" . . ./>

  • <processModel> 資格情報を暗号化していますか。
    カスタム アカウントを使用している場合、Machine.config のアカウントの資格情報がプレーンテキストで指定されていないことを確認します。Aspnet_setreg.exe ユーティリティを使用して暗号化された資格情報をレジストリに格納していることを確認します。Aspnet_setreg.exe ユーティリティを使用している場合、userName および password 属性は以下に示す設定と類似します。

    <processModel
userName="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
ASPNET_SETREG,password" . . ./>

  • 最低限の権限を持つアカウントを使用していますか。
    既定の ASPNET アカウントは最低限の権限を持つローカル アカウントで、ASP.NET の実行用です。リモート リソースへのアクセスに使用する場合、リモート サーバーにアカウントを複製する必要があります。代わりに、最低限の権限を持つドメイン アカウントを作成することもできます。

    アカウントが Users グループのメンバではないことを確認し、[ローカル セキュリティ ポリシー] ツールで [ユーザー権利の割り当て] を表示して、過剰なまたは不要なユーザー権利が割り当てられていないことを確認します。[オペレーティング システムの一部として機能] にユーザー権利が割り当てられていないことを確認します。

Web サービス

レビューのこの段階での目標は、Web サービスの構成の脆弱性を識別することです。このセクションのレビュー項目で取り上げた事項の背景情報については、モジュール 17「アプリケーション サーバーをセキュリティ保護する」およびモジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」を参照してください。

以下の質問を使用して、Web サービスのセキュリティ構成を確認します。

  • Documentation プロトコルを無効にしていますか。
    Web サービスのエンドポイントを公開したくない場合、Machine.config の <protocols> 要素から Documentation プロトコルを削除して、手動で Web サービス記述言語 (WSDL) ファイルを特定の Web サービス利用者に配布することができます。

  • HTTP Get および HTTP Post プロトコルを無効にしていますか。
    Machine.config の <protocols> 要素の HttpGet および HttpPost プロトコルを無効にする (コメントする)ことにより、Web サービスへの攻撃プロファイルを減らすことができます。

  • WSDL へのアクセスを制限していますか。
    生成された .WSDL ファイルを Web サーバーにストアして利用者へ配布している場合、ファイルが適切な ACL によって保護されていることを確認します。この保護は、悪意のあるユーザーにより WSDL が更新または置き換えられて、意図した URL と異なるエンドポイントを示すことを防ぎます。

  • SOAP 要求または応答で機密性の高いデータを渡しますか。
    Web サービスが機密性の高いデータを処理する場合、どのようにそのデータをネットワークで保護し、ネットワーク盗聴の脅威に対処していますか。SSL または IPSec 暗号化チャネルを使用、あるいはメッセージ部分を XML 暗号化を使用して暗号化していますか。

  • 呼び出し元をどのように認証していますか。
    Web サービスが制限付きの操作またはデータを公開する場合、呼び出し元の認証を行って承認をサポートする必要があります。Web サービスがどのようにクライアントを認証しているかを確認します。

  • SOAP ヘッダーの資格情報を渡しますか。
    SOAP ヘッダーの資格情報を渡す場合、プレーンテキストで渡しますか。プレーンテキストで渡す場合、暗号化されたチャネルが使用されていることを確認します。

Enterprise Services

ここでは、Enterprise Services アプリケーションおよびコンポーネントのレビューで考慮しなくてはならない重要なレビュー ポイントを説明します。このセクションで取り上げた問題の詳細については、モジュール 17「アプリケーション サーバーをセキュリティ保護する」を参照してください。

Enterprise Services アプリケーションをレビューする場合、以下を考慮してください。

  • アカウント

  • ファイルとディレクトリ

  • 認証

  • 承認

  • リモート サービス対象のコンポーネント

アカウント

Enterprise Services サーバー アプリケーションを使用する場合、どのアカウントを使用してアプリケーションを実行するのかを確認します。アカウントは [コンポーネント サービス] のアプリケーションの [プロパティ] ダイアログ ボックスの [ID] ページに表示されます。次のレビュー項目を確認してください。。

  • 最低限の権限を持つアカウントを使用していますか。
    Enterprise Services サーバー アプリケーションの実行に使用するアカウントが、ユーザー権利およびアクセス権を制限された最低限の権限を持つアカウントに構成されていることを確認します。プロセス アカウントを使用して下流データベースにアクセスする場合、データベース ログオンがデータベースに制限されていることを確認します。

  • 対話型アカウントを使用していますか。
    対話型アカウントを運用サーバーで使用しないでください。このアカウントは開発およびテスト期間のみ使用します。

ファイルとディレクトリ

以下の質問を検討して、NTFS アクセス許可を適切に適用して、さまざまな Enterprise Services アプリケーション関連ファイルをセキュリティ保護していることを確認します。

  • COM+ カタログがセキュリティ保護されていますか。
    COM+ カタログは COM+ アプリケーションの構成データを保持します。カタログ ファイルを保持する以下のフォルダが、ACL で制限された構成になっていることを確認します。

    %windir%\registration

    次の ACL を構成します。

    Administrators:Read, Write
System:Read, Write
Enterprise Services Run-As Account(s):Read

  • CRM ログ ファイルがセキュリティ保護されていますか。
    アプリケーションが Compensating Resource Manager を使用している場合、ログ ファイルが機密性の高いデータを含む可能性があるため、CRM ログ ファイル (.crmlog) は NTFS アクセス許可でセキュリティ保護される必要があります。

  • アプリケーションの DLL がセキュリティ保護されていますか。
    アプリケーションの DLL を保持するフォルダが以下の ACL で制限された構成になっていることを確認します。

    Users:Execute
Application Run as account:Execute
Administrators: Read, Write and Execute

    詳細については、モジュール 17「アプリケーション サーバーをセキュリティ保護する」を参照してください。

認証

サービス対象のコンポーネントは、クライアントのプロセス アドレス空間で実行されるライブラリ アプリケーション、または Dllhost.exe. の別のインスタンスで実行されるサーバー アプリケーションでホストされます。どちらであるかは、[コンポーネント サービス] のアプリケーションの[プロパティ] ダイアログ ボックスの [アクティブ化] ページで指定される [アクティブ化の種類] によって決まります。Enterprise Services ライブラリ アプリケーションのクライアント プロセスは通常 ASP.NET Web アプリケーション プロセスです。

以下の設定は、[コンポーネント サービス] のアプリケーションの [プロパティ] ダイアログ ボックスの [セキュリティ] ページで指定します。

サーバー アプリケーション

[アクティブ化の種類] が [サーバー アプリケーション] に設定されている場合は、以下の質問を検討します。

  • 匿名アクセスを防いでいますか。
    アプリケーションが呼び出しレベル以上の認証を使用しており、クライアントがメソッドの呼び出しごとに認証されることを確認します。このことにより、匿名アクセスを防ぎます。

  • どの偽装レベルを使用していますか。
    識別レベル以上の偽装を使用して下流システムのサービス コンポーネントの識別を許可していることを確認します。既定では、これがアプリケーションのアカウントとして実行して決定されるプロセス ID に設定されています。サービス対象のコンポーネントの偽装がプログラムによる場合、ID は偽装されていないことがあります。下流システムがサービス対象のコンポーネントの ID を使用してリモート リソースにアクセスできるようにしたい場合のみ、委任レベルを使用します。

ライブラリ アプリケーション

アクティブ化の種類がライブラリ アプリケーションに設定されている場合、認証および偽装の設定はホスト プロセスから継承されます。ここでのレビュー項目は、ASP.NET プロセスがホスト プロセスであると前提しています。

  • 認証を無効にしていますか。
    確認するには、アプリケーションの [プロパティ] ダイアログ ボックスの [セキュリティ] ページで [認証を有効にする] チェック ボックスを表示します。リモート サービス対象のコンポーネントから認証されていないコールバックを処理するなどの特定の要件がない限り、認証を無効にしないでください。

  • どの認証レベルを使用しますか。
    Machine.config の <processModel> 要素で指定される認証レベルは、リモート サービス コンポーネントまたは DCOM コンポーネントへの発信呼び出しに使用されます。この値とリモート サーバーで設定される値の、高い方が使用されます。<processModel> 要素の comAuthenticationLevel 設定を次のように確認します。

  • どの偽装レベルを使用しますか。
    この値は、ライブラリ コンポーネントから他のリモート コンポーネントへの発信呼び出しに影響します。Machine.config の <processModel> 要素で comImpersonationLevel 属性を確認します。

    <processModel comImpersonationLevel=
"Default|Anonymous|Identify|Impersonate|Delegate" .../>

承認

Enterprise Services アプリケーションのサービス対象のコンポーネントは、COM+ ロール ベースのセキュリティを使用して呼び出し元を承認します。以下の事項を検討して、適切な承認を行います。

  • アクセス確認が有効になっていますか。
    この設定は、COM+ 承認を有効にするかどうかを制御します。[コンポーネント サービス] のアプリケーションの[プロパティ] ダイアログ ボックスの [セキュリティ] ページで [このアプリケーションへのアクセス確認を行う] が選択されていることを確認します。

  • どのセキュリティ レベルを使用しますか。
    [コンポーネント サービス] のアプリケーションの[プロパティ] ダイアログ ボックスの [セキュリティ] ページで [セキュリティ レベル] を確認します。アプリケーションがプロセス レベルおよびコンポーネント レベルのアクセス確認を使用して、細かい承認をサポートしている必要があります。このことにより、特定のクラス、インターフェイス、およびメソッドへのアクセスを、アプリケーションがロールを使用して制御できるようになります。

    注: ライブラリ アプリケーションでは、プロセス レベルおよびコンポーネント レベルでのアクセス確認が有効になっていることが必要です。有効になっていない場合、ロール ベースの承認を使用できません。

  • コンポーネント レベルのアクセス確認を行う設定にしていますか。
    コンポーネント、インターフェイス、およびメソッド レベルでの承認確認をサポートするため、各コンポーネントは COM+ カタログで適切に構成される必要があります。アプリケーションの各コンポーネントについて、コンポーネントの[プロパティ] ダイアログ ボックスの [セキュリティ] ページで [プロセスおよびコンポーネント レベルでのアクセス確認を行う] が選択されているようにします。

リモート サービス対象のコンポーネント

以下の事項は、リモート サービス対象のコンポーネントを使用してネットワーク通信を行う場合に適用されます。一般的なシナリオは、リモート アプリケーション サーバーの Enterprise Services アプリケーションと通信する ASP.NET クライアントです。

  • 機密性の高いデータを渡しますか。
    その場合、どのようなメカニズムを使用してネットワーク盗聴の脅威に対処しますか。クライアントとサーバー間のリンクが IPSec などのトランスポート レベルで暗号化されていることを確認します。代わりに、Enterprise Services アプリケーションを Packet Privacy 認証レベルに構成します。この認証レベルは、アプリケーションとの送受信のすべてのデータ パケットを RPC で暗号化します。

  • 通信にファイアウォールを使用していますか。
    Enterprise Services は DCOM を使用し、DCOM はさらにに RPC を使用して通信します。RPC による通信にはファイアウォールの ポート 135 が開いていることが必要です。ファイアウォールおよび Enterprise Services の構成を確認して、最小限の追加のポートが開いていることを確認します。

    DCOM によって動的に割り当てられるポートの範囲を制限することができます。また、静的エンドポイント マッピングをそれぞれのポートに指定することもできます。詳細については、モジュール 17「アプリケーション サーバーをセキュリティ保護する」を参照してください。

Remoting

ここでは、アプリケーションの .NET Remoting の使用方法のレビューで考慮しなくてはならない重要なレビュー ポイントを説明します。このセクションで取り上げた問題の詳細については、モジュール 17「アプリケーション サーバーをセキュリティ保護する」を参照してください。

.NET Remoting ソリューションをレビューする場合、まずどのホストを使用してリモート コンポーネントを実行しているかを識別します。"HttpChannel" を介して ASP.NET ホストを使用する場合、IIS および ASP.NET のセキュリティが、適切な認証、承認、およびセキュリティ保護されたサービスをリモート コンポーネントに提供する構成になっていることを確認する必要があります。カスタムのホストを "TcpChannel" を介して使用する場合、このホストとチャネルの組み合わせにはカスタム認証および承認ソリューションが必要なため、コンポーネントがどのようにセキュリティ保護されるかを確認する必要があります。

ポートに関する考慮事項

Remoting は、インターネット クライアントに使用する設計になっていません。コンポーネントのリスン状態のポートに、インターネット クライアントから直接アクセスできないことを確認します。ポートは、通常サーバー側の構成ファイルの <channel> 要素で指定されます。

HttpChannel を介して ASP.NET をホストする

ASP.NET ホストを使用する場合、以下の項目を検討してください。

  • 機密性の高いデータをどのようにネットワークで保護しますか。
    SSL または IPSec を使用しますか。SSL または IPSec を使用しない場合、リモート コンポーネントとの送受信データは、情報の改ざんや漏えいの危険にさらされます。ネットワーク盗聴の脅威への対処にどのような手段がとられているかを確認します。

  • 呼び出し元をどのように認証していますか。
    アプリケーションの仮想ディレクトリの IIS で匿名アクセスを無効にしていることを確認します。Windows 認証を使用していることも確認します。アプリケーションの Web.config に以下の構成が含まれる必要があります。

    <authentication mode="Windows" />

  • ASP.NET のファイル承認を使用していますか。
    使用していない場合、なぜですか。.rem または .soap ファイルを作成し、そのファイルに NTFS アクセス許可を設定することにより、Remoting アプリケーションのエンドポイントへのアクセスを制御する ASP.NET のファイル承認を使用できます。次に ASP.NET FileAuthorizationModule が、コンポーネントへのアクセスを承認します。詳細については、モジュール 13「セキュリティ保護されたリモート コンポーネントを構築する」の「承認」を参照してください。

  • URL 承認を使用していますか。
    アプリケーションが <authorization> 要素を使用していることを確認します。<allow> および <deny> タグを適用して ASP.NET UrlAuthorizationModule を使用します。

  • 詳細なエラー情報がクライアントに返されるのを防いでいますか。
    アプリケーションの構成を確認して、詳細なエラー情報をクライアントに返さないように <customErrors> 要素が正しく設定されていることを確認します。以下に示すように、mode 属性が "On" に設定されていることを確認します。

    <customErrors mode="On" />

  • どの ID を使用して ASP.NET を実行しますか。
    既定の ASPNET アカウント、または Windows Server 2003 のNetwork Service アカウントなど、最低限の権限を持つアカウントを使用して ASP.NET を実行していることを確認します。

TcpChannel を介して カスタム プロセスをホストする

Windows サービスなどのカスタム ホスト プロセスを使用する場合、以下の項目を検討してください。

  • 機密性の高いデータをどのようにネットワークで保護しますか。
    クライアントからサーバーへのチャネルをセキュリティ保護していますか。トランスポート レベルの IPSec 暗号化を使用、またはアプリケーションにカスタム暗号化シンクを使用して、要求および応答データを暗号化することができます。

  • 呼び出し元をどのように認証していますか。
    "TcpChannel" には認証メカニズムがないため、自分で開発する必要があります。アプリケーションがどのように呼び出し元を認証しているかを確認してください。

  • クライアントを制限していますか。
    "TcpChannel" を介した Remoting は、リモート コンポーネントがそのクライアントを信頼する信頼関係にあるサーバー シナリオで使用される設計になっています。IPSec ポリシーを適用するなどして、リモート コンポーネントに接続できるクライアントの範囲を制限していますか。

  • 最低限の権限を持つプロセス ID を使用していますか。
    カスタム ホスト プロセスを実行する際にどのアカウントを使用しているか確認し、そのアカウントが最低限の権限を持つアカウントとして構成されていることを確認します。

データベース サーバーの構成

レビューのこの段階での目標は、SQL Server データベース サーバーの構成の脆弱性を識別することです。このセクションのレビュー項目で取り上げた事項の背景情報については、モジュール 18「データベース サーバーをセキュリティ保護する」を参照してください。

レビュー プロセスに焦点を当てて構築できるように、レビュー項目は以下の構成カテゴリに分かれています。

  • 修正プログラムと更新

  • サービス

  • プロトコル

  • アカウント

  • ファイルとディレクトリ

  • 共有

  • ポート

  • レジストリ

  • 監査とログ記録

  • SQL Server のセキュリティ

  • SQL Server のログオン、ユーザー、およびロール

修正プログラムと更新

サーバーが最新の Service Pack およびソフトウェア修正プログラムで更新されていることを確認します。確認対象には、オペレーティング システムおよび SQL Server の Service Pack および修正プログラムも含まれます。

必ず MBSA (Microsoft Baseline Security Analyzer) ツールを実行して、一般的な Windows と SQL Server の脆弱性、および Service Pack と修正プログラムの不足について確認してください。

MBSA の出力に応じて見つかった脆弱性を修正し、最新の修正プログラムや更新をインストールします。詳細については、モジュール 18「データベース サーバーをセキュリティ保護する」の「手順 1: 修正プログラムと更新」を参照してください。

サービス

必要なサービスのみが有効になっていることを確認します。サーバーが攻撃を受ける危険性を軽減するため、他のサービスがすべて無効になっていることを確認します。

  • どの SQL Server サービスを実行しますか。
    SQL Server は 4 つのサービスをインストールします。基本機能のみが必要な場合、Microsoft Search、MSSQLServerADHelper、および SQLServerAgent を無効にしてサーバーが攻撃を受ける危険性を軽減します。

  • 分散トランザクションを使用していますか。
    アプリケーションが COM+ のトランザクション サービスを使用して SQL Serverのトランザクションを管理する場合、データベース サーバーには DTC (Microsoft Distributed Transaction Coordinator) サービスが必要です。

    分散トランザクションを使用しない場合、DTC サービスが無効になっていることを確認します。

プロトコル

不要なプロトコルを使用しないことにより、攻撃を受ける危険性を軽減します。次のレビュー項目を確認してください。

  • SQL Server 用にどのプロトコルが構成されていますか。
    SQL Server は複数のプロトコルをサポートします。Server Network Utility を使用して、TCP/IP プロトコルのサポートのみが有効になっていることを確認します。

  • TCP/IP スタックを強化しましたか。
    サーバーのスタックが強化されているかどうかを確認するには、Regedt32.exe を使用して以下のレジストリ キーを調べます。

    HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    以下の子キーが存在する場合、TCP/IP スタックは強化されています。
    SynAttackProtect、EnableICMPRedirect、および EnableReadGWDetect

    必要なキー、および最大限にセキュリティを強化したスタックの適切なキー値の完全なリストについては、このガイドの「[HOWTO] TCP/IP スタックを強化する方法」を参照してください。

アカウント

以下の質問に答えて、データベース サーバーで使用されているアカウントを確認してください。

  • 最低限の権限を持つアカウントを使用して SQL Server を実行していますか。
    SQL Server を実行する際にどのアカウントを使用しているか確認し、そのアカウントが最低限の権限を持つアカウントであることを確認します。管理者アカウントまたは強力なローカル システム アカウントは使用しないでください。また、そのアカウントがローカル コンピュータの Users グループのメンバでないことも確認します。

  • 使用していないアカウントを削除または無効にしていますか。
    サーバーのローカル アカウントを監査し、使用していないアカウントがすべて無効になっていることを確認します。

  • Guest アカウントを無効にしていますか。
    Windows の "Guest" アカウントが無効になっており、データベース サーバーへの匿名の接続を制限していることを確認します。

  • 新しい管理者アカウントを作成しましたか。
    ローカルの既定の Administrator アカウントは、絶好の攻撃目標となります。セキュリティを向上させるため、管理目的の新しいカスタム アカウントを作成し、既定の Administrator アカウントを無効にしていることを確認します。

  • 強力なパスワード ポリシーを使用していますか。
    [ローカル セキュリティ設定] ツールで [パスワードのポリシー] を確認します。推奨されるパスワードのポリシーの詳細については、モジュール 18「データベース サーバーをセキュリティ保護する」の「手順 4: アカウント」を参照してください。

  • リモート ログオンを制限していますか。
    [ローカル セキュリティ設定] ツールの [ユーザー権利の割り当て] で、[ネットワーク経由でコンピュータへアクセス] が [Everyone] グループに設定されていないことを確認します。

  • NULL セッションを無効にしていますか。
    NULL セッションが無効になっており、匿名 (認証されていない) セッションがサーバーで作成されないようになっていることを確認します。これを確認するには、Regedt32.exe を実行して、"RestrictAnonymous" キーが以下に示すように "1" に設定されていることを確認します。

    HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

  • クライアントは Windows 認証を使用して接続を行いますか。
    その場合、NTLM 認証 (NTLMv2) の最も強力なバージョンが有効になっており、実行されていることを確認します。NTLMv2 認証が実行されていることを確認するには、ローカル セキュリティ ポリシー ツールを使用します。[ローカル ポリシー] を展開し、[セキュリティ オプション] を選択したら [LAN Manager 認証レベル] をダブルクリックします。[NTLMv2 応答のみ送信\LM と NTLM を拒否する] が選択されていることを確認します。

ファイルとディレクトリ

以下のレビュー項目を検討し、NTFS アクセス許可をデータベース サーバーで適切に使用していることを検証します。

  • SQL Serverインストール ディレクトリにアクセス許可を設定していますか。
    SQL Serverインストール ディレクトリのアクセス許可を確認して、アクセス許可が限定されたアクセスに付与されていることを確認します。アクセス許可の詳細については、モジュール 18「データベース サーバーをセキュリティ保護する」の「手順 5: ファイルとディレクトリ」を参照してください。

  • SQL Server ファイルに対する Everyone グループのアクセス許可を削除しましたか。
    SQL Server ファイルの場所 (既定では \Program Files\Microsoft SQL Server\MSSQL) に対するアクセス許可を確認し、"Everyone" グループが ACL のディレクトリから削除されていることを確認します。また、フル コントロールが SQL のサービス アカウントである "Administrators" グループ、およびローカル システム アカウントにだけ付与されていることも確認します。

  • セットアップ ログ ファイルがセキュリティ保護されていますか。
    SQL Server 2000 Service Pack 1 または 2 をインストールした場合、システム管理者またはサービス アカウントのパスワードが SQL インストール ディレクトリに残っている可能性があります。Killpwd.exe ユーティリティを使用してログ ファイルからパスワードのインスタンスを削除したことを確認します。

    このユーティリティの取得および使用方法については、マイクロソフト サポート技術情報の 263968「[FIX] Service Pack インストール時に標準セキュリティのパスワードが保存される 」を参照してください。

共有

以下の質問を検討し、サーバーが共有ファイルの存在によって不必要に公開されないようにしてください。

  • サーバーで何が共有になっていますか。
    コンピュータの管理 MMC スナップインで [共有フォルダ] の下の [共有] を選択して、共有および関連アクセス許可を確認します。すべての共有が必要であることを確認します。不要な共有はすべて削除します。

  • Everyone グループが共有にアクセスできますか。
    "Everyone" グループは指定されない限り共有にアクセスできないこと、その代わりに特定の許可が設定されていることを確認します。

  • 管理用共有を削除しましたか。
    サーバーのリモート管理を許可していない場合は、C$ や IPC$ などの管理用共有が削除されていることを確認します。

    注: 管理用共有が必要なアプリケーションもあります。Microsoft Systems Management Server (SMS)、 Microsoft Operations Manager (MOM) などがその例です。詳細については、マイクロソフト サポート技術情報の 318751「HOW TO: Windows 2000 または Windows NT 4.0 で管理用共有を削除します。」を参照してください。

ポート

サーバーでアクティブなポートを確認して、不要なポートが利用可能でないことを確認します。netstat コマンドを使用して行うこの確認の詳細については、このモジュールの「Web サーバーの構成」の「ポート」を参照してください。次に、以下の質問を検討します。

  • SQL Server のポートへのアクセスを制限していますか。
    SQL Server のポートへのアクセスをどのように制限しているか確認します。境界ファイアウォールがインターネットからの直接アクセスを防いでいることを確認します。内部からの攻撃を防御するため、IPSec ポリシーを確認して、ポリシーが SQL Server のポートへのアクセスを制限していることを確認します。

  • 名前付きのインスタンスが同じポートでリスンする構成になっていますか。
    名前付きのインスタンスを使用する場合、Network Server Utility を使用してインスタンスが特定のポートでリスンする構成になっていることを確認します。このことにより、クライアントサーバー間の UDPネゴシエーションを回避することができるため、追加のポートを開く必要がなくなります。

レジストリ

以下の質問を検討して、レジストリ構成のセキュリティを確認します。

  • SQL Server のレジストリ キーがセキュリティ保護されていますか。
    Regedt32.exe を使用して、Everyone グループが、以下のレジストリ キーの ACL から削除されていることを確認します。

    Administrators:Full Control
SQL Server service account:Full Control

  • SAM をセキュリティ保護していますか。
    以下に示すようにレジストリの キー (値ではありません) に "NoLMHash" を設定して、セキュリティ アカウント マネージャ (SAM) の LMHash ストレージを制限していることを確認します。

    HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

    詳細については、マイクロソフト サポート技術情報の 299656「How to Prevent Windows from Storing a LAN Manager Hash of Your Password in Active Directory and Local SAM Databases」(英語) を参照してください。

監査とログ記録

以下のレビュー項目を検討し、監査とログ記録をデータベース サーバーで適切に使用していることを検証します。

  • SQL Server 監査を有効にしましたか。
    SQL Server 監査を有効