Serverless 供应链最小权限实战

我见过不少 Serverless 函数，代码其实写得不差，问题却出在权限上：一个本来只该处理对象通知的函数，顺手拿到了读取更多数据、写入更多资源，甚至调用无关服务的能力。平时感觉“省事”，一旦事件入口或依赖出了问题，这种方便就会变成放大器。

Serverless 的麻烦在于，函数常常不只接 HTTP 请求。消息、对象存储、邮件或其他云服务事件，都可能把内容送进同一段业务逻辑。只要其中一个入口校验宽松，攻击者就可能借由文件名、对象路径或消息字段，把不可信数据推进后续流程。此时，函数拥有什么权限，决定了风险能走多远。

权限要按动作拆，不要按项目打包

我更倾向于把每个函数当成一张独立的“授权清单”。它需要读什么资源、写什么资源、允许调用谁，都应当能说清楚。只读的处理函数，不该同时拥有删除和写入权限；只消费消息的函数，也没理由默认访问全部数据存储。

尤其要留意输入会影响资源标识的地方。若对象路径、文件名或消息字段能够决定函数访问哪个资源，权限范围就必须更窄，同时先做来源、类型和结构校验。否则，代码里看似正常的一次读取，可能被恶意输入带去不该碰的位置。

部署身份、构建身份和运行身份也别混成一个。构建链路能接触依赖和产物，运行身份能接触业务资源；把两者分开，至少能避免一次构建侧失陷直接延伸到生产数据。

最小权限不是一次配置

权限收紧后，我会顺着函数真实执行路径再检查一遍：它加载了哪些依赖，是否会发起外部请求，异常信息会不会把敏感数据写进日志，跨函数调用是否真的只允许必要动作。发现一项多余授权，就删一项，而不是等“以后可能用到”。

供应链防护当然离不开依赖、构建产物和镜像检查，但最小权限提供的是最后一道刹车。输入被绕过、组件被污染时，函数依然可能失陷；可它拿不到多余资源，能造成的影响就会被压在更小的范围里。这种克制，往往比给函数塞进一大堆权限更让人睡得着。