谈DevOps自动化时，也应该考虑到SOX等法案
谈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法案这样联邦法规的可能性只会增加。