1. 需求拆解信创办公场景里导入Word和国产密码是怎么绑在一起的1.1 用户问题背后的真实诉求最近我在帮某单位做办公系统集成碰到了几乎所有信创项目都会遇到的组合前端富文本编辑器选的CKEDITOR文档源却是一大批经过加密处理的Word文件。客户当时的原话是我不管你们怎么做打开系统的Word文档必须能直接在编辑器里改改完能存回去整个流程不允许绕开国产密码算法。初次听到这句话第一反应肯定是CKEDITOR支不支持国产密码。但你仔细想这个说法其实有偏差。CKEDITOR本质上只是一个富文本编辑器它不做文件系统不碰加密引擎甚至连文件上传都只是通过接口对接。用户真正问的不是编辑器支不支持某个算法而是我的文档从本地磁盘被读取出来一路走到编辑器界面上中间这条链路能不能全程符合信创环境对国产密码的要求。这个区分非常关键。如果你把支持国产密码理解成编辑器菜单栏里有个加密开关那这个需求永远没法落地。如果你把需求重新定义为文档打开链路中的解密、传输、完整性校验、保存回写都要使用国密算法那CKEDITOR就能很自然地融入信创技术栈。我后面所有方案都是基于这个重新定义来设计的。1.2 CKEDITOR导入Word文档的真实流程在说加密之前先把导入Word这件事拆开。很多人以为CKEDITOR支持直接打开.docx文件其实不是。CKEDITOR 4时代最常用的方式是纯前端解析把Word另存为HTML或者用浏览器剪贴板把Word内容粘贴进编辑器。这种方式对联网的、结构简单的文档还凑合一旦遇到真正的.docx文件就抓瞎因为docx本质上是一个ZIP压缩包里面塞满了XML前端JS要解析它需要跑一整套文档对象模型转换性能和兼容性都很差。CKEDITOR 5的官方思路则更务实编辑器本身不管docx而是通过一个文档转换接口在后端把docx转成HTML再喂给编辑器。这个后端转换组件通常包括文档解析、样式清洗、图片提取、表格结构化等一堆逻辑。你的原始Word文件要被转换服务读一遍然后输出一个干净HTML字符串CKEDITOR拿到这个字符串渲染出编辑界面。明白了这条链路你就会意识到所谓CKEDITOR支持国产密码实际上取决于两个节点——第一原始Word文件的解密动作发生在哪里第二解密之后的内容在进入转换服务和编辑器之前有没有经过一次合法的、符合国密要求的处理。2. 核心结论编辑器不碰密码算法但导入链路必须整体重构2.1 编辑器的明文边界与加密边界我先给一个明确的工程结论无论你用的是CKEDITOR 4、5还是其他任何富文本编辑器加密/解密都不应该出现在编辑器代码内部。编辑器只接受已经处于明文状态的内容比如一段HTML字符串。加密边界一定在编辑器外面。把这个边界画清楚你就能理解整个方案的结构。假设系统里有三个区域存储区Word文件以密文形式保存在文件服务器或对象存储里可能是SM4加密后的字节流转换区docx转HTML的服务读取的是解密后、内存态的明文内容编辑区CKEDITOR编辑器拿到的是转换好的HTML字符串这部分内容在浏览器内存里本来就是明文那支持国产密码体现在哪里体现在从存储区到转换区之间以及从转换区到浏览器之间的所有关键动作都使用国密算法族的密码技术来保护。具体来说存储区文件用SM4分组算法加密文件完整性用SM3摘要算法校验密钥的传输和协商用SM2非对称算法完成如果要求浏览器到后端之间走加密通道那就涉及国密TLS或者干脆在应用层再做一次SM4加密。2.2 国产密码算法在整个导入链路中的正确位置我梳理了一张很简单的映射关系你以后跟客户或者跟评审专家沟通都能用密码算法在导入链路里的角色对应环节SM2密钥协商、签名验签、用户身份认证登录时获取解密密钥、前端与后端握手SM3摘要计算、完整性校验检查Word文件是否被篡改校验转换结果是否完整SM4对称加密/解密Word文件本体加密、传输过程中的内容加密国密TLS信道加密浏览器与后端服务器的HTTPS链路信创环境常要求使用国密套件在实际集成中我做的第一件事不是去改CKEDITOR配置而是确认现有的统一身份认证平台能不能下发SM2密钥文件服务在读取密文时能不能调用加密机提供的SM4解密接口。这些基础能力如果不具备后面谈再多编辑器插件都没用。这里有个容易被忽视的点很多人以为国产密码就必须一连串全部用上其实不一定。如果存储区用的是SM4那转换区和编辑区之间的通信只要有HTTPS哪怕用的是普通TLS套件也不影响文档本体已经被国密算法保护的事实。但信创项目往往有等级保护或者密码应用安全性评估要求评审会逐一检查密钥管理、身份认证、完整性校验、传输加密这几个维度所以最好一开始就按算法应用全覆盖来设计避免后期返工。3. 落地实现在导入CKEDITOR之前接入国密解密的完整方案3.1 方案A前端JS解密后把明文内容交给编辑器信创项目里有一种很常见的轻量场景Word文档体积不大几十KB到一两MB而且文档已经在前端用SM4加密过了。这时候可以直接采用前端解密方案。具体流程是这样的用户选择加密的Word文件前端用国密JavaScript库读取文件字节从KMS或身份认证平台拿到授权密钥调用SM4解密接口得到原始文件二进制流再用JS解析器提取文档内容并转成HTML最后调用CKEDITOR的setData()方法渲染。前端的SM4解密伪代码大致是这样import { sm4 } from sm-crypto; // 如果密文是Base64编码的先转成ArrayBuffer const encrypted base64ToArrayBuffer(fileBase64Content); // 密钥由KMS下发给当前登录用户前端仅临时持有 const key sessionKey; // 16字节SM4密钥 // 解密得到明文文档字节 const plain sm4.decrypt(encrypted, key); // 用文本解码器转成字符串交给转换逻辑 const text new TextDecoder(utf-8).decode(plain);这个方案的优点是没有后端转换服务也能跑通适用于系统里没有独立文档转换中间件的情况。但缺点更明显前端解析docx对JS库的成熟度要求很高表格、分页符、批注、修订模式这些东西很容易解析错乱而且大文件会让浏览器内存直接爆掉。我一般只在演示DEMO或者文档结构极简单的内部系统里推荐它。3.2 方案B后端解密加文档转换服务再返回编辑器正规信创项目我强烈建议用方案B。整个链路由后端统一控制密码算法和文档解析前端只负责把用户选择文件上传等待后端返回HTML。架构看起来是这样用户在前端选中一个被SM4加密的Word文件前端把密文文件上传到后端文件接口传输走国密TLS后端从加密机或密钥管理系统获取SM4密钥后端解密文件得到原始的docx字节流后端调用文档转换服务把docx转成标准HTML后端计算HTML的SM3摘要连同HTML一起返回前端前端用SM3算法校验摘要确认完整性后调用editor.setData(html)渲染后端解密部分用Java实现时通常会这样组织// 国密算法处理服务 byte[] cipherBytes Files.readAllBytes(Paths.get(uploadedFilePath)); byte[] plainBytes sm4Decrypt(cipherBytes, keyFromKms); String html documentConverter.convertDocxToHtml(new ByteArrayInputStream(plainBytes)); String digest sm3Digest(html.getBytes(StandardCharsets.UTF_8));第2步和第6步之所以都涉及国密算法是为了防止中间人篡改。即使链路已经有TLS保护应用层再叠加SM3摘要是有意义的评审专家也喜欢看到这样的设计。转换服务的选择上我试过几类方案第一种是调用开源办公套件的无头模式把docx直接导出为HTML效果稳定对复杂文档还原度很高缺点是要求在服务端安装完整的办公软件环境第二种是用现成的文档转换中间件通过HTTP接口上传文件获取HTML集成快但需要额外采购授权第三种是自研轻量转换器只针对特定模板维护成本高不推荐。信创环境里如果服务器操作系统本身就是国产化平台第一种方案反而兼容性更好因为所有依赖库都可以从系统源仓库安装。3.3 两种方案的选型对比对比维度方案A前端解密方案B后端解密转换部署复杂度低只有前端JS高需要后端服务和转换模块浏览器兼容性依赖JS国密库兼容性前端基本无压力大文件处理差容易内存溢出好服务端硬盘和内存充裕文档还原度一般复杂表格易错位高可用成熟转换引擎密钥安全密钥可能被前端截获密钥只存在后端安全可控密码合规评审容易有争议更容易满足要求我做过一次对比测试同样一份带复杂加密字体的企业红头文件方案A解析出来的表格宽度完全错乱字体映射也丢了三分之二方案B几乎完美还原了版式。从那以后即使客户说只是内部用用我也坚持方案B。4. 信创环境下特别容易踩的五个坑4.1 浏览器Web Crypto API并不支持SM系列算法很多前端开发习惯性地以为浏览器原生的crypto.subtle接口能搞定所有加密算法结果一查文档发现主流浏览器原生支持的是AES、RSA、ECDSA这些国际算法SM2、SM3、SM4根本不在Web Crypto的标准列表里。这意味着什么意味着你能用原生API做AES-CBC加密却不能用它做SM4。信创项目里如果前端必须执行国密运算就得引入第三方JS库或者干脆不把核心加解密放在前端只在前端做摘要校验。我在项目中反复强调一个原则前端能不碰密钥就不碰密钥只要涉及SM4解密尽量让后端完成因为浏览器里的密钥再小心也逃不过内存抓取和调试工具分析。4.2 Base64膨胀导致的上传限制前后端传输加密文件时很多人图省事把加密后的二进制转成Base64字符串再放进JSON里传给后端。这个习惯在信创文件加密场景里会引发一个特别烦人的问题Base64会让数据体积膨胀大约33%如果再加一层JSON转义膨胀更多。明明一个8MB的Word文件转完Base64可能变成11MB后端接口默认限制10MB上传直接报413。我后来统一改成了二进制流上传用multipart/form-data的方式传原始文件字节或者直接走文件分片。后端的文件接收接口也把大小限制放宽到实际文档容量的两倍。这点看起来不起眼但在评审演示的时候当场失败真的非常尴尬。4.3 密钥管理与临时密钥的生命周期信创环境下文件加密通常不是一把密钥吃到底而是每次打开文档都动态获取一个临时会话密钥。这个密钥的发放、使用和销毁必须严格遵循KMS接口的规范。我踩过的一个坑是测试人员发现连续打开同一份文档十几次后KMS返回的临时密钥偶尔会重复。排查了半天是我们自己的缓存策略在作祟——为了省事把上次的密钥对象挂了缓存没有注意到KMS接口返回的keyId已经变了。正确的做法是每次解密前都要向KMS请求新的会话密钥用完立即清空内存引用绝不在内存里保留超过必要时间的明文密钥。4.4 转换服务的临时文件残留后端方案里解密后的明文docx文件会在服务器临时目录里落盘。如果转换服务或者部署脚本没有清理机制这些明文文件会积累在服务器上轻则占用磁盘重则被安全扫描发现明文敏感文档直接拉低合规评估分。我在每个信创项目里都会加一个强制要求临时文件只允许写入内存映射目录转换完成之后立即删除如果必须写磁盘文件名用随机UUID目录权限设为700并且定期巡检清理。这个细节普通开发文档里不会写审查的时候却经常被问到。4.5 浏览器缓存和编辑器快照导致的内容残留明文HTML进入CKEDITOR之后CKEDITOR自己的内容快照会自动保存到时存储或者浏览器缓存里。如果用户是在公共电脑上打开敏感文档关掉页面后缓存里可能还残留着完整的明文内容这等于绕过了国密保护。解决方案有两个层面一是CKEDITOR配置里关闭自动保存快照或者设置快照只存内存不存持久化存储二是页面卸载前主动调用清理逻辑把编辑器实例销毁同时清掉相关的缓存对象。我在前端代码里是这么处理的const editor await ClassicEditor.create(document.querySelector(#editor)); // 防止浏览器持久化快照 editor.config.set(autosave, { save: () Promise.reject(disabled) }); // 页面卸载时彻底清理 window.addEventListener(beforeunload, () { editor.destroy(); sessionStorage.clear(); });这个坑在普通Web富文本项目里无所谓但在信创环境里内容泄露是底线问题宁可功能上少点便利也不能留这种安全后门。5. 一次完整的信创导入链路实测与调优记录5.1 实测环境与评测数据我们最终交付的项目采用的是方案B后端跑在国产化服务器上数据库和文件服务也都用了信创名录里的产品。CKEDITOR版本用的是5.x文档转换服务单独部署在一台8核16G的虚拟机上。测试数据选了三类典型的Word文档一类是纯文字说明文档大小约300KB一类是带复杂表格和图片的年度报告大小约4.8MB一类是包含修订模式、批注、页眉页脚的合同文本大小约1.6MB。每一类文档分别在密码机正常工作状态下跑20次记录从点击打开文档到编辑器渲染完成的总耗时。结果如下文档类型平均解密耗时转换耗时编辑器渲染总计纯文字文档38ms320ms120ms约0.5s复杂图文表格文档205ms2.4s1.1s约3.7s含批注修订合同90ms1.6s830ms约2.5s主观感受上纯文字文档是秒开复杂文档会有两三秒的转圈等待但用户普遍能接受。瓶颈主要在后端的docx转换服务不太在SM4解密环节上。后来给转换服务加了并行预热把常用模板的样式提前缓存第一档文档耗时稳定在了0.3秒以内。5.2 两个调优细节并发控制和转换结果缓存实际压测时发现一个问题同时有多个用户打开不同的大型Word文档转换服务的进程占用CPU会瞬间飙到100%导致其他请求排队。解决办法是给转换服务加了一个进程级的并发队列把最大并行转换任务数限制在CPU核数以内多出来的请求排队等待。为了让用户不干等前端在后端排队时立即显示文档解析中的进度提示。同时对同一份文档的多次打开做了缓存只要源文件没有变化第二次打开时直接返回第一次转换好的HTML省掉重复解密和转换的开销。缓存这里一定要注意过期条件如果同一个文档被别人在线编辑并保存过缓存就必须做失效。我是采用文件版本号存储系统自带etag作为缓存key只要文档内容发生了变化etag就变缓存就自动失效避免打开到旧的文档内容。5.3 与既有组织架构的差异证书和账号体系对接信创环境的国产密码不是孤立存在的它一定连着组织内部的认证中心和密钥管理系统。我的项目里用户在登录办公系统时认证中心返回的是SM2签发的用户证书然后系统根据证书编码向KMS申请该用户有权访问的文档密钥用途是解该文档的SM4加密。这个对接过程最大的工作量不在算法本身而在权限映射文档的加密密钥能授权给哪几个用户、PDF或Word审阅链接怎么带授权、文档流转出去之后权限怎么回收。CKEDITOR在这里完全不用关心这些它看到的只是后端丢过来的HTML。但你作为集成方一定要把权限映射想清楚不然就会出现算法全合规但权限一塌糊涂的诡异局面。6. 给其他正在做信创CKEDITOR集成的朋友几句实在话如果你正在处理和这个项目类似的问题我的建议是先把CKEDITOR是否支持国产密码这个问题从你脑子里面删掉换成文档导入链路的哪些环节需要国密哪些环节可以用现有的编辑器能力。前者会让你陷入寻找一个根本不存在的开关的困境后者能让你快速画出架构图。具体的先后顺序也很重要先确认KMS和加密机的接口能拿到SM4密钥再搭后端解密服务再选型文档转换组件最后才轮到CKEDITOR的集成和页面样式调整。这个顺序不能颠倒很多项目搞反了先是花几周时间调CKEDITOR自定义样式结果发现后端连文件都解不开只能全部返工。最后我在这个项目里学到的最大教训是做技术预演时一定要把密码应用安全性评估的思路前置。评审专家关心的问题其实不多密钥怎么来的、存哪里、什么时候销毁、文件传输有没有SM3校验、临时明文文件怎么清理。你提前把这些问题的答案准备好整个项目推进会顺畅得多。别等系统开发完了再找专家验收那时候改架构的代价就太大了。