Serverless把运行环境的管理交给了云服务商，企业只负责函数代码和配置。这消除了补丁管理和主机加固的部分压力，但把风险集中到了两个地方：函数的输入来源和函数的权限范围。理解这两点，就掌握了Serverless安全的主要脉络。
Serverless函数通常由事件触发，事件来源可能包括对象存储、消息队列、数据库变更和接口网关。如果函数对事件内容的信任程度过高，攻击者就可能通过构造特定事件内容实现注入。典型情形包括：把事件中的字段直接拼接到数据库查询语句中；把事件内容作为文件路径使用导致目录穿越；把事件内容反序列化为对象导致代码执行。防护上应把事件输入视为不可信数据，做严格校验和类型转换，避免直接拼接。
函数执行时会承担绑定的角色权限。常见问题是角色权限远超函数所需，例如一个只读取配置的函数被授予了对存储桶的写入和删除权限。一旦该函数被利用，攻击者就可以借助它的身份操作云资源。防护做法是逐函数定义最小权限角色，把权限收窄到具体的资源与动作，避免使用通配符。
函数依赖的第三方库同样纳入供应链风险管理范围，需要定期扫描与更新。配置方面要关注环境变量中的敏感信息，应通过密钥服务注入而不是写死在配置里；同时限制函数的公网访问方式，避免未授权调用。
Serverless的调用粒度细、实例生命周期短，日志采集容易被忽略。建议为函数启用结构化日志并集中收集，记录调用来源、输入摘要和执行结果，便于异常排查。同时对执行时长突增、错误率上升、异常出网等行为建立告警。
Serverless的安全责任边界发生了变化，但核心问题依然是输入信任和权限控制。把这两件基础工作做扎实，就能覆盖大部分风险。
售后客服
企业微信
