無伺服器環境正日益受到歡迎，這類環境經常主打一些方便企業營運與拓展業務的功能特色，例如：內建擴充性、跨地區服務、成本管理容易等等。幾乎每家主要雲端服務供應商 (CSP) 都提供了某種型態的無伺服器服務，而目前最受歡迎的兩大服務是 Amazon Web Services (AWS) Lambda 和 Azure Functions。
我們可以將無伺服器應用程式想像成在雲端基礎架構內執行的一段程式碼。這段程式碼可透過多種不同方式來觸發執行，例如經由一個 HTTP API 端點或事件。從資安的角度，我們可以將被執行的程式碼本身的安全性與其執行環境的安全性分開來看。雖然 CSP 沒辦法掌控被執行的程式碼，因為那是由使用者所負責，但 CSP 卻能掌控程式碼的執行環境。
我們先前就曾撰文探討過風險管理不當可能帶來什麼危險，而同樣的風險也適用於 CSP 和他們所提供的服務。以下我們將介紹一種許多開發人員在移轉到雲端環境之後常犯的資安錯誤。
環境變數
根據我們的研究發現，環境變數其實隱藏了許多重大資安風險。環境變數經常被用來儲存某些服務的預先授權金鑰，而這些服務又可能與程式碼的執行環境 (也就是無伺服器功能) 連結。我們觀察到一種反差很大的現象，比方說，Azure 服務花費了很多功夫在保護機密，將機密以加密形式儲存並透過安全通道傳輸。但這些機密最後卻以明碼方式儲存在執行環境的環境變數內。這些機密一旦外洩，就有可能讓駭客有機會入侵並執行任意程式碼 (視雲端架構而定)。或者，如果這些機密用於多個應用程式，有可能導致企業機密資訊或儲存的資料外流。
就資安角度而言，這樣的做法完全是個錯誤。環境變數是執行環境中的每個處理程序都看得到的資料，換句話說，執行環境中的每個處理程序都能拿到這些以明碼方式儲存的資料，即使它用不到。對開發人員來說，此一架構上的缺陷既是一個方便的捷徑，也是一項被接受的風險。但對資安人員來說，這絕對是一種非常危險的作法，而且會造成某些資安後果以及潛在的威脅情境。
環境變數的風險
以下說明一個可用於 Azure Functions 環境內的攻擊情境，這項攻擊一旦成功，駭客就能從遠端執行程式碼 (RCE) 或者洩漏、覆寫無伺服器功能的程式碼。
請注意，此攻擊情境的前提是：已部署的功能或環境必須存在著某種漏洞，駭客才能透過環境變數將資訊外洩。但我們經常會看到一些新發現的漏洞，還有一些使用者忘記該如何「正確」使用無伺服器環境變數的情況。
在各種環境變數遭到濫用的案例中，AzureWebJobsStorage 是Azure 環境當中一個可能導致資料外洩的環境變數。這個變數含有一個連線字串，可在功能程式碼實際部署位置授權使用者 AzureStorage 的操作權限，例如：移動、刪除、上傳等一般檔案操作。 這個連線字串若再配合 Microsoft Azure Storage Explorer 就能操控外洩的儲存帳號。
當使用者連上之後，就能刪除某個無伺服器功能或上傳新的版本。
影片 1：概念驗證：儲存成環境變數的機密如何遭到外洩。
那麼，正確的做法為何？我們強烈建議開發人員與開發團隊避免在其部署的應用程式中使用環境變數來儲存機密。
一個常見的反駁論點是，機密在某個時間點同樣還是要在記憶體內解開變成明碼才能使用。這話固然沒錯，但訣竅就在於要盡可能縮短這段時間，而且當我們已經用不到這些機密時，就要盡快將其記憶體內容抹除乾淨，以防止記憶體內容遭到外洩。我們在許多作業系統中都可以看到類似的作法，既然這樣，那為何 DevOps 不能採取同樣的作法呢？
此外還有一點很重要的是，如果透過金鑰保險箱綁定的方式來取得某個無伺服器功能的連線字串，該字串還是會被解開到環境變數當中。
我們或許需應該從架構的角度來改變取得機密或授權的方式，例如將資安強化就不需要用到機密，或者採用一種截然不同的架構。比方說，採用不同的方法儲存原始程式碼，讓無伺服器容器只擁有讀取權限。
另一個「架構上」的問題是，我們是否真的需要這些機敏資訊？還是它們只是繼承自我們程式的執行環境？如果我們真的需要這些資訊，那我們至少可以採取角色導向存取控管 (RBAC) 機制來關閉某些應用程式用不到的動作，例如刪除、上傳等等。
風險管理與有待探索的領域
上述風險可透過停用儲存帳號設定中的金鑰存取權限來加以防範。但這可能會影響到 Azure Visual Studio Code 擴充元件這類開發人員工具，使得開發人員無法上傳新的無伺服器功能。另一種建議的作法是使用虛擬網路來管制儲存帳號的網路存取，但這麼做的缺點是可能為使用者帶來額外成本。畢竟，我們不可能有一種完美的防禦機制來防止駭客經由漏洞來執行程式碼，但我們可以防止駭客因為一些簡單的機密外洩而從遠端執行程式碼或發動攻擊。
除此之外，我們還可以採取下列步驟來降低上述威脅情境的風險：
- 考慮採用 Azure 說明文件中的資安建議。
- 在團隊內部定期舉辦程式碼同儕審查，包括資安團隊在內。
- 強化無伺服器功能 API 的安全性，避免將整個 API 公開暴露在網路上。
- 管制可呼叫無伺服器功能的公開存取帳號，以及虛擬網路內部使用者的存取權限。
- 可能的話，避免使用環境變數來儲存機密和其他敏感資訊，改用更安全的方式和工具 (如保險箱) 來儲存機密。管制存取權限，只開放給特定人員使用，並採用安全的傳輸方式。
- 妥善保護無伺服器功能內部的通訊環境。
原文出處：Analyzing the Risks of Using Environment Variables for Serverless Management