事業継続計画

Visibility: Audit

目的

事業継続計画（BCP）は、GitLab に対する潜在的な脅威からの予防および復旧システムを構築するプロセスです。この計画により、事業中断が発生した際でも、人員と資産が保護され、迅速に機能できるようにします。

適用範囲

GitLab はリモートオンリーという性質上、設備・電力供給・通信の局所的障害、社会不安、テロ攻撃、火災、自然災害など、典型的な事業中断要因の影響を受けにくい構造になっています。ビジネスインパクト分析のシステムデータは、事業継続計画の策定およびテストの一環として活用することができます。

役割と責任

手順

リモートワーカー向け BCP

GitLab のような完全リモート企業の場合、データとサービスをホストする企業とのサービスレベル契約という形で、シンプルなコンティンジェンシープランを策定することで十分です。GitLab のような完全リモート体制の優位性は、特定の人員やシステムが利用不能になっても、残りの会社が通常通り業務を継続できるという点にあります。GitLab の完全リモート企業としての構造上、インシデント対応プロセスが事業継続計画の大部分を占めています。インシデント対応と事業継続の関係についてはこちらを参照してください。

エスカレーション

GitLab 内でインシデントをエスカレーションする必要がある場合は、こちらの手順を参照してください。SIRT は、インシデント対応手順の継続的なカバレッジとクロストレーニングを確保するため、オンコールスケジュールを維持しています。

個別のシステム障害は、テックスタックに基づき、システムオーナーにエスカレーションしてください。

事業継続計画が発動する条件

事業継続計画は、[SIRT のインシデント対応手順]((/handbook/security/security-operations/sirt/sec-incident-response/)において、SIRT の標準業務範囲を超えたサポートが必要な場合に発動されます。

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

個別のシステム障害に関する BCP は、テックスタックに基づき、システムオーナーが管理します。

連絡メッセージテンプレート

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

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

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

システムオーナーは、事業継続の準備の一環として、ベンダーとのコミュニケーション計画を維持する責任を負います。これらの計画により、障害発生後にすべてのシステムとサービスが通常業務に復帰し、サービスプロバイダーとの連携のためのコミュニケーションプロトコルが確立され、必要に応じてクリティカルサービスの代替サプライヤーが特定されます。

根本原因分析

事業継続計画が発動するたびに、教訓を特定するための根本原因分析を実施します。根本原因分析では、イベントのトリガーをレビューし、問題の再発を防ぐための改善策を推奨します。また、特定の事業継続シナリオへの対応において改善の機会が特定された場合は、事業継続計画および適用される手順を更新し、その教訓を反映させます。

外部コミュニケーション

外部向けのコミュニケーションは、インシデントの範囲と影響が確認された後に実施します。手順はこちらを参照してください。

事業継続テスト

事業継続計画（BCP）を正式化した後、次の重要なステップは計画のテストです。テストにより計画の有効性を検証し、実際のシナリオで何をすべきかを参加者に教育し、計画を強化すべき領域を特定します。テストは少なくとも年に1回実施する必要があり、テスト前に明確に定義されたテスト目標と成功基準を設けてください。

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

計画のテスト

テストには多くの課題があり、時間とリソースへの投資が必要です。その点を踏まえると、組織全体を巻き込んだ本格的な訓練を実施するより、会議室でのテーブルトップテストを実施した方が合理的な場合があります。BCP の初期「ドライラン」は、BCP の構造化ウォークスルーテストを実施することで行えます。初回テストは業務中断を最小化するためにセクションごとに、通常業務時間外に実施します。その後のテストは通常業務時間中に実施できます。実際のテストランはいずれ実施できます。実施可能なテストの種類には、チェックリストテスト、シミュレーションテスト、並行テスト、完全中断テストなどがあります。

要件と考慮事項

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

• テストは中断による財務的・運営的・評判的影響の評価を含めること。
• テストには必要に応じて主要なベンダー、サプライヤー、パートナーも参加させること。
• 計画の有効性を評価し、弱点を特定するための指標を設けること。
• テスト結果は、テスト中に特定されたギャップや弱点を含め、正式に文書化すること。
• ギャップや弱点に対処するための計画を策定し、変更内容を反映するよう計画を更新すること。

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

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

1. データ損失・侵害

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

2. データ復旧テスト

   • このテストシナリオは、バックアップと復旧システムが意図した通りに機能することを確認するために使用されます。これを証明するために、大量データを失い、その後復旧を試みるテストを実施します。
   • 評価すべき要素には RTO が含まれ、チームが目標を達成したかどうかを確認します。
   • また、復旧中にファイルが損傷したか？クラウドに保存されたバックアップは正常かつ時間内に復旧されたか？なども確認します。

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

   • 災害や緊急事態の際に通信できることは非常に重要です。しかし、最も破壊的なイベントでは従来の連絡手段が使えなくなる場合があります。
   • これらのシナリオに備えて、BC計画では取るべき行動を概説する必要があります。GitLab のように世界中にチームメンバーがいる企業では、代替通信手段の信頼性と効率性をテストする必要があります。
   • GitLab の全チームメンバーの連絡先情報を定期的に更新し、タイムリーな通知を受け取れるようにすることで、災害シナリオのプロセスを合理化します。

4. 個別システム障害

   • システムオーナーは、システム障害が発生した場合でも主要な業務機能が維持できるよう計画を持つべきです。これには、主要なシステムのサービスレベル契約、エスカレーションパス、必要に応じたバックアップ運用の理解が含まれます。

この計画は年に1回、または重要な組織変更後にレビューおよび更新されます。

例外

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

参考資料

• ビジネスインパクト分析
• 災害復旧計画（DRP）
• セキュリティリスクチーム
• SIRT

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