バックアップさえ取得していれば、システム障害やデータ消失から完全に復旧できるとは限らない。単なる「データ復元」が「サービス復旧」に直結しないのはなぜか。
「データのバックアップさえ取得しておけば、セキュリティ事故やデータの消失が起きても元通りに復旧できる」と企業は考えがちだ。しかし現実には、データのバックアップに成功していても、サービスの再稼働に失敗するケースが頻発している。企業がクラウドサービスの利用を拡大するにつれて、「データの復元」と「サービスの復旧」の間にあるギャップが浮き彫りになりつつある。
近年、企業はクラウドサービス内のデータを保護するために、オンプレミスインフラとクラウドサービスのバックアップの統合やバックアップツールの導入に対して積極的に投資している。しかし、どれほど高度なバックアップツールを導入しても、この根本的な問題は解決しない。「データが戻ること」と「そのデータを利用する業務システムが再び動くこと」は、全く別の問題だからだ。
バックアップの成功は、単にデータが複製されたことを意味するに過ぎない。現代のクラウドサービスは、データ単体で動いているわけではなく、多岐にわたる要素で構成されている。ユーザー認証などのID設定やDNS（ドメインネームシステム）のルーティング、属性や設定を示すメタデータ、外部企業が提供するAPI群、複数アプリケーション間の連携などがその例だ。通常のバックアップ処理では、これら全てを保存することは難しい。障害の発生後にこれらの依存関係が途切れたままになったり、正しい順序で再開されなかったりすれば、データは無事でもサービスは停止した状態が続く。
この「復旧の抜け穴」を防ぎ、確実にサービスを再稼働させるには何が必要なのだろうか。ベンダーが提唱する「責任共有モデル」の中で、企業は具体的にどう備え、どうすればよいのか。
バックアップに関する企業の成熟度には幅がある。初期段階にある企業は、セキュリティ監査などを通すための形式的な証跡作りとしてバックアップを取得し、データをコピーすれば作業完了と見なす。対照的に成熟度の高い企業は、事業継続戦略の一部としてバックアップを捉えている。具体的には、システム間の依存関係の把握や復旧手順の自動化、予備システムに切り替えるフェイルオーバーの予行演習などが含まれる。
Gartnerのアナリストであるフィンタン・クイン氏は、「分散型のシステム構成や現代のアプリケーション群の複雑さに手を焼く企業は後を絶たない」と指摘する。そうした企業は、復旧能力の確保を後回しにしがちだ。企業の投資判断は復旧要件に追い付いていないのが現状であり、IT担当者は復旧の仕組みより、ストレージの性能指標やセキュリティ機能に注目しがちだという。
「復旧の自動化よりも、不変性やネットワークからの隔離といった流行語への関心が依然として強い」（クイン氏）
企業が点在するバックアップシステムの一元化を図るようになる中で、これは大きな障壁となる。クイン氏によれば、大半の企業はオンプレミスインフラとクラウドサービス全体を単一のダッシュボードで可視化し、制御することを目指している。その結果、標準搭載のバックアップツールからサードパーティー製品へと乗り換え、管理体制の標準化と一貫したセキュリティ基準の適用を試みる動きが一般的になりつつある。
成熟度の高い企業はさらに一歩先を行く。そうした企業は「データのバックアップ」と「サービス全体の復旧」を明確に区別して扱う。この考え方は、複雑なITインフラをサイバー攻撃から復旧させる取り組みにも当てはまる。
「改ざん不可能なバックアップを保持するだけでは不十分だと、成熟した企業は気付いている」とクイン氏は述べる。
バックアップに真剣に取り組む企業であっても、技術的な壁に直面する。現代のクラウドサービスは、単独で完結するデータの集合体ではない。外部で管理されていたり、動的に割り当てられたりする周辺の構成設定に依存しており、標準的なバックアップではそれらを捉え切れないのだ。復旧作業が頓挫するのは、まさにこの部分だ。
調査会社Forrester Researchのプリンシパルアナリスト、ブレント・エリス氏は、この根本原因を「誤った同一視」と表現する。いまだに復旧のゴールを「サービスが稼働できる状態になったこと」ではなく、「データが元に戻ったこと」だと捉える企業が存在するという。
「復旧計画に欠けがちなのは、サービス間の依存関係を明確に示した構成図と、それを正しい順序で再構築するための作業手順だ」とエリス氏は語る。
エリス氏が典型例として挙げるのが、オーストラリアで国民的な確定拠出年金を運用する巨大基金UniSuperにおいて、2024年に発生したインシデントだ。同組織では、プライベートクラウドの設定作業中のミスが原因で、「Google Cloud」の契約全体が削除される事態に陥った。クラウドサービス内のデータと仮想マシンのバックアップは残っていたが、必要な顧客専用の設定が消失していたため、一から作り直さなければならなかった。「復旧に必要な情報が不完全な状態は、システムの設計次第でさまざまな形で表面化する」とエリス氏は説明する。
データの復元とサービスの復旧の間にあるギャップは、「クラウドサービスが停止した際、誰が復旧の責任を負うのか」という疑問をもたらす。ここで混乱の種になるのが責任共有モデルだ。「ベンダーに任せておけば何とかしてくれる」という期待は通用しない。大半の場合、ベンダーの責任範囲はインフラの稼働維持にとどまる。
例えばMicrosoftとSalesforceは、いずれもデータ保護が責任共有モデルに基づくことを明記している。Microsoftは、クラウド型オフィススイート「Microsoft 365」の災害復旧用データはバックアップの代わりにはならず、あくまでコンテンツの現在の状態を維持するだけだと明言している。Salesforceも同様に、自社のバックアップはインフラレベルの災害復旧を目的としており、それ以外の状況でビジネスレベルのデータを復元することはできないと明記している。
「企業はベンダーがサービスを復旧すると信じがちだが、契約上の義務は稼働維持であり、完全な復旧ではない。SaaSでは設定状態などを再構築せず、単にデータを戻すだけだ」とエリス氏は指摘する。データ保護が自社の責任であると理解している企業でさえ、SaaSの障害が長引いた場合には構造的な障壁にぶつかる。
エリス氏は次のように述べる。「SaaSの内部構造は不透明であり、障害時に別のシステムへ移行してすぐ業務を再開するのは極めて困難だ。データ構造の再定義や連携の再構築が必要であり、ベンダーロックインの事実が復旧の遅れを招く」
ストレージの性能だけではなく、クラウドの復旧能力を正しく評価するには、サービス間の依存関係、復旧手順の自動化、設定の復元などをカバーする機能を検討しなければならない。クイン氏とエリス氏は共通の課題を指摘する。それは、ツールを導入する企業が「データを引き出せるか」ばかりを問い、「サービスを稼働状態に戻せるか」をベンダーに確認していない点だ。
バックアップ製品の選定に際して、インフラの依存関係を評価し、サービスの完全な復旧能力を確保するためには、以下の質問項目をベンダーに投げ掛けるとよい。
復旧は技術的な課題であると同時に、製品調達の課題でもある。データ保護機能しか評価しない企業は、被害を受けた主要機能を手作業で再構築する事態に陥りかねない。一方で、復旧の自動化や依存関係の復元、テスト機能について深く切り込む企業は、自社が購入するものを正しく理解している。そうした企業は、復旧プロセスの大部分を自動化しやすい立場にあると言える。「これはクラウドネイティブなシステムを利用し、厳格な復旧テストが求められる企業が真っ先に注目すべきポイントだ」とクイン氏は言い添える。
Copyright © ITmedia, Inc. All Rights Reserved.
瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓
MFA（多要素認証）を入れたから安心という常識が崩れ去っている。フィッシング集団「Tycoon2FA」が摘発されたが、脅威が完全になくなったというわけではない。
「サイト内検索」＆「ライブチャット」売れ筋TOP5（2025年5月）
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。
「ECプラットフォーム」売れ筋TOP10（2025年5月）
今週は、ECプラットフォーム製品（ECサイト構築ツール）の国内売れ筋TOP10を紹介します。
「パーソナライゼーション」＆「A／Bテスト」ツール売れ筋TOP5（2025年5月）
今週は、パーソナライゼーション製品と「A／Bテスト」ツールの国内売れ筋各TOP5を紹介し...
ITmediaはアイティメディア株式会社の登録商標です。
