DevOps團隊的核心競爭力建設

1、 DevOps團隊的核心競爭力建設如今，以 Netflix、Etsy、Flickr 為代表的各個公司，都持續(xù)以更少的時間、更快地發(fā)布出新的功能，而他們的成功秘訣就是用到了“DevOps”。DevOps 如今已廣泛地被銀行、保險公司、政府和許多重監(jiān)管的行業(yè)組織所采用。這是一種交付軟件的新方法，它專注于持續(xù)集成、持續(xù)交付和消除工程與運營團隊之間的障礙，從而加快發(fā)布速度、并降低風險。雖然 DevOps 被大多數(shù)軟件團隊所熟知，但是很少有團隊真正實踐并維護著與之相稱的安全控制。像 Uber 和 eBay 之類存儲著大量個人敏感信息的組織，雖然運用 DevOps 簡化了開發(fā)和運營，推進了功能開發(fā)的速度，

2、但由于將安全隱患置于了次位，因此也遭遇過一些重大的違規(guī)事件。當然，也有不少的公司在運用 DevOps “快速前行”的同時，保持著高標準的信息安全。對此我們總結(jié)出了如上圖所示的 6 條基本原則：安全策略即代碼職責分離專注工作流與速度安全的首要位置自動化技術采用一、安全策略即代碼目前，在那些成功地將 DevOps 的速度與安全性結(jié)合的團隊中，最重要的特性是：他們運用代碼來指定各種安全策略。DevOps 的基石是“基礎架構(gòu)即代碼”，也稱“不可變基礎架構(gòu)”。運營者運用代碼來聲明其基礎架構(gòu)的需求，從而取代了手工管理與配置服務器與軟件的舊模式。這種方法能夠有效地抑制那些已被手動配置的服務器“獨角獸（uni

3、corn）”們進一步擴散，進而造成在出現(xiàn)故障時，卻無人知曉如何進行重建這一尷尬局面。更重要的是，它還能支持自動化擴容，以及預測如何將新生成的功能部署到不同的測試與生產(chǎn)環(huán)境之中。代表這種基礎架構(gòu)的代碼會與應用程序代碼一樣被檢入到源代碼的控制之中，進而可以實現(xiàn)版本控制、比較和保護。那些安全實踐經(jīng)驗較為豐富的 DevOps 團隊，可以通過采用“基礎架構(gòu)即代碼”的模型來管理應用程序的安全性。他們在新的應用或微服務中，用代碼來聲明安全策略的各種需求。例如，下面的一小段安全政策，就是一個用 Conjur 政策語言編寫的、提供貨幣換算服務的微服務：參考鏈接：/reference/policy.html由上可

4、見，它的語法是人類可讀且易于理解的。即：該代碼允許授予了貨幣轉(zhuǎn)換服務（currency-converter）權(quán)限，去訪問一個存儲著各種貨幣值的數(shù)據(jù)庫密碼。該政策是完全獨立且可不限重復的，既不依賴于外部因素，也不會被未來的解釋方式所左右。它完全可以被檢入到源代碼的控制中，作為應用代碼的一部分被予以內(nèi)部實現(xiàn)。那些日常管理著數(shù)千個應用相關權(quán)限的安全人員，可以通過該“安全策略即代碼”模型，將自身的團隊能力提升到一個新的水平，并能使得自己的工作更具可預測性。而這些恰是過去那些需要手動配置與應用相關的安全權(quán)限所無法企及的。所以，“安全策略即代碼”對于創(chuàng)建高效的安全 DevOps 流程是至關重要的。沒有它，

5、我們后面將要談到的安全 DevOps 各個方面都將無法實現(xiàn)。二、職責分離令人遺憾的是，在許多軟件團隊中，開發(fā)人員和操作人員還肩負著安全的職責，他們需要維護服務相關的帳戶、定義各種安全控制、控制對于敏感數(shù)據(jù)的訪問等。這些無疑增加了他們已有的且“滿滿的”工作量。1職責分離是速度的動因大多數(shù)關于職責分離的文章都會提到它在防止利益沖突和欺詐方面的好處，以及如何通過它來減少任何人超額擁有其本該擁有的基本權(quán)力。然而從另一個角度來看，高績效的 DevOps 團隊會將職責分離視為一種機會，他們籍此來保證團隊成員僅專注于自己最擅長的工作，并能夠根據(jù)每個人的能力來適當優(yōu)化團隊整體的工作流程。成熟的團隊具有明確的角

6、色和清晰的職責分工。安全和監(jiān)督由專門的安全人員來負責，開發(fā)人員會專注于編寫代碼，而操作人員則確保生產(chǎn)環(huán)境架構(gòu)能健康運營。每個職能團隊之間的接口“傳遞”已被編入到了安全策略之中。即：開發(fā)人員創(chuàng)建安全策略聲明其應用程序或服務所需要的權(quán)限安全人員隨即審核并批準相關的代碼更改操作人員確保應用程序的部署、并能夠按照預期運行。2職責結(jié)合：一種痛苦的反模式當任何一種開發(fā)、安全和運營角色被組合在一起時，組織將不可避免地出現(xiàn)由單一角色所帶來的巨大風險。對于開發(fā)者來說，他們通常無法意識到自己在生產(chǎn)系統(tǒng)中可能所擁有的權(quán)限，因此也就無法預知自己的某種疏忽會給組織帶來的危害程度。例如：去年某公司的初級工程師在入職的第一

7、天，就意外地刪除了該公司的生產(chǎn)數(shù)據(jù)庫。而發(fā)生這種情況的原因，正是因為他被賦予了在生產(chǎn)系統(tǒng)中的所有權(quán)限。就他所擁有的訪問權(quán)限而言，這位不幸的開發(fā)人員在完全不知的情況下，同時扮演著運營人員的角色。因此，問題的根源不在他的身上，而來自雇主：他們沒有將職責分離，沒能在源頭防范此類情況的發(fā)生。3每種角色的責任開發(fā)人員：能夠編寫代碼和測試案例，而不必擔心意外地觸碰生產(chǎn)環(huán)境；與運營人員交流其應用所涉及到的主機需求；與安全人員交流其應用所涉及到的安全需求。運營人員：執(zhí)行并實現(xiàn)應用程序有關主機（虛機）的需求；保證生產(chǎn)環(huán)境的可用性。安全人員：針對開發(fā)人員的應用需求授予相關權(quán)限；確保系統(tǒng)范圍內(nèi)，各種安全措施的落實與

8、到位。正如企業(yè)采用 DevOps 模式并不意味著開發(fā)人員需要承擔運營角色那樣，采用“DevSecOps”也并非意味著開發(fā)人員必須成為安全專家。因此，高績效的組織應當學會避免出現(xiàn)“快速推進卻時常犯錯”的行動狀態(tài)。他們需要的應當是“在知曉不會犯錯的基礎上快速推進”的各司其職模式。三、專注工作流與速度DevOps 的核心概念是產(chǎn)生可持續(xù)的、平穩(wěn)的工作流程。為了實現(xiàn)此目標，DevOps 團隊需要通過創(chuàng)建各種 CI/CD 管道、持續(xù)進行小而頻繁的代碼變更、端到端的部署、并采用類似基于微服務的系統(tǒng)架構(gòu)，以獲取上文提到的快速推進。1建模和優(yōu)化安全的工作流程看板（Kanban）是一個專注于流程和開發(fā)速度的工作

9、系統(tǒng)。其核心是將工作的各個階段可視化，即：隨著項目在不同階段的推進，各個狀態(tài)的可視化會有助于分解出其中出現(xiàn)的緩慢步驟、識別出瓶頸、并優(yōu)化其速度。一個長期面臨發(fā)布延遲的組織可能會發(fā)現(xiàn)：安全審查階段在自己的系統(tǒng)中花費的時間較長。原因通常在于安全審查開始得比較晚，并且所涉及的量又比較大。換句話說，太多的東西會一下子被“甩到”安全審查團隊的面前。那些經(jīng)驗豐富的組織一般會“將安全放到左邊”（在可視化看板中，一般假設工作流程從左邊開始，向右邊流動）。這就意味著安全團隊越早介入新版本/功能的開發(fā)越好。同時，如果他們在整個開發(fā)周期的早期階段，就能揭示出重大的安全問題，那么就可以防止后期出現(xiàn)延遲交付的情況。2為

10、速度加固微服務微服務架構(gòu)給安全團隊提供了許多好處，尤其是那些專注于自身發(fā)布速度的團隊。我們繼續(xù)以前面 “貨幣換算”的微服務為例。如果安全團隊只需要檢查并授權(quán)該應用去訪問單個數(shù)據(jù)庫的話，那么還是相對較為簡單的。但是如果該功能被置于一個龐大的且擁有數(shù)百萬行代碼的應用體系之內(nèi)時，那么安全團隊就可能需要對許多方面的變化進行梳理，以查找出對他們來說非常重要的審查內(nèi)容。同時，如果該龐大的應用在版本上經(jīng)歷了許多實質(zhì)性的變更，則會將審查變得更困難。畢竟，只讓安全團隊檢查幾十行的安全策略代碼和讓他們檢查上千行代碼相比還是容易得多的。如果新的版本不需要修改任何權(quán)限，那么對于已經(jīng)注冊的微服務代碼進行持續(xù)升級還是能保

11、持快速的；相反，如果需要在龐大的應用中退役或關停某個微服務，則需要考慮到所涉及的各種耦合關系和代碼層面的規(guī)模。傳統(tǒng)團隊在經(jīng)歷了瀑布式開發(fā)之后，常趨向于進行“爆炸式（big-bang）”發(fā)布應用。而一旦應用出現(xiàn)了質(zhì)量問題，則不得不迅速叫來安全人員進行代碼審查。如此一來，安全團隊所面臨的往往是累積了成上千次變更后的應用代碼和來自業(yè)務方面為了應用能早日上線的不斷施壓。因此，那些保持持續(xù)交付的大型團隊，會將他們的代碼庫分解成多個微服務來實現(xiàn)。同時他們也會邀請安全團隊運用各種專業(yè)的、精細化的模型來進行各種安全審查，以有助于加快發(fā)布進度、并提高可視性。3端到端簡化流程DevOps 引入了“盡早實現(xiàn)端到端”

12、的概念。這是一種簡單的降低交付風險、并提高預估信心的方法。對于團隊成員來說，他們能夠越快地將新服務“連接管道”，就能夠越快地獲知如何順利地去構(gòu)建部署流程，以及應對頻繁的升級和更新。同時，一些未完全實現(xiàn)的功能標志可以被隱藏地部署到生產(chǎn)環(huán)境之中，等到新的功能完善了，再向用戶全面展示和開放。這種方法同樣也能夠很好地降低服務中的安全變更風險，特別是當團隊采用了“安全策略即代碼”的原則后。例如，一項新的服務需要訪問內(nèi)部 CRM 數(shù)據(jù)庫和支付網(wǎng)關，那么該團隊的首要任務就是為該服務構(gòu)建出一個 CI/CD 管道，然后等基本連接構(gòu)建好之后，再將該管道升至 0.1 版本。如此，該服務的權(quán)限就已經(jīng)通過了審查，一旦完

13、成部署，它將以“預先注冊”的方式去訪問生產(chǎn)環(huán)境中的各種敏感資源。由此可見，這樣便消除了后續(xù)版本的部署風險，開發(fā)人員可以在后期去創(chuàng)建并實現(xiàn)剩余的功能。同時，安全團隊也提前獲知了服務的權(quán)限與安全的設置需求。高效的 DevOps 團隊應當能夠通過如下方式，來實現(xiàn)高速且流暢的工作流程：使用看板視圖來發(fā)現(xiàn)開發(fā)周期中的瓶頸，并優(yōu)化它們；“將安全放到左邊”，讓安全團隊盡早參與到開發(fā)周期之中，從而盡早發(fā)現(xiàn)相關的安全問題；使用“安全策略即代碼”的方法讓開發(fā)、安全和運營團隊進行高效且明確的溝通；將大型應用分解為更小的微服務，每個微服務都要有自己的安全策略；盡可能減少大批量的變更，使安全團隊能夠持續(xù)、少量、可預知地

14、進行安全審查；盡早實現(xiàn)“端到端”模式，以降低組件和模塊的持續(xù)升級所帶來的風險。無論您的公司有著上百位開發(fā)人員，還是只有較小規(guī)模的團隊，上述安全開發(fā)的流程原則都會給您帶來幫助。四、安全的首要位置軟件團隊通常會對嚴重的錯誤、蹩腳的設計和糟糕的系統(tǒng)性能做出及時的響應。因為這些問題既明顯又尖銳。而作為“硬幣另一面”,他們對于那些所謂的“技術債”，則只是通過一些預防性工作予以滯后解決，甚至擠壓下來，直到將來失控，并造成更大的問題。因此，經(jīng)驗豐富的DevOps 團隊通常應當把安全問題視為“頭等公民”，放在急需解決的首要位置，而不能將它們積壓到 To-Do（待辦）列表中，甚至永遠不去解決。既然一個團隊能夠重

15、視應用中的漏洞以及安全性，那么他們自然會在開發(fā)和發(fā)布過程中采取各種恰當?shù)陌踩胧?。我們下面來詳細研究一下這些安全實踐。1密碼的安全管理密碼的安全管理需要注意以下幾點：與生產(chǎn)系統(tǒng)有關的所有密碼信息（密碼、私鑰、或攻擊者可以利用的任何敏感信息）都應存儲在安全且高可用的庫中，并且只有被授權(quán)訪問它們的系統(tǒng)，能在恰當?shù)臅r間段訪問到；不允許庫管訪問到具體的密碼值/信息；確保密碼根據(jù)既定的時間表自動變更，進而控制其有效時間。2良好的安全習慣下面是以“安全為中心”的團隊時常踐行的一些安全要點：最小權(quán)限的原則可以適用到任何地方。機器也好、人員也罷，只能訪問他們適合訪問的資源。一旦有不恰當?shù)脑L問發(fā)生，應立即撤銷其

16、對應的權(quán)限。漏洞掃描會自動運行在所有相關的第三方特征庫之上。如果有最新的更新，則應立即升級各個漏洞庫。無論是否檢測到相關的漏洞，都應保持第三方特征庫為最新。因為某些修補程序可能僅適用于特征庫的最新版本，因此升級與更新將有助于避免出現(xiàn)重大的兼容性問題。針對潛在攻擊因素，應定期對應用程序（及其 CI/CD 環(huán)境）進行滲透測試。這些測試有時甚至可以作為 CD 管道的一部分，被自動化工具來完成。當然也可以通過定期的人為干預，如白帽子黑客，來增強效果。將應用與信息安全方面的培訓，放到所有新入職的開發(fā)人員的培訓計劃中，并讓他們得到持續(xù)教育。為產(chǎn)品代碼的變更開發(fā)工作流程，其中包含：攻擊向量因素和安全策略違規(guī)

17、等信息準確檢查與披露。例如，某個團隊使用著 GitHub PR(PullRequest)，那么提交者和審閱者都應使用同一個 PR 模板來進行編寫。3全員致力于安全速度在一些公司里，安全團隊常背負著“擋路人”的名聲。而實際情況卻是：在整個開發(fā)周期中，安全團隊往往過遲地獲悉新的系統(tǒng)與計劃。而無論開發(fā)進程是多么的流暢與快速，安全團隊始終有責任確保整體業(yè)務，不會因為新技術的部署而面臨風險。安全審批是需要時間的，特別是有大量項目并發(fā)進行的時候，當然，各種不滿的情緒很容易滋生。在一些“失?！钡慕M織中，開發(fā)人員甚至會秘密地部署那些未經(jīng)批準的應用，以顛覆安全團隊的權(quán)威，從而使事態(tài)更為惡化。因此，高績效的組織應

18、當從上述問題中認識根源，即：安全團隊被放置在了開發(fā)流程的錯誤位置。4將安全放到左邊經(jīng)驗豐富的團隊往往在開發(fā)新應用的早期階段就直接考慮到安全問題，讓安全團隊去檢查他們的架構(gòu)和技術選擇，并努力在流程中“將安全放到左邊”。如此，在大量代碼被編寫之前，安全團隊就能提早發(fā)現(xiàn)各種嚴重的問題，并能盡早解決。同時，此舉也會減少開發(fā)人員和安全人員之間的爭論，塑造出和諧的團隊關系。乍看來，“將安全放到左邊”在短時間內(nèi)會是一項吃力不討好的選擇。但是如果從整個開發(fā)的生命周期來看，早期的安全評估勢必會避免主要架構(gòu)在后期出現(xiàn)漏洞時的返工成本。實際上，早期的安全審查不但能降低開發(fā)項目的風險，還能為后續(xù)的發(fā)布周期降低成本。五

19、、自動化對于 DevOps 團隊來說，他們已經(jīng)能夠?qū)崿F(xiàn) QA、打補丁、部署、升級、回滾和災難恢復的自動執(zhí)行，并達到了前面提過的“不犯錯式快速推進”的效果。而對于高績效的 DevOps 團隊來說，他們還應當將安全性納入現(xiàn)有的自動化規(guī)劃之中，在不增加不當風險的前提下，實現(xiàn)快速的發(fā)布功能。1人類只做最擅長的事經(jīng)驗豐富的 DevOps 團隊不僅能夠最大限度地發(fā)揮系統(tǒng)自動化，還會持續(xù)尋找那些將人類重復執(zhí)行的任務轉(zhuǎn)化為自動化的機會。而安全性恰好就屬于這種自動化轉(zhuǎn)化的范疇。當然，在安全開發(fā)中也存在著一些僅適合人類完成的方面。例如：在新的應用程序被推出之前，以及在管理現(xiàn)有的應用程序時，安全團隊都是審查和判斷授

20、予各項權(quán)限的最佳選擇。盡管有許多高效的自動化工具可用于滲透測試，但是人類總能找到去攻擊軟件或系統(tǒng)的更好、更新的方法。2增加自動化，降低人數(shù)在大多數(shù)高績效的 DevOps 團隊中，一旦他們將持續(xù)集成（CI）的管道設置為以自動化的方式將應用程序推送到下個階段或是生產(chǎn)環(huán)境，那么操作人員就不必再參與應用程序的后期升級了。同樣，只要應用程序的安全政策沒有發(fā)生變更，且不需要增加新的權(quán)限，那就不需要讓安全人員作為審批的一個環(huán)節(jié)，也不可能造成瓶頸，甚至影響到應用的推進或上線。他們既然已經(jīng)人工批準了某個應用的注冊，那么只要該應用程序在運行時不需要更多的權(quán)限去訪問資源，升級應該被完全自動化。當然，在不影響安全性的

21、情況下，實現(xiàn)自動升級就需要在 CI 管道中設置更多的任務，包括：掃描第三方軟件庫和運行中的 CVE（Common Vulnerabilities and Exposures），檢查應用程序的代碼是否存在著安全漏洞，以及是否進行滲透測試等。這些自動化的配置雖然可能會需要一定的時間，但當它們被相互累計起來時，其成本、風險以及整體所花費的時間，都會比人工進行要節(jié)省得多。3自動化安全隨著數(shù)據(jù)中心自愈能力和災難恢復（DR）技術的發(fā)展，自動化安全沿著如下的發(fā)展路徑，逐步緩解了運營中可能出現(xiàn)的各種復雜故障：維護一個需要手動啟用的備用站點；對于手動站點的切換流程進行定期的演習與測試；完全自動化地切換到另一站點

22、；多個站點或區(qū)域同時運行，在出現(xiàn)故障時，能自動在系統(tǒng)中同步所有的差異；通過運用混沌工程（Chaos Engineering）原理故意造成基礎設施故障，進行測試。4自動化防范入侵自動化不但能協(xié)助高效的安全團隊做出及時的故障響應，還能防范各種入侵行為的發(fā)生。眾所周知，攻擊者入侵系統(tǒng)是需要時間的。如果某個關鍵數(shù)據(jù)庫的帳戶密碼需要每 90 天手動更改一次的話，那么他們將有幾個月的時間去試圖破解它。但是，如果該數(shù)據(jù)庫的密碼每天都自動更改（輪詢的方式），或更為頻繁的話，那么他們破解密碼的能力將大幅降低。5自動化響應入侵另一個防范入侵的關鍵因素是：定期自動化重構(gòu)基礎設施。即：通過虛擬機技術和自動化進程，可以

23、定期將服務器快速地恢復到已知的良好狀態(tài)，而不產(chǎn)生任何的宕機時間。在許多組織內(nèi)，各種自動化響應流程在檢測到入侵發(fā)生時，就啟動了自動恢復的進程，所有密碼被輪詢一次，而所有相關的“可調(diào)用”組件（如虛擬機、容器等）也被重新創(chuàng)建到過去已知的良好狀態(tài)。上面我們提到過，應當對災難恢復方案進行持續(xù)演習那樣，如果自動化流程也能夠持續(xù)測試與執(zhí)行的話，那么其相應的風險也會大幅降低。六、技術采用技術發(fā)展得如此迅速，以至于安全人員常被開發(fā)人員貼上“過時策略的執(zhí)行者”和“拒絕采用現(xiàn)代化工具”的標簽。如今，DevOps 使用到了各種 SaaS 產(chǎn)品，支持 CI、CD、配置管理以及各種編排的各種開源解決方案。安全團隊要想適應

24、該環(huán)境，并流暢地開展工作，就必須擁抱這些新的系統(tǒng)與技術。1安全理念的變遷劣等的安全團隊會負面地看待新的技術。對他們而言，現(xiàn)代化的工具代表了不斷增加的威脅因素、潛在的漏洞和受攻擊的可能性。而優(yōu)等的安全團隊則持有樂觀的態(tài)度，即：如果能安全地采用新的工具，組織的業(yè)務不但能夠運行得更快，而且組織也會更為安全。傳統(tǒng)的 IT 安全理念建立在靜態(tài)的本地數(shù)據(jù)中心和已知資產(chǎn)明細的基礎上。在系統(tǒng)邊界處，外圍防火墻作為主要的防御措施，抵御著各類攻擊。而內(nèi)部安全系統(tǒng)則專注于管理組織里的人員與機器。LDAP、Kerberos 和 Active Directory 是主流的管理身份與角色的工具。新添置的機器和新雇用的員工需要被手動配置到系統(tǒng)之中。如今，現(xiàn)代化的組織則使用微服務、容器、編排器（orchestrators）和無服務器技術來管理動態(tài)的基礎架構(gòu)。顯然這些與傳統(tǒng)的安全理念并不相稱。新的安全理念不再專注于“守住”生產(chǎn)環(huán)境中的資產(chǎn)，而是要更好地且“安全地支持企業(yè)的快速推進”。2新技術提高了安全性新的安