インシデント発生前にITチームが策定した計画（第1回で詳述）は、どのユーザーおよびデータが重要かを定義し、リカバリプレイブックの所要時間を見積もり、その妥当性を検証するものです。しかし、その価値は、それを実行するシステムにかかっています。
M365のインシデントが発生した際には、チームがプレッシャーの中で優先順位を判断する必要なく、計画が自動的に実行されなければなりません。ここで役立つのが、Autonomous Business Recovery（自律型ビジネス復旧、ABR）です。
ABRは、企業存続に最低限必要な機能（MVC）復旧計画に基づき、チームによるリアルタイムのトリアージなしに、自動かつ正確に計画を実行するシステムです。ランサムウェア、管理上のミス、IDの侵害など、データ損失イベントが発生すると、ABRは計画を実行に移します。
ABRと従来の一括復旧アプローチとの違いは、外科手術のような精密さにあります。従来の復元はすべてを一度に実行しようとするため、数時間でMicrosoftのAPI制限に達してしまい、最も重要なユーザーを、テナント内で最も重要度の低いデータと同じキューで待たせてしまいます。ABRはその逆を行います。MVC計画で定義されたものだけを、適切な対象者に対して、適切な順序で復旧します。ABRは3つの中核となる機能を通じてこれを実現しており、それぞれの機能が従来の復旧における異なる失敗要因に対処します。
古い前提に頼らず、最新のインテリジェンスを活用
インシデントが発生すると、多くの組織では、復旧の判断基準となる情報が古くなっていることに気づかされます。前四半期に行った分類作業では、財務チームが現在活発に利用しているSharePointサイトの状況を反映できていません。6ヶ月前に見直したMVC計画では、先週3人の重要ユーザーが取り組んでいたプロジェクトが考慮されていません。
ABRは、インシデントが発生する前にこの問題に対処します。Rubrikは、お客様の環境全体にわたって、バックアップメタデータ、ファイルインデックスデータ、Microsoft 365監査ログからシグナルを継続的かつバックグラウンドで取り込みます。これにより、どのデータが実際に誰によって、いつ最後に使用されたかを示すライブマップを構築します。復旧を開始する際は、数ヶ月前の想定に基づいてではなく、インシデント発生時点での組織の実際の状態に基づいて、復旧を実行します。
復旧シナリオ | 従来の一括復旧 | RubrikのMVCとABR |
復旧のトリガー | プレッシャーのかかる不確実な状況下で、手動でのトリアージが始まります。 | 事前に検証済みのリカバリプレイブックが自動的に実行されます。 |
最初の重要な数時間 | 対策本部の混乱：業務が停止したまま、技術チームが復旧の優先順位を巡って議論を重ねる。 | 戦略的マネジメント：ITチームが経営層、法務部門、顧客に対して明確なコミュニケーションをとることができる。 |
業務復旧までの時間 | 数週間〜数ヶ月：Microsoft APIの厳しいスロットリング制限により、復旧作業が阻害される。 | 数分〜数時間：インテリジェントなフィルタリングにより、ビジネスの核となる業務を即座に復旧させる。 |
経営層のガバナンス | 後手に回る説明：プレッシャーの中で、取締役会や規制当局に対し、技術的な遅延について弁明する。 | 監査可能な説明責任：事前に検証済みで、コンプライアンスに準拠した判断を下し、組織の評判を守る。 |
数週間ではなく、数時間で稼働可能
M365のインシデントで最も大きな損失を招くのは、発生直後の数時間です。それは、この間は即座に行動しなければならないというプレッシャーが最も高く、かつ、正しい判断を下すために必要な情報が最も不足しているからです。ITチームは対策本部で、役員のメールボックス、法務関連ファイル、顧客対応データのどれを先に復旧すべきか、状況が見えないまま手探りで議論を交わしています。
ABRは、こうした混乱を完全に解消します。ABRは、事前に検証済みのMVC計画を即座に実行します。何百万もの古いアイテムを無計画に一括復旧してMicrosoftの1日あたりのAPI制限を使い果たすのではなく、コアチームの機能維持に必要な重要な通信チャネルとデータのみを復旧します。管理者は、復旧作業が進行している間、インシデント発生時に最も重要な業務、すなわちリーダー層、法務部門、影響を受けるビジネスユニットとの連携に専念できるようになります。
ABRは復旧の優先順位と順序を決定すると、利用可能なすべてのAPI呼び出しを、重要なユーザー向けの優先度の高い資産に集中させます。ABRは、後回しにできる価値の低いコンテンツの復旧や、MVCの範囲外のユーザーのデータ復旧にはリソースを一切費やしません。
その正確性が、組織がいかに迅速に業務を再開できるかを直接左右します。大規模なM365環境において完全な一括復旧を行う場合、数週間かかることもあります。インシデント発生前に定義されたものだけを復旧することで、ABRは最小限の事業継続機能（MVB）を備えた状態を実現し、3時間以内にコア業務を機能させ、組織が対応可能な状態に導きます。
ビジネス成果
CIOやIT部門責任者にとって、MVC計画とABRを組み合わせることは、事後対応から計画主導型への転換を意味します。以前はプレッシャーの中、不完全な情報と明確な優先順位の枠組みがない状態で下されていた復旧の意思決定は、今や事前に決定され、可視性が確保された状態で、その時が来れば自動的に実行されます。
実際の運用では以下のようになります。午前3時にランサムウェア攻撃が発生したと想像してみてください。オンコールの管理者は、トリアージを開始する必要はありません。彼らは復旧を開始します。経営陣がレビューし、承認したMVC計画が、すでに実行されています。数時間以内に、CEOはメールにアクセスできるようになります。財務部門は、重要なファイルにアクセスできます。法務部門は、迅速な対応に必要なものを手にしています。組織は完全には復旧していませんが、機能しており、連絡を取り合えています。そしてリーダーシップ層は、何が起きたのかを把握しようと右往左往するのではなく、状況の主導権を握れています。
復旧が実行される際、リーダーシップ層はあらゆる決定、つまりは「何を、誰のために、どのような順番で復旧し、どれだけの時間がかかったのか」を説明することができます。その説明責任、つまりは取締役会、規制当局または顧客に対してあらゆる選択を説明できる能力こそが、計画的なインシデントと危機を分かつものです。
Microsoft 365は、組織の神経系です。それは、コミュニケーション、コラボレーション、そして業務運用が行われる場所です。M365の復旧にも、MVCの計画策定時と同じレベルで、事業継続に必要な要件を反映させる必要があります。それこそが、実践におけるサイバーレジリエンスの姿です。MVCとABRがそれを可能にします。
実際の動作を確認してみませんか？
Autonomous Business Recovery for Microsoft 365の一般提供を開始しました。
検証済みのM365復旧シーケンスが確立されていない場合は、インシデントが発生する前に、従来のバックアップと自律型の復旧との間に生じるギャップを解消しておく価値があります。
実際の動作を見る：ウェビナー「Introducing M365 Autonomous Business Recovery（M365自律型ビジネス復旧のご紹介）」をご覧ください。本ウェビナーでは、MVCからABRへの引き継ぎを含む、復旧シーケンス全体を実演しながら解説します。
戦略を評価しましょう：Rubrikのアカウントチームに連絡するか、パーソナライズされたデモをリクエストして、現在のレジリエンス対策の準備状況を評価してください。
テクニカルアーキテクチャをお探しのエンジニアリングチームはいらっしゃいますか？ Entra IDグループ構成、アクセスログ分析、APIクォータ管理を網羅した、「M365 Autonomous Business RecoveryによるAPIボトルネックの解決」ステップバイステップガイドをチームに共有してください。
本ブログで言及している未公開のサービスや機能は現時点では利用できません。公開時期等はRubrikの単独の裁量により決定され、予定どおりに一般公開されない可能性や公開が中止される場合もあります。ここで言及されるいかなるサービスや機能もRubrikが提供を約束するものではなく、その責任や義務を意味せず、いかなる契約にも含まれません。現在一般公開されているサービスや機能に基づいて、購入の意思決定を行うようにしてください。