在某家大型银行内部，一支工程师团队近日完成了将两百万行COBOL代码翻译为Java的工作——这次迁移历时十四个月，通过了所有测试套件，并按时上线，然而安全团队在第一周内便发现，信用卡号码、社会安全号码和账户余额正在毫无保护地流经API端点、Kafka管道以及原大型机架构从未暴露过的分析数据湖。
现代化改造成功了，但数据保护却失败了，而这种情况在大多数企业中发生的频率远比它们愿意承认的要高得多。
大型机现代化改造的投入正在加速，但相关讨论仍然绝大部分集中于代码翻译、云基础设施和降低成本，而数据安全——这个决定现代化项目是产生风险还是消除风险的唯一因素——在出现问题之前，往往得不到应有的重视。
现代化改造所带来的边界问题
传统大型机从未被设计为现代意义上的安全系统；它们被设计为无法访问的系统。IBM z/OS环境依赖物理隔离、RACF访问控制以及其架构本身的高度隐蔽性来保护敏感数据，数十年来，数据始终留在边界之内，因为它无处可去。
现代化改造从根本上改变了这一格局，因为当一个组织将COBOL应用迁移到云端或将DB2表复制到数据仓库的那一刻，敏感数据便开始跨越以前从未存在过的信任边界，而每一个新的集成点——无论是API调用、数据管道还是下游分析平台——都成为原有安全模型从未被构建来保护的攻击面。
这些系统的老化程度使挑战更加复杂——COBOL代码与没有人完整记录的业务逻辑紧密耦合，编写这些代码的开发人员正在陆续退休，而几乎每一家运行大型机的企业都共享同一项政策：不安装代理、不修改生产代码、不冒险中断处理关键业务交易的工作负载。
为何单靠代码翻译远远不够
AI辅助代码翻译工具加速了迁移过程——原本需要数年的工作现在可以在数月内完成——但将COBOL翻译为Java或Python，并不能翻译那些在数据存放于大型机内时保护数据的安全控制措施。在典型的z/OS部署中，加密由专用加密处理器在硬件层面处理，访问控制由RACF或ACF2强制执行，数据若不经过严格控制的批处理流程，就永远不会离开系统。
然而，当同样的数据迁移到云原生环境时，保护模型将彻底改变：数据现在分布在多个服务、区域和提供商之间，PCI DSS、HIPAA和GDPR下的合规范围扩展到数据离开z/OS后所接触的每个系统。如果没有在迁移开始前制定数据保护策略，各组织将发现，与其说是对安全进行了现代化改造，不如说是对风险进行了迁移。
在不触碰大型机的情况下保护数据
在现代化改造期间及之后保护数据的最实用方法是在网络层而非应用层运作，这一区别至关重要，因为修改传统COBOL应用程序几乎不可行，而在生产大型机上安装代理则会带来不可接受的运营风险。无代理数据保护解决方案在数据于大型机与下游系统之间流动时进行拦截——对敏感字段进行实时令牌化、脱敏或加密，无需更改大型机代码、数据库模式或现有工作流——而 最佳大型机升级与现代化解决方案现在已将这种内联安全作为核心组件而非事后补充加以整合。
其中，令牌化已成为在大型机环境中运营的企业的首选方法。保留格式的令牌维持了传统验证检查所期望的数据结构——例如信用卡号码的Luhn验证——同时消除了令牌与原始值之间的数学关联，这意味着令牌可以在不暴露敏感数据或破坏依赖一致格式的下游系统的情况下，流经云管道、分析平台和第三方集成。
企业在迁移前应评估的事项
计划实施大型机现代化改造方案的组织应在第一个工作负载迁移之前评估其数据安全态势——具体而言，包括敏感数据在大型机数据库和应用数据存储中的分布位置、哪些迁移路径将把这些数据暴露给新环境，以及数据到达云端后如何维持保护。做对现代化改造的企业从第一天起就将数据安全视为设计约束，而非事后追加的合规复选框；而做错的企业往往会发现——通常为时已晚——他们构建了一个比原有系统更快、更便宜但更加脆弱的版本。
