5.3 无服务器与微服务安全

5.3 无服务器与微服务安全

本节摘要：架构拆细之后，安全边界跟着碎了。本节讲无服务器与微服务两条新信任模型：函数的短生命周期权限怎么设计、服务间怎么互相认证、东西向流量为什么突然变成主战场，最后给一张新边界下的防御布局图。

拆掉一台服务器之后

传统架构里，安全边界画得很大而清晰：一台服务器一个边界，边界内互信。微服务把这台服务器拆成几十个独立部署的服务，无服务器进一步把"常驻的应用"拆成"按次执行的函数"。安全模型随之翻转：边界从少数几个变成成百上千个，每两个服务之间都可能是"陌生服务"的关系。旧的"内网即可信"假设在新架构里彻底失效——这就是服务网格与零信任在云原生时代兴起的原因。

责任模型也悄悄变化。无服务器模式下，运行时、补丁、容量全归厂商，客户负责的收缩为代码与配置（IAM 权限、触发器、环境变量）。听上去负担变轻，实际是把风险压缩到了更小的面积上——小面积意味着每个配置项都更关键：函数的执行角色过宽，等于给每次调用发一把万能钥匙；环境变量里塞密钥，等于把钥匙贴在透明的信封上。

函数安全：短生命周期的权限设计

无服务器函数的安全要点可以浓缩成三句。第一句：一个函数一个角色，权限按函数的实际动作最小化——读表的函数不给写权限，发邮件的函数不给数据库权限。函数数量多恰恰是优势：权限粒度可以细到每个业务动作，这是长驻服务器做不到的。第二句：密钥不进环境变量，用平台的角色映射让函数运行时自动获得短时效凭据——这是 4.3 临时凭据思想在函数层的直接应用。第三句：把触发器当入口防线管——HTTP 触发的函数过 API 网关的认证限流（5.2 全套适用），消息队列触发的函数验证消息来源，对象存储触发的函数警惕"任何上传都触发处理"带来的成本攻击。

成本攻击值得单独一句：无服务器的按量计费让"资源滥用"变成了"直接烧钱"。攻击者若能无成本触发高消耗函数，等于拿到了一张无限额的信用卡。防线是触发链路上的认证加配额，以及平台侧的消费告警——把"费用异常"当安全告警对待，是新时代运营的常识。

微服务安全：东西向流量的秩序

南北向流量（进出系统的流量）有网关把关，东西向流量（服务之间的流量）过去常年裸奔——反正都在内网。新架构里东西向成了主战场：攻入任何一个服务后，横向的可达性决定战果。秩序靠三件事建立。

服务身份与相互认证：每个服务有独立身份，服务间通信强制双向认证（通行做法是平台签发短时效证书，即服务网格的默认能力）。认证的意义是"陌生服务"模型：即使在内网，没有合法身份也进不了对话。通信授权：认证之上加授权——哪个服务可以调哪个服务的哪个接口，写成显式策略，未声明的默认拒绝。这与 IAM 策略同一思想，只是落点在服务间。流量加密：东西向全量加密，让"内网抓包"这类老手法失效。

# 服务间访问策略示例（声明式风格）
来自 服务[order-service]        # 订单服务
前往 服务[payment-service]      # 支付服务
允许 接口[POST /charges]        # 仅允许创建扣款这一个动作
条件 通信加密[双向认证] 且 时间窗口[业务时段]

# 未声明的组合（如 order-service 调 payment 的管理接口）默认拒绝。
# 攻防含义：支付服务即使被攻破，攻击者借用它的身份
# 也无法反过来调用订单服务的接口——身份是双向核验的。
​

图 5-3：新信任边界下的防御布局

数据面与可观测

服务化之后，一个用户请求会穿过七八个服务，调试与审计都依赖链路追踪。安全视角的链路追踪价值有二：一是出事时能还原攻击者穿行的完整路径（第六章取证的依赖），二是基线化"正常调用链"后，异常路径（从未出现过的服务间调用）即是告警。分布式环境里的日志要携带统一的追踪标识与身份标识，这是第六章日志治理在应用层的预埋。

自查三问收尾：函数角色是否逐个最小化（拿清单逐个比对实际调用与授权动作）；服务间是否还存在无认证的明文调用（服务网格的策略表里查未声明即拒绝的覆盖率）；消费告警与费用异常是否接入了安全告警通道。

一场函数权限过宽的复盘

给函数安全三句要点配一个案例，看过才知道权限过宽长什么样。背景：一个定时触发的报表函数每天凌晨汇总订单数据写入数据仓库。为省事，它的执行角色挂了"全部数据库读写"的策略模板。某天运维在日志里发现：这个函数在非调度时段向一个陌生外部地址发了请求——应用依赖库被投毒（供应链事件的函数版），攻击者借函数身份把订单库拖走了。

复盘：函数只需要两张表的只读权限与仓库的写权限，实际却握着全库读写；函数对外网络出口无白名单，数据静默流出；日志虽全（无服务器的好处），但告警规则没盯"非调度时段的网络请求"。三条整改：角色收敛到动作级（与三句要点第一句对齐）；出口白名单进函数配置基线；调度外活动告警。变式思考：如果函数挂的是短期凭据且权限最小化，同一供应链事件最多偷到一次单表读取——无服务器架构的短生命周期特性本可以把爆炸半径压到极小，前提是权限设计配得上这个架构红利。

新旧架构的安全成本对照

服务化迁移的安全账常被算错方向：只看到组件变多、防线变碎的成本，看不到结构性收益。列一张对照账。成本侧：服务身份数量膨胀、网格层引入运维复杂度、链路追踪要求统一日志规范。收益侧：权限粒度细化到服务级（单体时代全应用共享一个数据库账号的时代结束了）、故障与入侵的隔离单元变小（一个服务失陷不再等于整体沦陷）、部署回滚以分钟计（漏洞窗口期大幅缩短）。综合判断：服务的收益是结构性的、单向累积的，成本是一次性的、随成熟度递减的——前提是身份与网格这两层基础设施到位。算清这笔账，与 5.3 开头那句"拆得越细，东西向防线越是命门"合起来，就是对新架构安全性的完整判断。

本节要点回顾

• 拆掉服务器不等于拆掉责任：函数与托管组件的配置、身份、代码仍是客户侧责任，责任线随架构上移但从不消失。
• 函数安全三句要点：一个函数一个角色、凭据短时效、出口有白名单——短生命周期架构的红利要靠权限设计兑现。
• 东西向是微服务的命门：服务给身份、调用要授权、全链加密，网格层把这三件事统一供给。
• 链路追踪是安全基础设施：还原攻击路径靠它，异常调用链的告警也靠它，统一追踪标识要提前预埋。
• 安全账要算结构收益：权限粒度、隔离单元、回滚速度的收益是长期单向的，成本是一次性递减的。

考试风格的两点辨析

辨析一："无服务器意味着不需要网络安全。"错——网络边界消失，但出口管控、私有端点、调用的网络条件约束还在，且因为没有传统防火墙可配，这些约束改在函数配置与策略层表达，考验的恰恰是责任模型理解。辨析二："微服务数量多，权限模板复用效率高。"方向反了——模板复用正是权限过宽的源头，正确做法是按动作生成最小角色，宁可角色数量多，不让单个角色胖（与 2.3 组合风险的拆分原则同源）。

补一个高频追问：服务网格与 API 网关是不是一回事？不是，分工要分清。网关管南北向——外部请求进系统的那一道门，认证、限流、路由都在这；网格管东西向——服务与服务之间的内部通道，双向认证、调用授权、链路加密都在这。两者最容易被混着答的场景是"在网关上做了认证，内部服务之间就可以裸奔了吗"——答案是不行，网关的认证只覆盖进门那一刻，进门之后的每一次服务间调用都要网格层重新确认身份。考试里见到"已有统一入口认证"的题干，就要警惕选项里"内部调用无需再认证"这类偷换。

应用层的防线画完了，但画出来的防线要每天真实生效才算数——下一章进运营域：监控、响应、取证，以及一次完整的入侵复盘。