そのバックアップで本当に大丈夫!? ~失敗事例から紐解く、バックアップ時に忘れてはならない”あの”観点~ ブックマークが追加されました
近年、「ヒト・モノ・カネ」に続く4つ目の経営資源として「情報」が重要とされており、データやプロセスなど組織が持つ「情報」の資産価値が注目されている。「ヒト・モノ・カネ」を失えないのと同じように、「情報」も容易く消失することはできない。機器・ソフトウェアの障害やヒューマンエラーのほか、情報を暗号化するランサムウェアによって予期せぬデータ消失を被るのは、組織にとって痛手だ。
このような場合に備え、バックアップを取得することが有効とされている。バックアップとは、サーバなどの機器に記録されたデータを異なる媒体にコピーして保存することだ。いざという時、バックアップが無ければ過去の正常なデータを復旧させることは難しい。米国国土安全保障省ではUS-CERT(United States Computer Emergency Readiness Team)によって、全てのコンピュータユーザが重要データのバックアップを行い損失や破損に備える必要があると説かれているほか、総務省「国民のためのサイバーセキュリティサイト」でも、情報管理担当者の情報セキュリティ対策としてバックアップが推奨されている。
では、バックアップの取得にあたってどのような点に注意すべきだろうか。まず、本テーマに纏わるよくある誤解として、ある組織のセキュリティ担当役員A氏の発言を見てみよう。
A氏の組織では、平時から重要データのバックアップを取得している。たとえ何らかのシステム障害によってデータ消失が発生しても、バックアップを活用すれば問題なく過去の正常なデータを取り戻せるように思える。A氏と同様の考えから「バックアップさえあれば問題なし」とする組織は多いが、果たして本当に正しいだろうか。
バックアップを取得する目的は、先に説明したように何らかの理由でデータを消失した際、正常なデータの復元を行うことだ。本稿では、このようにバックアップからデータを復元する処理をリストアと呼ぶ(一般的には、さらに現在までの変更情報を反映して復旧することをリカバリと呼ぶ場合もある)。
つまり、いくら大量のバックアップを持っていても、そのバックアップをリストアに利用できなければ全く意味を為さないことになる。そしてここで留意すべきことは、実際にバックアップがあってもリストアできない例が少なくない、ということである。最近では国内の大手食品企業でも、バックアップを取得していながら有事にリストアできず大事に至ってしまった例が記憶に新しい。過去に米国で実施された調査では、データベース管理者の8割以上がリストアやリカバリに関する失敗を経験したと回答している。そのほかランサムウェア被害時にもこのような事例は多く、警察庁「令和4年におけるサイバー空間をめぐる脅威の情勢等について」によれば、ランサムウェア被害時、バックアップを取得していた企業・団体等のうち、バックアップを活用できたのは僅か19%だった。では、このような事例はいったい何故起きてしまうのだろうか。
本稿ではまず、バックアップを取得したもののリストアできない失敗事例を示す。次に、事例毎の原因や打ち手を考察する。そのうえで、各事例の引き金となっている真因と、リストアを見据えたバックアップの効果的な考え方を解説する。
初めに、A氏の組織ではどのようなリストアの失敗が起こり得るか、次章で代表的な3つの事例を解説する。
例えば、重要性を見誤ってバックアップ範囲外としていたデータが壊れてしまったり、前日の状態に戻ることを期待していたら1か月前の状態にしか戻れなかったりといった事例が挙げられる。
原因は、リストアを見据えたバックアップの範囲や方法の決定が、不十分であることだ。
冒頭でも述べた通り、組織が持つ「情報」は経営資源として無視できない資産価値を持つようになった。有事に「情報」を失わないためには、日頃からどのような「情報」を有し、何を重要としてバックアップ対象に含めるのか、どの時点の状態まで戻せればよいのか、など綿密に検討しておく必要がある。一般的には、BCPなどで定めるRPO(復旧に伴う最大データ損失量)やRTO(復旧にかかる最大許容時間)といった経営指標に基づく計画を策定し、これに基づいてバックアップを実施する。
例えば、導入間もないシステムの重要度が正しく決定されているか、バックアップ頻度は月次で十分かなど、バックアップ前に自組織の「情報」を洗い出し、リストア時の必要性を十分に整理した上でバックアップを実施する必要がある。
例えば、自然災害によってバックアップを失ってしまったり、ランサムウェアによってバックアップまで暗号化されてしまったりといった事例がこれにあたる。
原因は、効果的な保管方法を選択できていないことだ。1箇所に1つのバックアップしか保管していなければ、当然災害時などのリスクは高まるうえ、近年ではバックアップがランサムウェアの標的となり得ることも念頭において保管場所を計画しなければならない。
バックアップの損失を防ぐ考え方の一つとして、US-CERTが提唱する「3-2-1ルール」がある。これは、重要なデータに対して3つのコピーを2種類以上の媒体で、1つはオフサイト(別の場所)で保管すべきというものである。近年ではバックアップサービスを手掛ける米国企業を中心に、1つはオフラインで保管するとした「3-2-1-1ルール」や、さらにエラーが発生しないことを確認させる「3-2-1-1-0ルール」など独自の拡張ルールも提唱されはじめている。
これらの実現には、長期保管用ストレージの用意や複数媒体・複数箇所でのバックアップ管理などが求められるが、データ消失時にバックアップまで消失してしまっては二の句が継げない。重要システムでは是非導入しておきたい概念である(図1)。
図1:バックアップの「3-2-1」ルールとその拡張概念
例えば、バックアップやリストアに関する手順が属人的だったり、手順書に記載の漏れがあったりといった事例が考えられる。
原因は、これらの手順が標準化されていない、または最新化されていないことだ。正しい方法やタイミングでバックアップを計画しても、手順が不明瞭であれば重大なヒューマンエラーを招きかねない。
一般的に、組織にはスキルの異なる様々な人間が所属する。有事の対応手順は、担当者のスキルによらず正確な実施が可能となるよう、手順書として標準化することが大前提だ。さらに組織やビジネスは、常に内部および外部の環境変化に晒され、千変万化である。この変化に伴ってシステムの構成や運用も変化するため、従来の手順のままでは陳腐化してしまう。手順は一度作成したからといって慢心せず、このような状況変化に応じて定期的に網羅性や整合性を見直し、最新化しておくことが望ましい(図2)。
図2:環境変化に起因する手順の更新サイクル
ここまで、バックアップを取得していながらリストアに失敗してしまう事例を見てきた。先に述べたケース①から③はどれも代表的な失敗事例だが、それぞれ異なる事象に起因するように見える。ケース①は対象データ/方法の不正確さ、ケース②は保管方法の不適切さ、ケース③は手順の未確立/陳腐化が原因であり、それぞれ短期的な打ち手も異なる。
しかし、これらは全て一つの真因から生じていると考えることができる。本稿の冒頭で、バックアップの目的は「正常なデータを復元すること」、すなわちリストアであることを説明した。しかし先の事例では、いずれの場合もこのリストアについて十分に検討が為されておらず、バックアップが機能していない。つまり失敗事例を引き起こす真因とは、バックアップの目的である”リストア”を意識したバックアップが為されていないことである(図3)。
図3:バックアップに係る失敗事例・原因・真因
これらの失敗事例は、A氏の組織のように、正常なデータを保存するというバックアップの重要性に囚われたがゆえに、リストアというバックアップの本来の目的を見落としてしまっている場合に、起こりやすい。
バックアップとリストアは手段と目的という点で切り離すことのできない関係だ。目的である”リストア”を常に意識することで、正しいバックアップや平時の行動が導かれ、リストアの実現に至る。このようにリストアの実現を見据えるにあたって根底を為すのは、正しい目的意識なのである(図4)。
図4:失敗事例から見えるリストアへの目的意識の重要性
とはいえ、自組織の意識・行動がリストアを実現するうえで十分か、机上の空論だけで判断することは難しい。実現性を検証するには、定期的なリストアテストの実施が不可欠だ。
このような検証作業は重要性が認識されづらく、国内の大手企業でも、リストアの実現性検証はシステム構築時のみ、といった例が散見される。「データベース・セキュリティ」の普及促進を図るDBSC(データベース・セキュリティ・コンソーシアム)の調査「アンケートから見たDBセキュリティ対策とDBA意識」によると、バックアップからデータを戻す訓練の実施率は約5割に留まる。しかし、意識や行動の不足点を洗い出すうえでは欠かせない作業だ。内部環境、外部環境の変化に合わせ、必要に応じてタイムリーに検証することが望ましい。ただし経営リソースなどに鑑みて、定期的に(例えば、少なくとも年に1度など)実施することも考えられる。定期的な実施を促す動機が組織内に無ければ、ポリシーなどの上位文書でこの点を明記のうえ、活動計画書などに組み込んで予算を確保しておくことも肝要だ。
冒頭、A氏の発言にあったように「バックアップさえあれば問題なし」とするのではなく、“リストア”への目的意識をもって実施することがバックアップの大原則だ。
バックアップとリストアは表裏一体であり、リストアを念頭としないバックアップではいざという時に有効な打ち手になり得ない。
A氏には、次のような発言を期待したい。
いざという時本当に頼れるバックアップを目指して、明確な目的意識とともに対策にあたりたい。
塚越 雄登/Yuto Tsukagoshi
デロイト トーマツ サイバー合同会社
デロイト トーマツ参画後、金融業や自動車OEMなどを中心にサイバーセキュリティ態勢の第三者評価やセキュリティ中期計画策定の助言、国内外でのセキュリティ認証審査対応等のアドバイザリー業務に従事。近年は特に、B2B/B2C向け顧客IDとアクセス管理(Customer IAM)に係る戦略策定に関与。
※所属などの情報は執筆当時のものです。