目次


PaaS を脆弱性テストのベースに使用する

セキュリティー・テストのさまざまな概念とモデルを探る (クラウド・セキュリティーのテストベッドの構築は簡単ではありません)

Comments

さまざまなシナリオでのセキュリティー・テストの各種概念を使用して、脆弱性テストのベースとして PaaS (Platform as a Service) を使用することを検討してみましょう。この記事では、セキュリティー・テストの概念について評価、統合、定義する方法を説明した後、それらの概念をさまざまなシナリオと関連付けることで、さらに詳しく説明します。

しかし難しい概念についての説明を始める前に、まずユーザー PaaS モデルの構造について調べ、このトピックについて理解しましょう。

ユーザー PaaS モデルの構造

ユーザー PaaS モデルの構造には以下の 3 つのタイプがあります。

  • 「アプリケーション開発ライフサイクル」のプロセスでは、要件の定義から始まり、設計、コーディング、セキュリティー・テスト、デプロイメントのステージに至るまで、PaaS 上のアプリケーションを追跡します。
  • 「リスク管理ライフサイクル」では、アセットの特定からコスト効果の高い対策の実行に至るまで、リスク軽減のためのプロセスを追跡します。リスクというのは攻撃者が 1 つまたは複数の脆弱性を悪用する恐れのことです。
  • 「ビジネス・プロセス・ライフサイクル」では、開発者が PaaS の各ステージでアプリケーションを制御、保護することができます。このサイクルの一環として、開発者はスプレッドシート、ワード・プロセッサー、課金ツール、およびその他のビジネス・ツールを使用します。

では、これらのライフサイクル同士がセキュリティー・テストに関して互いにどう関係するのか、単純化して見てみましょう。

  • リスク管理ライフサイクルでは、PaaS テスターはアプリケーション開発にとってのリスクを明らかにし、リスクに基づいたセキュリティー・テストの手法を作成します。
  • アプリケーション開発ライフサイクルでは、テスターはそのリスクに基づいた手法を適用します。
  • ビジネス・プロセス・ライフサイクルでは、テスターはスプレッドシートやドキュメントを使用して、リスク・ベースのセキュリティー・テストの結果を脆弱性の評価を含めて記録します。

では、一般的なセキュリティー・テスト・モデルについて見てみましょう。

セキュリティー・テスト・モデル

標準やフレームワークを拠り所にして、最も脆弱なリンクを見つけ、侵入テストを実行するだけでは、以下の 3 つのタイプのセキュリティー問題を発見、検出する上では不十分です。

  • PaaS アプリケーションの設計レベルでのセキュリティーの欠陥
  • PaaS アプリケーションの実行レベルでのセキュリティーのバグ
  • PaaS プラットフォーム・レベルでのリソース不足

より適切なソリューションとしては、脆弱性テストのベースに PaaS を使用してセキュリティー・テスト・モデルを設定することです。このモデルは以下のようなフェーズで構成されます。

  • 発見ステージ
  • 自動脆弱性スキャン
  • 脆弱性評価プロセス
  • セキュリティー評価プロセス
  • 侵入テスト
  • セキュリティー監査
  • セキュリティー・レビュー

「発見ステージ」フェーズは、このセキュリティー・テスト・モデルの基礎であり、後続フェーズのビルディング・ブロックでもあります。このモデルを使用することにより、どのフェーズにおいてもギャップを検出して分析してから、次のフェーズに進むことができます。このプロセスはセキュリティー・レビュー・フェーズに達するまで繰り返されます。

どのフェーズにおいてもセキュリティー・テスト上の問題があることをテスターが発見した場合、テスターは前のフェーズに戻り、新しい情報を使用してテスト・プロセスを繰り返した後で、次のフェーズに進むことができます。

テスターは、前のステージに戻らなければならない回数について、独自の制限を設ける必要があります。その制限回数に達するまで、テスターは各フェーズでの新しいセキュリティー・テストや改善されたセキュリティー・テストの結果をドキュメント化する必要があります。

では、これらの各ステージについて調べ、さまざまなシナリオと結び付けてみましょう。

発見ステージ: SaaS のアップグレード

発見ステージは、脆弱性テストのベースとして PaaS を使用するセキュリティー・テストの最初のステージです。

発見ステージとは何か

まず、どのようなアプリケーションが PaaS 上で開発され、テストされているのかを特定します。次に、そのアプリケーションに以下のような脆弱性が潜在していないかの検出、つまり発見を試みます。

  • アプリケーションのロジックに欠陥がある
  • ユーザーからのクエリーへの応答が遅い
  • データベース接続の構成が不適切

これらの情報は多くの場合、コードやログを含むドキュメントの中に見つけることができます。

問題シナリオ

オンプレミスで適切に実行されるアプリケーションが、SaaS (Software as a Service) アプリケーションとしては適切に実行されないことがわかりました。このアプリケーションをクラウド内で実行してみると、このアプリケーションにはインジェクション攻撃に対する脆弱性 (無効なデータを処理することで生じる脆弱性) があることがわかります。

解決シナリオ

オンプレミスでアプリケーションのコードを調べた後、インジェクション攻撃のシミュレーションを PaaS テスト環境で実行します。

自動脆弱性スキャン: IaaS のアップグレード

発見ステージを終えたら、既知のセキュリティー問題が起きないかどうかを探します。そのためには、自動脆弱性スキャン・ツール (1 つまたは複数) を使用して、既知の脆弱性が発生する条件との突き合わせを行います。

自動脆弱性スキャンとは何か

このタイプのツールは、自動的にリスク・レベルを設定し、それらのレベルの検証や解釈に人間の介在を必要としません。このツールをクレデンシャル・ベースのスキャンで補完することができます。クレデンシャル・ベースのスキャンは、与えられたクレデンシャルを使用してローカル・アカウント・サービスに対する認証を行うため、よくある一部の誤検出をなくすのに役立ちます。

問題シナリオ

IaaS (Infrastructure as a Service) がアップグレードされ (この IaaS 上では PaaS が実行されます)、脆弱性が潜在している可能性のある仮想マシンが追加されました。

仮想環境では、ファイアウォール、ルーター、スイッチ、IPS (Intrusion Prevention System: 侵入防止システム) 機器を使用して実現される隔離ゾーンやセキュリティー・ゾーンを作成することができます。ただし、仮想マシン (VM) は IaaS 上の一定の場所にあるわけではないため、システムのセキュリティー・ルールをこれらの VM に一貫して適用するのは困難です。

解決シナリオ

セキュリティー・ポリシー管理ツールを入手し、VM 管理を統括するプロセスが存在しているかどうかを判断します。こうすることにより、VM の場所が変化すると、必要なセキュリティー機能を新しい場所に複製する機能がトリガーされるようになります。

仮想化に対応したソリューションを探します。仮想化対応つまり VM 対応のシステムやネットワーク・コンポーネントであれば、集中管理コンソール・ツールが、VM を追跡、モニター、そして変化する適切なポリシーで更新するのを支援する VM を特定することができます。こうしたソリューションは、さらなる可視性と制御を実現するための VMM/ハイパーバイザーのネットワーク・セキュリティー・ポリシーを管理できるように支援します。

脆弱性評価プロセス: 複数ホストによる脆弱性

脆弱性評価プロセス・ステージは、発見プロセスと脆弱性スキャン・フェーズの上に構築され、セキュリティーの脆弱性を特定するために使われます。

脆弱性評価プロセスとは何か

脆弱性評価プロセスでは、セキュリティーの脆弱性に関する発見をテスト対象の PaaS 環境に反映させます。例としては、レポートに含まれる、よくある誤検出をなくすことや、レポートで発見された各事項に適用すべきリスク・レベルを判断することなどがあります。

問題シナリオ

ある PaaS 開発者のクラウド・リソース最適化アプリケーションは、実際にはそのアプリケーションに障害が発生しているのに、ユーザーが正常に PaaS にアクセスしたという誤検出のレポートを生成しています。

この障害によって、PaaS プラットフォームは完全にシャットダウンされます。このアプリケーションは障害を特定することも、タイムアウトを短くすることもしません。この問題は、サービス・レベル・アグリーメント (SLA) の可用性保証の判断に必要なパフォーマンス・データにマイナスの影響を与えます。

この PaaS 開発者が作成したサービスは、単一ホストで構成される単純なサービスではありませんでした。ホストが 1 つであれば、サービス・インスタンスの複製を作成することができ、ホストに障害が発生した場合にも問題を回避できたはずです。この PaaS 開発者は、そのような構成にはせず、相互に依存する複数のホストで構成されるサービスを作成してしまい、ホストに障害が発生すると問題を回避できないことに気付きましたが遅すぎました。

この開発者が相互依存の複数ホストをどのように構築したのか、調べてみましょう。この開発者が作成したアプリケーションが A、B、C というビジネス・ロジック・コンポーネントで構成される課金アプリケーションである場合、以下のようにサービス・グループを構成することができます。

(A1, B1, C1)、(A2, B2, C2)、(An, Bn, Cn) と記述する場合、n はコンポーネント・タイプの番号であり、サービス・グループ・カテゴリーの番号を表しています。

  • サービス・カテゴリー 1 の場合は以下のとおりです。
    • A1 はサービス・コードを発見するためのロジックです。
    • B1 は請求にサービス・カテゴリーを挿入するためのロジックです。
    • C1 は郵便番号が正確かどうかを確認するためのロジックです。
  • サービス・カテゴリー 2 の場合は以下のとおりです。
    • A2 はサービス・コードを発見するためのロジックです。
    • B2 は請求にサービス・カテゴリーを挿入するためのロジックです。
    • C2 は郵便番号が正確かどうかを確認するためのロジックです。
  • サービス・カテゴリー n の場合は以下のとおりです。
    • An はサービス・コードを発見するためのロジックです。
    • Bn は請求にサービス・カテゴリーを挿入するためのロジックです。
    • Cn は郵便番号が正確かどうかを確認するためのロジックです。

タイムアウトの時間が長いため、システムの正常性が低下しているときでもユーザーはシステムにアクセスできてしまいます。

解決シナリオ

システムに障害が発生しないように問題を修正するために、開発者は複数のコンポーネントを (A1、A2、…An )、(B1、B2、…Bn)、(C1、C2、…Cn) のような独立プールに分解します。

こうすることにより、開発者は正常なデータ・センターで冗長なサービスのコピーを複数作成することができます。これはつまり、コンポーネント A1 に障害が発生した場合や動作が遅くなった場合にも、同じ独立プール内の他のすべてのコンポーネント (A2 から An まで) に障害が発生することはない、ということです。同様に、2 番目の独立コンポーネント・プール (B1 から Bn まで) や 3 番目のコンポーネント・プール (C1 から Cn まで) に障害が発生することもありません。

その結果、ユーザーは正常なシステムにアクセスすることができ、脆弱性評価プロセスでレポート結果に誤検出が現れることはありません。

セキュリティー評価プロセス: しきい値レベルの注入による脆弱性

セキュリティー評価プロセスは、脆弱性評価プロセスの上に構築されます。セキュリティー評価プロセスでは手作業による検証を追加し、本番フェーズで脆弱性を突いた攻撃にさらされる可能性があるレベルを確認します。

セキュリティー評価プロセスとは何か

セキュリティー評価プロセスでは、脆弱性を悪用して通常以上のアクセスをするようなことはしません。このプロセスでは、システムへの許可されたアクセスという形で行われる検証によって、システム設定の確認や、ログ、システム応答、エラー・メッセージ、およびコードなどの検証、そして数値分析結果の検証などを行うことが可能です。

セキュリティー評価は、対象システムを幅広くテストするためのものであり、特定の脆弱性によってどの程度の深さまで攻撃にさらされる恐れがあるかのテストまでは行いません。

問題シナリオ

年末の買い物シーズンになると、システムは通常よりも高いワークロード需要を検出します。それに対応してシステムは迅速に追加のリソース・インスタンスを作成し、ワークロード需要を動的にバランスさせます。こうした動作を実現するには、通常よりも多くのユーザーとデータ・リクエストがシステムにアクセスできるようにする必要があります。

しきい値レベルが注入されたことにより、不要リソースが解放されず、最終的にシステムは動作を停止します。システムにアクセスして、本番フェーズで脆弱性を突いた攻撃にさらされる恐れがあるレベルを開発者の手で確認する作業は行われませんでした。

解決シナリオ

ログ、システム応答、エラー・メッセージ、コードを地道に確認し、システムに対する許可されたアクセスを検証します。しきい値ポリシーが存在することを手作業で確認し、クラウド・コンピューティング・サービスのコンシューマーとプロバイダーが以下のポリシー作成に当たって何をすべきかの概要を記述します。

  • リソースしきい値ポリシー: クラウド内で実行されるアプリケーションのリソース使用量が、しきい値レベル以下で動的にバランスのとれた状態になるようにします。
  • ユーザーしきい値ポリシー: アプリケーションに同時にアクセスできるユーザーの数は、プロバイダーから提供されるユーザー・ライセンスに規定される上限値、つまりしきい値レベル以下になります。
  • データ・リクエストしきい値ポリシー: アプリケーションに対するデータ・リクエストがしきい値レベル以下で即座に処理されるようになります。

侵入テスト: LDAP/AD インジェクションに対する脆弱性

侵入テストでは、攻撃を受けている PaaS をシミュレートします。このテストはこれまでのステージの上に構築され、これまでのステージで発見された脆弱性を悪用してさらに深く PaaS や IaaS に侵入できるかどうかをテストします。

侵入テストとは何か

侵入テストでは、攻撃者が機密情報にアクセスできるかどうか、あるサービスに関するデータの完全性や可用性に攻撃者が影響を及ぼせるかどうか、そしてそのそれぞれが PaaS に及ぼす影響などをテストします。

それぞれのテストでは、自動化されたツールでは特定できないような脆弱性を見つけるために、テスターが一連の侵入テスト・ツールを使用して、自分の問題解決能力を拠り所にそれぞれの結果を比較します。また侵入テストでは、防御側の能力、つまり防御側が攻撃を検出して適切に対応できるかどうかもテストします。

NIST (National Institute of Standards and Technology: 米国国立標準技術研究所) の SP 800-115 (「参考文献」を参照) によれば、侵入テストで検出される脆弱性の大部分は以下のようなものです。

  • 構成の誤り
  • バッファー・オーバーフロー
  • 不適切な入力検証
  • レース・コンディション
  • ファイルやディレクトリーに対する不適切なパーミッション

侵入テストを行う人は、さらなるテストによって PaaS やベースとなるシステムにダメージが及ぶ前に、いつテストを停止すべきなのかも判断できる必要があります。侵入テストにより、システムを利用できなくなったり、機密データが公開されてしまったりする場合もあり得ます。

問題シナリオ

LDAP/AD インジェクションによる脆弱性を悪用することによってシステムが動作を停止します。ハッカーは、LDAP で特別な意味を持つ文字が、アプリケーションで無効にされないことを悪用します。

LDAP インジェクションは SQL インジェクションとよく似ており、LDAP ステートメントがユーザーから提供されるデータを使用して作成され、アプリケーションで検証されていない場合に発生します。LDAP インジェクションが発生すると、許可されないクエリーに権限を付与したり、LDAP ツリーの内容を変更したり、といった任意のコマンドを実行できてしまいます。

解決シナリオ

外部からの侵入をテストするための最も優れたツールを使用して、LDAP インジェクションと SQL インジェクションに対する脆弱性のテストを行うことを検討します。こうしたツールは、セキュリティーに関する他のタイプの脆弱性 (例えば、XSS (クロスサイト・スクリプティング)、不適切な認証プロトコル、不適切なデータベース接続構成など) のテストもカバーしているはずです。また内部用の適切な侵入テスト・ツールがないかを探し、偶発的な LDAP/AD インジェクションの発生から守る上で、LDAP およびセキュリティー・ポリシーが適切であるかどうかをテストします。

さらに、無線サイトへの侵入テストを行う優れたツールを探し、ウォードライビング (移動する車から脆弱な Wi-Fi ネットワークを探す行為) や中間者攻撃に対するテストを行います。無線セキュリティー・プロトコルが十分セキュアであること、またアクセス・ポイントやクライアント (モバイル端末やノート PC など) が適切に構成されていることを確認します。適切な構成を使用することで、不正なノート PC がなりすましによって、クライアントとアクセス・ポイントとの通信をインターセプトして LDAP/AD マルウェアを注入する試みを、防ぐことができます。モバイル・ノート PC や固定設置のデスクトップ PC を使用し、皆さんが所有する無線ネットワークの中にセキュアではないものがないかどうかを見つけます。

セキュリティー監査プロセス: しきい値ポリシーに違反していないかどうかの検証

セキュリティー監査というのは、ある企業の情報システムが一連の確立されたパフォーマンス基準にどの程度適切に従っているかを測定し、その情報システムのセキュリティーを体系的に評価することです。

セキュリティー監査とは何か

セキュリティー監査は多くの場合、情報システムがどの程度適切に法規制、業界標準、セキュリティー・ポリシーに従っているかを判断するために使用されます。セキュリティー監査では、これまで説明してきたセキュリティー・ツールによる手法を使用することにより、情報システム、情報処理プロセス (機密情報の処理、および非機密情報の処理)、ユーザー・プラクティスに関するセキュリティーを評価します。

問題シナリオ

これまでの説明のセキュリティー・ツールを使用して問題を修正しようとしたにもかかわらず、監査の結果、しきい値レベルが設定されていないことがわかりました。その監査から、しきい値レベルが設定されていない場合は開発者が以下の問題を認識できないことがわかります。

  • リソースが過度に使用されていないかどうか。
  • PaaS にアクセスしようとする開発者の数が、ユーザー・ライセンスで規定された制限に達したかどうか。
  • 開発者が送信するデータ・リクエストがしきい値レベルを越えていないかどうか。

解決シナリオ

監査者は、以下のポリシー作成にあたって開発者が何をすべきかを推奨事項として示す必要があります。

  • リソースしきい値ポリシー: クラウド内で実行されるアプリケーションが動的にバランスのとれた状態でリソースを使用し、しかもリソースの使用量がしきい値レベル以下となるようにします。
  • ユーザーしきい値ポリシー: アプリケーションに同時にアクセスできるユーザーの数は、プロバイダーから提供されるユーザー・ライセンスで規定される限度まで許容され、しかもしきい値レベル以下であるようにします。
  • データ・リクエストしきい値ポリシー: アプリケーションに対するデータ・リクエストが即座に処理されるようにし、しかもデータ・リクエストの数がしきい値レベル以下となるようにします。

しきい値ポリシーでは、数値分析の脆弱性とそれに対処する方法を扱う必要があります。簡単に言えば、切り捨てや四捨五入による誤差が受け入れ可能な限度を超える場合には、得られたメトリクスを調べれば有効値がどの程度失われたかがわかるはずです。良条件の (条件数が小さい) 問題を解決するための、正確な数値を出力するアルゴリズムを作成する専門能力は、おそらくプロバイダーよりも PaaS 開発者の方が高いことから、セキュリティー・レビュー・フェーズに進む前に、確実にしきい値ポリシーが確立されるはずです。

セキュリティー・レビュー・プロセス: コンプライアンスの検証

セキュリティー・レビューでは、業界または社内のセキュリティー・ポリシーがシステム・コンポーネントや製品に適用されていることを検証するプロセスが関わってきます。

セキュリティー・レビューとは何か

セキュリティー・レビューは通常、コードのギャップ分析やレビューを通じて行われるか、設計文書やアーキテクチャー図をレビューすることで行われます。このプロセスでは、他のセキュリティー・ツール手法 (脆弱性評価、セキュリティー評価、侵入テスト、セキュリティー監査など) は使用しません。

問題シナリオ

セキュリティー・レビューの際、ある組織単位が NIST の Special Publication 800-115 「Technical Guide to Information Security Testing and Assessment」の一部の側面に完全には準拠していないことがわかりました。

解決シナリオ

ドキュメントのレビューをすることで、ポリシーや手順の技術面やセキュリティー面が最新かどうかを判断するとともに、ログをレビューすることで、セキュリティー制御によって PaaS の使用状況に関する情報がログとして記録されていることや、その組織がログ管理ポリシーを遵守しているかどうかを確認します。ログ情報の例には以下のようなものがあります。

  • 認証の試みが成功したか失敗したかに関する認証サーバーまたはシステムのログ
  • 悪意のある活動や不適切な使用があったかどうかに関する侵入検知システムや侵入防止システムのログ
  • 脆弱性があることが知られているサービスおよびアプリケーションの情報を記録したセキュリティー・ログ
  • ユーザーしきい値、データ・リクエスト、リソースしきい値のレベルを記録した、しきい値ログ

ほとんどのタイプのログに関し、レビュー時間を短縮できる自動監査ツールがあるはずです。

まとめ

セキュリティー・テストを計画する際には、そのテスト・モデルの各フェーズで、セキュリティー・テストに関する問題を解決するためのベスト・プラクティスを検討する必要があります。テストに関する問題を解決する上で、次のフェーズに進む前に何回まで前のフェーズに戻ることができるのか、制限を設定する必要があります。開発者、マネージャー、ビジネス・アナリストでチームを構成し、ライフサイクルの各ステージでセキュリティー・テストを実行しやすいものにする必要があります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, セキュリティ, DevOps
ArticleID=978388
ArticleTitle=PaaS を脆弱性テストのベースに使用する
publish-date=07312014