サイバーレジリエンスの鍵は統合されたリカバリ戦略にある

多くの企業は、自社にはサイバーレジリエンス戦略があると考えています。

Veeam、Rubrik、Cohesiteといったプラットフォームでデータをバックアップし、IDはOktaやMicrosoft Entra IDで管理しています。 

クラウドインフラはAWS、Azure、Google Cloudにまたがり、ネットワークやエッジの構成はCloudflare、Akamai、F5、Fastlyに存在することもあります。可観測性についてはDatadog、Splunk、Dynatrace、Grafanaが担っています。 

各レイヤーにはそれぞれ独自の管理体制、担当チームがあり、さらに近年ではそれぞれ独自のリカバリ手法まで存在します。

表面上はこれで十分な備えに見えます。しかし実際には、これは分断にほかなりません。

リカバリは依存関係の問題

サイバーレジリエンスは、最終的には事業がどれだけ迅速に再稼働できるかによって測られます。これは、個々のプラットフォームを復旧できるかどうかとは全く別の問題です。

あるプロダクションアプリケーションがAWS上で稼働し、認証にOkta、DNSとエッジルーティングにCloudflare、監視にDatadog、デプロイワークフローにGitHub、運用プロセスにServiceNowを使用しているとします。そのデータは、これらとは全く異なるバックアッププラットフォームで保護されているかもしれません。

これらのシステムはそれぞれ単体で見れば「保護されている」と言えます。しかし、アプリケーションはこれらの依存関係が連携して初めて機能するのです。

これこそが、現在のサイバーレジリエンス市場が抱える構造的な弱点です。事業は一つの繋がったシステムとして稼働しているにもかかわらず、リカバリはベンダーのカテゴリーごとに分断されています。

欠落しているのは構成というレイヤー

この分断が最も顕著になるのが、構成のレイヤーです。

OktaやEntra IDを復旧するということは、単にユーザーレコードを復元するだけにとどまりません。グループ、ロール、条件付きアクセスポリシー、アプリケーション連携、認証ルール、権限など、すべてを信頼できる状態に戻す必要があります。

ネットワークについても同様です。CloudflareのDNSレコード、Akamaiのルーティングルール、F5のポリシー、セキュリティ構成が、それらが支えている環境と一致しなくなっていれば、AWSのワークロードを復旧させてもほとんど意味がありません。

可観測性もまた、別の依存関係を生み出します。アプリケーション自体は稼働していても、Datadogのモニター、Splunkのアラート、Dynatraceの設定、Grafanaのダッシュボードが失われていれば、インシデント対応チームは必要な可視性を得られなくなってしまいます。

これらのシステムは、リカバリプロセスの中で切り離されたパーツではありません。事業のリカバリは、これらを一体として復旧できるかどうかにかかっているのです。

個々には全て復旧できても、全体としては失敗し得る

大規模なサイバーインシデントが発生したと想像してみてください。Rubrikがデータを復元し、AWSのワークロードが再稼働します。Okta、Cloudflare、Datadogも再び稼働状態に戻ります。各チームはそれぞれ、自分たちのシステムが復旧したと報告します。

しかし、環境全体としては、もはや噛み合っていません。

Oktaのポリシーは誤った状態にあり、Cloudflareは間違った時点に復元されています。AWSのセキュリティグループはインシデント発生中に変更され、重要なDatadogモニターは失われ、GitHubのデプロイ権限はプロダクション環境と一致しなくなっています。

すべてのプラットフォームが利用可能な状態にあっても、事業そのものは稼働できないままかもしれません。

これこそが、プラットフォームのリカバリと事業のリカバリの違いです。 

個々のシステムを復旧させるだけでは、それらの間の依存関係も同時に復旧させない限り、サイバーレジリエンスは実現しません。

復旧可能性のギャップは、ツールとツールの間に存在する

従来のレジリエンス戦略は、各技術がそれぞれ保護されているかどうかを問う傾向にあります。

• データはバックアップされているか
• IDを復旧できるか
• AWSの災害対策(ディザスタリカバリ)は整っているか
• SaaSのバックアップ戦略はどうなっているか

いずれも重要な問いですが、その間には、もう一つ別の問いが存在します。

これらすべてのシステムを連携させている構成を、私たちは復旧できるのか。

ここには、IDポリシー、ネットワーク設定、クラウドリソース、可観測性のルール、SaaS連携、アクセス制御、そしてサードパーティの依存関係について、最後に確認できた正常な状態(last known-good state)が含まれます。

今日、これらのリカバリポイントは、さまざまなツール、各ベンダー固有の履歴、IaCリポジトリ、スクリプト、チケット、ドキュメント、そして環境を構築した担当者の記憶にまで分散して存在しているのが実情です。

これが、復旧可能性のギャップです。

サイバーレジリエンスには連携の取れたリカバリが不可欠 

サイバーレジリエンスを実現するために、組織がすでにバックアップ、ID、クラウドインフラ、ネットワーク、可観測性のために使用しているプラットフォームを置き換える必要はありません。課題は、それらのシステムを連携して復旧できる状態にしておくことです。

そのためには、環境全体にわたる構成と依存関係の可視化に加え、何がいつ変更されたのかを示すバージョン管理されたリカバリポイントが必要です。組織はまた、信頼できる状態を特定し、インシデント発生後に実際に復元可能な構成がどれかを把握しておく必要があります。

これは特にクラウド構成において重要です。インフラ、IDポリシー、ネットワークルール、アプリケーションの依存関係は絶えず変化し続けるためです。

目標は、単に個々のプラットフォームを復旧させることではありません。それらのプラットフォームが連携して機能するために必要な構成と依存関係を復元することにあります。

分断された保護は、サイバーレジリエンスとは言えない

もはや企業が導入するのは単一の技術スタックではありません。企業は何百もの相互に連携したプラットフォームを運用しています。

AWSは一つの役割を担い、Oktaはまた別の役割を担っています。Cloudflare、Datadog、GitHubもそれぞれ、運用環境における重要な一部を担っています。

こうしたアーキテクチャがなくなることはありません。

しかし、この同じ境界線に沿って構築されたリカバリ戦略は、次第に正当性を保つことが難しくなってきています。

インシデントが発生している最中、経営陣にとって、データバックアップが成功したことや、IDが復旧したこと、ネットワークチームが「もう少しで完了する」といった状況はどうでもよいことです。

唯一意味のある問いは、事業が稼働できるかどうかです。個々には成功したリカバリの集まりであっても、全体としては失敗したリカバリになり得るのです。

予防だけではもはや十分ではない理由を知り、組織は運用レジリエンスの構築に取り組む必要があります。