[[339257]]

【51CTO.com快譯】

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

身份標識

在設計新的分布式系統，或將單體應用(monolithic application)重構與增強為微服務時，人們往往會考慮每個微服務與其他微服務進行通信的業務應用和流程。那么與客戶、以及其他開發伙伴的合作過程中，我們需要采用微服務級別的身份標識。此類標識可以為我們帶來如下優勢：

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

跨云、域、主機和應用的負載

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

有研究表明：各類企業的大多數數據泄露事件都是由誤解所導致。這些誤解體現在：各種云服務和系統的安全配置策略，到底是云服務提供商的責任、還是應用所有者的職能。DevOps團隊應當確保在部署微服務之前，將合適的安全策略配置到云端環境中。

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

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

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

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

DevSecOps中的安全細節

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

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

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

用戶身份與服務身份

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

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

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

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

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

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

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