谈 DevOps 自动化时，也应该考虑到 SOX 等法案

【编者按】作者 Aaron Volkmann 是 CERT Division 高级研究员，在本文中，他对 DevOps 自动化违反 SOX 法案进行了阐述。同时，也简单的提出了如何通过 CI 来避免这个问题，本文系OneAPM工程师翻译。

为了解决类似 Enron、Worldcom 以及 Tyco 等公司暴露出的财务欺诈丑闻，21世纪初期美国国会颁布了萨班斯-奥克斯利法案（SOX Act）。SOX 法案要求上市公司通过一系列内部控制手段，确保向投资者披露正确的财务信息。在一家 IT 公司中，遵守 SOX 方案的主要准则之一就在于：确保没有任何员工可以单方面地在生产环境中变更软件代码。DevOps 的自动化技术，如持续集成（CI）、持续交付（CD）、基础设施即代码（IaC）从表面上看，似乎已经不再遵守 SOX 法案了。本文将会探讨 DevOps 自动化如何能够让公司在保持兼容性的同时，还能从实际上提高其合规程度。

当软件控制进程从传统的手动方式转换为更加自动化的过程时，很多公司都担心检查会被忽略，平衡被打破的同时也造成公司违反 SOX 法案。在图一中所展示的传统场景中，一名开发者对某个软件进行变更后，先将代码提交进入评审流程，然后通过手工或系统进行打包准备部署。新版本被提交到变更控制流程中，准备部署到生产环境中。在管理者批准将变更实施到生产环境之后，由生产服务工程师进行部署。尽管管理该过程有很多办法，但仍无法确保评审的代码版本就是部署到生产环境的那个版本。

通过使用 CI 服务器（如图二所示），software shop 可以记录与追踪每个源代码文件的哪个版本构成了软件的相应版本。在持续部署的过程中会有停顿，人们在此时对变更进行检查，准备投入生产环境；任何未经授权的变更都不能通过该环节。

CI 使得对打包软件所使用源代码文件的确切版本进行记录与审核成为可能。software shop 同样可以具备集中自动化测试的能力，这样就能一一扫描每个软件 build，寻找安全缺陷。

另一个可能抵制自动化的领域是服务器基础设施配置。在 SEI，由于需要管理员手动查看服务器build，经常会有人反对使用 IaC 作为服务器配置。在使用 IaC 工具（Chef，Docker 或者Puppet）时，可以将基础设施配置脚本作为可验证、可测试、可信赖的软件构件，相信它能够产生可靠且能够复制的结果。IaC 让开发者有机会集中精力开发和测试配置脚本，同时允许自动化抄送测试服务器镜像，减少人为错误的风险。

每家公司甚至各公司内的每个科技/商业领域都可能会有独特的需求和限制。在特定领域，达标的自动化水平可能也会不同。通过仔细将机器布置到位，让自动化进程按部就班，这样一来控制、审核和保护公司资源的能力，还有确保遵守如 SOX 法案这样联邦法规的可能性只会增加。

原文链接：A DevOps a Day Keeps the Auditors Away (and Helps Organizations Stay in Compliance with Federal Regulations such as Sarbanes-Oxley)

OneAPM 是应用性能管理领域的新兴领军企业，能帮助运维人员进行故障预警和定位，减少业务系统维护的工作量，同时还能提供可追溯的性能数据，量化运维部门的业务价值。想告别加班熬夜，欢迎免费注册使用！