クラウド事業者の経営状況が原因の場合

　通常、クラウド事業者の経営状況または技術が原因でサービスの提供が中止される場合、サービス提供中止に伴う顧客データなどの取り扱いは、そのサービスの規約や約款など、取引条件を定めた契約に記載されている。そもそも契約にこのような事態に至った際の取り扱いについて記載がないのなら、そのサービスを利用するのは考えものであるし、データサルベージ（救出）に提供される期間が極端に短い場合も、利用者が自身のデータ回収のために殺到する事態を想定すると良心的とは言い難い。とはいえ最終的には、クラウドサービスの契約も役務契約の一種であるから、そのサービス契約の準拠法に基づいて事業者都合による契約解除時の取り扱いは決まる。クラウドだから特別なルールがあるわけではない。

　それでも30％もの回答者がクラウドのサービス提供中止に不安を感じている理由とは何だろうか。筆者は2009年ごろにクラウドサービスの提供中止事例として日本でも紹介された幾つかの事例が原因の1つになっているように思える。

　例えば、Computerworldが2009年6月に「オンライン・ストレージ・サービスが突然終了――そのときデータはどうなるのか？」と題した記事を公開した。ここで例として挙げられている閉鎖したサービスは、AOL「Xdrive」「AOL Pictures」、HP「Upline」、Sony「Image Station」、Yahoo「Briefcase」（参考：米Yahoo!、オンラインストレージ「Yahoo! Briefcase」を終了）、「Digital Railroad」「TheLinkup」だが、AOLの2サービスと米Yahooの3サービスは無償サービスであった。また、HP「Upline」は有償サービスであったため、一部返金処理を行っている（参考：HP Upline、開始早々にサービス停止――非米国在住者のアカウント停止、返金も）。Sony「Image Station」はShutterflyを受け皿にサービスを移行している（参考：Shutterfly welcomes Sony ImageStation customers）。“サービス閉鎖”だけが記憶されているのではないだろうか。確かに同記事で詳しく紹介されているDigital Railroadのサービス閉鎖手順は褒められたものではないが、このような無償サービスの例を基にクラウド事業者のサービス中止時の振る舞いを一般化するのは賢明な行為とはいえないだろう。

　実際にクラウド事業者の経営破綻が発生した場合は、2001年に米連邦破産法11条適用を申請し2002年にC&Wに買収されたExodus Communicationsや、2005年に経営破綻し民事再生を申請した平成電電が2006年に日本テレコム（現ソフトバンクテレコム）に事業譲渡されたケースに近いシナリオで処理される可能性が高いと考える。ただし、これは破綻した事業者の事業内容などにもよる。

クラウド事業者の技術が原因の場合

　次に技術的な問題が原因となる場合だが、そもそもサービス提供が中断されるほどの障害がどの程度発生しているのかが分からないことには話を始められない。クラウドに関して信頼できる障害統計はまだ存在しないが、Open Security Foundationが収集しているクラウドインシデントを利用することで仮説は用意できそうだ。ここで収集されたインシデントは全部で493。最も古いデータは1998年で、2010年4月設立の同組織がどのようにして収集したのかは分かららないが、まずは全量集計してみよう。自動更新失敗（AutoFail）40件、データ喪失（Dataloss）4件、不正侵入（Hack）20件、機能停止（Outage）359件、脆弱性（Vulnerability）70件がそれぞれ掲載されている。

　このうち、クラウドやWebホスティングなどのIaaS関連サービスに絞り込むと該当件数は187件、内訳は機能停止（Outage）178件、不正侵入（Hack）9件となった。Open Security Foundationが収集している範囲では、IaaS層でのデータ喪失事案は存在しなかった。掲載されているインシデントの発生元事業者はAmazon Web Services、GoGrid、Heroku、Microsoft、Rackspaceなどとなっている。筆者の経験からもこの出現率構成比は妥当なものと見受ける。

　さて、本稿で問題になるのはデータ喪失に当たるわけだが、収集された全インシデント中4件で、わずか1％を占めるにすぎない。しかし、先にも挙げたTheLinkupのサービス閉鎖原因は移行失敗によるデータ喪失であったし（参考：Loss of customer data spurs closure of online storage service 'The Linkup'）、2011年5月のNTT PCコミュニケーションズが提供していたCLOUD9の障害と販売停止も、利用者データ不整合の発生が原因の1つだ（参考：NTTPCコミュニケーションズ 工事障害情報）。発生確率は低いが、一度発生すると利用者、事業者双方の事業継続を脅かす事態に陥りやすい重要な要素であり、筆者もこのリスクを挙げた回答者の根源的不安は理解できる。しかし、データ喪失リスクをゼロにすることはできない。そのようなSLA条件を提示している事業者は皆無であり、そもそも物理的に実現不可能だ。

犯罪行為が原因の場合

　残る犯罪行為が原因となる場合についてだが、総務省の資料に米国愛国者法適用事例と間違って紹介されている、2009年4月のCore IP Networks LLCに対するFBIによる家宅捜索と機材押収の件がこれに該当する。実は、この家宅捜索の後、Core IP Networks LLC CEOマイケル・フォークナー氏は詐欺の陰謀に関与したとして起訴され、その後、有罪となっており同社は現存しない（ちなみに愛国者法は裁判所の令状を要さず執行可能だが、この家宅捜索の際は令状が発行されていた）。IP Networks LLCの場合、事業規模が小さく、CEO自身が犯罪に加担していたためサービスが閉鎖されてしまったが、2011年6月に同じくFBIによる強制捜査を受けたDigital One（同社に収容されていた顧客システムが捜査対象）は、現在も事業を継続している（参考：深夜、FBIがデータセンターを強制捜査しサーバ押収。国際的なサイバー犯罪摘発のためと）。事業者自身が犯罪に加担しているCore IP Networks LLCの場合は問題外だが、ガバナンスモデルに基づいてきちんと法務・電子証拠開示ドメインに対応した施策を施している事業者は、強制捜査の手が入ったとしても事業継続にかかわるほどの問題にはなり得ないといえるだろう。

　日本に当てはめて考えると、2010年の刑法犯総数は49万7356件で、不正アクセス禁止法違反、コンピュータ・電磁的記録対象犯罪、ネットワーク利用犯罪は併せても6933件で1.4％を占めるにすぎない。こういった問題は事業者選定に当たって行う評価という観点からすると、天が落ちてくることを憂えるに等しく、本稿で挙げた1、つまり連載第4回後編「クラウドが直面する各国の法制度　～パトリオット法の影響とは？」で紹介したようにカントリーリスクの一部として把握すべき領域だ。

単一事業者に依存したシステム構築は単一障害点になりかねない

　とはいえ、ここまで見てきたように、サービス提供中止やデータ喪失事故の発生率は低そうだが、一時的なサービス停止は十分現実的なリスクといえるだろう。また、データ喪失は発生率こそ低いものの、一度発生すると利用者おろか事業者自身の事業継続性まで揺るがすリスク要素といえる。こういった問題に対しては冗長化によって障害（同時）発生リスクを分散するのが実務的に正しい態度だ。単一の事業者に依存していてはこの問題に実効性のある解を得ることはできない。そう、データを回収できると想定して対策を立てるのではなく、データを回収できなくなる可能性に備えてデータを冗長化しておくべきだ。この考え方の延長上にNISTが言うハイブリッドクラウドが存在するし、その実現に当たってクラウドブローカーというアクターも定義されている。

　ハイブリッドクラウドによる冗長化手法については並列・平行コンピューティングの話と、マスターデータマネジメントとデータライフサイクルマネジメントの話も併せてしなければならないので別の機会に譲ることにするが、本稿では単一事業者に依存したシステムを構築する場合はデータ回収不能となるリスクを受け入れる覚悟をしておく必要があることだけ強く主張しておきたい。クラウド事業者を1社しか選択しないという判断自体が単一障害点（SPOF：Single Point of Failure）を作り出しているからだ。こう書くと、「クラウド事業者がストレージやシステムの冗長化に責任を負うのが筋ではないか？」と問われてしまいそうだ。なるほど、クラウド事業者自身、自身の保有する資源を冗長構成し可用性確保に努めているだろう。しかし、ガバナンスという観点から見ると、冗長化したシステムを保有するクラウド事業者自体が利用者の事業システムを構成する要素の1つにすぎないのだ。クラウド利用が進むことによってシステムの捉え方をこれまでより一段マクロな視点にスライドさせるべき時期に来ているとご理解いただきたい。

　クラウド利用の進展によるシステム把握粒度のマクロ化とは、言い換えると低位粒度のブラックボックス化でもある。この点、2011年12月に発生した、「さくらのクラウド」での障害発生と終息の経緯をまとめたブログを読むと、利用者から見えなくなった部分、その歯がゆさがどれほどのものかよく理解できる。しかし、2011年4月に起きたAmazon Web ServicesのAmazon EBS障害に見られるように、「障害発生→対策→報告・改善計画・SLAに基づく補償」（この件ではSLA条件から導かれる補償条件より実際の補償内容は良かった）といった形式が一般化しつつある。補償はSLAを含む規約、規定、約款などの役務契約記載の条件に従って行われるようになるだろう。

業界分野別の標準化規定

　ここまでで連載第1回「“オレオレクラウド”にはこりごり、クラウドの本質を知る」から扱ってきた経済産業省企業IT動向調査で表れていた疑問に対する回答は一通り済んだことになる。

　第1回では、“クラウド”はバズワードではなく、NISTを中心としてさまざまな団体が連携し標準化に取り組まれている厳格な定義を備えた産業・技術体系としての姿を現しつつあること。

　第2回は、単純な時間当たりコストでクラウドとオンプレミスは同等コストであり、時間当たりの稼働率を加味したコストではクラウドが優位にあること。

　第3回で、そもそも絶対的な安全は存在しないことと、利用者自身のガバナンス体制の確立の重要性、さらに利用者のガバナンス体制に見合うガバナンス体制を持つクラウド事業者選定の重要性。

　第4回前編で、相互運用性確保にはまずクラウドのガバナンス、実装、制御の各モデルの整備を進め、整理された各モデルの関係を足掛かりにハイブリッドクラウドを実現することによって初めて確保できるようになること。

　第4回後編で、国や地域によって異なる法規の影響を考慮した利用計画が必要であるが、国を超えた共同規制の枠組み作りが進んでいること。

　第5回で、客観的な性能評価や比較方法の整備状況と来たるべきPaaS中心の利用が実現した際のマネジメントモデル。

　それぞれについて解説し、今回クラウド事業者がサービスを中止する理由と事例について見てきた。この数年でさまざまな点で進歩してはいるが現在も進化途上にある現在進行形の分野であることを納得いただけたかと思う。一般論として説明すると現在進行形の分野であるが故の不備がさまざまに存在するが、一般論を離れ一定の分野に話を絞ると今の時点でも解決策が見えてくる例があるのでここで紹介しておきたい。

　本連載第3回「クラウドは安全か？　事業者との責任分界点、注目すべき安全基準とは」で紹介したCSA Security Guidanceのリスクドメインモデルを覚えておられるだろうか。同モデルを開発したCSAは2011年8月に、CMM（Cloud Controls Matrix）という

• COBIT 4.1
• ISO/IEC 27001-2005
• NIST SP800-53 R3（連邦政府情報システムにおける推奨セキュリティ管理策）
• PCI DSS v2.0、BITS Shared Assessment SIG v6.0/AUP v5.0（Shared Assessmentはその名の通り、共同アセスメントプログラムで一種の第三者認証を提供）
• GAPP（米国会計基準で採用されているプライバシー原則で、Generally Accepted Privacy Principlesの略。AICPA/CICA Privacy Frameworkを改定して成立した）
• Jericho Forum （The Open Forumの下部組織でセキュリティを専門に扱っている）
• NERC CIP（北米の電力事業者向けセキュリティ標準）
• FedRAMP（米国連邦政府のセキュリティ統制をベースラインで評価する標準）（関連記事：米国発クラウドセキュリティ標準「FedRAMP」はどれほど効果があるのか？）
• HIPAA /HITECH Act（医療保険の相互運用性と説明責任に関する法律と健康情報技術に関する法律のセット）

の各規定の関係を整理した大変な労作のマトリックスを公開している。このマトリックスを見るだけでもCMMが多様な産業でのクラウド利用に対し、各分野向け標準の互換性確認を進めていることがよく理解できるはずだ。筆者は、これだけ多くの分野別標準を網羅したリストであるにもかかわらず、これら標準や法律の中でコントロール項目別に要求する実装を具体的に提示しているものがPCI DSSv2.0以外皆無であることに注目している。

規定内容が具体的かつインセンティブモデルを持つPCI DSSv2.0

　例えば、PCI DSSv2.0では要件11の4項で「侵入検知システムや侵入防止システムを使用して、カード会員データ環境との境界およびカード会員データ環境内の重要なポイントを通過する全てのトラフィックを監視し、侵害の疑いがある場合は担当者に警告する。全ての侵入検知および防止エンジン、ベースライン、シグネチャを最新状態に保つ」ことを要求している。他の規格などであれば要件11記載の「セキュリティシステムおよびプロセスを定期的にテストする」といった粒度で記載が終わり、実装粒度は実装側に任されてしまう（ただし、改善していく義務は負う）ところだが、PCI DSSでは念を入れて補足するc項で「IDS/IPS構成を調査し、IDS/IPSデバイスが最適な保護を実現するためのベンダーの指示に従って構成、保守、更新されていることを確認する」ことまで要件として規定している。

　VISAが公開している資料によると、実際にPCIサービスプロバイダー認証を受けているホスティング事業者は、2012年1月9日時点でRackspaceを含む110社。ちなみにAmazon Web ServicesはMerchant Services領域で登録されているのでこの110社には入らない。

　筆者が見る限り、日本のクラウド事業者は1社も登録されていないようだ。あらゆるサービスがクラウドに移植されていくということは、あらゆる取引がクラウドに移植されていくということでもある。コンシューマライゼーションとともにクラウド上に取引が移行していくと予測される中、この状況は少々心配になる。楽天のように認証は取得しているがリスト掲載はしていない、ということなら良いのだが、と願っている（参考：「楽天市場」の決済プロセスがECサイトで初めて完全準拠　～クレジットカード業界の情報セキュリティ基準「PCIDSS」）。

　話を戻すとPCI DSSが興味深いのは規定が他の標準と比較して圧倒的に具体的に記述されている、という点だけではない。PCI DSS規格は、VISAが主導して国際カードブランド5社が設立したPCI SSCが管理している。中でも主唱者であるVISAは、PCI DSSv2.0認証を取得している加盟店からカード情報などが流出、不正使用された場合、その加盟店などの管理責任を負うアクワイアラ（加盟店管理業者。多くは、加盟店を統括する銀行やその他金融機関）の損害補償義務を免除しているのだ。つまり、非常に具体的でかつハードルの高い仕様を提示する代わりに、問題発生時のリスクをVISAが肩代わりするというトレードオフを作って認証取得インセンティブを高めているわけだ。これは非常に賢い戦略といえるだろう。PCI DSS規格が具体的かつ定量的に記述されているのは、このインセンティブモデルを作るために一定の水準確保が必須だったから、という側面がある。具体的なインセンティブを用意することで高いハードルを短い期間で乗り越えさせて高度なシステムの普及を一挙に進めるという考え方であり、さらにその考え方が有効であることまで認証取得実績で証明している。「順次改善していけばよい」「まずは規格準拠を始めることが肝要」と緩やかな入り口を設定している多くの規格とは対照的な戦略だ。

　さて、次回は引き続きPCI DSSについて見て行くとともに、第三者認証の問題などを検討する。余裕があればNIST SP500-292/293やService Oriented Cloud Computing Infrastructure Frameworkなども扱ってみたい。