NIST 800-53 合规性

本页面是面向希望配置 GitLab Self-Managed 实例以满足适用 NIST 800-53 控制的 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 包含一套安全工具，您可以将其整合到客户应用程序的开发中，包括但不限于：

• 安全配置
• 容器扫描
• 依赖项扫描
• 静态应用程序安全测试
• 基础设施即代码 (IaC) 扫描
• 密钥检测
• 动态应用程序安全测试 (DAST)
• API 模糊测试
• 覆盖率引导的模糊测试

除了 CI/CD 管道外，GitLab 还提供了有关如何配置发布的详细指导。发布可以通过 CI/CD 管道创建，并对存储库中任何分支的源代码进行快照。创建发布的说明包含在创建发布中。对于 NIST 800-53 或 FedRAMP 合规性，一个重要考虑因素是已发布的代码可能需要签名以验证代码的真实性，并满足系统与信息完整性 (SI) 控制家族中的要求。

访问控制 (AC) 和身份认证 (IA)

GitLab 部署中的访问管理对每个客户都是独特的。GitLab 提供了广泛的文档，涵盖与身份提供商和 GitLab 本机身份验证配置相关的部署。在确定如何访问 GitLab 实例之前，考虑组织要求非常重要。

身份提供商

GitLab 中的访问可以通过 UI 管理，也可以通过集成现有的身份提供商来管理。为了满足 FedRAMP 要求，请确保现有的身份提供商在 FedRAMP Marketplace 上获得 FedRAMP 授权。为了满足 PIV 等要求，您应该利用身份提供商，而不是在 GitLab Self-Managed 中使用本机身份验证。

GitLab 提供了配置各种身份提供商和协议的资源，包括：

• LDAP

• SAML

• 有关身份提供商的更多信息，请参见 GitLab 身份认证和授权。

GitLab 本机用户身份验证配置

账户管理和分类 - GitLab 赋予管理员跟踪具有不同敏感度和访问需求的用户的能力。GitLab 通过提供细粒度访问选项来支持最小权限和基于角色的访问的概念。在项目级别，支持以下角色：

• Guest（访客）

• Reporter（报告者）

• Developer（开发者）

• Maintainer（维护者）

• Owner（所有者）

有关项目级别权限的更多详细信息可以在文档中找到。GitLab 还支持自定义角色，以满足具有独特权限要求的客户。

GitLab 还支持以下用户类型用于独特用例：

• 审计用户 - 审计角色提供对所有组、项目和其他资源的只读访问权限，除了管理员区域和项目/组设置。当与需要访问特定项目以验证流程的第三方审计人员合作时，您可以使用审计角色。

• 外部用户 - 可以设置外部用户为可能不属于组织的用户提供有限访问权限。通常，这可用于满足管理承包商或其他第三方访问的需求。诸如 IA-4(4) 之类的控制要求非组织用户根据公司政策进行识别和管理。设置外部用户可以通过默认限制项目访问来降低组织风险，并帮助管理员识别哪些用户不被组织雇佣。

• 服务账户 - 可以添加服务账户以适应自动化任务。服务账户不占用许可证下的席位。

管理员区域 - 在管理员区域中，管理员可以导出权限、审查用户身份、管理组等等。可用于满足 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 模式时，支持使用 FIPS 兼容密码的 PBKDF2+SHA512。

• 凭据清单使管理员能够在同一位置查看 GitLab Self-Managed 实例中使用的所有密钥。凭据、令牌和密钥的汇总视图可能有助于满足诸如审查密码或轮换凭据等要求。

• 设置客户密码长度限制。FedRAMP 委托 NIST 800-63B 在 IA-5 中建立密码长度要求。GitLab 支持 8-128 个字符的密码，默认设置为 8 个字符。GitLab 提供了使用 GitLab UI 更新最小密码长度的说明，希望强制执行更长密码的组织可以使用。此外，GitLab Self-Managed 客户可以通过管理员区域 UI配置复杂性要求。

• 默认会话持续时间 - FedRAMP 规定，对于在设定时间段内不活动的用户应该注销。FedRAMP 未指定时间段，但澄清了对于特权用户，应在标准工作时段结束时注销。管理员可以建立默认会话持续时间。

• 配置新用户 - 管理员可以使用管理员区域 UI 为其 GitLab 账户创建新用户。根据 IA-5 合规性要求，GitLab 要求新用户在首次登录时更改密码。

• 取消配置用户 - 管理员能够使用管理员区域 UI删除用户。删除用户的替代方法是阻止用户并移除所有访问权限。阻止用户会保留其在存储库中的数据，同时移除所有访问权限。被阻止的用户不影响席位计数。

• 停用用户 - 在账户审查期间识别的不活动用户可以被暂时停用。停用与阻止类似，但有一些重要区别。停用用户不会禁止用户登录 GitLab UI。停用的用户可以通过登录重新激活。停用的用户：

  • 无法访问存储库或 API。

  • 无法使用斜杠命令。更多信息请参见斜杠命令。

  • 不占用席位。

其他身份认证方法

双因素身份认证 - GitLab 支持以下第二因素：

• 一次性密码验证器

• WebAuthn 设备

文档中提供了启用双因素身份认证的说明。追求 FedRAMP 合规性的客户必须考虑获得 FedRAMP 授权并支持 FIPS 要求的双因素提供商。FedRAMP 授权的提供商可以在 FedRAMP Marketplace 上找到。在选择第二因素时，NIST 和 FedRAMP 现在指示必须使用抗钓鱼身份认证，如 WebAuthn (IA-2)。

SSH 密钥

• GitLab 提供说明来配置 SSH 密钥以身份认证并与 Git 通信。提交可以被签名，为拥有公钥的任何人提供额外的验证。

• 密钥应配置以满足适用的强度和复杂性要求，例如使用 FIPS 140-2 和 FIPS 140-3 验证的密码。管理员可以限制最小密钥技术和密钥长度。此外，管理员可以阻止或禁止被入侵的密钥。

个人访问令牌

在启用 FIPS 的实例中，用于用户访问的个人访问令牌默认被禁用。

其他访问控制家族概念

系统使用通知

联邦要求通常概述了登录横幅的需求。这可以通过身份提供商和 GitLab 横幅功能进行配置。

外部连接

记录所有外部连接并确保它们满足合规要求非常重要。例如，设置与第三方的 API 集成可能会违反数据处理要求，具体取决于该第三方如何保护客户数据。在启用外部连接之前，审查所有外部连接并了解其安全影响非常重要。对于追求 FedRAMP 或类似认证的客户，连接到其他未获得 FedRAMP 授权的服务或较低数据影响级别的服务可能会违反授权边界。

个人身份验证 (PIV)

满足联邦要求的组织可能需要个人身份验证卡。为了满足 PIV 要求，GitLab 要求客户将启用 PIV 的身份解决方案与 SAML 连接。本指南前面提供了 SAML 文档的链接。

审计和问责 (AU)

NIST 800-53 要求组织监控安全相关事件、分析这些事件、生成警报并根据警报的关键性进行调查。GitLab 提供了广泛的安全事件用于监控，这些事件可以路由到安全信息和事件管理 (SIEM) 解决方案。

事件类型

GitLab 概述了可配置的审计事件日志类型，这些事件可以流式传输和/或保存到数据库中。管理员能够配置他们希望为其 GitLab 实例捕获的事件。

日志系统

GitLab 包含一个高级日志系统，可以记录所有内容。GitLab 提供了有关日志系统的指导，其中包括广泛的输出。查看链接的指导以获取更多详细信息。

流式传输事件

GitLab 管理员可以使用事件流式传输功能将审计事件流式传输到 SIEM 或其他存储位置。管理员可以配置多个目标并设置事件标头。GitLab 提供示例用于事件流式传输，其中概述了 HTTP 和 HTTPS 事件的标头、负载等。

管理员审查 FedRAMP 或 NIST 800-53 AU-2 要求并实现映射到所需审计事件类型的审计事件非常重要。AU-2 识别以下事件类别：

• 成功和不成功的账户登录事件

• 账户管理事件

• 对象访问

• 策略更改

• 特权功能

• 进程跟踪

• 系统事件

• 对于 Web 应用程序：

  • 所有管理员活动

  • 身份认证检查

  • 授权检查

  • 数据删除

  • 数据访问

  • 数据更改

  • 权限更改

管理员在 GitLab 中启用事件时，应考虑所需的事件类型以及任何额外的组织要求。

指标

除了安全事件外，管理员可能还需要了解其应用程序的性能以支持正常运行时间。GitLab 提供了支持的指标文档，这些指标在 GitLab 实例中可用。

存储

客户有责任确保日志存储在满足合规要求的长期存储解决方案中。例如，FedRAMP 要求日志存储 1 年。客户组织可能还需要满足国家档案和记录管理局的要求，具体取决于收集数据的影响级别。审查收集记录的影响并了解适用的合规要求非常重要。

事件响应 (IR)

配置审计事件后，必须监控这些事件。GitLab 提供了集中式管理界面，用于从 SIEM 或其他安全工具编译系统警报、对警报和事件进行分类、并通知利益相关者。事件管理文档概述了如何在安全事件响应组织中运行上述活动。

事件响应生命周期

GitLab 可以管理组织的事件响应生命周期。查看以下资源，这些资源可能有助于满足事件响应要求：

• 警报

• 事件

• 值班安排

• 状态页面

配置管理 (CM)

变更控制

GitLab 在其核心功能中可以满足与变更控制相关的配置管理要求。问题和合并请求是支持变更的主要方法。

问题是在实施变更之前捕获元数据和批准的灵活平台。考虑查看 GitLab 文档中关于规划和跟踪工作的内容，以全面了解如何使用 GitLab 功能来满足配置管理控制。

合并请求提供了一种将变更从源分支标准化到目标分支的方法。在 NIST 800-53 的上下文中，考虑如何在合并代码之前收集批准以及谁有权在组织内合并代码非常重要。GitLab 提供了有关合并请求中各种可用设置的指导。考虑在完成必要的审查后将批准和合并权限仅分配给适当的角色。其他需要考虑的合并设置包括：

• 当添加提交时移除所有批准 - 确保在向合并请求添加新提交时不会继承批准。

• 限制可以忽略代码变更审查的人员。

• 分配代码所有者，以便在通过合并请求更改敏感代码或配置时收到通知。

• 允许代码变更合并前确保所有开放评论都已解决。

• 配置推送规则 - 可以配置推送规则以满足诸如审查已签名代码、验证用户等要求。

变更的测试和验证

CI/CD 管道是测试和验证变更的关键组成部分。客户有责任为特定用例实施充分的测试和验证管道。在选择服务时，考虑该管道运行的位置。连接到外部服务可能会违反已建立的授权边界，其中联邦数据被允许存储和处理。GitLab 提供了配置为在启用 FIPS 的系统上运行的运行器容器镜像。GitLab 提供了管道加固指导，包括如何配置受保护分支和实施管道安全性。此外，客户可能需要考虑在合并代码之前分配必需检查，以确保在更新代码之前所有检查都已通过。

组件清单

NIST 800-53 要求云服务提供商维护组件清单。GitLab 无法直接跟踪底层硬件，但可以通过容器和依赖项扫描生成软件清单。GitLab 概述了容器扫描和依赖项扫描可以检测的依赖项。GitLab 提供了有关生成依赖项列表的额外文档，可用于软件组件清单。软件物料清单 (SBOM) 支持在本文档的供应链风险管理部分进一步介绍。

容器注册表

GitLab 提供集成的容器注册表来存储 GitLab 项目的容器镜像，这可以用作在高度虚拟化和可扩展环境中部署容器的权威存储库。容器注册表管理指导可供审查。

应急规划 (CP)

GitLab 提供了指导和帮助，可帮助满足核心应急规划要求。审查包含的文档并相应计划以满足组织对应急规划活动的要求非常重要。应急规划对每个组织都是独特的，因此在建立应急计划之前考虑组织需求非常重要。

选择 GitLab 架构

GitLab 提供了有关 GitLab Self-Managed 实例支持的架构的广泛文档。GitLab 支持以下云服务提供商：

• Azure

• Google Cloud Platform

• Amazon Web Services

GitLab 提供了决策树来帮助客户选择参考架构和可用性模型。大多数云服务提供商在其区域中为托管服务提供弹性。在选择架构时，考虑组织对停机的容忍度和数据的关键性非常重要。可以考虑 GitLab Geo 以获得额外的复制和故障转移功能。

识别关键资产

NIST 800-53 要求识别关键资产，以确保在停机期间优先恢复。需要考虑的关键资产包括 Gitaly 节点和 PostgreSQL 数据库。客户应识别需要备份或复制或其他适当方式的额外资产。

备份

文档概述了关键组件的备份策略，包括：

• PostgreSQL 数据库

• Git 存储库

• Blob

• 容器注册表

• Redis

• 配置文件

• Elasticsearch

GitLab Geo

GitLab Geo 可能是任何追求 NIST 800-53 合规性实现的关键组件。审查可用文档以确保 Geo 为每个用例正确配置非常重要。

实施 Geo 提供以下好处：

• 将分布式开发人员克隆和获取大型存储库和项目的时间从分钟级减少到秒级。

• 使开发人员能够在不同地区并行贡献想法和工作。

• 在主站点和辅助站点之间平衡只读负载。

• 除了读取 GitLab Web 界面中可用的任何数据外（参见限制），还可用于克隆和获取项目。

• 克服远程办公室之间的慢速连接，通过提高分布式团队的速度来节省时间。

• 有助于减少自动化任务、自定义集成和内部工作流程的加载时间。

• 在灾难恢复场景中可以快速故障转移到辅助站点。

• 允许计划性故障转移到辅助站点。

Geo 提供以下核心功能：

• 只读辅助站点：维护一个主 GitLab 站点，同时仍然为分布式团队启用只读辅助站点。

• 身份认证系统钩子：辅助站点从主实例接收所有身份认证数据（如用户账户和登录）。

• 直观的 UI：辅助站点使用与主站点相同的 Web 界面。此外，还有视觉通知会阻止写入操作，并明确显示用户位于辅助站点。

其他 Geo 资源：

• 设置 Geo

• 运行 Geo 的要求

• Geo 限制

• Geo 灾难恢复步骤

PostgreSQL

GitLab 提供了有关如何配置具有复制和故障转移功能的 PostgreSQL 集群的指导。根据数据的关键性和 GitLab 实例的最大可接受停机时间，考虑启用复制和故障转移来配置 PostgreSQL。

Gitaly

在配置 Gitaly 时，考虑可用性、可恢复性和弹性之间的权衡。GitLab 提供了有关Gitaly 功能的广泛文档，这些文档应有助于确定正确的配置以满足 NIST 800-53 要求。

规划 (PL)

规划控制家族包括政策、程序和其他受控文档的维护。考虑利用 GitLab 来管理受控文档的生命周期。例如，受控文档可以存储为Markdown作为版本控制状态。对文档的任何更改都必须通过合并请求进行，这会强制执行组织的批准规则。合并请求提供了对受控文档所做更改的清晰历史记录，您可以在审计期间使用它来证明文档所有者等适当人员的年度审查和批准。

风险评估和系统与信息完整性 (RA)

扫描

NIST 800-53 要求持续监控漏洞并修复缺陷。除了基础设施扫描外，像 FedRAMP 这样的合规框架已将容器和 DAST 扫描纳入月度报告要求。GitLab 提供了支持容器扫描的安全工具，包括 Trivy 和 Grype 扫描器。此外，GitLab 提供了依赖项扫描功能。GitLab 中的动态应用程序安全测试 (DAST) 可用于满足 Web 应用程序扫描要求。GitLab DAST 可以配置为在管道中运行，并为正在运行的 Web 应用程序生成漏洞报告。

可用于保护和管理工作代码的其他安全功能包括：

• 静态应用程序安全测试 (SAST)

• 密钥检测

• API 安全

补丁管理

GitLab 在文档中记录了其发布和维护策略。在升级 GitLab 实例之前，请审查可用指导，这些指导可以帮助规划升级、无停机升级和其他升级路径。

安全仪表板可以配置为随时间跟踪漏洞数据，您可以使用它来识别漏洞管理计划中的趋势。

供应链风险管理 (SR)

软件物料清单 (SBOM)

GitLab 依赖项和容器扫描器支持 SBOM 的生成。在容器和依赖项扫描中启用 SBOM 报告可以使客户组织了解其软件供应链以及与软件组件相关的固有风险。GitLab 扫描器支持 CycloneDX 格式的报告。

系统和通信保护 (SC)

FIPS 合规性

基于 NIST 800-53 的合规性计划（如 FedRAMP）要求所有适用的加密模块都符合 FIPS 标准。GitLab 已发布了其容器镜像的 FIPS 版本，并提供了有关如何配置 GitLab 以满足 FIPS 合规性标准的指导。某些功能在 FIPS 模式下不可用或不受支持。

虽然 GitLab 提供 FIPS 兼容的镜像，但配置底层基础设施和评估环境以确认强制执行 FIPS 验证的密码是客户的责任。

系统和信息完整性 (SI)

安全警报、建议和指令

GitLab 维护一个建议数据库，用于跟踪与软件和依赖项相关的安全漏洞。GitLab 是 CVE 编号授权机构 (CNA)。遵循此页面以生成 CVE ID 请求。

电子邮件

GitLab 支持从 GitLab 应用程序实例向用户发送电子邮件通知。DHS BOD 18-01 指导表明，必须为出站消息配置基于域的消息身份认证、报告和一致性 (DMARC) 作为垃圾邮件保护。GitLab 提供了跨广泛电子邮件提供商的 SMTP 配置指导，可用于帮助满足此要求。

其他服务和概念

运行器

在任何 GitLab 部署中，运行器都是各种任务和工具所必需的。为了维护数据边界要求，客户可能需要在授权边界内部署自管理运行器。GitLab 提供了有关配置运行器的详细信息，其中包括以下概念：

• 最大作业超时时间

• 保护敏感信息

• 配置长轮询

• 身份认证令牌安全和令牌轮换

• 防止泄露敏感信息

• 运行器变量

利用 API

GitLab 提供了强大的 API 集来支持应用程序，包括 REST 和 GraphQL API。保护 API 从正确配置调用 API 端点的用户和作业的身份认证开始。GitLab 建议配置访问令牌（FIPS 不支持个人访问令牌）和 OAuth 2.0 令牌来控制访问。

扩展

扩展可能满足 NIST 800-53 要求，具体取决于建立了哪些集成。例如，编辑器和 IDE 扩展可能是允许的，而与第三方的集成可能会违反授权边界要求。验证所有扩展以了解数据在客户授权边界之外发送的位置是客户的责任。

其他资源

GitLab 为 GitLab Self-Managed 客户提供了加固指南，涵盖以下主题：

• 应用程序加固建议

• CI/CD 加固建议

• 配置建议

• 操作系统建议

GitLab CIS 基准指南 - GitLab 已发布CIS 基准来指导应用程序中的加固决策。可以与本文档结合使用，根据 NIST 800-53 控制加固环境。CIS 基准中的并非所有建议都直接与 NIST 800-53 控制保持一致，但作为维护 GitLab 实例的最佳实践。