ディザスタリカバリ (DR) とは、企業を重大な悪影響から保護することを目的とするセキュリティ計画のことです。これにより、企業は、データ障害の発生後、業務を長時間停止したり収益を大きく失うことなく、ミッションクリティカルな業務を維持または迅速に再開できます。
災害にはさまざまな形態と規模があります。地震、竜巻、台風などの壊滅的な事象だけでなく、機器の故障、サイバー攻撃などのセキュリティインシデント、場合によってはテロのことも指します。
企業は、災害に備え、実行すべきプロセスとミッションクリティカルな業務を再開するためのアクションを詳述した DR 計画を作成する必要があります。
ディザスタリカバリでは、企業の重要なビジネス業務をサポートする IT システムに重点を置きます。多くの場合、事業継続という用語と関連していますが、この 2 つは完全に同じ意味を持つわけではありません。DR は事業継続の一部です。事業のあらゆる側面を災害にかかわらず維持することに、より重点を置いています。
IT システムが事業の成功にとって必要不可欠になっているため、ディザスタリカバリは事業継続プロセスにおける主要な柱となっています。
ほとんどの経営者は、通常、予期しない危機が発生するまで自然災害の被害を受けるとは考えていません。その結果、多額の運用上および経済上の損失が発生します。これらの事象は予測できない場合があります。経営者として、災害への対応準備計画を策定していないというリスクを冒すことはできません。
企業が受ける災害には、技術的なもの、自然によるもの、人間によるものがあります。自然災害の例には、洪水、竜巻、台風、地滑り、地震、津波などがあります。一方、人間による災害や技術的な災害には、危険物質の流出、電源またはインフラ障害、化学および生物兵器による脅威、原子力発電所の事故またはメルトダウン、サイバー攻撃、テロ行為、爆発、市民による暴動などがあります。
計画の対象となる可能性がある災害は次のとおりです。
規模や業種に関係なく、予期しない事象が発生して日常業務が停止すると、企業は迅速に復旧して、顧客や得意先へのサービスの提供を継続する必要があります。
ダウンタイムは、企業が直面する最大規模の IT コストになり得ます。Infrascale 社の 2014 年 ～ 2015 年のディザスタリカバリに関する統計情報によると、1 時間のダウンタイムがもたらすコストが小規模企業では 8,000 ドル、中規模企業では 74,000 ドル、大企業では 700,000 ドルに及ぶ可能性があります。
中小規模企業 (SMB) の場合、生産性の損失が長引くと、失注、請求の遅延、納期の遅れ、ダウンタイムからの復旧作業に伴う勤務時間増による人件費の増加により、キャッシュフローが減少するおそれがあります。
ビジネスの大きな中断を予想して適切に対処できなければ、予期しない災害が発生したときに長期的な悪影響が生じるリスクを負うことになります。
DR 計画が導入されていれば、次のような複数のリスクから企業を守ることができます。
企業の高可用性への依存が高まっており、ダウンタイムに対する許容度は低下しています。このため、多くの企業では、DR を導入して災害による悪影響が日常業務に及ばないようにしています。
DR とダウンタイムにおける 2 つの重要な指標は次のとおりです。
RPO と RTO を特定したら、管理者はこの 2 つの指標を使用して、最適なディザスタリカバリ戦略、手順、およびテクノロジーを選択できます。
より厳格な RTO の時間内で業務を復旧するには、セカンダリデータを最適な形で配置し、容易かつ迅速にアクセスできるようにする必要があります。データを迅速にリストアする方法の 1 つが即時リカバリです。すべてのバックアップデータファイルをリアルタイムの状態に移行することで、ネットワーク経由で転送する必要がなくなります。これにより、サーバーとストレージのシステム障害に対する保護を提供できます。
即時リカバリを使用する前に、以下の 3 つの点を考慮する必要があります。
また、即時リカバリは最大で 15 分かかる可能性があるため、リカバリ時間を短縮したい場合はレプリケーションが必要になる場合があります。レプリケーションとは、定期的にデータベースをコンピュータサーバー A からサーバー B へ電子的に更新 (コピー) することです。これにより、ネットワーク内のすべてのユーザーは常に同じ情報レベルを共有します。
ディザスタリカバリ計画は、構造化されたアプローチを文書化したもので、計画外のインシデントに対応するための手順が規定されています。災害の影響を最小限に抑えて、企業がミッションクリティカルな業務を迅速に再開する、あるいは通常どおりの業務を継続するための予防手順で構成されます。
通常、DRP では、すべてのビジネスプロセスと継続ニーズを詳細に分析します。さらに、詳細計画を作成する前に、リスク分析 (RA) とビジネスインパクト分析 (BIA) を行う必要があります。RTO と RPO の規定も必要です。
リカバリ戦略はビジネスレベルを起点とする必要があります。これにより、企業の運営にとって最も重要なアプリケーションを判断できます。リカバリ戦略では企業のインシデント対応計画を定義します。一方、DRP では対応方法を詳述します。
リカバリ戦略を決定する際、次のような項目について検討する必要があります。
経営層はすべてのリカバリ戦略を承認する必要があります。リカバリ戦略は企業の目的や目標に沿ったものでなければなりません。リカバリ戦略が策定されて承認されたら、DRP に書き換えることができます。
ディザスタリカバリ計画 (DRP) のプロセスでは、ドキュメント作成だけにとどまらず、さまざまな作業を行う必要があります。ビジネスインパクト分析 (BIA) とリスク分析 (RA) は、DRP プロセスでリソースを集中させる領域を決定するのに役立ちます。
BIA は、破壊的な事象の影響を特定するのに役立ち、DR コンテキスト内でのリスク特定の開始点となります。また、RTO と RPO の決定にも役立ちます。
リスク分析により、BIA で浮き彫りになったプロセスとシステムの通常運用を妨げる可能性がある脆弱性と脅威を特定します。また、リスク分析を活用して破壊的な事象の発生確率を評価し、その潜在的な重大性を明らかにすることができます。
DR 計画のチェックリストには以下の手順が含まれます。
DRP 作成にあたり、必要なすべての重要なアクション手順の要約をまとめ、必要不可欠な連絡先をリストアップします。これにより、重要な情報に容易かつ迅速にアクセスできるようになります。
DR 計画では、チームメンバーの役割と責任を定義するとともに、アクション計画の開始条件の概要を示す必要もあります。その後、必ず対応とリカバリアクティビティを詳細に規定します。この他に、DRP テンプレートに入れる必須項目は次のとおりです。
DRP の範囲はさまざまです (基本的なものから包括的なものまで)。100 ページを超えるものもあります。
DR の予算もさまざまで、時間の経過とともに変動する場合があります。このため、米国連邦緊急事態管理庁のオンライン DR 計画など、無料で入手できるリソースを活用できます。また、オンラインには多数の無料の情報やハウツー記事があります。
DRP の目標チェックリストには、以下の項目が含まれます。
DR 計画では、少なくとも、日常のビジネス業務への悪影響を最小限に抑える必要があります。また、予期しないインシデントが発生した場合に従うべき緊急事態時の対応手順について、従業員が把握している必要があります。
DRP プロセスにおいて、距離は重要でありながら見過ごされることが多くあります。利便性、コスト、テスト、帯域幅を考慮したうえで DR サイトとして理想的なのは、プライマリデータセンターに近い場所にあるサイトです。ただし、停止の範囲はさまざまなので、プライマリデータセンターとその DR サイトが近くに配置されていると、地域的な事象によってその両方が破壊される場合があります。
特定の環境に合わせて DRP を調整できます。
テストではすべての DRP を実証します。これにより、計画の不備を特定し、災害発生前に問題を修正する機会を得ることができます。また、テストを行うことで計画の有効性を証明し、RPO を特定できます。
IT テクノロジおよびシステムは絶えず変化しています。このため、DRP が最新状態であることをテストによって保証します。
DRP をテストしない理由としては、予算の制限、経営層の承認の欠如、リソースの制約などが挙げられます。また、DR テストには、時間、計画、リソースが必要です。リアルタイムのデータの使用が伴う場合は、インシデントリスクとなる可能性もあります。しかし、テストは決して無視すべきでない DR 計画の必須要素です。
DR テストは、以下のようにシンプルなものから複雑なものまで多種多様です。
DR ポリシーでのテストをスケジュールする必要がありますが、業務の妨げとならないよう注意してください。テストの頻度が高すぎると生産性が低下し、担当者の負担が増えるためです。一方、テストの頻度が低すぎてもリスクがあります。また、大きなシステム変更を加えた後は必ず DR 計画をテストしてください。
テストの効果を最大限に高めるには、以下を実現する必要があります。
Disaster recovery-as-a-service は、ここ何年か注目を集めているクラウドベースの DR 手法です。DRaaS のメリットとしては、低コストで導入が容易になるうえ、定期テストが可能になる点です。
クラウドテストソリューションは共有インフラで実行されるため、企業のコストを削減できます。また、柔軟性が高く、必要なサービスのみを契約できるのに加え、一時インスタンスを起動するだけで DR テストを完了できます。
DRaaS に関する期待と要件は文書化され、サービスレベル契約 (SLA) に含まれます。サードパーティベンダーは、従量課金制または契約を通じて、クラウドコンピューティング環境へのフェールオーバーを提供します。
ただし、DR サイトには全ユーザーのアプリケーションを実行するための十分な領域が確保されていない可能性があるため、大規模災害の発生後にクラウドベースの DR を利用できない場合があります。また、クラウド DR によって帯域幅のニーズが増加するため、複雑なシステムを追加するとネットワーク全体のパフォーマンスが低下する可能性があります。
クラウド DR の最大の欠点は、プロセスをほとんど制御できないことだと考えられます。このため、定義されたリカバリポイント目標とリカバリタイム目標を達成しながらインシデント発生時に DRP を実施するには、サービスプロバイダを信頼する必要があります。
コストはベンダーごとにさまざまで、ストレージの使用量またはネットワーク帯域幅に基づいてベンダーによる課金が発生する場合は、コストがすぐに増加する可能性があります。したがって、プロバイダを選ぶ前に、綿密な内部評価を実施して DR ニーズを判断する必要があります。
候補となるプロバイダには次のような項目を確認します。
DR サイトにより、プライマリデータセンターが利用できない場合に、テクノロジインフラおよび運用をリカバリおよびリストアできます。内部サイトか外部サイトかは問いません。
企業には、内部 DR サイトを設置して維持する責任があります。このようなサイトは、より短い RTO と大規模な情報要件を抱える企業で必要になります。内部のリカバリサイトを構築する際の考慮事項には、ハードウェア構成、電源保守、サポート機器、レイアウト設計、冷暖房、場所、スタッフなどがあります。
外部サイトと比較するとはるかに高額ですが、内部 DR サイトでは DR プロセスのすべての側面を管理できます。
外部サイトは、サードパーティベンダーが所有して運用し、以下のいずれかに分類されます。
1980 年代に、SHARE Technical Steering Committee と International Business Machines (IBM) の 2 つの組織がDR サービスレベルを記述するためのティアシステムを考案しました。 このシステムでは、最小限の能力を表すティア 0 から最大限の能力を表すティア 6 までを使用して、オフサイトでのリカバリ能力を示しています。
第 7 ティアは、DR 自動化を盛り込むために後になって追加されました。現在、DR シナリオでの最高レベルの可用性を表しています。一般に、各ティアでのリカバリ能力が向上すると、コストも削減されます。
災害への備えは容易ではありません。ソフトウェア、ハードウェア、ネットワーク機器、接続、電力、テストを網羅した包括的なアプローチをとり、ディザスタリカバリを RPO 目標と RTO 目標の範囲内で達成できるようにする必要があります。綿密で実用的な DR 計画の実施は容易な作業ではありませんが、多くの利点が期待できます。
導入されたディザスタリカバリ計画を企業内の全員が認識する必要があり、その計画を実施するときには効果的なコミュニケーションが重要になります。DR 計画を策定するだけでなく、テスト、担当者のトレーニングに加え、すべてを適切に文書化して、定期的に改善することが必要不可欠です。最後に、サードパーティベンダーのサービスの導入は慎重に行うようにしてください。