Microsoft 365でデータ消失インシデントが発生した際、多くの組織が同じ厳しい現実に直面します。それは、「バックアップはあるが、計画がない」ということです。 データは保持されているかもしれませんが、業務再開への道筋は確保されていないのです。
ITリーダーにとって、真のリスクはこのギャップにあります。
本稿は、Rubrikがどのようにそのギャップを埋めるかについて解説する全2回シリーズの第1回です。Rubrikは、組織が平時に行うべき「何を、誰のために、どの順序で復旧すべきか」を定義するための事前の取り組みを含め、お客様の最小限の事業継続機能（MVB）の確立を支援します。
最小限の事業継続機能（MVB）：「一括復元」が抱える問題の解決策
従来のM365の復旧がなぜ失敗するのかについては、これまで説明してきたとおりです。組織がすべてのメールボックス、ファイル、アーカイブを完全に復元しようとすると、最終的にMicrosoftのAPIレート制限に達し、重要度の低いコンテンツの復旧に数週間を費やすことになります。では、どうすればよいのでしょうか？ よりスマートな復旧を実現するための計画を構築するには？ その取り組みはインシデントが発生する前に行う必要があり、まずは「最小限の事業継続機能（MVB）」を特定することから始まります。
最小限の事業継続機能（MVB）とは、M365の障害発生時に、組織が事業を継続するために何が必要かを、インシデント発生前にあらかじめ定義しておく復旧フレームワークのことです。MVBでは、すべてのユーザーやファイルを平等に扱うのではなく、組織にとって最も重要なユーザーとその業務に必要なデータを特定し、それらを中心に、検証済みの実行可能な復旧計画を策定します。
検証済みMVBプレイブックの5つのステージ
MVBのプレイブックは、次の5つのステージで構成されています。
ステージ | 概要 | 影響 |
1. 定義 | Exchange、OneDrive、SharePoint、Teamsにおける重要なユーザーをマッピングします。 | IT復旧の優先順位を、実際の事業継続ニーズと整合させます。 |
2. 発見 | RubrikがIDと資産をマッピングし、リアルタイムの復旧時間ベンチマークを生成します。 | 想定を事実に基づくデータとベースラインとなるRTOに置き換えます。 |
3. パーソナライズ | 自然言語によるAIコマンドを使用して範囲を絞り込みます。 | 価値の低いデータを除外することで、Microsoft APIのスロットリングを回避します。 |
4. 最適化 | RubrikのAIエージェントが、利用傾向に基づいた計画の調整案を提示します。 | 変化するユーザーの行動に合わせて、計画が動的に調整されるようにします。 |
5. 確定 | 検証済みのリカバリプレイブックを常設し、確実に利用できる状態にします。 | 危機が発生する前に、確実かつボタン操作だけで実行できる復旧体制を実現します。 |
ステージ1 - 重要なユーザーとM365アプリケーションの定義：MVBは、「事業継続において最も重要なユーザーは誰か？」、「彼らの業務に不可欠なM365アプリケーションは何か？」という、事業継続の観点から慎重に検討すべき2つの問いから始まります。これは単なる技術的な作業ではありません。この問いに答えるには通常、経営層、法務部門、財務部門および主要な顧客対応部門の意見を取り入れる必要があります（ただし、組織によって異なります）。管理者はそれらのユーザーを特定し、Exchange、OneDrive、SharePointおよびTeamsにマッピングします。このポリシーが、その後に続くすべての作業の基盤となります。
ステージ2 - Rubrikによる環境の検出とベースラインプランの構築：MVBポリシーが定義されると、Rubrik Security Cloudがお客様の実際の本番環境で稼働を開始します。古いドキュメントや手動での資産タグ付けに依存するのではなく、RubrikはMicrosoft Entra IDや、ADグループとロールを活用し、お客様のネイティブインフラストラクチャと直接統合します。また、ログにアクセスしてユーザーIDを検出し、それらに紐付く特定のM365アプリケーションや資産を自動的にマッピングします。
その結果、IDとデータの関係を結びつける動的なリレーションシップマップが作成されます。システムは、それぞれの重要なユーザーを、それに対応するメールボックス、OneDriveファイル、SharePointサイト、Teamsチャネルと紐付けます。最も重要な点として、Rubrikはこのメタデータを集約し、推定復旧時間のベースラインを即座に提示します。
ステージ3 - AIと自然言語による計画のパーソナライズ：ベースライン計画はRubrikが検出した内容を反映するものですが、多くの場合、組織には計画に反映すべき追加のコンテキストが存在します。RubrikのAIおよび自然言語機能により、管理者は複雑なメニューを操作したりスクリプトを記述したりすることなく、対話形式で計画を微調整できます。
例えば、管理者は以下のようなコマンドを入力することができます。
「Exchangeの復旧から全社的な一斉配信メールを除外する」。なぜなら、全社的な告知を大規模に復旧することは、価値の低いコンテンツにAPI容量を浪費することになるからです。
「OneDriveの復旧を、「Confidential（機密）」のラベルが付いたファイルに限定する。」
「3年以上前のアーカイブフォルダーをSharePointの対象範囲から削除する。」
これらの命令は即座に処理されます。それぞれの命令が適用されるたびに、システムはリアルタイムで計画を再計算し、資産の対象範囲と推定復旧時間を更新します。このように復旧対象範囲を絞り込むことで、1.5時間かかると予測されていた復元を55分に短縮できます。これは、業務が停止している状況下では大きな違いとなります。
ステージ4 - RubrikのAIエージェントによるプロアクティブな調整の推奨：MVB計画は、管理者が定義した内容にとどまりません。RubrikのAIエージェントは、お客様の環境におけるリアルタイムのシグナルと過去の使用パターンに基づいて、推奨事項を提示します。例えば、特定のSharePointサイトで重要なユーザーによるアクティビティが急増しているため計画に含めるべきであると指摘したり、頻繁にアクセスされないアーカイブデータの優先度を下げることで、より優先度の高いコンテンツのためにAPI容量を確保すべきであると提案したりします。最終決定権は常に管理者が持ち、すべての推奨事項は承認または拒否できます。このエージェントは、組織に代わって独断で決定を下すことはせず、時間の経過とともに計画の精度を向上させます。
ステージ 5 - 復旧計画の確認と確定：パーソナライズ設定とエージェントからの推奨事項が組み込まれた状態で、管理者が計画全体を確認します。意思決定を行うたびに推定復旧時間がリアルタイムで更新されるため、最終的なビューには、復旧対象（何が）、対象ユーザー（誰の）、対象アプリケーション（どのアプリケーション）、および所要時間が正確に反映されます。
この計画は、常時使用可能なリカバリプレイブックとして保存し、インシデント発生時に即座に実行できるようにしておくことも、復旧がすでに進行中であれば即時に実行することも可能です。この計画の目標は、完全な復元ではありません。その目的は、最も重要な機能がオンラインに復帰し、意思決定が可能になり、必要な業務を遂行できる状態、すなわち最小限の事業継続機能（MVB）を復旧させることです。完全な復旧はその後に続きますが、危機を終息させるのはMVBです。
強固なMVB計画がその基盤となります。 第2回では、自律型ビジネス復旧（ABR）が、ここでチームが策定した計画を活用し、リアルタイムで優先順位を判断する必要なく、数週間ではなく数時間で最小限の事業継続機能（MVB）を備えた状態を実現する方法について解説します。MVB計画が貴社の現在の復旧戦略にどのように適合するかを評価したい場合は、Rubrikアカウントチームまでお問い合わせいただくか、デモをリクエストしてください。
免責条項
本書で言及している未公開のサービスや機能は現時点では利用できません。公開時期等はRubrikの単独の裁量により決定され、予定どおりに一般公開されない、または公開が中止される場合もあります。ここで言及されるいかなるサービスや機能もRubrikが提供を約束するものではなく、その責任や義務を意味せず、いかなる契約にも含まれません。現在一般公開されているサービスや機能に基づいて、購入の意思決定を行うようにしてください。