GitLab セキュリティコンプライアンスコントロール

セキュリティコントロールとは何か？

セキュリティコントロールは、組織の資産およびデータに対するリスクを軽減または緩和するために実装される保護策と対策です。

コントロールの説明：

コントロールの説明は、特定のセキュリティ要件または活動を定義する明確で簡潔な記述です。GCF で適切に書かれたコントロールの説明は、以下の特徴があります。

• 能動的でプロフェッショナルな言葉を使用する
• 何をすべきか、またはどのようなセキュリティ対策が整備されているかを記述する
• ベンダー固有の用語を含まず一般的に書かれている（再利用可能でベンダー中立性を維持するため）
• 監査人による実行とテストが可能である
• 目的を明確に伝える

例：

• EPM-12: ノートパソコンは、データ流出を緩和するためにポータブルストレージデバイスの使用を防止するようデフォルトで構成されており、例外は文書化されマネジメントによって承認されます。
• PSM-6: セキュリティ意識向上トレーニングは、入社時およびその後年 1 回チームメンバーが完了することが求められます。トレーニングは、組織のセキュリティポリシー、業界のセキュリティベストプラクティス、職務上の責任に関連する脅威の状況などのトピックをカバーします。
• AIM-6: AI システムは、精度、性能、品質基準が満たされることを保証するために、定義された基準とテスト方法論を使用して検証および妥当性確認されます。

コントロールのオーナーシップ

コントロールが効果的に運用されるためには、明確なオーナーシップとアカウンタビリティが確立される必要があります。コントロールの設計、運用、証跡収集について、2 つの主要な役割が責任を負います。

Control Owner

• コントロール全体およびそれが緩和するリスクに対するアカウンタビリティを持つ
• コントロール上の不備および監査での発見事項について、コントロールが監査対応可能な状態になるよう修正する責任を持つ
• コントロールの実行をスチュワードや責任者に委任することはできるが、最終的なアカウンタビリティを保持する
• コントロール設計の変更および主要な運用調整を承認する

Process Owner

• コントロールが実際にどのように運用されているかを理解する専門家
• Compliance チームと連携して証跡を提供し、コントロールの実装を説明する
• 技術的な詳細、システムアクセス、またはテストのための運用上の文脈を提供することがある
• 多くの場合、実際にコントロール活動を実行または監督する人物

注： Control Owner と Process Owner は同一人物の場合もあります。

GitLab Control Framework (GCF)

私たちは現在および将来のセキュリティコンプライアンスニーズに対して包括的なアプローチを取ります。古い大企業は各セキュリティコンプライアンス要件を個別に扱う傾向があり、その結果、独立した Security Compliance チームが内部チームに対して重複した複数のリクエストを送ってしまいます。たとえば、そのような会社では、特定のデータベースがどのように暗号化されているかについて、SOC2 要件に基づいて 1 人のデータベースエンジニアに証跡提出を求め、次に ISO 要件で再度求め、さらに PCI 要件で再度求めるといったことが起こります。

これに対処するため、私たちはGitLab Control Framework (GCF) と呼ばれる共通コントロールフレームワークを開発しました。このアプローチは以下のように可視化できます。

graph TD;
    SOC2_Requirement1-->Team1;
    SOC2_Requirement1-->Team2;
    SOC2_Requirement2-->Team1;
    SOC2_Requirement2-->Team2;
    PCI_Requirement1-->Team1;
    ISO_Requirement1-->Team2;

GitLab の効率性価値を踏まえ、私たちは複数の基礎要件に 1 つのコントロールで対応するセキュリティおよび AI コントロールのセットを作成しました。これにより、Security Compliance チームは Control Owner へのリクエストを減らし、さまざまな監査に必要なすべての証跡を一度に効率的に収集できます。このアプローチは以下のように可視化できます。

graph TD;
    SOC2_Requirement1-->Control1;
    PCI_Requirement1-->Control1;
    SOC2_Requirement2-->Control2;
    ISO_Requirement1-->Control2;
    Control1-->GCF;
    Control2-->GCF;
    GCF-->Team1;
    GCF-->Team2;

GCF の方法論

セキュリティコンプライアンスの目標と要件が進化するにつれて、セキュリティコントロールフレームワークに関連する要件と制約も進化してきました。私たちの GCF は、GitLab 独自のインフラストラクチャ、ビジネスモデル、セキュリティ体制のために特別に開発された独自のコントロールセットです。

GCF は以下の包括的な分析プロセスを通じて開発されました。

1. 私たちが維持し、また取得を目指している認証およびアテステーション（SOC 2、ISO 27001、ISO 42001、PCI DSS、FedRAMP など）からのコンプライアンス要件を分析
2. 業界のベストプラクティスに沿うことを保証するために、NIST Cybersecurity Framework (CSF)、NIST SP 800-53、Secure Controls Framework (SCF) などの業界フレームワークと比較
3. GitLab のオールリモート、クラウドネイティブ、AI 駆動型の DevSecOps 環境に合わせたカスタムコントロールドメインとコントロールを作成

このアプローチにより、無関係なコントロールを排除し、必要に応じて GitLab 固有のコントロールを追加しながら、すべてのコンプライアンス要件へのマッピングを維持できます。フレームワークはカスタマイズ可能でスケーラブルになるよう設計されており、追加の認証を追求する際やビジネスが進化する際に、新しいドメインやコントロールを作成できます。

GCF の範囲とアセスメントアプローチ

GCF には、外部認証の対象範囲を超えるコントロールが含まれており、コンプライアンス必須コントロールとリスク駆動型コントロールの両方をカバーします。毎年、コントロールをテストおよびモニターするためのアセスメントスケジュールが作成され、四半期ごとにアセスメントがグループ化されて Compliance チームのメンバーに割り当てられます。

• コンプライアンスコントロール： 外部認証に必須。少なくとも年 1 回テストされる
• リスクベースコントロール： システムの重要度（Tier 1/2）またはデータの機密性（RED/ORANGE）によって駆動される。キャパシティとリスク優先度に基づいてテストされる

GCF の構造とデータ

従来のコントロールフレームワークは通常、コントロール ID、説明、オーナーといった最小限の情報を追跡します。GCF はより包括的なアプローチを取り、コントロール実装の詳細、コントロールがマッピングされている要件、コントロールの範囲（コントロールに含まれる資産とプロセス）、その他関連する詳細を以下のコントロールフィールドに文書化することで、コントロールに関する文脈を提供する広範なデータをキャプチャします。

GitLab Control Framework は、私たちの GRC ソリューションである GAS (GitLab Assurance Solution) で管理されています。この一元化されたリポジトリにより、効率的なコントロール管理、コントロール関係マッピングの可視化、監査準備、GitLab のセキュリティ体制の継続的モニタリングが可能になります。

エージェントがマージリクエストのレビューまたは承認のコントロールを実施する場合は、次の情報を記録します。

• エージェントの識別情報。
• エージェントの設定。
• 説明責任を負うチームメンバー。

エージェントの識別情報、設定、または説明責任を負うチームメンバーを変更する場合は、このフレームワークに従ってください。コントロールの証跡は、変更や削除から保護し、Compliance チームがエージェントによるコントロールをサンプリングできるよう、人間によるレビューと承認をエージェントによるレビューと承認から区別できるようにしなければなりません。

GCF コントロールドメイン

業界フレームワークとコンプライアンス要件の分析を通じて、GitLab のセキュリティプログラムの構造と運用モデルに沿った論理的なファミリーにコントロールを整理するカスタムコントロールドメインを作成しました。

GCF コントロールフィールド

GCF は、コントロールごとに以下のフィールドを追跡し、コンテキストの提供、効率的な管理の実現、監査活動のサポートを行います。

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
    accTitle: Visualization of control hierarchy - Admin Access Example
    accDescr: Flowchart showing how a Level 1 admin access control cascades to Level 2 product and entity-level processes, then to Level 3 asset-specific implementations.

  L1["Level 1: IAM-4<br/>Administrator access is granted based on<br/>job roles and responsibilities"];
  L2A["Level 2: IAM-4-GitLab.com<br/>Shared admin access process for systems supporting GitLab.com"];
  L2B["Level 2: IAM-4-Dedicated<br/>Shared admin access process for systems supporting Dedicated"];
  L2C["Level 2: IAM-4-Entity<br/>Shared admin access process for entity-level systems"];
  L3A1["Level 3: GCP Admin"];
  L3A2["Level 3: Google Workspace Admin"];
  L3B1["Level 3: AWS Accounts Admin"];
  L3B2["Level 3: Password Manager Admin"];
  L3C1["Level 3: Okta Admin"];
  L3C2["Level 3: SIEM Admin"];
  L3C3["Level 3: Antivirus Admin"];
  L3C4["Level 3: MDM Linux Devices Admin"];
  L3C5["Level 3: MDM macOS Devices Admin"];
  L1-->L2A;
  L1-->L2B;
  L1-->L2C;
  L2A-->L3A1;
  L2A-->L3A2;
  L2B-->L3B1;
  L2B-->L3B2;
  L2C-->L3C1;
  L2C-->L3C2;
  L2C-->L3C3;
  L2C-->L3C4;
  L2C-->L3C5;

3. Security Compliance の追加手順

Security Compliance が外部認証スコープへの組み込み評価を実施したのち、チームはこれらのコントロールのウォークスルーやテストを実施することを選択する場合があります。

さらに、システムが環境に高いリスクをもたらす場合（スコープに関わらず）、チームは追加のコントロールテストを実施することもあります。Production Readiness Assessment Template（テンプレート開発中）を使用してこのテストを文書化することができます。

4. ドキュメント化

Security Compliance は以下のドキュメント更新を行います。

• GAS - 実施されたコントロールテストの結果は GAS Assessments に文書化される
• External Audit ‘Technical Scope’ - スコープへの変更はこの wiki ページに反映される
• 継続的コントロールモニタリング（CCM）のテスト Issue／スケジュール - スコープ変更に基づく CCM の必要な更新は、将来のテストが確実に実施されるよう行われる

参考資料

Security Compliance チームページに戻る

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