ディザスタリカバリ
ディザスタリカバリ(英: disaster recovery)、災害復旧(さいがいふっきゅう)は、事業継続マネジメントにおける概念のひとつで、自然災害または人為的災害後の重要な技術インフラ、システム復旧、あるいは被害を最小限に抑えるための予防措置のことである。主にコンピュータシステムやネットワークなどIT関連で用いられることが多い。事業継続のための一連のポリシー、ツール、手順も含まれる。
災害の範囲には、建物単体での火災などの小規模なものから風水害、地震などの自然災害や不正侵入、テロなどの人為的なものなど比較的大きなものまで原因、規模にかかわらず含まれる。
ディザスタリカバリは、重大な破壊的イベントにもかかわらずビジネスのすべての重要な側面を機能させ続けることを含む事業継続計画とは対照的に、重要なビジネス機能をサポートするIT/テクノロジーシステムに焦点を合わせる[1]。ディザスタリカバリは事業継続計画の一部である[2][3]。ディザスタリカバリは、プライマリサイトが(少なくともしばらくの間)回復できない前提で、元の場所に復元するプロセス以外に、データとサービスをセカンダリの存続サイトに復元するプロセスを検討する。
ITサービス継続性
[編集]ITサービス継続性[4] (ITSC)は、事業継続計画(BCP) [5]の一部であり、ITディザスタリカバリ計画とより広範なITレジリエンス計画を網羅している。また、(音声)テレフォニーやデータ通信などの通信に関連するITインフラストラクチャとサービスの要素も組み込まれている。
ITSC計画には、目標復旧時点(RPO、最近のトランザクション)と目標復旧時間(RTO、時間間隔)を含める。
バックアップサイトの原則
[編集]計画では、バックアップサイト(ホットサイト、ウォームサイト、コールドサイト、スタンバイサイト)を、継続性のために必要に応じてハードウェアとともに配置する。
2008年に英国規格協会は、事業継続標準BS 25999と紐づいた、事業継続の中で計算機の継続に特化したBS 25777を立ち上げた。これは、2011年3月にISO/IEC 27031「セキュリティ技術-事業継続性のための情報通信技術の準備に関するガイドライン」が公開された後、撤回された。
目標復旧時間
[編集]目標復旧時間(RTO)は、災害(または中断)後に事業継続の中断により発生する許容できない影響を避けるために、ビジネスプロセスが復元されるべき目標期間とサービスレベルである [7]。
受け入れられている事業継続計画の方法論では、RTOは、プロセス所有者によってビジネス影響分析(BIA)中に確立される。これには、代替または手動の回避策のオプションによる時間枠が設定されることもある。
このテーマに関する多くの文献では、RTOは、目標復旧時点(RPO)を補完するものとして説明されており、2つの指標は、損失時間(RTO)の観点から、許容できるITSCパフォーマンスの限界を示す[7][8]。
実際の復旧時間
[編集]Forbesの概要は、「事業継続性と災害復旧の重要な指標」であるのは実際の復旧時間(RTA)であると述べている。
RTAは、演習または実際のイベント中に確立される。事業継続グループは、リハーサル(または実績)の時間を計り、必要な改善を行う[9]。
目標復旧時点
[編集]目標復旧時点(RPO)は、事業継続計画で定義される。これは、重大なインシデントが原因でITサービスからデータ(トランザクション)が失われる可能性がある最大の期間を表す[7]。
RPOが数分(または数時間)の場合、実際には、オフサイトのミラーバックアップを継続的に維持する必要がある。テープによる毎日のオフサイトバックアップでは不十分である[10]。
復旧時間の目標との関係
[編集]瞬時ではない復旧の後、一定期間にわたってデータ/トランザクションを復元し、重大なリスクや重大な損失を被ることなく復元する[7]。
RPOは、重大なインシデントが発生した場合に最近のデータが永続的に失われる可能性がある最大期間を測定し、そのような損失の量を直接測定するものではない。たとえば、事業継続計画が「利用可能な最後のバックアップまで復元する」場合、RPOは、オフサイトで安全に保管されたバックアップ間の最大間隔となる。
ビジネス影響分析は、各サービスのRPOを決定するために使用され、RPOは既存のバックアップ体制によって決定されない。オフサイトデータの準備が必要な場合、データが失われる可能性のある期間は、バックアップがオフサイトで作成される時間ではなく、バックアップを準備する作業の開始時間の近くから始まる[8]。
データ同期ポイント
[編集]データ同期ポイント[11]は特定の時点ですが、物理バックアップを実行するタイミングを含める必要がある。使用される1つのアプローチは、ディスクからディスクへのコピーが作成されている間、更新キューの処理を停止することである。バックアップ[12]は、データがテープにコピーされたり、他の場所に送信されたりしたときではなく、そのコピー操作の以前の時間を反映する。
RTOとRPOの値がコンピューターシステムの設計にどのように影響するか
[編集]RTOとRPOは、他のすべての主要なシステム設計基準とともに、ビジネスリスクを考慮してバランスを取る必要がある[13]。
RPOは、バックアップがオフサイトに送信される時間に関係する。同期コピーを介してオフサイトミラーにオフシッティングすると、予期しない問題が発生する可能性がある。テープ(またはその他の移動可能なメディア)の物理的な移動を行うと、比較的低コストでバックアップのニーズを快適にカバーできる。復旧は所定の場所で行うことができる。共有のオフサイトスペースとハードウェアにより、必要なパッケージが完成する[14]。
大量の高価値トランザクションデータの場合、ハードウェアを2つ以上のサイトに分割する。地理的領域に分割すると、復元力が増す。
歴史
[編集]コンピュータセンターの管理者が組織のコンピュータシステムへの依存を認識し始めたため、1970年代半ばから後半にかけて情報技術(IT)のディザスタリカバリ計画が開発された。
当時、ほとんどのシステムはバッチ指向のメインフレームだった。別のオフサイトメインフレームは、プライマリサイトのリカバリを保留しているバックアップテープからロードできた。ダウンタイムは比較的重要ではなかった。
災害復旧業界[15][16]は、バックアップコンピュータセンターを提供するために開発された。最も初期のそのようなセンターの1つは、スリランカにあった(Sungard Availability Services、1978)[17][18]。
1980年代から90年代にかけて、企業内のタイムシェアリング、オンラインデータ入力、およびリアルタイム処理が拡大するにつれて、ITシステムの可用性を高める必要があった。
2000年代にインターネットが急速に成長する前から、規制当局が関与するようになった。2、3、4、または5ナイン(99.999%)の目標がしばしば義務付けられ、ホットサイト施設向けの高可用性ソリューションが求められた[要出典]。
ITサービス継続性は、事業継続性管理(BCM)と情報セキュリティ管理(ICM)の実装、およびISO/IEC 27001、ISO22301で指定されている実装と運用の情報セキュリティ管理、および事業継続性管理の一部として、多くの組織にとって不可欠である。
2010年以降のクラウドコンピューティングの台頭はその傾向を続けている。今日では、ネットワーク自体が十分に信頼できる限り、コンピューティングサービスが物理的に提供される場所はさらに重要ではない(別の問題であり、最新のネットワークは非常に回復力があるため、懸念は少ない)。「サービスとしてのリカバリ」(RaaS)は、クラウドセキュリティアライアンスによって推進されているクラウドコンピューティングのセキュリティ機能または利点の1つである[19]。
災害の分類
[編集]災害は、脅威と危険の観点から3つに分類される。最初の分類は、洪水、台風、竜巻、地震、エピデミックなどの自然災害を含む自然災害である。2番目の分類は、パイプラインの爆発、輸送事故、ユーティリティの中断、ダムの決壊、偶発的な危険物の放出など、事故またはシステムと構造の障害を含む技術的な危険である。3番目の分類は、積極的な加害者攻撃、化学的または生物学的攻撃、データまたはインフラストラクチャに対するサイバー攻撃、妨害行為などの意図的な行為を含む、人為的な脅威である。すべての分類と種類の災害に対する準備措置は、予防、保護、軽減、対応、および復旧の5つのミッション領域に分類される[20]。
災害復旧計画の重要性
[編集]最近の研究は、より包括的な災害前計画アプローチを実装する方が長期的には費用効果が高いという考えを支持している。ハザードの軽減(災害復旧計画など)に1ドルを費やすごとに、社会の対応と復旧のコストを4ドル節約できる[21]。
2015年の災害復旧統計によると、1時間続くダウンタイムには以下のコストが掛かる。
- 中小企業は8,000ドル
- 中規模の組織は74,000ドル
- 大企業は70万ドル[22]
ITシステムが企業の円滑な運営、そして間違いなく経済全体にとってますます重要になるにつれて、ITシステムの継続的な運用とその迅速な回復を確保することの重要性が増している。たとえば、ビジネスデータが大幅に失われた企業のうち、43%は再開せず、29%は2年以内に閉鎖する。その結果、システムの継続または復旧の準備を非常に真剣に行う必要がある。これには、破壊的なイベントが発生した場合の損失を最小限に抑えることを目的とした、時間とお金の多大な投資が含まれる[23]。
管理措置
[編集]制御手段は、組織に対するさまざまな脅威を軽減または排除できる手順またはメカニズムである。さまざまなタイプの対策を災害復旧計画(DRP)に含めることができる。
ディザスタリカバリ計画は、事業継続計画と呼ばれるより大きなプロセスのサブセットであり、アプリケーション、データ、ハードウェア、電子通信(ネットワークなど)、およびその他のITインフラストラクチャの再開の計画が含まれる。事業継続計画(BCP)には、主要な担当者、施設、危機的コミュニケーション、評判保護など、ITに関連しない側面の計画が含まれ、IT関連のインフラストラクチャの回復/継続性については災害復旧計画(DRP)を参照する必要がある。
ITディザスタリカバリ制御対策は、次の3つのタイプに分類できる。
- 予防策–イベントの発生を防ぐことを目的とした管理。
- 探偵対策–不要なイベントを検出または発見することを目的としたコントロール。
- 修正措置–災害またはイベント後にシステムを修正または復元することを目的とした制御。
優れたディザスタリカバリ計画の対策では、これら3種類の制御を文書化し、いわゆる「DRテスト」を使用して定期的に実行する必要がある。
戦略
[編集]ディザスタリカバリ戦略を選択する前に、ディザスタリカバリプランナーはまず組織の事業継続計画を参照する。これは、目標復旧時点と目標復旧時間の主要な指標を示す必要がある[24]。 次に、ビジネスプロセスのメトリックが、システムとインフラストラクチャにマッピングされる[25]。
適切な計画を立てないと、災害の影響が拡大する可能性がある[26]。メトリックがマッピングされると、組織はIT予算を確認する。RTOとRPOの指標は、利用可能な予算に適合している必要がある。費用便益分析は、多くの場合、どの災害復旧対策を実施するかを指示する。
New York Timesは、ローカルおよびオフサイトのテープアーカイブのメリットにクラウドベースのバックアップを追加すると、「データ保護のレイヤーが追加されます」と書いている[27]。
データ保護の一般的な戦略は次のとおりである。
- テープに作成され、定期的にオフサイトに送信されるバックアップ
- オンサイトのディスクに作成され、オフサイトのディスクに自動的にコピーされるか、オフサイトのディスクに直接作成されるバックアップ
- オフサイトの場所へのデータのレプリケーション。これにより、データを復元する必要がなくなり(システムのみを復元または同期する必要がある)、多くの場合、ストレージエリアネットワーク(SAN)テクノロジを利用する。
- 管理データ(VM、テンプレート、ディスク)をプライベートクラウドセットアップの一部であるストレージドメインに複製するプライベートクラウドソリューション。これらの管理データは、OVF(Open Virtualization Format)と呼ばれるxml表現として構成されており、災害が発生すると復元できる。
- オンサイトとオフサイトの両方のデータセンターに複製するハイブリッドクラウドソリューション。これらのソリューションは、ローカルのオンサイトハードウェアに即座にフェイルオーバーする機能を提供するが、物理的な災害が発生した場合は、サーバーをクラウドデータセンターに立ち上げることもできる。
- データとシステムの両方をオフサイトで複製し、災害後(クラウドストレージに関連することが多い)でもシステムとデータへの継続的なアクセスを可能にする高可用性システムの使用
多くの場合、組織は、クラウドコンピューティングを介して、独自のリモートファシリティを使用するのではなく、外部委託のディザスタリカバリプロバイダーを使用してスタンバイサイトとシステムを提供することを選択できる。
組織は、システムの復旧の必要性に備えるだけでなく、そもそも災害を未然に防ぐことを目的とした予防措置も実施している。これらには次のものが含まれる。
- システムやデータのローカルミラー、およびRAIDなどのディスク保護テクノロジーの使用
- サージプロテクタ—繊細な電子機器への電力サージの影響を最小限に抑えるため
- 無停電電源装置(UPS)やバックアップ発電機を使用して、停電時にシステムを稼働させ続ける
- 警報器や消火器などの防火・消火システム
- ウイルス対策ソフトウェアおよびその他のセキュリティ対策
サービスとしてのディザスタリカバリ(DRaaS)
[編集]サービスとしてのディザスタリカバリDRaaSは、サードパーティであるベンダーとの取り決めである[28]。 一般に、サービスポートフォリオの一部としてサービスプロバイダーによって提供される。
ベンダーリストは公開されているが、ディザスタリカバリは製品ではなく、サービスである。いくつかの大規模なハードウェアベンダーが、非常に短時間でインストールして運用できるモバイル/モジュラー製品を開発している。
- シスコシステムズ[29]
- Google( Google Modular Data Center )は、この目的に使用できるシステムを開発した。[30][31]
- ブル(モブル)[32]
- HP(パフォーマンス最適化データセンター)[33]
- Huawei(コンテナデータセンターソリューション)、[34]
- IBM(ポータブルモジュラーデータセンター)
- Schneider-Electric(ポータブルモジュラーデータセンター)
- サンマイクロシステムズ(Sun Modular Datacenter)[35][36]
- SunGard可用性サービス
- ZTECorporation
関連項目
[編集]脚注
[編集]- ^ Systems and Operations Continuity: Disaster Recovery. Georgetown University. University Information Services. Retrieved 3 August 2012.
- ^ Disaster Recovery and Business Continuity, version 2011. Archived January 11, 2013, at the Wayback Machine. IBM. Retrieved 3 August 2012.
- ^ [1] 'What is Business Continuity Management', DRI International, 2017
- ^ M. Niemimaa (March 2017). “Information systems continuity process”. ACM.com (ACM Digital Library). 2020年12月21日閲覧。
- ^ “Defending The Data Strata”. ForbesMiddleEast.com (December 24, 2013). 2020年12月21日閲覧。
- ^ “ITIL glossary and abbreviations”. 2020年12月21日閲覧。
- ^ a b c d “Understanding RPO and RTO”. DRUVA (2008年). February 13, 2013閲覧。
- ^ a b “How to fit RPO and RTO into your backup and recovery plans”. SearchStorage. 2019年5月20日閲覧。
- ^ "Clock... modifications
- ^ Richard May. “Finding RPO and RTO”. 2016年3月3日時点のオリジナルよりアーカイブ。2020年12月21日閲覧。
- ^ “Data transfer and synchronization between mobile systems” (May 14, 2013). 2020年12月21日閲覧。
- ^ “Amendment #5 to S-1”. SEC.gov. 2020年12月21日閲覧。 “real-time ... provide redundancy and back-up to ...”
- ^ Peter H. Gregory (2011-03-03). “Setting the Maximum Tolerable Downtime -- setting recovery objectives”. IT Disaster Recovery Planning For Dummies. Wiley. pp. 19–22. ISBN 978-1118050637
- ^ William Caelli; Denis Longley (1989). Information Security for Managers. p. 177. ISBN 1349101370
- ^ “Catastrophe? It Can't Possibly Happen Here”. The New York Times. (January 29, 1995) 2020年12月21日閲覧. ".. patient records"
- ^ “Commercial Property/Disaster Recovery”. NYTimes.com (October 9, 1994). 2020年12月21日閲覧。 “...the disaster-recovery industry has grown to”
- ^ Charlie Taylor (June 30, 2015). “US tech firm Sungard announces 50 jobs for Dublin”. The Irish Times 2020年12月21日閲覧. "Sungard .. founded 1978"
- ^ Cassandra Mascarenhas (November 12, 2010). “SunGard to be a vital presence in the banking industry”. Wijeya Newspapers Ltd.. 2020年12月21日閲覧。 “SunGard ... Sri Lanka’s future.”
- ^ SecaaS Category 9 // BCDR Implementation Guidance CSA, retrieved 14 July 2014.
- ^ “Threat and Hazard Identification and Risk Assessment (THIRA) and Stakeholder Preparedness Review (SPR): Guide Comprehensive Preparedness Guide (CPG) 201, 3rd Edition”. US Department of Homeland Security (May 2018). 2020年12月21日閲覧。
- ^ “Post-Disaster Recovery Planning Forum: How-To Guide, Prepared by Partnership for Disaster Resilience”. University of Oregon's Community Service Center, (C) 2007, www.OregonShowcase.org. October 29, 2018閲覧。
- ^ “The Importance of Disaster Recovery”. October 29, 2018閲覧。
- ^ “IT Disaster Recovery Plan”. FEMA (25 October 2012). 11 May 2013閲覧。
- ^ The Professional Practices for Business Continuity Management, Disaster Recovery Institute International (DRI), 2017
- ^ Gregory, Peter. CISA Certified Information Systems Auditor All-in-One Exam Guide, 2009. ISBN 978-0-07-148755-9. Page 480.
- ^ “Five Mistakes That Can Kill a Disaster Recovery Plan”. Dell.com. 2013年1月16日時点のオリジナルよりアーカイブ。2012年6月22日閲覧。
- ^ J. D. Biersdorfer (April 5, 2018). “Monitoring the Health of a Backup Drive”. The New York Times 2020年12月21日閲覧。
- ^ “Disaster Recovery as a Service (DRaaS)”. 2020年12月21日閲覧。
- ^ “Info and video about Cisco's solution”. Datacentreknowledge (May 15, 2007). 2008年5月19日時点のオリジナルよりアーカイブ。2008年5月11日閲覧。
- ^ Kraemer (June 11, 2008). “IBM's Project Big Green Takes Second Step”. ChannelWeb. 2008年6月11日時点のオリジナルよりアーカイブ。2008年5月11日閲覧。
- ^ “Modular/Container Data Centers Procurement Guide: Optimizing for Energy Efficiency and Quick Deployment”. 2013年5月31日時点のオリジナルよりアーカイブ。2013年8月30日閲覧。
- ^ Kidger. “Mobull Plug and Boot Datacenter”. Bull. 2010年11月19日時点のオリジナルよりアーカイブ。2011年5月24日閲覧。
- ^ “HP Performance Optimized Datacenter (POD) 20c and 40c - Product Overview”. H18004.www1.hp.com. 2015年1月22日時点のオリジナルよりアーカイブ。2013年8月30日閲覧。
- ^ “Huawei's Container Data Center Solution”. Huawei. 2014年5月17日閲覧。
- ^ “Technical specs of Sun's Blackbox”. 2008年5月13日時点のオリジナルよりアーカイブ。2008年5月11日閲覧。
- ^ And English Wiki article on Sun's modular datacentre
参考文献
[編集]- ISO/IEC 22301:2012 (replacement of BS-25999:2007) Societal Security – Business Continuity Management Systems – Requirements
- ISO/IEC 27001:2013 (replacement of ISO/IEC 27001:2005 [formerly BS 7799-2:2002]) Information Security Management System
- ISO/IEC 27002:2013 (replacement of ISO/IEC 27002:2005 [renumbered ISO17799:2005]) Information Security Management – Code of Practice
- ISO/IEC 22399:2007 Guideline for incident preparedness and operational continuity management
- ISO/IEC 24762:2008 Guidelines for information and communications technology disaster recovery services
- The Professional Practices for Business Continuity Management, Disaster Recovery Institute International (DRI), 2017
- IWA 5:2006 Emergency Preparedness—British Standards Institution –
- BS 25999-1:2006 Business Continuity Management Part 1: Code of practice
- BS 25999-2:2007 Business Continuity Management Part 2: Specification
- BS 25777:2008 Information and communications technology continuity management – Code of practice—Others –
- "A Guide to Business Continuity Planning" by James C. Barnes
- "Business Continuity Planning", A Step-by-Step Guide with Planning Forms on CDROM by Kenneth L Fulmer
- "Disaster Survival Planning: A Practical Guide for Businesses" by Judy Bell
- ICE Data Management (In Case of Emergency) made simple – by MyriadOptima.com
- Harney, J.(2004). Business continuity and disaster recovery: Back up or shut down.
- AIIM E-Doc Magazine, 18(4), 42–48.
- Dimattia, S. (November 15, 2001). Planning for Continuity. Library Journal,32–34.