severless計算的出現使應用的安全責任發生了一次洗牌
severless計算的出現使應用的安全責任發生了一次洗牌，將很多責任從云服務的使用者身上轉移給了云供應商。除此之外，serverless計算還必須解決應用程序分離和多租戶資源共享本身的風險。
隨機化調度和物理隔離： 物理共存是在云平臺內部引發 hardware-level side-channel 和 Rowhammer 攻擊的主要原因。此類攻擊的第一步往往是尋找和攻擊目標位于同一物理宿主機的租戶作為侵入對象，而cloud functions的生命周期往往較短，且調度存在隨機性，這會使攻擊者難以找到和攻擊目標共存的侵入對象。使用一種隨機化的、能感知入侵的調度算法將會大大降低此類攻擊發生的可能性，不過這樣產生的物理隔離又可能會導致啟動時間增加、資源利用率降低以及低效通信等問題。
細粒度的安全上下文： cloud functions需要細粒度的配置，包括私鑰、儲存對象甚至是本地臨時資源的訪問權限。這要求我們轉變現有serverful應用的安全策略，并且為cloud functions提供能夠動態調用的安全API。舉個例子，某個cloud function可能需要給其他的cloud function或云服務提供安全授權，而基于密碼學的能力控制模型 (A capability-based access control mechanism using cryptographically)就能很好的適用于這樣的分布式系統(近期也有一些研究使用信息流作為跨函數訪問的控制方法)。如果為cloud function動態創建短期的密鑰和認證，則會進一步加大提供分布式安全控制所帶來的挑戰，比如非模糊性 (non-equivocation) 和認證吊銷問題。
在系統層面上，用戶需要為cloud function提供的更加細粒度的安全隔離措施，至少作為一個可選的選項。提供函數級沙箱的要面臨的挑戰是在不緩存執行環境的條件下，仍然要保證足夠短的啟動時間。一種可能性是使用本地快照，這樣每個函數都可以從一個足夠干凈的狀態啟動。或者，目前輕量級的虛擬化技術也正在逐漸被serverless供應商所采用，比如包括gVisor在內的library OS，通過用戶態的“墊片層 (shim layer)”來提供系統API；以及像AWS Firecracker這樣的unikernel和microVM，簡化訪客內核并幫助縮小可能的攻擊面。這些隔離技術可以把啟動時間降低到幾十毫秒，比起VM秒級的啟動速度要快得多。至于這些方案是否能夠達到和傳統VM技術相同的安全性還需要時間來檢驗，我們也希望構建低啟動延時的隔離環境能夠成為一個持續發展的研究和開發課題。至少從積極的一面看，serverless計算中由供應商提供的管理機制和短生命周期的實例會讓漏洞的修補變得更加迅速。
對于那些想要防御同駐攻擊 (co-residency attack) 的用戶而言，要求物理隔離可能是一個不錯的解決方案，因為近來的硬件攻擊（如 Spectre 和 Meltdown）幾乎可以使整個核心或是整臺物理機器癱瘓。云供應商可以為客戶提供一些高級選項，允許他們在專用的物理主機上啟動函數服務。
serverless計算的隱患： cloud function有可能會在通信期間泄露訪問模式和計時信息。對于serverful的應用而言，數據通常以批量方式檢索并緩存在本地。相對的，由于cloud functions生命周期短暫，并且廣泛分布在云端，因此它的網絡傳輸模式有可能會向網絡攻擊者（比如內部雇員）泄露更多的敏感信息（即便運輸載體已經被加密了），而將serverless應用拆分成諸多更小函數的趨勢則進一步加劇了這種風險。盡管最大的安全隱患往往來自外部的攻擊者，但針對內部人員也應當采取一定的防范措施，不幸的是，這些措施往往有很高的成本。