ソフトウェア・インテグリティ

 

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

アプリケーション・セキュリティとソフトウェア・セキュリティはどう違うか という問題を検討し、それぞれの規範をどのような場合に用いるかを説明します。


「アプリケーション・セキュリティ」と「ソフトウェア・セキュリティ」は多くの場合に同義語として用いられますが。実際には両者には違いがあります。情報セキュリティ分野のパイオニア、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)は、単なるアプリケーション・セキュリティの枠を超え、あらゆる種類のソフトウェアを包含する総合的なアプローチを構想する必要があります。

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

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

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

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