ISO27017认证政策新规中的“加密要求”更新了？要用新算法吗

加密不是“换件衣服”，而是重新设计安全基因

最近不少客户拿着ISO/IEC 27017:2022新版标准来问：“加密要求真变了？是不是得赶紧把SHA-256全换成SM4？”——先别急着改代码。这次更新的底层逻辑，根本不是“算法清单升级”，而是把加密从“可选项”拧成了“必答题”，而且考的是整套设计思维。

别只盯着算法，先看“谁在用、怎么用、用在哪”

新规里没硬性规定“必须上国密SM4”或“禁用RSA-2048”，但它反复强调一个词：上下文相关性。比如云服务商存储客户日志，不能只说“我们用了AES加密”，而要能讲清：密钥生命周期谁管？加密发生在传输中还是落盘时？密钥轮换是否与用户会话超时联动？——九蚂蚁帮客户做差距分析时，发现73%的“不合规项”其实卡在加密策略描述模糊，而非算法本身落后。

密钥管理，才是新规真正的“高压线”

新版本把密钥生成、分发、归档、销毁全链路纳入审核重点。举个真实案例：某金融SaaS企业原用云厂商默认KMS，但审计发现其密钥自动轮换周期设为90天，而业务系统日志保留策略是180天——这就导致旧密钥过期后，历史日志无法解密验证，直接被判“加密控制失效”。现在我们陪客户做的第一件事，往往是画一张《密钥生命周期地图》，把每个环节的责任人、触发条件、审计留痕方式钉死。

加密不再是IT部门的“独舞”，而是业务流程的“嵌入式动作”

以前加个SSL证书就算完成加密合规；现在ISO 27017要求：当客户在网页端提交身份证号，前端JS加密+传输TLS+后端数据库字段级加密，三者必须形成可追溯的加密证据链。我们给某政务云项目做的方案里，甚至把加密动作嵌进业务审批流——每次数据导出操作，系统自动生成含加密算法、密钥ID、时间戳的审计凭证，直接同步至监管平台。

说白了，这次更新像一次“安全意识手术”：切掉“重算法轻管理、重部署轻运营”的旧习惯。如果你还在纠结“该换什么算法”，不如先打开系统后台，查查密钥轮换日志有没有断层，看看开发文档里是否写明了每个敏感字段的加密层级——这些，才是新规真正想摁住的命门。