クラウドに預けていたデータが、 「雲」 が消えるかのごとく消失してしまった。 ２０日１７時頃、 レンタルサーバー会社のファーストサーバ（ 大阪市 ）で起きた 「データ消失」 事故。 その深刻な状況が日を追うごとに明らかになってきている。 被害にあった顧客件数は５６９８件で、 ほとんどが復旧不可能な状態。 ウェブサイトやメールに加え、 顧客情報やスケジュールなど多種多様なデータが失われ、 業務が止まった企業からは悲痛な叫びが聞こえてくる。 いったい何が起きているのか。
「データの消失があった５６９８件のお客様のうち、数百件を除く共有サーバーのデータは、残念ながらデータの復旧自体が不可能ということが分かりました。 本当に申し訳なく思っております」 ――。
小林製薬、１０９シネマズ、長野電鉄、カルディコーヒーファーム、海遊館、兵庫ひまわり信用組合、薬事日報、日本新聞協会、東京都卓球連盟、静岡産業大学、大津市市民活動センター、太陽光発電協会 ……。 数多くのウェブサイトが突然ダウンしたのは、２０日夕方のこと。 共通点は、ウェブサーバーの運用をファーストサーバに任せていたことだった。 ファーストサーバの作業ミスをきっかけに、同社が運用していたサーバー内のデータがドミノ倒しのように消えてしまった。 |
|
２３日、ファーストサーバは複数の顧客で共有するタイプのレンタルサーバーサービスに関し、 「データ復旧を行うことは不可能と判断した」 と公表。 顧客には 「お客様で取得されておられるバックアップデータによる再構築を行っていただきますようお願い申し上げます」 と呼びかけた。 共有型ではない専用サーバーサービスについては、当初、データ復旧ソフトにより一部、回復できたとし、顧客にデータを引き渡していた。 しかし、ある顧客企業から 「社内の他人のメールが読めてしまう」 と報告があり、確認したところ、復旧データに欠損があることが判明。 ２２日夜、すべての復旧データの提供をとりやめた。 そのため、障害の影響が及んだ約５７００の顧客すべてが、２６日現在も 「自力」 でウェブサイトを再構築するなどの作業を強いられている。 幸いにして手元にバックアップデータがあった顧客は、２２日１８時頃から再構築することが可能となり、順次、復旧している。 「熱さまシート」 「あせワキパット」 など２８のブランドサイトや携帯向けサイトをファーストサーバで運用していた小林製薬は、２２日中にすべてのサイトを復旧させた。 「企業サイトや通販サイトは別の場所で運用しており、ファーストサーバで運用していたのは単純な情報提供サイトのみ。 加えて自社にバックアップデータもあったので比較的早期に復旧できた」 （ 広報 ） ただ、被害企業・団体のうち完全に復旧できたのは一部。 多くは、２６日現在も一部が復旧できていないか、そのメドすらたっていない。 長野電鉄は多くのコンテンツのバックアップデータを持ち合わせていたが、 「お客様からの声」 や 「ボランティアツアー申し込み」 など投稿フォームから得た一部データが消失したままの可能性があるという。 「投稿フォーム機能の再設定に手間取っており、遅くとも今週中には完全に復旧させたい」 （ 事業推進課 ）とする。 社団法人 日本ロボット学会は、約２週間前にウェブサイトをリニューアルしたばかり。 リニューアル時のデータが残っており、懸命にデータを転送しているが、２５日夜時点での復旧率は約２０％。 ２週間のあいだに更新した論文などのデータは消失しており、会員に再提出を促す。 ロボット学会はメールシステムもファーストサーバで運用。 障害発生時からメールシステムの復旧までに届いたメールが消えている可能性があるため、仮運用のホームページで再送を呼びかけた。 「二度と戻って来ないデータが多いわけではないが、金額的な被害は大きい。 今回のミスは、ウェブサーバー屋のやる失敗ではなく、あり得ない。 まずはファーストサーバの環境で一刻も早く復旧させることを優先するが、すぐに他社に乗り換える予定」。 担当者はこう憤る。 |
|
これらは被害企業・団体の中でも、比較的、体制が整っており、被害が軽微な部類に入るとみられる。 約５７００のうち大半が中堅・中小規模の事業者。 復旧のメドがたたない企業・団体も数多く、ファーストサーバですら被害実態を把握できていない。 顧客は、ウェブサイト以外にもファーストサーバでさまざまなシステムを運用していた。 代表格がメール。顧客企業がパソコンにダウンロードしていたり、 「Ｇｍａｉｌ」 などの外部メールサービスに転送していた場合は難を逃れたが、そうではないサーバー上のメールは消失した。 事業に直結するシステムやデータの消失で、日常業務に支障をきたしている企業もある。 ウェブ上での予約ができない ＬＯＦＴ ＰＲＯＪＥＣＴ は逆手にとったイベントを企画 「新宿ＬＯＦＴ」 など都内でライブハウスを展開する ＬＯＦＴ ＰＲＯＪＥＣＴ では、各店舗のホームページは一部を除いて復旧したものの、ウェブサイト上での予約業務ができない状態が続いている。 障害を逆手にとり、 「ファーストサーバ データ消失オフ」 というイベントを７月１４日に開催することを決めた。 イベント案内には、こうある。 「我々ロフトグループも本稿執筆時（ ６月末日 ）にはまだまだ死線をさまよっている最中でございます。 と、そんな阿鼻叫喚のハンバーガーヒルを駆け抜けたサーバ管理者の皆様！ ここはひとつ、いまだ癒えぬ生傷を握りしめ、酒を酌み交わそうではありませんか！」被害企業として途方に暮れている様子が伝わってくるような文言だが、笑い飛ばせるだけ、まだマシだ。 |
ある素材のネット通販を手がけていた都内事業者は、通販サイトのみならず、この数年間に蓄積した顧客情報など一切のデータを失った。 それらのデータはすべてファーストサーバで管理しており、バックアップはない。 ウェブサイトはゼロから構築し直す予定で、２～３週間はかかるという。 この事業者は 「担当者がかわいそうだから」 と、匿名を条件にこう話す。「ダウン直前まで途切れることなく入ってきた注文を考えると、かなりの損害になる。 万単位の顧客データもゼロスタートになり、正直途方に暮れています。 言いたいことは、 『元に戻してほしい』 ですかね。 言ってもしょうがないですが。 大事なお客様とのつながりが断たれてしまい、信用を失ったことが何よりショックです」さらに深刻な事態が、 「サイボウズ」 というグループウェアの利用企業に想定される。 |
|
ファーストサーバは月々の利用料金だけで手軽にサイボウズを利用できる 「サイボウズ Ｏｆｆｉｃｅ９ ｆｏｒ ＡＳＰ」 のパートナー企業。 加えて、顧客企業が購入したパッケージ版のサイボウズを運用するサーバーとしても数百社に貸していた。 このうち、メール、スケジュール、顧客管理、営業記録など、約４００社のサイボウズのデータを丸ごと消失させてしまった。 ネット上の掲示板には 「顧客データもサイボウズに入れてたから、電話来ても誰が誰だかわかんないし何も答えられないし、サーバが落ちててって言い訳もできないし、会社自体が記憶喪失になったみたい」 「たぶん明日は段ボールから顧客との契約書原本取り出して、電話取りながらあいうえお順に並べる作業から一日が始まります」 といった書き込みがなされている。 真偽は不明だが 「困っていらっしゃるお客様から、２０日から２５日まで累計２００件ほどの問い合わせがあった」 （ サイボウズ広報 ）。 ファーストサーバは 「サイボウズのＡＳＰを利用していた１４９社のほとんどが、恐らくバックアップをとっていないと思われる。 実際にどれだけのお客様が自力でデータを復旧できない状況にあるのか、実態は把握できていない」 とする。 顧客情報は企業にとって事業の根幹ともいうべき資産。 そのバックアップを自社で管理していなかったのは 「自己責任」 という声もある。 ただ、クラウドサービスは企業情報システムに投資できない、あるいはＩＴ（ 情報技術 ）に疎い事業者が手軽に活用できるサービスとして普及した。 前出のネット通販事業者は 「こちらにも甘さがあったと思います」 としながら、 「『 稼働率１００％ 』 とうたわれていたので信用していた」 と話す。 サイボウズについても、ファーストサーバのＡＳＰサービスの説明資料で、 「データのバックアップ」 「リストア（ 復元 ）」 について、 「お客様作業不要」 と明記している。 一概に、被害企業を責めることはできない。 では、 「稼働率１００％」 「バックアップ不要」 のサービスがなぜ ……。 皮肉にも、障害の原因となった作業は、セキュリティーを高めるためのものだった。 |
|
ファーストサーバによると今回、脆弱性対策のために更新プログラムを作り、いつものようにプログラムを走らせた。 ところが、その更新プログラム自体に大きなバグ（ 不具合 ）があった。 「ファイル削除コマンド」 を停止させる記述漏れと、メンテナンスの対象となるサーバー群を指定する記述漏れがあったというのだ。 そのバグに気づかないまま、本番環境のサーバーで更新プログラムを起動。 だが更新プログラムは、対象外のサーバーでファイル削除コマンドを実行し、次々とデータを消去していった。 この範囲が、顧客件数５万件のうち約５７００件に及んだ。 不幸はここで終わらない。 通常なら、バックアップデータから元のデータを復元することで一両日中にウェブサイトなどは復旧する。 バックアップデータは、本番環境とは違うサーバー、あるいは外部記憶装置に定期的にとっておくことが基本だ。 ところがファーストサーバでは事情が違った。 ファーストサーバにおけるセキュリティ対策では、３つのＨＤＤに同じファイルをコピーしていた。 １つは 「本番系」。 もう１つは本番系のＨＤＤやシステムに不具合が生じた時、即座に切り替え、正常稼働を続けるための 「待機系」。 もう１つが、毎朝６時に本番系のデータを丸ごとコピーしておく 「バックアップ系」 だ。 この３つが、すべて同じサーバー内に同居していた。 あろうことか、ファイルを削除してしまう更新プログラムのバグは、本番系、待機系に加え、同じサーバー内にあるバックアップ系のＨＤＤまでをも消去するという代物だった。 |
|
なぜ、外部にバックアップをとっておかなかったのか。 ネット上では技術者を中心に、この点が指弾された。 これについてファーストサーバの村竹室長は、こう話す。 「おっしゃっているような一般的なバックアップというのは、我々のような低価格の料金で提供するのは難しい。 サーバー内の別のディスクでとることを、我々はバックアップと考えています」 ファーストサーバの主力であり、複数の顧客企業でサーバーを共有するサービス 「ビズ２」 の料金体系は、月額１８９０円からと低価格が売り。 データ容量が１８０ギガバイト（ ＧＢ ）と大きいプランでも月額５２５０円。 そのツケが、業者側でのデータ完全消失だった。 バックアップの構造は、共有サーバーより高価な、専用サーバーサービスでも同じだ。 こちらは、前述のようにデータ復旧ソフトによる作業で一部データが復旧したようだが、今後、復旧が進んでも 「データの精度や量は相当部分的なものにとどまる」 との見通し。 引き渡しまで数カ月以上要すると見込んでおり、当てにできそうにない。 同種のトラブルとしては国内最大級に発展しそうな大規模データ消失。 今となってはバックアップがない企業・団体は泣き寝入りするしかなく、損害賠償も多くを見込めそうにない。 |
|
ファーストサーバは２５日朝に公開した質疑応答集（ ＦＡＱ ）の中で、損害賠償についてこう明記した。 「サービス利用契約約款に基づいて、お客様にサービスの対価としてお支払いいただいた総額を限度額として、損害賠償させていただきます」 約款には 「利用者がバックアップを怠ったことで受けた損害についてファーストサーバは何ら責任を負わない」 という免責条項がある。 だが、今回は 「当社に故意または重過失が存する場合」 として適用せず、上記の 「賠償制限規定」 に基づいて個別対応するという方針だ。 内田・鮫島法律事務所の伊藤雅浩弁護士は、 「ファーストサーバに限らず、レンタルサーバー事業者は二重三重の防御線を敷いているので、データ消失による補償を約款以上に求めることはなかなか難しい」 と指摘する。 ただし、サービスの説明や宣伝に 「優良誤認」 があった場合はどうなのだろうか。 ファーストサーバは取材で、事実と異なる説明があったことを認めた。 ファーストサーバの主力サービスであるビズ２・シリーズのパンフレットに、こうある。 「ファーストサーバは、これまで以上に安心してレンタルサーバーサービスをご利用いただくために品質保証制度（ ＳＬＡ ）を設け、稼働率１００％を保証した高いビジネス品質のサービスでお客様のビジネスを支えます」 これは、本番系と同時にリアルタイムで待機系を動かし、サーバーを止めることなく稼働させる仕組みをうたっている。 「１００％」 は実現できなかったが、もう１カ所の記述が事実であれば、少なくとも消失は防げたはずだった。 |
|
ファーストサーバによる 「ビズ２」 のパンフレット。 「日に１回、外部にデータを保存」 との記述は事実でなかった。 「さらに人為的なデータ損失があった場合にそなえ、日に１回、外部サーバーにデータを保存していますので、お客様によるデータの誤消去があった場合にも、前日の状態に戻すことが可能です」 ――。 今回はファーストサーバによる 「人為的な誤消去」。 しかし実際は、バックアップは 「外部サーバー」 ではなく、 「同一のサーバー内の別ディスク」 にあり、完全なデータ消失に至ってしまった。 この点についてファーストサーバの村竹室長は 「数年前までは記述の通りだったが、現在は説明の通り異なる。 記述ミスで、修正をせずにいた可能性がある」 と語った。 約款をよく理解せず、こうしたうたい文句を信じてバックアップをとらなかった顧客がバカを見たのか。 それとも優良誤認に該当するのか。 議論の余地がありそうだ。 伊藤弁護士は 「悪い事情は、裁判でそれなりに考慮される可能性もある。 相手に重過失があり、多大な損害を被った場合、責任限定に関係なく争う余地はある」 とする。 |
|
もっともファーストサーバにとっても今回の事故は不運な出来事。 想定外の事態に見舞われ、社員は寝ずの対応に追われている。 中小企業であれば、つぶれてしまいかねない。 ただ、親会社はネットサービス国内最大手のヤフー。 ファーストサーバ社長はヤフー子会社の大手データセンター、ＩＤＣフロンティア取締役の磯部眞人氏であり、ファーストサーバ役員にはヤフー幹部が３人もいる。 「人員の派遣、お客様対応、技術的な協力を含め、事態の収束に向けて全面的にヤフーが支援している」 （ ヤフー広報 ）といい、ファーストサーバにとってはヤフー子会社であったことが不幸中の幸い。 ヤフーの２０１２年３月期の業績は、売上高が３０２０億円、純利益が１００５億円と盤石なことを考慮すると、逆に損害賠償の請求額が高くなる可能性もある。 ＩＴ部門のコスト削減圧力に加え、東日本大震災を機に注目された 「事業継続性」 から、クラウドサービスへの関心はますます高まっている。 そんな中で起きたデータ消失事故は、クラウド時代の盲点を浮き彫りにした。 そして、いまだに被害の全貌や実態は見えていない。 |
ヤフー子会社でレンタルサーバー事業を営むファーストサーバ（ 大阪市 ）のサービスにおいて、２０１２年６月２０日にデータ消失を伴う大規模障害が発生した。 同社は６月２５日午前、ウェブサイトで 「大規模障害の概要と原因について（ 中間報告 ）」 と 「大規模障害に関するＦＡＱ」 という文書を公開した。
これにより、サーバーを復旧する顧客は、サーバーを最初から再設定して、顧客が手元のパソコンなどに保存しているバックアップデータからデータを復旧することになる。 手元のパソコンなどにバックアップデータを持たない顧客に対しては、 「お客様にて新しくコンテンツを作成いただくこととなります」 と案内している。 ♠ 原因は更新プログラムのバグと運用の不備 ファーストサーバの発表文書では、障害発生の原因について、 「（ 脆弱性対策のための ）更新プログラム自体に不具合があったことに加えて、検証環境下での確認による防止機能が十分に働かなかったことと、メンテナンス時のバックアップ仕様の変更が重なり、今回のデータの消失が発生した」 と説明している。 具体的には、今回の障害前に作成した更新プログラムに 「ファイル削除コマンドを停止させるための記述漏れ」 というバグがあった。 この更新プログラムを検証環境で実行するという手順を踏んだにもかかわらず、バグに気づかないまま本番環境で実行された。 この結果、意図しないファイル削除が実行されてしまいデータが消失した。 一般にはこの時点でも、定時バックアップを取得してさえいれば、最新のデータは消失するものの、一定のデータは復旧できるはずだ。 実際に、ファーストサーバでも毎朝６時にバックアップを取得していた。 ところが、ファーストサーバではバックアップ領域にも更新プログラムを同時適用するという運用がなされており、バグのある更新プログラムによって、バックアップ領域でもファイル削除が実行されてしまったという。 ♠ 支払額を上限に損害賠償 ファーストサーバはデータ消失の責任を認めており、 「サービス利用契約約款に基づいて、お客様にサービスの対価としてお支払いただいた総額を限度額として、損害賠償させていただきます」 としている。 一方で、顧客企業のホームページや通販サイトにアクセスできないことなどによる機会損失については、 「損害賠償の対象とさせていただく予定はございません」 としている。 |
|
2019年12月4日午前11時ごろ、日本電子計算株式会社（通称：JIP）が運営するクラウドサービスが吹っ飛び、その上で動く全国の自治体システムも吹っ飛び、全国約50の自治体で戸籍管理や税務処理、医療保険、図書館などのデータが消失した。 午後5時時点の情報では、原因は 「ストレージに付随するファームウェアの故障であることが特定された」 が近日中のデータ復旧は絶望的らしい。 |
|
日本電子計算が運用する自治体専用IaaSサービス 「Jip-Base」 で12月4日10時56分頃から障害が発生し、同サービス上で稼働している業務システムの一部が利用できない状態が続いている。 例えば、東京都の中野区では、ウェブページ閲覧、⼾籍証明の発⾏、⼾籍の届出、後期⾼齢者医療保険関連⼿続きが利用できず、練馬区ではウェブページの更新 / 閲覧が不可の状態になっている。現在、この障害の影響を受けている自治体とサービスは下記の通り。 日本電子計算では、障害の原因を 「ストレージに付随するファームウェアの故障」 にあると特定。 復旧方法についても目途が立ち、12月9日の全面復旧を目指して作業を進めているという。 なお、同IaaSサービス上で稼働する業務システムについては、同社単独で復旧できるものではないため、各自治体によって復旧時期は異なる模様だ。 また、発表によると、今回の障害は外部からの攻撃などによるものではなく、情報流出や情報漏えいはないとしている。 |
|
NTTデータ傘下の日本電子計算が提供する自治体向けIaaS 「Jip-Base」 で障害が発生し、全国53の自治体と団体のシステムに影響が出ている件で、同社は12月16日に記者会見を開いて謝罪し、 「33の自治体で、一部のデータが復旧できない状態にある」 と明らかにした。 問題発生から2週間がたとうとする中、いまだ全面復旧の見通しは立っていない。 Jip-Baseは、各自治体向けに業務システムを提供するクラウドサービス。 障害は4日午前11時ごろから53の自治体や団体で発生。 東京都や愛知県など一部の自治体では、税務処理や戸籍管理のシステムが使えない状態になった。 日本電子計算は、障害の原因はストレージを制御するファームウェアの不具合だとしている。 この不具合を受け、ストレージの保守を担当するEMCジャパンは5日にファームウェアのアップデートを実行。 ファームウェアの不具合によるハードウェアの故障は6日に解消したが、その後の動作確認により、不具合の影響でストレージの一部が正しく読み出せない状態になっていることが分かった。 ストレージが読み出せないと、各業務システムを動かす仮想OSの起動や業務データへのアクセスが難しく、9日中の全面復旧は不可能だと判断した。 |
|
バックアップシステムにも以前から不具合 15％復旧できず |
|
日本電子計算は9日以降、ストレージやバックアップデータから仮想OSの情報や業務データの復旧作業を行っている。 同社の山田英司社長は、16日の段階で 「（仮想OSのうち）70％はIaaSとして復旧したが、15％は復旧不可能な状態にある」 と明かす。 残りの15％は、現在もバックデータからデータが復旧できるか確認している段階だという。 15％（約200個）の仮想OSが復旧できない状態にあるのは、日本電子計算によるバックアップが正常に行われていなかったからだという。 一部でバックアップが正常に行われていなかった理由について、Jip-Baseを統括する神尾拓朗部長（公共事業部基盤サービス統括部）は 「監視システムに不具合があったため」 と、ストレージのファームウェアとは別に原因があったことを明かした。 これにより、33の自治体で今も一部のデータが復旧できていない。 これらの仮想OSについては復旧を諦めず、利用事業者と連携してできる限り復旧作業を行うとした。 |
|
「修正パッチの情報が届かなかった」 |
|
山田社長は、ストレージを制御するファームウェアの不具合が起きたのは 「EMCジャパンから修正パッチの情報が届いていなかった」 からだと説明する。 日本電子計算とEMCジャパンは、EMCジャパンからファームウェアの修正パッチがリリースされた場合に、メールでパッチの情報を通知するよう契約を結んでいた。 しかし、今回の障害を事前に回避できたと考えられる修正パッチのリリース情報は、4日の段階では届いていなかったという。 一方で神尾部長は 「5日にEMCジャパンから修正パッチの情報が提供されたが、緊急度が低いものとされており、事前に見たとしてもパッチを適用していなかった可能性はある」 としている。 日本電子計算は、今回の障害に関して今後も被害状況の調査やデータ復旧を行うとしており、被害を受けた団体への補償などは現在検討中だという。 |
|
2019年12月4日に発生した50自治体のシステム障害は、発生から2日経過したがまだ全面復旧に至っていない。 今回の引き金になった日本電子計算のIaaS 「Jip-Base」 のシステム障害の原因については、日本電子計算は 「ストレージ機器のファームウエアの不具合ではあるが、Hewlett Packard Enterprise（HPE）のストレージ機器とは無関係」 （広報）とコメントした。 また復旧については、12月9日をめどにしていることも明らかにした。 HPEは2019年11月下旬、同社のストレージ機器であるSAS SSD製品にファームウエアのバグが見つかったことを明らかにしていた。 このバグが、Jip-Baseのシステム障害に関係するのではないかと、ネット上で騒がれていた。 またJip-Baseの復旧は2019年12月9日をめどとしているが、50自治体のすべてのシステムが復旧するにはさらに時間がかかりそうだ。 例えば中野区では戸籍証明の発行など一部システムは12月6日朝に2日ぶりに稼働したが、現在もホームページ閲覧や後期高齢者医療保険に関する手続きなどはできない状況だという。 これは、 「戸籍という重要情報なので、障害前のデータと整合性がとれているかを慎重に確認したので時間を要した」 （中野区役所）ためだ。 各自治体も、Jip-Baseが復旧してもデータの整合性や稼働確認などがあり、復旧に時間を要するとみられる。 |
HPのSSD、稼働32768時間で全データ喪失するバグ、復旧も不可。
世界中のサーバーが次々死亡しパニック
Hewlett Packard Enterprise(HPE)が11月29日に公開したサポート文書によれば、同社のサーバーやストレージ製品に使われている特定のSAS SSDにおいて、稼働時間が32,768時間を超えると、復旧が不可になる深刻な不具合が発生するとした。
HPEによると、SSD製造業者から特定のSAS SSDモデルのファームウェア障害についての通知を受けたという。 これらのSSDは、ProLiant、Synergy、Apollo、JBOD D3xxx/D6xxx/D8xxx、MSA、StoreVirtual 4335/3200 といった多くのHPE製サーバー / ストレージで使われている。
この問題は、 「HPD8」 より以前のファームウェアバージョンを使用しているSSDにおいて、32,768時間の稼働(およそ3年270日8時間)で障害が発生。 障害が発生すると、SSDのデータが喪失し、回復できなくなる。 同時に稼働を開始したSSDは、同時に障害が発生する可能性があるとしている。
32,768は16bitの整数型で負から正まで扱える範囲の最大値を1つ超える数値であり、これに関連した不具合と見られる。
HPEはこの問題を防ぐためのHPD8ファームウェアを配布しており、すぐに適用するよう呼びかけている。 適用しない場合、ユーザーは今後起こりうるエラーのリスクを受け入れることになる。 なお、リリースが遅く稼働時間が32,768時間に満たない一部モデルは、12月9日の週の配布を予定している。
|
NTTデータの子会社である 「日本電子計算株式会社（JIP）」 が運営するクラウドサービス 「Jip-Base」 にシステム障害が発生し、全国約50の自治体で 「戸籍管理・税務処理・医療保険・図書館」 などのデータが一部利用できない状態になっていることが明らかになりました。 ネット上では 「戸籍や税務などのデータが全て消失した」 とも囁かれているため、今後のデータ管理方法などにも注目が集まっています。 「Jip-Base」 でシステム障害が発生 日本電子計算株式会社が運用する自治体専用のIaaSサービス 「Jip-Base」 で、2019年12月4日10時56分頃からシステム障害が発生し、同サービス上で稼働している業務システムの一部が利用できない状態が続いていることが明らかになりました。 このシステム障害によって約50の自治体が影響受けており、東京都の中野区では 「ウェブページ閲覧・⼾籍証明の発⾏・⼾籍の届出・後期⾼齢者医療保険」 など⼿続きが利用できない状態となっており、練馬区ではウェブページの更新／閲覧が不可能な状態になっていると伝えられています。 なお、中野区では 「戸籍証明の発行など一部システムが12月6日に朝に稼働した」 と報告されています。 ネット上では 『ストレージのバグで戸籍や税務などのデータ全消失』 として大きな話題となっており、これらのデータの中には 「戸籍管理・税務処理・医療保険・図書館」 などの重要なデータが大量に含まれているため、データ復旧には長い時間がかかる可能性があるとして先行きを不安視する意見が多く出ています。 このシステム障害は 「ストレージに付随するファームウェアの故障が原因である」 と報告されており、2019年12月9日に 「Jip-Base」 を全面復旧することを目指して作業を進めていると説明されています。 しかしながら 「Jip-Base」 上で稼働している住民票発行などの業務システムは同社が単独で復旧できるものではないため、同社からは 『全面復旧の期日をお知らせできない』 とされています。 今回の障害は外部からの攻撃などによるものではないため 「情報流出・情報漏洩」 などの被害はないものの、ネット上で囁かれているように大規模なデータが消失しているのであれば、戸籍や税務などの情報を完全に復元することは困難であると考えられます。 Twitter上では 「データのバックアップをどのように行っていたのか？」 を追求する意見が出ていますが、海外ではこのようなデータ消失を防ぐために分散型でデータを管理するブロックチェーンや分散型台帳技術（DLT）を用いて国の重要データを管理する取り組みが進められているため、今後はこのような技術の活用が日本でも本格的に検討される可能性があると予想されます。 日本電子計算株式会社の親会社にあたる 「NTTデータ」 は実際にブロックチェーン関連の取り組みを進めているため、同社の新しいシステムが活用されていく可能性もあると考えられます。 ブロックチェーン技術は重要なデータを暗号化して複数の端末に保存する仕組みを採用しているため、特定のサーバーが影響を受けた場合でもその他のサーバーからデータを復元することができます。 ブロックチェーンや仮想通貨に寛容な国として知られるマルタ共和国のJoseph Muscat（ジェセフ・マスカット）首相は、2019年6月に 「同国すべての賃貸契約をブロックチェーンに登録すること義務付ける」 と発表しています。 |
|
クラウド時代のインシデントとして非常に興味深く、そして頭が痛い事件が起きました。 2020年11月1日、ふくい産業支援センターが運営するWebサービス 「ふくいナビ」 が障害によりサービスを停止しました。 サーバ管理会社のNECキャピタルソリューションによる調査の結果、サービス停止の理由は 「クラウドサーバのデータが完全に消失したこと」 だと判明しました。 驚くべきは、このサーバデータ消失の原因がマルウェアによる感染でもサイバー攻撃でもない点です。 ふくい産業支援センターは、2020年10月31日を更新期限とするクラウドサーバの賃貸借契約を、期限前の同年10月13日に更新しました。 しかし、NECキャピタルソリューションの社内手続きの瑕疵により更新処理が反映されずに貸与期間が終了してしまい、クラウドデータが完全に消えてしまったとのことです。 ふくい産業支援センターは 「システムと登録データは、バックアップを含め完全に消失し、復旧には相当の期間が必要で再稼働の時期は現時点では未定だ」 とコメントしました。 この事件に関するNECキャピタルソリューションの報告はまだありません。 |
| 「過失がないインシデント」 が発生 サービス利用側はどう動くべきか |
|
サービス提供側を責めるのは簡単ですが、最終報告書も出ていない状況のため、それはひとまず後にするとして、この事件はクラウドサービスの運用を事業者に委託している国内企業が一斉に 「ウチは大丈夫なのか？」 と再確認に動かざるを得ないものだと思います。 今回の事件のポイントは、クラウドサービス利用側が 「無過失」 かつ 「対策の打ちようがない」 ということです。 仮にサービス利用側が 「社内処理に問題があったのでは」 とサービス提供側に再発防止策を要求したとしても 「ダブルチェックの実施」 や 「見直しプロセスの徹底」 など具体策が出てこない内容を提示される可能性が高いでしょう。 サービス利用側は、こうした事態を想定してまずは社内でできることを考える必要がありそうです。 契約更新のワークフローの見直しや関連部署とのコミュニケーションから始めてみましょう。 システムやデータのバックアップをサービス提供側に委託しないのも一つの手です。 オフサイトとして自社内にバックアップを保管したり、サービス提供側とは別の事業者にクラウドストレージやサーバのバックアップを依頼したりする方法も有効です。 バックアップの基礎ともいえる下記の 「3ー2ー1ルール」 を参考にしてみてください。 ただしサービス提供側にとって、バックアップとはいえ個人情報が分散されることは大きなリスクです。 サービス利用側と提供側の間でバックアップの保管については話し合いを設けて折り合いをつけることが重要です。 |
| どこまで任せるか、どこから自分たちでやるか |
|
今回の事件は 「運用側のミスをどのようにカバーするか」、つまり本来であれば餅は餅屋として、システム運用のプロに任せるべき問題について 「プロがミスしたときにどうすべきか」 「どこまで考えるべきか」 を、頭の片隅には入れておかなければならないという気付きが得られるものだと思います。 また、自社サービスを支えるシステムの運用を他社に任せているという場合は、 「関係先のリスクまで念頭に置いておく」 という姿勢こそ、システムを利用する顧客に向けた、企業のあるべき姿です。 クラウドサービスの基盤については事業者に任せるとして、バックアップを自社でカバーする場合、情報の管理方法などこれまでのポリシーを変更することも後々必要になるかもしれません。 バックアップが必要となるのはHDの故障や電源故障などの突発的なトラブルよりも、圧倒的に 「人為的なミス」 によるという点も忘れないようにしましょう。 |
