クラウド・バックアップ管理者へ10の質問
バックアップIT管理者は、進化するランサムウェアの脅威やバグ、不具合、人為的ミスからデータを守るために、様々な課題に直面している。ここでは、必ずしも明白ではないかもしれない、データ・バックアップに関する重要な10の質問です。
バックアップに関しては、「定期的にデータをバックアップしているか？」を始めとして、いくつか明白な質問があります。
しかし、必ずしもそうではない、データバックアップに関する重要な質問もあります。単にバックアップを取っているだけでは、データが安全であるという保証にはなりません。また、3-2-1バックアップ・ルールのような時代遅れのバックアップのベスト・プラクティスに従う必要もありません。
このような現実を念頭に置いて、ここではすべての組織が自問自答すべき10の質問を洗い出してみましょう。これらの質問に対する答えは、ユーザのバックアップ戦略が単に基本的なことをカバーしているだけなのか、それともそれ以上の方法でデータを保護し、不測の事態が発生したときにビジネスの継続性を維持する能力を最大化するためのものなのかについて、本質的な洞察を与えてくれるでしょう！。
基本的なデータバックアップの実践
あまり知られていないデータバックアップの質問に移動する前に、データバックアップの基本、つまり効果的なバックアップ戦略のための絶対的に基本的なプラクティスについて説明します。
それには以下のようなものがあります：
適切なRTO（Recovery Time Objective）とRPO（Recovery Point Objective）を定義し、データのバックアップを作成する頻度を決定します。
設定したRTOとRPOの目標をバックアップ頻度に反映させること。
リカバリープランを作成し、データをリストアする際に実際に何をすべきかを把握する。
バックアップを定期的にテストし、リカバリ失敗のリスクを軽減する。
バックアップデータがすべて消去されるリスクを最小限に抑えるため、バックアップデータのコピーを複数保管すること。
これらのバックアップ方法を実践したからといって、何か褒められるわけではありません。これらは、すべての組織が効果的なバックアッププログラムを運用するために必要不可欠なものです。
高度なバックアッププラクティス
データバックアップのような重要なものに関しては、必要最低限で満足すべきではありません。バックアップデータを安全に保管し、効果的なリカバリのために使用する能力を最大化するために、高度なバックアッププラクティスを実施する必要があります。
高度なバックアッププラクティスを導入しているかどうかを知るにはどうすればよいでしょうか？以下の10の質問をしてみてください。
1. フェイルオーバー・リージョンはあるか？
フェイルオーバー・リージョンとは、本番ワークロードを通常ホストしているクラウド・リージョンとは別のクラウド・リージョンのことです。プライマリーリージョンで障害が発生した場合、フェイルオーバーリージョン内でデータとワークロードをリストアすることができます。
もちろん、復旧作業の一環としてフェイルオーバー・リージョンを設定することも可能です。しかし、それには時間と労力がかかり、復旧を遅らせることになります。それよりも良い戦略は、フェイルオーバー・リージョンを前もって構成しておき、可能な限り迅速に切り替えられるようにすることです。
しかし、2つのリージョンにお金を払いたくない！"とお考えかもしれません。一度に2つのリージョンで運用するとクラウド料金が高くなることを考えれば、それはもっともな指摘です。しかし、「pilot light」のような戦略を活用すれば、フェイルオーバー・リージョンを安価に維持することができます。
フェイルオーバー・リージョンでは最小限の環境しか稼働させないということだ。しかし、N2WS Backup & Recoveryのようなディザスタリカバリツールがあれば、異なるリージョンに即座にリストアすることができるため、地域的な障害によって元の本番環境が破壊された場合でも、バックアップ環境を新しい本番環境として迅速にスケールアップすることができます。
2. クロスクラウド保護は必要か？
フェイルオーバー・リージョンを設定したとしても、それだけでは最も深刻なクラウドの停止から保護するには不十分かもしれません。複数のクラウド・リージョンが一度にダウンした場合、あるいはクラウド・プラットフォーム全体に影響を及ぼす大規模なネットワーク問題、ランサムウェア攻撃によるデータの損失、従業員（または元従業員）による悪意のある内部攻撃、クラウド環境からの偶発的なデータ削除などの問題が発生した場合、フェイルオーバー・リージョンを設定していても必ずしも救われるとは限りません。
だからこそ、別のクラウドにバックアップ環境を構築することも検討すべきです。最悪のシナリオがプライマリ・クラウドを襲った場合、もう一方のクラウドにフェイルオーバーすることができます。
ここでもまた、別のクラウドを運用することでクラウド料金は増加するが、本番用ではないクラウドで最小限の環境を維持することで、コストを節約することができます。
3. 本格的なリカバリ運用を定期的にテストしているか？
データのバックアップとリカバリーのテストには、リカバリーのスクリプトが実際に実行されるかどうかを時々チェックすることから、全停電に対応した本格的なリカバリーのシミュレーションを実行することまで、さまざまな意味があります。
理想的には、後者を定期的に行うことです。完全な復旧訓練を実施し、その間に何が起こったかを文書化することができて初めて、実際の障害から迅速に復旧するための最高の準備が整います。
4. コンプライアンス指令を見直しているか？
コンプライアンスの枠組みには、合理的なバックアップとリカバリの保護を確保するための要件が含まれることが増えています。何を「合理的」とするかはフレームワークによって異なりますが、バックアップデータをオフサイトに保管したり、リカバリ計画をテストしたりすることは、コンプライアンス規則を満たすために不可欠です。
そのため、組織は、データのバックアップとリカバリの領域で、どのコンプライアンス指令が適用されるかを評価し、バックアップ戦略が要件を満たしていることを確認する必要があります。
5. バックアップデータとネットワークの安全性は確保されているか？
脅威者が本番データを暗号化または削除した場合、バックアップから業務を復元したいと思うでしょう。しかし、もし悪者がバックアップデータも暗号化し、身代金を支払ってデータを復号化しない限り、リカバリに使用できなくしたらどうでしょうか？バックアップに機密情報が含まれていて、それが悪人の手に渡ってしまったら？あるいは、脅威者がネットワークに対してDoS（Denial-of-Service：サービス拒否）攻撃を仕掛け、データ復旧の妨げになったらどうでしょう？
このようなリスクから保護するためには、ネットワークだけでなくバックアップデータも適切に保護する必要があります。バックアップを暗号化することで、攻撃者がバックアップデータを見つけて悪用することが（不可能ではありませんが）難しくなります。また、ネットワーク防御は、リカバリに必要なときにネットワークを運用し続けるのに役立ちます。
6. インフラ設定のクローン化とキャプチャはできているか？
迅速な復旧を保証するには、データのバックアップだけでは十分ではありません。ネットワーク・ルール、IAMポリシー、ストレージ・ティアの設定など、ワークロードが依存しているインフラ設定をリストアできるようにする必要もあります。
データそのもののバックアップに加え、インフラ設定のクローン化とキャプチャが、効果的なバックアップ＆リカバリ戦略に不可欠なのはこのためです。
7. バックアップの複数のコピーを様々な場所に保存していますか？
バックアップを暗号化することは、データ侵害が発生した場合に業務を復旧させるために必要な重要情報の改ざんを防ぐ一つの方法です。しかし、管理者の一人が誤ってバックアップデータを削除してしまったり、ソフトウェアツールの設定が不十分であったりといったリスクからビジネスを守ることはできません。また、バックアップをホストする物理的なインフラを破壊する自然災害のようなリスクからも保護できません。
そのため、バックアップのコピーを複数作成し、異なる場所に保管することがベストプラクティスとなります。この経験則はかつて3-2-1バックアップ・ルールと呼ばれ、組織は重要なデータを合計3つのインスタンス（1つのインスタンスは本番データそのものであり、残りの2つはバックアップである）を持つべきだというものでした。インフラ障害が重要な情報の損失につながるリスクを軽減するために、データの2つのインスタンスは別々のストレージメディアに保存されるべきであり、1つのコピーはリモートサイトに存在すべきです。
しかし、新しいクラウド機能と新たなコンプライアンス要件により、3-2-1バックアップ・ルールは時代遅れとなっています。また、データの複製だけでなく、ネットワークやインフラの設定も複製し、完全に信頼できるフェイルオーバーと本番環境へのスムーズな移行のためにキャプチャしておく必要ががあります。
8. リカバリ時に何を優先すべきか分かっているか？
復旧作業中、最終的な目標はすべてのデータを復旧することです。しかし、ビジネス・オペレーションにとってより重要なデータもあるはずです。例えば、3年間誰も開いていないWord文書は、収益を生み出すアプリケーションに接続されたデータベースほど迅速に復旧する必要はないでしょう。
だからこそ、復旧計画作業のドリルを実行する際に、どのデータに優先順位をつけるかを事前に決めておき、その優先順位を復旧計画に反映させることが重要です。そうでなければ、ビジネスへの深刻な中断を防ぐのに十分なほど、重要なリソースを迅速に復旧できる可能性はかなり低くなります。
9. 誰がデータ復旧を担当するのか - そして、担当者が不在の場合はどうするのか？
基本的なデータ復旧計画を策定しているほとんどの組織では、データ復旧業務を管理する担当者を指定しています。しかし、そのような担当者が不在になる可能性、あるいは標準的なコミュニケーション・チャネルの障害により、障害発生時に連絡が取れなくなる可能性については、常に計画されているわけではありません。
復旧計画を次のレベルに引き上げるためには、このようなリスクに対処する必要がある。理想的には、誰がリカバリーを行うことになっても機能するようなリカバリー戦略を立てることです。これは、スクリプトや特別な専門知識を必要とせず、中央から利用できるバックアップとリカバリーのツールを活用することで可能になります。
10. 障害発生時、顧客とのコミュニケーションは？
停電中に顧客や外部の関係者とコミュニケーションをとることは、データをうまく復旧させるために厳密には必要ではないので、これを「主な」質問のひとつに含めるつもりはありません。
しかし、ブランド保護と顧客満足の観点から、停電時の効果的な外部コミュニケーションは非常に重要です。そのために、コミュニケーション計画があるかどうか、そして、コミュニケーションの指揮を執る人たち（一般的には広報やコミュニケーション部門ですが、営業やカスタマーサポートなど、他のグループも巻き込む必要があるかもしれません）が、障害発生時に顧客に適切な情報を提供し続けるために何をすべきかを知っているかどうかを確認する価値があります。
データのバックアップとリカバリーを次のレベルへ
今日、基本的なデータ・バックアップとリカバリーの実践は、 それは基本的な期待であり、特別な啓蒙の証ではありません。群衆から抜きん出たい、サイバー攻撃や偶発的なデータ損失からビジネスを保護する能力を最適化したいのであれば、フェイルオーバー・リージョン、バックアップ・セキュリティなどのソリューションを導入して、より高いレベルを目指す必要があります。
N2WSでは、バックアップ、ディザスタリカバリ、ライフサイクル管理の包括的な機能だけでなく、定期的なディザスタリカバリのドリルやテストを実行し、ドキュメントを作成する機能も提供します。N2WSは、リカバリ時に優先すべきリソースを特定し、クロスリージョンバックアップやインフラ設定のクローン化などの高度な機能を提供します。
クライムではN2WS以外のAWSに対するソルーションを提供しています。
この記事が気に入ったらサポートをしてみませんか？