從一開始，像AWS這樣的公共云環境代表它們的用戶減輕了安全負擔?；镜墓蚕碡熑文Ｐ腿匀挥行?– 明確表示云提供商(即供應商)可以保護云本身的硬件和軟件，而客戶則負責其云中資產的安全性。當然，任何新型云計算的引入都會對模型的細節產生影響，使安全和運營團隊難以理解他們在這些不斷變化的環境中的新職責。

工作負載，特別是云計算工作負載，是為擁有、借用和開源代碼提供動力的應用程序工具。有許多不同類型的工作負載，隨著數據中心的不斷發展，多年來出現了新的選擇。這些工作負載帶來的好處通常伴隨著新的安全和后勤挑戰。正如我們所看到的從裸機到虛擬機(VM)的演變，然后是微服務和容器的引入，組織需要主動解決這些動態環境，以便在它們受到威脅之前有效保護這些動態環境。

這是我們在新的云原生環境出現時親眼看到的問題。每個都為處理它們的企業帶來了新的安全挑戰和復雜性。 這就是為什么您需要密切監控云中新架構的安全性，如無服務器，以及開發人員，操作人員和安全團隊可以保持警惕的三種方式 – 無論您的組織如何與云提供商分擔安全責任。

無服務器示例

無服務器或功能即服務(FaaS)是構建，架構和開發云原生應用程序的最新方式。開發團隊將應用程序代碼作為一組功能提供，而云提供程序負責運行這些功能。這允許開發人員專注于編碼，而提供商負責配置，擴展和計費。

過去一年中無服務器計算的采用呈指數級增長。云計算本地計算基金會(CNCF)是一個包括許多世界上最大的公共云和企業軟件公司以及100多家創新初創公司的組織，最近對550多名社區成員進行了調查，以解決當前的云原生技術問題。該調查發現，受訪者41%目前正在使用無服務器技術，另有28%計劃在未來12-18個月內使用。

這種新的無服務器計算的迅速普及引發了新的問題，即誰擁有使用無服務器框架(客戶或云提供商)部署的應用程序的安全性?正如前面提到的，在傳統的共享安全模型繪制云和一個什么樣的安全保障之間明確的界限在云中，在無服務器模式轉變一些責任推回給云供應商管理，操作系統，讓負責該應用程序的客戶在他們的云環境中運行。

對于DevOps和安全團隊來說，這似乎是個好消息，因為他們可以更專注于構建產品和應用程序而不是安全性，知道它正在被處理。但是，使用無服務器架構意味著組織有新的盲點，僅僅因為他們不再能夠訪問架構的操作系統，從而阻止他們在這些工作負載中添加防火墻，基于主機的入侵防護或工作負載保護工具。

由于無服務器是一種相對較新的架構，組織和云提供商仍在學習如何處理和保護它，而攻擊者仍在學習如何利用它。這就是為什么保護無服務器基礎架構超出共享責任模型概述的重要性。

合作準備整體工作負載安全性

隨著無服務器等新計算方法的出現，適用于傳統工作負載的共享責任模型變得不那么清晰，安全專業人員需要做好準備來保護這些新的工作負載。遵循以下指導可以幫助安全專家準備他們的服務，以安全地在無服務器云中運行。

1.不要相信誰擁有云環境中的安全性?，F代數據中心本質上是復雜的，這導致了固有的盲點，導致數據中心的某些元素缺乏明確的所有權。相信誰擁有安全性可能會在漏洞出現時讓公司陷入困境。在漏洞出現之前定義誰擁有安全性的規則將防止成為受害者并指責手指。

2.確保在復雜的現代數據中心內完全了解所有類型的工作負載。 缺乏對所有類型的不同工作負載的完全可見性使得保護整個云架構成為難以解決的問題。為了避免數據中心各個層面的漏洞，客戶團隊 – 開發人員，安全和運營團隊 – 必須假設他們的云提供商只負責安全措施的最低要求。

3.與您的云提供商合作，從頭開始主動為架構構建安全性。安全性是云提供商與其客戶之間的共同任務。發現攻擊或漏洞后，不要追溯修補或實施安全措施，而是從一開始就與云提供商合作以防止攻擊。如果存在攻擊從高級別利用云提供程序，啟動影響整個堆棧的攻擊，這一點尤為重要。

即使無服務器仍處于相對初期階段，它仍然存在。隨著新舊工作負載的出現和融合，在出現不可預測的漏洞之前，了解角色和職責并從粒度級別添加安全控制非常重要。如果沒有確保所有類型的體系結構(VM，容器和/或無服務器)的安全性，現代數據中心將無法有效運行。傳統的共享責任模型正在不斷發展，組織需要通過了解其重新定義的云安全責任來保持同步，否則它們將不可避免地落后。