トップページ | 全エントリー一覧 | RSS購読

[耳寄りな情報]

[リンク]

[FC2カウンター]

[ブログランキング]


人気ブログランキングへ

[ブログ内の検索]

[最近のコメント]

[最近のトラックバック]

[カテゴリー]

[FC2]

レンタルサーバ大手のファーストサーバで大規模障害発生 続報

前回の続きです。次第に詳細が明らかとなって来ました。

大規模障害の概要と原因について(中間報告)

(記事より一部引用)
データの消失について
■ 障害の概要
6月20日(水)17時ごろ、脆弱性対策を特定のサーバー群に対して
実施しました。脆弱性対策は更新プログラムを利用して一括して対
象とするサーバー群に対して実施するという運用を以前から行って
おり、今回も同様に作業を実施しました。実施にあたっては検証環
境において動作確認を行い対象サーバー群に問題が発生しないこ
とを確認したうえで、本番環境で実施するという手順を取っており
ます。しかしながら、更新プログラム自体に不具合があったことに
加えて、検証環境下での確認による防止機能が十分に働かなか
ったことと、メンテナンス時のバックアップ仕様の変更が重なり、
今回のデータの消失(バックアップデータの消失を含む)が発生
いたしました。

■ 障害の原因
原因1:脆弱性対策のための更新プログラムの不具合
脆弱性対策のためのメンテナンスが必要となる都度、メンテナン
スのための更新プログラムを作成しており、今回も更新プログラム
を作成しています。そのプログラムの記述において、ファイル削除
コマンドを停止させるための記述漏れと、メンテナンスの対象とな
るサーバー群を指定するための記述漏れが発生していました。

原因2:メンテナンス時の検証手順
メンテナンスに際しては、検証環境でまず動作確認を行うという
手順が定められていましたが、プログラム実行後の動作確認を
行う対象は、あくまでも当該メンテナンス対象サーバー群を確認
すれば足りるとされていたため、検証環境下で対象サーバー以外
に影響が及んだことの確認がないまま、動作確認上は問題なしと
判定され本番環境での実施が行われました。

原因3:メンテナンス仕様
システムを含むデータのバックアップは毎朝6時に取得しておりま
す。しかしながら、脆弱性対策のためのメンテナンスはバックアッ
プをしてあるシステムについても実施しておかないと、メンテナン
ス実施後にハードウェア障害が発生してバックアップに切り替え
た途端に脆弱性対策が講じられていないシステムに戻ってしまう
ことが過去に発生し、脆弱性対策がなされていないシステムが動
き続けていたという反省に立ち、脆弱性対策のメンテナンスに関し
ては対象サーバー群とそのサーバー群のバックアップ領域に対し
て同時に更新プログラムを適用するという構造に修正して実施し
ました。 そのため、今回のメンテナンス実施において、対象サー
バー群のデータ消失と同時にバックアップ領域のデータも消失し
たという事象に至っています。
(引用ここまで)

とまあ、過去の教訓を生かして作業を行ったらこれが裏目に出て
しまったと言う次第。人はミスをすると言う典型的な例であります。

今回のトラブルは、検証手順の範囲が限定的でヒューマンエラーに
対する防御が適切に働かなかった事が問題だと思われます。もしも、
悪意ある第三者が内部犯行を企てた際には、有効に対抗が出来な
いものと思われます。少なくともバックアップ領域に対しては、本番
システムの稼動状況を見てから作業に入るべきでした。

更新プログラムの作成に当たっては、削除コマンドの停止漏れ及び
適用すべきサーバー群の範囲指定漏れがあったそうです。結果的に
検証環境の全サーバー群に深刻な影響を及ぼしていたにも関わらず、
手順では当該サーバー群の確認だけで事足りるとしており、重大な
見落としが発生しました。

気になるのは、検証環境でも全サーバー群に影響しデータの喪失が
起こったこと。それにも関わらず、判定が「問題なし」となった理由が
よく分かりません。全サーバー群に等しく影響を及ぼしたプログラム
ミスが、どうして当該サーバー群だけ問題を起こさなかったのか?
ここが一番の謎です。検証段階で問題が起きていれば、システムへ
の適用は見送られたはずです。

恐らく、当該サーバー群に対し検証環境の段階で重大な確認漏れが
あったのではないかと推察します。守るべき手順を無視して障害が起
こった可能性は否定出来ません。会社の説明だけでは、この辺りが
判然としないので、第三者による検証が必要になって来るでしょう。

また、データを復活させるべくリカバリ作業が行われていましたが、
ここでも問題を起こしています。復旧したデータはリカバードファイル
として客先に提供されました。しかし、提供の仕方がまずくアクセス
権限を有していない者まで参照できる状態になっていた事が判明。
しかも、提供されたファイルは一部が破損しており、満足の行く内容
では無かったと指摘する声もあります。もっと深刻なのは、復元され
たデータには他社のデータまで混在していたこと。情報の漏洩まで
起きてしまっています。

本来、定期的なバックアップは利用者の責任で行うのが筋でありま
すが、ASP形式で提供されるサービスにはユーザー側でバックアップ
を取れないものがあります。今回のトラブルは、この点も大きな問題
となった様です。

例えば、市販されているサイボウズ製品とASP版とには機能差があり
ます。「サイボウズ Office 9 for ASP」では、メンテナンス時間の設定
やシステムタスク(データベースの最適化やバックアップなど)の設定
が出来ません。一番の問題は、バックアップをファーストサーバ独自の
専用サービスで提供していたことでしょう。ユーザー側ではバックアッ
プが出来ない為、結果的に業者任せとせざるを得ませんでした。その
事が、今回の大規模障害で完全に裏目へ出てしまった形です。

共用サーバーとVPSサービスに関しては、データの復旧が絶望的であり
公式見解として不可能との判断に至っています。今後、専用サーバー
サービスにおいても、顧客の要望次第で対応するとの事ですが復旧の
可能性は低いと見られています。

ファーストサーバは、1社で複数のサービスを提供している関係上、今回
の障害は全体の契約件数の10分の1程度の規模となっております。影響
を受けた契約顧客数は5698件であり、障害の対象から外れるサービスの
契約数は約4万5000件です。それでも、今回の障害には大手企業のサイト
も含まれている事から、影響の深刻度は決して軽くないと言えそうです。

今後、詳細な検証結果が公表される事を期待します。
トラックバック
トラックバック送信先 :
コメント

[楽天市場の注目商品!]


[楽天ソーラー]

[楽天カードが便利!]

[楽天スーパーWiFi]