現在大部分從業人員都很熟悉云計算，由于這種熟悉程度，有時候很難回想起云計算的原始承諾。

云計算的原始承諾是企業可將注意力從不增加價值的事物轉移到增加價值的事物。具體來說，企業原本需要構建基礎設施、維護數據中心以及提供業務所依賴的應用，而云計算可將其重點轉移到構建更好、更無縫和更相關的應用。

然而，僅因為事物在云端并不一定意味著所有維護要求都消失。例如，基礎設施即服務部署仍然需要你進行漏洞修復、布置虛擬網絡路徑、提供基礎安全設備以及完成很多其他任務，正如托管在內部數據中心時你做的那樣。

而無服務器應用的新趨勢有望幫助我們實現云計算的原始夢想。通過無服務器應用，不再有維護基礎設施的工作，讓你可專注于構建更好的應用。你可以想象，這非常令人信服和強大。

也就是說，保護無服務器應用安全相關的具體方法與企業過去可能采用的方法有些不同。這意味著，如果你計劃使用無服務器應用，你可能需要提前思考安全方法并打下堅實基礎。

[[203306]]

無服務器意味著什么?

無服務器并不意味著沒有服務器;事實是這里有服務器，只是用戶或者構建應用的開發人員不需要知道服務器，也不需要了解服務器在做什么、了解它們如何運作或者警惕應用層下可能發生的情況。開發人員可通過定義API進行交互以部署他們所需要的邏輯。擴展、與特定硬件或底層中間件服務接口邏輯等操作都是由環境無縫且透明地處理。

在Google Cloud Functions或Amazon Web Services Lambda等環境中，通過事件觸發功能，而應用功能用以響應這些事件，并實現小規模功能。環境會根據需要配置功能，并根據需求進行擴展。這樣做的優勢是，即使超出大多數云計算使用情況，你只需要支付你使用的部分。

這與常規、非服務器平臺即服務部署有何不同?簡單的回答是，從哲學角度來看它們非常接近。然而，即使在PaaS環境中，與無服務器環境相比，你仍然需要擔心底層部署方面的情況。

例如，你可能需要在很多PaaS情況下專門提供資源，這樣擴展并不是真正隱藏。同樣，PaaS中特定服務的配置(例如數據庫或郵件)可能需要非常了解底層部署。所以，從某種意義上來說，無服務器就像PaaS++。

無服務器應用的安全注意事項

你可能會想到，保護無服務器應用于保護傳統單片應用或其他云部署有所不同。

首先，最重要的是，你與7層網絡以下交互的能力幾乎不存在。這意味著你無法將入侵檢測設備放到虛擬網絡或者在底層操作系統安裝惡意軟件掃描工具。因此，你需要徹底且完整地了解你正在部署的邏輯相關的威脅模型。

同樣，你需要確保開發的代碼是安全的。這可能不是簡單的事情，因為應用安全是很多企業掙扎的領域。

例如，在應用問題方面，注入攻擊仍然排在首位。雖然在某種程度上，漏洞總是會發生，但其實我們保護無服務器應用的能力與我們了解應用邏輯、移除或緩解潛在問題、保持代碼高質量和監控環境的能力直接相關。這并非火箭科學，但確實需要有紀律。

如果你還沒有這樣做，這里有種方法可提供即時價值，那就是威脅建模。威脅建模已經是加強應用的有效工具，而它在無服務器環境中比其他情況下更有價值。它不僅可讓你系統地映射和分析組件之間的交互點，而且還可生成數據流映射作為流程的部分。即使你可能沒有完全了解數據存儲或計算的底層機制，但應用元素如何交互的虛擬映射很有用，不僅僅是對威脅模型的分析。

在執行此操作時，你可能會考慮有哪些可用的選項可隔離應用邏輯，以為你提供更多的可見性或對操作的控制。例如，Vanadium等工具可讓你以對開發人員透明的方式封裝功能。你還可以選擇自行部署包裝策略。這樣的策略可幫助尋找和過濾注入攻擊，而不是假設所有開發人員可提供無注入代碼。

最后，與任何其他事物一樣，監控是必須事項。除了訪問控制決策等，你還要了解應用邏輯本身。你想要發現任何不符合業務規則的異常事件。這將根據特定應用的用途而有所不同。這也是威脅建模可提供價值的領域，因為理想情況下，在創建和記錄威脅建模的時候，你將首先了解應用的設計原理。

無服務器應用是強大的工具，但確保這些工具的安全性并不是安全團隊可完全勝任的工作，因此，最好獲得額外的外部和內部專業技能。

同樣有幫助的做法是培訓內部員工，讓他們了解威脅建模方法、強大的編碼做法以及常見濫用案例、攻擊和威脅模型等。這也是很好的機會來培養人才、建立技能以及提高企業整體應用的復雜性和成熟度。