Content last updated 2025-08-07

リスクベースのコントロールテスト

リスクベースのコントロールテストとは何か？

リスクベースのコントロールテストとは、GitLabのSaaSプラットフォームに対するSOC 2レポートおよび情報セキュリティマネジメントシステムの範囲を超えてコントロールが効果的に運用されていることを確認するためのコントロールテストおよびモニタリングを指します。これらのSaaSプラットフォームには、顧客が最も保証を必要とする領域に基盤的コントロールが整備されています。

リスクベースのコントロールテストは、プロアクティブで、組織にとって最も重大なリスクの緩和に焦点を当てており、セキュリティを維持するためのより効果的かつリソース効率の高い手段を提供します。GitLabの四半期リスク評価などの指標によって駆動される適応型のアプローチであり、セキュリティ体制を継続的に改善することを目指しています。

これに対して、SaaSプラットフォームのコントロールモニタリングは、外部監査人がテストするものに合わせており、より標準化されコンプライアンス駆動型で、特定の標準（SOC 2、ISO 27001、PCI DSSなど）の要件をコントロールが満たしていることを検証するために通常は固定間隔で実施されます。

外部認証の維持を超えてコントロールおよびシステムの健全性についてレポートすることで、組織全体のコントロールの健全性をより明確に可視化できます。

なぜ外部認証に含まれないコントロールをテストするのか？

セキュリティコンプライアンスチームとして、また第二防衛ラインの重要な一部として、私たちはセキュリティコントロールが会社全体で効果的に運用されていることを保証する責任を負い、適切な注意とリソース配分を検討できるようリーダーシップにコンプライアンス体制を伝える責任があります。私たちは認証維持にとどまらないリスク緩和の価値を提供する必要があります。

ハイリスクなコントロールに焦点を当てることで、コンプライアンスチームはリソースを最適化し、最も重要なリスクが効果的に管理されるようにしつつ、低リスク領域に不必要にリソースを割り当てないようにできます。

外部認証（SOC2、SOX、FedRampなど）は、フレームワークに関連する環境の特定の要素・部分を対象とします。

たとえばSOXの場合、これは財務・会計プロセスをサポートするシステムだけを意味します。SOC2の場合、これは顧客データが保存されるあらゆる場所、または顧客が使用する製品に直接関わる環境の部分を意味する可能性があります。GitLabの環境はこれらの環境セグメントよりもはるかに広範であり、リスクベースのコントロールテストによって、まだテストやモニタリングがされていないその他のリスクの高いシステムやプロセスに対するコントロールを測定・評価でき、コントロールの健全性をより詳細に把握できます。

テストするコントロールはどのように選択されるのか？

コントロールは、私たちが企業として既に行っているさまざまなリスク評価および影響評価に基づいて優先順位付けされます。

リスクベースのコントロールテストのコントロールを選択するにあたっては、以下の属性を考慮します。

テックスタックに基づくクリティカルシステムティア
内部ハンドブックの脅威インテリジェンスによるCrown Jewels
テックスタックによるデータ分類
SaaS／ベンダーに関連するリスク（たとえば最近の侵害事件）
特定されたリスクのカバレッジ（セキュリティリスクチームが特定したリスク、CIS Top 18 Critical Security Controls、既知のギャップなど）
NIST 800-53Bに基づくコントロールのベースラインレベル
コントロールが最後にテストされてからの経過時間
過去の観察事項
コントロールの性質（手動、半自動、自動など）
規制ガイダンス
人、プロセス、テクノロジーの変更

一部のコントロールは既にコントロールモニタリングプロセスを通じてテストされているため、これらのコントロールはテスト対象として優先されません。テスト戦略は、新たなリスクが出現したり、コントロールが効果的に機能していると判断されたりする際に時間とともに適応します。それは動的であり、内部の変更（システム更新など）や外部要因（新しい規制要件など）に基づくリスク変化を考慮します。

チームは四半期ごとに調整して、上記の基準に基づいて翌四半期にテストするコントロールを特定します。

リスクベースのコントロールテストでは、どれくらいの頻度でコントロールをテストしますか？

セキュリティコンプライアンスは四半期ごとにリスクベースのコントロールテストを実施しますが、特定のコントロールのテスト頻度もリスクに基づいて決定されます。理想的には、テストは過去のテスト結果と、コントロール環境全体への洞察を広げることのバランスを取ります。コントロールが効果的に設計・運用されており、プロセスがほとんどエラーの影響を受けないと判断した場合、毎四半期同じコントロールをカバーするのではなく、別のコントロール／システムをテストすることを選択する場合があります。