何謂無伺服器的資安防護?

無伺服器的資安保障需要組織如何看待應用程式安全性的典範轉移。組織必須圍繞第三方雲端提供者託管的應用程式內的功能額外建立安全性,而不是使用次世代防火牆圍繞應用程式本身建立安全性。這額外的安全層可確保適當的應用程式強化和最小權限存取控制,因此每個功能的功能不會多於或少於其設計目的,幫助組織改善其安全狀況並保持合規性。

安排演示 無伺服器的資安保障解決方案

何謂無伺服器的資安防護?

什麼是無伺服器運算?

無伺服器運算是指由雲端供應商運行伺服器並動態管理機器資源分配的雲端運算模型。AWS Lambda Functions 、Google Cloud Functions 和Azure Functions是建置應用程式的熱門無伺服器框架。

 

無伺服器架構提供自動化、幾乎無限的擴充功能。 開發人員和部署的程式碼之間的距離很少,這可加快上市時間,並使個別功能的維護和測試更容易。 最後,消耗的應用程式資源的實際數量會影響定價,這意味著您只需為使用的資源付費,從而降低成本。

 

無伺服器代表了責任從客戶到雲端提供者的額外轉移。由於沒有涉及基礎架構,營運開銷會顯著降低。

 

將基礎架構管理轉移給您的雲端供應商使您能夠專注於開發解決方案來為您的組織和客戶提供服務。它可以幫助您保持專注於獨特的競爭優勢,並通常不僅在運算方面節省成本,還可以從人員轉移到開發。

無伺服器如何改善安全性?

以下是一些關鍵點:

 

  1. 雲端提供者負責作業系統、執行時間安全性和修補。在部署無伺服器應用程式時,您將對大部分堆疊的控制權交給雲端供應商,他們提供金鑰管理等服務。您不再擁有作業系統強化、管理權限、SSH 和分段。AWS微軟谷歌在保持其堆疊部分的修補程式和安全性方面是可靠的,因此給他們更大的堆疊部分肯定會改善這方面的情況。
  2. 無國家/短暫。此外,無伺服器運算的短暫且無狀態性質使攻擊者的生活變得更加困難。 像 AWS Lambda 這樣的無伺服器函數會運行幾秒鐘,然後就會終止。容器會被回收。 無伺服器功能隨時隨地出現,沒有記憶體,降低了長期攻擊的風險。
  3. 無伺服器應用程式的可見性 – 好處。無伺服器應用程式被建構為雲端中的大量小功能,這一事實為安全性提供了絕佳的機會。應用程式安全工具通常會花費令人難以置信的時間來分析和檢測您的打包應用程序,只是為了能夠觀察或過濾應用程式的內部流程。
  4. 更小的微服務 = 能夠為每個功能建立合適的、最少的角色。遷移到更小的微服務使您能夠執行更細粒度的 IAM。您有機會將安全政策套用到這些小事情,這可以顯著減少您的攻擊表面。

 

只要容器中的任何函數都需要訪問權限才能從 S3 讀取,該容器中的所有函數也將具有該權限。 借助 AWS Lambda,您有機會將權限套用至各個函數,並確保此類權限僅限於必要的最小範圍。如果您的某個功能存在脆弱性,則攻擊者只能存取該功能的有限功能,而無法存取授予容器的大量權限。

無伺服器保障的資安挑戰是什麼?

隨著無伺服器應用程式結構的變化,出現了一些新的挑戰。

 

  1. 安全可見性變得更加困難。 隨著無伺服器,資訊總量和資源數量會增加。 這會阻礙您了解所有數據的能力。 每天記錄中有十億個事件,從大量資料中獲取智慧,以實現真正的可觀察性是一件挑戰性。
  2. 通訊協定、向量和攻擊點已加倍至每個函數,而協議 = 潛在的攻擊點。 這需要針對 Google Functions、Azure Functions 和 AWS Lambda 安全性採取獨特的方法。
  3. 更多資源 = 更多管理權限。 更多資源等於更多的管理權限,在確定所有這些互動的權限時產生挑戰。 自動化技術可偵測組態風險,並自動產生最低權限的功能權限。
  4. 無伺服器應用程式中的可觀察性 — 挑戰。 無伺服器應用程式使用來自不同雲端供應商、跨多個版本和區域的不同服務。若要瞭解您的攻擊表面和潛在風險,您需要全面檢視整個無伺服器生態系統。 隨著您的應用程序的傳播,這個以安全為重點的檢視構建和維護可能會越來越具挑戰性。

在哪裡部署保障無伺服器的資安?

對於無伺服器應用程序,沒有地方可以放置 WAF、防火牆和 IDS 等傳統安全性。由於幾個原因,在攻擊者和資源之間建立牆並不簡單。

 

  1. 雖然更快、更頻繁的部署可能非常積極,但無伺服器的速度可能會為安全配置帶來新的挑戰。
  2. 安全工具可以增加處理時間,您必須將其乘以所有請求。 幸運的是,大多數保障伺服器的資安最佳實務不需要任何額外的處理時間。
  3. 周圍的侵蝕。 傳統應用程式有明確的邊界。外部和內部都不同,我們可以在周圍做安全 雖然安全保留在周邊並不理想,但仍然可以建造一個牆壁。

 

無伺服器應用程式更加多孔和細粒度。無伺服器應用程式由數十或數百個功能組成,是微型微服務,具有自己的策略、角色、應用程式開發介面、審計追蹤等。這改變了攻擊表面,而不是少量存在每個點背後隱藏了許多功能的入口點,現在有更多的入口點,每個點都在其後面都有一小部分應用程序。 現在保護您的應用程式需要考慮每個入口點。

 

各種事件可以觸發功能,例如:

  • 雲端儲存事件(例如AWS S3、Azure Blob 儲存、Google 雲端儲存)
  • 串流資料處理 (例如 AWS 運動)
  • 資料庫變更 (例如 AWS DynamoDB、Azure CosmosDB)
  • 程式碼修改 (例如 AWS CodeCommit)
  • 通知(例如短信,電子郵件,物聯網)

什麼是無伺服器的資安威脅?

雖然攻擊者的動機保持不變,但他們在無伺服器應用程式中使用的策略必須改變。以下是這種新應用程式架構特有的一些無伺服器資源保障威脅。

1. 超權功能的威脅

借助無伺服器應用程序,您有機會將權限應用於各個功能,並確保此類權限僅限於必要的最小範圍。這可讓您大幅減少攻擊表面,並減輕任何攻擊的影響。

 

不幸的是,Check Point 最近的研究發現,絕大多數開發人員都沒有利用這個機會。我們的研究發現,無伺服器應用程式中 98% 的功能都面臨風險,其中 16% 被認為「嚴重」。此外,大多數這些功能都提供了比其所需更多的權限,可以刪除這些權限以提高功能和應用程式的安全性。

 

在分析功能時,Check Point 會為每個功能分配風險評分。這是基於發現的姿勢弱點,以及不僅影響弱點的性質,還有它發生的背景的因素。 在掃描了即時應用程式中的數萬個功能後,我們發現大多數無伺服器應用程式的部署根本沒有達到最大限度地降低風險所需的安全性。Check Point 發現的最大安全狀況問題是不必要的權限,而其餘問題則與易受攻擊的程式碼和配置有關。

二.土豬日攻擊

事實上,無伺服器功能是短暫且短暫的,這使得攻擊者更難長期駐留在您的應用程式中。此外,這也是無伺服器的許多安全優勢之一。 但是,只是因為這使攻擊者的生活變得更加困難,並不意味著他們將阻止攻擊;他們只是改變策略。

 

無伺服器功能的持續時間短意味著無伺服器的資安保障威脅可能會發生變化。攻擊者可能會建立更短的攻擊,例如竊取一些信用卡號碼。 這個單回合的攻擊不斷重複,我們稱為「Groundheg Day」攻擊。

三.中毒井

儘管雲端原生資源的生命週期很短,但攻擊者仍然可以找到方法在您的應用程式中獲得長期持久性。攻擊者規避無伺服器應用程式短暫性的一種方法是透過上游攻擊,或「毒井」。

 

雲端原生應用程式往往包含許多模組和函式庫,其中的程式碼來自各種第三方來源。攻擊者會在一般專案中包含惡意程式碼。 然後,在井中毒後,雲端應用程式中的惡意程式碼可以打電話回家,獲取指令並造成嚴重破壞。

4. 增加無伺服器的資安設定時間

雖然這並不完全是安全性「威脅」,但它更是一個挑戰,也是對您在保護無伺服器架構的努力的努力上的困擾。

 

無伺服器帶來了提高應用程式開發速度的好處。不幸的是,傳統的安全性方法(開發人員編寫程式碼和套件工作負載,然後安全操作將安全控制放在這些工作負載周圍),對於無伺服器來說將無效。

 

如果開發人員必須等待安全性才能為他們開啟連接埠、IAM 角色或安全群組,速度提高的好處會迅速消失。 通常,解決方案是從方程中刪除 SecOps,這確實可能是一種風險。

 

另一方面,為無數無服務器資源配置權限和它們之間的互動是一項耗時的任務。 此外,開發人員在安全配置上「花費」的時間可能會很快變得昂貴,並且不是理想使用他們的時間。 利用自動化(例如CloudGuard Platform) ,可以增加無伺服器的資安保障,而無需投入過多的開發人員時間。

5.增加安全處理時間

無伺服器的另一個好處是,您只需按實際消費的費用付費,這可能會降低成本。 儘管如此,準確支付您使用的費用意味著任何加長處理時間都會增加成本。

 

在應用程序中放置過多的 app sec 配置可能會為您的功能增加額外的工作,從而增加成本。 雖然為了安全起見,增加處理時間是一項明智的投資,但它需要適當的實施以避免過度、不必要的成本增加。

 

與上述無伺服器的資安保障配置時間增加類似,這並不完全是威脅,而是您在保護無伺服器架構時必須應對的挑戰。

×
  反映意見
由於 Cookie 有其功能且可供我們用於資料分析和行銷等相關業務,本網站是有使用 Cookie 的。繼續瀏覽本網站即表示您同意我們使用 Cookie。若欲了解更多相關資訊,請參閱我們的 Cookie 聲明