このページの本文へ

TECH担当者のIT業界物見遊山第30回

必要なのはクラウドの情報開示と監査

ファーストサーバショックを超えて業界が取り組むべきこと

2012年07月19日 06時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

6月末に起こったファーストサーバのデータ消失事件は、クラウド普及に大きな冷や水をい浴びせる形となった。ここでは、事件が業界に与える影響と今後なにが必要になるのかを考えていきたい。

顧客データの消失と大きな規模が致命的

 6月20日に発生したファーストサーバ事件の概要は、すでに3本のニュース記事でお伝えしたとおりだ。障害の原因は、サーバーの脆弱性対策を行なう更新プログラムに不備があり、検証環境で不備を検知できず、本番環境でも範囲外のサーバーまですべてのデータを削除してしまったことにある。また、脆弱性対策をバックアップサーバーにおいても同時に行なう仕様になっていたため、本番と同じくバックアップも削除。複数のプログラムミスや運用体制の不備が重なり、未曾有の障害につながっていったのだ。

 今回のファーストサーバの事件で、もっとも致命的だったのは、取り戻しのできないデータの消失で、しかも大規模だった点だ。

 クラウドサービスのダウンやデータ消失は決して珍しいことではない。クラウドサービスの代名詞でもあるAmazon EC2は2011年4月に長時間のサービスダウンがあったほか、2012年6月も米国東部リージョンでシステム障害が起こったばかり。国内でも、2011年5月にはNTTPCコミュニケーションズの「WebARENA CLOUD9」がサービス自体を停止。また、2011年末からは、さくらのクラウドで障害が多発したため、当面サービスを無償化したほか、2012年6月にはニフティクラウドでもサービス障害が発生している。ただ、これらの障害の多くは、サービス自体のダウンで、データ消失も一部にとどまっている。

 これに対して、ファーストサーバは顧客から預かったデータの消失が5000件以上にのぼり、事業者側できちんとバックアップがとられていなかった。実際はバックアップといっても、同一マシンの別のHDDにデータがコピーされていただけなので、マシン単位の障害に対応できなかったのである。しかもファーストサーバの顧客はITにコストをかけられない中小企業がメイン。バックアップをとっていなかったために、サービス自体が再開されても、データが復旧できなったことも多かったようだ。

事件はクラウド反対派の常套句に

 こうしたファーストサーバ事件に対する反応を、ASCII.jpのニュースに対するTwitterのコメントをベースに見ていくと、ざっくり半分が「ファーストサーバの運用や事後対応を批判するもの」で、3割が「クラウドに対する不信感が高くなった」、そして2割が「バックアップの重要性を再認識」といった内容になっていた。多くの読者は、「自分でなくてよかった」と安心しつつ、「ファーストサーバユーザーの辛苦」を思うという感じだった。

 いずれにせよ、ファーストサーバが今後のクラウド普及において、大きな影を落としていくのは間違いない。たとえば、ネットワーク切断といえば9日間の利用不可となった1984年の世田谷局のケーブル火災、情報漏えいといえば450万件の漏えいにつながった2004年のYahoo! BBの事件、停電といえばクレーン船によって高電圧線が切られた2006年の首都圏大規模停電が思い起こされる。今回のファーストサーバ事件は、クラウドのもたらす安心・安全神話を揺るがす事件として同様に記憶され、クラウド反対派がそのメリットを否定する常套句として、「ファーストサーバのようになったら、どうするんだ」と使われてしまうことになる。もとより、外部にデータを預ける危険性やセキュリティは、以前から指摘されたクラウドの課題であるため、反対派にとっては「ほらみたことか」となったわけだ。

 ただ個人的には、今回の事件でクラウドの普及が今後も減速することはないと考えている。グローバルのITベンダーや大手通信事業者がこぞってクラウドサービスや製品をかつぎ、iPhoneのようなコンシューマデバイスのバックエンドまでクラウド化されている昨今、もはやオンプレミスへの後戻りはできない。セキュリティ製品、ビッグデータ、資産管理、基幹系システムなど、クラウドと距離のあったシステムやアプリケーションも次々とクラウドと統合化されており、きちんと市場に根を張っている。

事業者はデータセンターを公開せよ

 とはいえ、事件の教訓を活かし、クラウドを安心して利用できるITプラットフォームに育てて行くには、いくつかの施策が必要になってくる。

 直近で必要になるのは「約款」や「SLA(Service Level Agreement)」の見直しだ。ファーストサーバの事件では、損失したデータに対する損害賠償請求が可能か、大きな論議になっていた。しかし、現状のホスティングやレンタルサーバーのビジネスは、何重もの免責事項によって守られており、顧客データの損失は損害賠償の対象にならない根拠となっている。また、多くのクラウドサービスやデータセンターはサービスの可用性に対してSLAを提供しているが、これも考え直す必要が出てくる。停止時間に対する金銭的な保証は果たして、ユーザーのニーズにあったものなのか? 今後は、こうした約款やSLAの内容が顧客に不利にならないよう、精査されていくべきだろう。

 2つめはやはりデータのバックアップだ。ホスティング事業者はデータの安全性やバックアップ不要といった特徴を営業活動でアピールすることも多い。こうなるとバックアップ不要を謳っているのに、データの損失は補償なしという不利な条件で契約せざるを得ないことになる。今回のケースも、バックアップデータさえ残っていれば、最悪の事態は防げたはずだ。クラウドだからといって安心せず、バックアップをきちんと行なうのは、コンピューターを使うに当たって必須の作業であることを改めて認識しなければならない。また、事業者側も、コスト的な敷居を下げるため、低価格なバックアップメニューを用意したり、場合によっては同業他社のデータセンターにミラーリングするくらいの危機回避策もぜひ検討すべきだ。

 3つめに提唱したいのが、データセンターやサービス情報の開示である。とかく、クラウドインフラやデータセンターは、ユーザー情報のセキュリティを盾に情報が開示されていないことが多い。また、運用体制に関しても、ビジネス面でのノウハウであるため、明らかにしているところはない。しかし、今回のような事件は、運用体制を監査する仕組みがあれば防げたはずだ。システムやネットワーク構成、運用体制、バックアップなどは明示してもらい、正しく運用されているかを第三者にチェックしてもらいたい。

 先日、機会があってAmazon Web Serviceで聞いてみたところ、ストレージサービスのAmazon S3では、こうした第三者による監査やマルチリージョンでのデータ保護などを実施しつつ、運用に関するホワイトペーパーも提供しているという答えが返ってきた。また、最大の弱点とも言えるヒューマンエラーを前提にファイルをバージョン管理する仕組みがあるほか、削除を行なう権限をハードウェアトークンで付与することができるという。これはあくまで参考だが、国内の事業者もクラウドやデータセンターの「ブラックボックス化」は過去の遺物だと考え、運用やシステムの徹底的な透明化を進めてほしい。

 以上の施策は、とても地味だ。しかし、過去を振り返れば、こうした取り組みの積み重ねでしか、信用は取り戻せない。だから、親会社のヤフーをはじめ、ファーストサーバの競合になるすべての事業者も、この事件をスルーせず、サービス向上の糧にしてもらいたい。もちろん、われわれのようなメディアは、こうした地味な施策をきちんと記事で取り上げるべきだ。

カテゴリートップへ

この連載の記事

ASCII.jp特設サイト

クラウド連載/すっきりわかった仮想化技術

ピックアップ