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

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

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

コントロールの説明:

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

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

例:

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

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

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

コントロールオーナー

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

プロセスオーナー

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

注: コントロールオーナーとプロセスオーナーは同一人物の場合もあります。

GitLab Control Framework (GCF)

私たちは現在および将来のセキュリティコンプライアンスニーズに対して包括的なアプローチを取ります。古い大企業は各セキュリティコンプライアンス要件を個別に扱う傾向があり、その結果、独立したセキュリティコンプライアンスチームが内部チームに対して重複した複数のリクエストを送ってしまいます。たとえば、そのような会社では、特定のデータベースがどのように暗号化されているかについて、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コントロールのセットを作成しました。これにより、セキュリティコンプライアンスチームはコントロールオーナーへのリクエストを減らし、さまざまな監査に必要なすべての証跡を一度に効率的に収集できます。このアプローチは以下のように可視化できます。

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

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

GCFの構造とデータ

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

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

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. セキュリティコンプライアンスの追加手順

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

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

4. ドキュメント化

セキュリティコンプライアンスは以下のドキュメント更新を行います。

• GAS - 実施されたコントロールテストの結果はGAS Assessmentsに文書化される
• External Audit ‘Technical Scope’ - スコープへの変更はこのwikiページに反映される
• Continuous Control Monitoring (CCM) Testing Issues/Schedule - スコープ変更に基づくCCMの必要な更新は、将来のテストが確実に実施されるよう行われる

参考資料

セキュリティコンプライアンスチームページに戻る

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