【51CTO.com原創稿件】如今，以 Netflix、Etsy、Flickr 為代表的各個公司，都持續以更少的時間、更快地發佈出新的功能，而他們的成功秘訣就是用到了“DevOps”。
DevOps 如今已廣泛地被銀行、保險公司、政府和許多重監管的行業組織所採用。
這是一種交付軟件的新方法，它專注於持續集成、持續交付和消除工程與運營團隊之間的障礙，從而加快發佈速度、並降低風險。
雖然 DevOps 被大多數軟件團隊所熟知，但是很少有團隊真正實踐並維護著與之相稱的安全控制。
像 Uber 和 eBay 之類存儲著大量個人敏感信息的組織，雖然運用 DevOps 簡化了開發和運營，推進了功能開發的速度，但由於將安全隱患置於了次位，因此也遭遇過一些重大的違規事件。
當然，也有不少的公司在運用 DevOps“快速前行”的同時，保持著高標準的信息安全。
對此我們總結出瞭如上圖所示的 6 條基本原則：
安全策略即代碼
職責分離
專注工作流與速度
安全的首要位置
自動化
技術採用
安全策略即代碼
目前，在那些成功地將 DevOps 的速度與安全性結合的團隊中，最重要的特性是：他們運用代碼來指定各種安全策略。
DevOps 的基石是“基礎架構即代碼（infrastructure as code）”，也稱“不可變基礎架構”。
運營者運用代碼來聲明其基礎架構的需求，從而取代了手工管理與配置服務器與軟件的舊模式。
這種方法能夠有效地抑制那些已被手動配置的服務器“獨角獸（unicorn）”們進一步擴散，進而造成在出現故障時，卻無人知曉如何進行重建這一尷尬局面。
更重要的是：它還能支持自動化擴容，以及預測如何將新生成的功能部署到不同的測試與生產環境之中。
代表這種基礎架構的代碼會與應用程序代碼一樣被檢入到源代碼的控制之中，進而可以實現版本控制、比較和保護。
那些安全實踐經驗較為豐富的 DevOps 團隊，可以通過採用“基礎架構即代碼”的模型來管理應用程序的安全性。他們在新的應用或微服務中，用代碼來聲明安全策略的各種需求。
例如，下面的一小段安全政策，就是一個用 Conjur 政策語言（請參考https://www.conjur.org/reference/policy.html）編寫的、提供貨幣換算服務的微服務：
由上可見，它的語法是人類可讀且易於理解的。即：該代碼允許授予了貨幣轉換服務（currency-converter）權限，去訪問一個存儲著各種貨幣值的數據庫密碼。
該政策是完全獨立且可不限重複的，既不依賴於外部因素，也不會被未來的解釋方式所左右。它完全可以被檢入到源代碼的控制中，作為應用代碼的一部分被予以內部實現。
那些日常管理著數千個應用相關權限的安全人員，可以通過該“安全策略即代碼”模型，將自身的團隊能力提升到一個新的水平，並能使得自己的工作更具可預測性。而這些恰是過去那些需要手動配置與應用相關的安全權限所無法企及的。
所以，“安全策略即代碼”對於創建高效的安全 DevOps 流程是至關重要的。沒有它，我們後面將要談到的安全 DevOps 各個方面都將無法實現。
職責分離
令人遺憾的是，在許多軟件團隊中，開發人員和操作人員還肩負著安全的職責，他們需要維護服務相關的帳戶、定義各種安全控制、控制對於敏感數據的訪問等。這些無疑增加了他們已有的且“滿滿的”工作量。
職責分離是速度的動因
大多數關於職責分離的文章都會提到它在防止利益衝突和欺詐方面的好處，以及如何通過它來減少任何人超額擁有其本該擁有的基本權力。
然而從另一個角度來看，高績效的 DevOps 團隊會將職責分離視為一種機會，他們籍此來保證團隊成員僅專注於自己最擅長的工作，並能夠根據每個人的能力來適當優化團隊整體的工作流程。
成熟的團隊具有明確的角色和清晰的職責分工。安全和監督由專門的安全人員來負責，開發人員會專注於編寫代碼，而操作人員則確保生產環境架構能健康運營。
每個職能團隊之間的接口“傳遞”已被編入到了安全策略之中。即：開發人員創建安全策略聲明其應用程序或服務所需要的權限→安全人員隨即審核並批准相關的代碼更改→操作人員確保應用程序的部署、並能夠按照預期運行。
職責結合：一種痛苦的反模式
當任何一種開發、安全和運營角色被組合在一起時，組織將不可避免地出現由單一角色所帶來的巨大風險。
對於開發者來說，他們通常無法意識到自己在生產系統中可能所擁有的權限，因此也就無法預知自己的某種疏忽會給組織帶來的危害程度。
例如：去年某公司的初級工程師在入職的第一天，就意外地刪除了該公司的生產數據庫。而發生這種情況的原因，正是因為他被賦予了在生產系統中的所有權限。
就他所擁有的訪問權限而言，這位不幸的開發人員在完全不知的情況下，同時扮演著運營人員的角色。
因此，問題的根源不在他的身上，而來自僱主：他們沒有將職責分離，沒能在源頭防範此類情況的發生。
每種角色的責任
開發人員：
能夠編寫代碼和測試案例，而不必擔心意外地觸碰生產環境。
與運營人員交流其應用所涉及到的主機需求。
與安全人員交流其應用所涉及到的安全需求。
運營人員：
執行並實現應用程序有關主機（虛機）的需求。
保證生產環境的可用性。
安全人員：
針對開發人員的應用需求授予相關權限。
確保系統範圍內，各種安全措施的落實與到位。
正如企業採用 DevOps 模式並不意味著開發人員需要承擔運營角色那樣，採用“DevSecOps”也並非意味著開發人員必須成為安全專家。
因此，高績效的組織應當學會避免出現“快速推進卻時常犯錯”的行動狀態。他們需要的應當是“在知曉不會犯錯的基礎上快速推進”的各司其職模式。
專注工作流與速度
DevOps 的核心概念是產生可持續的、平穩的工作流程。
為了實現此目標，DevOps 團隊需要通過創建各種 CI/CD 管道、持續進行小而頻繁的代碼變更、端到端的部署、並採用類似基於微服務的系統架構，以獲取上文提到的快速推進。
建模和優化安全的工作流程
看板（Kanban）是一個專注於流程和開發速度的工作系統。其核心是將工作的各個階段可視化，即：隨著項目在不同階段的推進，各個狀態的可視化會有助於分解出其中出現的緩慢步驟、識別出瓶頸、並優化其速度。
一個長期面臨發佈延遲的組織可能會發現：安全審查階段在自己的系統中花費的時間較長。
原因通常在於：安全審查開始得比較晚，並且所涉及的量又比較大。換句話說：太多的東西會一下子被“甩到”安全審查團隊的面前。
那些經驗豐富的組織一般會“將安全放到左邊”（在可視化看板中，一般假設工作流程從左邊開始，向右邊流動）。
這就意味著：安全團隊越早介入新版本/功能的開發，就越好。同時，如果他們在整個開發週期的早期階段，就能揭示出重大的安全問題，那麼就可以防止後期出現延遲交付的情況。
為速度加固微服務
微服務架構給安全團隊提供了許多好處，尤其是那些專注於自身發佈速度的團隊。
我們繼續以前面 “貨幣換算”的微服務為例。如果安全團隊只需要檢查並授權該應用去訪問單個數據庫的話，那麼還是相對較為簡單的。
但是如果該功能被置於一個龐大的且擁有數百萬行代碼的應用體系之內時，那麼安全團隊就可能需要對許多方面的變化進行梳理，以查找出對他們來說非常重要的審查內容。
同時，如果該龐大的應用在版本上經歷了許多實質性的變更，則會將審查變得更困難。
畢竟，只讓安全團隊檢查幾十行的安全策略代碼和讓他們檢查上千行代碼相比還是容易得多的。
如果新的版本不需要修改任何權限，那麼對於已經註冊的微服務代碼進行持續升級還是能保持快速的。
相反如果需要在龐大的應用中退役或關停某個微服務，則需要考慮到所涉及的各種耦合關係和代碼層面的規模。
傳統團隊在經歷了瀑布式開發之後，常趨向於進行“爆炸式（big-bang）”發佈應用。而一旦應用出現了質量問題，則不得不迅速叫來安全人員進行代碼審查。
如此一來，安全團隊所面臨的往往是累積了成上千次變更後的應用代碼和來自業務方面為了應用能早日上線的不斷施壓。
因此，那些保持持續交付的大型團隊，會將他們的代碼庫分解成多個微服務來實現。
同時他們也會邀請安全團隊運用各種專業的、精細化的模型來進行各種安全審查，以有助於加快發佈進度、並提高可視性。
端到端簡化流程
DevOps 引入了“儘早實現端到端”的概念。這是一種簡單的降低交付風險、並提高預估信心的方法。
對於團隊成員來說，他們能夠越快地將新服務“連接管道”，就能夠越快地獲知如何順利地去構建部署流程，以及應對頻繁的升級和更新。
同時，一些未完全實現的功能標誌可以被隱藏地部署到生產環境之中，等到新的功能完善了，再向用戶全面展示和開放。
這種方法同樣也能夠很好地降低服務中的安全變更風險，特別是當團隊採用了“安全策略即代碼”的原則後。
例如，一項新的服務需要訪問內部 CRM 數據庫和支付網關，那麼該團隊的首要任務就是為該服務構建出一個 CI/CD 管道，然後等基本連接構建好之後，再將該管道昇至 0.1 版本。
如此，該服務的權限就已經通過了審查，一旦完成部署，它將以“預先註冊”的方式去訪問生產環境中的各種敏感資源。
由此可見，這樣便消除了後續版本的部署風險，開發人員可以在後期去創建並實現剩餘的功能。同時，安全團隊也提前獲知了服務的權限與安全的設置需求。
高效的 DevOps 團隊應當能夠通過如下方式，來實現高速且流暢的工作流程：
使用看板視圖來發現開發週期中的瓶頸，並優化它們。
“將安全放到左邊”，讓安全團隊儘早參與到開發週期之中，從而儘早發現相關的安全問題。
使用“安全策略即代碼”的方法讓開發、安全和運營團隊進行高效且明確的溝通。
將大型應用分解為更小的微服務，每個微服務都要有自己的安全策略。
儘可能減少大批量的變更，使安全團隊能夠持續、少量、可預知地進行安全審查。
儘早實現“端到端”模式，以降低組件和模塊的持續升級所帶來的風險。
無論您的公司有著上百位開發人員，還是隻有較小規模的團隊，上述安全開發的流程原則都會給您帶來幫助。
安全的首要位置
軟件團隊通常會對嚴重的錯誤、蹩腳的設計和糟糕系統性能做出及時的響應。因為這些問題既明顯又尖銳。
而作為“硬幣另一面”,他們對於那些所謂的“技術債”，則只是通過一些預防性工作予以滯後解決，甚至擠壓下來，直到將來失控，並造成更大的問題。
因此，經驗豐富的 DevOps 團隊通常應當把安全問題視為“頭等公民”，放在急需解決的首要位置，而不能將它們積壓到 To-Do（待辦）列表中，甚至永遠不去解決。
既然一個團隊能夠重視應用中的漏洞以及安全性，那麼他們自然會在開發和發佈過程中採取各種恰當的安全措施。我們下面來詳細研究一下這些安全實踐。
密碼的安全管理
密碼的安全管理需要注意以下幾點：
與生產系統有關的所有密碼信息（密碼、私鑰、或攻擊者可以利用的任何敏感信息）都應存儲在安全且高可用的庫中，並且只有被授權訪問它們的系統，能在恰當的時間段訪問到。
不允許庫管訪問到具體的密碼值/信息。
確保密碼根據既定的時間表自動變更，進而控制其有效時間。
良好的安全習慣
下面是以“安全為中心”的團隊時常踐行的一些安全要點：
最小權限的原則可以適用到任何地方。機器也好、人員也罷，只能訪問他們適合訪問的資源。一旦有不恰當的訪問發生，應立即撤銷其對應的權限。
漏洞掃描會自動運行在所有相關的第三方特徵庫之上。如果有最新的更新，則應立即升級各個漏洞庫。
無論是否檢測到相關的漏洞，都應保持第三方特徵庫為最新。因為某些修補程序可能僅適用於特徵庫的最新版本，因此升級與更新將有助於避免出現重大的兼容性問題。
針對潛在攻擊因素，應定期對應用程序（及其 CI/CD 環境）進行滲透測試。這些測試有時甚至可以作為 CD 管道的一部分，被自動化工具來完成。當然也可以通過定期的人為干預，如白帽子黑客，來增強效果。
將應用與信息安全方面的培訓，放到所有新入職的開發人員的培訓計劃中，並讓他們得到持續教育。
為產品代碼的變更開發工作流程，其中包含：攻擊向量因素和安全策略違規等信息準確檢查與披露。例如，某個團隊使用著 GitHub PR(PullRequest)，那麼提交者和審閱者都應使用同一個 PR 模板來進行編寫。
全員致力於安全速度
在一些公司裡，安全團隊常揹負著“擋路人”的名聲。而實際情況卻是：在整個開發週期中，安全團隊往往過遲地獲悉新的系統與計劃。
而無論開發進程是多麼的流暢與快速，安全團隊始終有責任確保整體業務，不會因為新技術的部署而面臨風險。
安全審批是需要時間的，特別是有大量項目併發進行的時候，當然，各種不滿的情緒很容易滋生。
在一些“失常”的組織中，開發人員甚至會秘密地部署那些未經批准的應用，以顛覆安全團隊的權威，從而使事態更為惡化。
因此，高績效的組織應當從上述問題中認識根源，即：安全團隊被放置在了開發流程的錯誤位置。
將安全放到左邊
經驗豐富的團隊往往在開發新應用的早期階段就直接考慮到安全問題，讓安全團隊去檢查他們的架構和技術選擇，並努力在流程中“將安全放到左邊”。
如此，在大量代碼被編寫之前，安全團隊就能提早發現各種嚴重的問題，並能儘早解決。
同時，此舉也會減少開發人員和安全人員之間的爭論，塑造出和諧的團隊關係。
乍看來，“將安全放到左邊”在短時間內會是一項吃力不討好的選擇。但是如果從整個開發的生命週期來看，早期的安全評估勢必會避免主要架構在後期出現漏洞時的返工成本。
實際上，早期的安全審查不但能降低開發項目的風險，還能為後續的發佈週期降低成本。
自動化
對於 DevOps 團隊來說，他們已經能夠實現 QA、打補丁、部署、升級、回滾和災難恢復的自動執行，並達到了前面提過的“不犯錯式快速推進”的效果。
而對於高績效的 DevOps 團隊來說，他們還應當將安全性納入現有的自動化規劃之中，在不增加不當風險的前提下，實現快速的發佈功能。
人類只做最擅長的事
經驗豐富的 DevOps 團隊不僅能夠最大限度地發揮系統自動化，還會持續尋找那些將人類重複執行的任務轉化為自動化的機會。
而安全性恰好就屬於這種自動化轉化的範疇。當然，在安全開發中也存在著一些僅適合人類完成的方面。
例如：在新的應用程序被推出之前，以及在管理現有的應用程序時，安全團隊都是審查和判斷授予各項權限的最佳選擇。
儘管有許多高效的自動化工具可用於滲透測試，但是人類總能找到去攻擊軟件或系統的更好、更新的方法。
增加自動化，降低人數
在大多數高績效的 DevOps 團隊中，一旦他們將持續集成（CI）的管道設置為以自動化的方式將應用程序推送到下個階段或是生產環境，那麼操作人員就不必再參與應用程序的後期升級了。
同樣，只要應用程序的安全政策沒有發生變更，且不需要增加新的權限，那就不需要讓安全人員作為審批的一個環節，也不可能造成瓶頸，甚至影響到應用的推進或上線。
他們既然已經人工批准了某個應用的註冊，那麼只要該應用程序在運行時不需要更多的權限去訪問資源，升級應該被完全自動化。
當然，在不影響安全性的情況下，實現自動升級就需要在 CI 管道中設置更多的任務，包括：掃描第三方軟件庫和運行中的 CVE（Common Vulnerabilities and Exposures），檢查應用程序的代碼是否存在著安全漏洞，以及是否進行滲透測試等。
這些自動化的配置雖然可能會需要一定的時間，但當它們被相互累計起來時，其成本、風險以及整體所花費的時間，都會比人工進行要節省得多。
自動化安全
隨著數據中心自愈能力和災難恢復（DR）技術的發展，自動化安全沿著如下的發展路徑，逐步緩解了運營中可能出現的各種複雜故障：
維護一個需要手動啟用的備用站點。
對於手動站點的切換流程進行定期的演習與測試。
完全自動化地切換到另一站點。
多個站點或區域同時運行，在出現故障時，能自動在系統中同步所有的差異。
通過運用混沌工程（Chaos Engineering）原理故意造成基礎設施故障，進行測試。
自動化防範入侵
自動化不但能協助高效的安全團隊做出及時的故障響應，還能防範各種入侵行為的發生。
眾所周知，攻擊者入侵系統是需要時間的。如果某個關鍵數據庫的帳戶密碼需要每 90 天手動更改一次的話，那麼他們將有幾個月的時間去試圖破解它。
但是，如果該數據庫的密碼每天都自動更改（輪詢的方式），或更為頻繁的話，那麼他們破解密碼的能力將大幅降低。
自動化響應入侵
另一個防範入侵的關鍵因素是：定期自動化重構基礎設施。即：通過虛擬機技術和自動化進程，可以定期將服務器快速地恢復到已知的良好狀態，而不產生任何的宕機時間。
在許多組織內，各種自動化響應流程在檢測到入侵發生時，就啟動了自動恢復的進程，所有密碼被輪詢一次，而所有相關的“可調用”組件（如虛擬機、容器等）也被重新創建到過去已知的良好狀態。
上面我們提到過，應當對災難恢復方案進行持續演習那樣，如果自動化流程也能夠持續測試與執行的話，那麼其相應的風險也會大幅降低。
技術採用
技術發展得如此迅速，以至於安全人員常被開發人員貼上“過時策略的執行者”和“拒絕採用現代化工具”的標籤。
如今，DevOps 使用到了各種 SaaS 產品，支持 CI、CD、配置管理以及各種編排的各種開源解決方案。
安全團隊要想適應該環境，並流暢地開展工作，就必須擁抱這些新的系統與技術。
安全理念的變遷
劣等的安全團隊會負面地看待新的技術。對他們而言，現代化的工具代表了不斷增加的威脅因素、潛在的漏洞和受攻擊的可能性。
而優等的安全團隊則持有樂觀的態度，即：如果能安全地採用新的工具，組織的業務不但能夠運行得更快，而且組織也會更為安全。
傳統的 IT 安全理念建立在靜態的本地數據中心和已知資產明細的基礎上。在系統邊界處，外圍防火牆作為主要的防禦措施，抵禦著各類攻擊。
而內部安全系統則專注於管理組織裡的人員與機器。LDAP、Kerberos 和 Active Directory 是主流的管理身份與角色的工具。新添置的機器和新僱用的員工需要被手動配置到系統之中。
如今，現代化的組織則使用微服務、容器、編排器（orchestrators）和無服務器技術來管理動態的基礎架構。
顯然這些與傳統的安全理念並不相稱。新的安全理念不再專注於“守住”生產環境中的資產，而是要更好地且“安全地支持企業的快速推進”。
新技術提高了安全性
新的安全保護措施，有助於各種安全流程跟上 IT 系統的發展節奏，並能防止影子 IT 的威脅。
例如，Beyond Corp 是 Google 的一個安全模型，它能夠將各種內部應用轉換為典型的部署模型。Google 並沒有將那些敏感的應用放置在 VPN 後面，而是將它們部署到了公網之上。
對於這些應用的訪問，完全取決於訪問者的身份，而並非他們所處的網絡。這就顛覆了傳統的IT策略，併為 Google 和使用它的其他組織提供了巨大的速度與靈活性。
Conjur 同樣在其產品中也用到了：將身份識別應用於所有的動態計算資產與用戶的安全理念。
其他一些以開發人員為中心的技術，也從根本上減少了開發者所需要訪問的敏感資產數量。它們有助於更好地實現職責分離。
例如，像 Pivotal Cloud Foundry 之類的 PaaS 系統和像 Kubernetes 這樣的部署編排器，能為開發人員提供完全隔離的、且獨立於系統操作的清晰視圖。
無服務器技術同樣能夠大幅提高系統的安全性。由於使用虛擬機或容器的開發人員，能夠“近距離地”接觸到操作系統，這給資產和敏感數據帶來了風險。
然而，在無服務器或“功能即服務（FaaS）”的模型中，這些資產是完全無法被訪問到的。
因此，對於大多數安全團隊來說，與其去監控並保護開發人員可能訪問到的資產，不如直接不讓他們“知曉”。
舊思維與新思想
傳統的 IT 安全模型著眼於：確定哪些資產需要被控制，然後構建出結構來“守住”它們。因此，所有工作流程都基於這種集中式的管控模型。
而新的方法則假設：手頭已經沒有一套完整的系統資產對應圖表了，應當使用的簡單而有效的準則。
即：每個實體都必須具有身份，必須通過策略清楚地傳達權限的更改，明確職責的分離，通過自動化的實現提高業務的推進速度。
藉助這一全新的理念，現代化的 DevOps 團隊將能夠在不犧牲安全性的情況下，保持高速的交付能力。而且這種新的理念、方法和模型勢必會被所有的組織所接受。
閱讀更多 51CTO 的文章
