Serverless 架构的安全性如何保障？
Serverless 架构将服务器运维交给了云厂商，但安全责任并没有随之转移。开发者需要在自己的可控范围内做好每一层防护。
身份认证与授权
Serverless 应用中，函数是基本执行单元，每个函数都可能成为攻击入口。身份认证和授权是第一道防线。
函数访问控制： 使用 IAM 角色和策略限制每个函数的权限范围。避免多个函数共享同一个 IAM 角色，为不同功能的函数分配独立的角色和策略，做到权限精准匹配。
API 网关认证： 在 API 网关层集成认证机制，如 AWS Cognito、OAuth2、JWT 验证等。不要让函数直接暴露在公网，所有外部请求都应经过网关的认证和校验。
最小权限原则： 只为函数分配执行任务所需的最低权限。研究表明，超过 90% 的 Serverless 函数被赋予了过高的权限。权限过大意味着一旦函数被攻破，攻击者能访问的资源也更多。
数据安全
Serverless 应用通常会对接多种数据存储服务（数据库、对象存储、消息队列），数据安全需要在传输和存储两个环节同时保障。
传输加密： 所有服务间通信必须使用 HTTPS/TLS 加密。这包括函数与数据库的连接、函数与第三方 API 的交互，以及 API 网关到客户端的通信。
存储加密： 对数据库（如 DynamoDB、RDS）和对象存储（如 S3）启用静态加密。主流云厂商都提供了默认加密选项，开启成本极低但安全收益显著。
密钥管理： 使用 AWS KMS、Azure Key Vault 等专业的密钥管理服务，不要将密钥硬编码在代码或环境变量中。通过密钥管理服务可以实现密钥的轮换、审计和访问控制。
敏感数据处理： 避免在日志中记录敏感信息（如用户身份标识、令牌、个人数据）。Serverless 应用的日志通常集中存储在云日志服务中，访问范围可能超出预期。
网络安全
虽然 Serverless 函数由云厂商管理运行环境，但网络层的配置仍然由开发者控制。
VPC 配置： 将需要访问内部资源的函数部署在私有子网中，通过 NAT 网关访问外部服务。这样可以避免函数直接暴露在公网，减少攻击面。
安全组规则： 为函数所在的安全组配置严格的入站和出站规则。默认拒绝所有流量，只开放必要的端口和目标地址。
VPC 端点： 使用 VPC 端点（如 AWS PrivateLink）访问云服务，流量不需要经过公网。这既提高了安全性，也降低了延迟。
代码安全
代码层面的安全问题是 Serverless 应用最常见的风险来源，传统的注入攻击在 Serverless 环境中依然存在。
依赖扫描： 定期扫描第三方依赖的已知漏洞。Serverless 应用的依赖链通常较长，一个间接依赖的漏洞就可能危及整个应用。可以使用 Snyk、OWASP Dependency-Check 等工具进行自动化扫描。
代码审计： 进行静态代码分析（SAST）和动态应用安全测试（DAST），重点关注输入验证、SQL 注入、命令注入和 XSS 等常见漏洞。Serverless 应用的输入源不止 HTTP 请求，还包括消息队列事件、存储变更事件、定时触发器等，所有入口都需要校验。
环境变量与密钥管理： 使用 Secrets Manager 或 Parameter Store 管理敏感配置，而不是直接写在环境变量中。环境变量在运行时可以被函数代码完整读取，一旦代码存在漏洞就可能泄露。
运行时安全
运行时安全关注的是函数执行过程中的隔离、资源控制和异常处理。
函数隔离： 云厂商在基础设施层面提供了函数间的隔离，但开发者也需要注意应用层面的隔离。不同敏感级别的函数不应共享状态或资源，避免低权限函数成为攻击高权限函数的跳板。
资源限制： 为每个函数设置合理的内存和超时限制。过长的超时时间可能被攻击者利用执行耗时操作，过高的内存分配则会增加资损风险（Serverless 按资源消耗计费，异常流量可能导致高额账单）。
异常处理： 妥善处理所有异常，避免将内部错误信息（如堆栈跟踪、数据库连接串）返回给调用方。异常信息泄露是攻击者收集系统信息的重要途径。
安全责任共担
Serverless 的安全责任是共担的：云厂商负责底层基础设施（计算、网络、操作系统）的安全，开发者负责应用代码、数据、配置和访问控制的安全。理解这个边界，是做好 Serverless 安全防护的前提。
面试中回答这个问题，应从上述五个层面展开，并结合实际项目说明如何落地这些安全措施，而不是停留在罗列要点的层面。