Webアプリケーションセキュリティの属性とは

一般に、Webアプリケーションのアーキテクチャは通常Webブラウザ上で行われる基本的なレンダリングとクライアントへの情報の送信に対応します。その裏側で、Webアプリケーションはさまざまな異なる階層を利用します。その中にはプレゼンテーション、業務、データに使用するサーバーが含まれる場合があります。ニーズに応じてアーキテクチャの種類やアーキテクチャを構成する階層方式はさまざまです。

要件に最適なWebアプリケーションアーキテクチャを構築することは必須ですが、Webアプリケーションセキュリティを構築することも重要です。これにより、本番環境へのデプロイ時に、セキュリティインシデントを生じることなくWebアプリケーションのすべての業務要件と性能目標を確実に達成できます。

Webアプリケーションのアーキテクチャはセキュアか？

これはWebアプリケーションセキュリティのアーキテクチャを構築する際にシステム・アーキテクチャ・チームが最初に問うべき問題です。一般的なWebアプリケーションアーキテクチャには重大なセキュリティの欠陥が存在する可能性があります。Webアプリケーションセキュリティはそれを修正しようとする行為です。

この記事はセキュアなWebアプリケーションアーキテクチャを構築する方法を見つけるための参考になります。以下では多層アーキテクチャを用いた場合と単層または2層Webアプリケーションアーキテクチャを用いた場合のメリットを比較検討します。その後で、これらのアーキテクチャのセキュリティの確保に必要な個別の属性について説明します。

単層および2層Webアプリケーションアーキテクチャの主な短所

単一障害点が生じる。 単一障害点とは、そこで障害が発生するとアプリケーション全体が目的の動作を停止する箇所を指します。

• アプリケーションのアップグレードやパッチ管理の際に、アプリケーションチームはアプリケーション全体をオフラインにする必要があります。
• 攻撃者はインターネットを利用してアプリケーションのいずれかの層に侵害すれば、データベースに保存されているアプリケーションファイルやデータに無制限にアクセスできます。

多層セキュアWebアプリケーション・アーキテクチャの主な長所

単一障害点を解消する：図3に示すように、多層アーキテクチャはアプリケーション内の単一障害点の箇所を排除します。

• ロードバランサーを使用して複数のWebサーバー間でトラフィックを分散することにより、Webサーバーが単一障害点になることを防ぎます。
  • このシナリオではロードバランサーが新しい単一障害点をもたらすことに注意してください。したがって、可用性の高いロードバランサーを使用することが重要です。
• DBクラスタの導入もデータベースサーバーが単一障害点になることを防ぐために役立ちます。

セキュリティが向上する：複数の層を実装することにより、Webアプリケーションアーキテクチャのセキュリティが向上します。単一障害点をなくすことで、攻撃者がアプリケーション全体をコントロールする機会が制限されます。

個別の属性

Webアプリケーションセキュリティのアーキテクチャを決定したら、次にいくつかの属性を検討する必要があります。次のセクションでは、層間認証、サーバー側妥当性検証、セキュア通信、保存データ、ロギングについて説明します。

層間認証

多層アーキテクチャでは、アプリケーションの異なる層/コンポーネントが相互に連携してシームレスな機能を実現します。アプリケーション層は、他の層との通信やデータ転送を開始する前に互いを認証する必要があります。これにより確実に攻撃者が他の通信層のIDを偽装できなくなるようにします。セキュアな層間認証は以下のメカニズムで実装可能です。

• Kerberos
• Mutual SSL
• IPの妥当性検証

ユーザー名とパスワードによる層間認証はリスクが大きくなるため、層間認証にユーザー名とパスワードを使用することは避けるべきです。

サーバー側の妥当性検証

データの妥当性検証はクライアント側（Webブラウザ）とサーバー側（Webサーバー）で行うことが考えられます。クライアント側の妥当性検証ではユーザーが指定したすべての入力がブラウザレベルで迅速に検証されるため、エンドユーザーは中断なく操作性を続けることができます。クライアント側の妥当性検証ではサーバーへのデータのラウンドトリップが不要なため、サーバーの負荷が低減し、パフォーマンスの向上につながりますが、

クライアント側のみに妥当性検証を実装しても悪意のあるユーザーに対する保護対策としては不十分です。多くの場合、攻撃者はクライアント側の妥当性検証を簡単にバイパスできます。これが可能になるのは攻撃者が独自の要求を作成できるためです。あるいは、既存の要求を変更して、Webブラウザクライアントとは別個にサーバーに送信する攻撃方法もあります。たとえば、攻撃者がWebプロキシを利用してWebブラウザとサーバーとの間のHTTPトラフィックを傍受する可能性があります。トラフィックを傍受することにより、攻撃者はクライアント側の妥当性検証が実行された後でパラメータを変更できます。

ユーザーが指定した悪意のあるデータからアプリケーションを保護するには、クライアント側の妥当性検証と共にサーバー側の妥当性検証を実装します。サーバー側の妥当性検証を実装することで、攻撃者がクライアント側の妥当性検証をバイパスするために代替手段（プロキシなど）でアプリケーションにアクセスすることを防ぎます。

サーバー側の妥当性検証では、ホワイトリストの形での厳密な入力妥当性検証も行う必要があります。

セキュアな通信

アプリケーションではHTTPSを用いてネットワーク上のトラフィックを暗号化する必要があります。HTTPSはクライアントアプリケーション（ブラウザ）とサーバーとの間のエンド・ツー・エンドのセキュアな接続を提供します。HTTPSによる通信は移動中のデータの保護に有効です。TLSとSSLは、HTTPSによる通信の機密性とインテグリティを保護する一般的なプロトコルの2つの例です。高レベルでは、サーバーは認証局から指定された有効なSSL証明書を用いてブラウザに対する認証を行います。その後、ブラウザとサーバーはすべてのネットワーク通信の暗号化に使用する共有の秘密を生成します。

アプリケーションサーバーでHTTPSが有効化されていない場合、ブラウザとサーバー間のトラフィックは非暗号化接続でやりとりされます。この場合、攻撃者は重要情報を取得しやすくなります。

アプリケーションサーバーがHTTPSをサポートしている場合でも、すべてのHTTPSの実装に共通して以下の事項を考慮する必要があります。

• TLS v1.2 or v1.1を利用する。できる限りSSL v2、SSL v3、TLS v1.0の利用は避けてください。これらのプロトコルには既知のセキュリティ脆弱性があります。
• 強力な暗号化を用いた暗号のみをサポートする。鍵長が128ビット未満の暗号の使用は避けてください。
• アプリケーションサーバーのTLS圧縮を無効にする。
• クライアント始動の再ネゴシエーションを無効にする。
• HTTPSを適用する。ユーザーがHTTP接続でアプリケーションにアクセスしようとした場合は、該当アプリケーションのHTTPSバージョンにリダイレクトする必要があります。

保存データ

バックエンド・データベース・サーバーに保存されているデータを保護します。攻撃者の目標は重要データを盗むことです。重要データは財務情報や個人識別情報（PII）、個人の医療記録など、多岐にわたる可能性があります。そのため、保存されているデータの保護は極めて重要です。

保存データを保護する場合の一般的な考慮事項を 以下に示します。

• 強力な暗号アルゴリズム（AESなど）を用いてデータを保護する。古い暗号アルゴリズムや非セキュアな暗号アルゴリズム（RC4、DESなど）の使用は避けます。
• 独自の暗号アルゴリズムを作成または実装するのではなく、暗号コミュニティで広く認められているアルゴリズムを使用および実装する。
• 強力な暗号アルゴリズムと共に、強力な暗号鍵（128ビット以上）を使用する。予測可能な方法で派生した暗号鍵の使用は避けます。暗号論的擬似乱数生成器（CSPRNG）（Javaの SecureRandomなど）も鍵の生成に使用できます。鍵を定期的に回転する必要もあります（データの重要度に応じて1～2年ごと）。
• 重要データをコンフィグレーションファイルに保存しない。
• データの送受信や抽出、変換、格納（ETL：extract-transform-load）のプロセスでデータを一時ファイルに保存する必要がある場合、データを一時的に保存した後は一時保存場所から消去する。一時ファイルに保存する必要がある重要情報はアプリケーションで暗号化することをお勧めします。

ロギング

ロギングはWebアプリケーションセキュリティにおいて不可欠です。ログファイルはセキュリティインシデントの特定に役立ち、アプリケーションの問題やアプリケーションが直面し得る異常な状態に関する情報を提供します。アプリケーションやユーザーアカウントが攻撃にさらされた場合、アプリケーションがログファイルに記録した情報が、攻撃を把握し、場合によっては攻撃者を突き止めるうえで決定的に重要です。したがって、ロギングシステムは開発者とシステム管理者にとって大いに有益です。ロギングの設計および保守は、以下の点を考慮して慎重に行ってください。

• アプリケーションはセキュリティイベント（認証成功/失敗イベント、認可失敗イベント、セッションcookieの変更、データ妥当性検証の失敗など）をログに記録する必要があります。
• アプリケーションで重要情報（ログイン資格情報、PII、クレジットカードまたは決済情報、セッションIDの値など）をログに記録しないでください。
• ログの保存には強力な暗号アルゴリズムを使用します。
• アクセス制御による制限を設けてログファイルへのアクセスを制限します。ログファイルへの書き込みアクセス権は対象アプリケーションのみに与えます。ログファイルの読み取り権限も制限し、定期的に見直します。ログファイルのすべてのアクセスを記録して監視し、可能であれば事前の承認を要求します。