[[339257]]

【51CTO.com快譯】

隨著微服務(wù)流程和系統(tǒng)部署在DevOps實踐中的廣泛使用，DevOps工程師在軟件開發(fā)項目中的安全責任日益增大。我們需要通過良好的DevSecOps流程，在保證應(yīng)用部署、運營和服務(wù)監(jiān)視的同時，通過容器與微服務(wù)來加持安全性。

身份標識

在設(shè)計新的分布式系統(tǒng)，或?qū)误w應(yīng)用(monolithic application)重構(gòu)與增強為微服務(wù)時，人們往往會考慮每個微服務(wù)與其他微服務(wù)進行通信的業(yè)務(wù)應(yīng)用和流程。那么與客戶、以及其他開發(fā)伙伴的合作過程中，我們需要采用微服務(wù)級別的身份標識。此類標識可以為我們帶來如下優(yōu)勢：

• 由于身份標識通常不會被經(jīng)常更改，因此它有助于我們理解分布式應(yīng)用的處理過程。
• 由于不需要通過限制某些微服務(wù)來提供各類節(jié)點，因此我們可以充分利用容器編排的敏捷性。
• 無論是容器還是虛擬機，由于它們的主機身份可以被抽象地用身份標識來表示，因此我們可以據(jù)此實現(xiàn)平臺化。

跨云、域、主機和應(yīng)用的負載

在微服務(wù)實際應(yīng)用中，一個最大問題是：橫跨多個域環(huán)境、計算類型、以及混合云的身份標識傳遞問題。通常說來，由于分布式系統(tǒng)橫跨了不同的安全與身份域，我們很難實現(xiàn)對不同復(fù)雜環(huán)境的可用性管理，以及動態(tài)擴展。

有研究表明：各類企業(yè)的大多數(shù)數(shù)據(jù)泄露事件都是由誤解所導(dǎo)致。這些誤解體現(xiàn)在：各種云服務(wù)和系統(tǒng)的安全配置策略，到底是云服務(wù)提供商的責任、還是應(yīng)用所有者的職能。DevOps團隊應(yīng)當確保在部署微服務(wù)之前，將合適的安全策略配置到云端環(huán)境中。

針對上述需求，我們可以采取的方法是：在所有環(huán)境中使用單一的證書頒發(fā)機構(gòu)，來作為CA(certificate authority)。例如，作為開源工具的服務(wù)網(wǎng)格(service mesh)，就可以在越來越多的項目中被用作CA中心。雖然，各種服務(wù)網(wǎng)格系統(tǒng)的配置過程可能相當繁瑣，但是它們可以充當非常實用的安全和運營的控制點。在具體實現(xiàn)上，我們可以在Kubernetes的多個集群中配置Istio(譯者注：一種微服務(wù)系統(tǒng)管理工具)。通過向Istio添加非Kubernetes服務(wù)，進一步擴展其信任范圍。當然，這也會增加配置的復(fù)雜性，最終還是取決于每個項目所有者將如何限制其控制權(quán)限?？偟恼f來，鑒于可操作微服務(wù)的復(fù)雜性，隨著應(yīng)用程序的迭代和操作管控的加強，此舉會帶來如下方面的好處：

• 更快地完成代碼的編寫與部署。
• 可重復(fù)的dev-sec-ops流程。
• 使用質(zhì)量檢查與安全掃描工具，來獲取更高的安全性。
• 增加對于用戶使用的可用性。
• 實現(xiàn)軟件級的故障轉(zhuǎn)移(魯棒性)。
• 快速或動態(tài)地實現(xiàn)可擴展性。

當然，有些用戶也可以選擇僅使用內(nèi)部身份表示，以及只使用一個簡單的在線證書，然后將兩者在分布式微服務(wù)的不同CA處實現(xiàn)同步。由于此類設(shè)置具有一定的復(fù)雜性，因此僅被那些在微服務(wù)開發(fā)、安全性和運營管理方面，有著豐富經(jīng)驗的DecSecOps流程和團隊所采用。此外，我建議您在圍繞著自身的業(yè)務(wù)流程和計算架構(gòu)的成熟度，進行充分評估的基礎(chǔ)上，酌情采用。

有了前面的基礎(chǔ)，用戶在對多個不同的實體實施身份管理(包括：識別，控制，構(gòu)建，保護，配置，監(jiān)控，以及信任傳遞)時，就容易得多了。通常，微服務(wù)的信任建立過程是一組DevSecOps的流程和架構(gòu)。它們定義了如何在新的分布式系統(tǒng)環(huán)境中(無論是否使用Kubernetes)，如何對微服務(wù)進行身份驗證。同時，我們需要通過成功落地DevOps，來實現(xiàn)基于身份的云服務(wù)負載。也就是說，為了保護微服務(wù)，我們需要自動化定義，創(chuàng)建，管理和保護各種負載的身份，以及微服務(wù)實體，并促進無摩擦的零流程安全(frictionless zero process security)。

DevSecOps中的安全細節(jié)

在此，我們給出的一種解決方案是：建立一個平臺，通過CI/CD管道，為每一種微服務(wù)創(chuàng)建一個身份標識，以確保這種嵌入式身份能夠通過密碼綁定到內(nèi)存中。那么，當微服務(wù)被發(fā)布到生產(chǎn)環(huán)境中時，該標識便可利用相關(guān)策略，自動化地創(chuàng)建并加固其安全性。據(jù)此，我們不但可以保護生產(chǎn)環(huán)境免受攻擊的侵害和泄露的危險，而且能夠確保微服務(wù)僅與那些已完成標識和認證的微服務(wù)間進行通信。

此類方案實際上充當了一個自動化的安全層。它將CI/CD無縫地添加到了DevSecOps的實現(xiàn)中。此外，為了保護CI/CD之外的負載，我們還可以借用Cyber Armor(請參見--http://www.cyberarmor.io/)平臺，自動將身份標識作為CI/CD的一部分，予以創(chuàng)建，并在部署的過程中持續(xù)實施保護。

在Kubernetes里，由于認證服務(wù)適用于整個集群的各種默認帳戶，因此在實踐中，除非我們需要為某個帳戶的身份識別，采取特殊的配置，否則通常不會將其用于微服務(wù)的身份認證之中。在此，Istio的服務(wù)度量控制(service measurement control)正好能夠發(fā)揮作用。它可以用作微服務(wù)的身份標識，融入DevOps的流程和處理之中。

用戶身份與服務(wù)身份

從單體發(fā)展到基于微服務(wù)，應(yīng)用所處的環(huán)境越來越復(fù)雜，并行運行的軟件也越來越多。就安全問題而言，每一個組件都會給服務(wù)架構(gòu)帶來攻擊面。因此，無論是用戶，還是微服務(wù)，都應(yīng)當在服務(wù)架構(gòu)中得到充分的驗證，以保障合理的安全態(tài)勢。

在過去的單體應(yīng)用中，應(yīng)用只需在內(nèi)部完成了對于某個用戶的身份識別與驗證，便可決定該用戶的使用權(quán)限。如今，用戶需要在前端(front-end)的微服務(wù)處提供自己的身份標識，而各個微服務(wù)則利用JSON Web令牌，并結(jié)合AUTH0等框架，根據(jù)用戶在整個信任鏈條中傳遞的身份信息，來認證該用戶權(quán)限，進而決定其是否可以獲取某些敏感數(shù)據(jù)。

運維管理中的微服務(wù)安全性：工具和流程

有時候，針對微服務(wù)的攻擊并非來自某個用戶，而是針對應(yīng)用運行環(huán)境中的某些程序邏輯漏洞。因此，我們需要持續(xù)進行掃描，并與既定的構(gòu)建和配置狀態(tài)相比較，通過自動發(fā)現(xiàn)和應(yīng)用映射，做出相應(yīng)的安全性調(diào)整，以防止各種潛在的攻擊。而且，在檢測到攻擊時，我們可以使用Grafana(譯者注：開源的分析與監(jiān)控平臺)，來通過查看圖表的方式，深入獲悉攻擊的類型和其他具體信息。

此外，我們可以使用Radware這種應(yīng)用配置管理工具，來保護基于微服務(wù)的應(yīng)用。例如，在應(yīng)用發(fā)生更改時，Radware會根據(jù)配置策略，將變更信息反饋送到Sec Ops處進行評估和處理。也就是說，一旦發(fā)現(xiàn)更改，此類工具會進一步檢查容器的注冊表，Kubernetes也會將其與上一個狀態(tài)的配置鏡像作比較，通過記錄已發(fā)現(xiàn)的更改，進而在所有不同的DevOps團隊之間共享這些更改信息，以便實施補救。

【原標題】DevSecOps Using Container and Microservices Security，作者: Larry Gordon

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