メル・ベックマン著

今からお話しするのは本当にあった出来事です。愚か者たちの名誉のために名前は変えてあります。さて、世にも恐ろしい物語の始まりです。

それはもう何年も前のことでした。ケイプロ・コンピュータという会社は、米国国税庁に提出する書類の期限前日に、ハードディスク・ドライブの壊滅的な障害に見舞われていました。提出に必要なデータの唯一のコピーがそのハードディスク･ドライブ上にあり、そのドライブのバックアップが取られていなかったのです。ケイプロ社の言い分は？「バックアップを取り忘れていた」からだそうです。ハードコピーからデータを回復させるのにいくらかかったと思いますか？ なんと40万ドルです！

バックアップにまつわる惨事は、インターネットの世界では日常茶飯事です。もちろんでっち上げの話もあります。しかし、そのほとんどは信憑性が高いものであり、特にその語り手が自分に不利になるような内容を提供していればなおさらです。ITの専門家として、私たちはバックアップを取り忘れてはならないのです。バックアップを取り忘れた人は民事罰の対象となりえます。また、将来的には独房に放り込まれる可能性も出てきます。

よくあるバックアップ取り忘れミスの犠牲となるようなことを避けるために、バックアップにまつわる一般的な「してはならないこと」を分類し、それぞれについて複合的な「ケース･スタディ」を作ってみました。この「してはならないこと」をうっかり犯してしまったら、今でこそ犯罪とはなりませんが、将来どうなるかはわかりません。ご一読いただいて、あなたご自身がそのような物語の主人公とならないようにご注意ください。

バックアップを検証しないことの大罪

バックアップの際に犯す罪のほとんどは怠慢によるものです。定期的にバックアップを取っているだけでは不十分なのです。回復の際に使用できるバックアップが作成されているかどうか、確かめなければならないのです。

その適例が、ここに登場する不運なデータセンターの管理者です。従来の設備が洪水の被害にあったため、交換用の設備のサーバーにデータを回復させるのが彼の役目でした。まず一本目のバックアップ・テープを挿入しました。バックアップ・ソフトウェアの返答は、「中身が空です。もう一度入れなおしてください」でした。テープを入れ直してみても、同じメッセージが返ってきます。「そういうことか。問題はない。これは日次のバックアップだ。洪水のせいで最後のテープが完了していなかったのだろう。その前の日のテープを入れてみよう。」と彼は考えました。しかし、そのテープも空でした。今度はちょっと焦りはじめ、週次バックアップのテープを入れてみました。しかしこれも空です。月次、四半期バックアップ・・・、すべて空でした。「こんなことあり得ない！」と叫ぶ他ありませんでした。

詳しい調べで明らかになったのは、毎晩バックアップ･ソフトウェアがオペレータに確認を求めていました。「新しいメディアが挿入されました。すべてのデータを削除しますか？」遅番担当のオペレータがその確認メッセージを誤解していたのです。「すべてのデータ」を削除するのではなく、このテープだけ削除すればいいと考え、「いいえ」と入力したため、バックアップ・ソフトウェアはそのまま処理を止めてしまったのです。今までまったく何もバックアップされていなかったのです。一度たりとも。データセンターの管理者は、確実にバックアップが取られているということに最終的な責任があったのですが、バックアップが正しく取られているかという検証をまったく行っていなかったのです。

回復の際に使用できるバックアップが定期的に取られていることを確かめるには、定期的にデータセット全体を回復させ、その内容がすべて判読可能であることを確認する必要があります。確かに、バックアップ・ユーティリティのほとんどはバックアップの際の記録プロセスの一環として、バックアップされたデータを自動的に再読み込みして検証しますが、起こりうるあらゆる障害モードが検知されることを期待してはいけません。月に一度はバックアップ･セットをランダムに選択して、スクラッチ・ディスクに回復させ、必要なファイルがすべて回復されているかどうかディスクをチェックすることで、バックアップが正しく行われていることを確認できます。

ログを確認しないという自殺行為

バックアップに失敗すると何故不幸かというと、問題が見つかったときが、たとえばデータの回復中のように、すでに手遅れとなっている場合がほとんどだからです。あるウェブサイトの管理者が、この自明の理を経験しました。ウェブ･サーバーを新しいコロケーション設備に配置換えした後に、社員向けのミッション･クリティカルなeコマースサイトのバックアップを再読み込みしているときのことでした。回復処理は何千個というファイルを処理したのですが、サイトがすべて回復されたとき、オンライン･ショッピングのアプリケーションが起動しなかったのです。

プログラマが呼び出され、問題箇所はすぐに判明しました。ウェブ･サイトのすべてのコンテンツは定期的にバックアップが取られていましたが、ファイル共有のロックが発生していたために、最も重要なトランザクション・データベースのバックアップが取られていなかったのです。毎回のバックアップ時に、バックアップ･ソフトウェアはファイル･ロックの問題が発生しているというメッセージを自動的にログしていましたが、ログを注意深く読んでいる人はいませんでした。その結果、バックアップ中にこの重要でかけがえのないデータベースがスキップされているとは、誰も知らなかったのです。

バックアップ処理は正常に稼動しているように見えました。処理時間も適切で、バックアップ用のボリュームもそれなりに消費しており、ログ・ファイルには何千というファイルが保存されていると記録されています。回復処理をスポット的に実行してみても上手くいっているようです。しかし、その回復されたデータを使って実際にアプリケーションを実行した人が誰もいなかったので、致命的なデータの消失が検知されず、気づいたときには手遅れになっていたのです。

ここでの教訓は、「ログ・ファイルをきちんと読みなさい」ということです。しかし、ログ・ファイルはいったい誰のものなのでしょうか。ほとんどの組織では、ログ・ファイルを「所有している」人がいないのが実態でしょう。ログ・ファイルは会社の共有財産なのです。しかし、重要なログ・ファイルには所有者が必ず割り当てられているはずです。バックアップ・ログやセキュリティ・ログは当然のことながら一番重要です。ログの所有者は、ログを定期的にチェックして、問題が生じていないかを調べなければなりません。また、所有者を定期的に交代するのもよいアイデアです。スタッフがログ・ファイル症候群で倒れないようにするためです。

バックアップが正しく取られているか否かを証明するために、単一の検証プロセスのみに依存してはいけません。定期的にバックアップから回復させることも重要ですが、バックアップが完璧に取られているか否かを確認する唯一の方法は、障害回復計画のリハーサルを適宜実施することです。

認識の甘さという罪

ITのプロたちにとって、バックアップ戦略を立案する際に、人的エラー、機器の故障、自然災害、などといった明らかな障害モードを予測するのは難しいことではありません。しかし、よく見過ごされがちではあるが、予測可能な障害として、故意にバックアップ・データが改竄されることがあります。ある大手金融機関が、この教訓を身をもって学ぶはめになりました。FBIが複数の窃盗事件を調査していたところ、この金融機関にたどり着いたのです。社内の誰かが、会社の顧客データベースから機密の個人情報を窃盗犯に売っていたのです。

トランザクション・ログ、スタッフのデータベースへのアクセスのパターン、通信先を詳細に監査したところ、何も問題が見つかりませんでした。情報を漏洩した犯人は非常に上手く証拠を隠滅したか、会社の数多くのセキュリティ管理を通らずにデータにたどり着いたか、のいずれかになります。この場合は後者であることが明らかになりました。管理権限の低い社員が、古いバックアップ・テープを保管庫から持ち出してコピーし、オリジナルのテープとすり替えたのです。幸いにも犯人は捕まりました。

この場合、ITスタッフがはまった落とし穴は、緊急のデータ回復用としてはデータが新しくない古いバックアップ・テープは、その他の用途でも役に立たないであろうと思い込んだことです。古いテープは共用の保管庫に保存されて、古い記録の回復用にアクセス可能になっているのに対し、「本物の」最新のテープは毎晩会社から持ち出されていたのです。セキュリティが確保されているオフ・サイトの倉庫は、費用がかかり、しかもスペースも限られているので、オフ・サイトにあった古いテープが本社に戻されて、長期間保管されていたのです。さらに悪いことに、1年以上前のテープはセキュリティの確保されていない共用の倉庫施設に運ばれていたのです。

すべてのバックアップ・テープは常に慎重に取り扱い、平等に保護をしておかなければなりません。古いメディアを安全な場所に保管できないのであれば、破棄してその詳細を記録して保管し、ある日FBIがドアをノックしても、当然の注意義務は果たしたことを証明できるようにしておかなければなりません。

バッテリーへの急襲

バックアップ・システムで考慮しなければならないのは、実際のデータの蓄積だけではありません。バックアップしたボリュームの完全性は保たれていても、障害発生時にそのデータを使用するための計画が検証されていなければ、一番タイミングの悪いときにどうしたら良いのかわからずに窮地に陥ることになります。ある電話会社のIT役員を襲った不幸がまさにこのケースです。このIT役員は、天候が荒れやすい海岸地方にある顧客サービス・センターには、バックアップ・データ・センターが必要であると先見の明を持っていたのです。

競合他社のサービス・センターが暴風のためにオフ・ラインになったのを見て、より内陸部の安全な場所に予備のデータ・センターを構築したところまでは彼は正しかったのです。新しいデータ・センターは、オリジナルのデータ・センターと寸分違わぬ複製となっており、理論上では、いつでも数時間以内に利用可能になるようになっていました。案の定、このバックアップ・サイトが運用を開始してから数年後、メインのサポート・センターが大変な暴風に見舞われました。この時点で、バックアップ・データはすでに別のサイトに保存されていました。そこで顧客サービスのスタッフは、この別のサイトに到着するとすぐに機器を操作し始め、バックアップを取り込んで緊急時の運用を開始しました。この作業には1時間かかりました。

1時間後、施設の電源が短時間停電しました。メインのデータ・センターとまったく同じバッテリーのバックアップが、ほんの数秒間だけその役目を果たしたかと思うと、あっという間に切れてしまったのです。暴風のために施設の電源は、回復したり止まったりを繰り返しました。このバックアップ・サイトは、以後数日間に渡って断続的な停電に悩まされました。そして、停電を乗り切るための安定したバックアップ用のバッテリーがないため、そのデータ・センターは閉鎖せざるを得なくなりました。

バックアップ施設の空調が停止して、バッテリーが加熱状態になっていたことがバッテリー故障の原因であることが後日わかりました。このバックアップ・センターは普段は運用されていなかったので、バッテリーを冷却する必要はないだろうと思っていたのです。バッテリー室を高温のままにしておいたので、バッテリーの電解液が徐々に「加熱調理」され、役に立たないものになっていたのです。

バックアップ用のオペレーション・センターや、通信回路やサーバー・ハードウェアなどの物理的な緊急用設備をお持ちなのであれば、「ホット・スタンバイ」モードで常に稼動させておくか、少なくとも定期的に運転してください。電気設備は手入れをしないと性能が低下します。緊急時に使用する資源が利用可能状態になっていることを確実にする唯一の方法は、その資源を定期的に使ってみることです。

サーバー・ラックの大量虐殺

職業安定所への道は、善意という敷石が敷き詰められている。つまり、何事も実行されなければ無意味なのです。日々のデータ管理については、誰もが注意を払っているつもりですが、誰でも自己満足に陥ってしまう可能性はあります。次々とシステムが増え続けているITデータ・センターでは、たった一つの不注意がIT資源の山をほんの一瞬で破壊しかねません。

大規模な小売流通業を営むある会社では、その本社オフィス・ビルの中央にある、塵ひとつ落ちていない、窓のあるショー・プレイスでデータ・センターを運用していました。その会社のITマネージャーは、施設のすべての入口で厳格なセキュリティを管理していて、許可を受けていない行動を監視するように常に言い聞かせていました。訪問者には必ず付き添いが付き、許可を受けていない人は、セキュリティ・エリアでは決して一人にはなれませんでした。

しかし、新しい空調設備を設置する工事の週に、一人よがりの行動が災いをもたらしました。作業員が、セキュリティ・エリアに入れてほしいと頼みにくることが数日続いたため、担当社員はドアにつっかえ棒をして開けたままにしたのです。この行動は、取り返しのつかない大惨事を招きました。

新しい空調設備は交流240ボルトで稼動しますが、これはサーバー室に並べられている、数多くのラック･マウントのサーバーに供給されている電圧の2倍です。新設備への電源ケーブルをつなぐ際、作業員は立ち並ぶラックの中からバックアップ用電源のコンセントを引き抜き、それを空調ユニットの新しい240ボルトの電源に差し込みました。後から別の作業員がやってきて、コンセントの近くの床に電源ケーブルが外れたまま置かれているのを見つけ、何かの拍子に抜けてしまったのだろうと思い込み、それを差し込みました。すると、バーン！と大きな音がして、会社の中核のアプリケーション・サーバーが置かれたラック筐体から、鼻をつんと突く煙があっという間に立ち昇りました。わずか数秒の間に、何十台というサーバーが破壊されました。

もちろん、こうした特別な状況はめったに無いことですが、作業員を付き添い無しでセキュリティ・エリアに立ち入らせないという規則を社員が守っていさえいれば、このような大惨事は防げたのです。

テープを無防備のまま運搬する

今までのお話でお分かりの通り、機密情報を含んだバックアップ・メディアはどこへ持ち運ぶにも保護されなければなりません。そのようなバックアップ・ボリュームを民間の配達サービスのような第3者に委託して、オフ・サイトの安全な場所まで運んでもらわなければならないようなこともよくあることです。しかし、業者が荷物を紛失してしまうこともあり、その被害は甚大になることもあります。驚いたことに、巨大な民間会社3社が、1ヶ月おきに次々とこのような紛失事故に見舞われたのです。その事故が壊滅的な結果となった理由は、バックアップが暗号化されていなかったからなのです。

ある会社は、現在および過去に勤務していた社員の個人情報60万件の記録を紛失しました。もう1つの会社は、20万人の株式仲買顧客を財政破綻の危機に陥れました。3つ目の会社は、60人の米上院議員を含む120万人の連邦政府職員の個人財務詳細情報を漏洩してしまいました。この話に共通しているとても悲しい背景は、バックアップ・メディアの事前の保護策として暗号化しておけば問題がなかったという事実です。

データの暗号化は、今日では広く利用され、事実上無償で利用できます。確かに、バックアップ戦略の中に暗号化処理を組み入れるのには、多少の労力を要します。それは、復号鍵をバックアップ・サイトに安全に配布して、緊急事態のときにデータを回復できるようにするという労力では決してありません。復号鍵の配布方法は、物理的なバックアップ・メディアの配布方法とは別の方法でなければならないのですが、この配布方法の課題に対する解決策は多数あります。その中から1つだけを選択すればよいのです。

上記の3つの会社で起こった事故は、この種の事故において単独の事例ではありません。最も広く公表されている例であるというだけです。このような大きな会社がバックアップの暗号化を怠っているとなると、もっと小さな規模の会社ではどれだけこの問題がはびこっているのでしょう。この種の問題がどの程度広がっているかを把握できる統計情報は存在しませんが、非常に多くの企業で暗号化が行われていないと推測するのが妥当なようです。しかし他社の心配をする必要はありません。まずは自社のことを心配するべきです。自社の状況についての統計情報なら簡単に作成できます。

恐怖の物語を体験しないために

以上お話したバックアップの悲劇を念頭において、自社のバックアップ手順をもう一度見直してください。IT担当者全員で見直し作業をするのが良いでしょう。そうすれば、バックアップ・システムの安全性を連動している、サイトのセキュリティ施策を見直す良い機会にもなります。今回ご紹介した恐怖の物語にあるような違反行為について1つでも心当たりがあるなら、見直しをする機会は残されています。自分の行為を何も言わずに是正してください。そして、「忘れていた！」と言えるなどとは絶対に思わないでください。

メル・ベックマン氏はベル・データ�鰍ﾌ提携先、米Penton Media, Inc.が発行している月刊誌「iSeries NEWS」のシニア・テクニカル・エディターです。