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