NIST 800-53コンプライアンス

プラン: Ultimate
提供形態: GitLab Self-Managed、GitLab Dedicated

このページは、該当するNIST 800-53コントロールを満たすようにGitLab Self-Managedインスタンスを設定したいGitLabの管理者向けのリファレンスです。GitLabは、管理者が持つ可能性のある様々な要件があるため、特定の設定ガイダンスを提供していません。NIST 800-53セキュリティコントロールを満たすGitLabインスタンスをデプロイする前に、技術的な詳細については顧客のソリューションアーキテクトと協力してください。

スコープ

このページは、NIST 800-53コントロールファミリーの構成に従っています。このページのスコープは主にGitLab自体への設定に限定されているため、すべてのコントロールファミリーが適用されるわけではありません。設定の詳細はプラットフォームに依存しないように意図されています。

GitLabのガイダンスは、完全に準拠したシステムを構成するものではありません。政府データを扱う前に、以下のことを行う必要があります:

追加の設定と技術スタック全体の強化を計画してください。
セキュリティ設定の独立した評価を検討してください。
サポートされているクラウドプロバイダー全体でのデプロイの違いを理解し、利用可能な場合は特定のガイダンスに従ってください。

コンプライアンス機能

GitLabは、GitLabで重要なコントロールとワークフローを自動化するために使用できるいくつかのコンプライアンス機能を提供しています。NIST 800-53に合わせた設定を行う前に、これらの基本的な機能を有効にする必要があります。

コントロールファミリーごとの設定

システムおよびサービス取得 (SA)

GitLabは、開発ライフサイクル全体にセキュリティを統合するDevSecOpsプラットフォームです。その核となる部分では、GitLabを使用してSAコントロールファミリーの幅広いコントロールに対応できます。

システム開発ライフサイクル

この要件の核となる部分を満たすためにGitLabを使用できます。GitLabは、作業を整理し、計画し、追跡できるプラットフォームを提供します。NIST 800-53では、アプリケーションの開発にセキュリティを組み込むことを義務付けています。CI/CDパイプラインを設定して、出荷時にコードを継続的にテストし、同時にセキュリティポリシーを適用できます。GitLabには、顧客アプリケーションの開発に組み込むことができるセキュリティツールスイートが含まれており、以下のようなものがあります:

CI/CDパイプラインに加えて、GitLabはリリースを設定する方法に関する詳細なガイダンスを提供します。リリースはCI/CDパイプラインで作成でき、リポジトリ内の任意のソースコードブランチのスナップショットを取得します。リリース作成の指示は、リリースを作成に含まれています。NIST 800-53またはFedRAMPのコンプライアンスにとって重要な考慮事項は、リリースされたコードの信頼性を検証し、システムおよび情報整合性 (SI) コントロールファミリーの要件を満たすために、コードに署名する必要がある場合があることです。

アクセス制御 (AC) および識別と認証 (IA)

GitLabデプロイにおけるアクセス管理は、顧客ごとに異なります。GitLabは、Identity Providerを使用したデプロイとGitLabネイティブの認証設定をカバーする幅広いドキュメントを提供しています。GitLabインスタンスへの認証のアプローチを決定する前に、組織の要件を考慮することが重要です。

Identity Provider

GitLabでのアクセスは、UIまたは既存のIdentity Providerとの統合によって管理できます。FedRAMPの要件を満たすには、既存のIdentity ProviderがFedRAMP MarketplaceでFedRAMPによって承認されていることを確認してください。PIVなどの要件を満たすには、GitLab Self-Managedでネイティブ認証を使用するのではなく、Identity Providerを活用する必要があります。

GitLabは、様々なIdentity Providerとプロトコルを設定するためのリソースを提供しており、以下を含みます。

LDAP
SAML
Identity Providerの詳細については、GitLabの認証と認可を参照してください。

ネイティブGitLabユーザー認証設定

Account management and classification - GitLabは、管理者が様々な機密性とアクセス要件を持つユーザーを追跡できるようにします。GitLabは、最小権限の原則とロールベースアクセスをサポートし、詳細なアクセスオプションを提供します。プロジェクトレベルでは、以下のロールがサポートされています。

ゲスト
レポーター
デベロッパー
メンテナー
オーナー

プロジェクトレベルの権限に関する追加の詳細は、ドキュメントで確認できます。GitLabは、独自の権限要件を持つ顧客向けにカスタムロールもサポートしています。

GitLabは、独自のユースケース向けに以下のユーザータイプもサポートしています:

監査担当者ユーザー - 監査担当者ユーザーロールは、管理者エリアとプロジェクト/グループ設定を除くすべてのグループ、プロジェクト、およびその他のリソースへの読み取り専用アクセスを提供します。プロセスを検証するために特定のプロジェクトへのアクセスを必要とするサードパーティの監査担当者と連携する場合に、監査担当者ロールを使用できます。
外部ユーザー - 外部ユーザーは、組織の一部ではない可能性のあるユーザーに限定的なアクセスを提供するように設定できます。通常、これは契約者やその他のサードパーティのアクセスを管理するために使用できます。IA-4(4)のようなコントロールでは、組織外のユーザーを会社の方針に従って識別し管理する必要があります。外部ユーザーを設定することで、デフォルトでプロジェクトへのアクセスを制限し、組織に雇用されていないユーザーを管理者が特定するのを支援することで、組織へのリスクを軽減できます。
サービスアカウント - サービスアカウントは、自動化されたタスクに対応するために追加できます。サービスアカウントは、ライセンスの下でシートを使用しません。

管理者エリア - 管理者エリアでは、管理者は権限をエクスポートしたり、ユーザーIDをレビューしたり、グループを管理したり、その他多くのことができます。FedRAMP / NIST 800-53要件を満たすために使用できる機能は以下のとおりです:

侵害が疑われる場合にユーザーパスワードをリセットします。
ユーザーをロック解除します。デフォルトでは、GitLabはサインイン失敗10回後にユーザーをロックします。ユーザーは10分間ロックされたままになるか、管理者がユーザーのロックを解除するまでロックされます。GitLab 16.5以降では、管理者はAPIを使用して、最大ログイン試行回数とロックアウト状態が維持される期間を設定できます。AC-7のガイダンスによると、FedRAMPはアカウントロックアウトのパラメータを定義するためにNIST 800-63Bに準拠しており、これはデフォルト設定で満たされています。
不正使用レポートまたはスパムログをレビューします。FedRAMPは、組織が異常な使用状況 (AC-2(12)) のアカウントをモニタリングすることを義務付けています。GitLabは、管理者が調査が保留されているアクセスを削除できる不正使用レポートで、ユーザーが不正使用を報告できるようにします。スパムログは、スパムログセクションの管理者エリアに統合されています。管理者は、そのエリアでフラグが付けられたユーザーを削除、ブロック、または信頼できます。
パスワードストレージパラメータを設定します。保存されたシークレットは、SC-13で概説されているようにFIPS 140-2または140-3を満たす必要があります。FIPSモードが有効になっている場合、PBKDF2+SHA512はFIPS準拠した暗号でサポートされます。
認証情報インベントリを使用すると、管理者はGitLab Self-Managedインスタンスで使用されているすべてのシークレットを1か所でレビューできます。認証情報、トークン、およびキーの統合ビューは、パスワードのレビューや認証情報をローテーションするなどの要件を満たすのに役立ちます。
パスワードの複雑さの要件を変更します。FedRAMPは、パスワード長要件を確立するためにIA-5のNIST 800-63Bに準拠しています。GitLabは8～128文字のパスワードをサポートしており、8文字がデフォルトとして設定されています。
デフォルトのセッション期間 - FedRAMPは、設定された期間非アクティブであったユーザーはログアウトされるべきであると定めています。FedRAMPは期間を特定していませんが、特権ユーザーについては標準的な作業期間の終わりにログアウトされるべきであると明確にしています。管理者はデフォルトのセッション期間を確立できます。
新規ユーザーのプロビジョニング - 管理者は、管理者エリアUIを使用して、GitLabアカウントの新規ユーザーを作成できます。IA-5のコンプライアンスに基づき、GitLabは新規ユーザーに初回ログイン時にパスワードを変更するよう要求します。
ユーザーの廃止 - 管理者は、管理者エリアUIを使用してユーザーを削除できます。ユーザーを削除する代わりに、ユーザーをブロックしてすべてのアクセスを削除できます。ユーザーをブロックすると、すべてのアクセスが削除される一方で、リポジトリ内のデータは保持されます。ブロックされたユーザーはシート数に影響しません。
ユーザーの非アクティブ化 - アカウントレビュー中に特定された非アクティブなユーザーは一時的に非アクティブ化される場合があります。非アクティブ化はブロックに似ていますが、いくつかの重要な違いがあります。ユーザーを非アクティブ化しても、ユーザーがGitLabUIにサインインすることは禁止されません。非アクティブ化されたユーザーは、サインインすることで再びアクティブになれます。非アクティブ化されたユーザーは以下のとおりです:
- リポジトリまたはAPIにアクセスできません。
- スラッシュコマンドを使用できません。詳細については、スラッシュコマンドを参照してください。
- シートを占有しません。

追加の識別方法

2要素認証 - GitLabは以下の第2要素をサポートします:

ワンタイムパスワード認証器
WebAuthnデバイス

2要素認証を有効にするための指示は、ドキュメントで提供されています。FedRAMPを追求する顧客は、FedRAMPの承認を受け、FIPS要件をサポートする2要素プロバイダーを考慮する必要があります。FedRAMPの承認を受けたプロバイダーは、FedRAMP MarketplaceでFedRAMPによって承認されていることを確認できます。第2要素を選択する際、NISTとFedRAMPは現在、WebAuthnのようなフィッシング耐性のある認証を使用する必要があることを示しています (IA-2)。

SSHキー

GitLabは、Gitと認証して通信するためのSSHキーを設定する方法に関する指示を提供します。コミットは署名でき、公開キーを持つ人に追加の検証を提供します。
キーは、FIPS 140-2およびFIPS 140-3検証済み暗号の使用など、該当する強度および複雑さの要件を満たすように設定する必要があります。管理者は最小キー技術とキー長を制限できます。さらに、GitLabは侵害されたキーをブロックします。

パーソナルアクセストークン

GitLabは、パーソナルアクセストークンを設定および管理する方法に関する指示を提供します。GitLabはきめ細やかな権限をサポートしており、これにより該当するユースケースに必要な権限のみにトークンのスコープを設定できます。

その他のアクセス制御ファミリーの概念

System Use Notifications

連邦政府の要件では、多くの場合、ログイン時にバナーが必要であると概説されています。これは、Identity ProviderとGitLabバナー機能を通じて設定できます。

External Connections

すべての外部接続をドキュメント化し、コンプライアンス要件を満たしていることを確認することが重要です。たとえば、サードパーティとのAPIインテグレーションを設定すると、そのサードパーティが顧客データをどのように保護するかによって、データ処理要件に違反する可能性があります。すべての外部接続をレビューし、有効にする前にそれらのセキュリティ上の影響を理解することが重要です。FedRAMPまたは同様の認証を追求する顧客の場合、他のFedRAMPによって承認されていないサービスや、データ影響レベルの低いサービスに接続すると、認可境界に違反する可能性があります。

Personal Identity Verification (PIV)

個人識別検証カードは、連邦政府の要件を満たす組織にとって必要となる場合があります。PIV要件を満たすために、GitLabは顧客がPIV対応のIDソリューションをSAMLと接続することを要求します。SAMLドキュメントへのリンクは、このガイドの以前のセクションで提供されています。

監査と責任 (AU)

NIST 800-53は、セキュリティ関連イベントをモニタリングし、それらのイベントを分析し、アラートを生成し、アラートの重要度に応じてアラートを調査することを組織に義務付けています。GitLabは、セキュリティ情報およびイベント管理 (SIEM) ソリューションにルーティングできる、幅広い配列のセキュリティイベントをモニタリングのために提供します。

イベントタイプ

GitLabは、設定可能な監査イベントログタイプを概説しており、これらはデータベースにストリーミングおよび/または保存できます。管理者は、GitLabインスタンス用にキャプチャしたいイベントを設定できます。

Log System

GitLabには、すべてをログに記録できる高度なログシステムが含まれています。GitLabは、広範囲の出力を含むログシステムのログタイプに関するガイダンスを提供します。詳細については、リンクされたガイダンスをレビューしてください。

ストリーミングイベント

GitLab管理者は、イベントストリーミング機能を使用して、監査イベントをSIEMまたはその他のストレージ場所にストリーミングできます。管理者は、複数の宛先を設定し、イベントヘッダーを設定できます。GitLabは、HTTPおよびHTTPSイベントのヘッダー、ペイロードなどを概説するイベントストリーミングの例を提供します。

管理者がFedRAMPまたはNIST 800-53 AU-2要件をレビューし、必要な監査イベントタイプにマップする監査イベントを実装することが重要です。AU-2は以下のイベントバケットを識別します:

アカウントログオンの成功および失敗イベント
アカウント管理イベント
オブジェクトアクセス
ポリシー変更
特権機能
プロセス追跡
システムイベント
ウェブアプリケーションの場合:
- すべての管理者アクティビティ
- 認証チェック
- 認可チェック
- データ削除
- データアクセス
- データ変更
- 権限変更

管理者は、GitLabでイベントを有効にする際に、必要なイベントタイプと追加の組織要件の両方を考慮する必要があります。

メトリクス

セキュリティイベントとは別に、管理者はアップタイムをサポートするためにアプリケーションのパフォーマンスへの可視性を必要とする場合もあります。GitLabは、GitLabインスタンスでサポートされているメトリクスに関する堅牢なドキュメントセットを提供します。

ストレージ

顧客は、ログがコンプライアンス要件を満たす長期ストレージソリューションに保存されることを確認する責任があります。たとえば、FedRAMPでは、ログを1年間保存することを義務付けています。顧客組織は、収集されたデータの影響に応じて、国立公文書館および記録管理局の要件を満たす必要もあるかもしれません。収集された記録の影響をレビューし、適用されるコンプライアンス要件を理解することが重要です。

インシデント対応 (IR)

監査イベントが設定されると、それらのイベントはモニタリングされる必要があります。GitLabは、SIEMまたはその他のセキュリティツールからのシステムアラートをコンパイルし、アラートとインシデントをトリアージし、利害関係者に情報を提供する一元化された管理インターフェースを提供します。インシデント管理ドキュメントは、セキュリティインシデント対応組織で前述の活動を実行するためにGitLabをどのように使用できるかを概説しています。

Incident Response Lifecycle

GitLabは、組織のインシデント対応ライフサイクル全体を管理できます。インシデント対応要件を満たすのに役立つ可能性のある以下のリソースをレビューしてください:

設定管理 (CM)

Change Control

GitLabは、その核となる部分で、変更管理に関連する設定管理要件を満たすことができます。イシューとマージリクエストは、変更をサポートするための主要な方法です。

イシューは、変更を実装する前にメタデータと承認をキャプチャするための柔軟なプラットフォームです。GitLabの機能が設定管理コントロールを満たすためにどのように使用できるかを完全に理解するために、作業の計画と追跡に関するGitLabドキュメントをレビューすることを検討してください。

マージリクエストは、ソースブランチからターゲットブランチへの変更を標準化する方法を提供します。NIST 800-53のコンテキストでは、コードをマージする前に承認をどのように収集すべきか、および組織内で誰がコードをマージする能力を持っているかを考慮することが重要です。GitLabは、マージリクエストの承認で利用可能な様々な設定に関するガイダンスを提供します。必要なレビューが完了した後、承認およびマージ権限を適切なロールにのみ割り当てることを検討してください。考慮すべき追加のマージ設定は以下のとおりです:

コミットが追加された場合にすべての承認を削除する - 新しいコミットがマージリクエストに対して行われたときに承認が引き継がれないようにします。
コード変更レビューを無視することができる個人を制限します。
機密情報コードまたは設定がマージリクエストを通じて変更されたときに通知されるようにコードオーナーを割り当てます。
すべてのオープンなコメントがコード変更のマージを許可する前に解決されていることを確認します。
プッシュルールを設定する - プッシュルールは、署名されたコードのレビュー、ユーザーの検証などの要件を満たすように設定できます。

Testing and Validation of Changes

CI/CDパイプラインは、変更のテストと検証の重要なコンポーネントです。特定のユースケースに対して十分なテストおよび検証パイプラインを実装する責任は顧客にあります。サービスを選択する際には、そのパイプラインがどこで実行されるかを考慮してください。外部サービスに接続すると、連邦データが保存および処理されることが許可されている確立された認可境界に違反する可能性があります。GitLabは、FIPS対応システムで実行するように設定されたRunnerコンテナイメージを提供します。GitLabは、保護ブランチを設定する方法やパイプラインセキュリティを実装する方法など、パイプラインの強化ガイダンスを提供します。さらに、顧客はコードを更新する前に、すべてのチェックがパスしたことを確認するために、コードをマージする前に必須チェックを割り当てることを検討するかもしれません。

Component Inventory

NIST 800-53は、クラウドプロバイダーがコンポーネントインベントリを維持することを義務付けています。GitLabは基盤となるハードウェアを直接追跡することはできませんが、コンテナスキャンと依存関係スキャンを通じてソフトウェアインベントリを生成できます。GitLabは、コンテナスキャンと依存関係スキャンが検出できる依存関係を概説しています。GitLabは、依存関係リストの生成に関する追加のドキュメントを提供しており、これはソフトウェアコンポーネントインベントリで使用できます。ソフトウェア部品表は、このドキュメントの後半の「サプライチェーンリスク管理」の下でカバーされています。

コンテナレジストリ

GitLabは、GitLabプロジェクト用のコンテナイメージを保存するための統合されたコンテナレジストリを提供します。これは、高度に仮想化されたスケーラブルな環境でコンテナをデプロイするための信頼できるリポジトリとして使用できます。コンテナレジストリの管理ガイダンスはレビューできます。

緊急時計画 (CP)

GitLabは、コアの緊急時計画要件を満たすのに役立つガイダンスとサービスを提供します。含まれているドキュメントをレビューし、緊急時計画活動の組織要件を満たすために適切に計画することが重要です。緊急時計画は各組織に固有のものであるため、緊急時計画を確立する前に組織のニーズを考慮することが重要です。

Selecting a GitLab Architecture

GitLabは、GitLab Self-Managedインスタンスでサポートされているアーキテクチャに関する広範なドキュメントを提供しています。GitLabは以下のクラウドプロバイダーをサポートしています:

GitLabは、顧客がリファレンスアーキテクチャと可用性モデルを選択するのを支援するための意思決定ツリーを提供します。ほとんどのクラウドプロバイダーは、マネージドサービス向けにリージョンで回復性を提供します。アーキテクチャを選択する際には、組織のダウンタイム許容度とデータの重要性を考慮することが重要です。追加のレプリケーションおよびフェイルオーバー機能のためにGitLab Geoを検討できます。

Identify Critical Assets

NIST 800-53は、停止中の優先的な復元を確実にするために、重要な資産の識別を要求します。考慮すべき重要な資産には、GitalyノードとPostgreSQLデータベースが含まれます。顧客は、必要に応じてバックアップまたはレプリケーションが必要な追加の資産を特定する必要があります。

バックアップ

ドキュメントは、以下を含む重要なコンポーネントのバックアップ戦略を概説しています:

GitLab Geo

GitLab Geoは、NIST 800-53のコンプライアンスを追求する実装の重要なコンポーネントとなるでしょう。各ユースケースに対してGeoが適切に設定されていることを確認するために、利用可能なドキュメントをレビューすることが重要です。

Geoを実装すると、以下の利点が得られます:

分散開発者が大規模なリポジトリとプロジェクトをクローンおよびフェッチするのにかかる時間を数分から数秒に短縮します。
開発者が地域を越えてアイデアをコントリビュートするし、並行して作業できるようにします。
プライマリサイトとセカンダリサイト間の読み取り専用負荷のバランスを取ります。
プロジェクトのクローン作成とフェッチ、およびGitLabウェブインターフェースで利用可能なデータの読み取りに使用できます (制限事項を参照)。
遠隔地のオフィス間の遅い接続を克服し、分散チームの速度を向上させることで時間を節約します。
自動化されたタスク、カスタムインテグレーション、および内部ワークフローの読み込み時間を短縮するのに役立ちます。
ディザスターリカバリーシナリオで、セカンダリサイトに迅速にフェイルオーバーできます。
計画的なセカンダリサイトへのフェイルオーバーを可能にします。

Geoは以下のコア機能を提供します:

読み取り専用セカンダリサイト: 分散チーム向けに読み取り専用セカンダリサイトを有効にしながら、1つのプライマリGitLabサイトを維持します。
認証システムフック: セカンダリサイトは、すべての認証データ（ユーザーアカウントやログインなど）をプライマリインスタンスから受け取ります。
直感的なUI: セカンダリサイトは、プライマリサイトと同じウェブインターフェースを使用します。さらに、書き込み操作をブロックし、ユーザーがセカンダリサイトにいることを明確にする視覚的な通知があります。

追加のGeoリソース:

PostgreSQL

GitLabは、レプリケーションとフェイルオーバーを使用してPostgreSQLクラスターを設定する方法に関するガイダンスを提供します。データの重要性とGitLabインスタンスの最大許容ダウンタイムに応じて、レプリケーションとフェイルオーバーを有効にしたPostgreSQLの設定を検討してください。

Gitaly

Gitalyを設定する際には、可用性、回復性、および弾力性の間のトレードオフを考慮してください。GitLabは、NIST 800-53要件を満たす正しい設定を決定するのに役立つGitaly機能に関する広範なドキュメントを提供します。

計画 (PL)

計画コントロールファミリーには、ポリシー、手順、その他の管理されたドキュメントの維持が含まれます。管理されたドキュメントのライフサイクルを管理するためにGitLabを活用することを検討してください。たとえば、管理されたドキュメントは、バージョン管理された状態でMarkdownに保存できます。ドキュメントへの変更はすべて、組織の承認ルールを強制するマージリクエストを通じて行われる必要があります。マージリクエストは、管理されたドキュメントに対して行われた変更の明確な履歴を提供します。これは、ドキュメントオーナーなどの適切な担当者による年次レビューと承認を実証するために、監査中に使用できます。

リスク評価およびシステムと情報整合性 (RA)

スキャン

NIST 800-53は、脆弱性の継続的なモニタリングと欠陥の修正を義務付けています。インフラストラクチャスキャンに加えて、FedRAMPのようなコンプライアンスフレームワークは、コンテナとDASTスキャンを月次報告要件のスコープに含めています。GitLabは、コンテナスキャンをサポートできるセキュリティツールを提供しており、TrivyやGrypeスキャナーが含まれます。さらに、GitLabは依存関係スキャン機能を提供します。GitLabのDASTは、ウェブアプリケーションスキャン要件を満たすために使用できます。GitLabDASTは、パイプラインで実行され、実行中のウェブアプリケーションの脆弱性レポートを生成するように設定できます。

アプリケーションコードを保護および管理するために使用できる追加のセキュリティ機能は以下のとおりです:

パッチ管理

GitLabは、リリースおよびメンテナンスポリシーをドキュメントに記載しています。GitLabインスタンスをアップグレードする前に、利用可能なガイダンスをレビューしてください。これはアップグレードの計画、ダウンタイムなしでのアップグレード、およびその他のアップグレードパスに役立ちます。

セキュリティダッシュボードは、脆弱性データを経時的に追跡するように設定でき、脆弱性管理プログラムのトレンドを特定するために使用できます。

サプライチェーンリスク管理 (SR)

ソフトウェア部品表

GitLab依存関係スキャナーとコンテナスキャナーは、SBOMの生成をサポートします。コンテナおよび依存関係スキャンでSBOMレポートを有効にすると、顧客組織は自身のソフトウェアサプライチェーンとソフトウェアコンポーネントに関連する固有のリスクを理解できるようになります。GitLabスキャナーはCycloneDX形式のレポートをサポートします。

システムおよび通信保護 (SC)

FIPSコンプライアンス

NIST 800-53に基づくコンプライアンスプログラム（FedRAMPなど）では、適用されるすべての暗号学的モジュールにFIPSコンプライアンスが要求されます。GitLabは、FIPSバージョンのコンテナイメージをリリースし、FIPSコンプライアンス標準を満たすようにGitLabを設定する方法に関するガイダンスを提供しています。特定の機能はFIPSモードでは利用できないか、サポートされていません。

GitLabはFIPS準拠したイメージを提供していますが、基盤となるインフラストラクチャを設定し、FIPS検証済み暗号が強制されていることを確認するために環境を評価する責任は顧客にあります。

システムおよび情報整合性 (SI)

セキュリティアラート、アドバイザリ、および指令

GitLabは、ソフトウェアと依存関係に関連するセキュリティ脆弱性を追跡するためのアドバイザリデータベースを維持しています。GitLabはCVE採番機関 (CNA) です。CVE IDリクエストの生成については、このページを参照してください。

メール

GitLabは、GitLabアプリケーションインスタンスからユーザーへのメール通知の送信をサポートしています。DHS BOD 18-01ガイダンスは、スパム保護として送信メッセージ用にドメインベースのメッセージ認証、レポート、および適合性 (DMARC) を設定する必要があることを示しています。GitLabは、幅広いメールプロバイダーにわたるSMTPの設定ガイダンスを提供しており、これはこの要件を満たすのに役立つ可能性があります。

その他のサービスと概念

Runner

どのようなGitLabデプロイにおいても、様々なタスクとツールのためにRunnerが必要です。データ境界要件を維持するために、顧客は認可境界内にセルフマネージドRunnerをデプロイする必要があるかもしれません。GitLabは、Runnerの設定に関する詳細情報を提供しており、以下のような概念が含まれます:

最大ジョブタイムアウト
機密情報の保護
長時間のポーリングの設定
認証トークンセキュリティとトークンローテーション
機密情報の漏洩防止
Runner変数

APIの活用

GitLabは、アプリケーションをサポートするために堅牢なAPIセットを提供しており、REST APIとGraphQLAPIが含まれます。APIの保護は、APIエンドポイントを呼び出すユーザーとジョブの認証の適切な設定から始まります。GitLabは、アクセスを制御するためにアクセストークン（FIPSでサポートされていないパーソナルアクセストークン）とOAuth 2.0トークンを設定することを推奨します。

拡張機能

確立されているインテグレーションに応じて、拡張機能はNIST 800-53要件を満たす場合があります。たとえば、エディタとIDEの拡張機能は許容される可能性がありますが、サードパーティとのインテグレーションは認可境界要件に違反する可能性があります。顧客の認可境界外にデータがどこに送信されているかを理解するために、すべての拡張機能を検証する責任は顧客にあります。

追加リソース

GitLabは、GitLab Self-Managed顧客向けに強化ガイドを提供しており、以下のようなトピックをカバーしています:

GitLabCISベンチマークガイド - GitLabは、アプリケーションにおける強化の決定を導くためにCISベンチマークを公開しています。これは、このガイドと連携して環境をNIST 800-53コントロールに準拠して強化するために使用できます。CISベンチマークのすべての提案がNIST 800-53コントロールに直接一致するわけではありませんが、GitLabインスタンスを維持するためのベストプラクティスとして機能します。