Loading article…
IT 災害復旧(または単に災害復旧 (DR) ) は、嵐や戦争などの自然災害または人為的災害の後に重要なインフラストラクチャとシステムを維持または再構築するプロセスです。DR では、重要なビジネス機能をサポートするIT システムに重点を置いたポリシー、ツール、および手順を使用します。 [1]これには、重大な混乱を伴うイベントにもかかわらず、ビジネス機能のすべての重要な側面を維持することが含まれます。したがって、これはビジネス継続性 (BC) のサブセットと見なすことができます。 [ 2] [3] DR では、プライマリ サイトがすぐには復旧できないと想定し、データとサービスをセカンダリ サイトに復元します。
ITサービスの継続性
ITサービス継続性（ITSC）はBCPのサブセットであり、[4]復旧ポイント/復旧時間目標の指標（主要なリスク指標として頻繁に使用される）に依存しています。IT災害復旧計画とより広範なIT回復力計画を網羅しています。また、電話やデータ通信などの通信に関連するITインフラストラクチャとサービスも組み込まれています。[5] [6]
バックアップサイトの原則
計画には、バックアップ サイト（「ホット」（災害発生前に稼働）、「ウォーム」（稼働開始の準備ができている）、「コールド」（稼働開始にかなりの作業が必要））の手配、および継続性のために必要なハードウェアを備えたスタンバイ サイトの手配が含まれます。
2008年、英国規格協会は、ビジネス継続性規格BS 25999をサポートするBS25777という特定の規格を立ち上げました。これは、コンピュータの継続性とビジネスの継続性を特に一致させることを目的としていました。これは、2011年3月にISO/IEC 27301「セキュリティ技術 - ビジネス継続性のための情報通信技術の準備に関するガイドライン」が発行された後に撤回されました。[7]
ITILではこれらの用語のいくつかを定義しています。[8]
目標復旧時間
目標復旧時間（RTO）[9] [10]は、事業継続性の中断を避けるために、中断後にビジネスプロセスを復旧しなければならない目標時間とサービスレベルです。 [11]
ビジネス継続性計画の方法論によれば、RTO は、代替または手動の回避策の時間枠の特定を含む、プロセスの所有者による ビジネス影響分析(BIA) 中に確立されます。
RTO は RPO を補完するものです。許容可能な、または「許容可能な」ITSCパフォーマンスの限界は、通常のビジネス プロセスの機能から失われた時間と、その期間中に失われたデータまたはバックアップされなかったデータの観点から、RTO と RPO によって測定されます。[11] [12]
実際の回復時間
実際の復旧時間（RTA）は、事業継続性と災害復旧にとって重要な指標です。[9]
事業継続グループは、時間指定のリハーサル（または実測）を実施し、その中でRTAが決定され、必要に応じて改良されます。[9]
リカバリポイント目標
リカバリポイント目標（RPO）は、 ITサービスからトランザクションデータが失われるまでの最大許容間隔です。 [11]
たとえば、RPOが分単位で測定される場合、実際には毎日のオフサイトバックアップでは不十分なので、オフサイトのミラーバックアップを継続的に維持する必要があります。 [13]
RTOとの関係
瞬時ではないリカバリでは、重大なリスクや損失を招くことなく、一定の間隔でトランザクションデータを復元します。[11]
RPO は、最近のデータが永久に失われる可能性がある最大時間を測定するものであり、損失量を直接測定するものではありません。たとえば、BC プランが最新の利用可能なバックアップまで復元することである場合、RPO はそのようなバックアップ間の間隔になります。
RPOは既存のバックアップ体制によって決定されるのではなく、BIAが各サービスのRPOを決定します。オフサイトデータが必要な場合、データが失われる可能性がある期間は、バックアップがオフサイトで保護されたときではなく、バックアップが準備されたときに始まる場合があります。[12]
平均時間
回復メトリックは、障害メトリックに変換したり、障害メトリックと一緒に使用したりできます。一般的な測定には、平均故障間隔(MTBF)、平均初回故障時間(MTFF)、平均修復時間(MTTR)、平均ダウンタイム(MDT) などがあります。
データ同期ポイント
データ同期ポイント[14]はバックアップが完了した時点です。ディスク間のコピーが完了するまで更新処理を停止します。バックアップ[15]コピーは、データがテープにコピーされたときや他の場所に転送されたときではなく、コピー操作の以前のバージョンを反映します。
システム設計
RTOとRPOは、ビジネスリスクやその他のシステム設計基準を考慮してバランスをとる必要があります。[16]
RPO は、バックアップがオフサイトで保護される時間に関係しています。同期コピーをオフサイトミラーに送信することで、ほとんどの予期しないイベントに対応できます。テープ (またはその他の移動可能なメディア) の物理的な輸送が一般的です。リカバリは、事前に決定されたサイトでアクティブ化できます。共有のオフサイトスペースとハードウェアがパッケージを完成させます。[17]
大量の高価値トランザクション データの場合、ハードウェアを複数のサイトに分割できます。
歴史
災害復旧と情報技術 (IT) の計画は、コンピュータ センターの管理者が組織がコンピュータ システムに依存していることを認識し始めた 1970 年代半ばから後半にかけて開発されました。
当時、ほとんどのシステムはバッチ指向のメインフレームでした。オフサイトのメインフレームは、プライマリ サイトの復旧を待つ間にバックアップ テープからロードすることができ、ダウンタイムは比較的重要ではありませんでした。
災害復旧産業[18] [19]は、バックアップコンピュータセンターを提供するために発展しました。サンガードアベイラビリティサービスは、スリランカ（1978年）に設立された最も初期のセンターの1つでした。[20] [21]
1980 年代から 90 年代にかけて、企業内のタイムシェアリング、オンライン データ入力、リアルタイム処理など、コンピューティングが飛躍的に成長しました。ITシステムの 可用性がさらに重要になりました。
規制当局が関与するようになり、2、3、4、または5つのナイン（99.999%）の可用性目標が義務付けられることが多くなり、ホットサイト施設向けの高可用性ソリューションが求められました。[引用が必要]
IT サービスの継続性は、それぞれ ISO/IEC 27001 と ISO 22301 で規定されている事業継続管理 (BCM) と情報セキュリティ管理 (ICM) の一部として不可欠になりました。
2010年以降のクラウドコンピューティングの台頭により、システムの回復力に新たな機会が生まれました。サービスプロバイダーは、可用性と信頼性を含む高いサービスレベルを維持する責任を引き受けました。彼らは、回復力の高いネットワーク設計を提供しました。Recovery as a Service （RaaS）は広く利用可能であり、 Cloud Security Allianceによって推進されています。[22]
分類
災害は、脅威と危険の 3 つの大まかなカテゴリによって発生します。
- 自然災害には、洪水、ハリケーン、竜巻、地震、疫病などの自然現象が含まれます。
- 技術的災害には、パイプラインの爆発、輸送事故、公共サービスの中断、ダムの決壊、偶発的な有害物質の放出など、事故やシステムおよび構造物の故障が含まれます。
- 人為的な脅威には、積極的な攻撃、化学攻撃や生物攻撃、データやインフラストラクチャに対するサイバー攻撃、破壊行為、戦争などの意図的な行為が含まれます。
あらゆるカテゴリとタイプの災害に対する準備措置は、予防、保護、緩和、対応、復旧という5つのミッション領域に分類されます。[23]
計画
研究は、より総合的な災害前計画アプローチを実施する方が費用対効果が高いという考えを支持している。災害軽減（災害復旧計画など）に1ドル費やすごとに、社会は対応と復旧のコストを4ドル節約できる。[24]
2015年の災害復旧統計によると、ダウンタイムが1時間続くと、コストが増加する可能性がある[25]
- 中小企業 8,000ドル、
- 中規模組織 74,000ドル、
- 大企業70万ドル以上。
ITシステムは企業の円滑な運営、そして経済全体にとってますます重要になってきており、ITシステムの継続的な運用と迅速な復旧を確保することの重要性が高まっています。[ 26]
管理措置
制御手段は、脅威を軽減または排除できる手順またはメカニズムです。メカニズムの選択は、災害復旧計画 (DRP) に反映されます。
制御手段は、イベントの発生を防ぐことを目的とした制御、望ましくないイベントを検出または発見することを目的とした制御、および災害またはイベント後にシステムを修正または復元することを目的とした制御に分類できます。
これらの制御は文書化され、いわゆる「DR テスト」を使用して定期的に実行されます。
戦略
災害復旧戦略は、事業継続計画から派生します。[27]次に、ビジネスプロセスの指標がシステムとインフラストラクチャにマッピングされます。[28]費用便益分析により、どの災害復旧対策が適切かが明らかになります。ダウンタイムのコストと特定の戦略の実装コストを比較すると、さまざまな戦略が意味を持ちます。
一般的な戦略は次のとおりです。
- テープにバックアップしてオフサイトに送る
- オンサイトのディスクへのバックアップ（オフサイトのディスクにコピー）またはオフサイト
- オフサイトでのレプリケーション。システムが復元または同期されると、ストレージエリアネットワーク技術を介して
- メタデータ（VM、テンプレート、ディスク）をプライベートクラウドに複製するプライベートクラウドソリューション。メタデータはOpen Virtualization Formatと呼ばれるXML表現として構成され、簡単に復元できます。
- オンサイトとオフサイトのデータ センターの両方に複製するハイブリッド クラウド ソリューション。これにより、オンサイトのハードウェアまたはクラウド データ センターへの即時フェイルオーバーが実現します。
- データとシステムの両方をオフサイトに複製しておき、災害後でもシステムとデータに継続的にアクセスできるようにする高可用性システム（クラウドストレージに関連することが多い）。[29]
予防戦略には以下が含まれます。
- システムやデータのローカルミラーとRAIDなどのディスク保護技術の使用
- サージプロテクター — 繊細な電子機器への電力サージの影響を最小限に抑えます
- 停電時にもシステムを継続させるために無停電電源装置（UPS）やバックアップ発電機を使用する
- 警報器や消火器などの火災予防・軽減システム
- ウイルス対策ソフトウェアおよびその他のセキュリティ対策。
サービスとしての災害復旧
災害復旧サービス（DRaaS）は、停電、機器の故障、サイバー攻撃、自然災害などのシナリオに対して、DR機能の一部またはすべてを実行するためにサードパーティベンダーと契約することです。[30]
クラウドシステムの災害復旧
以下のベストプラクティスは、クラウドホストシステムの災害復旧戦略を強化することができます。 [31] [32] [33]
- 柔軟性:災害復旧戦略は、部分的な障害 (特定のファイルの復旧など) と環境全体の障害の両方をサポートできるように適応できる必要があります。
- 定期的なテスト: 災害復旧計画を定期的にテストすることで、その有効性を検証し、弱点やギャップを特定できます。
- 明確な役割と権限: 災害復旧計画を実行する権限を持つ人物を明確に定義し、それらの人物に個別のアクセスと権限を与える必要があります。復旧を実行できる人物とバックアップ データにアクセスできる人物の間で権限を明確に分離することで、不正なアクションのリスクを最小限に抑えることができます。
- 文書化: オペレーターがストレスの多い状況でも効果的に計画に従えるよう、計画は十分に文書化され、わかりやすくする必要があります。
参照
参考文献
- ^ 「システムと運用の継続性：災害復旧」ジョージタウン大学 - 大学情報サービス。2012年2月26日時点のオリジナルよりアーカイブ。2024年7月20日閲覧。
- ^ 「災害復旧と事業継続」。IBM 。 2013年1月11日時点のオリジナルよりアーカイブ。 2024年7月20日閲覧。
- ^ 「ビジネス継続性管理とは何か?」Disaster Recovery Institute International 。 2024年7月20日閲覧。
- ^ 「データ層を守る」ForbesMiddleEast.com 2013年12月24日。[永久リンク切れ ]
- ^ M. Niemimaa、Steven Buchanan (2017 年 3 月)。「情報システム継続プロセス」ACM .com (ACM デジタル ライブラリ)。
- ^ 「2017 IT サービス継続性ディレクトリ」(PDF)。災害復旧ジャーナル。2018年 11 月 30 日時点のオリジナル(PDF)からアーカイブ。2018年 11 月 30 日閲覧。
- ^ 「ISO 22301は5月中旬に発行予定 - BS 25999-2は撤回予定」。ビジネス継続フォーラム。2012年5月3日。2021年11月20日閲覧。
- ^ 「リソース ハブで最新のコンテンツをすべて参照 | Axelos」www.axelos.com。
- ^ abc 「NFLドラフト同様、時計は回復時間の敵か」Forbes . 2015年4月30日。
- ^ 「災害復旧時間に間に合わない3つの理由」Forbes、2013年10月10日。
- ^ abcd 「RPO と RTO を理解する」 DRUVA 2008 . 2013 年2 月 13 日閲覧。
- ^ ab 「RPO と RTO をバックアップおよびリカバリ プランに組み込む方法」。SearchStorage。2019年5月 20 日閲覧。
- ^ Richard May. 「RPO と RTO を見つける」。2016 年 3 月 3 日時点のオリジナルよりアーカイブ。
- ^ 「モバイルシステム間のデータ転送と同期」2013年5月14日。
- ^ 「S-1 の修正案 #5」。SEC.gov。
リアルタイム ... 冗長性とバックアップを提供 ...
- ^ Peter H. Gregory (2011-03-03)。「最大許容ダウンタイムの設定 - 復旧目標の設定」。IT災害復旧計画入門。Wiley。19～22 ページ。ISBN 978-1118050637。
- ^ William Caelli、Denis Longley (1989)。マネージャのための情報セキュリティ。Springer。p. 177。ISBN 1349101370。
- ^ 「大惨事？ここで起こるはずがない」ニューヨークタイムズ。1995年1月29日
。患者記録
- ^ 「商業用不動産/災害復旧」ニューヨークタイムズ。1994年10月9日
。災害復旧業界は、
- ^ チャーリー・テイラー（2015年6月30日）。「米国のテクノロジー企業サンガードがダブリンで50人の雇用を発表」アイリッシュ・タイムズ。
サンガードは1978年に設立された。
- ^ Cassandra Mascarenhas (2010 年 11 月 12 日)。「SunGard は銀行業界において重要な存在となる」。Wijeya Newspapers Ltd.
SunGard ... スリランカの将来。
- ^ SecaaS カテゴリー 9 // BCDR 実装ガイダンス CSA、2014 年 7 月 14 日取得。
- ^ 「脅威と危険の特定とリスク評価（THIRA）と利害関係者の準備状況レビュー（SPR）：ガイド包括的準備ガイド（CPG）201、第3版」（PDF）。米国国土安全保障省。2018年5月。
- ^ 「災害後復旧計画フォーラム：災害復興パートナーシップによるハウツーガイド」オレゴン大学コミュニティサービスセンター、(C) 2007、www.OregonShowcase.org 。2018年10月29日閲覧。[永久リンク切れ ]
- ^ 「災害復旧の重要性」。2018年10月29日閲覧。
- ^ 「IT災害復旧計画」。FEMA。2012年10月25日。 2013年5月11日閲覧。
- ^ 「ビジネス継続性プログラムを開発、実装、維持するための専門的実践フレームワークの使用により、重大なギャップの可能性を減らすことができます」。DRI International。2021年8月16日。 2021年9月2日閲覧。
- ^グレゴリー、ピーター。CISA 認定情報システム監査 人オールインワン試験ガイド、2009 年。ISBN 978-0-07-148755-9。480ページ。
- ^ Brandon, John (2011 年 6 月 23 日)。「災害復旧戦略としてクラウドを使用する方法」。Inc。2013年5月 11 日閲覧。
- ^ 「サービスとしての災害復旧 (DRaaS) とは何ですか? | TechTarget による定義」。災害復旧。
- ^ AWS での耐障害性システムのエンジニアリング。O'Reilly Media。ISBN 9781098162399。
- ^ クラウド アプリケーション アーキテクチャ クラウドでのアプリケーションとインフラストラクチャの構築。O'Reilly Media。ISBN 9780596555481。
- ^ サイト信頼性エンジニアリング Google の運用システム運用方法。O'Reilly Media。ISBN 9781491951170。
さらに読む
- バーンズ、ジェームズ（2001）。事業継続計画ガイド。ニューヨーク州チチェスター：ジョン・ワイリー。ISBN 9780470845431. OCLC 50321216。
- Bell, Judy Kay (2000)。災害時の生存計画:企業向け実用ガイド。米国カリフォルニア州ポートヒューニーメ: Disaster Survival Planning。ISBN 9780963058027. OCLC 45755917.
- フルマー、ケネス（2015）。事業継続計画：計画フォーム付きステップバイステップガイド。ブルックフィールド、コネチカット州：ロススタインアソシエイツ社。ISBN 9781931332804. OCLC 712628907, 905750518, 1127407034。
- DiMattia, Susan S (2001). 「継続性のための計画」図書館ジャーナル. 126 (19): 32–34. ISSN 0363-0277. OCLC 425551440.
- Harney, John (2004 年 7 月～8 月)。「ビジネス継続性と災害復旧: バックアップまたはシャットダウン」。AIIM E -DOC マガジン。ISSN 1544-3647。OCLC 1058059544。2008 年 2 月 4 日のオリジナルからアーカイブ。
- 「ISO 22301:2019(en)、セキュリティとレジリエンス - ビジネス継続性管理システム - 要件」。ISO。
- 「ISO/IEC 27001:2013(en) 情報技術 - セキュリティ技術 - 情報セキュリティ管理システム - 要件」。ISO。
- 「ISO/IEC 27002:2013(en) 情報技術 - セキュリティ技術 - 情報セキュリティ管理のための実践規範」。ISO。
外部リンク
- 「ビジネス継続性、災害復旧、および関連データミラーリングと z/OS ストレージテクノロジーソリューションの用語集」。recoveryspecialties.com。2020 年 11 月 14 日にオリジナルからアーカイブ。2021 年 9 月 2 日に取得。
- 「IT 災害復旧計画」。Ready.gov。2021年 9 月 2 日閲覧。
- 「RPO (リカバリポイント目標) の説明」。IBM 2019-08-08 2021-09-02閲覧。