特 集 クラウドセキュリティ＜１＞ 技術的視点からのクラウドのセキュリティ課題 日本クラウドセキュリティアライアンス代表理事、運営委員 アルテア・セキュリティ・コンサルティング代表 ふた ぎ まさあき 二木 真明 ここでは、クラウドのセキュリティについて、技術的視点 利用者に提供している。いわばコンピュータシステムの最終 から考察する。クラウドの様々なサービス形態やサプライチ 製品をサービスとして提供するのだが、いわゆるASP（Appli- ェインの存在がもたらす課題を紹介し、解決の糸口を探って cation Service Provider）との大きな違いは、それぞれの機 みる。 能コンポーネントをユーザ・インターフェイス経由だけでな く、利用者のシステム若しくは他のサービスから機能として 直接利用できることだろう。API（Application Program 1．階層ごとに検討が必要なクラウドセキュリティ Interface）を経由して、ネットワークを経由したシステム連 クラウドをそのアーキテクチャや利用モデルから見ると、 携機能を提供するのである。これにより、利用者はSaaSで提 様々な技術要素に分解することができる。例えば、物理層の 供されるシステムを自らの情報システムに統合して利用する 直上には仮想化層があり、ここでハードウエアリソースの仮 ことができる。SaaSの場合、提供される単位は、ある業務を 想化や多重化、分散処理などが実装されている。この層は仮 サポートするアプリケーションに必要な作業の単位であるこ 想化されたハードウエアイメージを上位層に提供すると同時 とが多い。また、データ受け渡しの機能も提供される。一方、 に、リソースの配分調整や状況を冗長化、サーバやデータセ より基本的な機能、つまり、アプリケーション開発に必要な ンタにまたがる分散処理などの機能を上位層に意識させない フレームワークやミドルウエアの部品を提供するサービスも 形で提供する。いわゆるIaaS（Infrastructure as a Service） ある。このようなサービスは一般にPaaS（Platform as a モデルは、この環境を利用者に提供し、利用者は仮想的な Service）と呼ばれ、利用者が様々なカスタムアプリケーショ サーバとしてその環境を利用する。その上の層には仮想化さ ンをクラウド環境で効率良く開発、運用できる環境を提供す れたサーバごとに、それぞれオペレーティングシステムがあ る。 では、各層ごとに、細部を見ながらそのセキュリティ上の り、その上には通常のコンピュータシステム同様に様々なミ ドルウエアやアプリケーションを導入できる。S a a S 課題を考えてみよう。 （Software as a Service）モデルのサービスでは、こうした環 境の上にある目的のアプリケーションを構築し、その機能を 利用者の守備範囲 ＳａａＳ ＰａａＳ Ｉ ａａＳ 事 業 者 の 守 備 範 囲 I a a S カスタマイズ アプリケーション 運用・管理ツール S a P a a S a S ミドルウエア 開発環境 ＯＳ・基本ソフトウエア 仮想化層 Ｈ／Ｗ 物理層 図１．モデル別に見る事業者と利用者のカバー範囲 18 ITUジャーナル Vol. 45 No. 1（2015, 1） ない。現在では、ネットワークを含めた仮想化ソリューショ 2．物理・ハードウエア層と仮想化層 ンも普及しつつある。SDN（Software Defined Network） 物理層におけるセキュリティについては、従来のデータセ は、一種のネットワーク仮想化だが、幾つかのソリューショ ンタセキュリティの延長上にあるため、ここでは触れないこ ンでは、その中にコンピュータリソースの仮想化も含めて統 とにする。まず、クラウドの基盤とも言うべき仮想化層につ 合されている。つまり、ネットワークを含めたコンピュータ いて考えてみよう。大規模なコンピュータリソースを共有し システム全体を抽象化、仮想化して、リソース利用の効率化 ながら、上位層にあるソフトウエアに対しては、個々に独立 を行うのである。上位層から見れば、独立したコンピュータ したコンピュータであるかのように振る舞うのが仮想化層の リソースが独立したネットワークで接続されているように見 仕事だ。実際のハードウエアリソースの割当てや物理的な構 えるが、実はネットワークも物理的には共用されている。こ 成、地理的配置などを上位層に意識させないように抽象化 の場合も同様に、個々に定義された仮想ネットワークを確実 してしまうハードウエアの抽象化層と言うこともできる。上 に分離できるかどうかが課題となる。 位層は、仮想化層自体の挙動を意識する必要はなく、専用 こうした環境の上に、何らかの専用環境、例えば特定企 のハードウエアを利用しているのと同じように構築すること 業の情報システムなどを構築する場合、事業者が前述した課 ができる。裏を返せば、こうした大規模なリソースプールの 題への対応を確実に行っていれば、上位にあるシステムは特 共用に関わるセキュリティ全般は、基本的に仮想化層のみで にクラウドを意識することはない。だが、現実には他のイン 考え、実装する必要があるということになる。ここで最も大 スタンスからは見えないものの、情報の痕跡が事業者のスト きな課題は、上位層同士の論理的な隔離である。例えば、 レージやバックアップデバイス・メディアに残存している場 リソース割当てや解放の過程で、上位層の特定のインスタン 合もある。また、冗長化処理に伴って、データが事業者のネ スの情報が他のインスタンスに漏洩するようなことがあって ットワーク上を、そのまま流れる場合もあるかもしれない。利 はならない。例えそれが、ストレージやメモリの未使用領域 用者がこうした問題を確実に排除したいならば、例えば、上 に残った痕跡であったとしても、である。また、許可された 位層が仮想ストレージに保存するデータをOS等の機能で暗 手段以外での異なる上位層インスタンス間若しくは上位層と 号化するなどの対応も必要になるだろう。この場合、暗号鍵 仮想化層間の通信や干渉も防ぐ必要がある。特定のインス を利用者が管理し、事業者がそれを取得できなければ、物理 タンスが異常なリソース消費を行った場合に他のインスタン 的なストレージなどに残存した情報が事業者や他の利用者に スがその影響を受けるような事態も避けなくてはならない。 漏洩する心配は、ほぼなくなる。 この部分が、クラウドの最も基本的なセキュリティ課題であ る。IaaSのサービスにおいては、事業者側の仕組みとして、 3．アプリケーション構築・運用基盤層 これらをきちんと担保できなければならない。 さて、次にサービスの基盤という視点から、上位層を見て みよう。IaaSは基本的に、コンピュータのハードウエアと同 ハードウエアの抽象化は、コンピュータリソースだけでは 利用者の仮想ＤＣ環境 利用者の仮想ＤＣ環境 ネットワーク サーバ サーバ サーバ ネットワーク サーバ サーバ サーバ サーバ サーバ サーバ サーバ サーバ サーバ 仮想化・抽象化層 ＤＣ間ネットワーク データセンタ・Ｎ／Ｗ サーバ サーバ データセンタ・Ｎ／Ｗ サーバ サーバ サーバ サーバ データセンタ・Ｎ／Ｗ サーバ サーバ サーバ 図２．SDN/仮想化による仮想データセンタ（大規模IaaS） ITUジャーナル Vol. 45 No. 1（2015, 1） 19 特 集 クラウドセキュリティ＜１＞ 等の環境を利用者に提供するものだった。だが、アプリケー ルウエアの機能や開発フレームワークやそのコンポーネント ションをその上に構築したい利用者にとっては、OSから選択 自体の安全性だ。この部分について利用者は基本的に事業 できることのメリットはあまりない。むしろ、アプリケーショ 者に依存せざるを得ない。また、利用者環境の隔離について ンに必要な様々な環境がサービスとして提供されており、そ も、事業者の責任だ。注意が必要なのは、PaaSにおいて の下は意識しなくていい形の方が楽なのである。ただし、利 個々の利用者が利用するリソースは、その下のレベルで分離 用者は自分の好きなようにアプリケーションを構築したい。 されているとは限らない点だ。IaaSで分離されたひとつの環 その場合、必要なアプリケーションを構築するための道具立 境の中で、PaaS事業者は複数の利用者へのサービスを提供 てが提供されるPaaSが最適だ。事業者がPaaSを提供する場 することが多いからである。このような場合、下位層で分離 合、自らハードウエアを含めた基盤を構築する場合と、既存 されないリソースに関しては、PaaS事業者がそれを利用者に のIaaS事業者の環境を借りて構築する場合がある。前者は、 対して分離して提供しなければならない。つまり、IaaS環境 例えばグーグルのように大規模事業者に多い。こうした事業 上に、PaaS事業者のサービスとしてのアクセス制御を実装し 者はハードウエアやOSも含めて、自らが提供するサービスに て、リソースを保護しなければならないのである。PaaSにお 最適化している。もちろん、これらのセキュリティも同様だ。 けるセキュリティのもう一つの側面は、フレームワークとし 一方で後者のモデルは比較的小規模な事業者向けである。 てのセキュリティ機能の提供である。PaaSはアプリケーショ IaaSを使用すれば小規模な企業であっても、特色のある内容 ン開発の環境を提供する。利用者が開発するアプリケーショ でスケールの大きなサービスを提供することが可能だ。ここ ンにおいても、利用者自身が実装しなければならない多くの では、このような場合の課題を考えてみる。PaaS事業者自身 セキュリティ機能がある。こうした機能を実現するための安 は、その基盤のセキュリティをIaaS事業者に依存せざるを得 全なコンポーネントやフレームワークを事業者がツールとし ない。IaaSを直接利用する利用者同様に、IaaS事業者が提 て提供できれば、利用者がアプリケーションにセキュリティ 供するセキュリティのレベルを精査して、足りない部分は他 機能を実装する労力が削減されると同時に、その実装の安全 の手段で補う必要がある。ただし、IaaS事業者が提供するセ 性が高まることになる。PaaSにおいては、こうした機能の提 キュリティやそれに対する補完措置は、あくまでも、PaaS事 供が事業者自身のビジネスにおいての競争力向上にもつなが 業者のサービスが動作するための基盤の安全を保つためのも るだろう。例えば、アプリケーションで実装しなければなら のである点に注意が必要だ。利用者に対してはPaaS事業者 ないユーザ管理と認証や、データへのアクセス制御や暗号化、 自身が、サービスのセキュリティに関する責任を負う必要が ログの保存などのためのコンポーネントが提供されることで、 ある。 こうした機能をアプリケーションへ実装することが容易にな PaaSは、様々なアプリケーションを開発、運用するための るだろう。また、複数のアプリケーションにおいて、これら 環境を提供するサービスである。このレベルのセキュリティ を統一的に扱える。さらに、Webアプリケーションが中心に には二つの側面がある。一つは、PaaS事業者が提供するミド なるクラウド開発では、アプリケーションの脆弱性を排除す 利用者ごとのアプリケーション環境 （利用者が開発） 利用者ごとのアプリケーション環境 （利用者が開発） 事 業 者 提 供 開発環境・フレームワーク 事 業 者 が 提 供 アプリケーション実行基盤 仮想システム基盤 物理的システム基盤 ＯＲ 物理的システム基盤 図３．PaaSの構成例 20 ITUジャーナル Vol. 45 No. 1（2015, 1） I a a S るための機能も必要だ。Webフォームからの入力を適切にチ ては、APIもHTTPプロトコルの上に実装されることが多いた ェックして危険な文字入力を排除し、攻撃を防止するような め、一般のWebアプリケーションと同様の脆弱性を内包する ライブラリの提供なども開発者にとっては有益である。 可能性があるので、これらに留意した開発や運用が必要だ。 また、相手がコンピュータシステムであるAPIは、通常のユー ザ操作よりもはるかに高速で大量のデータ処理を必要とする 4．アプリケーション層 ため、利用者側のシステムの不具合や、意図的な攻撃によっ SaaSは、クラウドサービスの最上位層に位置する。PaaS 同様に下位のサービスの上に構築することも可能だ。IaaSの て、事業者側のシステムに悪影響が出ることも予想される。 こうした事態の予防や対処も課題の一つだろう。 上に直接構築する場合もあれば、PaaSで提供されるフレーム ワークやコンポーネントを利用する方法もある。IaaS上での 5．セキュリティ対策のサイクルから見たクラウド 構築は開発に柔軟性を与える反面、開発のための道具立て は自ら用意しなければならない。一方、PaaSを利用する場 セキュリティインシデントの予防という意味合いでのセキ 合、それが提供する開発環境に依存するのと同時に、運用 ュリティ実装は、前述したサプライチェインを意識する必要 する場合は、PaaS事業者が実装しているリソース管理の方 があることや、利用するクラウドのタイプによって、事業者 法によって、クラウドの利点であるスケーラビリティーや構 と利用者のそれぞれが実装、運用すべき範囲が変化する以 成変更の即時性などが制約を受ける場合もある。 外、技術的には、従来までのシステムとほぼ共通である。し SaaSにおいては、アプリケーションの全ての機能を事業者 かし、発生してしまったインシデントへの対処は大きく異な が開発、運用するため、これらに関するセキュリティ確保は る。インシデントへの対応は「発見」 「拡大防止」 「原因究 事業者が行う必要がある。利用者環境の分離は当然として、 明」 「対処」 「被害の復旧」という一連の流れで行われるが、 利用者内部のユーザ及びそのロールや権限の管理、認証機能 いずれもサプライチェインの下で、利用者と事業者間若しく とアクセス制御などを基本として、アクセスログの管理、外 は上位層の事業者と下位層の事業者間での役割分担と協調 部からの攻撃の検知や防御のための仕組みなどが実装され、 が必要になる。とりわけ困難となるのが「原因究明」である。 それらを利用者が必要な範囲で利用するためのインターフェ 利用者、事業者の切り分けが困難なだけでなく、例えば、攻 ースが提供される必要がある。こうしたインターフェースに 撃や不正行為の証拠を収集、保全する際の技術的困難が大 は、利用者側のユーザ自身が直接利用するユーザ・インター きい。クラウドではコンピューティングリソースは物理的、地 フェースと利用者のシステムから機能を利用するためのAPI 理的に分散され、かつ多くの利用者によって共用されている。 （アプリケーション・プログラム・インターフェイス）がある。 このような環境下で特定の利用者の処理や運用に関わる証 前者は対話型のユーザ認証を、後者は、システム間での認証 跡を全て収集することは困難だ。従来、物理的なサーバなど 連携のための仕組みを提供する必要がある。クラウドにおい を利用していた場合、いわゆるコンピュータフォレンジック 利用者ごとの利用環境 （利用者が管理） 利用者ごとの利用環境 （利用者が管理） アプリケーション・サービス （SaaS事業者） アプリケーション実行基盤（ＳａａＳ事業者） ＯＲ 物理的システム基盤 （ＳａａＳ事業者） ＯＲ ＰａａＳ事業者 Ｉ ａａＳ事業者 図４．SaaSの構成例 ITUジャーナル Vol. 45 No. 1（2015, 1） 21 特 集 クラウドセキュリティ＜１＞ 手法を駆使した調査も可能だったが、クラウド環境では、と ド上のサービスとして、こうしたセキュリティ機能を提供し りわけ、他の利用者に影響しない、つまり事業者のサービス ようというセキュリティ専業の事業者だ。SecaaS（Security を阻害しない形での調査は、ほぼ不可能である。こうした問 as a Service）とも呼ばれるこうしたサービス事業者は、利 題を解決するためには、発想を変える必要がある。コンピュ 用者のニーズに応じて、様々なセキュリティ機能を提供する。 ータフォレンジックでは、意図的に記録されている証跡のみ 利用者は、必要なサービスを買い、他のサービス若しくはオ でなく、改ざん、消去された情報の痕跡も取得することで、 ンプレミスのシステムと組み合わせて使用する。ここで、重 発生した事態を推定する作業が行われる。これは、意図的な 要となるのが、こうした付加機能を他のサービスと連携させ 不正行為の場合、証跡が消去、改ざんされる可能性がある るための事業者間インターフェースの標準化である。例えば、 からだ。一方、近年、こうしたコンピュータフォレンジック ユーザ認証、アクセス権管理（Authentication/Authori- 手法に対抗するアンチフォレンジック手法が発達し、こうし zation）の分野では、クラウドから多要素認証などの強固な た痕跡を発見できないケースも多くなっている。このため最 ユーザ認証とシングル・サインオンなどの機能を提供するサ 近では、事後のこうした調査に頼るだけでなく、あらかじめ、 ービスでは、アプリケーションがその認証や、アクセス許可 改ざん、消去が困難な形で、十分な証跡を取得し、保存し の問合せを外部のサービスに委ねるためのフレームワークが ておくという考え方が主流になりつつある。これは、街角に 必要になる。現在、クラウドの世界では、この分野が最も進 設置される監視カメラなどと同じ発想に基づくものだ。クラ んでおり、SAML（Security Assertion Markup Language） 、 ウドでは、正にこの考え方が重要である。利用者や外部者が OAuth、OpenID/OpenID Connectといった国際標準、業 変更、削除できない形で、事業者が証跡を保存するのはもち 界標準に準拠することが一般化しつつある。これによって、 ろんのこと、事業者自身も内部者の不正を見つけ出すことが 一つの認証プロバイダで認証しつつ、様々なクラウド上のサ できるような仕組みを作り、正しく運用していくことが重要 ービスや、オンプレミスのシステムを同一のユーザアカウン だろう。そして、こうした情報を必要に応じて利用者が取得 トに束ねることができるのである。今後、こうしたインター できるようにするためのインターフェースの提供も重要であ フェースの共通化は他の分野のサービスでも必要となる。た る。利用者固有の証跡に加え、事業者の管理状況やインシ とえば、ストレージの暗号化だ。クラウド利用における利用 デントの発生といった、利用者の安全に直結するような情報 者の最も大きな懸念点の一つを解消する技術は間違いなく強 についても、こうしたインターフェースを介して利用者が取 度の高い暗号化技術だが、暗号鍵を利用者自身が、ストレ 得できるようになれば、クラウドを利用する上での利用者の ージを提供する事業者とは分離した形で管理できなければ、 不安を払拭することにもつながるだろう。 どのような強力な暗号方式でも意味がない。例えば、ストレ ージ事業者は、暗号化機能とその管理のためのインターフェ ースのみを提供し、別の事業者が鍵生成やその管理サービス 6．セキュリティもクラウド化するSecaaS を提供する形が考えられるが、この場合、鍵管理を提供する さて、従来型（オンプレミス）のシステムでは、こうした 事業者と利用者や暗号機能を提供する事業者との間に標準 システムに組み込まれたセキュリティ機能以外に、様々なセ 化された鍵受け渡しのインターフェースが存在することが普 キュリティに特化したシステム（ハードウエア、ソフトウエ 及の鍵となるだろう。 ア）が導入されてきた。ファイアウォール、侵入検知・防御、 マルウエア対策、ログ管理と監視、高度な認証とシングル・ サインオンを提供するような認証システムといったものだ。ク ラウドにおいても同様の機能は必要になるが、利用者が自由 7．サプライチェインで考える SaaSなどのクラウドサービスとオンプレミスシステムを有 にこれらを導入することは困難である。とりわけ、SaaSや、 機的に結合させて情報システムを構築する「ハイブリッドク PaaSにおいて事業者側でこうした機能が提供されていない場 ラウド」はクラウド利用の王道と言えるが、SaaSが提供する 合に、利用者が取り得る手段は非常に限られる。事業者側 個々の機能同様に、SecaaSのセキュリティ機能もまたこれら としても、サービスのセキュリティそのものは重要だが、全 のビルディングブロックの一部と考えるべきだ。 ての利用者が使うわけではない付加機能にあまり多くの投資 ができないという事情がある。そこで登場するのが、クラウ 22 ITUジャーナル Vol. 45 No. 1（2015, 1） 本来、クラウドは、基盤からアプリケーションまでの様々 利用者ごとのアプリケーション環境 （利用者が開発） 利用者ごとのアプリケーション環境 （利用者が開発） 事 業 者 提 供 開発環境・フレームワーク 事 業 者 が 提 供 アプリケーション実行基盤 仮想システム基盤 物理的システム基盤 ＯＲ 物理的システム基盤 I a a S 図５．APIによるハイブリッドクラウド例 な階層で必要な部品（コンポーネント）をそろえてサービス う発想で考えるなら、セキュリティも含めて検討すべきポイ 化し、利用者がそれらを適材適所で組み合わせて自らの情報 ントはおのずと明らかになるだろう。 システムを構築できるようにすることで、情報システムの更 クラウドの技術的な課題はまだまだ多い。だが、一方で技 新期間やコストを最小化し、ビジネスのスピードに合わせて 術やサービス形態の進化もどんどんスピードアップしている。 最適なシステムを導入できることを目指すものだ。残念なが 利用者と事業者の双方がクラウドの意味を正しく理解するこ ら、我が国のクラウド利用は、まだその進化の過程にあり、 とで、こうした課題が解決され、クラウドの利用が様々な分 そこまでの本格的利用は極めて少ないが、クラウドが、こう 野で常識となる時代は、そう遠くないのかもしれない。 したコンポーネントのサプライチェインで成り立っているとい ITUジャーナル Vol. 45 No. 1（2015, 1） 23
© Copyright 2024 ExpyDoc
