[[386461]]

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

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

運行時安全

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

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

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

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

靜態(tài)安全

靜態(tài)安全是從執(zhí)行前的檢查階段，以及執(zhí)行后的取證分析階段，來保護無服務(wù)器的各項功能。

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

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

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

3. 在訪問規(guī)則上，應(yīng)當設(shè)置為：每個資源都需要用單獨的憑據(jù)來訪問，并對憑據(jù)進行安全管理。

4. 嚴格地限制功能發(fā)布、路由更改、以及負載分布的變更等權(quán)限。

5. 持續(xù)掃描功能庫，并及時修復(fù)發(fā)現(xiàn)的漏洞。

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

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

無服務(wù)器功能的開發(fā)工具與實踐

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

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

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

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

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

1. 基礎(chǔ)架構(gòu)即代碼(Infrastructure-as-code)定義了CloudFormation中的資源，其中包括：無服務(wù)器功能、API網(wǎng)關(guān)、Amazon S3存儲等。

2. 本地功能性測試。

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

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

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

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

構(gòu)建安全的無服務(wù)器功能

以下便是我們在開發(fā)安全的無服務(wù)器應(yīng)用時，值得遵循的六項優(yōu)秀實踐與規(guī)則：

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

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

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

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

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

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

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

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

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

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

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