【51CTO.com快譯】開發運維正在徹底改變開發人員和運營團隊的協同工作方式，以便更快速地交付更優秀的軟件。究其核心，開發運維的本質是自動化。開發、測試和部署方面的幾項任務自動化后，開發人員就可以經常修改代碼，并部署到生產環境。亞馬遜這家領先的開發運維倡導者曾經一度聲稱每天要部署1000多次。

[[173688]]

但是這種加快的工作流程有可能繞過安全編程實踐，開發人員常常發現很難在第一時間融入這種實踐。如果開發運維要繼續保持發展勢頭，開發人員就需要在軟件交付生命周期的早期階段整合安全測試。

這就是“加固型開發運維”背后的想法，這場運動讓開發人員負責安全測試。加固型開發運維插入了多個點，以便安全測試能夠及早發現潛在的軟件問題，以免這類問題進入生產環境，但同時又不影響持續集成和應用程序交付。

分析公司Securosis的首席技術官阿德里安·萊恩(Adrian Lane)說：“加固型開發運維就是在進入到生產環境之前整頓代碼，確保一旦代碼部署到生產環境，能夠抵御外部威脅。要像攻擊者那樣對待你的代碼。”

以開發運維之道確保代碼安全

開發運維的核心目標是，提供實現敏捷開發必不可少的自動化和實踐，并且讓軟件開發由龐大的瀑布項目轉為持續交付管道。

加固型開發運維需要一種類似的轉變：丟棄非常復雜的、為期多年的安全路線圖，改為逐步改進。太多企業組織往全面的計劃投入了大量的資金和時間，結果發現投入打了水漂。

總體愿景比路線圖更靈活，讓每個人都可以專注于逐步改進。比如說，致力于確保頭一個季度部署的所有新代碼沒有SQL注入問題，然后在下一個季度清理舊應用程序中的SQL注入問題，而不是說到年底所有應用程序都得到修復，清除開放式Web應用程序安全項目(OWASP)列出的十大安全漏洞排行榜上的所有軟件漏洞。

這種逐步改進方法的一個影響是，縮短了發現安全漏洞后修補漏洞所花的時間。通過把項目分成多個小部分，更容易優先確定代碼更改，并在更短的部署窗口內準備好發布。安全問題被有序地分成較小的具體任務后，開發人員就可以優先考慮并處理安全漏洞及其他代碼更改。

測試軟件有助于確保安全成為迭代方法的一部分。比如說，Gauntlt這種安全測試框架為眾多安全工具提供了鉤子(hook)，它讓開發人員、運維團隊和安全團隊在質量保證過程中相互合作，從而將測試融入到持續集成中。測試工作及早提供了應用程序安全方面的反饋。

讓開發人員負責安全測試并不是那么牽強附會――畢竟，開發人員一般相當了解在哪里找到應用程序的危險地帶(hot spots)。他們知道哪里的信息是硬編碼，哪些組件應該有更多的錯誤處理，哪些部分會得益于更好的數據管理。

Splunk的安全市場副總裁宋海巖在最近的一次視頻采訪中說：“更快地工作意味著更有效地處理安全漏洞。不要僅僅專注于在開發和測試過程中發現代碼錯誤――要考慮生產環境中的代碼有問題后，改進響應和修復流程。讓安全成為整個系統的一部分，那樣人們沒必要考慮安全。”

將安全納入工作流程

開發運維讓開發人員更快地移動，但更快地工作并不意味著糟糕代碼或更多的安全漏洞。完全存在這種風險：有更多的機會犯錯誤，或者忽視常見的配置設置。

硬編碼密碼就是一個明顯的例子。將密碼嵌入到源代碼中、“之后”修復，而不是合理創建含有登錄信息的一個配置文件來得更快速。要是不落實提醒開發人員回過頭去刪除密碼的控制機制，或者不落實發現遺留代碼的代碼審查流程，你就有可能敞開大門。

軟件提供商Micro Focus的副總裁喬治·韋伯(George Webb)說：“開發運維不是讓我們開發更多的不安全代碼，而是我們確實需要考慮落實治理和管理的種種方式。”

在大多數開發周期中，“安全測試”專注于外部威脅，比如用戶錯誤或惡意黑客攻擊，卻忽視了開發人員或管理員可能構成的內部威脅。加固型開發運維扭轉了這種情況，測試查找開發人員錯誤和管理員配置錯誤，并確保權限和角色正確分配，那樣在必要的情況下限制了數據訪問。安全測試應包括清理代碼、重置調試器以及審核配置文件的步驟。所有這些任務應在工作流程的早期階段完成，以免阻礙軟件交付。

韋伯表示，“我們并不改變你構建代碼、編寫代碼或者測試代碼的方式”，而是擴大了測試范圍，兼顧更多的使用場合。

持續交付管道的另一部分是實現工具鏈自動化，那樣用于開發、集成、測試、部署和代碼監控的工具可以連接起來。消除使用手冊和易出錯的流程，并實現工具標準化，確保每個人都遵循同樣的程序、使用同樣的工具集來工作。通過嘗試，搞清楚在哪里把安全融入到工具鏈中。比如說，只要新代碼簽入(checked in)、應用程序完成，代碼分析常常最有意義。

理想方法因組織和團隊而異。比如說，許多開發運維團隊發現很難加入靜態代碼分析，因為靜態掃描往往需要很長的時間。萊恩表示，如果代碼每天要提交多次，就沒有足夠時間加入安全測試。

模糊的界線，但治理存在

開發運維消除了開發、質量保證、運維和安全方面的孤島，那樣每個人都能作為同一個團隊的成員協同工作。雖然開發人員承擔了更多的安全責任，但他們并沒有讓安全團隊失業。

安全管理員應繼續為內外系統管理開發人員的身份、角色和訪問權限。開發人員應該被視為特權用戶，而不是管理員，只可以訪問他們需要處理的那些類型的數據或源代碼部分。

為了避免阻礙開發人員，一個方法就是使針對受限制的資源請求臨時提升權限的過程實現自動化。另一個方法是建立一個組件庫或資源庫，擁有認為可以安全使用的最新版本的組件庫和模塊。只要開發人員訪問組件庫，應用程序不太可能受到舊代碼錯誤的危害，而版本標準化簡化了維護和部署。

安全團隊仍然有其工作，但角色發生了變化。現在它建議并幫助工具選擇，給出部署方面的建議，甚至幫助編寫代碼或測試，以驗證代碼。

Micro Focus的解決方案及支持副總裁雷納托·奎達斯(Renato Quedas)說：“我們一起測試，一起開發，一起部署。就因為界線模糊并不意味著你沒有任何控制可言。”

自動化控制為安全鋪平道路

自動化是將安全控制融入到開發運維的關鍵。工具鏈中的每個工具可以生成審計跟蹤記錄，比如誰簽入代碼，出現了什么變更。掃描工具可以定期檢查企業的每個GitHub代碼庫，密切關注被發送到企業外面的敏感數據，比如硬編碼的登錄信息、加密密鑰以及其他類型的訪問令牌。

開發人員可能將新版本的組件和庫上傳到共享組件庫或資源庫，但這么做應該啟動一個驗證過程，確保新組件是合法的，并生成審計跟蹤記錄，表明誰進行了變更。

在部署到生產環境前后使用Chaos Monkey是另一個很好的例子，表明了安全測試如何成為整個生命周期的一部分。Chaos Monkey是來自網飛公司(Netflix)的一個開源項目，這種服務在亞馬遜網絡服務上運行，網飛駐留在該平臺上。Chaos Monkey力求自動擴展群組，并終止群組里面的虛擬機。這樣一來，各團隊就可以隔離并解決應用程序或總體架構在處理故障時面臨的任何問題，以免在沒人照看的凌晨時分演變成重大問題。

由于把重點都放在了自動化和工具鏈上，很容易忘了這點：開發運維并不是單單著眼于技術或流程。采用某一種工具或方法并不意味著“搞開發運維”。開發運維是一種理念。它可能始于開發流程的重要人員，但是要真正發揮影響，開發運維就需要滲入到企業文化中。

首先要尊重

加固型開發運維要奏效，工作團隊、開發人員和運維團隊就需要信任對方。若沒有這個必不可少的部分，每一個請求和任務就會變得很艱難。

開發人員、運維團隊和安全人員對于彼此都抱有先入為主的觀念，因而很難讓各團隊合為一體。開發人員不是可以為所欲為的牛仔，運維團隊并不干脆拒絕偏離既定流程的任何事情，安全人員并不只是一味嘮叨安全漏洞和規則。要有大家都在同一個團隊的想法，這點很重要。

為了博得每個團隊的關注，要解決它們最關注的問題。與運維團隊談論避免停運和性能故障，與安全和風險專業人員著重談論數據泄密和安全漏洞，與開發人員談變如何減少計劃外的工作。

進行常規的紅隊/藍隊演練，那樣所有團隊成員都能看到問題在哪里，并如何改變日常做法。檢測到網絡中斷有多快?要花多長時間才能查明問題，并拿出解決方法?目前是否進行測試以用于軟件測試或網絡監控?是時候設計新的測試來檢測未來的類似事件嗎?

一開始，你就需要讓每個人意見一致，讓團隊看到別人要處理的種種挑戰。開發運維原本就需要大家的共同參與。否則，自動化工具、逐步改進或安全控制機制都毫無作用。

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】