雲原生3R原則、現代最小許可權與DevSecOps平臺建設 - octo

banq發表於2021-07-29
dev

幾個月前，VMware 現代應用程式技術長 James Watters 在雲原生安全日上發表了一篇 引人入勝的演講，他稱之為“現代最小特權”。基本概念是在  整個 DevSecOps 生命週期中應用最小許可權原則來正確保護現代應用程式。
我想深入研究這個策略並在這裡分享我們的觀點。 
現代應用程式比傳統應用程式更復雜——它們規模更大、變化更快、分佈更廣（即，沒有傳統的安全邊界）。雖然這似乎會使保護它們變得更加困難，但云原生開發空間中的許多創新如果得到適當利用，可以 透過自動化它們並使它們成為預設/簡單選項，從而使安全的許多方面 變得更容易。
 

3R原則
隨著行業在過去十年中採用雲原生應用程式，已經出現了一套明確的最佳實踐。這些最佳實踐之一被稱為 “3R” （ repair, repave, rotate） ——修復、重鋪、旋轉：   

  • 修復：在更新可用時立即修復易受攻擊的軟體。 
  • Repave：從已知的良好狀態重新修復伺服器和應用程式，經常做。 
  • 輪換：頻繁輪換系統憑據，因此它們僅在短時間內有用。 

支援 3 R 的雲原生架構有幾個原則： 
  • 不變性：一旦部署了某些東西，就不應對其進行修改或重新配置。任何新程式碼、配置更改或任何其他更改都應該在原始碼管理中進行，並且應該部署一個新的、不可變的例項。最低許可權意味著部署後沒有任何更改。 

  • 短暫性：許多傳統應用程式都有可以存活數月或數年的元件或例項（例如，VM）。這為駭客提供了一個很大的機會來訪問該應用程式並利用該訪問許可權進行進一步的攻擊。根據合同，雲原生設計原則側重於臨時性和最小化例項存在的時間長度。Repaving 不斷減少駭客入侵系統的時間。最小特權意味著將駭客的機會視窗儘可能地接近於零。 
  • 臨時身份： 類似的原則適用於身份和秘密——你不希望任何長期存在的東西，因為這為駭客提供了利用這些憑據的機會。相反，您需要頻繁輪換憑證的自動化。最低特權再次意味著向零前進。 
  • 事件驅動的漏洞管理：如果你有一個完全自動化的 CI/CD 管道並且你有正確的漏洞管理工具，你可以連線它們，以便在發現漏洞和修復可用時，系統可以自動啟動重新部署。這變成了事件驅動的安全問題重鋪。全部自動化，無需人工參與！最小特權意味著將發現漏洞和修補漏洞之間的時間間隔儘可能地縮短到零。 
  • DevX 作為控制（Shift left + DevX）： 提供出色的開發人員體驗意味著允許開發人員專注於他們的業務邏輯。開發人員應該考慮安全性，但理想情況下，DevSecOps 平臺只為他們處理大部分。即，安全控制儘可能地是內建的。最低許可權意味著在可能的情況下自動和透明地執行控制。 

這些原則彙集在無伺服器應用程式中。無伺服器應用程式是不可變的、短暫的，並且首先使用 API。但是這些原則可以應用於微服務和許多其他型別的架構。
 

自動化3R
任意數量的事件都可以觸發Repave重鋪。它可能是檢查新程式碼的開發人員、進行配置更改的站點可靠性工程師 (SRE)，或者檢測漏洞並自動應用修復程式的安全系統。
在所有情況下，它都是相同的標準和安全流程。事實上，當您在自動化之上構建更高階的策略時，您可以開始做一些很酷的事情。例如，如果您的安全系統發現漏洞或配置錯誤，則可能會觸發重新部署。
但是它再次注意到該應用程式再次具有相同的漏洞或配置錯誤，它可以觸發對管理員的警報，因為這是一個更深層次或更微妙的安全問題。
這使自動化系統能夠處理大多數問題，並且只冒出非常重要的問題供人類調查。

最低許可權意味著讓自動化儘可能地完成工作。 
 
那麼如何獲得 DevSecOps 平臺呢？需要一個整體且整合良好的解決方案。平臺必須具備： 

  • 具有安全性的應用程式框架 

  • API 服務和安全 
  • 安全的容器構建服務 
  • 應用服務 
  • L7 應用網路和安全 
  • Kubernetes 策略和生命週期管理，直至作業系統 




 

相關文章