CISSP合格ノート・CBK#08 事業継続計画と災害復旧計画 (Business Continuity Planning &Disaster Recovery Planning)

CBK#08 事業継続計画と災害復旧計画

go to menu page

CBK#08 事業継続計画と災害復旧計画
(Business Continuity Planning &Disaster Recovery Planning)

10.1. 事業継続計画 (ＢＣＰ: Business Continuity Planning)

ＢＣＰ定義：

├ あらかじめ決められた期間内にクリティカルなビジネス機能を回復させることにより、事業運営の復旧を円滑に行い、災害の全体的な影響を減らす。
├ 損失を最小限にとどめる。
└ できるだけ早期に、損害を受けた設備を修復または交換する。

ＢＣＰ要件：

├ 復旧手順の文章化、試験、訓練により、危険の際に生じる混乱を避けること。
├ 災害を宣言するための明確な指針。
├ クリティカルなサービスをタイムリーに再開するために必要な指示を与えること。
├ クリティカルなシステムとサポート機能の格納、防護および復旧手順を文章化すること。
├ 主要拠点が深刻な機能停止に至った場合に、代替拠点でクリティカルな業務を再開するために必要な処置やリソースを記述すること。
└ 復旧手順を文章化して、事情に通じている人員が手順を実行できるようにすること。

ＢＣＰの諸段階：

1. プロジェクトの管理と開始
2. 事業影響度分析（ＢＩＡ）
3. 復旧戦略
4．計画の設計と作成
5．実装
6．試験
7．維持管理、認識、訓練

復旧のプロセス：

    1． 災害への対処
    2． クリティカルな機能の修復
    3． クリティカルでない機能の修復
    4． 回復および修復
    5． 本来拠点の復帰

主要な要素:

├ 範囲と計画の開始 (Scope and Plan Initiation)
├ ビジネス影響分析 (Business Impact Assessment)
├ 事業継続計画作成 (Business Continuity Plan Development)
└ 計画の承認と実施 (Plan Approval and Implementation)

10.1.1. 範囲と計画の開始 (Scope and Plan Initiation)

ＢＣＰプロセスを開始する。

計画の範囲策定を伴う。

├ 役割と責任 (Roles and Responsibilities) ：
├ ＢＣＰ委員会 (The BCP Committee):
├ 委員会は、計画の策定、実行、テストを行う責任を負うために作られる。
└ 上級管理職や全てのファンクショナルビジネスユニット、情報システムおよびセキュリティ管理者の代表から成る。
└ 上級管理職の役割:
└ 計画の4 段階の全てに関して最終的な責任を負う。

10.1.2. ビジネス影響分析 (ＢＩＡ: Business Impact Assessment)

├ 事業部門において中断イベントによる影響を把握するためのプロセスである。
├ 影響は財務に関わるもの(数量的)か、運営に関わるもの(質的、例えば顧客に対応することができない等)である。
├ 脆弱性評価はＢＩＡプロセスの一部であることが多い。
└ 企業の存続にとって致命的となるシステムを特定し、災害や中断イベントによって引き起こされる許容休止時間を見積もる。

ＢＩＡの主要な３つのゴール：

臨界優先順位 (Criticality Prioritization)：

└ 致命的となる事業部門のプロセス全てを確認して優先順位をつけ、中断イベントの影響を見積もらなければならない。

ダウンタイムの見積もり (Downtime Estimation):

└ 存続している企業であり続け、事業が許容できるＭＴＢ(Maximum Tolerable Downtime、 最大許容ダウンタイム)を見積もらなければならない。

リソース要件 (Resource Requirements)：

└ 重要なプロセスに必要なリソースをこの段階で明確にする。 最も時間に依存するプロセスに最大のリソース割り当てを行う。

ＢＩＡの４つのステップ：

必要な評価材料を収集する:

└ 許容レベルの運営を続けるためにどの事業部門が重要であるか見定める。

脆弱性評価を実施する:

├ 完全なリスク評価より小規模で、ＢＣＰもしくはＤＲＰのための情報を提供することに焦点を絞っている。
├ 機能は損失影響分析を実施することである。
└ 重要なサポート分野を定義しなければならない。

収集した情報を分析する:

文章化と提言:

└ 調査内容をもとに評価しを報告するとともに、提言する。

10.1.3. 事業継続計画の整備 (Business Continuity Plan Development)

├ ＢＩＡで収集した情報を用いて実際の事業継続計画を整備すること。
└ これには計画の実施、テスト、進行中の計画の保守が含まれる。

主な２つのステップ：

継続戦略を定義する：

└ ビジネスは災害による中断イベントをどのように管理すると想定されるか。

継続戦略を文書化する：
└ 結果を文書化する。

10.1.4. 計画の承認と実施 (Plan Approval and Implementation)

└ 最終的なシニアマネジメントの署名をもらい、全社レベルで計画を認知し、必要に応じてメンテナンス手順を実施することが含まれる。

10.2. 災害復旧計画 (ＤＲＰ: Disaster Recovery Planning)

├ 情報システムリソースに多大な損失を与える中断イベントについて、事前、事中、事後に取るべきである首尾一貫した行動の包括的なステートメント。
└ 主要な目的は、代替サイトで重要なプロセスを実行し、迅速な復旧手順によって、組織にとっての損失が最小になるようなタイムフレームで本来のサイトと通常のプロセスに戻ることができるようにすることである。

災害復旧プロセスのフェイズ:

├ データ処理継続計画 (Data Processing Continuity Planning)
└ データ復旧計画のメンテナンス (Data Recovery Plan Maintenance)

10.2.1. データ処理継続計画 (Data Processing Continuity Planning)

代表的な代替処理タイプ：

└ 相互扶助契約 (Mutual aid agreements / Reciprocal agreements)：
├ 似たようなコンピューティングニーズを持った他の企業との契約。
├ 利点は低コスト
└ 欠点は、イベントの最中にそれぞれの組織が完全な運営プロセスを行えるほどの、余分なキャパシティを持っていることが非常にありそうにないことであるという点である。

10.2.2. サブスクリプションサービス (Subscription services)

ホットサイト (Hot site)：

├ 完全に設定したコンピュータ設備で、電力、暖房、換気、空調(HVAC)、機能しているファイルサーバやプリンタサーバ、ワークステーションを持つ。
├ 利点は２４時間/７日利用可能なことである。
└ 欠点は費用がかかること、サービスプロバイダがキャパシティ以上のものを売るかもしれないこと、情報が２カ所に保存される際のセキュリティの危険、コントロールを２回行われなければならないため管理リソースを多く必要とすることである。

ウォームサイト (Warm site):

├ 電力、暖房、換気、空調とコンピュータを持つ設備であるが、アプリケーションがインストールされていない場合がある。
├ 利点はコストがホットサイトよりかからないこと、サイト(場所)の選択が柔軟に行えること、ホットサイトと比較して管理リソースが少なくて済むことである。
└ 欠点は、新しいサイトで生産処理を始めるための時間と労力の差である。

コールドサイト (Cold site):

├ 緊急時に設備を持ち込むことができるが、サイトにハードウェアは全くない。
├ 利点は低コスト。
└ 欠点は災害が起こった際に機能しない可能性があることである。

10.2.3. 複数センター (Multiple centers)

├ 処理が複数のセンターに分散しており、冗長性に関して分散アプローチを取り、利用可能なリソースを共有する。
├ 利点は低コスト。
└ 欠点は大きな災害では複数サイトの処理能力を簡単に凌駕してしまうことである。

10.2.4. サービスビューロー (Service Bureaus)

├ 代替バックアッププロセスサービスの全てを提供してもらうことをサービスビューローと契約する。
├ 利点 ⇒ 迅速な反応と可用性である。
└ 欠点 ⇒ 大規模な災害時に費用とリソースの取り合いになることである。

データセンターバックアップの他の選択肢:

├ ローリング / モバイルバックアップサイト (Rolling / Mobile backup sites)
├ 組織内もしくは外部からの代替ハードウェア供給
└ プレハブビルディング

移行処理における耐障害性と冗長性レベルに使用される３つのコンセプト：

Electronic vaulting:

├ バックアップデータをオフサイトの場所に転送すること。
└ これは主に代替サイトのサーバに、コミュニケーションラインを通じてデータのダンプを行うバッチ処理である。

リモートジャーナリング (Remote journaling):

├ 代替サイトにトランザクション処理を平行して行うこと。
└ データが生じるたびに、リアルタイムのデータがコミュニケーションラインを使って送信される。

データベースシャドーイング (Database shadowing):

└ リモートジャーナリングのライブ処理を使用するが、複数のサーバにデータベースセットを複製することによって、さらなる冗長性を持たせる。

10.2.5. データ復旧計画のメンテナンス (Data Recovery Plan Maintenance):
計画を最新で適切な物に保つ。

10.2.6. ＤＲＰのテスト (Testing the DRP: Disaster Recovery Plan):
テストのタイプ：

チェックリスト (Checklist)：

└ 計画のコピーがマネジメントにレビューのために配布される。

構造化ウォークスルー (Structured Walk-Through)：

└ ビジネスユニットのマネジメントが計画のレビューのために集まる。

シミュレーションテスト (Simulation Test)：

└ 全てのサポート要員が訓練の遂行セッションで集まる。

パラレルテスト (Parallel Test)：

└ 重要なシステムが代替サイトで実行される。

完全中断テスト (Full-Interruption Test)：

└ 通常の生産が中断され, 実際の災害復旧プロセスが行われる。

災害復旧プロセスの主要な要素：

復旧チーム(The recovery team)：

├ 災害の宣言時に復旧手順を実行する任務が明確に定義される。
└ 主要な職務はあらかじめ決められた重要なビジネス機能を代替のバックアップ処理サイトで行うことである。

10.2.7. 救助チーム (The Salvage Team):

├ 本来のサイトを通常業務環境の状態に戻すために派遣される。
└ このチームは多くの場合、本来のサイトを再開できるかどうかの宣言をする権限を与えられる。

10.2.8 通常業務再開 (Normal Operations Resume):

├ 最小の混乱やリスクで生産業務を代替の場所から本来の場所に戻す全ての手順。
└ 全ての業務が本来のサイトで完全に生産モードに戻るまで緊急事態が終わったとは言えない。

10.2.9. その他の復旧問題 (Other recovery issues):

├ 外部のグループとのインターフェイス
├ 従業員関係
├ 不正行為と犯罪
├ 金銭出費
└ メディア関係

go to menu page

ここまで

narto.hatenablog.com