ファーストサーバの事故は、システムの構成、運用体制の不備、人的なミスといった複数の要因が重なったことで大きなものとなった。それぞれの要因は軽微なものであったかもしれないが、それがいくつも重なったことは、果たして"不運"で済まして良いことなのだろうか。今後さらに、クラウドというシステムに、事業が大きく依存していくことが確実ななかで、ユーザー企業側はいったい何に気をつけるべきなのか。一方の事業者側および業界側は、どのように信用を担保していくべきなのか。NPO法人情報セキュリティ研究所の上原哲太郎氏に、今回の事故に関する分析と業界につきつけられた課題をうかがった。なお、本インタビューはあくまでも上原氏個人の意見として伺ったものとなっている。［聞き手：渡辺聡］

上原 哲太郎（うえはら・てつたろう）
工学博士。2006年1月から京都大学学術情報メディアセンター准教授を務めたのち、2011年10月より総務省情報通信国際戦略局通信規格課標準化推進官に就任。2012年7月からは同省情報流通行政局情報流通振興課情報セキュリティ対策室を併任する。NPO法人情報セキュリティ研究所を2002年に設立、副代表理事。2011年より同研究員

（前回までの連載はこちら）

なぜ「フェイルセーフ」が機能しなかったのか

──今回のファーストサーバの事件は、どういうケースであったと理解していますか？

上原氏（以下敬称略）：今回の事故が起きたサービスは"クラウド"といわれていますが、正確にはマネージドサービスと呼ばれるレンタルサーバです。そこで実際に起きたのは、パッチを当てるスクリプトのバグによって「本番サーバとバックアップサーバの両方に消去コマンドが走った」ということのようです。

そこで問題になるのは「バックアップと宣伝していたものが、実は待機系だった」という点です。動いているシステムのスナップショットを取るのがバックアップにもかかわらず、今回の場合はスナップショットではなかった。さらに、パッチを当てる際に、バックアップという名の待機系にも即座に当てるという運用をしていた。その運用が妥当かどうか、というのがひとつの論点になります。

もうひとつ、リカバリーについても気になっています。事故が起きたのはマネージドサーバですが、顧客が解約したり、あるいは何かの都合でマイグレーションしてサーバの移行をしたりといった場合に、ハードディスクをワイプしていなかったと思われる点です。

そのためにリカバリーをしたときに、過去のデータがすべて出てきてしまい、現在の顧客に対するリカバリー作業の困難度が高くなってしまった。特に共用サーバは、リカバリーしたファイルが、どの顧客のものだったのか、正確かつ機械的に振り分けることができなくなったと見ています。それが顧客の被害を拡大してしまった。

──そのような推測が正しいとすると、これまでファーストサーバが営業上うたっていたセキュリティや安全性、また今後の運用について素直に受け入れていいものでしょうか？

上原：今回については、不幸な要因がいくつか重なっているのは確かですが、運用自体は、一般的なトラブルを想定したものとしては、それほど極端にひどいとは思いません。このくらいのコスト構造で実現可能なサービスとしてリーズナブルなものです。

したがって、大きなミスが起きなければ、現在も何の問題もなく運用され続けていたでしょう。バックアップ系統も、軽度のインシデントであれば問題が露見しなかったはずです。

──では、今回のような事件は、ユーザーにとって単に不運で済む話なのか、それとももっと考えるべきところがあるのか、どちらでしょうか？

上原：技術的な観点では、顧客にとって不運な話でした。ただし、私自身の本音では、オペレーションミスに対するフェイルセーフがあまりに効かない構造になっていたことに対して、サーバ運営者に一定の責任を感じてほしいと思っています。いくら安価なサービスとはいえ、フェイルセーフの観点から講じておくべきだった対策がいくつかあります。

1点目は、パッチを当てる際にサーバ群の指定の仕方も含めた、オペレーションミスを防止する仕組みがなかったように見えます。2点目は、本番系とバックアップ系で時間を置いて修正するというオペレーションをしていなかったことです。3点目は、このようなオペレーションミス時のハードディスクのデータリカバリーを想定していたとは思えない全体運用です（注：本インタビュー後に公開された第三者調査委員会の報告書によれば、2点目のシステム変更のバックアップ系への反映は、本来は時間差で行われることになっていたものの、当該オペレーションについては運用者の独自判断でバックアップ系へ同時に適用されていたことが明らかになっている）。

これらの「なぜ、それをやらなかったのか」というポイントが、すべて抜けていることに対して一定の責任はあるのではないかと思っています。

===

「電気通信事業」の延長ではクラウド事業者に届かない規制

上原：事故が起きたサービスはB2Bがメインで、とくにグループウェアやECサイトを運用していた顧客企業へのインパクトは大きなものです。ところが、約款上は安価であるが故に「利用料金を上限とした損害賠償しか負わない」とされています。それ自体は商慣行にのっとったものですが、現実として救済策がないと小さな企業では倒産しかねません。この点は、クラウドサービス全体として業界がどう考えるべきか、試金石だと思います。

クラウドサービスというものは、事業者にとってビジネスのコアにあたる情報を預けると同時に、クラウド基盤の管理責任も預けています。しかし、約款では障害発生への補償は、利用料金を上限にするというのが一般的で、情報資産の毀損や事業機会の遺失利益まではカバーされません。

それに対するリスクヘッジをどこでとるのか、今まできちんと考えてこなかったツケが、今回で明らかになりました。社会的にどういう制度を作っていくのが正しいのか、国がどうやって係わっていくのかというのが、より大きなテーマとして浮かんできます。

──現在のところ国はクラウドサービスに対して、規制するにしろ振興するにしろ、なんらアクションができていないように見えます。

上原：御存知の通りネット関連のサービスは、電気通信事業かどうかで管轄が総務省か経産省か変わります。電気通信事業だとしても、次は通信の主体は誰かという問題が出てきます。

今回のようなB2Bがメインのレンタルサーバの場合は、おそらく電気通信事業の主体は貸している側ではなく借りている顧客側になります。サーバを借りた顧客がメールサーバを運営して情報交換を始めると、通信の主体はあきらかに顧客側になるので法律や規制が及びますが、実はインフラ側には直接の規制は及びません。一番怖いのはこの点です。

クラウド事業者が提供するインフラの上で運営されているサービスに対して、電気通信事業の延長で国から何か統制しても、インフラを提供するクラウド事業者には届かない構造なのです。

例えば、Googleみたいに自分がクラウド基盤を提供しつつ、電気通信事業としてB2BあるいはB2Cのサービスもやっているなら、まだ国による統制が可能です。しかし、今回のファーストサーバのようなケースが一番難しいです。

先日、とあるレジストラ事業者が、自社サービスで登録された他社のドメインを一方的に無効にする事件がありました。これもまったく同じ構造で、レジストラ事業者は電気通信事業者かもしれないけれど、レジストラ事業そのものは電気通信事業ではないので政府の統制が効きません。

こういうインフラに対して、国として網を掛けるのか、それとも掛けないのかというところから、議論をちゃんとしなくてはいけない時期が来ているのだと思います。

===

「自主ガイドラインを守っていたら海外勢に負けてしまう」

──制度とビジネスのボタンの掛け違いは確かにあります。しかも、そのズレが簡単に直せないほど、インターネット界隈が進んでしまっている状態です。

上原：インターネットというものが、これだけのスピードで発達したことに対して、「国があまり網を掛けなかったからだ」という自覚が、実は国にもあるだろうと思うのです。

したがって、消費者保護という目的なら規制に対して国が前向きになることはあり得ますが、B2Bマーケットでのビジネスについては無闇に規制できません。それは政府が守るものではなく業界団体が自主的にすべき、という発想になりやすい。

このように国が出て行きづらい領域については、業界団体が自主ガイドラインを作り、それを皆が守って行く、という仕組みでこれまでは上手くまわっていました。ですが、これだけ経済活動がグローバル化しているなかで、今さら業界団体による自主的な制限ができるものでしょうか。

よく言われるのが、国内の事業者が自主ガイドラインを守っても、それに縛られない海外の会社に競争で負けてしまう、というロジックです。これにどう立ち向かうのかという、悩ましい問題もあります。

──利用者側もきちんと把握しないまま、よくわからないシステムにデータを預けていて、そのことに意識が及んでいません。

上原：少なくとも、クラウドにサービスを載せたりデータを預けたりするにあたり、そのことを経営判断する立場の人間へのアウェアネスを高めなければ、同じような事件は何度も起き、何度も痛い目に遭う事業者が出てきます。

潜在的な危険に気がつかず、大ニュースになって初めて自分たちが置かれている状況に気がつくという構造は、これまでも繰り返されてきました。このようなあり方が今後も続くのは、多くの人に取って不幸ですから、できるだけ早くアウェアネスを向上する方法が必要だと思います。ただ、残念ながら名案はありません。

===

クラウドサービスの「相場感」が無いので裁判は難しい

──社会全体で対策を考えるために、弁護士の中には今回の被害者は訴訟を起こすべきだとおっしゃる方もいます。さらには米国のクラスアクションのような制度を設ける議論につながることを期待する声もあります。

上原：現状では、約款の規定を超える損害賠償を得るためには、裁判が必須なわけです。今回も、事故によって事業上の損失を被った会社の中から、そういうアクションが起こすところがあれば、そこから議論が定まってくることが期待できます。

ただ、今の所は訴訟を起こす、起こしたという話を聞いていません。おそらく多くの顧客は、事故の原因を過失だと自信を持って断言できるほど、技術的知識がないのだと思います。

とはいえ、裁判をして本当に勝てるのかというとわかりません。技術畑の人は「勝って当たり前」という方もいますが、実は勝てる見込みがあまりないような気もしています。ここの判断は本当に難しいです。

別件で、不正アクセスの被害を受けた会社がサーバ管理会社に対して被害の一部弁済を求めた裁判が起き、それを個人的に傍聴する機会がありました。その際に法廷で、原告側が技術的にプリミティブな話を少しずつ積み上げるように説明しても、法曹側の人たちに理解してもらえるのは一部に留まってしまうという現場を目の当たりにしました。技術に関する判断の善し悪しといった、技術者なら共有できる空気が、残念ながら法廷では伝わらないと感じました。

今回の事件に当てはめれば、クラウド事業者ならばこのくらいのバックアップをするのが常識だろう、という相場観というか感覚値があるはずですが、それに対する客観的な裏付けは誰も持っていません。裏付けがないものは、裁判で証拠になり得ないんですよね。

仮に、不正アクセス事件において、被害に遭ったシステムを構築したシステムインテグレーターが「SQLインジェクションは非常に困難で高度な攻撃なので予見は不可能であり、我々に瑕疵はない」と裁判で弁明したとします。それに対して「この年のこの本には、教科書的にSQLインジェクションの攻撃例と、その防御法が載っている」とか「この新聞記事にSQLインジェクションについて書かれている」といった技術的争点に対するエビデンスを客観的に積み上げられます。だから、裁判で戦いようがあります。

ところが、クラウドについては、「バックアップをこういう体制でするものだ」というのは、まだ教科書もないし、新聞記事もありません。新しい技術、新しいサービスだから、おそらく戦えないのでは、という気がします。

ただ、戦えないからと言って、そこで諦めるのは惜しいです。クラウドサービスの相場観を客観化するためにも、業界側で努力して欲しいところです。

===

顧客ガイドライン先行で業界ルールの浸透を

──クラウドのバックアップについては、業界の自主的なガイドラインで解決するものでしょうか。規制やルールを作れという意見がありますが、それは実現可能なのでしょうか。

上原：おそらく両面作戦になります。ひとつは、顧客側のガイドラインの作成です。例えば、B2Bサービスのビジネスユーザーを対象にした「クラウドサービス調達ガイドライン」を用意し、チェックすべき項目などを啓蒙していくとよいのではないでしょうか。

もうひとつは、事業者側が自分たちの正当性を確保するためのガイドラインです。サービス品質維持のためにすべきことや、顧客保護のための対策など、ある程度の基準を示す方向がありうると思います。

ただ、事業者側のガイドラインは、現在のような業界構造では、事業者の立場によって意見が別れるため、正直なところ作成が難しいでしょう。したがって、先に顧客側のガイドラインを作る方が、現実的かもしれません。

例えば、自治体に向けた調達基準ガイドラインのようなものを作れば、自治体の担当者が調達業者やバックエンドのクラウド業者にガイドラインへの適応を求めれば、うまく浸透してくように思います。

あとはSLA（Service Level Agreement）というものの概念を、きちんと伝えることです。事業者側に対して、約款がどんどん長くなってきており、まともに読めなくなっていることへの対応をお願いしたいです。

ビジネスユーザーであっても、コンシューマに近い層なら、いくら約款に書いてあったとしても、事故発生時に不満の声がどうしても上がります。読みやすい約款は、そういった事態への自衛策でもあるし、業界としての規律みたいなものにもなります。

重要な条項は、約款に書かれているものを抜粋して、大きく表記することを業界ルールにできると良いのではないでしょうか。例えば、ダウンタイムが何％というのは、どういう条件や根拠に基づいているのかを明らかにするといったことです。

似たようなものとして「特定商取引に関する法律」では、ECサイトに対して特定の項目を利用者にわかりやすく提示することを求めています。ああいうことが必要になってきているのかもしれません。