アプリケーションセキュリティとソフトウェアセキュリティ の違い

「アプリケーションセキュリティ」と「ソフトウェアセキュリティ」は多くの場合に同義語として用いられますが。実際には両者には違いがあります。情報セキュリティ分野のパイオニア、Gary McGraw氏によると、アプリケーションセキュリティがソフトウェアのデプロイ後に発生する事後的アプローチであるのに対し、ソフトウェアセキュリティはデプロイ前の段階で対応する予防的アプローチです。

ソフトウェアのセキュリティを確保するには、ソフトウェア開発ライフサイクル（SDLC）の全段階にセキュリティを組み込む必要があります。したがって、ソフトウェアセキュリティはアプリケーションセキュリティとは異なり、はるかに広範なものです。

ソフトウェアセキュリティの一部としてのアプリケーションセキュリティ

ご存知のように、アプリケーションはデータとユーザー（または他のアプリケーション）とを関連付ける役割を果たします。

たとえば、ユーザーが患者の医療情報に関する複雑な解析を行う場合、アプリケーションで簡単に処理を実行することが可能で、複雑な計算はアプリケーションが行います。同様に、オンラインバンキングの取引もWebベースのアプリケーションまたはモバイルアプリで処理され、この過程で非公開の金融データが処理、送信、保存されます。

ソフトウェアはインターネット上で処理または送信されるデータの重要度や機密性を認識しないため、処理するデータの重要度に基づいてソフトウェアを設計・開発する必要があります。「公開」に分類されたデータはユーザー認証なしにアクセスが許可されます。その一例として、Webサイトのお問い合わせページやポリシーページに記載されている情報が挙げられます。ただし、ソフトウェアでユーザー管理を行っている場合には、このような情報へのアクセスに多要素認証方式を導入する必要があります。アプリケーションで処理するデータの分類に基づき、セキュアコーディングを実践すると共に、保存または送受信されるデータの適切な認証、認可、保護をアプリケーションの設計に組み込むことが求められます。

ソフトウェアと関連する重要データを保護するには、SDLCの各フェーズで対策を取る必要があります。この対策は、開発のデプロイ前とデプロイ後のフェーズに大別できます。繰り返しになりますが、ソフトウェア・セキュリティはデプロイ前の問題に対応し、アプリケーションセキュリティはデプロイ後の問題を扱います。

ソフトウェアセキュリティ（デプロイ前）の作業：

• セキュアなソフトウェア設計
• 開発者向けのセキュア・コーディング・ガイドラインの開発
• セキュアなコンフィグレーション手順およびデプロイメントフェーズの標準の策定
• 既定のガイドラインに従ったセキュアコーディング
• ユーザー入力の妥当性検証と適切なエンコーディング方式の実装
• ユーザー認証
• ユーザーセッション管理
• 機能レベルのアクセス制御
• 強力な暗号を用いた保存データと移動中のデータのセキュリティ保護
• サードパーティー・コンポーネントの検証
• ソフトウェア設計/アーキテクチャの欠陥の捕捉

アプリケーションセキュリティ（デプロイ後）の作業：

• デプロイ後のセキュリティテスト
• ソフトウェア環境のコンフィグレーションの欠陥捕捉
• 悪意のあるコードの検出（開発者がバックドアや時限爆弾を作成することによって実装）
• パッチ/アップグレード
• IPフィルタリング
• ロックダウン型実行可能ファイル
• 実行時のプログラム監視によるソフトウェア利用規定の適用

詳細なガイダンスについては、セキュア開発成熟度モデル（BSIMM：Building Security In Maturity Model）の活動をご覧ください。

シナリオ1：Webアプリケーションセキュリティ

Webアプリケーションは多くの場合クライアントサーバー・ベースのアプリケーションで、ブラウザがクライアントとして機能し、サーバーとの間で要求の送信と応答の受信を行ってユーザーに情報を提供します。そのため、Webアプリケーションセキュリティではクライアント側の問題、サーバー側の保護、保存データおよび移動中のデータの保護が課題になります。

クライアント側の問題は、ユーザーインターフェイスの設計時に予防策を考慮しておかないと修正がさらに難しくなります。その一例が、JavaScriptで変更可能なDOMオブジェクトから別のDOMオブジェクトの値を設定するDOMベースのクロスサイト・スクリプティングです。最近のブラウザはアプリケーションの保護が強化されていますが、多くのアプリケーションは現在も下位互換性をサポートしているためユーザーの範囲が幅広く、古いバージョンのブラウザ、非セキュアなクライアントコンピューターにも対応しています。そのため、クライアント側のコンポートはこれらの問題を検討する設計フェーズでセキュリティを実装する必要があります。

サーバー側のコンポーネントはアプリケーション開発の設計・コーディングフェーズで対策を実装することによって保護できますが、そのためにはセキュアなシステム/サーバーソフトウェアをインストールする必要があります。Apache Tomcat（3.1以前）など、古いサーバーソフトウェアは現在では正式にはサポートされておらず、これらのバージョンには報告されていない脆弱性が存在する可能性があります。速やかに最新バージョンにアップグレードすることをお勧めします。

その他の一般的なインフラストラクチャのセキュリティ脆弱性：

• 冗長化サーバーのバナー
• ローカルデータと移動中のデータの保存を許可されているページのキャッシュ
• サーバーでサポートされている弱い暗号スイート
• cookieによって露出された内部ネットワークアドレス
• cookieのセキュリティ

シナリオ2：モバイル・アプリケーション・セキュリティ

最近では、多種多様なオペレーティングシステムやセキュリティ設計が用いられているスマートフォンやタブレットなどのモバイルシステムがWebアプリケーション以上に普及しています。これらの端末およびその端末上で実行されるアプリケーションは、端末に保存された重要データに多大なリスクをもたらす可能性があります。仕事上のEメールや個人の連絡先が信頼されていないネットワークに露出する場合もあります。また、これらのアプリケーションは多くの補助サービスと通信します。端末自体が盗まれる可能性もあります。マルウェアがインストールされることもあり得ます。モバイルアプリのリバースエンジニアリングによって重要な企業データにアクセスされることも考えられます。これらは数ある可能性のほんの一部にすぎません。さらに、モバイル端末上で動作しているマーケティングアプリケーションの中には、テキストメッセージ、通話履歴、連絡先などの個人情報や仕事上の重要情報を収集しているものがあるかもしれません。

モバイルベースのソフトウェアのリスク要因

• アプリケーションのコーディング
• アプリケーションの頒布
• アプリケーションのコンフィグレーション
• 端末のコンフィグレーション

モバイルアプリケーションの設計には、Root化/脱獄の検出、リバースエンジニアリングに対する耐タンパー性、音声、指紋、画像、位置情報を利用した多段認証の機能を組み込むことをお勧めします。セキュアコーディングのガイドラインに従う必要があることは言うまでもありません。

各種のモバイル端末ベンダーに対応したアプリケーションストアは、セキュリティ審査プロセスもさまざまです。配信の過程でアプリケーションの信頼性が毀損されないようにすることが重要です。このフェーズでは耐タンパー性が特に重要です。

これらのアプリケーションを実行する端末はその端末独自のシステムのソフトウェアを使用しており、非セキュアなコンフィグレーションになっている可能性があります。アプリケーションコードの保護、Root化/マルウェアの検出、認証、チャネル検証に関連する端末のコンフィグレーションは、モバイル端末のコンフィグレーション標準に従って行う必要があります。ここで注意を要するのはアプリケーションだけではありません。モバイルソフトウェアのコンフィグレーションも以上のようなあらゆる可能性を考慮し、セキュアな方法で設定しなければなりません。

モバイルアプリケーションへのセキュリティ対策の実装は、Webアプリケーションの場合よりさらに困難です。モバイルアプリケーションでは、Webアプリケーション以上にコードの難読化やタンパー検出（コードの改ざん防止を目的とする）などの対策が求められます。

各種のアプリケーションテスト

テストの目的は、実装バグ、設計・アーキテクチャの欠陥、非セキュアなコンフィグレーションの検出です。以下に、効果的なアプリケーション・セキュリティ・テストをいくつかご紹介します。

1. ソースコードに着目した静的アプリケーション・セキュリティ・テスト（SAST）
2. アプリケーションとインフラストラクチャに存在する脆弱性の検出に着目した動的アプリケーション・セキュリティ・テスト（DAST）
3. DASTとSASTの組み合わせを利用して挙動解析を行い、データフロー、I/Oなどを検出するインタラクティブ・アプリケーション・セキュリティ・テスト（IAST）
4. セッション終了、アプリケーション終了、エラー通知などのアプリケーション・ランタイム・エンジンのセキュリティ機能を利用してアプリケーションの自己保護を可能にするRuntime Application Self Protection（RASP）

とはいえ、アプリケーションセキュリティはソフトウェアセキュリティのさまざまな領域のうちの1つにすぎません。

ソフトウェアのリスク：

• WebまたはWeb以外のアプリケーション/インフラストラクチャ
• セキュリティ上問題がある設計
• 不適切なコンフィグレーション
• 技術的な制約
• 通信の暗号化
• バックエンドデータベースのセキュリティ

以上の2つのシナリオでもわかるように、デプロイ後フェーズのアプリケーションテストはWebアプリケーションとモバイルアプリケーションの場合でさまざまな違いがあります。モバイル・アプリケーションはWebアプリケーションより改ざんされやすい傾向があります。また、モバイル・アプリケーション・セキュリティの最大の要素はモバイル端末ハードウェアのセキュリティです。

ネットワークセキュリティはどこに当てはまるか

ソフトウェアセキュリティに関しては、アプリケーションの実行や特定のアプリケーションによるデータ処理を制限するにはファイアウォールなどのペリフェラルによる対策で十分だという一般の誤解があります。企業はネットワークセキュリティ対策（個別のコンピューターのIPアドレスがインターネット上で直接見られることを防ぐ機能を持つルーターなど）の実装に大きな投資をしています。

その他の一般的な対策：

• 通常のファイアウォール
• 暗号化/複合化プログラム
• ウイルス対策プログラム
• スパイウェア検出/削除プログラム
• 生体認証システム
• データ解析および情報漏えい対策ツール

ベライゾンの2015年度データ漏洩・侵害調査報告書によると、各種のインシデントのうちWebアプリケーションに対する攻撃はわずか9.4%に留まっています。組織のソフトウェアセキュリティ対策（SSI）は、単なるアプリケーションセキュリティの枠を超え、あらゆる種類のソフトウェアを包含する総合的なアプローチを構想する必要があります。

アプリケーションセキュリティとソフトウェアセキュリティの違い：まとめ

アプリケーションセキュリティを確保する方法は、アプリケーションのセキュアコーディングだけではありません。アプリケーションを実行するインフラストラクチャのほか、サーバーやネットワークコンポーネントなどのセキュアなコンフィグレーションも必要になります。アプリケーションのセキュリティを最大限に確保するには、アプリケーションとサーバーのコンフィグレーション、通信の暗号化、認証資格情報と暗号化キーを保存するデータベースのアクセス制御をすべて考慮する必要があります。

最大限のソフトウェア・セキュリティを確保するには、ソフトウェアとそのソフトウェアを実行するインフラストラクチャの両方を保護する必要があります。これにはソフトウェアセキュリティ（設計、コーディング、テストフェーズ）とアプリケーションセキュリティ（デプロイ後のテスト、モニタリング、パッチ適用、アップグレードなど）の両方が含まれます。ソフトウェアセキュリティは組織の情報セキュリティ体制の向上、資産の保護、非公開情報のプライバシー保護を目的とする総合的なアプローチであるのに対し、アプリケーションセキュリティはその全体的なプロセスの一領域にすぎません。

                      アプリケーションセキュリティはソフトウェアセキュリティの第一歩です。