ほとんどの企業は、サイバーレジリエンス戦略を整備していると答えるだろう。
Veeam、Rubrik、Cohesityなどのプラットフォームでデータをバックアップし、アイデンティティはOktaまたはMicrosoft Entra IDで管理している。
クラウドインフラはAWS、Azure、Google Cloudにまたがって存在する。ネットワークやエッジの構成は、Cloudflare、Akamai、F5、Fastlyに置かれている場合がある。可観測性はDatadog、Splunk、Dynatrace、Grafanaが担う。
各レイヤーにはそれぞれ独自の制御、担当チーム、そして近年では独自の復旧手順がある。
机上では、これで網羅できているように見える。実際には、断片化している。
復旧は依存関係の問題
サイバーレジリエンスは、最終的にはビジネスをどれだけ早く再開できるかで測られる。個々のプラットフォームを復旧できるかどうかを問うこととは異なる。
本番アプリケーションはAWS上で稼働し、認証にOkta、DNSとエッジルーティングにCloudflare、監視にDatadog、デプロイワークフローにGitHub、運用プロセスにServiceNowを使っているかもしれない。データは、まったく別のバックアッププラットフォームで保護されている可能性もある。
これらのシステムはすべて、個別には「保護されている」と見なせる。しかし、アプリケーションが機能するのは、依存関係が連携して動く場合だけだ。
これこそが、今日のサイバーレジリエンス市場における構造的な弱点である。ビジネスは1つの接続されたシステムとして動いているのに、復旧はベンダーのカテゴリーごとに分断されている。
欠けているのは構成のレイヤー
この断片化が最も明確に表れるのが、構成のレイヤーだ。
OktaやEntra IDを復旧するには、ユーザーレコード以上のものを戻す必要がある。グループ、ロール、条件付きアクセス ポリシー、アプリケーション連携、認証ルール、権限のすべてを、信頼できる状態に戻さなければならない。
ネットワークも同様だ。CloudflareのDNSレコード、Akamaiのルーティングルール、F5のポリシー、セキュリティ構成が、それらを支える環境と一致しなくなっていれば、AWSのワークロードを復旧してもほとんど意味はない。
可観測性も別の依存関係を生む。アプリケーションが稼働していても、Datadogのモニター、Splunkのアラート、Dynatraceの設定、Grafanaのダッシュボードが失われれば、インシデント対応チームは必要な可視性を得られない。
これらのシステムは、復旧プロセスを構成する別々の部品ではない。ビジネスの復旧は、それらを一体として戻せるかどうかにかかっている。
すべてを個別に復旧しても、全体としては失敗する
大規模なサイバーインシデントを想像してみよう。Rubrikがデータを復旧し、AWSのワークロードがオンラインに戻る。Okta、Cloudflare、Datadogも再び稼働している。各チームは、自分たちのシステムが復旧したと報告する。
しかし、環境はもはや一体として機能しない。
Oktaのポリシーが正しくない。Cloudflareは誤った時点の状態に復旧されている。インシデント中にAWSのセキュリティグループが変更された。重要なDatadogモニターが失われている。GitHubのデプロイ権限は、もはや本番環境と一致しない。
各プラットフォームは利用可能でも、ビジネスは依然として運営できない可能性がある。
これが、プラットフォームの復旧とビジネスの復旧の違いだ。
個々のシステムを復旧するだけでは、それらの間の依存関係も復元しない限り、サイバーレジリエンスは実現しない。
復旧可能性のギャップはツール間にある
従来のレジリエンス戦略では、それぞれのテクノロジーが保護されているかどうかを問う傾向がある。
- データはバックアップされているか。
- アイデンティティを復旧できるか。
- AWSのディザスタリカバリは用意されているか。
- SaaSのバックアップ戦略はどうなっているか。
いずれも重要な問いだが、その間にはもう1つの問いがある。
これらすべてのシステムを連携させている構成を復旧できるか。
そこには、アイデンティティポリシー、ネットワーク設定、クラウドリソース、可観測性ルール、SaaS連携、アクセス制御、サードパーティーの依存関係について、最後に正常だった状態が含まれる。
現在、こうした復旧ポイントは、異なるツール、ベンダー固有の履歴、IaCリポジトリ、スクリプト、チケット、ドキュメント、そして環境を構築した人々の記憶に分散していることが多い。
これが復旧可能性のギャップである。
サイバーレジリエンスには、連携した復旧が必要
サイバーレジリエンスを実現するために、組織がバックアップ、アイデンティティ、クラウドインフラ、ネットワーク、可観測性に現在利用しているプラットフォームを置き換える必要はない。課題は、それらのシステムを一体として復旧できるようにすることだ。
そのためには、環境全体にわたる構成と依存関係を可視化し、何がいつ変更されたかを示す、バージョン管理された復旧ポイントを用意する必要がある。組織はまた、信頼できる状態を特定し、インシデント後に実際に復元できる構成を把握しなければならない。
これは、インフラ、アイデンティティポリシー、ネットワークルール、アプリケーションの依存関係が継続的に変化し得るクラウド構成において、特に重要だ。
目的は、個々のプラットフォームを復旧することだけではない。それらのプラットフォームが連携して機能するための構成と依存関係を復元することだ。
断片化された保護はサイバーレジリエンスではない
企業はもはや、1つのテクノロジースタックを購入していない。相互接続された何百ものプラットフォームを運用している。
AWSは1つの役割を担い、Oktaは別の役割を担う。Cloudflare、Datadog、GitHubも、それぞれ運用環境の別の重要な部分を担っている。
このアーキテクチャがなくなることはない。
しかし、同じ境界を軸に構築された復旧戦略は、ますます正当化しにくくなっている。
インシデント発生時、取締役会が気にするのは、データのバックアップが成功したか、アイデンティティが復旧したか、ネットワークチームが「ほぼ完了」したかではない。
意味のある唯一の問いは、ビジネスを運営できるかどうかだ。個々の復旧が成功しても、全体としては復旧に失敗する可能性がある。
予防だけではもはや不十分な理由を学び、組織はオペレーショナルレジリエンスを構築する必要がある。