事業継続計画

目的

事業継続計画 (Business Continuity Plan: BCP) は、GitLab に対する潜在的な脅威からの予防と復旧の仕組みを構築するプロセスです。本計画は、業務中断が発生した場合でも、人員と資産が保護され、迅速に機能できるようにすることを目的としています。これには、通常のインシデントを超える、より広範な危機的状況への GitLab の対応方針も含まれます。

範囲

GitLab は、オールリモートという性質上、機器の局所的な故障、電力供給の障害、通信障害、社会不安、テロ攻撃、火災、自然災害といった業務中断の典型的な原因にさらされる可能性が低くなっています。こうした状況が、主要な人員やインフラストラクチャが長期間利用できなくなる事態など、より広範な危機に発展した場合も、本書に記載する同じプロセスを通じて管理します。事業継続計画の立案やテストの一環として、ビジネス影響度分析のシステムデータを活用することができます。

役割と責任

手順

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

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

危機的状況

危機とは、通常のインシデントよりも広範囲または長期間にわたる業務中断です。主要な人員が長期間対応できない事態、物理的な拠点に影響する自然災害、パンデミック、長期にわたるインフラストラクチャの停止などが該当します。主要な人員が対応できなくなる危機的状況については、GitLab の People Safety & Security (PSS) チームが、チームメンバーの所在地にかかわらず世界中の状況を監視し、影響を受ける可能性のある人を特定して直接連絡します。

GitLab は、危機専用のチームやプロセスを別途設けるのではなく、本計画に記載する同じエスカレーション、調整、コミュニケーションの体制を通じてこうした状況を管理します。危機が以下のビジネスへの影響の表に示す複数の領域に及ぶ場合、関係するステークホルダーは個別に対応するのではなく、連携して対応を調整します。

こうした状況では、GitLab は生命と健康の保護、中核的な事業運営の継続、情報セキュリティの順に優先します。危機の際に主要なコミュニケーション手段が利用できない場合は、代替の連絡手段を使用して連携を維持します。

エスカレーション

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

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

事業継続計画の発動条件

事業継続計画は、SIRT の標準オペレーションを超えるサポートが必要となった場合に [SIRT のインシデント対応手順]((/handbook/security/security-operations/sirt/sec-incident-response/)の中で発動されます。

発動時、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、エスカレーション経路、必要に応じたバックアップ運用の理解が含まれます。

5. 危機シナリオ

   • 主要な人員が長期間対応できない事態など、より広範な業務中断を伴うシナリオは、上記と同じテーブルトップ演習／シミュレーションの手法でテストします。

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

例外

本手順への例外は、情報セキュリティポリシー例外管理プロセスに従って追跡されます。

参考資料

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

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