![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
クラウド・サービスのセキュリティー・ポリシーは、クラウド・サービスのセキュリティーのさまざまな側面に焦点を当てますが、その焦点の当て方は、SaaS、PaaS、IaaS のどのサービス提供モデルのスキームについて言及しているかによって異なります。
- SaaS (Software as a Service)
のポリシーで焦点を当てるのは、コンシューマーが個人であるか、企業であるか、政府機関であるかに関わらず、コンシューマーにレンタルする特定のアプリケーションへのアクセス管理です。SaaS
アプケーションは、悪意のあるインスタンス・リソースを割り当てるマルウェア・アプリケーションからの攻撃に対して脆弱であるため、このリスクを軽減するようにポリシーで対処しなければなりません。例えば、歯科医院が指定した業務時間内に、歯科助手はアプリケーションの承認を受けて、歯科診察記録をダウンロードできるとします。この診察記録をダウンロードできる時間帯は、悪意のあるハッカーにとって都合の良い早朝の時間帯に変更されるというリスクがあります。
- PaaS (Platform as a Service)
のポリシーでは、独立系ソフトウェア・ベンダー、新興企業、あるいは大企業の部門によって作成されてホストされるアプリケーションのビジネス・ライフサイクル全体を通して、データを保護すること、そしてアプリケーションへのアクセスを管理することに焦点が当てられます。例えば、ハッカーが歯科診察記録を台無しにするためにボットネットを使用してマルウェア・アプリケーションをインストールする場合、PaaS
はボットネットの操作を指揮する指令室 (CnC) として使用されます。ポリシーでは、このように PaaS が使用されるリスクを軽減しなければなりません。
- IaaS (Infrastructure as a Service) のポリシーで焦点を当てるのは、クラウド環境内の仮想マシンの管理と、これらの仮想マシンを実装する従来からのコンピューティング・リソースのインフラストラクチャーへのアクセス管理です。IaaS のポリシーは、仮想マシンに対するリスクを軽減する上で、ガバナンス・フレームワークに対処しなければなりません。仮想マシン内や仮想マシン間のインフラストラクチャーに対して悪意のある変更を加えるためにボットネットが使用される場合、IaaS はそのボットネットの操作を指揮する指令室 (CnC) として使用されてきました。
この記事ではクラウド・サービスのセキュリティー問題で重要となる側面を簡単に説明した後、リスク・アセスメント・プログラムの一環となる、リスクを軽減する方法について説明します。
クラウド・サービスのセキュリティーを脅かすものには以下のものがあります。
- 欠陥のあるハイパーバイザー
- しきい値ポリシーの欠如
- 負荷が重くなりすぎたロード・バランシング
- セキュアでない暗号化
これから上記のそれぞれについて、詳しく検討していきます。
ハイパーバイザーは、複数のオペレーティング・システムが 1 つのハードウェア・ホストを共有することを可能にします。すべてのタイプのクラウド・サービスは、このハイパーバイザー上で稼働する仮想マシンで実行されます。クラウド・サービスには、さまざまな信頼レベルのユーザーやテナント、そしてクラウド管理者がアクセスします。例えば、あるテナントは特定の SaaS へのアクセスに関して 1000 ユーザーのライセンス契約を持っていたりします。
ハイパーバイザーに欠陥がある場合、あるいはそのセキュリティーが侵害された場合には、インスタンス・リソースおよびデータ・リクエスト・キューのすべてのセキュリティーが侵害されます。すると、ハッカーがワークロードの需要の急増中にインスタンス・リソースやデータ・リクエスト・キューの使用量を監視するためのしきい値ポリシー (「しきい値ポリシー」に関する詳細はこちらを読んでください) に対して悪意のある操作を行う可能性が出てきます。仮想マシン間の通信に使用される内部仮想ネットワークの制御には、セキュリティー・ポリシーを実施するだけの可視性がありません。そのため、仮想マシンのネットワークを制御する任務と、仮想マシンのセキュリティーを制御する任務との間には、明確な一線を引けない可能性があります。
ハッカーが高度な特権を持つユーザーとなって管理制御権を利用して仮想マシンから抜け出し、悪意のあるプログラムをハイパーバイザー上で実行する可能性もあります。例えば、ハッカーがディレクトリー・ファイルにアクセスして、インスタンス・リソースを他の仮想マシンに悪質な目的で割り当て直したとすると、1 つの仮想マシン上でテナント間のストレージ、メモリー、ルーティング、そして信用を分離するメカニズムが機能しなくなります。
ハッカーは、仮想マシン内で再び割り当てられたインスタンス・リソースのパージ後の残留データから、機密情報を盗むことも可能です。ハッカーは欠陥のあるハイパーバイザーを利用して、正常な仮想マシンの近隣にある仮想マシンを特定し、そのアクティビティーをモニターします。そしてその近隣の仮想マシン内に入り込み、悪意のあるコードを PaaS アプリケーションに追加する恐れがあります。
エンド・ユーザーはサービス・プロバイダーと契約する前に、そのプロバイダーのセキュリティー・ポリシーを評価する必要があります。クラウド・コンピューティングのセキュリティー態勢を自社内の環境と比較し、クラウド内のインスタンス・リソース、ユーザー、データ・リクエストの各しきい値ポリシーが、サービス・プロバイダーのセキュリティー・ポリシーに含まれていることを確認してください。
リソースしきい値ポリシーは、ワークロードの需要の急増に伴って追加されたインスタンス・リソースの使用状況を監視する上で役立ちます。ユーザーしきい値ポリシーは、あるクラウド・サービスのタイプに同時にログインしているユーザー数およびログオフしたユーザー数、さらにはログインしているユーザー数がライセンスで規定された同時最大ユーザー数に達しているかどうかをチェックします。
これらのポリシーを確立しないことで生じるリスクには、以下のものがあります。
- リソースしきい値ポリシーが確立されていない場合、インスタンス・リソースが最大容量に達したことが認識されないため、クラウド・サービス・プロバイダーからの警告もなく、サービスが停止することになる可能性があります。
- ユーザーしきい値ポリシーが確立されていない場合、同時ユーザー数が最大数に達しつつあることも、クラウド・サービスを利用し終わってからログオフしていないユーザーが何人いるのかも把握することができません。これらのログインしたままのユーザーは、ハッカーに悪用される可能性があります。
- データ・リクエストしきい値ポリシーが確立されていない場合、データ・リクエスト・キューの空き容量を把握することができないため、ハッカーが悪意のあるデータ・リクエスト (SQL で注入したリクエストなど) でキューを溢れさせるようにすることで、データ・リクエスト・キューが最大容量に達してしまう可能性があります。
ロード・バランシングは、インスタンス・リソースおよびデータ・リクエスト・キューの負荷を分散する手段です。例えば、各インスタンス・リソースの負荷がその容量の 50 パーセント以下に抑えられていれば、あるインスタンスに障害が発生したとしても、正常なインスタンスがビジネス・トランザクションを引き継ぐことができます。
あるキューに障害が発生したとしても、そのキューを宛先とするデータ・リクエストを正常なキューが引き継げるように、キューに入れられたデータ・リクエストによる各キューの負荷は、キュー容量の 50 パーセント以下に抑えておかなければなりません。
インスタンス・リソースのロード・バランシングが仮想マシン内のマルウェア・アプリケーションによって損なわれると、悪意のあるトランザクションによってインスタンス・リソースのフラッドが引き起こされ、それぞれのリソースが容量の 100 パーセントにまで達してしまう可能性があります。
ロード・バランシングで負荷が重くなりすぎすると、インスタンス・リソースまたは負荷共有の冗長構成といったフェイルオーバー・メカニズムを活かすことができなくなるため、障害の発生したリソース・インスタンスから正常なインスタンスにビジネス・トランザクションを移すことは不可能になります。
データの機密性と完全性を確保するには、何らかの形での暗号化が必要です。機密データや個人的なデータではないとしても、クラウドとの間でデータの受け渡しを行う場合や、クラウド内でデータを操作する場合には、暗号化によってデータを保護しなければなりません。
ハッカーが暗号解読法の進化や悪意のあるインスタンス・リソースを利用することによって、暗号化アルゴリズムがセキュアではなくなる恐れがあります。ハッカーは暗号化アルゴリズムに潜む欠陥を探り出した後、暗号化アルゴリズムに悪意のある変更を加えることで、強力な暗号化を強度の低いものに変えてしまいます。
ハッカーはさらに踏み込んで、最新バージョンの暗号化アルゴリズムを突き止めて、自分のマシンでリバース・エンジニアリングを行い、アルゴリズムの仕組みを探り出す場合もあります。
リスクを軽減するコスト効果の高い方法では、セキュリティー制御を適用します。これにより、アセットの脆弱性が悪用されてセキュリティー上の脅威が組み込まれる可能性を低くすることができます。
リスクの軽減に取り組む前に、保護するアセットを特定する必要があります。以下に挙げるのは最も簡単なリスク・アセスメントの方法です。
- アセットを特定する
- リスクを分析する
- セキュリティー対策を適用する
- 実行後またはイベント発生後の評価を行う
念頭に置いておくべき重要な概念は、どの段階においても上記のステップを振り返り、後で追加された変数や気付いていなかった変数を組み込めることです。
まずは、アセットを特定するところから始めます。特定する対象となるアセットは、ハードウェア、ソフトウェア、ネットワーク・コンポーネント、要員、ユーザー、ドキュメント、施設など、クラウド・サービスのタイプを直接構成するアセットです。これらのアセットを特定してリスクの軽減に取り組んでいる際に、特定のアセットが除外されていたことがわかった場合には、いつでもステップ 1 に戻り、アセットのインベントリーを更新してからステップ 2 を繰り返すことができます。
ステップ 3 でセキュリティー対策を分析するなかで、特定のリスクに対処していないことが判明したら、ステップ 2 に戻ってそのリスクを分析し、脅威が脆弱性を悪用するリスクそれぞれの潜在的損失または確率を判断します。ステップ 3 からステップ 1 に戻って、保護するアセットのインベントリーを更新することもできます。
ステップ 4 では、リスク・アセスメント・プログラムを定期的に再評価します。これを行う理由は、新たなリスク、コスト効果の高いセキュリティー制御、新しく登場したインフラストラクチャー技術、そして新しい法案などによる影響をリスク・アセスメント・プログラムは受けるからです。
ここからは、各ステップについて詳しく説明します。
クラウドのコンシューマーとプロバイダーの両方が、ハードウェアおよびソフトウェア・アセットを特定し、各アセットを置き換える際のコストを見積もる必要があります。また、アセットのインベントリーを維持し、定期的に更新する必要もあります。アセットは、組織の再編や、よりエネルギー効率に優れた技術、より優れたフェイルオーバー・メカニズム、そして管轄の境界を超えたデータ・プライバシーのエクスポートに関する新しい法案によって変更される可能性があるためです。
コンシューマーが特定しなければならないハードウェアおよびソフトウェア・アセットの数は、SaaS プロバイダーからサービスをレンタルする場合には、コンシューマーが制御できる範囲が大きい PaaS を使用する場合や、それよりもさらに範囲が大きい IaaS を使用する場合よりも少なくなります。
以下に、特定する必要のあるアセットを、クラウド・サービスのタイプごとに説明します。
SaaS のアセット
クラウド・コンシューマーが制御できるのは、コンシューマーのデスクトップ、ラップトップ、またはモバイル機器からアプリケーションにアクセスする方法だけです。そのため、特定する必要があるアセットは、モバイル機器のオペレーティング・システム、アプリケーション、およびデフォルト・プログラムということになります。このことから、機器アセットのインベントリーは、SaaS で使用するプログラムとアプリケーションだけに絞り込むことが重要です。同じ機器上にある SaaS にアクセスするために必要なプログラムと私的なプログラム (ダウンロードしたゲームなど) をインベントリーに混在させるのは賢明ではありません。
クラウド・プロバイダーは、少なくとも以下のアセットを制御する必要があります。
- オペレーティング・システム
- ハードウェア
- ネットワーク・インフラストラクチャー
- アクセス管理アプリケーション
- インスタンス・リソース
- SaaS アプリケーションのアップグレードとパッチ
クラウド・コンシューマーには、上記のアセットを特定する責任はありません。
PaaS のアセット
この場合、クラウド・コンシューマーが特定しなければならないアセットは、コンシューマーが制御可能なアセットです。つまり、プラットフォームのビジネス・ライフサイクル全体で、すべてのアプリケーションを特定します (例えば、スプレッドシート、ワード・プロセッサー、バックアップ、課金、給与処理、請求などのアプリケーション)。
PaaS セットアップでクラウド・プロバイダーが制御しなければならないアセットには、少なくとも以下のものがあります。
- オペレーティング・システム
- ハードウェア
- ネットワーク・インフラストラクチャー
- インスタンス・リソース
クラウド・コンシューマーには、上記のアセットを特定する責任はありません。
IaaS のアセット
クラウド・コンシューマーが特定しなければならないアセットは、コンシューマーが制御可能なアセットです。これには、オペレーティング・システム、ネットワーク機器、そして仮想マシン・レベルでのデプロイ済みアプリケーションが含まれます。コンシューマーは、インスタンス・リソースや仮想サーバーの数、またはストレージ域のブロック数を増減することができます。
インフラストラクチャー、および基礎となるコンポーネントについては、クラウド・コンシューマーは制御することができません。これらのアセットについては、プロバイダーが特定する必要があります。
リスクとは、脅威によってクラウド・サービスの脆弱性が悪用される潜在的損失または確率です。コスト効果の高い対策が講じられていなければ、クラウド・サービスは脆弱になりやすくなり、その脆弱性が悪用されることで、クラウド・サービスの脅威となります。
アセットに対するリスクの潜在的損失は、それぞれのアセットが抱えるリスクの影響に依存します (つまり、ユーザーが常に使用できるドキュメント・アセットの場合には潜在的損失はありませんが、十分な対策が講じられていないクラウド環境内のインスタンス・リソース・アセットの場合には 0.96 という高い値となります)。また、1 年間に脅威が発生する頻度によっても、アセットに対するリスクの潜在的損失は左右されます。
脆弱性が悪用される仕組み
ここで、ハッカーがクラウドに伴うさまざまな脆弱性をまとめて悪用し、インスタンス・リソースのアセットに対して攻撃を仕掛ける方法を単純な例で説明します。ここで取り上げる脆弱性は、以下のとおりです。
- アプリケーションでのしきい値モジュールの欠如
- インスタンス・リソース内の残留データ
- 仮想ネットワークでの不十分なネットワーク・ベースの制御
- 特権ユーザーに対する不十分な監視
優れたアプリケーションは複数のモジュールに分けられていて、これらのモジュールが相互にやりとりしてタスクあるいは一連のタスクを行います。モジュールに分けることで、開発者は既存のモジュールを再利用したり新規モジュールを追加したりするという方法で、簡単にアプリケーションにモジュールを追加できるようになります。アプリケーションにしきい値モジュール (インスタンス・リソースにはその最大容量よりも低く設定、データ・リクエストには別のレベルを設定) がなければ、コンシューマーにも、プロバイダーにも、インスタンス・リソースまたはデータ・リクエストが最大容量に達しているかどうかを知る手段がありません。また、正常な仮想マシンが収容された物理サーバーに、ハッカーが悪意のある仮想マシンを作成したとしても、それが発覚したときには後の祭りです。その一例は、DoS (Denial of Service: サービス不能) 攻撃です。ハッカーは、悪意のある仮想マシンの近隣を、悪意のあるインスタンス・リソースと悪意のあるデータ・リクエスト・キューで溢れかえらせることによってサービスを妨害します。そうすることで、物理サーバーの最大容量に到達するまで、被害者が仮想マシンの数を増やすように仕向けるというわけです。
データの残留は、以前に割り当てられていたインスタンス・リソースのデータが完全にパージされずに、同じユーザーまたは別のユーザーに割り当て直されると発生します。インスタンス・リソースには、メモリー、キャッシュ、プロセス、セッション、しきい値、そしてストレージ・リソースなどがあります。ハッカーはインスタンス・リソースの内部を調べて、被害者の個人情報を入手します。
仮想ネットワークでの不十分なネットワーク・ベースの制御は、ネットワーク・レベルで機能するセキュリティー制御が IaaS ネットワーク・インフラストラクチャーで機能しない場合に発生します。これにより、権限を持つ管理者によるインフラストラクチャーへのアクセスが制限されます。ハッカーが利用するのは、IaaS 管理者は仮想ネットワークでは標準的な制御 (IP をベースにネットワークのゾーニングをするなど) を適用できないという事実です。IaaS プロバイダーが信頼できるネットワーク・スキャンを攻撃活動から区別する手段を持っていないとしたら、ネットワーク・ベースの脆弱性スキャンを許可することはできません。また、実際のネットワーク上のトラフィックを仮想ネットワーク上のトラフィック (例えば、同じサーバー上のハイパーバイザーで稼働する複数の仮想マシン間での通信など) と区別するための制御が不十分であるという場合もあります。
特権ユーザーに対する不十分な監視とは、管理アクセス権を持つ特権ユーザーを装ってハイパーバイザーから仮想マシンにアクセスするハッカーが、悪意のあるアクティビティーを行った場合に、そのアクティビティーをプロバイダーが十分に監視しきれていないことを意味します。この場合、例えば管理アクセス権を手に入れたハッカーが悪意のあるインスタンス・リソースとデータ・リクエストのキューを作成しても、プロバイダーはハッカーの行動に気付きません。また、ある仮想マシンの正常なリソース・インスタンスを、悪意のあるインスタンス・リソースとして別の仮想マシンに不当に割り当て直す場合もあります。
脆弱性悪用の重大さのランク付け
さまざまな脆弱性の悪用による潜在的損失については、もちろん皆さんが独自に体系化あるいはランク付けしなければなりません。私は以下の点を基準にランク付けをしています (上に記載したものほどランクへの影響が大きくなっています)。
- ハッカーの侵入方法
- ハッカーが探り出そうとしているターゲット
- ハッカーが使用するツール
ハッカーは例えば、管理アクセス権を持つ特権ユーザーを装って侵入し、正規のシステム管理者が初めは気付かないような悪意のあるアクティビティーを行う可能性があります。また、SQL インジェクションを送信するという手段で侵入し、ファイル名を探り出してファイル内の残留データを探すこともあります。
仮想マシンに侵入しさえすれば、後はハッカー用のツールを使用して、信頼できるネットワーク・スキャンを装った悪意のあるネットワーク・スキャンの攻撃アクティビティーを実行することができます。攻撃アクティビティーには、各アプリケーションに含まれるモジュールのリストを作成することも含まれます。このリストから、ハッカーがアプリケーションにしきい値モジュールが含まれていないことを発見すれば、ツールを使用または作成して、インスタンス・リソースの最大容量に達するまでインスタンス・リソースを作成し続ける可能性があります。
リスク・アセスメントの次のステップは、概念の上では比較的簡単ですが、多くの物事と同様に、実際に行うとなると多少難しくなります。それは、リスクを軽減するための対策がコスト効果に優れていて、その対策を実装するコストに匹敵するだけのメリット、あるいはそれ以上のメリットがあるかどうかを判断することです。脅威が脆弱性を悪用するリスクの確率を低くすれば、ROI は高くなります。
重要な点は、コスト効果の高い対策ではないことがわかった場合、リスクはそのまま残り、これらのリスクを軽減することはできないということです。その場合、リスクを受け入れ、それ以上のコストをかけないことを学ぶ必要があります。これは、リスク・アセスメントやリスク軽減において最も受け入れ難い概念の 1 つですが、リスクのなかには、それを軽減してメリットをもたらすにはコストがかかり過ぎるものもあるということです。
けれども、そのまま残されているリスクがあまりにも多く、コスト効果の高い対策があまりにも少ない場合には、リスク・アセスメントの手順を繰り返す必要があります。それには以下の理由があります。
- リスク・アセスメントやリスク軽減に取り組むのが初めてだったとしたら、この手順を数回繰り返して、アセットを特定するスキル、リスクを分析して理解するスキル、そして適用できる可能性のある対策の全容を把握して適用可能な方法を決定するスキルを磨くことが推奨されます。
- コストを上回るメリットをもたらす新しい対策およびクラウド・インフラストラクチャー技術を見逃さないように常に注意していることも必要です。
- あるいは別の方法として、対策を実装する場合よりもコストが低い場合には、保険を購入して残されているリスクを引き渡すことを検討する必要があります。
以下に挙げるのは、この記事ですでに取り上げた対策の例です。
- インスタンス・リソース、ユーザー、およびデータ・リクエストのしきい値ポリシーが規定されていることを確実にする。
- インスタンス・リソースを再び割り当てる前に、残留データをパージする。
- フェイルオーバー・メカニズム、ビジネス継続性、および災害時復旧の計画を実施する。
- 特権ユーザーを監視し、これらのユーザーの素性とログイン/ログオフ・アクティビティーをチェックするとともに、物理監視サーバー、ネットワーク、およびインフラストラクチャーを構成するその他のコンポーネントの正常性をチェックする。
- コンシューマーとプロバイダーに、リスクの軽減および対策によってもたらされるメリットについての情報を提供する。
リスク・アセスメントは 3 年ごとに行うことになりますが、以下の事態が発生した場合には、それよりも短い周期でリスク・アセスメントを実施する必要があります。
- ソフトウェア、ハードウェア、ネットワーク・アセットに影響する可能性のある新しいクラウド・サービス技術が登場した場合
- 新たな脆弱性と新たな脅威が出現した場合
- 以前は残留リスクとして分類されたリスクを効果的に軽減できる新しい対策が適用可能になった場合
- 新しいリスク軽減手法が考案された場合
- 組織の変更 (合併など) によって、すべてのカテゴリーのアセットに大きな影響があった場合
- 管轄の境界を超えて法律およびコンプライアンス関連の規制に大きな変更があった場合
実際、組織のクラウド・サービスのリスク・アセスメントおよびリスクの軽減を担当しているとしたら、週に一度は情報データベース・サービスで、こうした事態に関する情報をチェックする必要があるはずです。新たな脅威と脆弱性に関するニュース・フィードを作成することを検討してください。
クラウド・サービスのリスクを軽減すると共に、サービスの高可用性 (高い値のアップタイム) を維持するためには、事前のリスク計画によって、各クラウド・タイプで特定する必要のあるアセット、分析対象とするリスク、コスト効果の高い対策、そしてリスクを軽減した後に評価しなければならない内容を明らかにしておく必要があります。チームを構成する開発者、ユーザー、ビジネス・アナリストが協力して、クラウド・サービスにまだ残っているリスクを減らしていかなければなりません。チームは事前のリスク計画によってさまざまな情報を明らかにしておくことで、クラウド・サービスに対するリスクを軽減する作業が大幅に容易になるということがわかるはずです。
学ぶために
- この記事の著者が、記事「クラウド内のワークロードを分散させる:
しきい値ポリシーを使ってワークロードへの要求を動的に分散させる」および「クラウド・コンピューティングとグリッド・コンピューティングの比較:
サービスのタイプ、類似点と相違点、そして検討しなければならない点」のなかで、しきい値ポリシーについて説明しています。
- この著者が記事「アプリケーションの動作を変更する:
社内からクラウドへ」で、アプリケーションをクラウドにマイグレーションするためにアプリケーションを変更するにあたっての先を見越した対応と反応的な対応の違いを説明しています。
- developerWorks
のクラウド開発者向けリソースで、クラウド開発プロジェクトを作成しているアプリケーションおよびサービス開発者たちの知識と経験を調べて共有してください。
- developerWorks の SOA and web
services および Industries で、この記事の話題に関連する developerWorks リソースをさらに見つけてください。
- 次のステップ: IBM
Smart Business Development and Test on the IBM Cloud にアクセスする方法を調べてください。
製品や技術を入手するために
- IBM Smart Business Development
and Test on the IBM Cloud で使用できる製品イメージを調べてください。
議論するために
- developerWorks
のクラウド・コンピューティング・グループの一員になってください。
- developerWorks
でクラウドに関する優れたブログのすべてを読んでください。
- 専門家のネットワークであるとともに、互いにつながりを持ち、共有、協力するためのコミュニティー・ツールが集められている
developerWorks コミュニティーに加わってください。
