非结构化数据安全体系构建：在线文档平台元数据与签名机制深度测评与管控指南

1. 执行摘要

随着企业数字化转型的深入，非结构化数据的生产与流转已从传统的本地文件系统全面迁移至云端协作平台（SaaS）。在《非结构化数据安全体系构建》指南中，我们确立了以**XMP（Extensible Metadata Platform）为核心的元数据驱动防御和以PAdES（PDF Advanced Electronic Signatures）**为基础的防篡改体系 1。然而，当这一理论框架遭遇腾讯文档、企业微信（微文档）、石墨文档及Office 365等主流在线文档平台时，面临着从“文件本位”向“数据流本位”的深刻范式转移。

本报告作为上述指南的深度补充，以网络安全专家的视角，对上述平台在元数据持久化嵌入、数字签名完整性保护及跨平台流转控制方面的能力进行了详尽的穿透式分析。研究发现，虽然Office 365通过MIP（Microsoft Purview Information Protection）实现了元数据与云端协作的高度融合，但在国产SaaS平台中，普遍存在着“元数据气隙（Metadata Air Gap）”现象——即文件在云端以数据库记录形式存在时具备权限控制，一旦导出为实体文件，其安全属性往往随之剥离。此外，数字签名机制在SaaS环境中常异化为视觉层面的“电子印章”，缺乏底层PAdES-LTA（长期归档有效性）标准的密码学支撑。

基于此，本报告不仅揭示了各平台的技术底座差异，更提出了一套针对性的“在线文档安全管控架构”。该架构主张通过API网关拦截、中间件注入及终端驱动联动等手段，强制弥合SaaS平台与本地文件安全标准之间的裂痕，确保数据无论在云端协作还是落地分发，始终处于可识别、可验证、可追溯的受控状态。

2. 绪论：云协作时代的元数据“气隙”风险

在深入剖析具体平台之前，必须厘清云协作环境对传统非结构化数据安全模型构成的本质挑战。这种挑战并非源于加密算法的强弱，而在于数据形态的根本性变化。

2.1 从“黑盒”到“玻璃盒”的形态演变

在本地环境中，一个Word文档或PDF文件是一个独立的二进制容器（BLOB），我们称之为“黑盒”。安全策略（如XMP标签、数字签名）像纹身一样刻在容器表面 1。然而，当文件上传至腾讯文档或石墨文档时，它被解析、拆分并存入NoSQL或关系型数据库中。此时，文档变成了一个“玻璃盒”——由无数个数据库字段（行、列、段落对象）动态渲染而成的视图。

这种形态转换带来了元数据持久性的断裂。在云端，文件的密级可能只是数据库中的一个字段（如permission_level: “secret”） 2。当用户执行“下载”或“导出”操作时，平台需要实时生成一个新的二进制文件。如果导出引擎没有被明确编程以将数据库中的密级字段映射回XMP标准头部，那么下载下来的文件就是“裸奔”的——失去了所有安全上下文。这就是本报告所定义的“元数据气隙”。

2.2 在线环境下的PAdES签名困境

PAdES标准的核心要求是基于文件内容的哈希值进行密码学签名，并将验证数据（CRL、OCSP响应）嵌入文件本身以实现长期有效性（LTV） 1。在SaaS环境中，浏览器无法直接调用用户的本地USB Key（U盾）进行私钥运算，导致必须依赖**远程签名（Remote Signing）**服务。

这引入了两个核心风险点：

1. 1. 内容一致性风险： 用户在浏览器中看到的渲染内容，与服务器后台用于计算哈希的二进制流是否完全一致？所见即所签（WYSIWYS）在Web环境下极难严格保证。
2. 2. 密钥托管风险： 为了便捷，私钥往往托管在云端。虽然腾讯电子签等平台使用了区块链存证技术 4，但这与标准的PAdES-LTA嵌入式验证机制在技术路线上存在分歧，导致导出的PDF文件在脱离平台环境后，可能无法在Adobe Reader等标准阅读器中验证其完整性 5。

3. 深度测评：Microsoft 365 (MIP) 的元数据原生融合

在所有受测平台中，Microsoft 365（以下简称O365）凭借其对OOXML文件格式标准的掌控力及Microsoft Purview Information Protection（MIP）体系的深度集成，展现了最为成熟的元数据安全能力。它通过重构底层存储机制，有效解决了“协作”与“加密”的天然矛盾。

3.1 元数据架构的演进：从 Custom XML 到 LabelInfo.xml

在早期的Office版本中，自定义元数据通常存储在OOXML（ZIP容器）内的custom.xml部件中 6。然而，这种方式在多人实时协作（Co-authoring）场景下存在严重的锁冲突问题。为了支持在加密文档上进行多人同时编辑，微软对元数据存储架构进行了根本性的重构。

3.1.1 协同编辑下的元数据持久化

O365引入了新的元数据存储位置。当租户开启“支持敏感度标签文件的协同创作”功能后，标签信息不再存储于传统的自定义属性中，而是写入到OPC（Open Packaging Conventions）结构下的docMetadata文件夹内的labelinfo.xml文件中 7。

这种架构变革带来了深远的安全意义：

• • 细粒度同步： labelinfo.xml允许元数据作为一个独立的流参与到FRS（File Replication Service）的同步机制中，避免了因修改元数据而锁定整个文件内容。
• • 跨平台一致性： 无论是Web端（Word Online）、桌面端还是移动端，应用程序都统一读写这一标准位置。DLP扫描引擎只需解压ZIP包并解析此XML文件即可获取密级信息，无需完全渲染文档内容 8。
• • 属性映射： 系统会将标签的GUID、租户ID（Tenant ID）以及分配方式（手动或自动）写入该文件。例如，一个标记为“绝密”的文档，其XML中会包含<Label id=”GUID” method=”Privileged”…> 9。

3.1.2 跨租户流转的元数据生存能力

O365的一个显著优势是元数据在邮件流转中的生存能力。当一个带有敏感度标签的文档作为附件发送时，Exchange Online会将标签元数据提取并注入到邮件头（Message Headers）中的msip_labels字段 9。
这实现了防御前置：接收方的邮件网关（SEG）在接收邮件数据包的握手阶段，即可通过解析头部信息识别出附件的密级，从而在文件落地前实施拦截或隔离策略。这种“元数据外显”的设计，完美契合了零信任架构下的持续验证原则。

3.2 PDF导出的PAdES支持与XMP注入

在将Office文档转换为PDF的过程中，O365表现出了对标准的严格遵循，但需依赖特定的配置。

• • XMP注入机制： 当用户在Word Online中使用“另存为PDF”功能时，系统会自动将源文档的MIP敏感度标签映射为PDF的XMP元数据。具体而言，它会将标签名称和GUID写入PDF的自定义属性中，使得支持MIP的PDF阅读器（如Adobe Acrobat）能够识别并显示红色的保护横幅 10。
• • 策略强制： 为了防止用户通过“打印到PDF”这一非结构化路径绕过元数据注入（打印操作本质上是生成图片流，会丢失所有语义元数据），O365允许管理员通过组策略或云策略禁用“打印到PDF”功能，强制用户使用保留元数据的“导出”功能 11。
• • PAdES签名集成： O365本身不作为PAdES的签发机构（CA），但其架构允许集成Adobe Sign或DocuSign。当通过这些插件签署文档时，它们会生成符合PAdES-LTA标准的签名包，并将其回写到SharePoint存储中 12。

3.3 存在的安全敞口与应对

尽管架构先进，但O365仍存在特定配置下的敞口：

• • 旧版客户端兼容性： 如果组织内存在不支持新版元数据结构的旧版Office客户端，协同编辑可能会失败，或者元数据在保存时被剥离。
• • 第三方云存储： 当文件流转至非微软生态（如存入Google Drive）再被编辑时，labelinfo.xml可能被视为冗余数据而被清理。
• • 管控建议： 必须在SharePoint管理中心通过PowerShell指令Set-SPOTenant -EnableSensitivityLabelForPDF $true显式开启PDF元数据强制注入功能 13，并配合端点DLP监控非Office进程对labelinfo.xml结构的修改行为。

4. 深度测评：腾讯生态（文档与企业微信）的边界防御体系

与微软的“文件中心”策略不同，腾讯生态采用了典型的“平台中心”安全模型。其安全核心在于身份认证（微信体系）和访问控制列表（ACL），而非将安全属性强绑定于文件本身。

4.1 腾讯文档的元数据机制

腾讯文档本质上是一个在线的多人实时协作数据库应用。

• • 云端元数据（Cloud Metadata）： 通过分析腾讯文档的API接口（如WEDRIVE接口），我们发现其文件的权限、归属、密级等信息均作为对象属性存储在云端数据库中 14。例如，通过API获取文件详情时，可以读取到custom_properties字段 2。这些属性在腾讯云COS（对象存储）层面可能有对应的Tags或Metadata映射 16。
• • 导出过程中的元数据丢失（The Drop）： 关键的安全隐患发生在导出环节。目前的测试和文档分析显示，当用户将腾讯文档导出为本地.docx或.pdf文件时，系统主要关注内容的视觉还原。虽然文档标题、作者等基础信息会被保留 18，但通过API设置的自定义安全属性（如“绝密”标签）并没有被自动映射到下载文件的XMP头部或Office自定义属性中。
• • 后果： 一个在腾讯文档云端被严格限制访问的文件，一旦被有权限的用户下载到本地，就变成了一个没有任何安全标记的普通文件，能够轻松绕过基于标签的本地DLP检查。

4.2 腾讯电子签（Tencent Qian）与数字签名

腾讯电子签是腾讯生态中处理签名的核心组件，其技术路线具有鲜明的中国特色，即“国密合规”与“区块链存证”。

• • 算法与合规性： 腾讯电子签严格遵循《中华人民共和国电子签名法》，采用SM2（椭圆曲线公钥密码算法）和SM3（杂凑算法）进行数字签名 5。这在合规性上优于使用RSA算法的通用PAdES方案。
• • PAdES兼容性挑战： 虽然SM2算法安全性极高，但它并非国际通用的PDF阅读器（如未经配置的Adobe Reader）默认信任的算法。这导致导出的已签署PDF文件在部分国际化软件中可能显示“签名有效性未知”。
• • 存证链（Evidence Chain）模式： 腾讯更倾向于使用区块链技术来确保证据链的完整性 4。签名的哈希值被上链存储，验证时通过云端查验。这种模式与PAdES-LTA强调的“离线自包含验证”（即所有验证证据都打包在PDF文件内部）存在逻辑上的差异。对于高度依赖离线存档的涉密场景，这种依赖云端验证的机制可能存在长期可读性风险。

4.3 企业微信（WeCom）的沙箱防御

面对元数据落地丢失的风险，企业微信采取了“不落地”的防御策略。

• • 微盘与安全沙箱： 企业微信微盘实际上构建了一个受控的容器环境。通过开启“文件防泄漏”模式（保密模式），管理员可以禁止文件的下载、导出和外部转发 19。
• • 水印与审计： 既然无法保证文件离境后的安全，企业微信转而强化事中和事后的威慑。强制明/暗水印（Watermarking）和详尽到“谁在何时查看了哪一页”的审计日志（Audit Logs），构成了其安全体系的最后一道防线 20。
• • 局限性： 这种沙箱模式极其依赖客户端的完整性。一旦攻击者通过截屏（尽管有防截屏机制，但无法防御物理拍摄）或内存Dump方式提取内容，由于缺乏内嵌的XMP元数据，泄漏的数据将难以被自动化系统识别和追溯。

5. 深度测评：石墨文档的API开放性与流转安全

石墨文档（Shimo Docs）在架构上介于Office 365与腾讯文档之间，其私有化部署版本（Private Deployment）提供了较高的API开放度，为企业自定义安全控制提供了可能。

5.1 API 级元数据管理

石墨文档的SDK和API设计允许开发者对文件属性进行深度操作。

• • 自定义属性（Custom Properties）： 石墨的API支持props:<key>格式的自定义文件属性设置 2。这允许企业在云端为文件打上“项目代号”、“保密期限”等标签。
• • 导出接口的可拦截性： 与腾讯文档类似，石墨的标准导出功能默认不包含自定义XMP注入。但是，其POST /files/v1/export/{fileId}接口是异步执行的，并返回下载链接 21。
• • 安全机会： 对于私有化部署客户，这意味着可以在导出服务（Export Service）和最终用户之间插入一个API网关。当导出任务完成后，网关可以先获取文件流，读取云端的custom_properties，利用Python脚本（如python-xmp-toolkit）将这些属性写入文件XMP，然后再将处理后的文件返回给用户。这是弥补SaaS元数据气隙的关键路径。

5.2 第三方签名集成模式

石墨文档自身不扮演CA角色，而是通过集成法大大、上上签等第三方服务商来实现电子签名功能。

• • 流转风险： 在这种模式下，文档从石墨流转至签名平台的过程中，元数据的传递至关重要。如果API调用仅传输了PDF的视觉版式（Layout），而未传输元数据（Metadata），签完名的文件归档时就会丢失密级信息。
• • 集成建议： 在调用第三方签名API时，必须检查该服务商是否支持“元数据透传（Metadata Passthrough）”或PAdES标准的自定义属性写入。如果不支持，企业需在签名文件回传至石墨系统后，立即启动一个后处理任务，重新将安全标签“补录”进已签名的PDF中。

6. 平台能力横向对比与差距分析

为了直观展示各平台对《非结构化数据安全体系构建》指南中核心要求的支持情况，特编制如下对比分析表。该表重点关注元数据在从云端到本地转换过程中的生存能力，以及签名的标准化程度。

分析结论：

• • Office 365 是目前唯一能够开箱即用实现“元数据驱动安全”闭环的平台。其文件格式的所有权使其能够将安全元数据植入文件基因。
• • 腾讯生态 走的是“零信任沙箱”路线。它不试图保护满世界乱跑的文件，而是试图建立一个文件跑不出去的安全围栏（企业微信）。这在封闭生态内极其有效，但在跨供应链协作中面临挑战。
• • 石墨文档 的价值在于其API的可编程性。对于有开发能力的安全团队，石墨提供了手动构建XMP注入网关的接口基础，适合需要高度定制化的场景。

7. 补充指南：在线文档安全管控架构设计

鉴于上述分析中暴露出的“元数据气隙”问题，单纯依赖平台原生设置无法满足高等级安全需求。企业安全架构师需构建一套叠加的管控架构，通过技术手段强制实现元数据的落地注入与签名的合规化。

7.1 架构一：元数据注入网关（The Metadata Injection Gateway）

针对腾讯文档和石墨文档导出文件丢失标签的问题，建议部署一层API网关作为唯一的“文件出口”。

• • 实施逻辑：
1. 1. 权限收敛： 在SaaS平台管理后台，关闭普通用户的“直接下载”和“导出”权限，仅保留“在线预览”和“编辑”权限 20。
2. 2. 构建中间件： 开发一个企业内部的“安全下载插件”或Web门户。
3. 3. API 联动流程：
• • 用户请求下载 -> 中间件调用SaaS API（如石墨 GET /files/{id}）获取文件流。
• • 中间件同步调用元数据API（如腾讯 WEDRIVE 或石墨 custom_props）获取该文件的密级（例如 Level: Confidential） 14。
4. 4. 实时注入（The Injection）： 中间件服务器使用 Python-XMP-Toolkit 或 ExifTool，在内存中将获取到的密级信息写入文件流的XMP标准头部（esec:Classification）。
5. 5. 文件交付： 将处理后的、带有XMP“纹身”的文件流返回给用户浏览器。
• • 价值： 确保所有落地文件均带有可被终端DLP识别的安全标签，填补了SaaS与本地安全之间的鸿沟。

7.2 架构二：审计日志锚定（Audit Log Anchoring）

针对PAdES-LTA签名难以在Web端实时生成的问题，利用SaaS平台的不可篡改日志构建“逻辑签名”。

• • 实施逻辑：
1. 1. 哈希上链： 开发定期任务，通过API获取核心文档的版本哈希值（Hash）。
2. 2. 存证关联： 将文件哈希值与SaaS平台的审计日志（Who, When, What）进行关联，并将此组合信息写入企业内部的WORM（Write Once Read Many）存储或区块链节点。
3. 3. 验证机制： 当需要验证导出的本地文件是否被篡改时，计算本地文件哈希，并与存证系统中的记录比对。
• • 价值： 虽然文件本身可能缺乏PAdES嵌入式数据，但通过外部存证链实现了同等效力的完整性校验与不可抵赖性，且规避了复杂的PKI密钥管理问题。

7.3 架构三：终端驱动的“落地即加密”（Terminal Catch-and-Tag）

如果无法部署网关，可利用终端安全软件（基于Minifilter驱动）进行补救。

• • 实施逻辑：
1. 1. 流量嗅探/域识别： 终端驱动监控浏览器进程，识别来自特定SaaS域名（如 docs.qq.com, shimo.im）的数据流写入操作。
2. 2. API 反查： 一旦检测到文件生成（IRP_MJ_CREATE），Agent立即挂起文件句柄，并通过文件名或URL调用SaaS平台的Open API查询该文件的密级属性。
3. 3. 本地补标： Agent在本地文件系统层面上，将查询到的密级写入文件的ADS（交换数据流）或直接修改文件头注入XMP。
4. 4. 放行： 写入完成后释放句柄，允许用户访问。
• • 价值： 在不改变用户习惯且无需改造SaaS平台的前提下，实现了“下载即打标”的自动化管控。

7.4 针对PAdES签名的合规化改造建议

对于涉及跨境业务或需满足长效法律效力的合同文档：

• • 强制转换： 建议引入本地签名服务器。文件从SaaS导出后，必须经过签名服务器。服务器调用硬件安全模块（HSM）中的机构私钥，对PDF进行符合PAdES-LTA标准的重签名，嵌入可信时间戳（TSA）和吊销列表（CRL）。
• • 双重签名： 对于国内业务，保留腾讯电子签的SM2签名以满足《电子签名法》；同时叠加一层PAdES签名以满足国际通用的文档完整性验证需求。

8. 结论

在线文档平台的普及使得非结构化数据的安全边界变得模糊。虽然Microsoft 365通过MIP体系实现了从云端到本地的元数据闭环，但对于广泛使用的腾讯文档、石墨文档等国产SaaS平台，企业不能默认其导出的文件具备安全自证能力。

“元数据气隙”是当前SaaS数据安全的最大隐患。

要构建真正健壮的非结构化数据安全体系，企业必须从“被动依赖”转向“主动干预”。通过部署API级元数据注入网关，实施审计日志锚定，以及利用终端驱动进行落地补救，企业可以强制将SaaS平台灵活的协作能力纳入到严谨的XMP/PAdES安全框架中。这不仅是技术的堆叠，更是数据主权的回归——确保无论数据流向何方，其安全属性始终如影随形，不可剥离。

Works cited

1. 1. 非结构化数据安全体系构建
2. 2. Metadata | Cloudreve, accessed December 16, 2025, https://docs.cloudreve.org/en/api/metadata
3. 3. PDF Advanced Electronic Signature (PAdES) – eSignGlobal, accessed December 16, 2025, https://www.esignglobal.com/glossary/pades-advanced-electronic-signature-v4
4. 4. 电子签名-电子合同 – 腾讯电子签, accessed December 16, 2025, https://qian.tencent.com/mulESign
5. 5. 电子签名揭秘：了解PAdES如何确保PDF签名的安全性 – eSignGlobal, accessed December 16, 2025, https://www.esignglobal.com/zh-CN/blog/PAdES-for-PDF
6. 6. Bind content controls to custom XML parts in Visual Studio – Microsoft Learn, accessed December 16, 2025, https://learn.microsoft.com/en-us/visualstudio/vsto/walkthrough-binding-content-controls-to-custom-xml-parts?view=visualstudio
7. 7. New metadata model MIP – Information security and compliance, accessed December 16, 2025, https://alberthoitingh.com/2021/12/01/new-metadata-model-mip/
8. 8. Enable co-authoring for files encrypted with sensitivity labels – Microsoft Learn, accessed December 16, 2025, https://learn.microsoft.com/en-us/purview/sensitivity-labels-coauthoring
9. 9. Purview under the hood: the cross-tenant quirks of sensitivity labeled content – Seppala365.cloud, accessed December 16, 2025, https://seppala365.cloud/2025/02/15/purview-under-the-hood-the-cross-tenant-quirks-of-sensitivity-labeled-content/
10. 10. Apply sensitivity labels to PDFs created with Office apps – Microsoft Community Hub, accessed December 16, 2025, https://techcommunity.microsoft.com/blog/microsoft365insiderblog/apply-sensitivity-labels-to-pdfs-created-with-office-apps/4214665
11. 11. Print to PDF is blocked if Mandatory Labeling is enabled – Microsoft Support, accessed December 16, 2025, https://support.microsoft.com/en-us/office/print-to-pdf-is-blocked-if-mandatory-labeling-is-enabled-328c575c-9db9-4879-953b-a5e176f61e78
12. 12. pades pdf advanced electronic signature – eSignGlobal, accessed December 16, 2025, https://www.esignglobal.com/blog/pades-standard-pdf-advanced-electronic-signature
13. 13. Enable sensitivity labels for files in SharePoint and OneDrive | Microsoft Learn, accessed December 16, 2025, https://learn.microsoft.com/en-us/purview/sensitivity-labels-sharepoint-onedrive-files
14. 14. 获取文件列表- 文档- 企业微信开发者中心, accessed December 16, 2025, https://developer.work.weixin.qq.com/document/path/93657
15. 15. 配置可调用微盘接口的应用 – 企业微信开发文档, accessed December 16, 2025, https://developer.work.weixin.qq.com/document/path/93654
16. 16. Inventory Overview – Tencent Cloud, accessed December 16, 2025, https://www.tencentcloud.com/document/product/436/30622
17. 17. Copying and Moving Objects – Tencent Cloud, accessed December 16, 2025, https://www.tencentcloud.com/document/product/436/44872
18. 18. Quick Tip: Beware of Metadata in PDF Exports, accessed December 16, 2025, https://kleiber.me/blog/2019/07/12/quick-tip-beware-pdf-export-metadata/
19. 19. 安全高级功能介绍, accessed December 16, 2025, https://open.work.weixin.qq.com/help2/pc/20783
20. 20. 如何设置微盘权限, accessed December 16, 2025, https://open.work.weixin.qq.com/help2/pc/15301
21. 21. 文件操作| 石墨文档中台, accessed December 16, 2025, https://open.shimo.im/docs/SDK-3.12/apis/file
22. 22. 石墨API 列表| 石墨文档中台, accessed December 16, 2025, https://open.shimo.im/docs/SDK-3.10/apis