CUI 保护：安全处理受控非密信息

受控非密信息（Controlled Unclassified Information，CUI）是敏感但未归类为机密的信息，依据联邦法律、法规或政府通用政策，需要采取保护或限制传播的控制措施。对于国防、能源、医疗等其他受监管领域中的联邦机构和承包商而言，妥善处理 CUI 的义务具有重大的合规与合同影响。

然而，许多组织仍然缺乏满足联邦要求所需的流程、系统控制以及可视性。随着 CMMC 第 1 阶段的实施 正在推进，政府也正通过 FAR CUI rule 向更统一的承包商处理要求迈进，CUI 合规已不再只是“理想目标”。它已成为合同前提条件。

无法证明对 CUI 进行恰当的识别、标记、保护和分发控制的组织，可能面临不利的审计发现、合同延迟，以及丧失未来奖项的资格。

本指南将解析 CUI 到底是什么、保护要求具体是什么，以及如何制定切实可行的方案来安全地处理 CUI。

受控非机密信息（Controlled Unclassified Information，CUI）是什么？

受控非机密信息（CUI）是指联邦政府创建或持有的信息，或由某机构代表政府创建或持有的信息；这些信息需要按照适用的法律、法规以及政府层面的政策进行保护或分发控制。

作为正式的信息类别，CUI 由 Executive Order 13556 设立，并在 32 CFR Part 2002 中编入。它用一个单一且一致的框架，取代了 FOUO、LES 和 SBU 等零散的旧式标记体系，以便在联邦机构及其承包商之间对敏感但非机密的信息进行保护。

支撑整个项目的关键原则是：只有依据联邦法律、法规或政府范围内政策需要进行保护的信息，才能被指定为 CUI。机构不得仅凭行政偏好自行创建 CUI 类别。

CUI 分为两类处理类别：

• CUI Basic 是默认设置。除非 NARA CUI Registry 明确对某一类别标注为 CUI Specified，否则会将 32 CFR Part 2002 的统一标准应用于所有 CUI。横幅标记看起来像 CUI 或 CUI//PRVCY。
• CUI Specified 适用于授权法律或法规中包含特定的处理控制措施（且与 CUI Basic 默认值不同）的情况。这些类别带有“SP-”前缀，例如 CUI//SP-CTI。

差异在于控制措施的来源，而不是敏感度级别；当特定主管部门保持沉默时，CUI Basic 会填补其中的空白。

NARA CUI Registry 是权威来源，涵盖 125+ 个类别。合同方应到这里确定其遇到的任何 CUI 的正确分类、标记和处理方式。

常见的 CUI 示例

并非所有 敏感数据 都是 CUI；它必须与 CUI Registry 中列出的某个主管机构相对应。以下是按主要类别归纳的常见 CUI 示例：

• 国防（CTI）： 受控技术信息（CTI）包括技术示意图、系统设计文档以及为军事应用开发的源代码，并在 DFARS 252.204-7012 的主管机构授权下标记为 CUI//SP-CTI。
• 出口管制： 涉及美国军火清单（U.S. Munitions List）中防务物项的技术图纸，以及需经过出口许可的技术数据，均归入 CUI Registry 的出口管制类别。
• 执法： 犯罪记录信息、DNA 鉴定资料以及线人身份识别数据，出现在与执法相关的 CUI 类别下。
• 隐私： 社会保障号码、金融账户号码、生物识别数据以及 HIPAA 覆盖的健康信息，归入与隐私/健康相关的 CUI 类别进行处理。
• 关键基础设施： 化学恐怖主义脆弱性信息、关键能源基础设施信息以及信息系统脆弱性信息，出现在关键基础设施类别下。

这些示例仅用于说明，并非最终定论。在您制定处理规则之前，请始终在 CUI Registry 和合同条款中核实具体类别、授权方以及所需标记。

关键的 CUI 保护要求

保护 CUI 不仅仅是把文件锁起来。它涵盖标记（打标）、物理与数字层面的防护，以及控制谁可以访问并共享信息。每个领域都包含特定的联邦要求，任何一个方面的缺口都可能削弱你整体的合规态势。下面是你需要在三大核心保护支柱上做到位的内容。

标记与标识 CUI

标记不一致是导致合规评估失败的最快方式之一。标记贯穿整个 CUI 处理链条：它们告诉获授权的持有者，谁可以访问信息、信息可以如何共享，以及适用哪些保护措施。

标准标记示例：

• 无类别的 CUI Basic：CUI
• 已指定的 CUI：CUI//SP-CTI
• 带有传播控制的已指定 CUI：CUI//SP-SGI//FEDONLY

在实践中，准确的横幅标识以及一致的下游标注（邮件主题、文件页眉、封面页和存储库）正是防止 CUI 泄露到不受控制的渠道中的关键。

每份 CUI 文件都必须包含用于标识主管机构的指定指示（designation indicator）。相关指导还建议：当邮件包含 CUI 时，在邮件的主题行和正文中应用 CUI 横幅标识。

保护措施与受控环境

CUI 必须在具备充分 访问控制 的受控环境中处理，并采取防止未经授权查看或偷听的保护措施。

NIST SP 800-171 Rev. 1 确立了基线：CUI 的机密性影响值不低于 FIPS 199 中等（moderate）。根据 FIPS 199，中等表示机密性丧失“预计可能对组织运作、组织资产或个人产生严重的不利影响”。

组织必须在 System Security Plan (SSP) 中描述其 CUI 系统边界，包括运行环境、要求如何被实施，以及与其他系统的连接方式。

物理安全要求包括：将访问限制为授权人员、对访客进行陪同、维护访问审计日志，以及在替代工作地点执行安全防护措施。

访问控制和传播（发布）控制

CUI 的访问遵循一条清晰的原则：只有获得授权、具有合法“知悉必要性（need-to-know）”并接受过适当培训的用户才能访问。

NIST SP 800-171 Rev. 3 强化了账号管理，要求明确允许的账号类型，基于有效的“知悉必要性（need）”和预定用途授权访问，并对系统账号的使用情况进行持续监控。

根据 32 CFR 2002.16 ，传播必须遵守制定 CUI 类别的相关法律，应服务于合法的政府目的，且不得受到已授权的有限传播控制的限制。

在与外部各方共享 CUI 之前，请核实接收方是否具有合法的“知悉必要性（need-to-know）”，是否理解 CUI 的要求，并且能够对信息进行适当保护。

这里的培训同样至关重要。2025年1月的 FAR CUI 规则规定，承包商不得允许任何员工在未完成适当培训的情况下处理 CUI；并且在被要求时，承包商必须提供培训证明。

CUI 和网络安全框架

CUI 的保护义务并非孤立存在。它们位于由多个联邦网络安全框架构成的分层体系之中，这些框架会将政策要求转化为具体且可审计的安全控制。

理解这些框架如何相互衔接，对于构建合规环境至关重要；尤其是在不同合同引用不同版本或基线的情况下。

NIST SP 800-171 与 CUI

NIST SP 800-171 将 CUI 的保护义务转化为适用于非联邦系统的具体安全要求。当前版本 Rev. 3 包含 17 个控制族中的 97 项安全要求。Rev. 2 则在 14 个控制族中包含 110 项要求。

直接影响 CUI 处理的关键领域包括：

• 访问控制： 账户管理、最小特权、职责分离、信息流控制
• 审计与责任追究： 审计日志需记录事件类型、时间、来源、结果以及身份；保留期限应与组织和合同要求保持一致
• 事件响应： 在组织定义的频率下开展运维处理能力、跟踪和测试
• 媒体保护： 处置前进行清除（消除数据），运输过程中进行加密保护

将这些领域合在一起，它们界定了审计人员在评估 CUI 处理是否真正得到落实（而不只是被记录）时所关注的日常运营控制措施。

FIPS 199 影响级别与 CUI

合规“传导链”是这样运作的：FIPS 199 对影响级别进行分类，FIPS 200 制定最低安全要求，而控制选择则来自 NIST 安全控制基线。随后，这些基线会针对处理 CUI 的非联邦组织被定制为 NIST SP 800-171。

实际影响十分显著：

• 云托管： 对于云环境中的 CUI 系统，FedRAMP Moderate 通常被视为中等影响信息系统的最低适当基线。
• 加密： 密码学模块必须通过 FIPS 140-2 验证，而不仅仅是使用经 FIPS 批准的算法。NIST 的 CMVP 指南也指出，未经验证的密码学被视为不提供任何保护。
• 网络防护： 中等基线涵盖访问控制、边界防护、网络隔离、传输机密性与完整性，以及网络监测。

对于与关键项目或高价值资产相关的 CUI，NIST SP 800-172 提供增强的安全要求，但仅在合同语言中明确指定时才适用。

安全处理 CUI 的最佳实践

以下最佳实践将 CUI 合规义务转化为团队可以立即采取的具体步骤：从最初的数据发现，到访问治理、加密以及事件响应。

1. 准确识别并分类 CUI

只有联邦机构才能将信息指定为 CUI。当承包商遇到可能未标记的 CUI 时，应将其报告给合同官（Contracting Officer）以便做出官方认定，而不是由承包商自行标记。FAR CUI 规则要求在发现潜在 CUI 后八小时内进行报告。

从逐份合同审查开始。将每份合同中规定的 CUI 类别映射到你们实际的信息流。常见的范围界定失败包括：

• 缺失的系统： 未能识别在主要环境之外处理 CUI 的系统
• 第三方盲区： 未能考虑代表你接触 CUI 的服务提供商
• 影子 IT： 忘记考虑协作工具和云服务——CUI 可能最终落在这些地方

培训同样重要，应在三个层级开展：

• 全面认知： 面向所有可能接触 CUI 的人员
• 岗位/角色专属培训： 面向经常处理 CUI 的员工
• 高级技术培训： 面向管理 CUI 环境的系统管理员

对培训的投资至关重要，因为人为因素仍然是首要漏洞；根据 Netwrix 2024 Hybrid Security Trends Report 的数据，47% 的 IT 专业人士将员工的错误和疏忽视为首要安全挑战。

发现（识别）方面的挑战同样普遍；由 Netwrix 赞助的 2025 SANS Attack Surface Management (ASM) Survey 显示，只有 28% 的组织认为其 ASM 平台能够有效识别敏感文件；另有 41% 表示只能部分识别。

这正是工具发挥真正作用的地方。例如，First National Bank Minnesota 使用 Netwrix Auditor 和 Netwrix Data Classification 来发现、分类并将敏感数据迁移到安全位置，并将 Active Directory 重建从原本的 6 个月缩短到 3 周完成。

2. 在对象级别上治理访问权限

文件夹级别和站点级别的权限对 CUI 来说不够细粒度。NIST SP 800-171 承认，可以在应用程序和服务级别实现访问强制机制，以提高对 CUI 的保护。

属性型访问控制（ABAC）（如 NIST SP 800-162 所定义）会在每次访问请求时，将用户、数据和环境的属性与已定义的策略规则进行比对评估。对 CUI 而言，其优势在于动态最小权限：

• 角色变更： 当某人的任务分配发生变化时，其对不再需要的 CUI 的访问会通过更新后的主体属性自动撤销
• 分类变更： 当数据分类发生变化时，无需手动重新配置即可在所有受影响用户之间自动调整访问限制

3. 对传输中和静态存储中的 CUI 进行加密

NIST SP 800-171 要求对在受控环境之外传输或存储的 CUI 进行加密。在受保护的环境中，其他防护措施可能满足该要求，但任何离开该边界的 CUI 都必须加密

关键要求是：加密模块必须通过 FIPS 140-2 验证，并在文档中记录证书编号。如果特定模块没有经过 NIST 的 Cryptographic Module Validation Program，仅使用 AES-256 也不够。

密钥管理同样值得同等关注，因此应将其视为基础设施，而不是事后考虑。

4. 监控、记录并响应事件

NIST SP 800-171 要求审计记录能够记录事件类型、时间、地点、来源、结果以及关联的身份。必须能够对单个用户的操作进行唯一追踪，并且审计记录的保留期限应与组织定义的要求以及合同定义的要求保持一致。

在事件响应中，时间线变得越来越紧迫。根据你的行业不同，适用的报告义务也会有所差异：

• FAR CUI 规则： 在 8 小时内报告疑似或已确认的 CUI 事件
• DFARS 252.204-7012： 国防部（DoD）承包商通过 DIBNet 报告
• CIRCIA： 关键基础设施实体必须在 72 小时内向 CISA 报告

要满足这些时间要求，需要具备取证能力，并准备好预先制定的调查流程，而不仅仅是检测。

将活动数据与访问权限关联起来，这里会立刻见效。在真实世界中，即使只有一次可疑的文件变更激增，如果你的团队必须从彼此割裂的日志中拼凑出答案，那么这件事也可能会演变成持续数天的“手忙脚乱”。

Netwrix 如何帮助组织保护 CUI

没有任何单一流程或清单能够让 CUI 合规在一夜之间实现。对承包商而言，挑战在于：在不拼接那些彼此割裂、从而会留下评估人员发现的漏洞的工具的前提下，将数据发现、访问治理和审计就绪之间的“点”真正连起来。

如果你的环境基于 Microsoft 基础设施，并同时包含本地文件服务器、Active Directory 和 Microsoft 365，那么你需要一个平台，能够从同一个地方覆盖全部内容。

The 1Secure Platform 可在文件系统、数据库、协作平台和云存储等范围内提供自动化发现，让你能够在评估人员之前找到与 CUI 相关的数据。

它可以将敏感文件隔离在不安全的位置，把它们移动到安全区域，移除过度的权限，并将 classification tags 嵌入到文件中，把数周的手动盘点变成自动化、可重复的流程。

但仅靠发现并不够。更棘手的问题是：谁可以访问这些数据、该访问是否恰当，以及你能否证明这一点？1Secure Platform 会报告过度暴露的敏感数据对象、已分类内容的详细权限结构，以及与敏感文件和文件夹相关的活动。

这意味着你可以识别权限过度的情况下 CUI 位于哪里，并在其成为审计发现之前进行整改。

Netwrix Endpoint Protector 将这一覆盖范围扩展到终端层，防止 CUI 通过未经授权的渠道离开受控环境。它会阻止向未批准的 USB 设备传输数据，并监控和控制通过浏览器、电子邮件客户端以及云存储应用程序进行的上传。它还会对已批准的可移动介质强制执行加密，从而直接应对 CUI 处理要求旨在防止的外泄风险。

现成的合规报告可以显示谁访问了数据、发生了哪些更改以及时间点，而交互式搜索帮助你在几分钟内而不是几天内回答审计人员的问题。

申请 Netwrix 演示 了解一个平台如何帮助您在混合环境中发现、保护并证明 CUI 的合规性。