セキュリティのためのアーキテクチャと設計レビュー

トピック

 モジュールの内容
 目的
 適用対象
 モジュールの使用方法
 アーキテクチャと設計レビュー プロセス
 展開およびインフラストラクチャに関する考慮事項
 入力検証
 認証
 承認
 構成管理
 機密性の高いデータ
 セッション管理
 暗号化
 パラメータ改ざん
 例外管理
 監査とログ記録
 要約
 その他のリソース

モジュールの内容

セキュリティで保護された Web アプリケーションを構築するには、適切なアーキテクチャと設計が必要です。開発が済んでしまってからセキュリティを改良するのでは、コストと労力がかかりすぎます。アーキテクチャと設計レビューによって、開発段階に入る前に、アプリケーションのセキュリティ関連の設計機能を検証することができます。これによって、潜在的な脆弱性が悪用される前に、また修正に膨大なリエンジニアリング作業が要求される前に、こうした脆弱性を識別し、修正することができます。

このモジュールでは、アーキテクチャの設計を徹底的に見直す場合の質問事項について説明します。既にアプリケーションを作成済みの場合でも、このモジュールを読んで、アプリケーション設計時に使用した概念、原則、技術を再検討する必要があります。

目的

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

• アーキテクチャの設計を徹底的に見直す場合の質問事項について把握する。

• Web アプリケーションのアーキテクチャと設計を分析する。

• 現在のセキュリティ レビューの手法を開発および改良する。

• 設計段階で脆弱性を修正するプロセスを作成する。

• 主要なアプリケーション展開とインフラストラクチャのセキュリティ検討事項を識別する。

• 円滑で安全な Web アプリケーション展開を保証します。

適用対象

Web アプリケーション

モジュールの使用方法

モジュールの効果的な使用方法

• セキュリティ レビューをアーキテクチャの設計プロセスに統合します。できるだけすぐに開始します。さらに、設計が変更されたら、このモジュールで説明する手順を使って、変更を見直します。

• セキュリティ レビュー方法を開発します。このモジュールでは、設計のセキュリティを改善する場合の質問事項について説明します。確認プロセスを完了する前に、アプリケーション固有の質問事項がある場合は、それを追加する必要があります。

• 潜在的な脅威について理解します。モジュール 2「脅威とその対策」に、アプリケーションを構成するさまざまなコンポーネントと層に影響する脅威の一覧を示します。レビュー プロセスの結果を改善するには、これらの脅威について理解することが必要です。

アーキテクチャと設計レビュー プロセス

アーキテクチャと設計レビュー プロセスでは、セキュリティの観点からアーキテクチャと設計の分析を行います。設計を完了したばかりの場合には、設計ドキュメントがこのプロセスに役立ちます。設計ドキュメントがどの程度包括的であるかに関わらず、アプリケーションを分解し、信頼境界、データ フロー、エントリ ポイント、特権を持つコードを含む主要なアイテムを識別できる必要があります。さらに、アプリケーションの物理的な展開構成についても知る必要があります。最も共通して脆弱性が見られるこれらの分野に採用した設計手法に注意してください。このガイドでは、これらの分野をアプリケーション脆弱性カテゴリと呼んでいます。

アプリケーションのアーキテクチャと設計を再確認する場合は、次の側面について検討します。

• 展開とインフラストラクチャ: 対象となる展開環境と関連付けられたセキュリティ ポリシーとの関連でアプリケーション設計の再確認を行います。さらに、基底にあるインフラストラクチャ層のセキュリティによって課される制約についても検討します。

• アプリケーションのアーキテクチャと設計: 認証、承認、入力検証、例外管理などが含まれる、アプリケーションの重要な領域へのアプローチを再確認します。アプリケーション脆弱性カテゴリをロードマップとして使用し、レビュー中に重要な分野の見落としがないことを確認することができます。

• 各層ごとに分析: アプリケーションの論理層をひととおり調べ、ASP.NET Web ページとコントロール、Web サービス、受信したコンポーネント、Microsoft .NET Remoting、データ アクセス コードなどのセキュリティを検証します。

図 5.1 に、このような 3 つに分かれたレビュー プロセスのアプローチを示します。

図 5.1
アプリケーション レビュー

このモジュールの残りの部分では、上記の各分野に対するレビュー プロセス時に確認する主な考慮事項と質問について説明します。

展開およびインフラストラクチャに関する考慮事項

基底にあるネットワークとホストのインフラストラクチャがアプリケーションに提供するセキュリティ設定について考察し、ターゲット環境によって課される制限について調べます。展開トポロジと中間層アプリケーション サーバー、境界ゾーン、および内部ファイアウォールによる設計上の影響についても検討します。

次の質問を確認して、展開とインフラストラクチャの潜在的な問題を識別します。

• ネットワークはセキュリティで保護された通信を提供していますか

• 展開トポロジには内部ファイアウォールが含まれていますか

• 展開トポロジにはリモート アプリケーション サーバーが含まれていますか

• インフラストラクチャのセキュリティに必要な制限は何ですか

• Web ファーム問題について検討しましたか

• ターゲット環境がサポートする信頼レベルは何ですか

ネットワークはセキュリティで保護された通信を提供していますか

クライアントとサーバー間、またはサーバー間でやり取りされている間、データは最も脆弱な状態にあります。データのプライベートな部分はどの程度にする必要がありますか。あなたは顧客データに法的な責任がありますか。

アプリケーションはデータ伝送の前に、データを安全に処理したり、変換する責任がありますが、ネットワークはデータ送信の際にデータの完全性とプライバシーを保護する責任があります。データをプライベートにしておく必要がある場合は、適切な暗号化アルゴリズムを使用してください。さらに、ネットワークの整合性を維持するため、ネットワーク デバイスがセキュリティで保護されていることを確認します。

展開トポロジには内部ファイアウォールが含まれていますか

内部のファイアウォールが Web サーバーをアプリケーション サーバー、またはデータベース サーバーと区別している場合は、次の質問を検討して、これに対応した設計になっていることを確認してください。

• ダウンストリーム サーバーは Web サーバーをどのように認証しますか

  ドメイン アカウントと Windows 認証を使用する場合、ファイアウォールは必要なポートを開きますか。ポートを開かない場合、あるいは、Web サーバーとダウンストリーム サーバーが別々のドメインにある場合、ミラーリングしたローカル アカウントが使用できます。たとえば、データベース サーバー上で Web アプリケーションを実行するために使用される、最小限の権限を持つローカル ASPNET アカウントを二重化することができます。

• 分散されるトランザクションを使用しますか

  Web サーバーが Microsoft Distributed Transaction Coordinator (DTC) のサービスを使用して分散されるトランザクションを起動する場合、内部のファイアウォールが DTC 通信に必要なポートを開きますか。

  ファイアウォール経由した DTC の使用法の詳細については、マイクロソフト サポート技術情報の 250367「[INFO] MS DTC をファイアウォール経由で動作可能にする」(http://support.microsoft.com/default.aspx?scid=kb;ja;250367) を参照してください。

展開トポロジにリモート アプリケーション サーバーが含まれていますか

展開トポロジに物理的なリモート中間層が含まれる場合は、次の質問を検討してください。

• Enterprise Services を使用しますか
  使用する場合は、DCOM ポート範囲を制限した上で、内部ファイアウォールでこれらのポートを開きますか。

  注: 状況によっては、中層の Web サービスを Enterprise Services アプリケーションのフロントエンドとして使用するのが優れた設計の選択といえます。このアプローチを使用する場合、Web サーバーは Simple Object Access Protocol (SOAP) を使用し、ポート 80 経由でアプリケーション サーバーと通信することができます。

  詳細については、次の マイクロソフト サポート技術情報を参照してください。

  • 技術情報の 312960「[PRB] COM+ アプリケーションのエンドポイントを静的にできない」(http://support.microsoft.com/default.aspx?scid=kb;ja;312960)

  • 技術情報の 259011 の単純な DCOM クライアント サーバー テスト アプリケーションに関する情報 (http://support.microsoft.com/default.aspx?scid=kb;ja;259011)

  • 技術情報の 248809「[PRB] NAT ベースのファイアウォール越しに DCOM が機能しない」(http://support.microsoft.com/default.aspx?scid=kb;ja;248809)

  • 技術情報の 154596「[HOWTO] ファイアウォールで動作するように RPC の動的ポート割り当てを構成する方法」(http://support.microsoft.com/default.aspx?scid=kb;ja;154596)

• .NET Remoting を使用しますか
  Remoting は、信頼されたサーバー状況で使用されるように設計します。ネットワークでは、Web サーバーだけが中間層の Remoting コンポーネントにアクセスできるようにする IPSec ポリシーをサポートしていますか。ASP.NET は、認証と承認に対応するため、リモート コンポーネントをホストしますか。

• Web サービスを使用しますか
  使用する場合、中間層の Web サービスはどのように Web アプリケーションを認証しますか。Web アプリケーションは、Web サービスが Web サーバーを認証できるように Web サービス プロキシ上に資格情報を構成しますか。そうでない場合、Web サービスは呼び出し元を識別しますか。

インフラストラクチャのセキュリティに必要な制限は何ですか

設計上、ホスト インフラストラクチャのセキュリティ制限が無効になることを仮定していますか。たとえば、必要なサービス、プロトコル、またはアカウント特権の可用性に基づいて、セキュリティ制限に設計上のトレードオフが必要な場合があります。次の質問を検討します。

• 使用できない可能性のあるサービス、またはプロトコルに依存していますか
  開発およびテスト環境で使用できるサービスとプロトコルは、運用環境で使用できない可能性があります。制限と要件を理解するには、インフラストラクチャ セキュリティを担当するチームに連絡します。

• 機密性の高いアカウント特権に依存していますか
  設計には、最小限の特権を持つプロセス、サービス、ユーザー アカウントを使用していますか。許可されない可能性のある機密性の高い特権を必要とするオペレーションを実行しますか。

  たとえば、アプリケーションがスレッド レベルの偽装トークンを作成して、リソース アクセスのためのサービス ID を作成する必要がありますか。この場合は、"オペレーティング システムの一部として機能" 特権が必要です。この特権は、プロセス侵害に関連したセキュリティ リスクが高まるため、Web サーバー プロセスには付与しないでください。この機能が必要な場合、高い特権を、たとえばアウト プロセス Enterprise Services アプリケーションで区切る必要があります。

Web ファーム問題について検討しましたか

アプリケーションを Web ファームに展開する場合、ファーム内のどのサーバーがクライアント要求を処理するかについて予想することはできません。同じクライアントからの継続的な要求は、別々のサーバーで提供される可能性があります。したがって、次の問題について検討する必要があります。

• セッション状態をどのように管理していますか
  Web ファームでは、Web サーバー上でセッション状態を管理することができません。その代わりに、ファーム内のすべての Web サーバーからアクセスされるサーバー上のリモート状態ストアを設計に組み込む必要があります。詳細については、このモジュールで後述する「セッション管理」を参照してください。

• マシン固有の暗号化キーを使用しますか
  データベースなどの共有データ ソースのデータの暗号化に暗号化機能を使用する場合、暗号化キーと解読キーはファーム内のすべてのマシンで同一にする必要があります。設計上、マシン関係を要求する暗号化メカニズムが不要なことを確認してください。

• フォーム認証、または保護された表示状態を使用しますか
  いずれかを使用する場合は、 <machine key> 設定に依存します。Web ファーム内では、すべてのサーバーで共通のキーを使用しなければなりません。

• SSL (Secure Sockets Layer) を使用しますか
  SSL を使用してブラウザと Web サーバー間のトラフィックを暗号化する場合は、SSL 接続をどこで終端しますか。オプションには、Web サーバー、アクセラレータ カードを装備した Web サーバー、またはアクセラレータ カードを装備したロード バランサがあります。通常、SSL セッションをアクセラレータ カードを装備したロード バランサで終端させると、特に多数の接続を持つサイトの場合に最大のパフォーマンスを実現します。

  SSL をロード バランサで終端させると、ロード バランサから Web サーバーに向かうネットワーク トラフィックは暗号化されません。つまり、ロード バランサと Web サーバー間でデータがやり取りされている間、攻撃者はデータを解読してから、ネットワーク トラフィックをスニフィングすることが潜在的に可能です。こうした脅威は、Web サーバー環境を物理的にセキュリティで保護するようにすること、または IPSec ポリシーが提供するトランスポートレベルの暗号化機能を使用し、内部のデータ センター リンクを保護することによって対処できます。

ターゲット環境がサポートする信頼レベルは何ですか

ターゲット環境のコード アクセスのセキュリティ信頼レベルによって、コードがアクセスできるリソースと、特権を持つ実行可能な処理が決定します。ターゲット環境でサポートされている信頼レベルを確認してください。Web アプリケーションが完全信頼で動作することを許可されている場合、コードはあらゆるリソースにアクセスできますが、オペレーティング システムのセキュリティによります。

Web アプリケーションが低い信頼レベルで動作しなければならない場合、リソースの種類と特権を持つ実行可能な処理のタイプが限定されます。部分的な信頼レベル状況では、特権を持つコードを設計上サンドボックスする必要があります。さらに、別のアセンブリを使用して、特権を持つコード分離します。これは、特権を持つコードをアプリケーションのその他の部分と区別して構成し、必要な追加コード アクセス許可を付与できるようにするためです。

詳細については、モジュール 9「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。

注: アプリケーションを共有サーバー上で展開する計画の場合、またはアプリケーションがホスティング企業によって運用される場合、信頼レベルが頻繁に問題になります。これらの場合、セキュリティ ポリシーを確認して、Web アプリケーションに指定する信頼レベルを調べます。

入力検証

多くの Web アプリケーション攻撃では故意に無効な入力が使用されることから、アプリケーションによって入力を検証する方法を考察します。不完全な入力検証は、SQL 挿入、クロスサイト スクリプト (XSS)、バッファ オーバーフロー、コード挿入など多数のサービス拒否と権限の不正取得攻撃によって悪用されるおそれがあります。表 5.1 に、入力検証に関連する最も一般的な脆弱性を示します。

表 5.1: 一般的な入力検証の脆弱性

脆弱性	影響
Hypertext Markup Language (HTML) 出力ストリーム内の検証されていない入力	アプリケーションは XSS 攻撃を受けやすくなっています。
SQL クエリの生成に使用された検証されていない入力	アプリケーションは SQL 挿入攻撃を受けやすくなっています。
クライアント側の検証に依存	クライアント検証は容易に回避されます。
セキュリティの決定に入力ファイル名、URL、ユーザー名を使用	アプリケーションは、セキュリティの短所につながる正規化のバグの影響を受けやすくなっています。
悪意のある入力に対するアプリケーションだけのフィルタ	潜在的に悪意のある入力の範囲は膨大なため、アプリケーションだけで適切にフィルタリングすることはほとんど不可能です。入力を制限、拒否したり、校正します。

潜在的な入力検証セキュリティの問題を特定するのに役立つ、次の質問を確認します。

• どのように入力を検証しますか。

• 入力を使用して何を実行しますか。

どのように入力を検証しますか

設計ではどの入力検証アプローチを指定しますか。まず、設計によって戦略を計画する必要があります。アプリケーションは、受信したすべての入力を制限、拒否、校正する必要があります。既知の有効なタイプ、パターン、および範囲を確認するデータ検証は、既知の不正な文字を検索することによるデータ検証よりも簡単に行えるため、入力の制限が最善の方法です。多層防御戦略を使用する場合も、既知の不正な入力を拒否し、入力を校正する必要があります。

次の質問は、潜在的な脆弱性を特定するのに役立ちます。

• エントリ ポイントについて知っていますか
  個々の入力フィールドで発生するイベントを追跡できるように、アプリケーションのエントリ ポイントを識別する設計になっていることを確認してください。Web ページ入力、コンポーネントおよび Web サービスに対する入力、データベースからの入力を検討します。

• 信頼境界について知っていますか
  信頼境界の内部にある信頼された送信元から渡される入力であれば、入力検証は必ずしも必要ではありません。ただし、信頼されていない送信元から渡された入力には、入力検証の検討が必須です。

• Web ページの入力を検証しますか
  エンド ユーザーを信頼されたデータ ソースとして見なさないでください。標準のフォーム フィールドと非表示のフォーム フィールド、クエリ文字列、Cookie を検証することを確認してください。

• コンポーネント、または Web サービスに渡される引数を検証しますか
  これらの引数を検証しなくても安全な場合は、データが現在の信頼境界の内部から受信される場合だけです。ただし、多層防御戦略の場合には複数の検証層を推奨します。

• データベースから取得したデータを検証しますか
  特に、別のアプリケーションからデータベースに書き込みが行われるような場合、このような形態の入力についても検証が必要です。別のアプリケーションがどの程度徹底した入力検証を行っているかについては仮定しないでください。

• アプローチを集中化していますか
  一般的なタイプの入力フィールドの場合、共通の検証ライブラリとフィルタリング ライブラリが使用されているかどうかを調べ、検証規則が一貫して適用されることを確認します。

• クライアント側の検証に依存していませんか
  クライアント側の検証には依存しないでください。クライアント側の検証は、サーバーへのラウンド トリップ回数を減らすために使用することができますが、この検証方法は簡単に回避できるため、セキュリティについては依存しないでください。サーバー側のすべての入力を検証します。

入力を使用して何を実行しますか

処理のタイプが異なると脆弱性のタイプも異なるため、アプリケーションが入力を使って何を実行するのかを確認してください。たとえば、SQL クエリで入力を使用する場合、アプリケーションは潜在的に SQL 挿入に対する脆弱性があります。

可能性のある脆弱性を特定するのに役立つ、次の質問を確認します。

• アプリケーションは、正規化問題が起こりやすくなっていますか
  アプリケーションがセキュリティの決定を行うために、入力に基づいた名前を使用するかどうか確認します。たとえば、ユーザー名、ファイル名、または URL を受け付けますか。名前を多くの方法で表現できることから、これらの名前は正規化のバグとなることで有名です。アプリケーションが名前を入力として受け付ける場合は、これらの入力を処理する前に、検証済みで正規表現に変換されていることを確認します。

• アプリケーションは、SQL 挿入攻撃の影響を受けやすくなっていますか
  入力フィールドを使って SQL データベース クエリを形成する場合は、その入力フィールドに特に注意してください。これらの入力フィールドのタイプ、形式、長さ、範囲に対して、適切な検証が行われていることを確認します。さらに、クエリが生成される方法についても確認します。パラメータ化されたストアド プロシージャを使用する場合、入力パラメータは実行形式のコードとして扱われず、リテラルとして扱われます。この方法は、効果的なリスク緩和策といえます。

• アプリケーションは、XSS 攻撃の影響を受けやすくなっていますか
  HTML 出力ストリームに入力フィールドを含める場合には、XSS に対して脆弱になる可能性があります。入力を検証し、出力をエンコードすることを確認します。ある範囲の HTML 文字を受け付ける入力フィールドの処理方法に特に注意してください。

認証

アプリケーションが呼び出し元をどのようにして認証し、どのように認証を使用し、ストレージに格納されている資格情報のセキュリティをどのように確保し、また、その情報をネットワーク上にいつ渡すのかを調べます。認証の脆弱性によって、アプリケーションを偽装攻撃、辞書攻撃、セッション ハイジャックなどの攻撃に影響されやすくしてしまいます。表 5.2 に、認証に関連する最も一般的な脆弱性を示します。

表 5.2: 一般的な認証の脆弱性

脆弱性	影響
弱いパスワード	パスワード解読と辞書攻撃のリスクが高くなります。
構成ファイルのクリア テキスト資格情報	サーバーにアクセスできる内部関係者、またはホストの脆弱性を利用して構成ファイルをダウンロードする攻撃者は、資格情報に直接アクセスすることができます。
ネットワーク上でのクリア テキスト資格情報のやり取り	攻撃者はネットワークを監視して認証資格情報を盗み、ID を偽装することができます。
過剰な特権を持つアカウント	プロセスまたはアカウントが侵害されることによるリスクが高くなります。
長いセッション	セッション ハイジャックに関連するリスクが高くなります。
個人用の設定と認証が混在	個人設定データは、永続性のある Cookie に適しています。それに対し、認証 Cookie は不適切です。

次の質問を検討し、アプリケーションが認証を実行する方法の潜在的な脆弱性を特定します。

• パブリックなアクセスと制限アクセスを区別していますか。

• サービス アカウント要件を特定していますか。

• どのようにして呼び出し元を認証しますか。

• データベースを使用する場合の認証方法はどのようにしますか。

• 強力なアカウント管理方法を実行しますか。

パブリックなアクセスと制限アクセスを区別していますか

アプリケーションが、認証が不要な公共エリアと、認証が必要な制限エリアを提供する場合、これらをどのように区別しているのか、サイトの設計を調べます。制限付きのページとリソースには別個のサブフォルダを使用し、これらのフォルダが SSL を要求するように設定することで、インターネット インフォメーション サービス (IIS) でこれらのセキュリティを保護します。この方法によって、サイト内で機密性の高いデータと認証 Cookie のセキュリティが必要なエリアだけに限定して SSLを使用し、これらのセキュリティを提供することを可能にします。これによって、SSL に関連した新たなパフォーマンスへの悪影響がサイト全体に及ぶことが避けられます。

サービス アカウント要件を特定していますか

設計上、データベース、ディレクトリ サービス、その他のリモート ネットワーク リソースを含むさまざまなリソースに接続することが要求されるサービス アカウントの範囲を識別することが必要です。アカウント 1 つでさまざまなタイプのリソースの範囲に接続できる十分な権限を持つ高度なアカウントを要求するような設計は行わないでください。

• 最小限の権限を持つアカウントが必要な設計ですか
  どのリソース、および操作がどの特権を必要とするのかを特定していますか。各アカウントが特定の関数を実行するために必要な特権が正確に識別されていることを確認し、すべての場合において最小限の権限を持つアカウントを使用します。

• アプリケーションでサービス アカウント資格情報を保持する必要がありますか
  保持する必要がある場合には、資格情報が暗号化され、制限されたアクセス制御リスト (ACL) を持つレジストリ キーなど、制限された場所に保持されていることを確認します。

呼び出し元の認証

呼び出し元の認証には、次の方法を検討します。使用する方法は、設計で使用される認証のタイプによって異なります。

• クリア テキスト資格情報はケーブル上でやりとりされますか
  フォーム認証、または基本認証を使用する場合、あるいは Web サービスを使用し、SOAP ヘッダーで資格情報を渡す場合は、SSL を使用して転送中の資格情報を保護することを確認します。

• 独自のユーザー ストアを実装しますか
  実装する場合は、ユーザー資格情報を格納する場所と方法を確認します。一般的な誤りは、プレーンテキスト、または暗号化されたパスワードをユーザー ストアに格納することです。その代わりに、検証のためのパスワード ハッシュを格納することが必要です。

  SQL Server のユーザー ストアに対して資格情報を検証する場合、入力ユーザー名とパスワードに特に注意してください。悪意のある SQL 文字が挿入されていないかどうかを確認します。

• フォーム認証を使用しますか
  使用する場合は、SSL を使用して資格情報を保護するほかに、同じく認証 Cookie を保護する必要があります。さらに、セッションの有効期間を制限して Cookie リプレイ攻撃の脅威に対応することを確認し、さらに Cookie が暗号化されていることを確認します。

  フォーム認証の詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」とモジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」を参照してください。

データベースを使用する場合の認証方法

アプリケーションがデータベースに接続する場合は、使用する認証機構、使用する予定のアカウント、データベース内でアプリケーションの承認を計画する方法について調べます。

次の質問は、データベースの認証方法を確認するのに役立ちます。

• SQL 認証を使用しますか
  Windows 認証を使用して SQL Server に接続するのが理想的です。この方法が本質的により安全であることがその理由です。SQL 認証を使用する場合、ネットワーク上と、データベース接続文字列内の資格情報のセキュリティ保護を計画する方法について調べます。

  ネットワーク インフラストラクチャで IPSec 暗号化チャネルが提供されていない場合は、SQL 資格情報の自動暗号化機能を提供するために、サーバー証明書がデータベース上にインストールされていることを確認します。さらに、データベース接続文字列のセキュリティ計画を実行する方法についても調べます。これらの文字列には、SQL アカウントのユーザー名とパスワードが含まれるためです。

• プロセス アカウントを使用しますか
  アプリケーションのプロセス アカウントを使用し、Windows 認証を使用して SQL Server に接続する場合、最小限の権限を持つアカウントを前提とした設計になっていることを確認します。この目的のために、ローカルな ASPNET アカウントが提供されている場合、ローカル アカウントを使用して、データベース サーバー上に重複アカウントを作成する必要があります。

  ドメイン アカウントの使用を計画する場合、それが最小限の権限を持つアカウントであることを確認し、関連ポートを開くことによって、介在するすべてのファイアウォールが Windows 認証をサポートすることを確認します。

• サービス アカウントを使用しますか
  データベース内でよりきめ細かい認証をサポートするために複数の ID を要求する設計になっている場合は、アカウント資格情報を保存する方法 (Data Protection API (DPAPI) を使用して暗号化され、安全なレジストリ キーに保持されるのが理想的)、およびサービス ID を使用する方法について検討します。

  さらに、サービス アカウントを使用して、偽装されたセキュリティ コンテキストを作成する場合に使用されるプロセスについても調べます。Microsoft® Windows® 2000 上では ASP.NET アプリケーション プロセスでこれを実行しないようにしてください。プロセス アカウントの権限を増やすことになり、また " オペレーティング システムの一部として機能" 特権を付与しなければならないためです。このことは、リスク係数が増大するため、使用を避ける必要があります。

• 匿名のインターネット ユーザー ID を使用することを検討しましたか
  フォーム認証、またはパスワード認証を使用するアプリケーションの場合、アプリケーションごとに別々の匿名ユーザー アカウントを構成することができます。次に、偽装を可能にし、匿名 ID を使ってデータベースにアクセスできます。この方法は、同じ Web サーバー上の異なるアプリケーションに対して、別々の承認と ID の追跡に対応できます。

• 元のユーザー ID を使用しますか
  本来の呼び出し元を偽装する必要のある設計の場合は、接続プールの効果がないため、十分な拡張性を提供するアプローチかどうかを検討する必要があります。代替的なアプローチとしては、信頼されたクエリ パラメータを経由して本来の呼び出し元の ID をアプリケーション レベルでフローさせる方法があります。

• データベース接続文字列をどのように格納しますか
  データベース接続文字列がハードコード化されているか、または構成ファイルか COM+ カタログにクリア テキストで格納されている場合は、脆弱になっています。その代わりに、そのようなデータベース接続文字列を暗号化し、暗号化されたデータへのアクセスを制限する必要があります。

  SQL サーバーの接続オプションとデータベース接続文字列を安全に格納する方法については、モジュール 14「セキュリティ保護されたデータ アクセスを構築する」を参照してください。

強力なアカウント管理方法を実行しますか

アプリケーションが Window 認証を使用する場合は、強力なパスワードの使用、ログイン試行の制限、そのほかのアカウント管理ポリシーの実践方法は、Windows セキュリティ ポリシーによって実行できます。それ以外の場合は、アプリケーション層が担当します。アプリケーションのアカウント管理の次の側面について検討します。

• アプリケーションは強力なパスワードを実行しますか
  たとえば、ASP.NET ページは正規表現を使ってパスワードの複雑さの規則を検証しますか。

• 失敗したログイン試行回数を制限しますか
  試行回数を制限することで、辞書攻撃の脅威に対抗できますか。

• 障害が発生した場合、公開する情報が多すぎませんか
  「不正なパスワード」などのメッセージを表示しないことを確認してください。悪意のあるユーザーにユーザー名が間違っていないことを知らせているからです。これによって、攻撃者がパスワードを解読する作業に専念できてしまいます。

• パスワードの定期的な変更が必要ですか
  パスワードの定期的な変更を強制的に行うことを推奨します。そうでない場合、ユーザーは自分のパスワードを変更しない可能性が高くなることから、さらに脆弱になります。

• 侵入された場合、アカウントをすぐに無効にすることができますか
  アカウントが危険にさらされた場合、攻撃者によってそのアカウントが継続して使用されないように、アカウントを容易に無効にできますか。

• アプリケーションはログイン試行を記録しますか
  失敗したログイン試行を記録することは、侵入を試みる攻撃者を検出するための効果的な方法といえます。

承認

アプリケーションがユーザーを承認する方法を調べます。さらに、データベース内部でアプリケーションを承認する方法、およびシステムレベル リソースへのアクセスを制御する方法についても調べます。承認の脆弱性は、情報の漏えい、データの改ざん、権限の不正取得に起因する可能性があります。多層防御は、アプリケーションの承認戦略に適用可能な重要なセキュリティ原則です。表 5.3 に、承認に関連する最も一般的な脆弱性を示します。

表 5.3: 一般的な承認の脆弱性

脆弱性	影響
単一のゲートキーバーに依存する	ゲートキーパーがバイパスされたり、正しく構成されていない場合、ユーザーは不正にアクセスできることになります。
アプリケーションの ID に対し、システム リソースのロックに失敗した	攻撃者は、アプリケーションを悪用して、制限されたシステム リソースにアクセスできます。
データベース アクセスを指定されたストアド プロシージャに制限できない	攻撃者は、SQL 挿入攻撃をマウントして、データの取得、操作、または破壊を行います。
権限の分離が不十分である	ユーザー別承認を実行する責任の所在、または機能というものはありません。

アプリケーション設計の承認戦略を検証するのに役立つ、次の質問を確認します。

• どのようにしてエンド ユーザーを承認しますか

• データベース内のアプリケーションをどのようにして承認しますか

• どのようにしてシステムレベルのリソースに対するアクセスを制限しますか

エンド ユーザーを承認する方法

承認は、設計時に次の 2 つの視点から検討する必要があります。最初に、エンド ユーザー承認について検討します。どのユーザーがどのリソースにアクセスし、どんな操作を実行できますか。次に、どのようにして悪意のあるユーザーがアプリケーションを使ってシステム レベルのリソースにアクセスできないようにしますか。次の質問を確認して、アプリケーションの承認戦略を検証します。

• 多層防御戦略を使用しますか
  アクセス制御の実行を単一のゲートキーパーに依存した設計にしていないことを確認します。このゲートキーパーに障害が発生した場合、あるいは攻撃者がバイパスに成功した場合に何が起こるのかを考えてみてください。

• どのゲートキーパーを使用しますか
  IIS Web 権限、NTFS 権限、ASP.NET ファイル承認 (Windows 認証の場合のみ適用)、URL 承認、プリンシパル権限要求などのオプションがあります。特定のタイプが使用されない場合は、その理由を把握していることを確認します。

• ロールベースのアプローチを使用しますか
  ロールベースのアプローチを使用する場合、ロール リストをどのように保守し、それに必要な管理インターフェイスのセキュリティをどの程度にしますか。

• ロールによって十分な権限の分離が行われていますか
  別個のユーザー ロールに関連付けられた特権が適切に分離できるように、設計上、正しい単位が設定されていますか。特定のユーザーの要件を満たすためだけに、ロールに上位の特権が付与される状況を回避します。その代わりに、新しいロールを追加することを検討します。

データベース内のアプリケーションの承認方法

アプリケーションがデータベースに接続するために使用するアカウントの機能は、アプリケーション要件に十分な機能に限定し、必要以上の機能を持たないようにします。

• アプリケーションはストアド プロシージャを使用してデータベースにアクセスしますか
  アプリケーションのログインには、指定されたストアド プロシージャにアクセスする特権だけが付与できるため、ストアド プロシージャを使用してデータベースにアクセスする方法を推奨します。ログインがデータベースに対して直接作成/読み取り/更新/削除 (CRUD) 操作を実行することを制限することができます。

  これによって、セキュリティだけでなく、パフォーマンスと将来の保守可能性にも利点があります。データベースの承認方法の詳細については、モジュール 14「セキュリティ保護されたデータ アクセスを構築する」を参照してください。

システムレベルのリソースに対するアクセスを制限する方法

アプリケーションを設計する場合、アプリケーションがアクセスできるシステムレベル リソースの面から、配置される制限について検討します。アプリケーションには、最小限の要求リソースにアクセスできる権限だけを付与するようにします。これは、アプリケーションが危険にさらされた場合の損害を限定する、リスク緩和戦略です。次の問題について検討します。

• コード アクセス セキュリティを使用しますか
  コード アクセス セキュリティは、コード (および Web アプリケーション) が特定のタイプのシステムレベル リソースにアクセスできないようにするリソース制約モデルを提供します。コード アクセス セキュリティを使用する場合、必然的に設計にも影響します。コード アクセス セキュリティを設計計画の中に含めるかどうかを確認したら、それに応じて権限を持つコードを分離し、独立させ、リソース アクセス コードを固有のアセンブリに配置するように設計します。

• アプリケーションはどの ID を使用しますか
  設計では、プロセス ID、および匿名のインターネット ユーザー アカウントやサービス ID などの偽装 ID を含み、アプリケーションが使用するすべての ID を識別する必要があります。さらに、これらの ID がアクセスする必要のあるリソースを示す必要があります。

  展開時に、システムレベルのリソース上に適切な ACL を構成することで、アプリケーションの ID が必要なリソースにだけアクセスできるようにすることができます。

  コード アクセス セキュリティの詳細については、モジュール 9「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。

構成管理

アプリケーションが構成可能な管理インターフェイスを提供する場合、管理インターフェイスのセキュリティを確保する方法について調べます。さらに、セキュリティで保護する構成データの機密性のレベルについても調べます。表 5.4 に、構成管理に関連する最も一般的な脆弱性を示します。

表 5.4: 一般的な構成管理の脆弱性

脆弱性	影響
セキュリティで保護されていない 管理インターフェイス	権限のないユーザーによるアプリケーションの再構成と機密性の高いデータへのアクセスが可能になります。
セキュリティで保護されていない構成ストア	権限のないユーザーが構成ストアにアクセスし、アカウント名、パスワード、データベース接続明細などのシークレットを取得できます。
クリア テキストの構成データ	サーバーにログインできれば、誰でも機密性の高い構成データを参照できます。
管理者が多すぎる	管理者の監査と入念な検査が困難になります。
過剰な権限を持つプロセス アカウントとサービス アカウント	権限の上昇攻撃が可能になります。

次の質問を使用して、アプリケーションの構成管理の設計方法について検証することができます。

• リモート管理をサポートしますか。

• 構成ストアをセキュリティで保護しますか。

• 管理者権限を分離しますか。

リモート管理をサポートしますか

設計にリモート管理が指定された場合、管理インターフェイスと構成ストアをセキュリティで保護しなければなりません。これらは本質的に機密性の高い操作であること、また管理インターフェイス上でアクセス可能なデータであることがその理由です。リモート管理設計の次の方法を検討します。

• 強力な認証を使用しますか
  すべての管理インターフェイスユーザーに対して認証が必要です。Windows またはクライアント証明書による認証などの強力な認証を使用します。

• ネットワーク トラフィックを暗号化しますか
  IPSec または仮想プライベートネットワーク (VPN) 接続が提供するような、暗号化された通信チャネルを使用します。セキュリティで保護されていないチャネル上では、リモート管理をサポートしないでください。IPSec によって、サーバーの管理に使用できるクライアント マシンの ID と台数を制限できます。

構成ストアをセキュリティで保護しますか

アプリケーションの構成ストアを識別し、構成ストアへのアクセスを制限する方法と内部のデータをセキュリティで保護する方法について調べます。

• 構成ストアは Web 空間にありますか
  Web 空間のファイルに保持された構成データは、Web 空間の外部に保持されたデータよりもセキュリティが低いと見なされます。ホスト構成の誤りや未発見のバグによって、攻撃者が HTTP 上で構成ファイルを取得し、ダウンロードすることを潜在的に可能にします。

• 構成ストアのデータはセキュリティで保護されていますか
  データベース接続文字列、暗号化キー、サービス アカウント資格情報などの構成データの主要アイテムが、ストアの内部で暗号化されることを確認します。

• 構成ストアへのアクセスをどのようにして制限しますか
  認証された管理者だけがデータのアクセスと操作ができるように、管理インターフェイスが必要な承認を提供していることを確認します。

管理者権限を分離しますか

管理インターフェイスがコンテンツの更新、サービス アカウントの再構成、データベース接続明細などのさまざまな機能に対応する場合、コンテンツ開発者とオペレータ、またはシステム管理者を区別するために管理インターフェイスがロールベースの承認をサポートすることを確認してください。たとえば、Web サイトの静的なコンテンツを更新する担当者が、顧客のクレジット制限を変更したり、データベース接続文字列を再構成することを必ずしも許可する必要はありません。

機密性の高いデータ

アプリケーションがストアやアプリケーションのメモリ内にある機密性の高いデータや、ネットワーク上でやり取りされている機密性の高いデータをどのように扱うのかを調べます。表 5.5 に、機密性の高いデータの処理に関連する最も一般的な脆弱性を示します。

表 5.5: 機密性の高いデータを処理する場合の一般的な脆弱性

脆弱性	影響
必要のないときにシークレットを保存する	そもそも、この動作は、シークレットを保存しない方法とは対照的に、セキュリティ リスクを劇的に高めます。
シークレットをコードに格納する	サーバー上にコードがある場合、攻撃者によってそのコードがダウンロードされるおそれがあります。シークレットは、バイナリ アセンブリで識別可能です。
シークレットをクリア テキストで格納する	サーバーにログオンできるユーザーなら誰でもシークレットのデータを参照できます。
クリア テキストの機密データをネットワーク上で通過させる	盗聴者によって、ネットワークが監視され、データが露出したり、改ざんされるおそれがあります。

次の質問を使用して、アプリケーションが機密性の高いデータを処理する方法を検証することができます。

• シークレットを保存しますか。

• 機密性の高いデータをどのように格納しますか。

• 機密性の高いデータをネットワーク上で渡しますか。

• 機密性の高いデータを記録しますか。

シークレットを保存しますか

シークレットには、アカウント パスワード、暗号化キーなどのアプリケーションの構成データが含まれています。可能であれば、どんな理由でもシークレットは保存しない別の設計方法を特定します。シークレットを扱う場合、シークレットの処理はプラットフォームに任せ、可能な限り、アプリケーションからシークレットを処理する負担を取り除くようにします。シークレットを格納する場合は、次の質問を検討してください。

• シークレットの保存は回避できますか
  代替的な実装技術を使用すれば、シークレットを保存する必要をなくすことができます。たとえば、ユーザーがパスワードを知っていることを確認するだけでよいとすれば、パスワードを保存する必要はありません。その代わりに、一方向のパスワード ハッシュを保存します。

  さらに、Windows 認証を使用する場合、埋め込まれた資格情報とともに接続文字列を格納することは避けます。

• シークレットはどのように保存しますか
  暗号化を使用する場合、暗号化キーをどのようにしてセキュリティで保護しますか。プラットフォームが提供する DPAPI 暗号化機能を使用して、キー管理を実行することを検討します。

• シークレットはどこに保存しますか
  アプリケーションが暗号化されたデータをどのように保存するのかを調べます。最大限のセキュリティを得るため、暗号化されたデータへのアクセスは、Winodows ACL を使用して制限する必要があります。アプリケーションがクリア テキストやソースコードにシークレットを保存しないことを確認します。

  ローカル セキュリティ機関 (LSA) を使用する場合は、シークレットを取得するコードを管理者権限で実行する必要がありますが、これによってリスクが高くなります。拡張された特権を必要としない別のアプローチは、DPAPI を使用する方法です。

• シークレットをどのように処理しますか
  アプリケーションがシークレットにアクセスする方法と、シークレットがクリアテキスト形式でメモリ上に保持される期間を調べます。シークレットは、通常、オンデマンドで取り出し、できるだけ最短時間で使用し、破棄する必要があります。

• シークレットを Cookie に保存しますか
  Cookie に保存する場合、Cookie を暗号化し、クライアント コンピュータ上に保持しないようにします。

機密性の高いデータをどのように格納しますか

顧客のクレジット カード明細などの機密性の高いアプリケーション データを格納する場合は、データを保護する方法について調べます。

• どのような暗号化アルゴリズムを使用しますか
  Triple DES などの、キー サイズの大きい強力な暗号化アルゴリズムを使用してデータを暗号化してください。

• 暗号化キーをどのようにしてセキュリティで保護しますか
  暗号化されたデータのセキュリティは、あくまで暗号化キーのセキュリティと同程度でしかありません。したがって、キーをセキュリティで保護する方法を調べます。キーは DPAPI を使って暗号化し、レジストリ キーなどの制限された場所に確保するのが理想的です。

機密性の高いデータをネットワーク上で渡しますか

機密性の高いデータをネットワーク上で渡す場合、データがアプリケーションによって暗号化されているか、あるいはデータが暗号化された通信リンク上でだけ渡されるのかを確認します。

機密性の高いデータを記録しますか

アプリケーション (またはホスト) が、クリア テキストのログ ファイルにユーザー アカウント パスワードなどの機密性の高いデータを記録するかどうかを調べます。通常はこれを回避してください。アプリケーションは、機密性の高いデータをクエリ文字列で渡さないようにしてください。これらのデータはログに記録され、さらにクライアントのブラウザのアドレス バーに表示されてしまいます。

セッション管理

Web アプリケーションはステートレスな HTTP プロトコル上に構築されるため、セッション管理はアプリケーション レベルの責任です。アプリケーションによるセッション管理方法はアプリケーションのセキュリティ全体に影響するため、これを調べます。表 5.6 に、セッション管理に関連する最も一般的な脆弱性を示します。

表 5.6: 一般的なセッション管理の脆弱性

脆弱性	影響
暗号化されていないチャネル上でセッション ID を渡す	攻撃者がセッション ID を取得して ID を偽装するおそれがあります。
セッションの有効期間を延長	セッション ハイジャックとリプレイ攻撃のリスクが高くなります。
セキュリティで保護されていないセッション状態ストア	攻撃者がユーザーのプライベートなセッション データにアクセスするおそれがあります。
クエリ文字列内のセッション ID	ID を偽装し、別のユーザーになりすましてアプリケーションにアクセスするために、クライアント側でセッション ID を容易に修正することができます。

次の質問を使用して、アプリケーションが機密性の高いデータを処理する方法を検証することができます。

• セッション ID はどのようにしてやり取りされますか。

• セッション有効期間を制限しますか。

• セッション状態ストアをどのようにしてセキュリティで保護しますか。

セッション ID はどのようにしてやり取りされますか

ユーザー セッションを管理するためにアプリケーションが使用するセッション ID を調べて、これらのセッション ID がやり取りされる方法を調べます。次の点を考慮してください。

• 暗号化されていないチャネル上でセッション ID を渡しますか
  たとえば、Cookie に含まれるトークンなど、セッション ID を使用してセッション状態を追跡する場合、ID または Cookie が SSL などの暗号化されたチャネル上だけでやり取りされるかどうかを確認します。

• セッション Cookie を暗号化しますか
  フォーム認証を使用する場合は、アプリケーションが <forms> 要素に protection="All" 属性を使用して、認証 Cookie を暗号化することを確認します。ユーザーの認証 Cookie を盗難する XSS 攻撃のリスクを軽減するため、SSL のほかに、この方法を実際に使用することを推奨します。

• セッション ID をクエリ文字列で渡しますか
  アプリケーションがセッション ID をクエリ文字列で渡さないことを確認します。これらの文字列は、クライアント側で容易に修正できます。したがって、ユーザーが別のユーザーとしてアプリケーションにアクセスし、ほかのユーザーのプライベートなデータにアクセスして、潜在的に権限を格上げすることが可能になります。

セッション有効期間を制限しますか

アプリケーションがセッション ID を有効とみなす期間を調べます。アプリケーションは、セッション ハイジャックとリプレイ攻撃の脅威を緩和するために、有効期間を制限する必要があります。

セッション状態ストアをセキュリティで保護する方法は

アプリケーションがセッション状態を格納する方法を調べます。セッション状態は、Web アプリケーション プロセス、ASP.NET セッション状態サービス、または SQL Server 状態ストアに格納できます。リモート状態ストアを使用する場合、Web サーバーからリモート ストアへのリンクが、ケーブル上のデータを保護するために IPSec または SSL を使って暗号化されることを確認します。

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

暗号化

アプリケーションが暗号化を使用してセキュリティを提供する場合、使用目的と使用方法を確認します。表 5.7 に、暗号化に関連する最も一般的な脆弱性を示します。

表 5.7: 一般的な暗号化の脆弱性

脆弱性	影響
カスタム暗号化を使用	試用、およびテスト済みのプラットフォームが提供する暗号化に比べ、セキュリティ レベルはほぼ確実に低くなります。
誤ったアルゴリズムを使用、またはキー サイズの指定が小さすぎる	新しいアルゴリズムほどセキュリティが高くなっています。キー サイズを長くするほど、セキュリティが強化されます。
暗号化キーをセキュリティ保護できない	暗号化されたデータのセキュリティは、あくまで暗号化キーのセキュリティと同程度でしかありません。
同じキーを使用したまま期間を延長	静的なキーは、時間の経過とともに検出される可能性が高くなります。

次の質問を検討してください。アプリケーションが機密性の高いデータを処理する方法を検証することができます。

• 特定のアルゴリズムを使用する理由は何ですか

• 暗号化キーをどのようにしてセキュリティで保護しますか

特定のアルゴリズムを使用する理由は何ですか

暗号化が真のセキュリティを発揮するのは、それが適切に使用された場合と、正しいアルゴリズムが正しいジョブに使用された場合です。また、アルゴリズムの強度も重要です。次の質問を検討して、暗号化アルゴリズムの使用を確認してください。

• 独自の暗号化を開発していますか
  クライアント側の検証には依存しないでください。暗号化アルゴリズムとルーチンは、周知のとおり、開発し正しく理解することが困難です。多くの場合、カスタム実装は保護強度を弱め、プラットフォームが提供する実証済みのサービスに比べ、セキュリティが低くなるのがほぼ確実です。

• 正しいアルゴリズムを十分なキー サイズで使用していますか
  アプリケーションが使用するアルゴリズムと目的について検証します。キー サイズを長くするほど、セキュリティが強化されますが、パフォーマンスに影響します。期間が延長されてもデータ ストアに保持されている変動しないデータの場合、暗号化をより強化することが何よりも重要です。

適切なアルゴリズムとキー サイズを選択する方法については、モジュール 4「セキュリティ保護された Web アプリケーションの設計ガイドライン」の「暗号化」セクションを参照してください。

暗号化キーをどのようにしてセキュリティで保護しますか

暗号化されたデータのセキュリティは、あくまで暗号化キーのセキュリティと同程度でしかありません。暗号化されたデータを解読するには、攻撃者がキーと暗号テキストを取得できなければなりません。したがって、設計を調べ、暗号化キーと暗号化されたデータがセキュリティで保護されていることを確認します。次のレビュー項目について検討します。

• 暗号化キーをどのようにしてセキュリティで保護しますか
  DPAPI を使用する場合、プラットフォームでキーを管理します。それ以外の場合は、アプリケーションがキー管理を担当します。アプリケーションが暗号化キーをセキュリティで保護する方法を検証します。DPAPI を使用して、他の形式の暗号化に必要な暗号化キーを暗号化するのが正しい方法です。次に、制限された ACL で構成されたキーの下のレジストリに配置するなどの方法で、暗号化キーを安全に格納します。

• キーが再使用される頻度はどれくらいですか
  キーは乱用しないでください。同じキーを長く使用すればするほど、検出される可能性が高くなります。キーをどの位の頻度でどのように使用するのか、またキーをどのように配布し、サーバー上にインストールするかについて考慮していますか。

パラメータ改ざん

アプリケーションがパラメータを使用する方法を確認します。これらのパラメータには、クライアントとサーバー間でやり取りされるフォーム フィールド、クエリ文字列、Cookie、HTTP ヘッダー、表示状態が含まれます。クエリ文字列などのパラメータを使用して、セッション ID などの機密性の高いデータを渡す場合は、悪意のあるクライアントによってサーバー側のチェックが簡単なパラメータ改ざんで容易に迂回されるおそれがあります。表 5.8 に、パラメータ改ざんに関連する最も一般的な脆弱性を示します。

表 5.8: 一般的なパラメータ改ざんの脆弱性

脆弱性	影響
すべての入力パラメータを検証できない	アプリケーションは、サービス拒否攻撃、および SQL 挿入と XSS を含むコード挿入攻撃を受けやすくなっています。
暗号化されていない Cookie 内の機密データ	Cookie データはクライアント側で変更するか、またはネットワーク上を通過させるときに取得、変更できます。
クエリ文字列とフォーム フィールドの機密データ	クライアント側で簡単に変更できます。
HTTP ヘッダー情報を信頼	クライアント側で簡単に変更できます。
保護されていない表示状態	クライアント側で簡単に変更できます。

パラメータ改ざん攻撃の影響を受けやすい設計にしないように、次の質問を検討してください。

• すべての入力パラメータを検証しますか

• 機密性の高いデータをパラメータで渡しますか

• セキュリティのために HTTP ヘッダーのデータを使用しますか

すべての入力パラメータを検証しますか

アプリケーションが、標準のフォーム フィールドと非表示のフォーム フィールド、クエリ文字列、および Cookie を含むすべての入力パラメータを検証することを確認します。

機密性の高いデータをパラメータで渡しますか

アプリケーションが機密性の高いデータをクエリ文字列やフォーム フィールドなどのパラメータで渡す場合、これよりもセキュリティの高い (たとえば、暗号化された Cookie で) セッション ID を渡す方法を使用せずに、あえてこの方法を使用する理由について確認します。この情報を使用して、セッションをサーバー上の状態ストアで保持されているユーザーの状態に関連付けます。次のレビュー項目について検討します。

• 機密性の高いデータを含む Cookie を暗号化していますか
  アプリケーションがユーザー名やロール リストなどの機密性の高いデータを含む Cookie を使用する場合は、それらが暗号化されていることを確認します。

• 機密性の高いデータをクエリ文字列、またはフォーム フィールドで渡しますか
  この方法は推奨できません。クエリ文字列、またはフォーム フィールドのデータを簡単に操作できないようにする方法は存在しないためです。その代わりに、暗号化されたセッション ID を使用し、機密性の高いデータをサーバー上のセッション状態ストアに格納することを検討します。

• 表示状態を保護していますか
  Web ページ、またはコントロールが表示状態を使用して、HTTP 要求全体の状態を保持している場合、表示状態が暗号化されていること、メッセージ認証コード (MAC) との整合性がチェックされていることを確認します。これは、マシン レベル、またはページ単位で構成できます。

セキュリティのために HTTP ヘッダーのデータを使用しますか

ヘッダーは攻撃者が容易に操作できることから、Web アプリケーションが HTTP ヘッダーの情報に基づいてセキュリティ決定を行わないことを確認します。Web アプリケーションによって生成されたページから発生した要求をチェックする場合は、HTTP 参照元フィールドの値に依存しないでください。依存した場合には脆弱性が生じます。参照元フィールドはクライアントによって簡単に変更できるため、この方法は本質的にセキュリティで保護されません。

例外管理

アプリケーションがエラー状況を処理する方法を検証します。構造化された例外処理を一貫して使用することを推奨します。さらに、アプリケーションに例外が発生した場合に、公開する情報が多すぎないことを確認します。表 5.9 に、例外管理に関連する主な 2 つの脆弱性を示します。

表 5.9: 例外管理の一般的な脆弱性

脆弱性	影響
構造化された例外処理が使用できない	アプリケーションはサービス拒否攻撃、論理的短所による影響を受けやすくなり、セキュリティの脆弱性が発生する可能性があります。
クライアントに公開する情報が多すぎる	攻撃者がそれ以降の攻撃の計画、調整にこの情報を利用する可能性があります。

次の質問を検討してください。例外管理のセキュリティに関連する脆弱性の影響を受けない設計であることを保証します。

• 構造化された例外処理を使用していますか。

• クライアントに公開する情報が多すぎませんか。

構造化された例外処理を使用していますか

アプリケーションが構造化された例外処理を使用する方法を調べます。アプリケーション全体を通じて、構造化された例外処理を一貫して使用することを指定する必要があります。これによって、より堅牢なアプリケーションを作成し、また、アプリケーションがセキュリティの脆弱性が明らかになる可能性のある一貫性のない状態になりにくくします。

クライアントに公開する情報が多すぎませんか

不正なユーザーがエラー メッセージに含まれる過度の詳細情報を利用できないようにしてください。次の項目を再確認します。

• 例外の検出、処理、記録はサーバー上で行いますか
  アプリケーションが内部的な例外条件をアプリケーション境界を越えて適用しないことを確認します。例外は、サーバー上で検出し、ログに記録する必要があります。また、必要に応じて、クライアントに汎用のエラー メッセージを返す必要があります。

• 集中的な例外管理システムを使用していますか
  アプリケーションを通じて一貫性のある例外処理とログへの記録を行う場合、形式化した例外管理システムを使用することが最善の方法です。さらに、このシステムは、状態とパフォーマンスの監視のために運用チームが使用できる監視システムに結合することができます。

• 一連のカスタム エラー メッセージを定義しましたか
  設計では、重大なエラーが発生した場合にアプリケーションが使用するカスタム エラー メッセージを定義する必要があります。カスタム エラー メッセージには、悪意のあるユーザーによって利用される可能性のある機密性の高いデータ項目が含まれていないことを確認します。

  .NET アプリケーションの例外管理フレームワークの設計と実装については、MSDN 記事「.NET における例外管理」(http://www.microsoft.com/japan/msdn/net/bda/exceptdotnet.aspx) を参照してください。

監査とログ記録

アプリケーションが監査とログを使用する方法について検証します。ログ ファイルの定期的な分析は、否認の問題を回避するだけでなく、侵入の兆候を識別するのに役立ちます。表 5.10 に、監査とログに関連する最も一般的な脆弱性を示します。

表 5.10: 一般的な監査とログの脆弱性

脆弱性	影響
失敗したログオンを監査できない	侵入の試みが検知されません。
監査ファイルをセキュリティ保護できない	攻撃者は証拠を隠すことができます。
アプリケーション層全体の監査ができない	否認の脅威が増加します。

次の質問を検討してください。アプリケーションが監査と記録を行う方法を検証できます。

• 監査の対象となる主な動作を特定しましたか

• 元の呼び出し元 ID をフローする方法は検討しましたか

• 安全なログ ファイル管理ポリシーについて検討しましたか

監査の対象となる主な動作を特定しましたか

設計では、監査の対象となる動作を定義する必要があります。次の点を考慮してください。

• 失敗したログイン試行を監査しますか
  これによって、侵入とパスワード解読の試みを検出することが可能です。

• その他の主なオペレーションを監査しますか
  データ取得、ネットワーク通信、管理機能 (ログの有効化、無効化など) を含むその他の主要イベントを確認します。

元の呼び出し元 ID をフローする方法は検討しましたか

複数のアプリケーション層全体で動作状況を監査することを保証する必要があります。そのためには、元の呼び出し元 ID が各層で使用できるようにする必要があります。

• アプリケーション層全体を監査しますか
  各層で必要な動作を監査するかどうかを調べます。

• 複数のログの同期をとる方法は
  個人による犯罪を証明する場合、または否認の訴訟を解決する場合、法的な手続きとしてログファイルが必要になることがあります。通常、監査がリソース アクセス時に、そのリソースにアクセスするルーチンと同じルーチンによって生成される場合、監査は最も権限を持つとみなされます。アプリケーション設計がログ ファイルの同期を計算に入れ、任意の形式の要求 ID のログを記録することにより、ログ ファイルの複数のエントリを相互に関連付けて、それらを 1 つの要求に関連付け直すようになっていることを確認します。

• 元の呼び出し元の ID をフローさせる方法は
  たとえば、このアプローチによって提供される拡張性が限定されていることから、元の呼び出し元 ID をオペレーティング システム レベルでフローしない場合には、アプリケーションによって元の呼び出し元 ID をフローする方法を特定します。これは、各層を横断する監査 (また、潜在的には承認) に必要です。

  さらに、複数のユーザーが 1 つのアプリケーション ロールにマッピングされる場合、アプリケーションが元の呼び出し元 ID を記録することを確認します。

安全なログ ファイル管理ポリシーについて検討しましたか

アプリケーション設計が、ログ ファイルのバックアップ、アーカイブ、分析方法を計算に入れているかどうかを確認します。ログ ファイルはいっぱいになったり、上書きされたりしないように定期的にアーカイブし、侵入の兆候を検出するために定期的に分析する必要があります。さらに、バックアップのために使用するアカウントは最小限の権限を持つようにし、純粋にバックアップを目的とした追加の通信チャネルはセキュリティで保護することを保証します。

要約

アプリケーションのアーキテクチャと設計を事前に分析、およびレビューする時間と労力を投じることによって、設計関連の脆弱性を排除し、全体的なセキュリティを向上することができます。設計段階で脆弱性を修正する方が、開発サイクルの後半で本質的にリエンジニアリングが必要になってから修正するよりも容易に行うことができ、また費用も少なく済みます。

対象となる展開環境とそれによって定義されたセキュリティ ポリシーに関連して設計を考慮することによって、円滑で安全なアプリケーション展開が保証できます。

アプリケーションが既に作成済みの場合でも、アーキテクチャと設計レビューはセキュリティの評価プロセスの重要な部分であり、脆弱性の修正と将来の設計の改善に役立ちます。

その他のリソース

詳細については、次のリソースを参照してください。

• 分散 Web アプリケーションの各層にまたがる認証、承認、およびセキュリティで保護された通信の設計、構築、構成の詳細については、「セキュリティ保護された ASP.NET アプリケーションの構築」(http://msdn2.microsoft.com/en-us/library/Aa302415.aspx) を参照してください。

• 印刷可能なチェックリストについては、このガイドの「チェックリスト: Web サービスをセキュリティ保護する」を参照してください。