GitLab プロジェクトのベースライン要件
目的
このページの目的は、スコープで定義するプロジェクトが満たさなければならない最小限の要件を概説することです。最終的な目標は、GitLab のコードベースに最終的に影響を与える変更が独立したレビューなしで行われないようにし、脆弱性やサプライチェーン攻撃が本番環境に到達するリスクを減らすことです。このページはまた、GitLab ユーザーが重要と考えるプロジェクトを保護するための構成例を示すことで、ユーザーを支援できます。
GitLab のドッグフーディングへのコミットメントと効率のバリューを踏まえると、これらのベースラインプロジェクト構成はすべてのプロジェクトに必要なわけではなく、スコープで定義するプロジェクト、または別途伝えられた理由で重要と判断されるプロジェクトにのみ必要であることを理解することが重要です（こうした場合には、これらのベースライン構成が「なぜ」必要なのかを明確に説明できる必要があります）。
ただし、チームメンバーがプロジェクトを作成または作業する際に、これらのベースライン構成を念頭に置くことが推奨されます。これらは、GitLab プロジェクトでなされる貢献のセキュリティと品質を向上させるように設計されているためです。
スコープ
これらのベースライン構成は、GitLab のコードベースに直接的または間接的に影響を与えるプロジェクト、および/または GitLab のビルド、リリース、デプロイに影響を与えるプロジェクトに適用しなければなりません。これには、本番コード、インフラストラクチャ、コンテナのビルド、または GitLab 製品を構成するソフトウェアをデプロイする CI/CD パイプラインを含むプロジェクトが該当します。
この基準に当てはまるプロジェクトの例：
- GitLab のコンポーネントをビルドするプロジェクト
- GitLab のコンポーネントのコードベースを管理するのに役立つボットをビルドするプロジェクト
- 重要な非 GitLab システム（例：Salesforce）のコードベースを更新するために使用されるプロジェクト
この基準に当てはまらないプロジェクトの例：
- コードを持たないプロジェクト
- GitLab のコードベースに影響を与えないボットをビルドするプロジェクト（例：YAML ファイルを CSV に変換するスクリプト）
プロジェクトの使用法は時間の経過とともに自然にシフトする可能性があり、継続的にプロジェクトの使用法を再評価することが重要です。プロジェクトはどちらのカテゴリーにも入ったり出たりする可能性があるため、毎日プロジェクトで作業する際にそれを念頭に置いてください。期待されるのは、プロジェクトにこれらのベースライン構成が設定されている場合でも、チームメンバーが作業で協力し合い、個人が単一障害点になるリスクを高める知識のサイロでの作業を避けることで、効率が低下しないことです。これらの価値観はまた、変更に複数のチームメンバーを関与させることで、私たちの透明性の価値を促進します。
自分のプロジェクトがどこに当てはまるかわかりません
問題ありません！決して珍しいことではありません。質問がある場合は、私たちが対処し、適切なカテゴリーに当てはめられるよう、提起してください。プロジェクトの分類方法をここでイテレーションを行い、セキュリティと品質、そして効率へのコミットメントを確保できます。
自分のプロジェクトは基準に当てはまらないようですが、それでもこれらの構成が必要ですか?
プロジェクトがベースライン構成を要求するための一般的な基準を厳密に満たさないが、何らかの理由でプロジェクトをベースライン構成を使用して構成すべきと判断される場合もあります。こうした場合には、これらのベースライン構成の必要性の背後にある「理由」の根拠が明確に伝えられる必要があります。既存の基準を満たさないと思われるプロジェクトに対して多くの類似した根拠が提供される場合、それはプロジェクトのスコープと基準を調整すべきという指標である可能性があります。
ベースライン要件
スコープで定義するプロジェクトは、以下のすべての要件を満たさなければなりません。チームは、より厳格な統制を適用できます。
- 直接プッシュする代わりに、保護されたブランチへのマージリクエストを必須にします。
- デフォルトブランチへの強制プッシュを無効にします。
- 署名のないコミットを拒否するプッシュルールを有効にします。
- GitLab のコードレビューガイドラインに従います。
- レビューされていないコミットがマージされないよう、マージリクエスト承認ルールを設定します。デフォルトブランチへのマージ前に、少なくとも 1 件の承認を必須にします。
- 新しいコミットが追加されたらすべての承認を削除する設定を有効にします。
- マージリクエスト作成者による承認を禁止する設定を有効にします。
- コミットを追加したユーザーによる承認を禁止する設定を有効にします。
- マージリクエストでの承認ルールの編集を禁止する設定を有効にします。
- 適用される SOX や FedRAMP の統制を含め、法律、規制、または契約が要求する場合は、人による承認を必須にします。
- Code Owners ファイルでファイルの所有者を定義します。
- 保護されたブランチの設定で、Code Owner 承認を有効にします。
- マージリクエストが Code Owner の所有するファイルを変更する場合、少なくとも 1 人の Code Owner による承認を必須にします。
シークレットの漏えいを防ぎます。
- シークレットプッシュ保護を有効にします。
トークンのアクセスを制限します。
- サービスアカウントには、個人アクセストークンではなくプロジェクトまたはグループアクセストークンを使用します。有効期限とスコープの要件を含め、トークン管理標準に従います。
- CI ジョブトークンのアクセスを、明示的な認可済みプロジェクトとグループの許可リストに制限します。きめ細かな権限を使用して、各エントリに必要な権限だけを付与します。
CI/CD 変数を保護します。
- シークレットまたは認証情報を含むすべての CI/CD 変数をマスクして非表示にし、それらの変数を保護されたブランチに制限します。
- パイプラインを手動で開始する際、プロジェクトメンバーによる CI/CD 変数の上書きを禁止します。パイプライン変数の制限を参照してください。
- CI の依存関係を固定バージョンに固定します。
latestのような参照先が変わる参照は使用しないでください。 - CI ジョブで使用する前に、パッケージ、ツール、コンテナイメージの完全性を検証します。署名済みのイメージやアーティファクトについては、署名の検証を参照してください。
- CI の依存関係を固定バージョンに固定します。
セキュリティスキャンを実行します。
- すべてのマージリクエストパイプラインで SAST、依存関係スキャン、シークレットスキャンを実行します。マージリクエストパイプラインでのセキュリティスキャンを参照してください。
- デフォルトブランチからビルドされるすべてのコンテナイメージで、コンテナスキャンを有効にします。
- すべての Infrastructure as Code の変更でセキュリティ設定の誤りを確認するため、Infrastructure as Code スキャンを有効にします。
マージチェックを必須にします。
- マージ前に CI パイプラインの成功を必須にします。
- ターゲットブランチと比較して、セキュリティスキャンで新たに検出された High または Critical の脆弱性について承認を必須にするよう、マージリクエスト承認ポリシーを設定します。
公開された CI コンポーネントを保護します。
- CI コンポーネントをホストするプロジェクトでは、下流のパイプラインが利用するコンポーネントの内容が不正に変更されないよう、すべての semver バージョンタグに不変タグを使用します。
公開されたパッケージを保護します。
- 公開レジストリにパッケージを公開する前に、許可されたファイルやファイルパターンの承認済みリストに照らして内容を確認します。npm パッケージの場合は、パッケージの内容に関するガイダンスに従います。
- サポートされている場合は、パッケージ保護ルールを設定して、パッケージをプッシュまたは削除できるユーザーを制限します。
本番イメージとデプロイを保護します。
- 本番イメージをプッシュ、上書き、削除できるユーザーを制限します。本番タグのパターンには保護されたコンテナタグを使用し、本番イメージのみを保持するリポジトリには保護されたコンテナリポジトリを使用します。
- 本番イメージの semver バージョンタグに不変のコンテナタグを設定して、公開後に誰も上書きや削除できないようにします。
- 保護された環境を設定して、本番環境にデプロイできるユーザーを制限します。
- 本番デプロイジョブを保護されたブランチに制限します。デプロイの安全性に関するガイダンスを参照してください。
質問がある場合は、#security-help で尋ねてください。
設定例
保護されたブランチ
Code Owners を使用する承認ルール
継続的なモニタリング
これらのベースライン構成を要求する基準を満たすプロジェクトは、私たちのこのページに示されているガイダンスに従っていることを確認する継続的コントロールモニタリングプログラムの一環として、GitLab Security Compliance チームによって構成テストのためにいつでも選択される可能性があることに注意してください。プログラムの概要については、GCF セキュリティコントロールライフサイクルページを参照してください。
継続的なコントロールモニタリングの対象は、現在、保護されたブランチと MR 承認の設定のみです。パイプラインと CI/CD の統制は、まだ対象に含まれていません。
Security Compliance チームはまた、上記で概説されたすべての MR 承認および保護されたブランチ設定について、Devo SIEM ツールでの検出/アラートと Slack を使用してライブモニタリングを実装しています。設定の変更の結果として、適切な承認/SOD なしに MR がマージされた場合、根本原因を特定して修復を実行するための観察 Issue が開かれます。修復には、なぜ変更されたかを理解する、設定をコンプライアンスに戻す、適切な承認や職務分掌（SOD）なしにマージされた MR をレビューして悪意のある変更が含まれていないことを確認する、必要に応じて遡及的な承認を取得するなどのステップが含まれます。Security Compliance はまた、変更の根本原因を特定し、設定がチームの開発作業を完了するために変更される必要がないようにワークフローの変更を実装することに向けて作業するために、変更を行った個人とプロジェクトを所有/作業するチームの管理を巻き込みます。
さらなるセキュリティ推奨事項
- 変数を平文で保存したり、包括的なシークレット管理のためにマスクされた環境変数に依存したりしないでください。代わりに、外部シークレットストレージソリューションを設定してください
- プロジェクトの脅威モデルの作成を強く検討してください。
- プロジェクトがより確立された時点で、AppSec レビューを依頼することを検討してください。
- さらに質問がある場合は、AppSec チーム (
@gitlab-com/gl-security/appsecおよび#security_help)に連絡してください。
参考文献
- GitLab リポジトリ (新しいプロジェクト作成のガイダンス)
- 変更管理ポリシー
- GCF セキュリティコントロールライフサイクル
5d840611)