セキュリティの概要

セキュア Web アプリケーションデザインは、製品やプラットフォームに特有のものではなく、あらゆる Web アプリケーションを安全にデザインして実装する場合に役立ちます。このセクションでは、開発者とアプリケーションアーキテクトのためにセキュリティの概念を紹介します。これらの概念のほとんどは、Web アプリケーション以外のものを含めて、すべてのアプリケーション開発サイクルに当てはまるものです。

リスク評価

リスク評価 は、安全なシステムをデザインする作業の枠組み作りに役立つので、デザイン処理の最初のステップで行なう必要があります。リスク評価の基本的な手順は次のとおりです。

  1. 保護するリソースの特定
  2. 相対値の割り当て
  3. 可能性のあるアタッカーの特定
  4. 各タイプのアタッカーの相対的頻度の予測
  5. アタックツリー分析の実行と可能性のあるアタックルートの特定
  6. 可能性のあるアタックルートすべての保護

保護するリソースには、データベース、ファイル、または組織外の事業者にとって価値があるリソースが含まれます。リスク評価処理は、顧客情報などの社会的、法的な問題の秘密度、処理、および取り扱いに関する社内ポリシーに依存します。

アタッカーのスキル、頻度、方法の予測はすべて、アタックツリー分析と呼ばれる関連処理に属します。この処理は、分析と評価の主観的処理の形式化に役立ち、プロジェクトのセキュリティゴールの優先順位の決定に役立ちます。

アタックツリー分析から、保護するアタックルートを特定します。分析を行うときは、デザイン内で実装するセキュリティのタイプに関する情報を整理します。 この情報は、アプリケーションデザインに見合ったセキュリティポリシーやプライバシーポリシーの作成に役立ちます。

セキュリティポリシー

セキュリティポリシー は、組織のセキュリティニーズに関する分析を書き出したものです。特に、セキュリティを考慮したアプリケーションデザインを計画するときに役立ちます。ポリシーを正しく書き出しておけば、セキュリティポリシーの条件を厳守、保護するようにコードをより簡単に変更できます。 また、製品の条件の変化に合わせて、セキュリティポリシーを最新の状態に保つ必要があります。

委任

委任は、アプリケーションアーキテクチャ内の専門モジュールやレイヤーにタスクを割り当てる行為です。たとえば、リソースファイルのグループを保護するタスクの権限を JAAS に委任したり、ユーザー管理やグループ管理のタスクの権限を LDAP サーバに委任することがあります。これは、モジュラーアーキテクチャまたはレイヤー化とも呼ばれています。

モジュールの定義方法は人によって異なります。高レベルから、モジュールを必須とオプションのハードウェア、ドライバ、ソフトウェアのカテゴリーに分類することもあれば、入力、記憶、表示、処理、出力などの機能的なロールに分類することもあります。また、モジュールをサーブレット、JSP、JavaBean などのソフトウェアコンポーネントとして定義することもあります。

委任は、デザインと開発において非常に重要です。理論上は、セキュリティアーキテクチャが、オペレーティングシステムで使用される ACL (Access Control List:アクセスコントロールリスト) やファイルシステムによって実装されるアクセス許可などの、プラットフォームに存在する既存のレイヤーにアプリケーションの機能を委任します。

安全な実装では、他のプログラマーや開発者は、アプリケーションレイヤーに依存してデータの安全を確保できます。つまり、レイヤー化の観点からすると、データを外部から取得する場合、データを安全に処理することはあなたのタスクとなります。

検証

検証とは、受け取る情報の内容が正しいことを確認することです。アプリケーションで名前とアドレス情報を受け取る際、代わりに SQL コマンドを受け取ってしまうと、実行メソッドの呼び出し中にこの SQL コマンドが実行されてしまう可能性があります。一方、アプリケーションの検証メカニズムでは 、データを実行メソッドに渡す前に SQL の文字や文字列を確認およびフィルタして除外することができます。

検証とそのセキュリティ条件の間にある関係、正式な信頼は、人や物を信頼する行為を定義および分析する、公認された処理です。

セキュリティスペシャリストは、正式な処理を用いて信頼できるエンティティを識別します。正式な処理はセキュリティポリシーと非常に密接に関連しています。多くの場合、セキュリティポリシーでは、リソースやエンティティを信頼するために必要な条件が定義されます。つまり、会社の正式な信頼処理を定義する特定のポリシーは変わりやすいということです。

入手されたデータが信頼できるリソース (正式な信頼のための、ポリシーで定められたすべてのテストに合格したリソース) から来たものでないかぎり、そのデータを信頼することはできません。データを信頼できない場合は、検証が必要となります。

宣言セキュリティとプログラムセキュリティの比較

宣言セキュリティは、併用される他の Web コンポーネントとは別のレイヤーとして実装されます。ファイルアクセスの許可セットや、ユーザー、グループ、ロールなどのセキュリティシステムを設定してから、アプリケーションの認証メカニズムをそのレイヤーに組み込みます。

宣言セキュリティを使用すると、Web アプリケーションを作成するプログラマーはプログラムの作成環境を無視することができます。また、Web アプリケーションを更新する場合、一般的にセキュリティモデルのリファクタリングは必要ありません。

宣言セキュリティは、ファイルアクセスの許可セットや ACL として、また、Web アプリケーションへのすべてのリクエストを遮断するフィルタとして実装されます。

プログラムセキュリティでは、かなり詳細にセキュリティを設定することができます。Web アプリケーション内の各コンポーネントがセキュリティモデルを実装するので、コンポーネントのレベルでセキュリティを強化でき、また、必要な場合はページごとにセキュリティを強化することも可能です。これにより、柔軟性と精度が高まりますが、実装コストがかさみます。

プログラムセキュリティは、HTTP ヘッダーをチェックするすべてのサーブレットに追加する、一般的なメソッドのセットとして実装できます。

宣言セキュリティは、コードを再使用するデザインになっていて管理が容易であるため、ほとんどの J2EE アプリケーションでプログラムセキュリティよりも奨励されています。また、宣言セキュリティでは、セキュリティの責任はセキュリティの実装者にあるため、アプリケーションプログラマーはアプリケーション開発に専念でき、管理者はセキュリティポリシーの強化に専念できます。