如何消除“技術(shù)債”？高效DevOps團(tuán)隊(duì)的6個(gè)核武器

原創(chuàng)
作者：陳峻編譯 2018-05-29 09:37:37

云計(jì)算 如今，以 Netflix、Etsy、Flickr 為代表的各個(gè)公司，都持續(xù)以更少的時(shí)間、更快地發(fā)布出新的功能，而他們的成功秘訣就是用到了“DevOps”。

站在用戶的角度思考問題，與客戶深入溝通，找到榕城網(wǎng)站設(shè)計(jì)與榕城網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名與空間、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋榕城地區(qū)。

【51CTO.com原創(chuàng)稿件】如今，以 Netflix、Etsy、Flickr 為代表的各個(gè)公司，都持續(xù)以更少的時(shí)間、更快地發(fā)布出新的功能，而他們的成功秘訣就是用到了“DevOps”。

DevOps 如今已廣泛地被銀行、保險(xiǎn)公司、政府和許多重監(jiān)管的行業(yè)組織所采用。

這是一種交付軟件的新方法，它專注于持續(xù)集成、持續(xù)交付和消除工程與運(yùn)營團(tuán)隊(duì)之間的障礙，從而加快發(fā)布速度、并降低風(fēng)險(xiǎn)。

雖然 DevOps 被大多數(shù)軟件團(tuán)隊(duì)所熟知，但是很少有團(tuán)隊(duì)真正實(shí)踐并維護(hù)著與之相稱的安全控制。

像 Uber 和 eBay 之類存儲著大量個(gè)人敏感信息的組織，雖然運(yùn)用 DevOps 簡化了開發(fā)和運(yùn)營，推進(jìn)了功能開發(fā)的速度，但由于將安全隱患置于了次位，因此也遭遇過一些重大的違規(guī)事件。

當(dāng)然，也有不少的公司在運(yùn)用 DevOps“快速前行”的同時(shí)，保持著高標(biāo)準(zhǔn)的信息安全。

對此我們總結(jié)出了如上圖所示的 6 條基本原則：

• 安全策略即代碼
• 職責(zé)分離
• 專注工作流與速度
• 安全的首要位置
• 自動化
• 技術(shù)采用

安全策略即代碼

目前，在那些成功地將 DevOps 的速度與安全性結(jié)合的團(tuán)隊(duì)中，最重要的特性是：他們運(yùn)用代碼來指定各種安全策略。

DevOps 的基石是“基礎(chǔ)架構(gòu)即代碼（infrastructure as code）”，也稱“不可變基礎(chǔ)架構(gòu)”。

運(yùn)營者運(yùn)用代碼來聲明其基礎(chǔ)架構(gòu)的需求，從而取代了手工管理與配置服務(wù)器與軟件的舊模式。

這種方法能夠有效地抑制那些已被手動配置的服務(wù)器“獨(dú)角獸（unicorn）”們進(jìn)一步擴(kuò)散，進(jìn)而造成在出現(xiàn)故障時(shí)，卻無人知曉如何進(jìn)行重建這一尷尬局面。

更重要的是：它還能支持自動化擴(kuò)容，以及預(yù)測如何將新生成的功能部署到不同的測試與生產(chǎn)環(huán)境之中。

代表這種基礎(chǔ)架構(gòu)的代碼會與應(yīng)用程序代碼一樣被檢入到源代碼的控制之中，進(jìn)而可以實(shí)現(xiàn)版本控制、比較和保護(hù)。

那些安全實(shí)踐經(jīng)驗(yàn)較為豐富的 DevOps 團(tuán)隊(duì)，可以通過采用“基礎(chǔ)架構(gòu)即代碼”的模型來管理應(yīng)用程序的安全性。他們在新的應(yīng)用或微服務(wù)中，用代碼來聲明安全策略的各種需求。

例如，下面的一小段安全政策，就是一個(gè)用 Conjur 政策語言（請參考https://www.conjur.org/reference/policy.html）編寫的、提供貨幣換算服務(wù)的微服務(wù)：

由上可見，它的語法是人類可讀且易于理解的。即：該代碼允許授予了貨幣轉(zhuǎn)換服務(wù)（currency-converter）權(quán)限，去訪問一個(gè)存儲著各種貨幣值的數(shù)據(jù)庫密碼。

該政策是完全獨(dú)立且可不限重復(fù)的，既不依賴于外部因素，也不會被未來的解釋方式所左右。它完全可以被檢入到源代碼的控制中，作為應(yīng)用代碼的一部分被予以內(nèi)部實(shí)現(xiàn)。

那些日常管理著數(shù)千個(gè)應(yīng)用相關(guān)權(quán)限的安全人員，可以通過該“安全策略即代碼”模型，將自身的團(tuán)隊(duì)能力提升到一個(gè)新的水平，并能使得自己的工作更具可預(yù)測性。而這些恰是過去那些需要手動配置與應(yīng)用相關(guān)的安全權(quán)限所無法企及的。

所以，“安全策略即代碼”對于創(chuàng)建高效的安全 DevOps 流程是至關(guān)重要的。沒有它，我們后面將要談到的安全 DevOps 各個(gè)方面都將無法實(shí)現(xiàn)。

職責(zé)分離

令人遺憾的是，在許多軟件團(tuán)隊(duì)中，開發(fā)人員和操作人員還肩負(fù)著安全的職責(zé)，他們需要維護(hù)服務(wù)相關(guān)的帳戶、定義各種安全控制、控制對于敏感數(shù)據(jù)的訪問等。這些無疑增加了他們已有的且“滿滿的”工作量。

職責(zé)分離是速度的動因

大多數(shù)關(guān)于職責(zé)分離的文章都會提到它在防止利益沖突和欺詐方面的好處，以及如何通過它來減少任何人超額擁有其本該擁有的基本權(quán)力。

然而從另一個(gè)角度來看，高績效的 DevOps 團(tuán)隊(duì)會將職責(zé)分離視為一種機(jī)會，他們籍此來保證團(tuán)隊(duì)成員僅專注于自己最擅長的工作，并能夠根據(jù)每個(gè)人的能力來適當(dāng)優(yōu)化團(tuán)隊(duì)整體的工作流程。

成熟的團(tuán)隊(duì)具有明確的角色和清晰的職責(zé)分工。安全和監(jiān)督由專門的安全人員來負(fù)責(zé)，開發(fā)人員會專注于編寫代碼，而操作人員則確保生產(chǎn)環(huán)境架構(gòu)能健康運(yùn)營。

每個(gè)職能團(tuán)隊(duì)之間的接口“傳遞”已被編入到了安全策略之中。即：開發(fā)人員創(chuàng)建安全策略聲明其應(yīng)用程序或服務(wù)所需要的權(quán)限→安全人員隨即審核并批準(zhǔn)相關(guān)的代碼更改→操作人員確保應(yīng)用程序的部署、并能夠按照預(yù)期運(yùn)行。

職責(zé)結(jié)合：一種痛苦的反模式

當(dāng)任何一種開發(fā)、安全和運(yùn)營角色被組合在一起時(shí)，組織將不可避免地出現(xiàn)由單一角色所帶來的巨大風(fēng)險(xiǎn)。

對于開發(fā)者來說，他們通常無法意識到自己在生產(chǎn)系統(tǒng)中可能所擁有的權(quán)限，因此也就無法預(yù)知自己的某種疏忽會給組織帶來的危害程度。

例如：去年某公司的初級工程師在入職的第一天，就意外地刪除了該公司的生產(chǎn)數(shù)據(jù)庫。而發(fā)生這種情況的原因，正是因?yàn)樗毁x予了在生產(chǎn)系統(tǒng)中的所有權(quán)限。

就他所擁有的訪問權(quán)限而言，這位不幸的開發(fā)人員在完全不知的情況下，同時(shí)扮演著運(yùn)營人員的角色。

因此，問題的根源不在他的身上，而來自雇主：他們沒有將職責(zé)分離，沒能在源頭防范此類情況的發(fā)生。

每種角色的責(zé)任

開發(fā)人員：

• 能夠編寫代碼和測試案例，而不必?fù)?dān)心意外地觸碰生產(chǎn)環(huán)境。
• 與運(yùn)營人員交流其應(yīng)用所涉及到的主機(jī)需求。
• 與安全人員交流其應(yīng)用所涉及到的安全需求。

運(yùn)營人員：

• 執(zhí)行并實(shí)現(xiàn)應(yīng)用程序有關(guān)主機(jī)（虛機(jī)）的需求。
• 保證生產(chǎn)環(huán)境的可用性。

安全人員：

• 針對開發(fā)人員的應(yīng)用需求授予相關(guān)權(quán)限。
• 確保系統(tǒng)范圍內(nèi)，各種安全措施的落實(shí)與到位。

正如企業(yè)采用 DevOps 模式并不意味著開發(fā)人員需要承擔(dān)運(yùn)營角色那樣，采用“DevSecOps”也并非意味著開發(fā)人員必須成為安全專家。

因此，高績效的組織應(yīng)當(dāng)學(xué)會避免出現(xiàn)“快速推進(jìn)卻時(shí)常犯錯(cuò)”的行動狀態(tài)。他們需要的應(yīng)當(dāng)是“在知曉不會犯錯(cuò)的基礎(chǔ)上快速推進(jìn)”的各司其職模式。

專注工作流與速度

DevOps 的核心概念是產(chǎn)生可持續(xù)的、平穩(wěn)的工作流程。

為了實(shí)現(xiàn)此目標(biāo)，DevOps 團(tuán)隊(duì)需要通過創(chuàng)建各種 CI/CD 管道、持續(xù)進(jìn)行小而頻繁的代碼變更、端到端的部署、并采用類似基于微服務(wù)的系統(tǒng)架構(gòu)，以獲取上文提到的快速推進(jìn)。

建模和優(yōu)化安全的工作流程

看板（Kanban）是一個(gè)專注于流程和開發(fā)速度的工作系統(tǒng)。其核心是將工作的各個(gè)階段可視化，即：隨著項(xiàng)目在不同階段的推進(jìn)，各個(gè)狀態(tài)的可視化會有助于分解出其中出現(xiàn)的緩慢步驟、識別出瓶頸、并優(yōu)化其速度。

一個(gè)長期面臨發(fā)布延遲的組織可能會發(fā)現(xiàn)：安全審查階段在自己的系統(tǒng)中花費(fèi)的時(shí)間較長。

原因通常在于：安全審查開始得比較晚，并且所涉及的量又比較大。換句話說：太多的東西會一下子被“甩到”安全審查團(tuán)隊(duì)的面前。

那些經(jīng)驗(yàn)豐富的組織一般會“將安全放到左邊”（在可視化看板中，一般假設(shè)工作流程從左邊開始，向右邊流動）。

這就意味著：安全團(tuán)隊(duì)越早介入新版本/功能的開發(fā)，就越好。同時(shí)，如果他們在整個(gè)開發(fā)周期的早期階段，就能揭示出重大的安全問題，那么就可以防止后期出現(xiàn)延遲交付的情況。

為速度加固微服務(wù)

微服務(wù)架構(gòu)給安全團(tuán)隊(duì)提供了許多好處，尤其是那些專注于自身發(fā)布速度的團(tuán)隊(duì)。

我們繼續(xù)以前面 “貨幣換算”的微服務(wù)為例。如果安全團(tuán)隊(duì)只需要檢查并授權(quán)該應(yīng)用去訪問單個(gè)數(shù)據(jù)庫的話，那么還是相對較為簡單的。

但是如果該功能被置于一個(gè)龐大的且擁有數(shù)百萬行代碼的應(yīng)用體系之內(nèi)時(shí)，那么安全團(tuán)隊(duì)就可能需要對許多方面的變化進(jìn)行梳理，以查找出對他們來說非常重要的審查內(nèi)容。

同時(shí)，如果該龐大的應(yīng)用在版本上經(jīng)歷了許多實(shí)質(zhì)性的變更，則會將審查變得更困難。

畢竟，只讓安全團(tuán)隊(duì)檢查幾十行的安全策略代碼和讓他們檢查上千行代碼相比還是容易得多的。

如果新的版本不需要修改任何權(quán)限，那么對于已經(jīng)注冊的微服務(wù)代碼進(jìn)行持續(xù)升級還是能保持快速的。

相反如果需要在龐大的應(yīng)用中退役或關(guān)停某個(gè)微服務(wù)，則需要考慮到所涉及的各種耦合關(guān)系和代碼層面的規(guī)模。

傳統(tǒng)團(tuán)隊(duì)在經(jīng)歷了瀑布式開發(fā)之后，常趨向于進(jìn)行“爆炸式（big-bang）”發(fā)布應(yīng)用。而一旦應(yīng)用出現(xiàn)了質(zhì)量問題，則不得不迅速叫來安全人員進(jìn)行代碼審查。

如此一來，安全團(tuán)隊(duì)所面臨的往往是累積了成上千次變更后的應(yīng)用代碼和來自業(yè)務(wù)方面為了應(yīng)用能早日上線的不斷施壓。

因此，那些保持持續(xù)交付的大型團(tuán)隊(duì)，會將他們的代碼庫分解成多個(gè)微服務(wù)來實(shí)現(xiàn)。

同時(shí)他們也會邀請安全團(tuán)隊(duì)運(yùn)用各種專業(yè)的、精細(xì)化的模型來進(jìn)行各種安全審查，以有助于加快發(fā)布進(jìn)度、并提高可視性。

端到端簡化流程

DevOps 引入了“盡早實(shí)現(xiàn)端到端”的概念。這是一種簡單的降低交付風(fēng)險(xiǎn)、并提高預(yù)估信心的方法。

對于團(tuán)隊(duì)成員來說，他們能夠越快地將新服務(wù)“連接管道”，就能夠越快地獲知如何順利地去構(gòu)建部署流程，以及應(yīng)對頻繁的升級和更新。

同時(shí)，一些未完全實(shí)現(xiàn)的功能標(biāo)志可以被隱藏地部署到生產(chǎn)環(huán)境之中，等到新的功能完善了，再向用戶全面展示和開放。

這種方法同樣也能夠很好地降低服務(wù)中的安全變更風(fēng)險(xiǎn)，特別是當(dāng)團(tuán)隊(duì)采用了“安全策略即代碼”的原則后。

例如，一項(xiàng)新的服務(wù)需要訪問內(nèi)部 CRM 數(shù)據(jù)庫和支付網(wǎng)關(guān)，那么該團(tuán)隊(duì)的首要任務(wù)就是為該服務(wù)構(gòu)建出一個(gè) CI/CD 管道，然后等基本連接構(gòu)建好之后，再將該管道升至 0.1 版本。

如此，該服務(wù)的權(quán)限就已經(jīng)通過了審查，一旦完成部署，它將以“預(yù)先注冊”的方式去訪問生產(chǎn)環(huán)境中的各種敏感資源。

由此可見，這樣便消除了后續(xù)版本的部署風(fēng)險(xiǎn)，開發(fā)人員可以在后期去創(chuàng)建并實(shí)現(xiàn)剩余的功能。同時(shí)，安全團(tuán)隊(duì)也提前獲知了服務(wù)的權(quán)限與安全的設(shè)置需求。

高效的 DevOps 團(tuán)隊(duì)?wèi)?yīng)當(dāng)能夠通過如下方式，來實(shí)現(xiàn)高速且流暢的工作流程：

• 使用看板視圖來發(fā)現(xiàn)開發(fā)周期中的瓶頸，并優(yōu)化它們。
• “將安全放到左邊”，讓安全團(tuán)隊(duì)盡早參與到開發(fā)周期之中，從而盡早發(fā)現(xiàn)相關(guān)的安全問題。
• 使用“安全策略即代碼”的方法讓開發(fā)、安全和運(yùn)營團(tuán)隊(duì)進(jìn)行高效且明確的溝通。
• 將大型應(yīng)用分解為更小的微服務(wù)，每個(gè)微服務(wù)都要有自己的安全策略。
• 盡可能減少大批量的變更，使安全團(tuán)隊(duì)能夠持續(xù)、少量、可預(yù)知地進(jìn)行安全審查。
• 盡早實(shí)現(xiàn)“端到端”模式，以降低組件和模塊的持續(xù)升級所帶來的風(fēng)險(xiǎn)。

無論您的公司有著上百位開發(fā)人員，還是只有較小規(guī)模的團(tuán)隊(duì)，上述安全開發(fā)的流程原則都會給您帶來幫助。

安全的首要位置

軟件團(tuán)隊(duì)通常會對嚴(yán)重的錯(cuò)誤、蹩腳的設(shè)計(jì)和糟糕系統(tǒng)性能做出及時(shí)的響應(yīng)。因?yàn)檫@些問題既明顯又尖銳。

而作為“硬幣另一面”,他們對于那些所謂的“技術(shù)債”，則只是通過一些預(yù)防性工作予以滯后解決，甚至擠壓下來，直到將來失控，并造成更大的問題。

因此，經(jīng)驗(yàn)豐富的 DevOps 團(tuán)隊(duì)通常應(yīng)當(dāng)把安全問題視為“頭等公民”，放在急需解決的首要位置，而不能將它們積壓到 To-Do（待辦）列表中，甚至永遠(yuǎn)不去解決。

既然一個(gè)團(tuán)隊(duì)能夠重視應(yīng)用中的漏洞以及安全性，那么他們自然會在開發(fā)和發(fā)布過程中采取各種恰當(dāng)?shù)陌踩胧Ｎ覀兿旅鎭碓敿?xì)研究一下這些安全實(shí)踐。

密碼的安全管理

密碼的安全管理需要注意以下幾點(diǎn)：

• 與生產(chǎn)系統(tǒng)有關(guān)的所有密碼信息（密碼、私鑰、或攻擊者可以利用的任何敏感信息）都應(yīng)存儲在安全且高可用的庫中，并且只有被授權(quán)訪問它們的系統(tǒng)，能在恰當(dāng)?shù)臅r(shí)間段訪問到。
• 不允許庫管訪問到具體的密碼值/信息。
• 確保密碼根據(jù)既定的時(shí)間表自動變更，進(jìn)而控制其有效時(shí)間。

良好的安全習(xí)慣

• 下面是以“安全為中心”的團(tuán)隊(duì)時(shí)常踐行的一些安全要點(diǎn)：
• 最小權(quán)限的原則可以適用到任何地方。機(jī)器也好、人員也罷，只能訪問他們適合訪問的資源。一旦有不恰當(dāng)?shù)脑L問發(fā)生，應(yīng)立即撤銷其對應(yīng)的權(quán)限。
• 漏洞掃描會自動運(yùn)行在所有相關(guān)的第三方特征庫之上。如果有最新的更新，則應(yīng)立即升級各個(gè)漏洞庫。
• 無論是否檢測到相關(guān)的漏洞，都應(yīng)保持第三方特征庫為最新。因?yàn)槟承┬扪a(bǔ)程序可能僅適用于特征庫的最新版本，因此升級與更新將有助于避免出現(xiàn)重大的兼容性問題。
• 針對潛在攻擊因素，應(yīng)定期對應(yīng)用程序（及其 CI/CD 環(huán)境）進(jìn)行滲透測試。這些測試有時(shí)甚至可以作為 CD 管道的一部分，被自動化工具來完成。當(dāng)然也可以通過定期的人為干預(yù)，如白帽子黑客，來增強(qiáng)效果。
• 將應(yīng)用與信息安全方面的培訓(xùn)，放到所有新入職的開發(fā)人員的培訓(xùn)計(jì)劃中，并讓他們得到持續(xù)教育。
• 為產(chǎn)品代碼的變更開發(fā)工作流程，其中包含：攻擊向量因素和安全策略違規(guī)等信息準(zhǔn)確檢查與披露。例如，某個(gè)團(tuán)隊(duì)使用著 GitHub PR(PullRequest)，那么提交者和審閱者都應(yīng)使用同一個(gè) PR 模板來進(jìn)行編寫。

全員致力于安全速度

在一些公司里，安全團(tuán)隊(duì)常背負(fù)著“擋路人”的名聲。而實(shí)際情況卻是：在整個(gè)開發(fā)周期中，安全團(tuán)隊(duì)往往過遲地獲悉新的系統(tǒng)與計(jì)劃。

而無論開發(fā)進(jìn)程是多么的流暢與快速，安全團(tuán)隊(duì)始終有責(zé)任確保整體業(yè)務(wù)，不會因?yàn)樾录夹g(shù)的部署而面臨風(fēng)險(xiǎn)。

安全審批是需要時(shí)間的，特別是有大量項(xiàng)目并發(fā)進(jìn)行的時(shí)候，當(dāng)然，各種不滿的情緒很容易滋生。

在一些“失?！钡慕M織中，開發(fā)人員甚至?xí)孛艿夭渴鹉切┪唇?jīng)批準(zhǔn)的應(yīng)用，以顛覆安全團(tuán)隊(duì)的權(quán)威，從而使事態(tài)更為惡化。

因此，高績效的組織應(yīng)當(dāng)從上述問題中認(rèn)識根源，即：安全團(tuán)隊(duì)被放置在了開發(fā)流程的錯(cuò)誤位置。

將安全放到左邊

經(jīng)驗(yàn)豐富的團(tuán)隊(duì)往往在開發(fā)新應(yīng)用的早期階段就直接考慮到安全問題，讓安全團(tuán)隊(duì)去檢查他們的架構(gòu)和技術(shù)選擇，并努力在流程中“將安全放到左邊”。

如此，在大量代碼被編寫之前，安全團(tuán)隊(duì)就能提早發(fā)現(xiàn)各種嚴(yán)重的問題，并能盡早解決。

同時(shí)，此舉也會減少開發(fā)人員和安全人員之間的爭論，塑造出和諧的團(tuán)隊(duì)關(guān)系。

乍看來，“將安全放到左邊”在短時(shí)間內(nèi)會是一項(xiàng)吃力不討好的選擇。但是如果從整個(gè)開發(fā)的生命周期來看，早期的安全評估勢必會避免主要架構(gòu)在后期出現(xiàn)漏洞時(shí)的返工成本。

實(shí)際上，早期的安全審查不但能降低開發(fā)項(xiàng)目的風(fēng)險(xiǎn)，還能為后續(xù)的發(fā)布周期降低成本。

自動化

對于 DevOps 團(tuán)隊(duì)來說，他們已經(jīng)能夠?qū)崿F(xiàn) QA、打補(bǔ)丁、部署、升級、回滾和災(zāi)難恢復(fù)的自動執(zhí)行，并達(dá)到了前面提過的“不犯錯(cuò)式快速推進(jìn)”的效果。

而對于高績效的 DevOps 團(tuán)隊(duì)來說，他們還應(yīng)當(dāng)將安全性納入現(xiàn)有的自動化規(guī)劃之中，在不增加不當(dāng)風(fēng)險(xiǎn)的前提下，實(shí)現(xiàn)快速的發(fā)布功能。

人類只做最擅長的事

經(jīng)驗(yàn)豐富的 DevOps 團(tuán)隊(duì)不僅能夠最大限度地發(fā)揮系統(tǒng)自動化，還會持續(xù)尋找那些將人類重復(fù)執(zhí)行的任務(wù)轉(zhuǎn)化為自動化的機(jī)會。

而安全性恰好就屬于這種自動化轉(zhuǎn)化的范疇。當(dāng)然，在安全開發(fā)中也存在著一些僅適合人類完成的方面。

例如：在新的應(yīng)用程序被推出之前，以及在管理現(xiàn)有的應(yīng)用程序時(shí)，安全團(tuán)隊(duì)都是審查和判斷授予各項(xiàng)權(quán)限的最佳選擇。

盡管有許多高效的自動化工具可用于滲透測試，但是人類總能找到去攻擊軟件或系統(tǒng)的更好、更新的方法。

增加自動化，降低人數(shù)

在大多數(shù)高績效的 DevOps 團(tuán)隊(duì)中，一旦他們將持續(xù)集成（CI）的管道設(shè)置為以自動化的方式將應(yīng)用程序推送到下個(gè)階段或是生產(chǎn)環(huán)境，那么操作人員就不必再參與應(yīng)用程序的后期升級了。

同樣，只要應(yīng)用程序的安全政策沒有發(fā)生變更，且不需要增加新的權(quán)限，那就不需要讓安全人員作為審批的一個(gè)環(huán)節(jié)，也不可能造成瓶頸，甚至影響到應(yīng)用的推進(jìn)或上線。

他們既然已經(jīng)人工批準(zhǔn)了某個(gè)應(yīng)用的注冊，那么只要該應(yīng)用程序在運(yùn)行時(shí)不需要更多的權(quán)限去訪問資源，升級應(yīng)該被完全自動化。

當(dāng)然，在不影響安全性的情況下，實(shí)現(xiàn)自動升級就需要在 CI 管道中設(shè)置更多的任務(wù)，包括：掃描第三方軟件庫和運(yùn)行中的 CVE（Common Vulnerabilities and Exposures），檢查應(yīng)用程序的代碼是否存在著安全漏洞，以及是否進(jìn)行滲透測試等。

這些自動化的配置雖然可能會需要一定的時(shí)間，但當(dāng)它們被相互累計(jì)起來時(shí)，其成本、風(fēng)險(xiǎn)以及整體所花費(fèi)的時(shí)間，都會比人工進(jìn)行要節(jié)省得多。

自動化安全

隨著數(shù)據(jù)中心自愈能力和災(zāi)難恢復(fù)（DR）技術(shù)的發(fā)展，自動化安全沿著如下的發(fā)展路徑，逐步緩解了運(yùn)營中可能出現(xiàn)的各種復(fù)雜故障：

維護(hù)一個(gè)需要手動啟用的備用站點(diǎn)。

對于手動站點(diǎn)的切換流程進(jìn)行定期的演習(xí)與測試。

完全自動化地切換到另一站點(diǎn)。

多個(gè)站點(diǎn)或區(qū)域同時(shí)運(yùn)行，在出現(xiàn)故障時(shí)，能自動在系統(tǒng)中同步所有的差異。

通過運(yùn)用混沌工程（Chaos Engineering）原理故意造成基礎(chǔ)設(shè)施故障，進(jìn)行測試。

自動化防范入侵

自動化不但能協(xié)助高效的安全團(tuán)隊(duì)做出及時(shí)的故障響應(yīng)，還能防范各種入侵行為的發(fā)生。

眾所周知，攻擊者入侵系統(tǒng)是需要時(shí)間的。如果某個(gè)關(guān)鍵數(shù)據(jù)庫的帳戶密碼需要每 90 天手動更改一次的話，那么他們將有幾個(gè)月的時(shí)間去試圖破解它。

但是，如果該數(shù)據(jù)庫的密碼每天都自動更改（輪詢的方式），或更為頻繁的話，那么他們破解密碼的能力將大幅降低。

自動化響應(yīng)入侵

另一個(gè)防范入侵的關(guān)鍵因素是：定期自動化重構(gòu)基礎(chǔ)設(shè)施。即：通過虛擬機(jī)技術(shù)和自動化進(jìn)程，可以定期將服務(wù)器快速地恢復(fù)到已知的良好狀態(tài)，而不產(chǎn)生任何的宕機(jī)時(shí)間。

在許多組織內(nèi)，各種自動化響應(yīng)流程在檢測到入侵發(fā)生時(shí)，就啟動了自動恢復(fù)的進(jìn)程，所有密碼被輪詢一次，而所有相關(guān)的“可調(diào)用”組件（如虛擬機(jī)、容器等）也被重新創(chuàng)建到過去已知的良好狀態(tài)。

上面我們提到過，應(yīng)當(dāng)對災(zāi)難恢復(fù)方案進(jìn)行持續(xù)演習(xí)那樣，如果自動化流程也能夠持續(xù)測試與執(zhí)行的話，那么其相應(yīng)的風(fēng)險(xiǎn)也會大幅降低。

技術(shù)采用

技術(shù)發(fā)展得如此迅速，以至于安全人員常被開發(fā)人員貼上“過時(shí)策略的執(zhí)行者”和“拒絕采用現(xiàn)代化工具”的標(biāo)簽。

如今，DevOps 使用到了各種 SaaS 產(chǎn)品，支持 CI、CD、配置管理以及各種編排的各種開源解決方案。

安全團(tuán)隊(duì)要想適應(yīng)該環(huán)境，并流暢地開展工作，就必須擁抱這些新的系統(tǒng)與技術(shù)。

安全理念的變遷

劣等的安全團(tuán)隊(duì)會負(fù)面地看待新的技術(shù)。對他們而言，現(xiàn)代化的工具代表了不斷增加的威脅因素、潛在的漏洞和受攻擊的可能性。

而優(yōu)等的安全團(tuán)隊(duì)則持有樂觀的態(tài)度，即：如果能安全地采用新的工具，組織的業(yè)務(wù)不但能夠運(yùn)行得更快，而且組織也會更為安全。

傳統(tǒng)的 IT 安全理念建立在靜態(tài)的本地?cái)?shù)據(jù)中心和已知資產(chǎn)明細(xì)的基礎(chǔ)上。在系統(tǒng)邊界處，外圍防火墻作為主要的防御措施，抵御著各類攻擊。

而內(nèi)部安全系統(tǒng)則專注于管理組織里的人員與機(jī)器。LDAP、Kerberos 和 Active Directory 是主流的管理身份與角色的工具。新添置的機(jī)器和新雇用的員工需要被手動配置到系統(tǒng)之中。

如今，現(xiàn)代化的組織則使用微服務(wù)、容器、編排器（orchestrators）和無服務(wù)器技術(shù)來管理動態(tài)的基礎(chǔ)架構(gòu)。

顯然這些與傳統(tǒng)的安全理念并不相稱。新的安全理念不再專注于“守住”生產(chǎn)環(huán)境中的資產(chǎn)，而是要更好地且“安全地支持企業(yè)的快速推進(jìn)”。

新技術(shù)提高了安全性

新的安全保護(hù)措施，有助于各種安全流程跟上 IT 系統(tǒng)的發(fā)展節(jié)奏，并能防止影子 IT 的威脅。

例如，Beyond Corp 是 Google 的一個(gè)安全模型，它能夠?qū)⒏鞣N內(nèi)部應(yīng)用轉(zhuǎn)換為典型的部署模型。Google 并沒有將那些敏感的應(yīng)用放置在 VPN 后面，而是將它們部署到了公網(wǎng)之上。

對于這些應(yīng)用的訪問，完全取決于訪問者的身份，而并非他們所處的網(wǎng)絡(luò)。這就顛覆了傳統(tǒng)的IT策略，并為 Google 和使用它的其他組織提供了巨大的速度與靈活性。

Conjur 同樣在其產(chǎn)品中也用到了：將身份識別應(yīng)用于所有的動態(tài)計(jì)算資產(chǎn)與用戶的安全理念。

其他一些以開發(fā)人員為中心的技術(shù)，也從根本上減少了開發(fā)者所需要訪問的敏感資產(chǎn)數(shù)量。它們有助于更好地實(shí)現(xiàn)職責(zé)分離。

例如，像 Pivotal Cloud Foundry 之類的 PaaS 系統(tǒng)和像 Kubernetes 這樣的部署編排器，能為開發(fā)人員提供完全隔離的、且獨(dú)立于系統(tǒng)操作的清晰視圖。

無服務(wù)器技術(shù)同樣能夠大幅提高系統(tǒng)的安全性。由于使用虛擬機(jī)或容器的開發(fā)人員，能夠“近距離地”接觸到操作系統(tǒng)，這給資產(chǎn)和敏感數(shù)據(jù)帶來了風(fēng)險(xiǎn)。

然而，在無服務(wù)器或“功能即服務(wù)（FaaS）”的模型中，這些資產(chǎn)是完全無法被訪問到的。

因此，對于大多數(shù)安全團(tuán)隊(duì)來說，與其去監(jiān)控并保護(hù)開發(fā)人員可能訪問到的資產(chǎn)，不如直接不讓他們“知曉”。

舊思維與新思想

傳統(tǒng)的 IT 安全模型著眼于：確定哪些資產(chǎn)需要被控制，然后構(gòu)建出結(jié)構(gòu)來“守住”它們。因此，所有工作流程都基于這種集中式的管控模型。

而新的方法則假設(shè)：手頭已經(jīng)沒有一套完整的系統(tǒng)資產(chǎn)對應(yīng)圖表了，應(yīng)當(dāng)使用的簡單而有效的準(zhǔn)則。

即：每個(gè)實(shí)體都必須具有身份，必須通過策略清楚地傳達(dá)權(quán)限的更改，明確職責(zé)的分離，通過自動化的實(shí)現(xiàn)提高業(yè)務(wù)的推進(jìn)速度。

借助這一全新的理念，現(xiàn)代化的 DevOps 團(tuán)隊(duì)將能夠在不犧牲安全性的情況下，保持高速的交付能力。而且這種新的理念、方法和模型勢必會被所有的組織所接受。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】

當(dāng)前題目：如何消除“技術(shù)債”？高效DevOps團(tuán)隊(duì)的6個(gè)核武器
分享網(wǎng)址：http://www.5511xx.com/article/ccdihci.html