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

[[230791]]

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

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

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

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

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

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

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

[[230792]]

安全策略即代碼

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

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

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

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

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

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

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

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

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

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

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

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

[[230793]]

職責(zé)分離

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

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

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

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

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

每個(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)營(yíng)角色被組合在一起時(shí)，組織將不可避免地出現(xiàn)由單一角色所帶來(lái)的巨大風(fēng)險(xiǎn)。

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

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

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

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

每種角色的責(zé)任

開發(fā)人員：

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

運(yùn)營(yíng)人員：

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

安全人員：

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

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

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

[[230794]]

專注工作流與速度

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

為了實(shí)現(xiàn)此目標(biāo)，DevOps 團(tuán)隊(duì)需要通過(guò)創(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)的可視化會(huì)有助于分解出其中出現(xiàn)的緩慢步驟、識(shí)別出瓶頸、并優(yōu)化其速度。

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

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

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

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

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

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

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

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

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

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

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

相反如果需要在龐大的應(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ì)量問(wèn)題，則不得不迅速叫來(lái)安全人員進(jìn)行代碼審查。

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

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

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

端到端簡(jiǎn)化流程

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

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

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

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

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

如此，該服務(wù)的權(quán)限就已經(jīng)通過(guò)了審查，一旦完成部署，它將以“預(yù)先注冊(cè)”的方式去訪問(wèn)生產(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)能夠通過(guò)如下方式，來(lái)實(shí)現(xiàn)高速且流暢的工作流程：

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

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

[[230795]]

安全的首要位置

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

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

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

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

密碼的安全管理

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

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

良好的安全習(xí)慣

• 下面是以“安全為中心”的團(tuán)隊(duì)時(shí)常踐行的一些安全要點(diǎn)：
• 最小權(quán)限的原則可以適用到任何地方。機(jī)器也好、人員也罷，只能訪問(wèn)他們適合訪問(wèn)的資源。一旦有不恰當(dāng)?shù)脑L問(wèn)發(fā)生，應(yīng)立即撤銷其對(duì)應(yīng)的權(quán)限。
• 漏洞掃描會(huì)自動(dòng)運(yùn)行在所有相關(guān)的第三方特征庫(kù)之上。如果有最新的更新，則應(yīng)立即升級(jí)各個(gè)漏洞庫(kù)。
• 無(wú)論是否檢測(cè)到相關(guān)的漏洞，都應(yīng)保持第三方特征庫(kù)為最新。因?yàn)槟承┬扪a(bǔ)程序可能僅適用于特征庫(kù)的最新版本，因此升級(jí)與更新將有助于避免出現(xiàn)重大的兼容性問(wèn)題。
• 針對(duì)潛在攻擊因素，應(yīng)定期對(duì)應(yīng)用程序（及其 CI/CD 環(huán)境）進(jìn)行滲透測(cè)試。這些測(cè)試有時(shí)甚至可以作為 CD 管道的一部分，被自動(dòng)化工具來(lái)完成。當(dāng)然也可以通過(guò)定期的人為干預(yù)，如白帽子黑客，來(lái)增強(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 模板來(lái)進(jìn)行編寫。

全員致力于安全速度

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

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

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

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

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

將安全放到左邊

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

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

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

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

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

[[230796]]

自動(dòng)化

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

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

人類只做最擅長(zhǎng)的事

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

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

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

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

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

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

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

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

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

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

自動(dòng)化安全

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

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

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

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

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

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

自動(dòng)化防范入侵

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

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

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

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

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

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

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

[[230797]]

技術(shù)采用

技術(shù)發(fā)展得如此迅速，以至于安全人員常被開發(fā)人員貼上“過(guò)時(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ì)會(huì)負(fù)面地看待新的技術(shù)。對(duì)他們而言，現(xiàn)代化的工具代表了不斷增加的威脅因素、潛在的漏洞和受攻擊的可能性。

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

傳統(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ī)器和新雇用的員工需要被手動(dòng)配置到系統(tǒng)之中。

如今，現(xiàn)代化的組織則使用微服務(wù)、容器、編排器（orchestrators）和無(wú)服務(wù)器技術(shù)來(lái)管理動(dòng)態(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 并沒(méi)有將那些敏感的應(yīng)用放置在 VPN 后面，而是將它們部署到了公網(wǎng)之上。

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

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

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

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

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

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

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

舊思維與新思想

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

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

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

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

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