[[386461]]

【51CTO.com快譯】不可否認，我們在得益于無服務器帶來的效率、可擴展性、以及成本優勢等功能與便利的同時，必須保證無服務器應用的安全性。在本文中，我將向您介紹如何使用AWS Lambda和相關工具，來開發無服務器功能，以及那些行之有效的無服務器安全策略和優秀實踐。

總體而言，無服務器的安全性處置方法可分為兩類：運行時(runtime)安全和靜態(static)安全。

運行時安全

毫不夸張地說，無服務器的相關功能一旦開始運行并被調用，其安全隱患就出現了。特別是涉及到有用戶輸入信息時，暴露的攻擊面會更大。例如：惡意用戶可能通過SQL注入的方式，竊取甚至刪除后臺的數據。同樣，跨站點腳本(XSS)攻擊可以將腳本注入到運行在無服務器的微虛擬機(microVM)上。如此，就算無服務器已執行完了所提供的功能(或是超時了)，microVM仍會spin down，而此時XSS攻擊便可以在無服務器環境中站穩腳跟，通過啟動其他進程來興風作浪。

我們既可以將無服務器的安全保護作為一個功能性層面來運行，也可以將其作為并行的進程來運行。而此類保護既可以驗證用戶輸入的完整性，又能夠監控文件、進程和連接是否存在著任何異常或惡意行為。

不過，在函數每一次被調用時，安全保護都被激活。這往往會增加運行時間，特別是在無服務器的情況下，每次就會增加100ms的運行成本。而且，如果需要加載較大的代碼包，那么此類延遲的增加，就會對整體性能造成較大的負面影響。話雖如此，對于那些金融服務和關鍵性基礎設施的應用而言，由于安全性比性能更為重要，因此運行時安全對于它們的無服務功能來說，是必不可少的。

實際上，無服務器功能已經自帶了不少安全機制。例如：惡意攻擊無法在運行時中更改函數的代碼，畢竟它僅能作為一個實例被執行。同時，無服務器功能通常運行在AWS Lambda等云端服務上，而云服務提供商自身已經提供了免受DDoS攻擊、DNS攻擊、TCP SYN攻擊、以及會話劫持攻擊的能力。因此，用戶只需遵循編程時的各種優秀實踐，并保持每個函數在邏輯上盡量簡單，即可達到運行時安全的效果。畢竟，隨著應用的迭代，代碼量的逐漸增多，功能性超時也會隨之增加。因此，我們需要持續通過運行時安全，來保護無服務器的各項功能。

靜態安全

靜態安全是從執行前的檢查階段，以及執行后的取證分析階段，來保護無服務器的各項功能。

具體而言，執行前的檢查可遵循如下安全檢查列表(其中，前三點是無服務器安全性特有的要求)：

1. 為每項功能分配一個角色，以定義其對于資源的訪問權限。建議做法是：授予必要且最低的訪問權限。

2. 為了避免由于錯誤的配置所導致的安全漏洞，請將所有資源都組織到同一個應用之中。

3. 在訪問規則上，應當設置為：每個資源都需要用單獨的憑據來訪問，并對憑據進行安全管理。

4. 嚴格地限制功能發布、路由更改、以及負載分布的變更等權限。

5. 持續掃描功能庫，并及時修復發現的漏洞。

為了將上述安全措施集成到CI/CD流程中，光靠人工干預顯然是不夠的，我們需要通過安全自動化的規模性能力，來保護各項功能與資源。

第二階段則是通過一系列來自云提供商的工具，在執行后進行取證分析。例如，我們可以使用AWS CloudWatch、AWS X-Ray、AWS Security Hub、AWS GuardDuty、以及最新的Amazon Detective，來監控和分析AWS Lambda無服務器的各項功能。

無服務器功能的開發工具與實踐

由于AWS Lambda具有對Java、Go、PowerShell、Python、Node.js、C#和Ruby的原生支持，因此在以下的示例中，我們將使用Python、Node.js或Ruby語言，通過基于Web的AWS控制臺，來創建一項無服務器功能(如下面的屏幕截圖所示)。值得注意的是，AWS提供的用于編寫函數的文本編輯器，并不適合創建那些會用到多個文件、軟件庫、以及依賴項的大型函數。

當然，您也可以選擇使用AWS的命令行界面(CLI)工具，在本地開發和提交各項功能。您可以參考這里，來進一步了解AWS CLI的安裝和配置。

同時，您可以把在本地開發好的所有源代碼文件，放入一個zip文件，然后上傳到AWS CLI中(如下所示)。

我們需要通過更強大的開發工具，以及專用的開發環境，來開發更為復雜的服務，以及在CI/CD管道中引入可擴展的自動化靜態安全。這里羅列了各種強大的、適合開發人員的AWS工具。此外，Lumigo網站也提供了一些較為實用的工具，具體請參見--https://lumigo.io/blog/comparison-of-lambda-deployment-frameworks/。

無服務器框架(Serverless Framework，SLS)是目前最受歡迎的開發工具，它在GitHub上獲得了超過38,000顆星。AWS無服務器應用程序模型(Serverless Application Model，SAM)則是另一款十分流行的工具。它們都能夠讓開發人員在serverless.yml文件中，構建無服務器項目。此類項目可以被轉換為CloudFormation模板。AWS將它用來創建各種所需的資源。具體而言，SLS和SAM能夠提供：

1. 基礎架構即代碼(Infrastructure-as-code)定義了CloudFormation中的資源，其中包括：無服務器功能、API網關、Amazon S3存儲等。

2. 本地功能性測試。

3. 多階段性的CI/CD管道集成。

4. 完全開源的修改潛力。

此外，SLS還提供了1000多個現有插件的列表。這些插件不但可以極大地改善和簡化無服務器的功能開發，還可以按需被編寫出新的插件。以下代碼段便是一個小型插件的示例：

在開發人員能夠使用SLS，來創建有效的無服務器項目時，無服務器棧(Serverless Stack)為他們提供了寶貴的分步說明。同時，作為一套出色的初學者教程，該資源方便了開發人員獲取有關無服務器開發的工作流，以及如何使用AWS基本組件的經驗。

構建安全的無服務器功能

以下便是我們在開發安全的無服務器應用時，值得遵循的六項優秀實踐與規則：

1. 通過將資源定義與函數區分開來，讓您的代碼庫井然有序。您可以利用不同資源作為參數，而不是經過硬編碼的字符串。同時，您可以通過共享代碼，來盡量減小程序包的大小。

如下兩個示例，演示了良好的代碼庫組織結構。其中，第一個展示了共享庫的多項功能：

第二個例子是由無服務器棧提供的：

2.遵循最小特權原則，將身份和訪問管理(IAM)中的角色限制為單個功能級別上。

3.使用諸如AWS SSM代理之類的服務，來管理好密鑰。

4.單個無服務器功能僅能執行一項任務。如果某個函數的輸出需要進一步處理的話，請將該輸出保存到數據存儲庫中，并由該保存動作來觸發新的函數。記住：不要使用當前函數去調用另一個函數。

5.盡量少用遠程連接。無論多么復雜，函數的大部分都應該在本地處理其輸入，然后返回對應的結果。注意：遠程連接不但會增加延遲，而且可能導致在調試和擴展時出現問題。

6.盡量少用依賴性。最好將它們放置在前文提到的共享層中，并持續執行安全掃描。

這些便是我想在本文中和您討論的，各種無服務安全性的策略、工具和實踐。

原文標題：Examining Serverless Security Strategies, Tools, and (Current) Best Practices，作者: Selvam Thangaraj

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