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应用拆分成诸多更小函数的趋势则进一步加剧了这种风险。尽管最大的安全隐患往往来自外部的攻击者，但针对内部人员也应当采取一定的防范措施，不幸的是，这些措施往往有很高的成本。