公開：2025年1月22日
18分で読めます
GitLabでSOC2セキュリティ要件に対応するためのガイド
SOC2セキュリティ要件に対応する、GitLab DevSecOpsプラットフォームのアプリケーションセキュリティ機能について解説します。
機密性の高い顧客情報を扱う企業にとって、SOC（システムおよび組織管理）2コンプライアンスの達成は単なる推奨事項ではなく、多くの場合、必要不可欠です。SOC2は、米国公認会計士協会（AICPA）が策定した厳格な監査基準であり、サービス組織のセキュリティ、可用性、処理の完全性、機密性、プライバシーに関する管理体制を評価します。
SOC2は法的義務ではありませんが、ニュースで頻繁に報じられる情報漏洩事件の影響もあり、重要性が高まっています。SOC2コンプライアンスを達成することで、顧客データを適切に保管し、第三者によるセキュリティ管理の評価を受けていることが伝わり、顧客からの信頼を得られます。
本ガイドでは、SOC2コンプライアンスの要件を解説し、GitLabがどのように組織のアプリケーションセキュリティの最高水準の達成に役立つかをご紹介します。
SOC 2で定められている要件
SOC2コンプライアンスを達成するには、独立した監査担当者による監査が必要となります。監査では、組織の管理体制の設計および運用の有効性を評価します。監査プロセスは非常にコストがかかることが多く、多くの組織は監査前の準備を十分に行えていないのが現状です。通常、SOC2監査は約1年を要するため、効率的な事前監査プロセスを確立することが重要です。
SOC2コンプライアンスを達成するには、組織は以下のトラストサービス規準に基づく要件を満たす必要があります。
| 規準 | 要件 |
| :---- | :---- |
| セキュリティ | - 不正アクセスを防ぐための管理策を実施
- リスクの特定と軽減のための手順を確立
- セキュリティインシデントを検知および対応するためのシステムを構築 |
| 可用性 | - 合意されたとおりにシステムの稼働を保証
- 現在の使用状況と容量をモニタリング
- システム可用性に影響を与えうる環境リスクを特定・対処 |
| 処理の完全性 | - システムの入力・出力の正確な記録を維持
- システムエラーを迅速に特定し修正する手順を実施
- 製品・サービスが仕様を満たすよう処理作業を定義 |
| 機密性 | - 機密情報を特定し保護
- データ保持期間のポリシーを策定
- 保持期間終了後、機密データを安全に破棄する方法を確保 |
| プライバシー | - 機密個人情報を収集する前に同意を取得
- プライバシーポリシーを明確かつわかりやすく伝達
- 法的手段を通じて信頼できる情報源からのみデータを収集 |
なお、これらの要件は一度達成すれば終わりではなく、継続的に準拠する必要があります。監査担当者は一定期間にわたる管理策の有効性の有無を評価します。
セキュリティ要件を満たし、維持する方法
GitLabには、SOC2のセキュリティ要件を満たすためにすぐに活用できる機能が数多く用意されています。
| セキュリティ要件 | 対応機能 |
| :---- | :---- |
| 不正アクセスを防ぐための管理策を実施 | - 非公開のイシュー／マージリクエスト
- カスタムロールときめ細かい権限設定
- セキュリティポリシー
- 検証済みコミット
- コンテナイメージの署名
- CodeOwners
- 保護ブランチ |
| セキュリティインシデントを検知および対応するためのシステムを構築 | - 脆弱性スキャン
- マージリクエスト内セキュリティウィジェット
- 脆弱性インサイトコンプライアンスセンター
- 監査イベント
-脆弱性レポート依存関係リスト
- AIによる脆弱性の説明
- AIによる脆弱性の修正 |
| リスクの特定と軽減のための手順を確立 | 上記すべてのツールを活用して、セキュリティチームが脆弱性発見時の対応および軽減手順を確立できます |
それでは、各要件に対応するセキュリティ機能についてさらに詳しく解説しましょう。なお、上記のほとんどの機能は、GitLab Ultimateプランのサブスクリプションおよび適切なロールと権限設定が必要となります。詳細については、該当するドキュメントをご確認ください。
不正アクセスから保護するための制御の実装
組織の資産を保護して、規制遵守を達成し、業務の継続性を維持し、信頼を築くためには、強固なアクセス制御の実装が不可欠です。GitLabでは、最小権限の原則に従ったアクセス制御を実装でき、不正アクセスからの保護を実現します。ここでは以下の項目について簡単に紹介します。
セキュリティポリシー
GitLabのセキュリティポリシー（いわゆるガードレール）を使用すると、セキュリティおよびコンプライアンスチームは組織全体で一貫した制御を実装できます。これにより、セキュリティインシデントの予防、コンプライアンス基準の維持、一括でのベストプラクティスの自動適用によるリスクの低減が可能になります。
以下のようなポリシーを利用できます。
-
スキャン実行ポリシー：パイプラインの一部として、または指定したスケジュールに応じてセキュリティスキャンの実行を強制
-
マージリクエスト承認ポリシー：スキャン結果に基づいて、プロジェクトレベルの設定や承認ルールを適用
-
パイプライン実行ポリシー：プロジェクトパイプライン内でCI/CDジョブの実行を強制
-
脆弱性管理ポリシー：脆弱性の対応ワークフローを自動化
以下に、パイプライン実行ポリシーを活用してコンプライアンスを確保する例をご紹介します。
-
複数のコンプライアンスジョブをまとめたプロジェクトを作成します。たとえば、デプロイされるファイルの権限を確認するジョブを含めます。これらのジョブは、複数のアプリケーションで再利用できるように汎用的な内容にしておきます。
-
このプロジェクトへの権限はセキュリティ／コンプライアンス担当者に限定し、デベロッパーがジョブを削除できないようにします。これにより職務分離が実現します。
-
対象のプロジェクトにこれらのコンプライアンスジョブを一括で挿入します。ジョブが必ず実行されるよう強制しつつ、開発の妨げにならないようにチームリーダーが実行を承認できるようにします。これにより、コンプライアンスジョブが常に実行され、デベロッパーによって削除されることがなくなり、ご利用の環境にて常にコンプライアンスが確保されるようになります。
セキュリティポリシーの作成方法については、GitLabのセキュリティポリシーに関するページをご覧ください。
カスタムロールと詳細な権限
GitLabのカスタム権限を使用すると、標準のロールベースの権限ではできないきめ細かいアクセス制御を実装できます。これにより、以下のような利点が得られます。
-
より正確なアクセス制御
-
セキュリティコンプライアンスの向上
-
誤ったアクセスのリスク軽減
-
ユーザー管理の効率化
-
複雑な組織構造への対応
カスタムロールに関するページを参照して、きめ細かな権限を設定できるカスタムロールの作成方法をご確認ください。
ブランチ保護とCodeOwners
GitLabでは、次の2つの主要な機能により、コードに変更を加えられるユーザーをさらに厳密に管理できます。
-
ブランチ保護：変更をマージする前に承認を必須とするなど、特定のブランチを変更できるユーザーに関するルールを設定できます。
-
CodeOwners：各ファイルを指定された所有者に関連付け、該当ファイルが変更された際に自動的に適切なレビュアーを指定します。
これらの機能を組み合わせることで、適切な担当者がレビュー・承認を行う体制を構築でき、コードのセキュリティと品質を高い水準で維持できます。
保護ブランチとCodeOwnersの設定方法については、保護ブランチおよびCodeOwnerのページをご参照ください。
検証済みコミット
コミットにデジタル署名を追加することで、なりすましではなく、本当に自分が作成したものであることを証明できます。デジタル署名は、自分だけが発行できる「電子印鑑」のようなものです。GitLabに公開GPG鍵を登録すれば、署名が正しいかを確認でき、マッチすればそのコミットにはVerified（検証済み）のマークが付きます。さらに、未署名のコミットを拒否したり、本人確認ができていないユーザーのコミットをブロックしたりするルールも設定可能です。
コミットには以下の方法で署名できます。
-
SSH鍵
-
GPG鍵
-
個人用x.509証明書
検証済みコミットの詳細は、署名付きコミットに関するページをご覧ください。
セキュリティインシデントの検出と対応のためのシステムの構築
強固なセキュリティ対策状況の維持、規制遵守の確保、被害の最小化、変化し続ける脅威への迅速な対応には、セキュリティインシデントを検知し対応するシステムの構築が不可欠です。
GitLabには、アプリケーションのライフサイクル全体を対象とするセキュリティスキャンと脆弱性管理機能が備わっています。以下の機能について簡単に説明します。
セキュリティスキャンと脆弱性管理
GitLabには以下のような多様なセキュリティスキャナーが備わっており、アプリケーションのライフサイクル全体をカバーします。
-
静的アプリケーションセキュリティテスト（SAST）
-
動的アプリケーションセキュリティテスト（DAST）
-
コンテナスキャン
-
依存関係スキャン
-
Infrastructure as Code（IaC）スキャン
-
カバレッジガイドファジング
-
Web APIファジング
これらのスキャナーはテンプレートを利用すれば、パイプラインに追加できます。たとえば、テストステージでSASTと依存関係スキャンのジョブを実行するには、.gitlab-ci.ymlに以下を追加します。
stages: - test
include: - template: Jobs/Dependency-Scanning.gitlab-ci.yml - template: Jobs/SAST.gitlab-ci.yml ```
これらのジョブは環境変数やGitLabジョブ構文を使ってすべて設定可能です。パイプラインが起動すると、セキュリティスキャナーが動作し、現在のブランチとターゲットブランチの差分から脆弱性を検出します。検出された脆弱性はマージリクエスト（MR）内で確認でき、コードがターゲットブランチにマージされる前に細部まで監視する必要があります。MRには脆弱性に関して以下の情報が表示されます。
* 説明
* ステータス
* 重大度
* 証拠
* 識別子
* URL（該当する場合）
* リクエスト／レスポンス（該当する場合）
* 再現用資産（該当する場合）
* トレーニング情報（該当する場合）
* コードフロー（高度なSAST使用時）
<center><i>脆弱性を紹介するMRの表示画面</i></center><br>
デベロッパーはこれらの情報を活用して、セキュリティチームのワークフローを妨げることなく脆弱性を修正できます。デベロッパーは、レビュープロセスにかかる時間を短縮するために、理由を添えて脆弱性を無視したり、もしくは脆弱性を追跡するための非公開イシューを作成したりすることが可能です。
マージリクエストのコードがデフォルトブランチ（通常は本番環境レベル）にマージされると、脆弱性レポートにセキュリティスキャナーの結果が反映されます。セキュリティチームはこれらの結果をもとに、本番環境で見つかった脆弱性の管理・トリアージを行います。
<center><i>バッチステータス設定が表示された脆弱性レポート</i></center><br>
脆弱性レポート内の脆弱性の説明をクリックすると、MRと同じ脆弱性データが表示される脆弱性ページに移動します。これらの情報は、影響評価や修正作業の際に信頼できる唯一の情報源として活用できます。脆弱性ページでは、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)のAI機能を使って脆弱性の説明を生成したり、修正のためのMRを作成したりして、解決までの時間を短縮できます。
> ##### GitLabに含まれるセキュリティスキャナーや脆弱性管理の詳細は、[アプリケーションセキュリティに関するページ](https://docs.gitlab.com/ee/user/application_security/)をご覧ください。
### ソフトウェア部品表
GitLabはソフトウェアで使用されているコンポーネント（部品）の詳細をリスト化できます。これはコードの「材料表」のようなもので、ソフトウェア部品表（[SBOM](https://about.gitlab.com/ja-jp/blog/the-ultimate-guide-to-sboms/)）と呼ばれます。プロジェクトで使われている外部コードに関して、直接使われているコードやそれらが依存するコードも含め、すべてを把握できます。各項目について、使用バージョンやライセンス情報、既知のセキュリティ問題の有無も表示されます。これにより、自社のソフトウェアの構成を把握し、潜在的なリスクを見つけやすくなります。
<center><i>グループレベルの依存関係リスト（SBOM）</i></center>
> ##### 依存関係リストのアクセス方法と活用法は、[依存関係リストに関するページ](https://docs.gitlab.com/ee/user/application_security/dependency_list/)をご参照ください。
### システム監査とセキュリティ対策状況のレビュー
GitLabは、誰がいつ何を変更したかなど、システム内のすべての動きを記録します。コードを監視するセキュリティカメラのようなものだと考えてください。これにより、以下が可能になります。
* 不審な動きを発見する
* 規制当局にルール遵守を証明する
* 問題が発生した際に状況を把握する
* GitLabの利用状況を把握する
これらの情報は一元管理されているため、必要に応じて容易に確認・調査できます。たとえば、監査イベントを使うと以下の情報を追跡できます。
* GitLabプロジェクトにおいて、誰がいつ特定ユーザーの権限レベルを変更したか
* 誰がいつ新しいユーザーを追加または削除したか
<center><i>プロジェクトレベルの監査イベント</i></center>
> ##### 監査イベントの詳細については、[監査イベントに関するページ](https://docs.gitlab.com/ee/user/compliance/audit_events.html)をご覧ください。
## コンプライアンスとセキュリティ対策状況の監視
GitLabのセキュリティダッシュボードは、すべてのセキュリティリスクを1か所で表示する「コントロールルーム」のような機能です。複数のセキュリティツールを個別に確認する必要はなく、全プロジェクトの調査情報を1つの画面でまとめて把握できます。これにより、プロジェクトに潜む問題の早期発見と迅速な対応が可能になります。
<center><i>グループレベルのセキュリティダッシュボード</i></center>
> ##### セキュリティダッシュボードの詳細については、[セキュリティダッシュボードに関するページ](https://docs.gitlab.com/ee/user/application_security/security_dashboard/)をご覧ください。
## リスクを特定し、軽減するための手順の確立
脆弱性には特定のライフサイクルがあります。たとえば、セキュリティポリシーを使って、脆弱なコードを保護ブランチにマージするには承認が必要という手続きを設けることができます。さらに、本番環境で脆弱なコードが検出された場合、優先的に対応し、評価・修正・検証を行うという流れを定めることも可能です。
* 優先順位は、GitLabのスキャナーによって提供される脆弱性の重大度に基づいて決められます。
* 評価は、AIによる脆弱性の説明機能が提供する悪用の詳細情報を使って行えます。
* 修正後は、GitLabに組み込まれた回帰テストやスキャナーを使用して検証できます。
すべての組織に共通の対応策はありませんが、GitLabのような統合プラットフォームを活用することで、複数の異なるツールを使う場合と比べて、リスクをすばやく把握・対処でき、リスク全体を低減することが可能です。
### SOC 2コンプライアンスに関するベストプラクティス
* 強固なセキュリティ文化を確立する：組織全体でセキュリティへの意識と責任感を高めましょう。
* すべてを文書化する：ポリシー、手順、コントロールの詳細なドキュメントを維持しましょう。
* 自動化できる部分は自動化する：自動化ツールを使用してコンプライアンスプロセスを効率化し、エラーを削減しましょう。
* 効果的に情報を共有する：関係者に対し、コンプライアンスの取り組みについて情報を伝えましょう。
* 専門家の助言を求める：SOC2準拠の取り組みにおいて、信頼できるコンサルタントとの連携を検討しましょう。
SOC2コンプライアンスは大きな取り組みですが、その価値は計り知れません。アプリケーションセキュリティと運用上の卓越性への取り組みを示すことで、顧客からの信頼を築き、企業としての評判を高め、市場における競争力を強化できます。
## 詳細はこちら
GitLabの詳細、またGitLabがSOC2コンプライアンスの達成とセキュリティ対策状況の強化にどのように役立つかについては、以下のリソースをご覧ください。
* [GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)
* [GitLabのセキュリティおよびコンプライアンスソリューション](https://about.gitlab.com/ja-jp/solutions/security-compliance/)
* [GitLabアプリケーションセキュリティに関するページ](https://docs.gitlab.com/ee/user/application_security/)
* [GitLab DevSecOpsチュートリアルプロジェクト](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)