先日国内の大手レンタルサーバー事業者で大規模なデータ喪失事故が発生した。原因はセキュリティアップデート用のプログラムミスということだが、バックアップも含めて全データを失う結果になり、被害は契約していた約5700社にも及んだ。事故のリスクはゼロにはできないものの、利用者としてできることを考えてみる。
事故の顛末
当該サービスでは、待機系サーバ(ホットスタンバイ)を用意しており、同じようにアップデートしたことで、正常に動くサーバを失ったことや1日1回以上はユーザの環境をバックアップしていたものの、バックアップも同じサーバ内のディスクに取得していたことでバックアップも同時に失うことになったことで被害を拡大した。また、他社が提供しているグループウェアなどアプリケーションを稼動させてサービスとして提供したものについてもサービスを停止するだけではなくデータを喪失することになった。
今回事故が発生したレンタルサーバサービスは、クラウドサービスでのいわゆるIaaSを提供していたことになる。利用者にとっては、クラウドサービスは、常に最新バージョンで安全な環境が利用できるものという認識があり、そのように宣伝も行っていることも事実である。そのため、サービス提供者は最新環境を維持するために、利用者に特に断りなく日常的にセキュリティパッチを当てていたと思われる。その点ではセキュリティに関しては意識も高く、最新サービスを提供していたとも言える。
ただし、待機系がある場合には、安全のためには本番環境と同時に更新しないで、待機系を更新して正常動作を確認してから本番環境を更新するのが一般的だろう。また、利用者環境に影響がある場合には予め通知をすることが望ましい。
SLAで守られるもの守られないもの
稼働率100%を宣伝文句にして、サービスレベルを保障する事業者であり、クラウドのユーザとしてはSLAを結んでおけば大丈夫という意識があったが、あくまでサービス停止による損害賠償額が契約金額の範囲内でのみの保障であることが明らかになって、驚いたユーザも多いだろう。そもそもSLAは、想定されるサービスレベルが維持できない時には違約金を契約の金額の範囲で払い戻すという契約が一般的であり、あくまで提供しているサービスのレベルを保証するもので、その上で稼動するシステムやビジネスについては保証していない。
今回の事故は更新プログラムのミスというサービス提供者側に全面的な過失がある。しかしながら、契約内容に従えば、契約金額を上限に返金されるだけにとどまる。例えば交通機関が止まっても運賃の払い戻しはあっても自社のビジネスに対する補償(機会損失や直接的な損害に対する補償)がないのと同じだと考えれば理解できるだろう。また、サービス提供する事業者も利用者から契約範囲を超える損害賠償を求められる可能性があるため重大な過失があったとは認めないだろう。
今回の事例も含めて、SLA契約内容の多くは提供者側の過失であっても、賠償額は契約金額を上限としていることが多いことから、賠償額が不足する分については自分で「保険」をかける必要がある。実際にそのような事故の損害を補償する保険を提供する損保会社もある。
第三者によるリスク評価
ところで、こうした損害保険はどのように保険料を算出しているのだろうか。現在のところ、利用者が少ないせいか、補償額も保険料もほぼ固定となっている。今後損害保険サービスが複数の会社から提供されるようになると、様々なリスクに応じた保険料の算出が行われるようになるだろう。
クラウドサービスの多くは、仮想化された環境など利用者向けの環境に関する情報は提供されるものの、物理的なデータセンターの位置も含めて実際にどのような物理的な環境で稼動しているのかはあまり公開したがらないのが実情である。もちろん、低コストで利用者に提供するためには、クラウドサービスは物理的な環境は関係なく、サービス内容を通知すれば十分ということも可能である。
しかしながら、システムのリスクを算出する際には、第三者の評価が必要となるはずである。そのため、より情報を公開する方がリスクが低く、保険料が低くなる可能性も高い。今後クラウドの安全性や性能については保険料で評価される可能性があると考えられる。具体的には、物理的な環境以外にも、通常時運用状況や人員だけではなく、システム更新時の手順やトラブル発生時の対応なども評価することで、リスクの算出、さらには、利用者が支払う保険料が算出できるようになる。結果として、優れたサービスは提供価格とは関係なく保険料が低く抑えられるようになり、利用者にとってもサービスを選ぶ一つの目安になるだろう。
今回の教訓は
今回の事故の教訓としては、クラウドのサービス、例えSaaSであっても利用者のデータや環境を維持管理するのは利用者の責任であることが明らかになった。しかしながら、個別にバックアップを取得していないケースも多いのも事実である。これまでにもデータ喪失のニュースが報じられているものの、SaaSやデータベースなど動的にデータを生成しているものについては、利用者側だけでは完全なバックアップを取得しにくく、サービス側のシステムに関する情報やバックアップ手段の提供が必要だ。また今回の事故についても、更新プログラムの検証がきちんとされていたのか、パッチを当てる際の手順などの疑問はあっても、正しい場合であってもユーザからは確認することはできない。この点については、サービス提供者を信じるか第三者のリスク評価に委ねるしかない。
また、事故が発生した際にはクラウド事業者の補償は期待できないことから、自分で補償を確保する必要がある。今回の事故は、偶然親会社が大手サービス事業者であったため、復旧のための人員やそれなりの対応が行われていたものの、今回の事故では、特別損失として約12億円が計上されることになり、サービス提供企業が財務的な体力のない中小企業であった場合には、大規模な事故が発生した時点でサービスを完全停止した可能性も考えられる。実際に海外のクラウド事業者ではそのような事例も発生している。今後もクラウドサービスの普及に伴い、常に事故が発生する可能性があることから、利用者は第三者の評価に基づいた安全なクラウドサービスを選ぶことや保険に入るだけでは必ずしも十分ではない。契約しているサービスが停止する可能性も考慮して、他のクラウドに移行しやすく設計・構築しておくことも重要である。