仮想リソースを使用した SaaS 指向の Web アプリケーションの脆弱性を軽減するためのポリシーを作成する

さまざまな組織が Web ベースのソフトウェアを利用してビジネス・プロセスを実行し、取引を行い、顧客にサービスを提供しています。締め切りが近づくと、組織は慌ただしくなり、セキュリティー関連の機能を犠牲にして大急ぎでアプリケーションを本番稼働させがちです。こうした反応的なアクションは、標準以下の品質のアプリケーションを生み出す結果になることが多いため、もっと先を見越したソリューションとして、SaaS 指向の Web アプリケーションの脆弱性を軽減するためのポリシーを作成する (そして SaaS ベースのアプリケーション脆弱性スキャナーを併用する) 必要があります。作成するポリシーでは、アプリケーションの中で問題が発生しやすい箇所を想定し、それらの問題を修復するための構成済みのソリューションをいくつか用意しておくようにします。この記事では、そうしたポリシーを作成するためのロードマップを示し、IBM Rational AppScan 製品のスキャナー・ツールを使用した場合の例を説明します。

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。


developerWorks 貢献著者レベル

2012年 7月 26日

クラウド・サービスのプロバイダーは、極めて動的なスケーリングが要求されるような環境下で、物理インフラストラクチャーの状態と仮想リソースを追跡するために、クラウド・サービスの測定ポリシーを規定します。SLA (Service Level Agreement: サービス・レベル・アグリーメント) に規定される測定ポリシーに関して、クラウド・サービスのユーザーがプロバイダーと交渉可能な範囲は、どの程度の範囲をユーザーが制御できるかによります。クラウド・サービスに関してユーザーが制御できる範囲が広ければ広いほど、測定ポリシーを作成する上での変数は多くなります。

この記事では SaaS モデルの考え方を理論的に説明し、実際面では仮想リソースを使用した SaaS 指向の Web アプリケーションの脆弱性を軽減するためのポリシーを作成する方法について説明します。

SLA: 仮想リソース

クラウド・サービスのタイプによって、SLA で規定して追跡 (つまり測定) する必要がある、仮想リソースの可用性が決まります (例えば、サービスの可用性として 99 パーセントを保証することが要求されるなど)。クラウド・サービスの測定ポリシーを作成する際にどんな変数を含めるかは、クラウド・サービスのタイプ、そして仮想リソースの可用性の両方の影響を受けます。

SaaS ベースの仮想リソース

SaaS ユーザーは、大きく分けると以下の 3 つのグループにすることができます。

  • 技術者以外のユーザー
  • アプリケーション開発者
  • Web サイト管理者

SaaS モデルでの要求事項はグループごとに異なります。

  • SaaS のユーザー: エンド・ユーザーが制御できるのは、ノート PC、ネットワーク、モバイル機器などからプロバイダーのアプリケーションへのアクセスのみです。ユーザーは測定ツールにアクセスすることはできません。
  • SaaS のプロバイダー: 少なくとも、プロバイダーはオペレーティング・システム、ハードウェア、ネットワーク・インフラストラクチャー、アプリケーションのアップグレードおよびパッチなどの仮想リソースを制御することができます。プロバイダーは測定ツールを制御することができます。

PaaS ベースの仮想リソース

PaaS (Platform as a Service) ベースの仮想リソースの可用性は、PaaS の契約者がプロバイダーと交渉する SLA に反映されます。SLA では、アプリケーションへのアクセスの管理の他に、データを保護するための仮想リソースによって提供されるサービスの可用性を中心に規定します。

Rational AppScan OnDemand Production Site Monitoring

Web サイト管理者は SaaS モデルを使用することにより、さまざまなアプリケーションやドメインにわたる動的 Web コンテンツ特有のセキュリティー・リスクを常に明らかにして優先順位付けを行い、脆弱性に対して対策をとることができます。Rational AppScan OnDemand Production Site Monitoring (AppScan Monitoring) にはロールに基づいてレポートにアクセスする機能とスキャンを許可する機能があり、また AppScan テスト・ポリシーのサブセットとしての非侵入型ポリシーを活用し、ログインせずに本番サイトを安全にスキャンすることができます。

コードをテストするため、あるいは本番前に Web アプリケーションをスキャンするためのソリューションである Rational AppScan と AppScan Monitoring とを組み合わせると、アプリケーションのライフサイクル全体にわたる完全なセキュリティー・テスト戦略を作成することができます。


SaaS モデルの考え方の実際

ビジネス要件が変更されると、SaaS モデルに対するユーザー要件としきい値要件も変わります。SaaS モデルへのアクセスに Windows Internet Explorer を使用する場合も Mozilla Firefox を使用する場合も、それぞれ独特の落とし穴があります。

ユーザー要件の変更

SaaS ユーザーが制御できる内容は SaaS アプリケーションにアクセスすることのみであり、アプリケーションに同時にアクセスできる技術者以外のユーザーの数は、ユーザー・ライセンスによって制限されます。SaaS の契約者はプロバイダーと交渉し、新しいライセンスでは同時にアクセスできる最大ユーザー数を増やすようにユーザー要件を変更することができます。技術者以外のユーザーは脆弱性テストの対象となるアプリケーションに変更を加えることはできません。

アプリケーション開発者はアプリケーション開発のビジネス・ライフサイクルを制御できるため、アプリケーションや Web サイトの中で SaaS ユーザーが求めるタスクを変更、または追加することができます。アプリケーションまたは Web サイトの動作を変更するごとに、開発者はオンデマンドで脆弱性の検出、スキャン、改善を実行する必要があります。

Web サイト管理者は Web サイトを制御することができます。新しいアプリケーションやアップグレードされたアプリケーションを開発者が起動した後、Web サイト管理者は技術者以外のユーザーやアプリケーション開発者の求めるユーザー要件の変更に対応する必要があります。また、動的にスケールアップまたはスケールダウンすることが可能なリソースを拡張できるように、Web サイト管理者はサイトの構成を変更する必要があります。技術者以外のユーザーとアプリケーション開発者は Web サイトの構成を変更することはできません。

しきい値要件の変更

SaaS の契約者はユーザーしきい値要件を制御できる必要があります。ユーザーしきい値要件では、アプリケーションに同時にアクセスできるユーザーの数を、プロバイダーが発行したユーザー・ライセンスで指定されている最大数以下になるように、つまりしきい値レベル以下になるように設定します。SaaS の契約者はユーザー・ライセンスに記載されたユーザー数の制限を引き上げるように、プロバイダーと交渉する必要があります。

プロバイダーはリソースしきい値ポリシーを制御することができます。このポリシーにより、脆弱性テスト対象のアプリケーションのリソースの使用状況を動的にバランスさせることができます。SaaS の契約者は各ユーザーの役割 (技術者以外のユーザー、アプリケーション開発者、Web サイト管理者) に応じて各ユーザーに割り当てられる動的リソースの量について、プロバイダーと交渉する必要があります。

プロバイダーはデータ・リクエストしきい値を制御します。このしきい値により、アプリケーションに対するデータ・リクエストが即座にしきい値レベル以下になるように確実に処理されます。SaaS の契約者はデータ・リクエストの最大数の変更について、プロバイダーと交渉する必要があります。どこまで最大数を増加できるかは、各ユーザーの役割と、SaaS ユーザーに割り当てられるリソースの量に依存します。

IE と Firefox の落とし穴を回避する

Internet Explorer と Firefox は Rational AppScan OnDemand と AppScan Monitoring へのアクセスに最もよく使われるブラウザーです (この記事の公開時点で Google Chrome がどの程度使用されているかの統計は確認していませんが、おそらく Google Chrome のユーザーは増えていると思います)。どちらのブラウザーを選択するかはユーザーの好み次第です。

Firefox は Internet Explorer よりもページのロードが高速ですが、落とし穴が 1 つあり、メモリーを大量に使用します。Firefox は Internet Explorer よりもメモリー使用量の増え方が速く、アイドル状態の場合もメモリー使用量が増加し続けます。

Firefox がどの程度メモリーを使用するかは以下の要素に影響されます。

  • どのようなアドオンや拡張機能を Firefox に追加してあるか
  • 脆弱性に関する Web アプリケーションのテストや Web サイトの監視に関し、どのくらい長く Rational AppScan を使用するか
  • Firefox が使用されずにアイドル状態となるとなる期間の長さ
  • デスクトップ PC またはノート PC 上で他にどのようなアプリケーションが使用されているか
  • デスクトップ PC またはノート PC に搭載されている CPU の数と使用可能な最大メモリー量
  • アプリケーションの脆弱性をテストする SaaS ユーザーが Rational AppScan を使用している合計時間

CPU が対応できるメモリーの最大量にメモリー使用量が近づくと、ブラウザーの動作が遅くなってきます。

ブラウザーのメモリー使用量が増大することによる落とし穴を避けるためには、以下の 7 つの手順に従ってください。

  1. 脆弱性のテストを終えたら、Rational AppScan OnDemand と AppScan Monitoring から即座にログオフします。
  2. Windows の「タスク マネージャー」を起動します。
  3. 「プロセス」タブを選択します。
  4. firefox.exe (iexplore.exe) のイメージを探します (そして、それぞれのメモリー使用量がどの程度増加しているかを調べます)。
  5. Firefox (IE) のプロセスを選択します。
  6. 「タスク マネージャー」の一番下にある「プロセスの終了」ボタンをクリックします。
  7. 本当にそのプロセスを終了するかどうかを確認するメッセージが表示されたら、再度「プロセスの終了」ボタンをクリックします。

そしてブラウザーを再起動します。Firefox のプラグインや Active X コントロールをインストールするためには許可が必要です。


仮想リソースを使用した SaaS 指向の Web アプリケーションの脆弱性を軽減するためのポリシーをどのようにして作成するか

脆弱性テストの対象となる Web アプリケーションはユーザーが属するグループ (技術者以外のユーザー、アプリケーション開発者、Web サイト管理者) によって異なる可能性があるため、仮想リソースを使用した SaaS 指向の Web アプリケーションの脆弱性を軽減するためのポリシーは、すべての SaaS ユーザーに適用可能なものを作成する必要があります。

ここでは、そうしたポリシーを作成するという単純化されたシナリオを紹介します。以下に挙げるのは、このシナリオにおいてポリシーに含める必要があるチェックリストの各項目に関するヒントです。

  • 目的: ポリシーの目的を記述してください
  • スコープ: ポリシーの範囲を規定してください
  • 背景: ポリシーの背後にある情報を記述してください
  • アクション: しっかりと準備をしてください
  • 制限事項: 制限事項を扱ってください

目的: ポリシーの目的を記述してください

セキュリティー・ポリシーを実行して目標を実現できるように、そのセキュリティー・ポリシーによって何をしようとしているのかを簡単に記述します。以下のようなテンプレートを使用すると、目的を記述する方法についての感覚をつかむことができます。

このポリシーの目的は、SaaS 指向の Rational AppScan OnDemand と Rational AppScan OnDemand Production Site Monitoring をエンド・ユーザー (技術者以外のユーザー、アプリケーション開発者、Web サイト管理者) が使用する上でのセキュリティー・ポリシーを容易に実装できるようにすることです。このポリシーでは、ポリシーの一部として、しきい値レベル、ユーザー要件と脆弱性の特定、そして監視に焦点を絞っています。

スコープ: ポリシーの範囲を規定してください

セキュリティー・ポリシーの適用範囲を明確にすることにより、スコープを定義します。その範囲の中で、どのエンド・ユーザーがそのポリシーの対象となるのか、またそれらのユーザーが企業なのか政府機関なのかを規定します。さらに、ユーザーしきい値レベル、データしきい値レベル、リソースしきい値レベルの最大値と最適値、どんなユーザー要件を満たす必要があるか、そして脆弱性の特定方法と監視方法について規定します。

プロバイダーは、コンシューマーが Rational AppScan OnDemand と AppScan Monitoring にアクセスする際、彼らのアクティビティーがセキュリティー・ポリシーの範囲内に収まっているかどうか (アクセス制御に関するセキュリティー・ポリシーの条項に従っているかどうか) を確認する必要があります。コンシューマーとしてセキュリティー・ポリシーの条項に従うことに合意した後で、ポリシーに規定されている範囲を超えるアクティビティーを行った場合、SaaS ユーザーはポリシー違反のリスクをおかすことになります。その場合には、プロバイダーはポリシーに従わない場合の結果を示すことで、コンシューマーのアクティビティーをポリシーの範囲内に収めさせる必要があります。

スコープを記述するためのテンプレートとして、以下を使用することができます。

このポリシーは Rational AppScan OnDemand と Rational AppScan OnDemand Production Site Monitoring を使用するすべての SaaS エンド・ユーザーに適用されます。すべての SaaS エンド・ユーザーはアクセス制御に関し、このセキュリティー・ポリシーのすべての条項に同意し、このセキュリティー・ポリシーに関するすべての契約条件を遵守することに同意します。このポリシー、IT ポリシー、規制に違反する行為を行ったすべてのエンド・ユーザー、開発者、Web サイト管理者は、このプロバイダーによるサービスの制限あるいは打ち切りの対象となります。

背景: ポリシーの背後にある情報を記述してください

コンシューマーが最初に知りたがることは、プロバイダーは社内のプロバイダーなのか社外のプロバイダーなのか、プロバイダーと SaaS ユーザーとの間の制御の管理の境界はどこなのか (例えば、SaaS のエンド・ユーザーはほとんど何も制御できない、など)、プロバイダーがどのようにしてアクセス制御の管理やデータの保護、仮想マシンの管理を行い、クラウドのセキュリティーに対する攻撃や SaaS でのインシデントにどう対応するのか、といった点です。

SaaS ユーザーは、セキュリティー・ポリシーがノート PC に対するシステム (そしてユーザーしきい値レベル、データしきい値レベル、リソースしきい値レベル) の回復についてどこまでカバーしているのか、また SLA の規定に従って割引、一定期間の支払い免除、あるいは解約の権利の取得がどの程度早く実現されるのかを知りたがります。

SaaS ユーザーは、いずれかの Rational AppScan 製品に脆弱性が考えられる場合、またそれらの脆弱性を解消するための改善方法に関して、IBM Security Bulletin にアクセスするための方法を知りたがります。

以下のようなテンプレートを使用すると、何を含めればよいかの感覚をつかむことができます。

Rational AppScan OnDemand と Rational AppScan OnDemand Production Site Monitoring は、通信業界の一員である IBM によって外部でホストされています。

ワークロード要求が急増し、システムのパフォーマンスが保証レベルである 30 日間の可用性よりも低下した場合には、プロバイダーは SLA の規定に従い、SaaS ユーザーに対して、割引、一定期間の支払い免除、サービス解約の権利を与える必要があります。

プロバイダーは、しきい値ポリシーや脆弱性軽減ポリシーの例外や制限事項について、コンシューマーに通知しなければなりません。

ユーザー・ライセンスには、以下の 3 種類の最大数が規定されています。

  • アプリケーションに同時にアクセスできるユーザーの数
  • 各ユーザーに割り当てられるリソース・インスタンスの数
  • ワークロード要求が急増した際に処理することが可能なデータ・リクエストの数

アクション: しっかりと準備をしてください

ここでは、コンシューマーを満足させるために、以下の 7 項目のアクションを行うことを提言します。

  • アクション #1: 仮想リソースを使用した SaaS 指向の Web アプリケーションの脆弱性を軽減するためのポリシーのコピーをコンシューマーに送ります。そうすることで、コンシューマーは Rational AppScan OnDemand や AppScan Monitoring に契約する前にポリシーを検討することができ、また疑問を解決することができます。
  • アクション #2: SaaS ユーザー・ライセンスの中に、同時にアクセスできるユーザーの数、それらのユーザー用のリソース・インスタンスの数、そして各ユーザーが処理できるデータ・リクエストの数に関する最大値の制限を明記します。
  • アクション #3: Rational AppScan OnDemand と AppScan Monitoring によってスキャンできる脆弱性の種類を明記します。
  • アクション #4: クラウドを使用する予定のユーザーにクラウドへのアクセスを許可する前に、それらのユーザー全員の経歴チェックを要求します。どの程度詳細に経歴チェックをするかは、脆弱性テストの対象となるアプリケーションの種類や、クラウドを使用する予定のユーザーが属する業界の種類などに依存します。
  • アクション #5: 承認されたクラウド・ユーザーとなるための、セキュリティー意識、データの命名法および扱い方に関するトレーニング・プログラムを脆弱性テスト完了後に実施することを要求します。
  • アクション #6: SaaS ベースのモデルの下位層にあるハードウェア、ソフトウェア、ネットワークのインフラストラクチャーに対するメンテナンスやアップグレードが予定されている場合、それについて事前に注意を促します。
  • アクション #7: ソフトウェアの脆弱性をテストする際にはダミー・データやテスト・データを使用するように注意を促します。機密データを使用することは禁止します。

以下のようなテンプレートを使用することができます。

セキュリティー・トレーニング: プロバイダーは、脆弱性に対する意識や脆弱性の軽減に関し、承認された SaaS ユーザーとなるためのセキュリティー・トレーニングの最低要件を設定します。

事前に通知されたメンテナンス: プロバイダーは、アップグレードをはじめとするメンテナンスのスケジュールを設定します。

経歴チェック: プロバイダーは、クラウドを使用する予定のユーザーに対する経歴チェックの要件を設定します。

SaaS ユーザー・ライセンス: プロバイダーは以下の数に対して最大値を設定します。

  • アプリケーションに同時にアクセスできるユーザーの数
  • ユーザーがアプリケーションにアクセスして実行する際に使用できるリソース・インスタンスの数
  • 利用可能なリソース・インスタンスを使用してユーザーが同時に送受信できるデータ・リクエストの数

テスト・データ: プロバイダーは脆弱性テストの対象となるアプリケーションに使用するテスト・データに関して最低要件を設定します。

制限事項: 制限事項を扱ってください

ほとんどの場合、何らかの制限事項があるものです。例えば次のような制限事項が考えられます。

  • サービスの優先度の問題: 組織がコンシューマーに割り当てた役割により、コンシューマーのグループが異なると優先度も異なる場合があります。SaaS アプリケーションにアクセスする上で、管理者権限を持つエンド・ユーザーは管理者権限を持たないエンド・ユーザーよりも高い優先度を持ちます。
  • 管理ガバナンス・グループの変更: あらゆる変更を反映するために、セキュリティー・ポリシー、しきい値ポリシー、そして SLA を更新する必要があります。
  • クラウド・サービスのタイプに対する例外: 以下にヒントを記載します。例外の例として、プロバイダーが直接制御できる範囲外で光ファイバーが誤って切断された場合や、事前に通知されたメンテナンス (不定期および定期)、そして事前に通知された (先を見越した) アプリケーションのアップグレードなどが挙げられます。
  • セキュリティー・ポリシーに関する契約条件のいずれかを遵守しなかった場合のセキュリティー・ペナルティー: セキュリティー・ポリシーや IT ポリシーの規制に従わなかった場合の結果を規定しておきます。

以下のようなテンプレートを使用することができます。

SaaS のユーザー・ライセンスを管理するエンド・ユーザーは、ライセンスされたアプリケーションにアクセスする上で、他のエンド・ユーザーよりも高い優先度を持ちます。

最近の組織変更により、ポリシー・ガバナンス・グループは FGH 部門から RST 部門に異動しました。そのため、仮想リソースを使用した SaaS 指向の Web アプリケーションの脆弱性を軽減するためのポリシーを更新する必要があります。

サービスの例外として現在認められている事項は以下のとおりです。

  • 事前に通知された、アプリケーションの動作に対する先を見越した変更やアップグレード
  • プロバイダーのホストがボットネットから攻撃を受けた場合
  • プロバイダーによる、事前に通知されたメンテナンス
  • プロバイダーのサービスを通常どおり利用できるのは午前 7 時から午後 6 時まで、サービスの利用が制限されるのは午後 8 時から午後 11 時まで

まとめ

セキュリティー・ポリシーを作成するためには、事前に計画を立て、ポリシーの目的、スコープ、背景をどう記述するかという問題を解決する必要があります。当然ながらクラウド環境ではデータが危険にさらされる可能性があるため、Web アプリケーションのセキュリティーに関して説得力のあるポリシーを作成することが重要です。

開発者はクラウド・サービスのコンシューマーとプロバイダーの両方と話し合い、コンシューマーが制御できる範囲をどの程度にする必要があるか、プロバイダーはどのようなアクションを実行する必要があるか、ポリシーに対する制限事項として何があるか、といった問題を検討する必要があります。最も重要なことは、コンシューマーはプロバイダーからセキュリティー・ポリシーを (そしてしきい値ポリシーも) 入手して内容を確認し、解決すべき疑問点を整理してからプロバイダーと交渉することです。

参考文献

学ぶために

製品や技術を入手するために

  • IBM SmarterCloud Enterprise で利用可能な製品イメージを調べてみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Rational
ArticleID=826709
ArticleTitle=仮想リソースを使用した SaaS 指向の Web アプリケーションの脆弱性を軽減するためのポリシーを作成する
publish-date=07262012