事業継続計画

目的

事業継続計画 (Business Continuity Plan: BCP) は、GitLab に対する潜在的な脅威からの予防と復旧の仕組みを構築するプロセスです。本計画は、業務中断が発生した場合でも、人員と資産が保護され、迅速に機能できるようにすることを目的としています。

範囲

GitLab は、オールリモートという性質上、機器の局所的な故障、電力供給の障害、通信障害、社会不安、テロ攻撃、火災、自然災害といった業務中断の典型的な原因による影響を受けにくくなっています。事業継続計画の立案やテストの一環として、ビジネス影響度分析 のシステムデータを活用することができます。

役割と責任

手順

リモートワーカー向けの BCP

GitLab のようなオールリモート企業の場合、当社のデータやサービスをホストする企業との SLA という形式のシンプルなコンティンジェンシープランで十分です。GitLab のようなオールリモートのワークフォースの利点は、利用できない人員やシステムのクラスタがあっても、会社の残りの部分は通常どおり稼働し続けられる点にあります。GitLab はオールリモート企業として構築されているため、インシデント対応プロセスが当社の事業継続計画の大部分を占めています。インシデント対応とその事業継続との関係性についての詳細はこちらを参照してください。

エスカレーション

インシデントを GitLab 内でエスカレートする必要がある場合の手順はこちらで確認できます。SIRT はインシデント対応手順を継続的にカバーし、相互トレーニングを行うため、オンコールスケジュールを維持しています。

個別のシステム停止については、Tech Stack に従って各システムオーナーへエスカレートしてください。

事業継続計画の発動条件

事業継続計画は、SIRT の標準オペレーションを超えるサポートが必要となった場合に SIRT のインシデント対応手順 の中で発動されます。

発動時、SIRT はトリアージのため #BCP_Events チャンネルにメンションします。

個別システム停止に対する BCP は、Tech Stack に従って各システムオーナーが管理します。

関係者連絡用メッセージテンプレート

セキュリティインシデントを起因として BCP が発動された場合、以下のテンプレートを使用してすべてのメンバーをタグ付けし、#BCP_Events にスレッドを作成します。

@here、GitLab の事業継続計画が SIRT インシデントへの対応として発動されました。タグ付けされたステークホルダーは、インシデント詳細を確認のうえ、対応の要否を判断してください。

ベンダーとのコミュニケーションおよびサービス復旧計画

システムオーナーは、事業継続準備の一環として、ベンダーとのコミュニケーション計画を維持する責任を負います。これらの計画は、停止からの復旧後にすべてのシステムとサービスが通常運用に戻ること、サービスプロバイダーとの連携プロトコルを確立すること、必要に応じて重要サービスの代替供給元を特定することを保証するものです。

根本原因分析

事業継続計画が発動された際には必ず、教訓を特定するために根本原因分析を実施します。根本原因分析では、事象のトリガーをレビューし、問題の再発を防ぐための是正策を提案します。さらに、特定の事業継続シナリオへの対応について改善の機会が見つかった場合は、それらの教訓を反映する形で事業継続計画および関連手順を更新します。

外部コミュニケーション

外部コミュニケーションは、インシデントの範囲と影響が判明した時点で発信します。手順はこちらで確認できます。

事業継続テスト

事業継続計画 (BCP) を策定した後の次の重要なステップは、その計画をテストすることです。テストにより、計画の有効性を検証し、実際のシナリオで何をすべきかを参加者に周知し、計画の強化が必要な領域を特定できます。計画のテストは少なくとも年に 1 回実施しなければならず、テストに先立って明確なテスト目標と成功基準を定義しておく必要があります。

なお、GitLab の運用構造は完全リモート企業であるため、インシデント対応プロセスが事業継続計画の大部分を構成しています。インシデント対応テストのスコープは、インシデントによって影響を受ける可能性のある他の関係者を含めるように拡張することができ、BCP テスト活動の証跡として活用できます。

計画のテスト

テストは多くの課題を伴い、時間と人的リソースの投資を必要とします。そのことを踏まえると、組織全体を巻き込んだ本格的なドリルではなく、会議室でテーブルトップテストを実施するほうが現実的な場合があります。BCP の構造化ウォークスルーテストを実施することで、計画の初期的な「ドライラン」を行えます。最初のテストはセクション単位で、業務への支障を最小化するため通常業務時間外に実施します。その後のテストは通常業務時間中に実施できます。最終的には実地でのテストも実施できます。実施可能なテストの種類には、チェックリストテスト、シミュレーションテスト、パラレルテスト、フル中断テストなどがあります。

要件と考慮事項

BCP テストを実施する際は、以下の基準を満たす必要があります。

• テストでは、業務中断が財務、運用、レピュテーションに与える影響の評価を含めるべきです。
• 必要に応じて、主要なベンダー、サプライヤー、パートナーの関与をテストに含めるべきです。
• 計画の有効性を測定し、弱点を特定するための指標を整備するべきです。
• テスト結果は、テストで特定されたギャップや弱点を含めて正式に文書化しなければなりません。
• 特定されたあらゆるギャップや弱点に対処する計画を策定し、変更内容を文書化するために計画を更新します。

事業継続計画テストのシナリオ

前項で詳しく説明したように、プランレビュー、テーブルトップテスト、シミュレーションテストなど、いくつかの種類のテストがあります。 実施可能なテストシナリオの例を以下に示します。

1. データ損失/侵害

   • 今日の職場で最も一般的な災害の一つです。データ損失や侵害の原因は次のようなものが考えられます。
     • ランサムウェアやサイバー攻撃
     • 意図せず削除されたファイルやフォルダ
     • サーバー/ドライブのクラッシュ
     • データセンターの停止
   • データはミッションクリティカルであり、損失は販売や物流アプリケーションへの大きな影響など、深刻な結果をもたらす可能性があります。
   • 目標は、できるだけ早くデータへのアクセスを回復することです。バックアップからの復元がその解決策です。しかし、誰がその責任を負うのでしょうか? このケースのコミュニケーションプランは? 優先順位は? 直ちに連絡すべき相手は? 関与するベンダーはいますか? これらをはじめとする多くの質問が、このテストを通じて回答されます。

2. データリカバリテスト

   • このテストシナリオは、バックアップおよびリカバリシステムが意図したとおりに機能することを確認するために使用します。これを証明するため、大量のデータを失い、それを回復するテストを実施します。
   • 評価する要素には、RTO や、チームがその目標を達成したかが含まれます。
   • また、リカバリ中にファイルへの損傷はなかったか、バックアップはクラウドに保管されていたか、それが正常かつ時間どおりにリカバリされたかなども記録します。

3. 緊急時のコミュニケーション

   • 災害や緊急時にコミュニケーションを取れることは極めて重要です。しかし、最も破壊的な事象は、従来のコミュニケーション手段を奪う可能性があります。
   • こうしたシナリオに対しては、BCP で取るべきアクションを示しておく必要があります。世界中にチームメンバーがいる GitLab のような企業では、代替の通信手段について信頼性と効率性をテストしておくべきです。
   • すべての GitLab チームメンバーの連絡先情報を定期的に更新し、適切なタイミングで通知を受け取れるようにすることで、災害シナリオのプロセスを円滑化します。

4. 個別システムの停止

   • システムオーナーは、システム停止が発生した場合にも主要な業務機能が継続できる計画を持つべきです。これには、主要なシステムの SLA、エスカレーション経路、必要に応じたバックアップ運用の理解が含まれます。

この計画は、年次または組織に重大な変更があった後にレビューされ、更新されます。

例外

本手順への例外は、Information Security Policy Exception Management Process に従って追跡されます。

参考資料

• ビジネス影響度分析
• 災害復旧計画 (DRP)
• Security Risk Team
• SIRT

ページのソースコードを見る - ページの編集 - please contribute.