无服务器架构安全责任如何划分

本文目录导读：

1. 核心原则：责任的“向上”与“向下”移动
2. 详细责任划分边界
3. 容易忽视的“灰色地带”和盲点
4. 总结对照表
5. 给开发运维团队的建议

无服务器架构（Serverless）的核心特点是“开发者无需管理服务器”，但这并不意味着安全责任完全由云厂商承担，无服务器架构遵循共享责任模型（Shared Responsibility Model）,只是责任的边界发生了显著变化。

以下是关于无服务器架构安全责任划分的详细分析,以及一些容易被忽视的盲点。

核心原则：责任的“向上”与“向下”移动

与传统云架构（如IaaS或PaaS）相比,无服务器架构中：

1. 云厂商的责任增加了： 它们负责底层基础设施（物理机、虚拟机、网络）以及运行时环境（如AWS Lambda的执行环境、操作系统的补丁、底层容器的隔离）。
2. 用户的责任也改变了（并未消失）： 用户不再需要管理OS补丁和防火墙，但需要负责代码安全、配置安全、数据安全、身份与访问管理（IAM）以及业务逻辑安全。

详细责任划分边界

可以按“云厂商负责”和“用户负责”两个维度来拆解：

云厂商（如AWS、Azure、GCP）负责的部分

1. 物理基础设施安全： 数据中心、网络、电力、散热、物理访问控制。
2. 虚拟化/容器层安全： 确保不同客户的函数执行环境是隔离的（沙箱机制）,防止侧信道攻击。
3. 运行时环境的安全： 负责底层操作系统（Amazon Linux、Ubuntu等）的补丁和加固，包括内核、系统库等。
4. 核心服务API的安全： 保证其提供的API Gateway、函数计算服务、对象存储等核心服务的API本身不存在高危漏洞。
5. 函数生命周期管理： 确保函数冷启动时的安全初始化、热实例的回收和清理（如/tmp目录的清理）。

用户（开发/运维团队）负责的部分

这是容易被忽视或误判的部分,具体包括：

1. 代码安全（第一位）： 函数的代码本身是否存在漏洞（SQL注入、命令注入、不安全的反序列化等）,无服务器代码暴露的攻击面更大。
2. 依赖项安全： 函数引用的第三方库（如npm、PyPI、Maven包）是否存在已知漏洞（CVE），与传统环境不同,这些依赖会直接打包进部署包。
3. 身份与访问管理（IAM）： 这是最核心、最易出错的安全边界。
   • 函数执行角色（Execution Role）： 函数在运行时能调用哪些云资源（如读写S3、写入DynamoDB）。原则：最小权限。 如果权限过大（如给了一个AdministratorAccess的角色）,攻击者通过一个SSRF漏洞就能拿下整个账户。
   • 调用方权限： 谁（用户、其他函数、API网关）可以调用这个函数,需要设置细粒度的资源策略。
4. 配置安全（Misconfiguration）：
   • API Gateway： 是否启用了认证？CORS（跨域资源共享）配置是否过于宽松？是否开启了公网访问？
   • 环境变量： 数据库密码、API密钥是否明文硬编码在环境变量中？虽然环境变量本身是加密的，但函数内代码可以读取。建议使用KMS加密或Secrets Manager动态获取。
   • 事件源绑定： S3桶的事件通知是否自动触发一个处理函数？如果S3桶是公开写权限，任何人都可以往桶里放文件，从而导致函数被恶意触发（恶意文件上传、拒绝服务）。
5. 数据安全（Data Security）：
   • 函数处理的数据（如用户上传的文件、数据库记录）在传输中（TLS/SSL）和静态存储（加密）是否被保护？
   • 函数内部数据处理： 是否在日志中不小心打印了敏感信息（如信用卡号、密码）？日志（CloudWatch等）本身是否被正确保护？
6. 业务逻辑与输入验证：
   • 事件源注入： 攻击者可以通过修改事件（如API Gateway请求体、DynamoDB Streams记录）来操纵函数逻辑。
   • 功能滥用： 一个生成图像缩略图的函数，如果没有限制输入文件大小，攻击者可以传入巨大图片，导致函数执行超时或消耗巨额费用（资源耗尽攻击或成本攻击）。
7. 日志与监控： 函数是否开启了全面的日志记录？是否有告警机制检测异常行为（如大量未授权调用、异常的错误率）？

容易忽视的“灰色地带”和盲点

1. 共享库 vs. 自定义运行时： 如果用户使用自定义运行时（Custom Runtime），例如自己打包了一个Debian镜像或自定义语言环境，那么操作系统补丁的责任就部分回到了用户身上,云厂商只保证基础沙箱的安全。
2. 依赖下沉（Function Shredding）： 无服务器函数通常很短命，但如果函数内使用了持久化连接（如数据库连接池）或缓存（如内存中的变量、/tmp目录），这些状态在不同调用之间是共享的，攻击者如果控制了实例，可能窃取这些共享数据，用户需要确保/tmp目录不存储敏感数据,且连接池安全。
3. 第三方服务集成： 函数可能会调用第三方API（如Stripe、Twilio、或用户自建的后端），这些第三方服务的认证凭据（API Token）存储在环境变量中。如果凭据泄露，攻击者可以直接以函数的身份访问第三方。 用户需负责管理这些凭据。
4. 供应链安全（Software Supply Chain）： 部署函数时，会打包所有依赖，如果一个上游包被恶意篡改（如node_modules中的包被注入后门），用户发布的代码就天然带毒。用户需负责对依赖进行扫描和校验（如使用SBOM、Snyk、WhiteSource等工具）。
5. 冷启动安全： 虽然云厂商会隔离实例，但用户需要保证函数在冷启动时的初始化代码（如连接数据库、加载密钥）是安全的，不要在初始化阶段加载所有权限的密钥,而是按需加载。

总结对照表

给开发运维团队的建议

1. 零信任架构： 哪怕函数是“同一个账户下的”，也要假设函数之间的调用是“不安全的”,每个函数只能拥有完成其功能所需的最小权限。
2. 强制使用IAM角色，而非长期密钥： 绝不要在函数代码或配置文件里写死Access Key/Secret Key,只使用IAM执行角色。
3. 实施输入验证与净化（Input Validation & Sanitization）： 对来自API Gateway、数据库、S3事件的所有输入,在函数内部进行严格的校验和逃逸处理。
4. 使用Secret Management服务： 使用AWS Secrets Manager、Azure Key Vault或GCP Secret Manager存储敏感信息,并配置自动轮换。
5. 监控与成本保护： 设置函数并发限制（Reserved Concurrency）、账户预算和异常调用告警,攻击者可能通过大量调用耗尽你的账户额度。
6. 代码与依赖扫描： 在CI/CD流水线中集成安全扫描工具（如Snyk、Checkmarx、AWS CodeGuru Security）,检测高危依赖和代码漏洞。
7. 日志隔离： 不要把函数产生的所有日志都发送到同一个日志组，并做好日志的访问控制（最小化读取权限）。

总结一句话： 在无服务器架构下，云厂商负责“硬件和底层系统的安全”，而你（用户）负责“你写出来的代码、你配置的策略、你引用的依赖以及你对数据的处理安全”。IAM权限配置和依赖供应链安全是用户最容易出问题、后果也最严重的领域。