SOC 2準拠を数分で実現するGitLabのコンプライアンスフレームワーク

コンプライアンスは、重要だと誰もが認めながら、誰も好んで取り組みたがらない領域です。その実態はスプレッドシートとスクリーンショット、そして近づいてくる監査への漠然とした不安のなか。GitLabのカスタムコンプライアンスフレームワークは、ここに別のアプローチを持ち込みます。プロジェクトがあるべき姿を文書化するのではなく、コントロールを一度定義すれば、あとはプラットフォームが実際の状態を継続的に検証してくれます。

本記事では、コンプライアンス遵守がなぜ重要なのか、テンプレートを使ってSOC 2フレームワークを数分で立ち上げる方法、遵守状況を継続的に監視する方法、ポリシーによってコンプライアンスを強制する方法、そしてすぐに使える標準テンプレートのラインナップを紹介します。あわせて、AI固有のコンプライアンステンプレートが今後どこへ向かうのかにも触れます。実際の動作は、以下の動画でご確認ください。

プランに関する注記: コンプライアンスフレームワークはPremiumとUltimateでご利用いただけます。フレームワークの要件とコントロール、および遵守状況のレポートとコンプライアンスステータスレポートを支えるチェック機能はUltimate限定。本記事の内容はGitLab.com、GitLab Self-Managed、GitLab Dedicatedのいずれにも当てはまります。

コンプライアンス遵守が重要な理由とカスタムフレームワークの役割

SOC 2、ISO 27001、PCI DSS、FedRAMPといった規制上・契約上の義務が存在するのは、顧客もパートナーも規制当局も、ソフトウェアが責任ある方法で開発・提供されているという裏付けを必要としているからです。これを満たせないことは、単なる書類上の問題では済みません。商談が止まり、制裁金が科され、製品リリースが遅れ、信頼が損なわれます。しかもコンプライアンスは一度きりのイベントではありません。監査時点では準拠していたプロジェクトも、誰かがスキャナーを無効化した瞬間、ブランチ保護を外した瞬間、必要な承認を経ずにマージした瞬間に、ずれ始めます。

このギャップを埋めるために設計されたのが、カスタムコンプライアンスフレームワークです。GitLabにおけるコンプライアンスフレームワークとは、特定のコンプライアンス義務を負うプロジェクトや、追加の監督が必要なプロジェクトを識別するために、トップレベルグループ上に作成するラベルです。ラベル単体でも、整理と可視化には十分に役立つでしょう。さらにUltimateでは、フレームワークに要件を持たせられます。要件はコントロールで構成され、コントロールとは、そのフレームワークが適用されたすべてのプロジェクトの設定や挙動に対する自動チェックのことです。

静的アプリケーションセキュリティテスト（SAST）が動いているか、デフォルトブランチが保護されているか、マージリクエストに2件の承認が必要になっているか。こうした確認をエンジニアに依頼する代わりに、GitLabがスケジュールに沿って、また関連するプロジェクト設定が変更されるたびに、自動で評価します。コンプライアンスは、監査前にかき集めるスナップショットから、一年を通じて見守れるものへ。フレームワークはトップレベルグループで作成し、配下のすべてのサブグループとプロジェクトに継承されます。複数の標準を同時に満たす必要があるプロジェクトには、最大20個のフレームワークを適用できます。

これによって日々の負荷はいくつかの点で変わります。コンプライアンスが開発ワークフローの手前へと左シフトし、監査準備は証跡を再構成する作業からレポートを書き出すだけの作業になり、一貫性は善意ではなくプラットフォームによって担保されるようになります。

テンプレートを適用してSOC 2に準拠する

フレームワークを手作業で構築するとなると、要件とコントロールを1つずつ定義していくことになります。SOC 2のように多数のコントロールにマッピングされる標準では、この作業は反復的で、ミスも起きやすいもの。テンプレートはこの問題を解決します。名前、説明、色、要件、コントロールまですべて設定済みの完成されたフレームワークを、1ステップで導入できるようにするためです。

コンプライアンス遵守テンプレートプロジェクトには、こうしたフレームワークがJSONファイルのライブラリとして公開されており、soc2.jsonもそのひとつです。

テンプレートをグループに取り込む方法は2つあります。

方法A: コンプライアンスセンターでテンプレートから作成する

UIから離れることなく、組み込みテンプレートを使ってフレームワークを直接作成できます。

1. トップレベルグループに移動します。
2. サイドタブでセキュリティ > コンプライアンスセンターを選択します。
3. 新規フレームワークボタンをクリックします。
4. テンプレートから作成を選択します。
5. 下にスクロールしてSOC 2テンプレートを表示し、詳細を表示を選択して、そのテンプレートが実装するコントロールを確認します。
6. テンプレートを使用ボタンを押してSOC 2テンプレートを適用します。必要に応じて名前、説明、色をカスタマイズしてください。完了したら次へを選択します。
7. 含まれている要件とコントロールをプレビューします。
8. フレームワークを必要とするグループ/プロジェクトに適用します。
9. フレームワークの作成ボタンを押します。

これでフレームワークが作成され、選択したグループ/プロジェクトに適用されます。

方法B: SOC 2のJSONテンプレートをインポートする

製品内のテンプレートピッカーが搭載されていないGitLabバージョンをお使いの場合や、テンプレートをバージョン管理下に置いて先に手を加えたい場合は、JSONを直接インポートしてください。

1. コンプライアンス遵守テンプレートプロジェクトに移動し、soc2.jsonをダウンロードします。
2. トップレベルグループに移動します。
3. セキュリティ > コンプライアンスセンターを選択します。
4. フレームワークタブで新規フレームワークを選択し、続いてフレームワークのインポートを選択します。
5. ローカルシステムからsoc2.jsonファイルを選択します。
6. インポートが成功すると、フレームワーク一覧にSOC 2フレームワークが表示されます。

フレームワークは、プロジェクトに紐づけて初めて機能します。実際に使用するグループ/プロジェクトへの適用を忘れないでください。

注記: 同じ名前のフレームワークがすでに存在する場合、インポートはUnable to determine the correct upload URLエラーで失敗します。既存のフレームワークの名前を変更するか、削除してから実行してください。

フレームワークを編集してプロジェクトに適用する

作成したフレームワークは編集できるほか、別のグループ/プロジェクトへ追加で適用することも可能です。

1. セキュリティ > コンプライアンスセンターでフレームワークタブを開きます。
2. SOC 2フレームワークにカーソルを合わせ、Edit Frameworkを選択します。
3. 要件とコントロールセクションのアクションで、... > 編集を選択します。
4. 要件やコントロールに必要な変更を加えます。
5. スコーピングセクションで、SOC 2の対象となるグループ/プロジェクトを選択します。
6. Update Frameworkを選択します。

グループ内の新規プロジェクトすべてにSOC 2を自動的に継承させたい場合は、基本情報セクションでそのフレームワークをグループのデフォルトに設定します。以降、新規作成およびインポートされたすべてのプロジェクトにフレームワークが適用されます。

SOC 2テンプレートが実際にチェックする内容

適用されたSOC 2フレームワークは、GitLabのコントロールを該当するトラストサービス規準（TSC）にマッピングします。主なものは次のとおりです。

フレームワークがプロジェクトに適用されると、GitLabはコンプライアンススキャンを実行し、各コントロールの合否のレポートを開始します。手作業での証跡収集は不要です。

コンプライアンスの状況を継続的に把握する

フレームワークの適用は価値の半分にすぎません。残りの半分は、いま自分たちがどの位置にいるのかをいつでも把握できることです。それを担うのがコンプライアンスステータスレポート（Ultimate）で、トップレベルグループのセキュリティ > コンプライアンスセンター > ステータスから確認できます。

このレポートには、フレームワークのコントロールにプロジェクトが準拠している/していない直近のケースが表示されるため、ギャップを素早く見つけて塞げます。各行から読み取れる情報は次のとおりです。

• ステータス: 要件が準拠しているか違反しているか
• 要件: 要件のうち、失敗した具体的なコントロール（例:「2件以上の承認」）
• フレームワーク: そのコントロールが属するフレームワーク（例: SOC 2）
• プロジェクト: 違反が検出された場所
• 最終スキャン: そのギャップが最初に記録された日時
• 修正の提案: 問題を解決するための情報

プロジェクト、フレームワーク、要件で絞り込めるほか、プロジェクトのコンプライアンス詳細ビューへ直接ジャンプしたり、監査担当者から証跡を求められた際にレポート全体をエクスポート（添付ファイルとして受信トレイに配信）したりもできます。

裏側では、レポートを更新するスキャンが自動的にトリガーされます。フレームワークがプロジェクトに追加されたとき、関連するフレームワークの要件が変更されたとき、そして12時間ごとの定期実行。結果は通常、スキャン実行から5〜10分後に反映されます。つまり、コンプライアンスのずれが表面化するまでの時間は、翌年の監査から数時間へ。レポートを閲覧するには、管理者であるか、対象グループでセキュリティマネージャーまたはオーナーのロールを持っている必要があります。

ポリシーでコンプライアンスを強制する

レポートは、何かがおかしくなったときにそれを知らせてくれます。一方ポリシーは、そもそもおかしなことが起きないようにするための仕組み。ここでコンプライアンスフレームワークは観測から強制へと踏み込むわけですが、これはフレームワークのラベルに紐づくUltimateの機能です。

コンプライアンスフレームワークは、セキュリティポリシー のスコープとして機能します。スキャン実行ポリシー、パイプライン実行ポリシー、マージリクエスト承認ポリシーはコンプライアンスフレームワークにスコープを設定でき、そのラベルを持つすべてのプロジェクトが自動的にこれらを継承します。たとえば、デフォルトブランチでSAST、シークレット検出、依存関係スキャンの実行を必須にしたうえで、新たなクリティカルな脆弱性を持ち込むマージリクエストには、指定したセキュリティチームの承認をマージ前に要求する、といった運用も可能。ポリシーが個々のプロジェクトではなくフレームワークに紐づいているため、新しいプロジェクトをフレームワークに追加すれば、そのプロジェクトは即座に同じガードレールの下に入ります。

これらの要素は連携して働きます。フレームワークが義務を定義し、コントロールとステータスレポートが遵守状況を測定し、ポリシーとコンプライアンスパイプラインが挙動を強制する。SOC 2が2件の承認とスキャナーの実行を求めていると文書化するだけでは終わりません。その要件に反するものをリリースすること自体を難しくします。コントロールが失敗すればステータスレポートが警告し、ポリシーが設定されていれば、違反する変更はマージされる前にブロックされます。

利用可能なテンプレート

GitLabは、認知された標準をGitLabのコントロールにマッピングした事前定義済みフレームワークテンプレートを、コンプライアンス遵守テンプレートプロジェクトで継続的に拡充しています。公開時点では以下が含まれます。

各テンプレートの要件とコントロールの正確な対応関係は、コンプライアンス標準のリファレンスに記載されています。そのままインポートしても、出発点として使ってもかまいません。フレームワークをJSONとしてエクスポートし、自社における標準の解釈に合わせて要件とコントロールを調整して、再度インポートするという流れです。JSONスキーマはシンプルで、フレームワークはname、description、color、そしてrequirementsの配列を持ち、各要件がそれぞれのcontrolsと評価用のexpressionを持つという構成。この構造のおかげで、テンプレートはバージョン管理下に置きやすく、グループ間で共有しやすくなっています。

今後の展望: AI固有のコンプライアンステンプレート

現在扱われているコンプライアンス標準の多くは、従来型のソフトウェアを前提に書かれたものです。組織が自社製品や自社の開発ワークフローにAIを組み込むにつれ、AIシステムをどのように構築し、承認し、監視するかを統制する新しい種類の義務が生まれつつあります。代表例が、EU AI法、ISO/IEC 42001、NIST AIリスクマネジメントフレームワーク。

GitLabは、同じテンプレート駆動のモデルをこの領域に広げるべく、AIガバナンスコンプライアンステンプレート（エピック#16808、計画は作業アイテム#22336で追跡）を検討しています。ねらいは、今日SOC 2を導入するのと同じ手軽さでAIガバナンスフレームワークを採用できるようにすること。AI固有の義務に対応する要件とコントロールをあらかじめ定義し、AI機能を構築・デプロイするプロジェクトに適用して、同じコンプライアンスステータスレポート上で可視化するという構想です。

ここで押さえておきたい区別が1つあります。コンプライアンスとは、定められた要件を満たしている状態を指します。対してガバナンスは、システムとルールの両方が変化していくなかでAIシステムを準拠した状態に保ち続ける、継続的な能力のこと。GitLabの大きな方向性は、AIによる検出と、人間が介在する承認、そして監査可能なポリシーベースの強制を組み合わせるというもの。AIの検出結果は判断材料にとどめ、リリースの可否は責任を持つ人間と測定可能なコントロールが握り続けます。AI固有のテンプレートは、いわばそのオンランプ。新たに生まれつつあるAI要件を、すでに他の領域で使っているフレームワーク、コントロール、ステータスレポート、ポリシーの仕組みへ、そのまま素早く落とし込めるようになります。

まとめ

カスタムコンプライアンスフレームワークを使えば、自社の義務を一度定義するだけで、あとはGitLabが継続的に検証してくれます。テンプレートが着手時の手作業をまるごと取り除いてくれるため、SOC 2フレームワークまでは数クリック、あるいはJSONを1つインポートするだけの距離。コンプライアンスステータスレポートは12時間サイクルで遵守状況を可視化し、セキュリティポリシーとコンプライアンスパイプラインが、その可視性を強制力へと変換します。標準のライブラリはすでに利用可能で、AI固有のテンプレートも視野に入ってきました。「コンプライアンスを満たすべきだ」から「満たしていることを継続的に証明できる」までの道のりは、かつてないほど短くなっています。

詳しくはコンプライアンスフレームワークのドキュメントをご覧いただき、カスタムコンプライアンスフレームワークのクリックスルーデモもぜひお試しください。

本ブログ記事には、1933年証券法（改正済み）第27A条および1934年証券取引所法第21E条にいう「将来の見通しに関する記述」が含まれています。これらの記述に反映された期待は合理的なものと考えていますが、既知および未知のリスク、不確実性、前提条件、その他の要因の影響を受けるため、実際の結果は大きく異なる可能性があります。これらのリスクおよびその他の要因の詳細については、当社がSECに提出する報告書の「リスク要因」の項に記載しています。当社は、法令により義務付けられる場合を除き、本ブログ記事の日付以降にこれらの記述を更新または改訂する義務を負いません。