談 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 是應用性能管理領域的新興領軍企業，能幫助運維人員進行故障預警和定位，減小業務系統維護的工做量，同時還能提供可追溯的性能數據，量化運維部門的業務價值。想告別加班熬夜，歡迎免費註冊使用！