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

[[230791]]

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

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

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

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

當然，也有不少的公司在運用 DevOps“快速前行”的同時，保持著高標準的信息安全。

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

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

[[230792]]

安全策略即代碼

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

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

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

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

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

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

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

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

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

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

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

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

[[230793]]

職責分離

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

職責分離是速度的動因

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

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

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

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

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

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

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

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

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

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

每種角色的責任

開發(fā)人員：

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

運營人員：

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

安全人員：

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

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

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

[[230794]]

專注工作流與速度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

端到端簡化流程

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

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

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

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

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

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

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

高效的 DevOps 團隊應(yīng)當能夠通過如下方式，來實現(xiàn)高速且流暢的工作流程：

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

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

[[230795]]

安全的首要位置

軟件團隊通常會對嚴重的錯誤、蹩腳的設(shè)計和糟糕系統(tǒng)性能做出及時的響應(yīng)。因為這些問題既明顯又尖銳。

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

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

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

密碼的安全管理

密碼的安全管理需要注意以下幾點：

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

良好的安全習慣

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

全員致力于安全速度

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

而無論開發(fā)進程是多么的流暢與快速，安全團隊始終有責任確保整體業(yè)務(wù)，不會因為新技術(shù)的部署而面臨風險。

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

在一些“失常”的組織中，開發(fā)人員甚至會秘密地部署那些未經(jīng)批準的應(yīng)用，以顛覆安全團隊的權(quán)威，從而使事態(tài)更為惡化。

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

將安全放到左邊

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

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

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

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

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

[[230796]]

自動化

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

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

人類只做最擅長的事

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

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

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

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

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

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

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

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

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

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

自動化安全

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

維護一個需要手動啟用的備用站點。

對于手動站點的切換流程進行定期的演習與測試。

完全自動化地切換到另一站點。

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

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

自動化防范入侵

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

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

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

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

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

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

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

[[230797]]

技術(shù)采用

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

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

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

安全理念的變遷

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

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

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

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

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

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

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

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

例如，Beyond Corp 是 Google 的一個安全模型，它能夠?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)計算資產(chǎn)與用戶的安全理念。

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

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

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

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

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

舊思維與新思想

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

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

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

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

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