微服务安全不是加个防火墙就完事
公司刚把老系统拆成十几个微服务，接口一上线，运维就收到告警——某个用户服务被频繁调用，日志显示请求来自内部网段，但IP地址根本不在已知服务列表里。后来查出来是测试环境的一个临时容器没做访问控制，被人当成跳板打进了生产网。这种事在微服务架构里太常见了。
微服务之间来回通信，API 调用密集，光靠网络隔离远远不够。每个服务都得有自己的安全策略，否则一个漏洞就能牵出整条链路。
统一认证：别让每个服务自己验身份
最开始我们给每个服务都加了 JWT 验签逻辑，结果改一次权限规则就得发十几次版本。后来换成 API 网关统一处理认证，所有外部请求先过 gateway，带上合法 token 才能进内网。
内部服务间调用也不放任自流。用 OAuth2 的 client credentials 模式，服务启动时向授权中心申请短期令牌，调用时放在 Authorization 头里。
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...token 有效期设成 1 小时，配合刷新机制，就算泄露影响也有限。
服务间通信必须走 TLS
别以为在私有 VPC 里就能明文传数据。K8s 集群里 pod 之间的流量默认是裸奔的，我们吃过亏——日志里发现订单金额被篡改，追踪下来是攻击者在节点上抓包修改了未加密的 gRPC 请求。
现在所有服务间调用强制开启 mTLS（双向 TLS），用 Istio 自动注入 sidecar 代理，证书由 cert-manager 从私有 CA 动态签发。配置看起来复杂，但一旦跑通，新加的服务也能自动接入。
最小权限原则要落到实
订单服务不需要访问用户密码字段，但早期接口设计图省事，返回了整个 user 对象。后来调整成按需提供：查询订单时只返回用户 ID 和昵称，真要获取敏感信息得单独走审批流程调用权限更高的接口。
RBAC 规则写进服务的中间件里，比如某个支付回调接口只能被“支付网关”角色调用：
<rule service="order-service" method="POST" path="/callback" allowed-from="payment-gateway" />日志和监控不能少
安全事件往往藏在细节里。我们在网关和关键服务上加了审计日志，记录每次调用的来源 IP、目标服务、响应码和耗时。ELK 收集后跑固定规则，比如“同一源 IP 一分钟内失败超 10 次”就触发告警。
有次半夜报警，查下来是某个定时任务配置错了重试策略，疯狂刷接口。虽然不是攻击，但也暴露了异常行为检测的必要性。
依赖组件也要定期体检
去年 Log4j 漏洞爆发时，我们连夜扫了所有服务的 jar 包，发现两个冷门服务用了带漏洞的版本。现在 CI 流程里加了 SCA 工具（如 Trivy），每次构建自动检查第三方库风险。
微服务数量一多，手动管理就跟不上。自动化工具+统一策略，才是长久之计。