それは何か？　セルフサービス方式で提供される場合、DRaaSプロバイダーは、災害時に必要なツールやサポート文書とともに、対象となるインフラを用意します。セルフサービスとは、初期設定と継続的な保守・監視をお客様の組織で行うことを意味します。つまり、DRaaSプロバイダーは、インフラとツールが正しく動作することを保証しますが、それだけで、ソリューション全体に対する全責任を負うわけではありません。DRaaSプロバイダーは、インフラとツールが正しく動作することを保証しますが、ソリューション全体に対する完全な責任は負いません。

このような場合に最適です。このモデルは、DR戦略を実行するためのスキルと能力を備えた大規模なITチームをすでに持っている組織に適しています。このような企業では、セルフサービス型DRaaSが、地域分散戦略、消費型モデルへの移行、OPEX支出への移行に役立ちます。

災害復旧は、ITインフラストラクチャを復活させ、サイバー攻撃、ハードウェア障害、偶発的なデータ削除などの自然または人為的な災害の後に重要なビジネス機能を再開することを総称して意図されている手順、ツール、ポリシー、およびリソースのセットです。

これは、サービスの中断後にすべての重要なプロセスを復旧させようとするものであり、事業継続のサブセットと考えることができます。

DRaaS（Disaster Recovery as a Service）といえば、かつては大きなトラックの荷台にデータセンターを運んできて、そこにデータをアップロードするものでした。しかし、この面倒で時間のかかるプロセスは、かつてはディザスターリカバリーサービスのゴールドスタンダードでした。

クラウドコンピューティングの台頭により、DRaaSは新たな進化を遂げました。クラウド・ディーザスター・リカバリー・サービスの騒音は、オフィスの外でアイドリングしている大きなトラックの代わりに、利用可能なサービスの多さへの混乱から生じているのです。

DRaaSプロバイダーは、明確に定義されたカテゴリーではなく、さまざまな領域に分類される。この記事では、この領域におけるDRaaSの3つの主要な選択肢を探っていきます。しかし、ディザスターリカバリーサービスのキーワードは柔軟性である。多くのDRaaSプロバイダーが存在する中で、あなたの組織に最適なDRaaSは、次に示す選択肢の外にあるかもしれないです。

災害復旧計画を作成するためには、まず、ダウンタイムが発生した場合にビジネスが引き受ける時間目標と許容可能なデータ損失を見積もる必要があります。これらの目的は、回復時間と回復ポイントの目標と呼ばれています。

RTOは、完全に、回復時間目標を指します。この測定量は事業継続のための災害の後で、ユーザのITの下部組織およびサービスを元通りにするべきである時間の量を確立します。

次に、RPO（Recovery Point Objective）は、組織が災害時に失われたデータの最大許容量を定義します。さらに、最終的なデータバックアップインスタンスから災害発生までの最大許容時間についての洞察を提供します。つまり、適切なバックアップスケジュールと頻度を決定するために使用することができます。

バックアップとは、データのコピーを作成し、プライマリおよびセカンダリの場所に保存するプロセスです。あなたは、ローカルドライブ、NASデバイス、オフサイトのデータセンター、クラウドストレージ、および他の手段でファイルをバックアップすることができます。これはデータ損失を経験することが起こればあなたのデータを元通りにすることを可能にします。

一方、ディザスターリカバリーは、データとITリソースを問題から保護することを目的とした、より総合的なプロセスであり、大規模な中断後の基幹業務システムの迅速な再構築を促進します。

したがって、バックアップは災害復旧の1つのサブコンポーネントにすぎないと結論づけることができます。

災害復旧を管理するには、堅牢な災害復旧計画とそれに対応する事業継続計画の起草、実装、およびテストが必要です。

ビジネスインパクト分析を行う際には、理想的なリカバリーインフラ（オンプレミスかクラウドか）と、災害復旧アプローチ（マルチサイト、ウォームスタンバイ、パイロットライト、またはバックアップとリカバリーのいずれか）を考慮する必要があります。

ITの災害復旧の計画は効果的にサイバー攻撃、停電および自然な災害のような自然な、人為的な災害によって引き起こされるサービス中断にいかに対応するかの詳しい指導を提供する構造化された文書です。

計画自体は、すべての中核となるビジネスプロセスに加えて、その過程で発生する可能性のある災害を考慮しています。その上で、各災害の影響を最小限に抑えるための戦略と、重要な業務を迅速かつシームレスに復旧するための利用可能な二次リソースの活用方法を提示します。

災害復旧計画はサービス中断に迅速かつ効果的に対応するのを助けるように努めます。それは各潜在的な災害の効果を最小にすることに焦点を合わせ、基幹業務を元通りに戻します。

IT災害復旧計画の主要な要素には、以下のものが含まれます。

●災害対応のためのすべての責任の割り当て
●災害対応の実施フレームワーク
●バックアップから新しいシステムにデータを復元するプロセス
●処理を反転させて通常の動作を再開する手順を説明

災害復旧計画を作成するためには、以下のことを行う必要があります。

●ビジネスリーダーと災害復旧計画の必要性について話し合う
●復旧が必要なビジネスプロセスとデータを重要度別にグループ化
●想定される災害事例を特定する
●災害復旧の目標を定義する
●目標に応じて回復できるツールや方法を定義する
●災害復旧計画とワークフローの実施
●エンドユーザーへの教育

事業継続の計画が破壊的なでき事の後で動いている事業活動を保つために必要なすべてのプロシージャおよび議定書を定義するのに使用されています。従って、一言で言えば、事業継続の計画は「いかに私達は災害が起これば私達のビジネスプロセスを維持していくか」に答えるものです。

災害復旧計画は、一方では、災害に続く重要なITインフラストラクチャおよびサービスを復元するために必要なステップおよびリソースを具体的に扱うものです。それは「いかに私達は災害の後で再開してもいいか」の質問に答えることを意味します。

しかし、災害復旧は事業継続の重要な要素の一つです。

災害復旧計画は、ウォークスルー・テスト、卓上テスト、および技術テストによって評価することができます。

ウォークスルー・テストは基本的に災害復旧計画のステップバイステップのレビューであり、卓上テストは各チームメンバーがどのように答えるか決定するために「what-if」のシナリオを起動させます。その後、並行テストやライブ/フル中断テストのような技術テストで補足することができます。

1. S3 Object Lockに対応したサイバー脅威対策。これにより、不変のバックアップが可能になり、ランサムウェアやハッカーだけでなく、誤って削除されたり、悪意のあるインサイダーからも防弾性のある保護を提供します。どんなオンプレミスのストレージでも、十分な大きさのハンマーを持った（またはガソリンの入ったキャニスターを持った）動揺した従業員が、最も洗練されたアクセス制御やWORM技術でさえも簡単に回避することができるため、単純にそうはいきません。

2. オフサイトバックアップ。クラウド・オブジェクト・ストレージは定義上オフサイトに位置しているため、これは「無料」で含まれており、3-2-1 バックアップ・ルールの「1」を達成することは完全に容易である。これは非常に重要なコスト要因であり、オンプレミスのオブジェクトストレージを使用する場合、オフサイトバックアップを行う方法を見つける必要があるからです。そして、どのようにアプローチするにしても、そのためだけにいくつかの余分な$$を費やす必要があります。

3. パフォーマンスとスケーラビリティ。成熟したクラウドオブジェクトストレージは、一般的に実行し、はるかに優れたスケーラビリティを持っています。実際、Amazon S3は来月で15歳になりますが、これはVeeamと同じくらい古いです。しかし、言うまでもなく、この弾丸は、最近キノコのように飛び出している新しいベンダーには適用されないかもしれません。あなたがコミットする前にデューデリジェンスを行い、広範囲にテストを行ったとしても、彼らは常に後で登録をオーバーする可能性があります…心に留めておいてください – いつものように、あなたはあなたが得たものを支払します!

1. コストが安くなる。ほとんどの場合、長期的にはオンプレミスのオブジェクトストレージの方が安くなります。ストレージの価格だけでなく、電気代、冷却費、その他のデータセンターのコストも考慮する必要があります。また、あまり成熟していないオブジェクト・ストレージ・ソリューションを子守するための人的資源コストも考慮に入れてください。

2. データの主権。もしあなたのデータの一部またはすべてをオンプレミスで保管することを必要とする州、業界、企業のポリシーや規制に縛られている場合、選択肢はありません！もしあなたがこれらのソリューションを利用することを決めたならば、現在は豊富にあります。

1. 成熟度の低いオブジェクトストレージソリューションの信頼性とパフォーマンスの問題に対処しなければならないため、TCOが高くなる可能性があります。過去2年間、ほとんどのオブジェクトストレージベンダーが次々とHotfixを発行しているのを見てきましたが、誰がこれらの問題を発見していると思いますか？そう、あなたの仲間です。

2. バケットで100TB（場合によっては数十TB）に近づくにつれ、スケーラビリティの問題が発生する可能性があります。これは、残念ながら、多くのオンプレミスのオブジェクトストレージは、通常のファイルシステムの上に「ボルトオン」のソリューションであり、何十億ものオブジェクトに対応できるように最初から設計されているのとは対照的だからです。そのため、Veeamがバニラファイルシステムを使用するのと比較して、パフォーマンスや信頼性の面で良いことはありません。

それは何か？　パーシャルマネージドDRaaSは、次のステップとなる責任共有モデルです。DRaaSプロバイダーは、初期設定と継続的なメンテナンスと監視を行い、お客様はサービスにアクセスし、一部の機能にアクセスすることができます。なぜ多くの企業がこのモデルを好むのでしょうか？それは、DR戦略に対してよりカスタマイズされたアプローチと安心感を与えるからです。

最適な方法：　 サービスプロバイダーは、大規模なITチームやディザスターリカバリーを成功させるための社内スキルが不足している組織にこのモデルを推奨することが多いようです。また、ITチームを他のビジネスプロフェッショナルや目標に集中させたいと考えている企業も、このモデルを利用するとよいでしょう。なお、このモデルにおけるツールは通常DRaaSプロバイダーによって選択されますが、組織は復旧目標に応じて必要なツールを選択することができます。

それは何か？　セルフサービスとは反対に、DRaaSプロバイダがサービスの全結果に責任を持つのがフルマネージドDRaaSソリューションである。このモデルでは、リカバリポイント目標（RPO）やリカバリ時間目標（RTO）など、財務的なSLAがリカバリの指標となる場合があります。このモデルでは、DRaaSプロバイダーは、設計、実装、保守監視、テスト、起動のすべてを行います。

以下のような場合に最適です。このモデルは、ITリソースやディザスターリカバリーのスキルが限られている、または全くない組織に最適です。また、ディザスターリカバリーの拠点となる2次、3次拠点がない場合や、ディザスターリカバリーのSLA保証の安全性を求める場合にも最適なモデルです。

この2つの用語は大まかに言うと以下のようなものです。

バックアップとは、データのコピーを作成し、オリジナルの紛失や破損に備えてオフサイトに保管することです。

レプリケーションとは、データをコピーし、データセンター、コロケーション施設、パブリッククラウド、プライベートクラウドなど、企業のサイト間でデータを移動させることです。

バックアップはデータ管理に欠かせないものです。バックアップを作成することで、データの損失、破損、マルウェアの攻撃からデータを保護することができます。バックアップコピーを作成することで、紛失や破損、マルウェアの攻撃からデータを守ることができます。

リカバリは、バックアップにアクセスし、破損または紛失したファイルを復元するプロセスです。リカバリーを効果的に行うには、バックアップ・コピーに簡単にアクセスでき、最新の状態である必要があります。最高の状態で、リカバリはシームレスかつ迅速に行われます。

バックアップがなければ、デジタルデータは1台のハードディスクやクラウドなど、1つの場所にしか存在しないため、データは非常に脆弱なままです。スケッチブックを水たまりに落としたり、間違った書類をシュレッダーにかけてしまうように、たった一度の誤操作、マルウェアの攻撃、機器の故障がすべてを消し去る可能性があるのです。また、特にソフトウェアのアップグレードやデータ移行時には、データが破損する危険性があります。

データのコピーを複数持つことは重要ですが、ビジネスの観点からは、障害からできるだけ早く回復する能力の方がより重要です。アプリケーション全体、アプリケーションのセット、サイト全体、あるいは単一のファイルなど、どのような場合でも迅速なリカバリが不可欠です。

必要な復旧の種類によって、復旧時点目標（RPO）と復旧時間目標（RTO）の指標にかかる性能要件が決まります。RPOは、組織が許容できるデータ損失に影響されますが、RTOは、特にデータとアプリケーションを特定の時点まで一貫して復旧する場合、復旧プロセスがどれだけ自動化されているか（手動ではなく）、復旧計画がどれだけ効果的に実施されテストされているかに依存します。

サイバー攻撃の数は絶えず増加しており、その頻度はますます高くなり、ハッカーは企業の機密データから利益を得るために、より多くの方法を考案しています。ガートナーの専門家は、2025年までに最大75%のIT企業が1つ以上のランサムウェア攻撃の標的になると予測しています。侵入者は、身代金を支払わないとデータを復元できないようにすることを好むため、こうした攻撃はバックアップに影響する可能性が高い。

つまり、データ保護の今までのゴールドスタンダードでさえ、実際にデータを保護するには十分でない可能性があるということです。データを安全に保つための新しい方法を導入する必要があります。そのような方法の一つが、3-2-1-1-0バックアップルールです。

3-2-1-1-0バックアップ・ルールとは？

3-2-1-1-0バックアップ・ルールは、5つの条件を満たすことを要求していることです。

●本番用コピーを含め、少なくとも3つのデータコピーを用意すること。
●テープとクラウドストレージのように、少なくとも2つの異なるストレージメディアを使用すること。
●少なくとも1つは、マシンが物理的に破損した場合に備えて、オフサイトで保管すること。
●少なくとも1つのコピーはオフラインで保管するか、クラウドを使用する場合はイミュータブル（不変）であること（不変とは、このコピーがいかなる状況下でも変更されないことを意味します）。
●バックアップはエラーゼロで完了すること。

この戦略では、データの復元性が最も高く、ランサムウェアからの保護が最も優れています。バックアップのエラーがゼロであれば、データを復元して作業を継続することができます。1つのコピーがオフラインであれば、インターネット経由でマルウェアが到達することはありません。1つのコピーがオフサイトにあれば、オフィスで災害が発生した場合でも、そのコピーを使用することができます。2つの異なるストレージと3つのコピーがあれば、少なくとも1つはどこかで利用可能であり、仕事を再開するのに役立つことが保証される。3-2-1-1-0のルールは、すべての卵を一つのカゴに入れておかないことで、どんな場合でもオムレツを作ることができるようにすることです。

「3-2-1」と「3-2-1-1-0」のバックアップルールの違い

つい最近まで、3-2-1ルールが業界標準であり、データを大切にする企業はこのルールに従っていて、自分たちは大丈夫だと思っていた。しかし、ランサムウェアの攻撃頻度の増加やバックアップ重視の傾向を考慮すると、バックアップにはさらなる保護が必要です。

「3-2-1」と「3-2-1-1-0」のバックアップルールの違いは、前者は本番データの保存に役立ち、後者は競合他社が持つすべての機能を提供し、さらにバックアップ保存のメカニズムを追加している点です。3-2-1-1-0ルールは、マルウェア、物理的な損傷、人的ミスなど、主要なデータセットに何が起こっても、データを取り戻す可能性を大幅に向上させるものである。これは、利用可能な最高レベルの保護機能です。

全体的な複雑さ

第一の大きな課題は、今日の典型的な企業環境の複雑さです。最近では、データやワークロードは、さまざまなアプリケーション、コンピューター、サーバー、プラットフォームの間に分散しています。

競争力を維持するためにソフトウェアやハードウェアを見直し、刻々と変化する現実に対応させる必要があるだけでなく、最近終了したローカル環境から主にクラウド環境へのシフトのような大きなプラットフォームの変化にも直面しています。そのため、詳細かつ綿密なディザスターリカバリープランが必要となってきます。さらに、このようなシフトと複雑で変化し続ける技術環境は、計画を見直し、定期的に更新する必要があることを意味します。

増加するコスト
ディザスターリカバリーのコスト要因には3つあります。

●データのコスト まず第一に、データのコストがかかります。顧客の記録、請求書、プロジェクト、ワークフロー、データベースなど、これらすべてが失われる可能性があり、会社にとっては倒産に等しい事態を招きかねません。

●ダウンタイムのコスト：現代のビジネスは、電子リソースに大きく依存しています。そのため、これらのリソースがダウンすると、ビジネスの一部または全体が機能しなくなります。つまり、ダウンタイムが発生するたびに損失が発生することになります。

●追加のリソースと労働力のコスト。最後に、どんな複雑なインフラでも、優れた災害復旧計画を作ろうとすれば、時間とお金の両方を費やすことになります。そして、ここに費やす費用の選択肢は無限にありますが、予算はそうではありません。優れたディザスターリカバリーソリューションを開発、導入、維持するためには、より多くのハードウェア、ソフトウェア、労働力が必要になります。

最初の2つのコストの結果、通常、復旧時間と復旧ポイントの目標をかなり厳しく設定することになります。これらは、ワークロードをどれくらいの速度で復旧させるべきか、どれくらいのデータ損失が許容されるかを示す重要な指標となります。しかし、人件費とリソースにかかるコストもかなり高いので、希望と能力のバランスを取る必要があります。

不適切なディザスターリカバリープロセス

災害復旧ソリューションの設計が不十分であれば、存在しないのと同じことです。DRのワークフローで見落としがないように、以下の4つのステージに注意を向ける必要があります。

●プランニング：復旧時間と復旧ポイントの目標を設定し、ソリューションのアーキテクチャを考え、ハードウェアとソフトウェアのベンダーを選択する必要があります。
●レビュー：この段階では、技術者やCレベルとともに計画を見直し、忘れ物がないか、予算が確保されているかを確認します。
●実施：プランニングとレビューの段階で準備が整ったら、いよいよ実際にソリューションを導入します。
●定期的なテストとレビュー：新しいディザスタリカバリ環境の定期的なテストを予定し、さまざまなイベントであらゆるワークロードやデータを復旧する準備が実際にできているかどうかを確認します。テストが完了したら、計画を見直し、必要に応じて更新してください。

不十分なバックアップ保護

適切なプロセスを導入しているかもしれませんが、使用しているツールにも気を配る必要があります。すべての種類のワークロードが適切にバックアップされているかどうかを定義してください。例えば、クラウド仮想マシンを使用している場合、アーキテクチャを正常に復元できるようにするためには、特定のツールセットと異なるアプローチが必要になります。

新しいコールトゥアクション
次に、バックアップを行う場合、すべてのデータを1つのストレージに保存するのは危険とされています。

このため、最も一般的なバックアップの保存方法である「3-2-1バックアップルール」では、どの時点でも各ファイルのバージョンを最低3つ持ち、そのうち2つはバックアップ、1つはオフサイトに保存することとしています。

最後に、現代のデータセキュリティの脅威であるランサムウェアの攻撃が成功する確率が高いことを念頭に置いておく必要があります。ランサムウェアは、ファイルとバックアップの両方を暗号化することを目的としていることがあります。したがって、バックアップの1つが暗号化されても復旧できるように、3-2-1ルールを守る必要があります。

また、いわゆるエアギャップバックアップの手法を導入することもできます。これは、インフラから完全に切り離されたデータのコピーを持つことです。これは、ランサムウェアから身を守る究極の方法ですが、コストがかかります。

DR=Disaster Recovery

ランサムウェアには様々な種類がありますが、ほとんどのランサムウェアは主に2つのカテゴリーに分類され、いくつかの類似した特徴を持っています。サイバー犯罪者は、通常、標的を絞った電子メール（スピアフィッシング）や、悪意のあるコードに感染したウェブサイトにユーザーを誘導することで、ユーザーのコンピュータを感染させます。

その際、ポップアップで身代金を要求してファイルへのアクセスを遮断したり（ロックスクリーン／スクリーンロッカー型ランサムウェア）、データを暗号化して読み取りやアクセスができないようにする（暗号化型ランサムウェア）などの方法をとります。いずれにしても、身代金を支払ってデータへのアクセスを回復させることが目的です。

一般的に、身代金はビットコインで支払われ、支払われると復号化キーが成功する傾向にあると言われています。しかし、犯罪者の誠実さやフォローの仕方によっては、データを届けないことも知られています。ランサムウェアのコストは2020年に200億ドル、組織の規模に関わらず平均支払い額は171％増加したと言われています。

中小企業も同様にリスクがあります。評判の回復、生産性、サービスの中断、さらに身代金など、ランサムウェアから回復するためのコストは、平均で140万ドルでした。

復旧ポイントと時間目標 をランサムウェアに対応したディザスターリカバリープランを考える際には、バックアップソリューションによって復元する必要のある復旧ポイントだけでなく、組織が正常な状態に戻るまでの復旧時間や、一般的な復旧能力についても考える必要があります。それだけでなく、組織が正常な状態に戻るまでにかかる回復時間や、一般的な回復能力についても考慮する必要があります。

プランのテストとセキュリティアップデートの実施

ディザスタリカバリプランを自社で運用している場合は、パッチやセキュリティのアップデートを怠らないようにしてください。2017年に発生したWannaCryの攻撃も、パッチの適用を怠ったことが原因と考えられます。最新のセキュリティパッチを導入していないなど、小さなことが原因で、システムがサイバー攻撃に対して脆弱な状態になっている可能性があります。このような事態を防ぐために、定期的にチェックしたり、自動パッチをオンにしたりしましょう。

防止策の追加 ランサムウェア対策の大部分は、ランサムウェアが組織のデバイスに感染し始める前に食い止めることです。以下のようなセキュリティコントロールを追加することで、悪意のあるコンテンツがユーザーベースに届く前にある程度防ぐことができます。

●エンドポイント検出と応答（EDR）
●URLフィルタリング
●Webコンテンツフィルタリング
●不審なメールを評価するためのサンドボックス環境
●スパムフィルタ

従業員の教育

不審なリンクを頻繁にクリックしてしまう従業員がいることを心配しているのであれば、彼らを教育し、テストすることも重要です。ランサムウェアがどのようなものかという情報を共有し、従業員をテストすることも必要です。これには、偽装した悪意のあるメールを使って、組織を最も危険にさらす可能性のある人物を確認することができます。

データレプリケーションとは、データをコピーして別のサイトに保存することです。アレイベースレプリケーションは、物理または仮想ストレージアレイレベルで実行されるデータレプリケーションの一種で、ハイパーバイザーのスナップショットには依存しません。アレイベースレプリケーション製品は、特定のストレージベンダーによって提供されます。単一ベンダーのソリューションであるため、これらの製品はその特定のストレージソリューションとのみ互換性があります。

Zertoとアレイベースレプリケーションの違い:
Zertoのソフトウェアベースのプラットフォームは、エンタープライズクラスのレプリケーションソリューションを提供し、柔軟性が高く、仮想環境を最大限に活用することが可能です。Zertoのソリューションはベンダーに依存しないため、特定のベンダーに縛られることはありません。また、アレイベースではないため、レプリケーションプロセスがアレイリソースを消費することはありません。

Zertoは仮想インフラストラクチャ内に直接インストールされるため（個々のマシン上ではなく）、ハイパーバイザと統合してデータのあらゆる変更をレプリケートします。毎回、データはキャプチャされ、クローン化され、リカバリサイトへ送信されます。この革新的なハイパーバイザーベースのレプリケーション・ソリューションは、他のどのレプリケーション手法よりもはるかに効率的で正確、かつ迅速な対応が可能です。さらに、Zertoは継続的にデータを保護するため、ビジネスに支障をきたすようなデータ損失の心配はありません。

データレプリケーションとは、データをコピーして別のサイトに保存するプロセスです。アプライアンスベースのレプリケーションは、外部の物理アプライアンスを使用し、そのアプライアンス上で直接レプリケーションコードを実行します。このタイプのレプリケーションはハードウェアベースで、1つのプラットフォームに特化しています。アプライアンスベースのレプリケーションは、両方の拠点にハードウェアを追加する必要があるため、クラウド戦略には適していない場合が多いです。

アプライアンスベースのレプリケーションはどのように機能するのか？
アプライアンス・ベースのレプリケーションは、データのローカルコピーまたはバックアップを取り、ローカルアプライアンスに保存します。その後、定期的にタスクを実行して、データをセカンダリアプライアンス（多くの場合、別のサイトにある）にコピーします。このプロセスでは、レプリケーションジョブ間のギャップが大きくなり、データセットに大きなギャップが生じるため、RPOが希望より長くなる可能性があります。

仮想環境の保護に関しては、アプライアンスベースとアレイベースの両方のオプションに、同様のデメリットがあります。

●アプライアンスベースのレプリケーションでは、仮想環境ではなく物理環境がコピーされるため、設定の変更に気づかない可能性があります。
●アプライアンスベースのレプリケーションは、仮想環境ではなく物理環境をコピーするため、構成の変化に対応できず、事業継続計画がすぐに時代遅れになる可能性があります。
●アプライアンス・ベースのレプリケーションは粒度が粗く、仮想化の要件や利点と相反します。
●アプライアンス・ベースのレプリケーションでは、物理管理コンソールと仮想化管理コンソールの2つの管理ポイントが必要であり、常に調整しなければならないため、管理が非常に煩雑になります。

仮想環境を意識したZertoプラットフォームは、仮想環境向けに構築されたエンタープライズクラスのレプリケーションソリューションを提供します。Zertoは、革新的なエンタープライズクラスの仮想レプリケーションと、データセンタとクラウドの両方に対応する事業継続およびディザスタリカバリ機能を提供する最初のソリューションです。

企業・組織は、破壊的な事象に対応するだけでなく、絶え間ない変化にも業務を適応させなければならないことが多くなっています。ビジネスレジリエンスとは、組織がストレスを吸収し、重要な機能を回復し、変化する状況下で成功するための準備を整えていることを意味します。

ビジネスレジリエンス、事業継続、ITレジリエンス
ビジネスレジリエンスには、障害が発生した場合に事業を再開するためのガイドとなる事業継続計画を持つことが含まれます。しかし、組織の運用性を維持するためのプロセスに重点を置く事業継続に比べ、ビジネスレジリエンスはより戦略的で全体的なアプローチとなります。ITレジリエンスとは、データを保護し、計画外の障害発生時にシステムやデータを可能な限り迅速に復旧させることです。ITレジリエンスとビジネスレジリエンスは密接に関係しています。

フェイルバックとは、災害や障害によって復旧したシステムを元の場所に戻すこと、または主要な生産インフラストラクチャに戻すことです。ディザスターリカバリーに不可欠な要素であり、オンプレミスシステム間、オンプレミスシステムとクラウド間、クラウドとクラウド間、またはこれらの組み合わせでフェイルバックを設定することができます。

フェイルバックはフェイルオーバーと関連しており、メインシステムをセカンダリロケーションやインフラに切り替えることです。フェイルオーバー中は、セカンダリーシステムがお客様のシステムのオンラインと運用を維持し、プライマリーの本番環境で障害が解決されるまでの時間を確保します。障害が解決されると、元のインフラや場所にフェイルバックされます。

フェイルバックはどのように行われるのか？

フェイルバックは必要不可欠なオペレーションですが、見落とされがちです。しかし、ディザスタリカバリおよびデータ保護戦略には欠かせないものです。今日の常時接続社会では、事業継続が必須であると同時に、さまざまな不可避な原因による緊急の中断がこれまで以上に一般的になっています。

●自然災害
●デジタル強盗、ランサムウェア攻撃
●システム障害・停電

フェイルオーバーとは、プライマリサイトや本番サイトで発生した問題の影響を受けないセカンダリサイトやクラウドに、アプリケーションやインフラを復旧させることができるようにすることを指します。フェイルオーバーは事業継続と災害復旧（BCDR）の重要な要素であるため、できるだけシンプルかつ組織的に行うとともに、誤ったフェイルオーバーが発生しないように明確なアクションを設定する必要があります。

フェイルオーバーはどのように機能するのか？

フェイルオーバーは通常、データ、アプリケーションの構成、およびサポートするインフラをセカンダリサイトにリストアすることによって機能します。このプロセスは、通常、この複雑な動作を容易にする専用のソフトウェアまたはハードウェアによって実行されます。マーケットで最も優れたツールは、自動化とオーケストレーションが組み込まれており、復旧作業を簡素化します。これらのツールは、数時間前や数日前のデータではなく、わずか数秒前のデータを復元することも可能です。アプリケーションの一貫性は、フェイルオーバー時のダウンタイムを最小化する上で重要です。これを達成するためには、アプリケーションを理解し、（コンポーネントだけでなく）全体としてリストアできるツールが必要であり、その結果、通常のITオペレーションに迅速に戻ることができます。

ハイパーバイザーは、仮想マシンとその仮想ディスクをホストし、実行するソフトウェアベースのオペレーティング・プラットフォームです。ハイパーバイザーベースのレプリケーションは、ハイパーバイザーソフトウェアと直接統合され、仮想マシンと仮想ディスクを別のハイパーバイザーや他のストレージに複製するソフトウェアです。

ハイパーバイザーは、仮想マシンとその仮想ディスクをホストし、実行するソフトウェアベースのオペレーティング・プラットフォームです。ハイパーバイザーベースのレプリケーションは、ハイパーバイザーソフトウェアと直接統合され、仮想マシンと仮想ディスクを別のハイパーバイザーや他のストレージにレプリケートするソフトウェアである。

ハイパーバイザーベースのレプリケーションはどのように機能するのか？

仮想化は非常に優れた機能と利点を提供しますが、他の技術が進化しない限り、あるいは進化しない限り、組織はそれらを完全に受け入れることはできません。スナップショットやストレージ層バックアップを使用する旧来のレプリケーション技術を使用しながら仮想環境やハイブリッド環境を管理すると、仮想化のメリットを十分に活用することが難しくなり、クラウドへの移行が阻害されます。

Zertoのようなハイパーバイザーベースのレプリケーションは、仮想マシンや仮想ディスクの変更を監視し、アプリケーションのパフォーマンスに影響を与えることなく、継続的にジャーナルベースのレプリケーションを提供することができます。ハイパーバイザーベースのレプリケーションは、ソースとデスティネーションのストレージの種類に完全に依存しないため、すべてのストレージプラットフォームと仮想化によって可能になったすべての機能をネイティブにサポートします。また、既存のインフラストラクチャにシームレスに統合することができます。

事業継続(Business Continuity)とは、24時間365日接続・稼働していることを意味します。組織の可用性と機能性は、ブランドの信頼と従業員のモラルを維持するための基本です。事業継続には、計画外の障害に対するコンティンジェンシー・プランや、計画的なダウンタイムを削減するための投資など、戦略的なプランニングが必要です。事業継続は、オフラインの期間が長ければ、悲惨な結果を招く可能性があるため非常に重要なのです。

事業継続と災害復旧の比較
事業継続は、ディザスターリカバリー（DR）と相互に関連し、BCDRという共通の頭字語を形成しています。この2つの用語は同じ意味で使われることが多いのですが、事業継続は組織全体の運用性を維持することを意味し、災害復旧は障害発生後のITシステムの復旧に重点を置いています。

なぜ事業継続が重要なのか？
デジタル進化の今日、事業継続は、実現が困難であるにもかかわらず、当たり前のように期待されるようになりました。定期的にダウンタイムが発生すれば、従業員も顧客も不満を抱くでしょう。また、さまざまな原因により、計画外の中断がこれまで以上に一般的になっています。

●自然災害
●労働争議
●デジタル強盗、ランサムウェア攻撃
●システム障害・停電

しかし、予期せぬ障害に対する計画を怠ると、組織にとって悲惨なことになりかねません。最悪の場合、企業は永久に閉鎖される可能性さえあります。

事業継続計画(BCP)
事業継続計画とは、「組織が障害発生後に対応、回復、再開し、あらかじめ定義された業務レベルまで回復するための指針となる手順書を文書化したもの」と定義されています。災害復旧は、BCP全体のサブセットです。なぜなら、データがなければ、データセンターに入り込んだどんな障害にも翻弄されてしまうからです。

IT部門がダウンしたシステムを復旧させたら、BCPを実行するチームは、できるだけ早く業務を復旧させる計画を開始しなければならないため、事業継続計画を策定することが重要です。一分一秒を争います。

BIAは、組織の重要で時間的制約のある業務に着目し、自然災害を含むあらゆる中断、機能停止、または災害が発生した場合に何が起こるかを判断するものです。 BIAは、事業継続の要件とリソース依存に重点を置き、ダウンタイムが組織にどのような影響を与えるかを示すことで、特定のビジネス要件を正当化します。

リスクアセスメントとビジネスインパクト分析
事業継続計画の関連ステップであるリスクアセスメントでは、サイバー攻撃、ネットワーク障害、自然災害、サプライヤー障害、ユーティリティ停止など、具体的に起こりうる災害や障害を特定する。リスクアセスメントでは、これらの脆弱性を軽減することに焦点を当てます。

BIAは、リスクアセスメントの段階で明らかになったリスクが、万一発生した場合にビジネスにどのような影響を及ぼすかを予測しようとします。これにより、ビジネスへの影響を軽減し、ビジネスの継続性を確保するために、それぞれのリスクに対してどのような回復策が必要かを判断します。 BIAの結論は、ビジネスをサポートするすべてのタイプのアプリケーションとプロセスに関連するRTOとRPOの要件を推進することになります。

BIAを実施するには？
ビジネスインパクト分析の方法は業界によって異なるため、一概には言えませんが、以下のリストはBIAで評価すべき多くの分野です。

●計画外の混乱時に起こりうる変化
●計画外の混乱がもたらす法的または規制上の影響
●事業継続に必要な全事業部門のインベントリ
●主要な人材とサポートスタッフ
●障害発生後の依存関係
●テスト計画の妥当性確認
●優先順位と作業順序の決定

BIAは、これらの領域に加え、組織内の複数の部門やビジネスユニットを巻き込んで分析を行い、ユーザのニーズに合った復旧戦略の立案を支援します。

従来のバックアップ方法では、仮想マシン(VM)を保護するためにスナップショットを使用していました。バックアップの際、目的のデータのスナップショットが取られ、専用のバックアップ・ストレージに移動されます。大規模な組織では、このストレージは、拡張性とサービスレベル契約要件を満たすために強力なリソースを必要とします。スナップショットでは、システムリソースが枯渇するため、システム管理者は深夜などの使用頻度の低い時間帯にスナップショットのスケジュールを組む必要があり、データギャップは必要不可欠なものです。

スナップショットの仕組み
スナップショットは、特定の時点から仮想マシン（VM）を複製し、災害からの復旧のために複数の復旧ポイントを維持するためによく使用されます。スナップショットは、VMレベルまたはストレージ・エリア・ネットワーク（SAN）レベルで実行できます。

VMレベルのスナップショットはハイパーバイザーで作成され、パフォーマンスに最も大きな影響を及ぼします。VMレベルのスナップショットベースのレプリケーション・システムは通常、パフォーマンスへの影響を軽減するために、毎日または毎週、業務時間外にレプリケーションを行うように構成されています。

ストレージレベルのスナップショットは、VMレベルのスナップショットに比べてパフォーマンスへの影響は少ないものの、ストレージコントローラの処理能力を必要とし、規模が大きくなるとパフォーマンスを低下させる可能性があります。そのため、ストレージレベルのスナップショットを作成する頻度は、パフォーマンスに影響を与える可能性があるため、非常に限られています。

スナップショットのデメリット
上述したように、バックアップと保護に関して、スナップショットには主に2つの欠点があります。それは、パフォーマンスへの影響と、スナップショットが提供するリカバリポイントの粒度です。

●パフォーマンスへの影響: スナップショットの作成と使用は、本番環境のパフォーマンスに悪影響を与えるため、データを保護するためには慎重な計画とスケジューリングが必要です。この悪影響を避けるため、スナップショットは通常、数時間に1回、場合によっては24時間に1回だけ取得されます。数時間おきに取得したリストアポイントは、ダウンタイムが発生した場合、最大で24時間分のデータ損失が発生するなど、大きな影響を及ぼします。

●非粒度（細かさ）: スナップショットはVM単位の一貫性のみをサポートします。つまり、アプリケーションが複数のVMで構成されている場合、スナップショットはすべてのVMで一貫性を維持することができません。このため、ダウンタイムが発生した場合、すべてのVMが異なる一貫性のない時点にリカバリされる可能性があります。

IaaSは、インターネット上で必要なコンピューティングインフラを提供し、多くの種類のワークロードのための標準的なモデルとして急速に普及しました。IaaSには物理リソースと仮想リソースの両方が含まれ、クラウド上でアプリケーションやワークロードを実行するために必要なものが提供されます。

IaaSプロバイダーは、通常世界中にある大規模なデータセンターを管理しており、その中には、その上にあるさまざまな層の仮想化コンピューティングリソースを動かすのに必要な物理マシンが入っています。これらのサービスには、通常、自動スケーリングやロードバランシングなどのサポートサービスが付属しています。IaaSには、ネットワーキングとストレージのサービスも含まれます。

IaaSを選択する理由
IaaSの人気は、その柔軟性と費用対効果に大きく起因しています。IaaSは、組織のニーズや要件に応じて、コンピューティング・インフラストラクチャを簡単にスケールアップまたはスケールダウンできるため、柔軟性があります。また、サードパーティ製のディザスターリカバリーソリューションを柔軟に選択することができます。IaaSの費用対効果は、従量課金制であることと、物理的なコンポーネントやその他のプライベートインフラへの支出を削減できることの両方から生まれます。

パブリッククラウドは、組織がオンデマンドのコンピューティングサービスとインフラストラクチャを管理するためにプロバイダーを雇うコンピューティングモデルである。このプロバイダーは、月額または使用量に応じた料金の購入でコンピューティングリソースを提供し、複数の組織がリソースを共有するのが一般的です。

プライベートクラウドは、コンピューティングリソースが専用で専有されており、基盤となるハードウェア層が他のすべてから分離されていることを意味します。企業は、自社のデータセンター、コロケーション施設、またはプライベートクラウドプロバイダーを利用することができます。

ハイブリッドクラウドモデルは、プライベートクラウドとパブリッククラウドを組み合わせて使用し、クラウドコンピューティングの柔軟な組み合わせを作成します。ハイブリッドクラウドコンピューティングは、インフラと運用を拡張し、組織のニーズに一貫して対応します。

さまざまなクラウドの選択肢は何を提供するのか?

パブリッククラウドサービスプロバイダーは、アクセスのしやすさ、コスト効率、オプションサービスなどを提供します。企業は、データの保存や機密性の低いアプリケーションのために、パブリッククラウドサービスを利用することがよくあります。

プライベートクラウドは、コントロールしやすく、セキュリティも高いが、メンテナンス、アップグレード、ソフトウェアの管理は、通常エンドユーザーが行います。

プライベートクラウドとパブリッククラウドのリソースを組み合わせてハイブリッドクラウドを構築する場合、企業はニーズに合わせてサービスの組み合わせを選択し、運用やコストの変化に応じてアプリケーションやデータを異なるクラウド間で柔軟に移行することが可能になります。

SaaSは、ベンダーが提供する完全なソフトウェアソリューションを、通常は消費ベースで提供します。一般的な例としては、電子メール、カレンダー、オフィスツール（Microsoft Office 365など）などがあります。基本的に、お客様は組織のためにアプリケーションをレンタルし、ユーザはインターネットを介してそのアプリケーションに接続します。

インフラからアプリのデータまで、基盤となる部分はすべてサービス・プロバイダーのデータセンターに収容されます。ベンダーは、アプリケーションのアップタイムには責任を負いますが、アプリケーションでホストされているデータには責任を負いません。データに対する責任は、ユーザが負うことになります。

なぜSaaSを選ぶのか？

SaaSは、ソフトウェアとハードウェアのための最小限の初期費用で、高度なアプリケーションにアクセスする柔軟性を組織に提供します。SaaSでは、ハードウェア、ミドルウェア、ソフトウェアの購入、インストール、更新、保守の必要がないため、ERPやCRMなどの高度なエンタープライズ・アプリケーションも、あらゆる規模の組織で手頃な価格で利用することができます。通常は使用した分だけを支払います。SaaSサービスは、自動的にスケールアップとスケールダウンを行います。また、インターネットに接続できる環境であれば、どのコンピューターやモバイル機器からでもSaaSアプリケーションやデータにアクセスすることができます。

SaaSの保護

しかし、ほとんどのSaaSソリューションが責任共有モデルを採用しているため、SaaSデータの保護は組織に委ねられています。ソフトウェア・ベンダーによる基本的な保護はあるものの、SaaSのデータはベンダーの責任ではなく、ユーザの責任となります。つまり、障害、不慮の削除、ランサムウェアの攻撃は、復元不可能なデータと生産性の損失につながる可能性があるということです。

クラウドデータ管理とは、データを自社のサーバーではなく、クラウド上に置くことです。クラウドデータは、オンプレミスのデータストレージを補完することができますが、すべてのデータをクラウドに置くことを選択する企業も増えています。クラウドデータマネジメントの利点は、ユーザがどこからでもデータにアクセスできることです。また、データ管理にクラウドを利用することで、バックアップ、災害復旧、アーカイブがよりシンプルになり、必要に応じてストレージを追加購入できるため、費用対効果も高くなります。ただし、クラウドによるデータ管理は、セキュリティやデータ損失などの問題が発生する可能性があるのが難点です。

なぜクラウドデータマネジメントを選ぶのか？
従来のデータストレージには、いくつかの欠点があります。

・老朽化したハードウェアのアップグレードや交換に費用がかかる
・データセンターの賃貸料の高騰
・スケーリング（拡張）に伴う追加コスト
・コンプライアンスに対応するための専門的な社内ノウハウ
・オンプレミスでのデータ保持のリスク増大

クラウドでのデータ管理は、柔軟性、内蔵のセキュリティ、手頃な価格で、これらの問題を解決します。しかし、クラウドへのデータ移行は複雑で時間がかかり、データを危険にさらすだけでなく、社内のリソースを消費してしまう可能性があります。

リスクとは、ポジティブであれネガティブであれ、組織の目標や目的に影響を与える可能性のあるあらゆる事象を指します。リスクマネジメントでは、リスクとは、これらの目標にマイナスの影響を与える可能性のある事象のことである。サイバーセキュリティの観点では、リスクとは、データ資産や業務の損傷や暴露につながる可能性があるあらゆる事象を指します。このようなリスクをうまく管理するためには、効果的なプロセスや戦略を開発する必要があります。

なぜリスクマネジメントに投資するのか？
サイバーセキュリティの例で説明すると、サイバーセキュリティのリスクはかつてないほど高まっています。例えば、ランサムウェアの攻撃はここ数年エスカレートしており、人質を取って悪質なコードを公開し、企業に破壊的な打撃を与えるケースが増えています。ランサムウェアの攻撃を受けると、企業の重要なデータは暗号化され、身代金を支払うまでアクセスできなくなります。

この攻撃から回復するためには、多額の評判と収益の損失が発生する可能性があります。リスクマネジメントは、サイバーセキュリティの脅威を認識し、事前に計画を立てます。サイバーセキュリティの脅威に対応するための十分な情報と効果的な戦略を準備しておくことで、組織の回復力が大幅に向上します。

Kubernetes (KOO-bur-NEH-teez) または K8S は、コンテナ化されたワークロードとアプリケーションの管理を支援する強力なオープンソースプラットフォームで、コンテナオーケストレーションの標準となっています。また、コンテナで実行されるマイクロサービス・アーキテクチャの人気と普及に伴い、その使用範囲は拡大する一方です。

Kubernetesの仕組み
Kubernetesは、コンテナ化されたアプリケーションのライフサイクルを管理するための完全なフレームワークを提供します。DevOpsチームは、コンテナ展開の自動化、フェイルオーバー計画の準備、すべてのアプリケーションとグループが正しく動作していることの確認などを、規模に関係なく環境全体を完全に制御するために設定されたスケーラブルなアプローチで行うことができます。コンテナがオンプレミス、クラウド、またはハイブリッドデータセンターのいずれに保存されていても、Kubernetesによってデータとリソースを完全に管理することができます。

コンテナで異なる保護方法が必要
他のデータと同様に、コンテナもバックアップし、保護し、あらゆる災害に備えなければなりませんが、基礎となるさまざまな側面がこれらのプロセスを複雑にしています。まず、コンテナとパイプラインの問題があります。コンテナ・イメージをキャプチャするだけでなく、パイプライン、つまりイメージを生成するためのファクトリーを保護することがより理にかなっています。これには、設定スクリプトやドキュメントも含まれます。また、永続的なアプリケーションデータやボリュームを保護することも重要です。

データ保護とDRのためのKubernetesのオプションは限られています。環境がより複雑になり、より多くのコンテナが組み込まれるようになると、企業はコンテナ化されたアプリケーションと、さまざまなクラウドサービスにある残りのデータとの間でディザスタリカバリのアプローチを調整できるソリューションが必要になります。

クライムはKubernetesに対する次のデータ保護とDRソリューションを提供します。

●Kasten K10 Platform

●Zerto for Kubernetes

効率的で費用対効果の高いクラウドストレージの管理手法を確立するために、守るべき最高のヒントとコツを紹介します。

▸ ニーズを定義する。 プロバイダーやソリューションを選択する前に、正確なニーズを定義する必要があります。そうしないと、ベンダーをウィンドウショッピングするために多くの時間とお金を費やすことになります。

データを分類する。データをタイプ別に分類し、組織にとって重要なデータセットを定義することが推奨されます。

▸ プロバイダーを綿密周到に選択する。クラウド ストレージ市場は、現代のクラウドの世界で最も競争の激しい市場の一つです。つまり、少なくとも10社の素晴らしい有名ベンダーがあり、あなたに合うかもしれないということです。したがって、コスト削減のためだけに無名業者を選択する必要はありません。大手ベンダーよりも価格が高くなる可能性もあるし、サポートが悪かったり、スタートアップ企業にありがちなトラブルに見舞われる可能性もあります。

▸ クラウド上で安全性を確保する。多くのクラウドストレージベンダーが提供するIDアクセス管理ソリューションは、一見難しそうですが、洗練された便利なものです。データの漏洩や損失を避けるためには、時間をかけて堅牢なデータアクセスポリシーを作成することが最も重要です。主なアクセスパターンとして、最小権限ルールを採用してみてください。

▸ コストをコントロールする。 ベンダーを選択したら、そのソリューション・エンジニアリング・チームと連絡を取り、シナリオに応じた最適なアプローチを検討します。これにより、初期コストを削減し、継続的なコストを監視および管理するためのドキュメントを作成することができます。さらに、ベンダーによっては、すぐに必要でないデータを、より安価なデータストレージの階層に保存することを認めてくれるところもあります。

▸ 構造を作成する。 クラウドへのデータのアップロードや、完全なデジタル文書のワークフローの作成を始める前に、図面を引いて構成図を作りましょう。その構成により、クラウドデータストレージが1年後にゴミサイトとならないようにすることができます。

1. 誤って削除してしまうこと: 1つ目の理由は、実はMicrosoft 365のデータ損失で最も多い懸念事項です。ユーザーを削除すると、その意図があったにせよなかったにせよ、その削除はネットワーク上に複製されます。バックアップを取れば、オンプレミスのExchangeでもOffice 365でも、そのユーザーを復元することができます。

2. 保持ポリシーのギャップと混乱：Microsoft 365 の保持ポリシーは、コンテンツの保持や削除を求める規制、法律、社内ポリシーに組織が準拠できるように設計されており、それらはバックアップではありません。しかし、バックアップの代わりに保持ポリシーに頼ったとしても、管理はおろか、維持することも困難です。バックアップは、より長く、よりアクセスしやすいリテンションを提供し、すべてを保護し、一箇所に保存して、簡単にリカバリできるようにします。

3. 内部セキュリティーの脅威：ビジネスに対する脅威を考えるとき、私たちは通常、外部の脅威から保護することを考えます。しかし、多くの企業は内部からの脅威を経験しており、それはあなたが考えている以上に頻繁に起こっています。ハイグレードなリカバリーソリューションがあれば、重要なデータが失われたり破壊されたりするリスクを軽減することができます。

4. 外部からのセキュリティ脅威： ランサムウェアはますます巧妙になり、犯罪者はユーザーの手を煩わせ、リンクをクリックさせ、身代金を要求するために組織全体のデータを暗号化する方法をより多く見つけてきています。バックアップを取れば、攻撃される前のインスタンスにデータを簡単に復元することができます。

5. 法的コンプライアンス要件：Microsoft 365 には eDiscovery 機能が組み込まれていますが、サードパーティのバックアップソリューションは、バックアップ内を簡単に検索し、あらゆる法規制のコンプライアンスニーズに対応したデータを迅速に復元できるように設計されています。

6. ハイブリッドメールの導入とMicrosoft 365への移行の管理：Microsoft 365 に移行する場合でも、オンプレミスの Exchange と Microsoft 365 のユーザーを混在させる場合でも、交換データは同じ方法で管理および保護する必要があり、移行元のロケーションは関係ありません。

7. Teams のデータ構造：Teams のバックエンドは、多くの人が思っているよりもはるかに複雑です。Teamsは自己完結型のアプリケーションではないため、Teamsで生成されたデータはExchange Online、SharePoint Online、OneDriveなど、他のアプリケーションに存在することになります。このように複雑なレイヤーが追加されているため、データを適切に保護することが最も重要です。

Veeam Backup for Microsoft Office 365　がそれらにお答えします。

ディザスタ・リカバリ（災害対策）の用語、話題などを特集しました。

https://www.climb.co.jp/faq/faq-category/disasterrecovery

バックアップポリシー作成のベスト・プラクティスについては

サーバ仮想化の基本要素である、1台のホスト上に存在するすべてのVMは、物理サーバのリソースを共有し、1つのハイパーバイザによって管理されていることを忘れてはいけません。もし、これら全てのVMが同時にバックアップジョブを開始したらどうなるのでしょうか？ハイパーバイザーやホストサーバのリソースに負担がかかり、遅延が発生したり、最悪の場合バックアップが失敗したりする可能性があります。

ここでスナップショットの威力が発揮されます。スナップショットはVMのある時点のコピーを取得し、フルバックアップと比較してはるかに迅速な処理が可能です。スナップショット自体はバックアップではありませんが、イメージベースバックアップの重要な構成要素です。VMスナップショットがバックアップと同等でない主な理由は、VMから独立して保存できないからです。このため、スナップショットの取得頻度によっては、VMのストレージ容量が急速に増大し、パフォーマンスに影響を与える可能性があります。このため、取得するスナップショットの数量を認識することが重要です。

分散型システムにおけるリカバリーの課題

よく設計された分散システムでは、あるコンポーネントの故障がシステム全体の故障を意味することはないはずです。むしろ、故障はそのコンポーネント自体に分離されるべきです。このような種類の障害を適切に検出し、対応するようにシステムを設計することは可能である。いずれにせよ、災害復旧テスト計画は、現実的な条件が訓練されるように、これらのニュアンスを考慮する必要があります。ここでは、復旧可能な分散型システムを設計する際に対処しなければならない課題をいくつか紹介します：

ネットワーク障害とデータレプリケーション
ネットワークトポロジーは、通常の運用中に変化することがあります。ネットワーク・パーティション、ネットワークの混雑、ポリシー、ルール、セキュリティ・グループ、その他多くの要因によって、システム内のコンポーネント間で断続的または恒久的な切断が発生することがあります。

フェイルオーバー時のプライマリーネットワークとリカバリーネットワークをどのように設計し、運用しているか？また、本番システムと並行してどのようにテストを行うかを理解することも重要です。リカバリーシステムは、オンデマンドでリカバリーできることが分かっていればそれでいいのです。

分散トランザクション管理
分散システムで実行されるトランザクションは、複数のシステムにまたがる可能性があり、それらのシステム間で調整する必要があることを意味します。この調整は、複数のマシンプロセスにまたがるトランザクションを調整することになるため、些細なことではありません。

さらに、トランザクションは、それらの他のマシン上の他のトランザクションや、データベースやファイルシステムなどの外部リソースと調整する必要がある場合があります。

サービス依存性の解決
サービス間でビジネスロジックの実行やサービスコールを連携させるためには、サービス同士を見つけることができる必要があります。ほとんどのマイクロサービス実装では、サービスディスカバリーが必要ですが、モノリシックなアーキテクチャでも応用が可能です。

データの一貫性と回復
多くの場合、ディザスタリカバリは、データの損失や破損を最小限に抑えながら、できるだけ早くサービスを回復することを目的としています。したがって、アプリケーションは、状態を失ったりデータを破損したりすることなく、障害から回復できるように設計されていなければなりません。

バックアップとディザスタリカバリの計画
バックアップは復旧計画に欠かせないもので、データのバックアップコピーがない場合は、ゼロから作り直すことも可能です。

災害復旧テスト + 復旧メカニズムの検証
リカバリープランは複雑なメカニズムに依存しており、本番環境に導入する前にテストが必要です。

ソフトウェアの新バージョンが常にリリースされ、リカバリに影響を与える可能性のある新機能が追加されるため、テストは定期的に行う必要があります。

分散システムに障害が発生した場合、コンポーネントやサービス間に多くの依存関係が存在する可能性があるため、どのように復旧させるか判断が難しい場合があります。ここでは、分散システムで依存関係を管理し、復旧の順序を設定するための主な考慮事項を紹介します：

重要な依存関係を特定する： 重要な依存関係の特定：まず、システム内のさまざまなサービスやコンポーネント間の依存関係をマッピングすることから始めます。システムの機能にとって最も重要な依存関係を特定し、これらの依存関係に障害が発生した場合の影響を判断します。

依存関係の優先順位付け： 重要な依存関係を特定したら、システム機能への影響と、他のサービスやコンポーネントが依存する度合いに基づいて、依存関係の優先順位を決定します。

復旧手順を確立する： 各サービスやコンポーネントの復旧手順を定義し、復旧に必要な手順と依存関係を明記します。

復旧プロセスを自動化する： 手動による介入を最小限に抑え、システムの復旧に必要な時間を短縮するため、可能な限り復旧プロセスの自動化を検討します。

復旧計画のテストと検証 ：定期的にテストと検証を行い、効果的で最新の状態に保つようにします。復旧のための模擬演習を実施し、潜在的な問題を特定し、計画を改善します。

1. 誤って削除した場合

ユーザを削除すると、その意図の有無にかかわらず、その削除はビジネスアカウントとメールボックスの削除とともにネットワーク全体に複製されます。Microsoft 365 に含まれるネイティブのごみ箱とバージョン履歴では、データ損失の保護に限界があります。バックアップからの単純なリカバリは、Microsoft 365がデータを永久に削除した後、あるいは保持期間が過ぎた後に大きな問題に変わる可能性があります。

2. 保持ポリシーのギャップと混乱

保持ポリシーを含め、継続的に進化するポリシーは、管理はおろか、対応することも困難です。Microsoft 365のバックアップと保持ポリシーは限定的であり、状況に応じたデータ損失しか管理できず、包括的なバックアップソリューションとして意図されていいません。

3. 内部セキュリティの脅威

一般的にセキュリティの脅威というと、ハッカーやウイルスを思い浮かべます。しかし、企業は内部からの脅威を経験しており、それは想像以上に頻繁に起こっています。企業は、意図的であれ無意識であれ、自社の従業員による脅威の犠牲になっています。ファイルや連絡先へのアクセスはすぐに変更されるため、最も信頼してインストールしたファイルから目を離すことは困難です。マイクロソフトは、通常のユーザと、退職前に会社の重要なデータを削除しようとする解雇された従業員との違いを知る術がありません。さらに、ユーザは感染したファイルをダウンロードしたり、信頼できると思っていたサイトに誤ってユーザ名やパスワードを流出させたりすることで、知らず知らずのうちに深刻な脅威を作り出しています。

4. 外部からのセキュリティ脅威

ランサムウェアのようなマルウェアやウイルスは、世界中の企業に多大な損害を与えている。企業の評判だけでなく、社内データや顧客データのプライバシーやセキュリティも危険にさらされています。外部からの脅威は、電子メールや添付ファイルを通して忍び込む可能性があり、特に感染したメッセージが非常に説得力があるように見える場合、どのような点に注意すべきかをユーザに教育するだけでは必ずしも十分ではありません。定期的なバックアップは、感染していないデータの別コピーを確保し、データの復旧をより確実かつ簡単にするのに役立ちます。

5. 法的およびコンプライアンス要件

法的措置が取られる中で、不意に電子メールやファイル、その他の種類のデータを復元する必要が生じることがあります。マイクロソフトはいくつかのセーフティネット（訴訟ホールドとリテンション）を組み込んでいますが、これらはユーザ企業を法的トラブルから守る強固なバックアップソリューションではありません。法的要件、コンプライアンス要件、アクセス規制は業界や国によって異なり、罰金、罰則、法的紛争はどの企業も遭遇したくないものです。

株式会社クライムではMicrosoft 365ユーザのデータを保護を手助けする多くのソリューションを提供しています。

フェイルオーバーとは、信頼性の高いバックアップシステムに自動的かつシームレスに切り替える機能のことである。コンポーネントまたはプライマリ・システムに障害が発生した場合、スタンバイ運用モードまたは冗長性のいずれかでフェイルオーバーを実現し、ユーザーへの悪影響を軽減または排除する必要。

以前アクティブだったバージョンの異常な故障や終了時に冗長性を実現するには、スタンバイデータベース、システム、サーバー、その他のハードウェアコンポーネント、またはネットワークが、常に自動的に動作に切り替わる準備が整っていなければなりません。言い換えれば、フェイルオーバーはディザスタリカバリ（DR）にとって非常に重要であるため、スタンバイコンピュータサーバシステムを含むすべてのバックアップ技術は、それ自体が障害を免れるものでなければならない。

サーバーのフェイルオーバー自動化には、パルスまたはハートビート状態が含まれる。つまり、ハートビート・ケーブルは、プライマリ・サーバーが常にアクティブな状態で、ネットワーク内の2つのサーバーまたは複数のサーバーを接続する。ハートビートが続いているか、パルスを感知している限り、セカンダリー・サーバーはただ休んでいるだけである。

しかし、セカンダリー・サーバーがプライマリー・フェイルオーバー・サーバーからのパルスの変化を感知すると、インスタンスを起動し、プライマリー・サーバーのオペレーションを引き継ぐ。また、技術者やデータセンターにメッセージを送り、プライマリー・サーバーをオンラインに戻すよう要求する。手動承認構成の自動化と呼ばれるシステムでは、技術者やデータセンターに単に警告を発し、サーバーへの変更を手動で行うよう要求するものもある。

仮想化では、ホスト・ソフトウェアを実行する仮想マシンまたは擬似マシンを使用して、コンピュータ環境をシミュレートします。このようにして、フェイルオーバー・プロセスは、コンピューター・サーバー・システムの物理的なハードウェア・コンポーネントから独立することができる。

アクティブ-アクティブとアクティブ-パッシブまたはアクティブ-スタンバイは、高可用性（HA）のための最も一般的な構成である。それぞれの実装手法は異なる方法でフェイルオーバーを実現しますが、どちらも信頼性を向上させます。

通常、同じ種類のサービスをアクティブに同時に実行する少なくとも2つのノードがアクティブ-アクティブ高可用性クラスタを構成します。アクティブ-アクティブ・クラスタは、すべてのノードにワークロードをより均等に分散し、単一のノードが過負荷になるのを防ぎ、負荷分散を実現します。また、より多くのノードが利用可能な状態に保たれるため、スループットと応答時間が向上します。HAクラスタがシームレスに動作し、冗長性を実現するためには、ノードの個々の構成と設定を同一にする必要があります。

対照的に、アクティブ-パッシブクラスタでは、少なくとも2つのノードが必要ですが、そのすべてがアクティブであるとは限りません。最初のノードがアクティブな2ノード・システムでは、2番目のノードはフェイルオーバー・サーバとしてパッシブまたはスタンバイのままになります。このスタンバイ運用モードでは、アクティブなプライマリ・サーバーが機能しなくなった場合でも、バックアップとして機能するように待機しておくことができます。ただし、障害が発生しない限り、クライアントはアクティブなサーバーにのみ接続します。

アクティブ-アクティブ・クラスタと同様に、アクティブ-スタンバイ・クラスタの両サーバはまったく同じ設定で構成する必要があります。こうすることで、フェイルオーバー・ルーターやサーバーが引き継がなければならない場合でも、クライアントはサービスの変化を認識することができません。

アクティブ-スタンバイ・クラスタでは、スタンバイ・ノードが常に稼働しているにもかかわらず、実際の利用率がゼロに近づくことは明らかです。

アクティブ-アクティブ・クラスタでは、各ノードが単独で全負荷を処理できるにもかかわらず、両ノードの利用率は半分ずつに近づきます。ただしこれは、アクティブ-アクティブ構成ノードの1台が負荷の半分以上を一貫して処理する場合、ノードの障害によってパフォーマンスが低下する可能性があることも意味します。

アクティブ-アクティブHA構成では、両方のパスがアクティブであるため、障害発生時の停止時間は実質的にゼロです。アクティブ-パッシブ構成では、システムが一方のノードから他方のノードに切り替わらなけ ればならず、時間がかかるため、停止時間が長くなる可能性があります。

アプリケーション・サーバーは、単にアプリケーションを実行するサーバーである。つまり、アプリケーションサーバーのフェイルオーバーは、この種のサーバーを保護するためのフェイルオーバー戦略です。

最低限、これらのアプリケーション・サーバは固有のドメイン名を持つべきであり、理想的には異なるサーバ上で実行されるべきです。フェイルオーバークラスターのベストプラクティスには通常、アプリケーションサーバーのロードバランシングが含まれます。

フェイルオーバー・テストでは、サーバー障害時にシステムの能力を検証し、復旧に向けて十分なリソースを割り当てる。言い換えれば、フェイルオーバー試験は、サーバーのフェイルオーバー能力を評価します。

このテストでは、何らかの異常終了や障害が発生した場合に、必要な余分なリソースを処理し、バックアップシステムに業務を移行する能力がシステムにあるかどうかを判断します。例えば、フェイルオーバーとリカバリーのテストでは、クリティカルな障害時にしばしば破られるパフォーマンスのしきい値を達成した時点で、システムが追加のCPUや複数のサーバーを管理し、電力を供給する能力を判断します。これは、フェイルオーバーテスト、回復力、およびセキュリティの間の重要な関係を浮き彫りにしています。

コンピューティングやネットワークなどの関連技術において、フェイルオーバーとは、バックアップ復旧設備にオペレーションを切り替えるプロセスのことである。フェイルオーバーにおけるバックアップ・サイトは一般に、スタンバイまたは冗長化されたコンピュータ・ネットワーク、ハードウェア・コンポーネント、システム、またはサーバーであり、多くの場合、二次災害復旧（DR）ロケーションにある。通常、フェイルオーバーでは、フェイルオーバー・ツールまたはフェイルオーバー・サービスを使用して、一時的に運用を停止し、リモート・ロケーションから運用を再開します。

フェイルバック操作では、予定されたメンテナンス期間または災害の後に、本番稼動を元の場所に戻します。スタンバイ状態から完全に機能する状態に戻すことです。

通常、システム設計者は、CA、HA、または高水準の信頼性が要求されるシステム、サーバー、またはネットワークにおいて、フェイルオーバー機能を提供する。また、フェイルオーバーの実践は、仮想化ソフトウェアの使用により、サービスの中断がほとんどない物理的なハードウェアへの依存度が低くなっています。

フェイルオーバークラスターは、フォールトトレランス（FT）、継続的可用性（CA）、または高可用性（HA）を一緒に提供するコンピュータサーバーのセットです。フェイルオーバークラスターのネットワーク構成では、仮想マシン（VM）、物理ハードウェアのみ、またはその両方を使用できます。

フェイルオーバークラスター内のサーバーの1台がダウンすると、フェイルオーバープロセスが起動します。障害が発生したコンポーネントのワークロードをクラスター内の別のノードに即座に送信することで、ダウンタイムを防ぐことができます。

アプリケーションやサービスに対してHAまたはCAのいずれかを提供することが、フェイルオーバークラスターの主な目的である。フォールトトレラント（FT）クラスタとしても知られるCAクラスタは、メインシステムやプライマリシステムに障害が発生した場合のダウンタイムを排除し、エンドユーザが中断やタイムアウトなしにアプリケーションやサービスを使い続けることを可能にします。

対照的に、HAクラスタではサービスが短時間中断する可能性があるにもかかわらず、ダウンタイムは最小限に抑えられ、自動的に復旧し、データの損失はありません。HAクラスタの復旧プロセスは、ほとんどのフェールオーバークラスタソリューションの一部として含まれているフェールオーバークラスタマネージャツールを使用して構成できます。

広義には、クラスタとは2つ以上のノードまたはサーバを指し、通常は物理的にケーブルで接続され、ソフトウェアで接続されます。並列処理または並行処理、負荷分散、クラウド・ストレージ・ソリューションなどの追加のクラスタリング技術が、一部のフェイルオーバー実装に含まれています。

インターネットフェイルオーバーは、基本的に冗長またはセカンダリのインターネット接続であり、障害発生時のフェイルオーバーリンクとして使用される。これは、サーバーにおけるフェイルオーバー機能のもう1つの部分と考えることができます。

• クロスクラウド戦略の導入： 複数のクラウドプロバイダーを活用することで、ベンダーロックインを回避し、異なるプラットフォームやインフラにリスクを分散することで耐障害性を高める。
• フェイルオーバープロセスの自動化： 自動化ツールを使用して、フェイルオーバープロセスを迅速かつシームレスに行い、ディザスタリカバリイベント中の人的介入を最小限に抑え、エラーの可能性を低減する。
• 頻繁なDR訓練の実施： 定期的な災害復旧訓練を計画、実施し、計画の有効性をテストし、弱点を特定します。関係者全員が参加し、万全の態勢を整える。
• データ重複排除の最適化 高度なデータ重複排除技術を使用して、バックアップに必要なストレージ量を削減し、プロセスをより効率的でコスト効果の高いものにする。
• 明確なRTOとRPO指標を確立する： 復旧時間目標（RTO）と復旧時点目標（RPO）を明確に定義し、文書化することで、ディザスタリカバリ戦略が事業継続の目標に合致するように。

• バックアップの暗号化を維持 データ保護を確実にし、ランサムウェアやサイバーセキュリティの問題によるリスクを軽減するために、暗号化されたリソースのクロスリージョンバックアップを作成します。
• バックアップネットワークをセグメント化する： バックアップシステムをメインネットワークから分離します。専用のVLANを使用し、バックアップが運用システムと同じネットワークセグメントからアクセスできないように。
• バックアップの完全性を定期的に検証する： バックアップの定期的なチェックと検証を行い、データが破損していないこと、必要なときに正常にリストアできることを確認します。
• ローリングバックアップ戦略を採用する： ローリングバックアップスケジュールを実施し、複数のバージョンのデータを異なる時間枠で保持する。これにより、ランサムウェア感染前の時点に復元することができます。
• エンドポイントプロテクションを使用してバックアップエージェントを保護する： バックアップ・エージェントを実行するすべてのデバイスとサーバーが、ランサムウェアのエントリ・ポイントにならないように、堅牢なエンドポイント保護機能を備えていることを確認します。

• フェイルオーバープロセスの自動化 重要なITシステムのフェイルオーバー・メカニズムを自動化します。フェイルオーバーを自動化することで、リカバリ時間を短縮し、手動による介入を最小限に抑えながら、重要なサービスの運用を維持できます。N2WSのリカバリシナリオ機能を使用すると、フェイルオーバーをシームレスにオーケストレーションできるため、障害が発生した場合でもシステムを迅速にオンラインに戻すことができます。
• 資産インベントリの定期的な更新 すべてのIT資産とその構成の最新のインベントリを維持します。これにより、復旧計画が正確なものとなり、復旧作業中に重要なコンポーネントがすべて計上されるようになります。
• モジュール式の復旧計画を作成する： 障害の具体的な性質に基づいて、個別に起動できるモジュール式のセグメントで復旧計画を策定します。これにより、的を絞った効率的な復旧作業が可能になります。
• 高可用性システムに投資する： 重要なアプリケーションの継続的なアップタイムを保証する高可用性ソリューションを導入する。これにより、ダウンタイムを最小限に抑え、部分的なシステム障害が発生した場合でもサービスの継続性を維持します。
• DR訓練とテストの実施 自動化された災害復旧（DR）訓練を定期的に実施して、復旧計画をテストし、意図したとおりに機能することを確認します。N2WSを使用すると、このようなDR訓練をスケジュールして自動化できるため、復旧プロセスが効果的で、チームが実際のインシデントに備えていることを確認できます。

• 一貫性を保つために、Azure Resource Manager（ARM）テンプレートを使用します： インフラストラクチャのデプロイメント用にARMテンプレートを作成し、維持します。これにより、ディザスタリカバリ時に重要な一貫性のある反復可能なデプロイメントプロセスが保証されます。
• コンプライアンスのためのAzure Policyの実装： Azure Policy を使用して、ディザスタリカバリの構成とコンプライアンス要件を実施し、検証します。これにより、デプロイされたすべてのリソースがディザスタリカバリの標準に準拠していることを確認できます。
• Azure Private Linkを活用したセキュアな接続性： Azure Private Linkを活用して、オンプレミスのネットワークをAzureサービスにプライベート接続することで、攻撃対象領域を減らし、フェイルオーバーおよびリカバリプロセス中の安全なデータ転送を実現します。
• Azure DevOpsによるフェイルオーバーテストの自動化：Azure DevOpsを使用して、ディザスタリカバリのテストをCI/CDパイプラインに統合します。フェイルオーバーテストを自動化することで、手動による介入なしにディザスタリカバリプランを定期的に検証できます。
• マルチテナント管理のためのAzure Lighthouseの導入： マネージドサービスプロバイダーや大企業の場合、Azure Lighthouseを使用して、複数のAzureテナントを1枚のガラスから管理し、ディザスタリカバリシナリオ中の監視と制御を改善します。

• Azure Site RecoveryとCRRの併用：CRRとAzure Site Recovery（ASR）を組み合わせることで、仮想マシン（VM）のレプリケーション、フェイルオーバー、リカバリを自動化できます。ASRは、ディザスタリカバリプロセス全体をオーケストレーションすることができ、より包括的なソリューションを提供します。
• アラートでレプリケーションの健全性を監視 Azure Monitorでカスタムアラートを設定して、CRRプロセスの健全性とステータスを追跡します。このプロアクティブな監視により、あらゆる問題が迅速に検出、対処され、データの一貫性と可用性が維持されます。
• マルチクラウド戦略の導入による耐障害性の強化： Azure内だけでなく、異なるクラウドプロバイダー間で重要なデータを複製することで、ディザスタリカバリ戦略を強化します。N2WSのようなツールは、クロスクラウドレプリケーションを可能にし、クラウドプロバイダー固有の障害に対するフェイルセーフを提供します。
• レプリケートされたデータをエンドツーエンドで暗号化する： レプリケーションプロセス中、静止時と転送時の両方でデータが暗号化されていることを確認します。暗号化キーの管理とアクセスにはAzure Key Vaultを使用し、ディザスタリカバリ計画にさらなるセキュリティ層を追加します。
• レプリケーションとフェイルオーバーを定期的にテストする： Azure AutomationとASRを使用して、ディザスタリカバリ訓練を自動化します。定期的なテストにより、レプリケーションとフェイルオーバープロセスの信頼性と効率性を確保し、運用に影響が出る前に潜在的な問題を浮き彫りにすることができます。

• ストレージ階層を活用してレプリケーションコストを最適化： Azureのストレージ階層（ホット、クール、アーカイブ）をASR内で戦略的に活用する。たとえば、アクセス頻度の低いVMにはクールストレージを使用し、ディザスタリカバリ機能を維持しながらストレージコストを最適化する。
• リカバリプランによるワークロードの優先順位付け： 重要なVMとサービスのフェイルオーバーを優先する詳細なリカバリプランを作成します。この優先順位付けにより、災害時に最も重要なアプリケーションを可能な限り迅速に利用できるようになります。
• 分離された環境でフェイルオーバーを定期的にテストする： 分離された環境で、無停止のフェイルオーバーテストを定期的に実施する。このような訓練により、稼働中のサービスに影響を与えることなく災害復旧計画を検証し、復旧プロセスが意図したとおりに機能することを確認できます。
• レプリケーションにタグベースの自動化を活用する： プロダクション」や「クリティカル」などのタグに基づいて、VM のレプリケーションを自動化します。これにより、特定のタグに一致する新しいVMにASRレプリケーション設定を自動的に適用し、手作業による介入なしにVMを確実に保護することができます。
• マルチクラウド戦略との統合による耐障害性の強化： N2WSなどのツールを使用してASRをクロスクラウド機能と統合することにより、ディザスタリカバリ戦略を拡張します。これにより、異なるクラウド環境間でのリカバリが可能になり、クラウド固有の障害から保護されるため、回復力がさらに高まります。

• マルチクラウドDR戦略の採用： ディザスタリカバリのワークロードをクラウドプロバイダーに分散することで、ベンダーロックインを回避し、各プロバイダーのコスト効率を活用します。これにより、耐障害性が向上し、価格設定の柔軟性も高まります。
• 迅速なフェイルオーバーのためのリカバリシナリオの実装： N2WSを使用して、わずか数クリックでフェイルオーバーを自動化し、オーケストレーションします。これにより、ダウンタイムを最小限に抑え、複雑な手動リカバリプロセスの必要性を低減し、最終的に運用コストを削減します。
• 自動化されたDRテストを活用して、コストのかかるエラーを回避します： 自動DRテストツールを使用して、ディザスタリカバリ計画を定期的にテストします。これにより、多額の費用をかけずに復旧プロセスを検証し、運用を中断することなく万全の準備を整えることができます。
• イミュータブルバックアップでDRバックアップにさらなるセキュリティ層を追加します： イミュータブル・バックアップは、データの改ざんや削除を確実に防止するため、余分なコストをかけずにさらなる安全策を提供します。
• クロスリージョンDRとクロスアカウントDRで耐障害性を強化します： N2WSのクロスリージョンバックアップとクロスアカウントバックアップ機能を利用して、地域の停電から保護し、データセキュリティを向上させます。

• クロスクラウド戦略の導入： 複数のクラウドプロバイダーを活用することで、ベンダーロックインを回避し、異なるプラットフォームやインフラにリスクを分散することで耐障害性を高める。
• フェイルオーバープロセスの自動化： 自動化ツールを使用して、フェイルオーバープロセスを迅速かつシームレスに行い、ディザスタリカバリイベント中の人的介入を最小限に抑え、エラーの可能性を低減する。
• 頻繁なDR訓練の実施： 定期的な災害復旧訓練を計画、実施し、計画の有効性をテストし、弱点を特定します。関係者全員が参加し、万全の態勢を整える。
• データ重複排除の最適化 高度なデータ重複排除技術を使用して、バックアップに必要なストレージ量を削減し、プロセスをより効率的でコスト効果の高いものにする。
• 明確なRTOとRPO指標を確立する： 復旧時間目標（RTO）と復旧時点目標（RPO）を明確に定義し、文書化することで、ディザスタリカバリ戦略が事業継続の目標に合致するようにする。

ディザスタリカバリ計画のコストは、組織の規模、IT インフラの複雑さ、データ保護とリカバリに対する特定の要件など、いくつかの要因によって大きく異なる可能性があります。

1. 事業規模と複雑さ

事業規模は災害復旧コストに直接影響します。大企業ほどITインフラが複雑な場合が多く、より広範で高度な復旧ソリューションが必要となります。中小企業(SMB)は通常、よりシンプルなITアーキテクチャを持ち、低コストで保護と復旧が可能です。

複雑さは規模だけの要因ではなく、事業運営の性質も影響します。複数の拠点にまたがる多面的な事業を展開する企業は、包括的かつ協調的な戦略が必要なため、復旧コストが高くなります。

2. リスク評価と許容度

リスク評価には、事業運営に対する潜在的な脅威とその発生の可能性を特定することが含まれます。リスクに対する許容度が低い組織は、継続性とデータ保護を確保するために、ディザスタリカバリに多額の投資をしなければなりません。これは通常、冗長システム、頻繁なバックアップ、より強固なセキュリティ対策にかかるコストが高くなることを意味します。

逆に、より高いリスクを受け入れようとする組織は、包括的ではないが、より手頃な災害復旧ソリューションを選ぶかもしれません。このアプローチは、初期コストを削減することができるが、特定のタイプの災害に対してビジネスが脆弱になる可能性がある。リスク許容度とコストのバランスをとることは、効果的な災害復旧計画を策定する上で極めて重要です。

3. テクノロジーの選択

ディザスタリカバリのために選択されるテクノロジーは、コストに大きく影響する。クラウドベースのDR、自動化されたフェイルオーバーシステム、リアルタイムのデータレプリケーションのような高度なテクノロジーは、ディザスタリカバリをより効率的にし、組織のリアルタイムのニーズに適応させることで、コストを削減するのに役立ちます。

テープ・ストレージや冗長化されたオンプレミス・ハードウェアのような伝統的なバックアップ方法は、より高価ですが、最新のディザスタリカバリ戦略では依然として役割を果たしています。例えば、ネットワークから切り離された冗長システムは、ランサムウェア攻撃に対する効果的な対策となります。

4. コンプライアンスと規制要件

規制への準拠は、災害復旧コストに影響する極めて重要な要素です。業界によって基準や要件はさまざまであり、多くの場合、遵守を確実にするために多額の投資が必要となります。

例えば、医療や金融の組織は、厳格なデータプライバシー法を遵守する必要があり、特定のデータ保護要件に対応する復旧ソリューションが必要となります。

災害復旧コストを最適化し、削減する方法をいくつかご紹介します。

クラウドベースの災害復旧ソリューションの活用

クラウド・サービスを利用することで、企業は物理インフラにかかる高額な初期費用を回避することができます。その代わりに、実際に使用するストレージやコンピュート・リソースに対して、多くの場合、サブスクリプションや従量課金で支払いを行います。この柔軟性により、大規模な資本支出をすることなく、変化するビジネス・ニーズに対応できるスケーラブルなソリューションが可能になります。

さらに、クラウドDRソリューションには冗長性と高可用性が組み込まれていることが多く、データとアプリケーションに複数の場所からアクセスできるようになっています。これにより、災害時のデータ損失やダウンタイムのリスクを軽減することができます。

適切なRTOとRPOの設定

RTO（Recovery Time Objective：目標復旧時間）とは、システムのダウンタイムが業務に重大な影響を与えるまでに許容される最大時間のことです。RPO（Recovery Point Objective）は、時間単位で測定したデータ損失の許容量を示す。適切なRTOとRPOを設定することは、効果的なディザスタリカバリにとって極めて重要です。

組織は、これらの目標とコストとのバランスを考慮しなければならない。RTOとRPOをゼロに近づけようと努力すると、法外なコストがかかることがあり、多くの場合、最先端の技術とインフラが必要になります。さまざまなシステムやデータの重要性を評価することは、現実的で費用対効果の高いRTOとRPOの設定を決定するのに役立ちます。

ITシステムの優先順位付け

システムとデータの重要性に基づいて復旧作業に優先順位をつけることは、費用対効果の高いディザスタリカバリに不可欠です。階層化には、IT資産を階層に分類することが含まれ、階層1が最も重要です。これにより、最も重要な要素に集中的に投資することが可能になり、重要な業務の迅速な復旧が保証されます。

重要度の低いシステムは、より低い階層に割り当てることができ、RTOとRPOの基準が高くなる可能性があります。このアプローチにより、組織はリソースをより効率的に割り当て、重要でないシステムへの不必要な支出を避けることができる。効果的な優先順位付けと階層化により、バランスの取れた財政的に持続可能なディザスタリカバリ戦略を実現します。

自動化されたフェイルオーバーとフェイルバック

自動化されたフェイルオーバーは、災害時に重要なシステムが手動で介入することなくバックアップ・インフラに切り替わることを保証し、ダウンタイムを最小限に抑えます。一方、自動化されたフェイルバックは、災害が解決されると、オペレーションをプライマリインフラストラクチャに戻します。これらの自動化されたプロセスは、信頼性とスピードを向上させ、災害による全体的な影響を軽減します。

自動化への投資には初期費用がかかりますが、ダウンタイムと手作業を減らすことで長期的なメリットが得られます。また、自動化によって復旧手順の一貫性が確保されるため、復旧プロセスを複雑にする人為的ミスを防ぐことができます。

ストレージ階層化によるコスト削減

ストレージ階層化では、データを重要度とアクセス頻度に基づいて分類し、それに応じて異なるタイプのストレージメディアに格納します。重要で頻繁にアクセスされるデータは、高価ではあるが高性能なストレージ・ソリューションに保存することができる。一方、重要度が低く、アクセス頻度の低いデータは、より低コストのストレージ層に移すことができます。

クラウドプロバイダーは、ミッションクリティカルなデータ用の高速SSDから、アーカイブデータ用の経済的なコールドストレージオプションまで、さまざまなストレージクラスを提供しています。使用パターンに基づいて階層間でデータを移動する自動化されたポリシーを実装することで、最適なストレージコスト管理が実現します。これにより、ストレージ費用を削減し、重要なデータを迅速に復旧できるようにしてディザスタリカバリを強化します。

N2WSは、DR戦略の有効性を高めながら、ディザスタリカバリのコストを大幅に削減します：

• 複数のリージョン、アカウント、クラウドにまたがるDRを自動化します： 自動化されたクロスリージョン、クロスアカウント、クロスクラウド機能により、ディザスタリカバリを簡素化し、安全性を確保します。
• DRテストと訓練の実行と自動化： ゼロコストで自動化されたDRドライランにより、ディザスタリカバリのテストを簡単に実施し、万全の準備を整えることができます。
• リカバリシナリオによるフェイルオーバーのオーケストレーション： ワンクリックで複数のリソースのフェイルオーバーを管理し、復旧作業を効率化します。
• 暗号化リソースのサポート： 暗号化されたリソースのクロスリージョンおよびクロスアカウントDRを実現し、セキュリティのレイヤーを追加します。
• カスタムDR生成によるコスト削減 N2WSのカスタムDR生成オプションにより、ディザスタリカバリコストを削減します。
• イミュータブルバックアップでセキュリティを強化 DRバックアップを不変性で保護し、データの整合性を確保します。
• 頻繁なバックアップ 最短60秒間隔でバックアップを取得し、RPOを最小化します。
• ほぼゼロのRTOを達成： 重要なシステムを数秒で復旧し、業務への影響を最小限に抑えます。
• フェイルオーバーとフェイルバックの自動化 リカバリプロセスを自動化することで、ダウンタイムを短縮し、一貫した信頼性の高い結果を保証します。
• 完全に機能するDRバックアップのリストア： すべてのVPCとネットワーク設定をそのままにバックアップをリストアし、シームレスなリカバリを実現します。

テクノロジーだけでは、組織のサイバーセキュリティ態勢を強化することはできません。サイバー攻撃の複雑さと脅威が増す中、組織は多層防御を構築することに注力しなければなりません。つまり、全員がセキュリティリスクと潜在的なインシデントを認識し、不審な点があれば報告することが必要です。この人的保護層の重要性は、多くの侵害が従業員のミスによるものであるという事実にあります。ハッキングの成功は、不注意や単純なミス、サイバー脅威やサイバー犯罪者のやり方に関する知識不足が原因であることが多いのです。

フィッシング、リモートアクセス（RDP）、ソフトウェアアップデートが、サイバー犯罪者が侵入する3つの主なメカニズムであることを知ることは、侵入先を絞り込む上で大きな助けになります。攻撃経路の観点から、最も労力を費やすべきものです。

従業員のサイバー意識はどうか？

サイバーセキュリティの意識向上プログラムを実施し、従業員の潜在的な知識のギャップを特定する。組織のサイバーセキュリティに対する意識の成熟度を、たとえば次のような方法で評価します。 フィッシング・シミュレーション・プログラムを使って、現在のサイバー意識のレベルを明らかにしましょう。

送った覚えのない荷物の配送状況を確認するために、リンクをクリックするようにというメールを受け取ったことはありませんか？あるいは、アカウントのパスワードを確認するためにリンクをクリックするよう求めるものがありましたか？これらはいずれもフィッシングメールである可能性があります。

ヒューマンファイアウォールは、あらゆる種類のランサムウェアに対する防御のための重要なレイヤーです。協力することで、脅威を特定し、データ漏洩を防止し、被害を軽減することができます。より多くの従業員がヒューマンファイアウォールに参加することで、より強固なものになります。

あなたの組織にとって重要なプロセスは何ですか？業務に支障をきたすような出来事があった場合、誰に連絡する必要がありますか？事業継続計画（BCP）が常に利用可能であることを確認することは、たとえすべてが失われ、ロックダウンされたとしても、組織が生き残るために非常に重要です。BCPは別の場所に保存され、不変であり、24時間365日利用可能であることを確認することがベストプラクティスです。BCPは、計画外のサービス停止時にどのように業務を継続するかを概説する必要があります。デジタルのシステムやサービスが復旧するまでの間、業務を継続できるように、手動による回避策をBCPに記載する必要があります。

サイバーセキュリティ対応計画を成功させるためには、どの資産が組織にとって重要で、どのようにすれば効果的に保護できるかを洞察することが不可欠です。保護を開始する前に、最も効果的な計画を立てるために、これらの資産を特定し、タグ付けする必要があります。デジタル資産にタグを付けることは、干し草の山から針を探すのと、簡単な検索で必要な特定の資産を見つけるのとでは、大きな違いがあります。

ランサムウェア攻撃に対する防御レベルを上げるには、サイバーセキュリティに関するスタッフの教育やトレーニングが非常に効果的かつ効率的です。あなたの組織にはセキュリティの専門家がいないため、基本的な知識を提供し、インシデントに直面したときに取るべき適切なアクションを明確にする必要があります。また、サイバーセキュリティ教育プログラムの有効性を繰り返し検証する必要があります。

多くの組織では、セキュリティ啓発のためのトレーニングは年に1回しか行われていませんが、残念ながらこれでは十分ではありません。ヒューマン・ファイアウォールのトレーニングは継続的に行うべきであり、脅威の発生に応じて従業員は更新や新しいブリーフィングを受ける必要があります。また、従業員は、職種が変わるたびに新しい問題について教育を受ける必要があります。サイバーセキュリティの筋力は、セキュリティ事故の可能性がある前に訓練しておく必要があります。従業員への教育こそが、ランサムウェアに対する最大の防御策であり、保護策であることを忘れないでください。

最終的に、すべてのセキュリティは、貴重な資産を保護することです。この場合、それはデータですが、その保護には、すべてのレイヤーを含む徹底的な防御戦略が必要です。徹底的な防御戦略を行うには、最も価値のあるデータを特定し、その周りに防御の層を構築して、可用性、完全性、機密性を保護する必要があります。セグメンテーションとは、インフラストラクチャーをゾーンに分割することで、必要なアクセスレベル、共通の制限ポリシーによる制約、ゾーン内外での接続性などを考慮して、オブジェクトを論理的なゾーンにグループ化することです。

ゾーンとは、特定の特性、目的、用途、および/または特定の制限のセットを持つ領域のことです。ゾーンを使用することで、多くの種類のリスクを低減するための効果的な戦略を持つことができます。より詳細かつ効果的な方法で環境を保護しながら、それに関連するコストを削減することができます。すべてを同じレベルで保護するのではなく、システムや情報を特定のゾーンに関連付けることができるようになりました。さらに、規制遵守の対象となるシステムをサブゾーンにグループ化することで、コンプライアンスチェックの範囲を限定できるため、長時間の監査プロセスに必要なコストと時間を削減することができます。

3-2-1ルールは、データを保護するための業界標準であり、ランサムウェアとの戦いにおいて究極の防御策となります。このルールでは、重要なデータそれぞれについて、少なくとも3つのコピーを保管し、バックアップデータを2つの異なるメディアに保存するよう求めています。また、データのコピーを1部、オフサイトに複製します。

この原則は、ユーザーアカウントまたはプロセスに、その意図する機能を実行するために絶対に必要な権限のみを与えることを意味します。最小特権の原則は、障害や悪意ある行動からデータや機能を保護するための重要な設計上の考慮事項として広く認識されています。

複雑すぎる設計はITチームにとって管理が難しく、攻撃者が弱点を突いたり、影に隠れたりすることを容易にします。管理しやすいシンプルな設計は、基本的に安全性が高いのです。K.I.S.S.（シンプルでわかりやすく）の原則に基づき、設計を行うようにしましょう。

既存のインフラにセキュリティを追加することは、既存のインフラを強化することを考えるだけでなく、新しいインフラや刷新されたインフラを設計するよりもはるかに難しく、コストも高くつきます。仮想インフラストラクチャでは、最初からセキュリティが確保されたマスター・イメージを構築するのがベターな方法です。既知の攻撃ベクトルをすべて取り除き、コンポーネントが追加され、正しく機能するために特定のオープン化や追加ソフトウェアが必要な場合にのみアクセスを開放することが、ベストプラクティスと言えます。こうすることで、すべてのビルドに一貫性が生まれ、最新の状態に保たれるため、安全なベースラインが構築されます。

職務分掌は、企業の持続的なリスクマネジメントと内部統制の基本的な構成要素である。これは、セキュリティに関するタスクと権限を複数の人に分散させるという考え方です。一人の人間がすべてをコントロールできるべきではありません。つまり、一人の人間がすべてを削除する能力も持ってはいけないということです。例えば、ある人が本番環境をコントロールし、別の人がバックアップ環境をコントロールすることです。バックアップの実践においても、プライマリバックアップシステムとは異なる認証と管理下にあるデータのセカンダリおよびオフサイトコピー（すなわちDR）を持つことは、ベストプラクティスと考えられています。

日常生活において、私たちは個人の衛生や清潔さを重要視しています。手を洗うことで感染症の蔓延を防ぐことができることは周知の事実であり、清潔さを保つことは日常生活の基本です。

しかし、脅威や脆弱性が増加し、デジタルとの接点が広がるにつれ、デジタル・インフルエンザに感染する危険性が常に存在することになります。実際のインフルエンザと同じように、いくつかの基本的なデジタル衛生習慣に従うことで、デジタル世界を移動する際のリスクを低減する方法があります。優れたデジタル衛生習慣に従うことで、データを健康に保ち、プライバシーを保護し、セキュリティを損なわないようにすることができます。

重要な実践例:
– 各ログインソースにユニークなパスワードを作成する。こうすることで、あるパスワードが破られたとしても、盗まれたパスワードで他のアカウントにアクセスされることがなくなります。
– パスワードマネージャーを使用する。100を超えるパスワードを覚えるのは大変です。優れたパスワードマネージャーを使えば、すべてのログイン情報を管理でき、固有のパスワードを簡単に作成し、使用することができます。
– 多要素認証（MFA）を利用する。MFAを設定することで、さらなるアカウントの安全性を確保することができます。
– 堅牢なパスワードポリシーを使用する
– アカウントのロックアウトポリシー
– 未使用のデバイス、アプリケーション、退職した社員、必要のないプログラムやユーティリティを削除する。
– パッチ管理：使用中のソフトウェア、ハードウェア、ファームウェアがすべて最新のソフトウェアレベルで動作していることを確認する。

デジタル健康法はレジリエンスを高めるための重要な要素です。定期的にバックアップをとっていれば、サイバー脅威は災害ではなく、むしろ不勝手なものになります。1日分の仕事を失うことはあっても、すべてを失うことはないでしょう。特定の種類のデータをどれくらいの頻度でバックアップするか、クラウドサービスを使うか、物理デバイスを使うかは、必要なサービスやセキュリティレベルに基づいて選択する必要があります。

ランサムウェアは、ファイルを暗号化することで、自分自身のデータからあなたを締め出す。このため、適切なバックアップはこの種の攻撃から回復するための優れた方法です。バックアップがあれば、暗号化されたファイルを最近のバックアップリポジトリにあるコピーと簡単に交換することができます。バックアップに戻すと、最新のデータの一部を失うかもしれませんが、サイバー犯罪者にお金を払ってファイルを復元してもらうよりは確実によいでしょう。

暗号化により、許可された者だけがあなたの情報にアクセスできるようにします。あなたの情報が定義されたセキュリティ・ドメインから離れるとすぐに、あなたの情報があらかじめ定義された適切なレベルで暗号化されていることを確認します。暗号化自体は干渉を防ぐものではありませんが、権限のない第三者があなたの情報を読むことを禁止することができます。暗号化は、他のセキュリティ対策が失敗した場合に、機密データを保護するのに役立ちます。

ランサムウェア対策のための13のベスト・プラクティスを紹介しています。

https://www.climb.co.jp/faq/faq-category/ransamware-best13

ブログでも各種ランサムウェア対策を紹介しています。