クリティカルシステム階層化方法論
This is a Controlled Document
In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.目的
クリティカルシステム階層化方法論の目的は、GitLab の SaaS サブスクリプション（GitLab.com または GitLab Dedicated の提供）への影響に基づいてシステムを分類することにより、GitLab を支援することです。システムを特定の階層に分類することで、GitLab はリスク軽減活動を適切に優先順位付けし、内部統制を調整できます。
範囲
クリティカルシステム階層化方法論は、Tech Stack（社内のみ）で追跡される GitLab 全体で使用されるすべてのシステムに適用されます。
役割と責任
| 役割 | 責任 |
|---|---|
| Security Risk Team | クリティカルシステム階層化方法論を所有し、Business Impact Analysis を通じて新しいシステムの Critical System Tier を指定します。 |
| IT Compliance | 新しいシステムが Tech Stack に追加されたときに Security Risk チームと連携して Critical System Tier の定義をサポートします。 |
| システムの Business/Technical Owner | 正確な階層が指定されるように、所有するシステムに関する完全かつ正確なデータを提供します。 |
クリティカルシステム階層化手順
GitLab において重要なシステムが何であるかを定義することは、当社の環境の性質と、ビジネス活動を遂行するために使用される多くのシステム全体に存在する統合の数を考えると、複雑になり得ます。GitLab の ビジネスインパクト分析（BIA） 手順は、Security Risk チームによる新しいシステムの Critical System Tier 指定を可能にします。Critical System Tier の指定に使用される BIA の質問は次のとおりです。
- システムの中断（システムが利用不可）の影響は何ですか?
- システムの中断の潜在的な影響を説明してください。影響を受ける GitLab チーム（複数可）を指定してください。
Security Risk チームは、Business Owner からの回答とシステムが提供するサービスに関する自身の理解に基づいて、新しいシステムに Critical System Tier を判断的に指定します。各階層を区別するために使用されるガイドラインは、次のセクションで説明されています。
Critical System Tier の指定
システムは、次のマトリックスに基づいて Critical System Tier が指定されます。
| Critical System Tier (CST) 1 | CST の説明 | 例 |
| Tier 1 ミッションクリティカル2,3 | 中断または侵害が、GitLab SaaS サブスクリプションおよびお客様データの可用性/セキュリティに即時かつ重大な影響を与えます（定義については Data Classification Standard を参照）。 | GitLab.com、Google Cloud Platform、Elastic |
| Tier 2 ビジネスクリティカル4 | 中断が主要なビジネス機能や能力の遂行に影響を与えます。 | Okta、Salesforce、Workday |
| Tier 3 ビジネスオペレーショナル | 中断が標準的なビジネスプロセスを完了する上での効率や費用に影響します。 | DocuSign、Figma、Tableau |
| Tier 4 アドミニストレーティブ | 中断が個々の GitLab チームメンバーの生産性/ウェルビーイングに影響します。 | Vimeo、Donut |
Note: 1 階層化方法論の延長として、Data Classification Standard は、各データ分類レベルに対する 特定の Security and Privacy コントロール要件を規定しています。これらの要件は、システムの階層に関係なく、システムのデータ分類に基づいて遵守されるべきです。
Note: 2 Data Classification Standardで定義される RED Data を扱うシステムはすべて、Tier 1 ミッションクリティカル とみなされます。RED データの漏えいや損失は、どの分類レベルよりもビジネスへの影響が大きいためです。
Note: 3 Third Party Sub-Processorとして指定されたシステムはすべて、Tier 1 ミッションクリティカル とみなされます。これらのプロバイダーは、GitLab のデータ処理契約に基づき、GitLab に代わってお客様のデータを処理するためです。
Note: 4 デフォルトでは、SOXの対象範囲のシステムは、最低でも Tier 2 ビジネスクリティカル システムになります。その中断により、GitLab が主要な財務業務を遂行する能力や、それらについて正確に報告する能力に影響が及ぶ可能性があるためです。
Critical System Tier は、GitLab のお客様にサービスを提供するために重要なシステムのリスク軽減活動の優先順位付けを支援します。GitLab のコアサービス提供は SaaS です。したがって、中断発生時に GitLab SaaS サブスクリプションおよびお客様データの可用性/セキュリティに即時かつ重大な影響を与えるシステムが優先事項となります。これらが Tier 1 ミッションクリティカル システムです。
GitLab はなぜこの方法論を必要とするのですか?
GitLab 全体で使用されるシステムを階層化することにより、チームメンバーは特定のシステムに関連する作業の優先順位付けに関する意思決定を行うことができます。たとえば、多くのシステムにわたって複数のリスクが特定され、是正が必要な場合、チームメンバーは指定された Critical System Tier を活用して是正活動の優先順位付けに関する意思決定を行うことができます。この方法論はまた、GitLab に組織全体で最も重要なシステムを容易に特定するメカニズムを提供し、これによりチームはそれらのシステムを積極的に保護および確保することができます。
Critical System Tier の維持
既存のシステムの Critical System Tier は定期的に検証されます。システムの指定された階層は、GitLab で使用されるすべてのシステムの Single Source of Truth である Tech Stack（社内のみ）で確認できます。
例外
この手順に対する例外は、Information Security Policy Exception Management Process に従って追跡されます。
参考文献
5d840611)