安全加固

一、现象：三起「串号」投诉，指向一个没人想到的入口 先摆数字。去年 Q3 我们给一家多租户订单 SaaS 做安全加固复盘。技术栈是 Nginx 1.24 反代 + Spring Boot 3.1（内嵌 Tomcat 10.1.11），对外提

先说背景。 社区里已经聊了不少安全加固的"该不该做"——默认拒绝、最小权限、一票否决权、CVE 分级，都很精彩。但我最近帮两个团队做安全基线落地时，撞上了一个更"肉疼"的问题：安全加固的性能账单，没人算过账。 打个比方：你给一栋楼装了防盗门

一、现象：一次「找日志」的例行操作，挖出 40 万条明文手机号 上个月给一家做本地生活的 SaaS 客户做季度安全加固复盘。他们上个月刚收到监管问询函，触发点很具体：某竞对员工以「用户投诉退款」为由进客服群，报了一个手机号要求查订单，值班同

先说背景。做了 3 年安全加固，最近帮两个团队做安全基线落地，一个现象让我很扎心：安全团队把规则一条条落地——TLS 1.3、mTLS、WAF、限流、最小权限、日志脱敏——开发也配合、审计也过了、领导也签字了。但没人能回答一个朴素的问题：这

【背景】 我在给一套内部服务做安全加固，目标是"证书 90 天强制轮换 + 轮换期间业务无感"。栈是 Go 1.22 + gRPC，跑在 3 节点自建 K8s 1.28，没有 Istio，mTLS 由应用层自己用 crypto/tls 的

一、现象：一个"运维排查请求"，把生产密钥全拖走了 上个月给一家做电商中台的客户做季度安全复盘。他们上个月被通报：生产环境的对象存储 AK/SK（明文）出现在了某次渗透测试的报告附件里。客户第一反应是"内鬼"，因为他们确认过：".env"

先说背景。我做了 10 年分布式系统，安全加固是日常，但越做越觉得一个悖论：我们加的每一层防护，本身都在引入新的故障点和攻击面。 打个比方：你给房子装了防盗门、猫眼、门铃、电子锁、指纹锁、监控摄像头、报警联动——每一样都是"安全"，但小偷现

【背景】 我负责一套 K8s 1.29（containerd 1.7）集群上约 40 个微服务的镜像安全加固。CI 流水线已接入 Trivy 扫描，策略是"无 CRITICAL 方可发布"。基础镜像统一用 eclipse-temurin:1

«结论先行：连接池里的"会话变量"是会跨业务复用的——任何一次 "SET SESSION"（sql_mode、time_zone、max_execution_time、character_set_*）如果不被显式复位，就会沿着这条连接污染下

【背景】 做了 8 年安全加固，我最近在给一个 20+ 微服务的团队做审计日志改造，被同一个问题反复问："支付流水里那个卡号字段、登录日志里那个手机号，到底该不该打？"——听起来是个二选一，实际牵出来的分歧比我预期的多得多。 打个比方：审计

【背景】 我维护一套内部 API 网关：Java 8 + Netty 4.1.x，3 副本跑在 3 节点自建 K8s 1.26，没有 Istio / sidecar，mTLS 由网关自己用 SslContextBuilder 做。上游客户端

一、现象：报错文案统一了，用户还是被枚举光了 去年给一家做 B 端 SaaS 的客户做安全加固复盘，目标是登录接口 "POST /api/v1/auth/login"，Spring Boot 3.2 + Spring Security 6.

背景：我在做安全加固时反复纠结一件事——"默认拒绝（deny by default）"到底该卡在哪一层。打个比方，一个系统像一栋楼，你不可能每层都焊铁门，但总得有几道真正拦得住的关卡；否则就是"看着很严、其实随便进"，出事了才发现门早被人踹

背景：我做了 3 年安全加固，最近给一套 Spring Boot 3.1 服务做镜像安全加固，基础镜像从 openjdk:8-jdk 换成了 eclipse-temurin:17-jre（slim 倾向，单镜像约 480MB），K8s 1.

【背景】 我在做一套对外 API 的安全加固，网关是 4 个副本（Go + 自研，跑在 3 节点 K8s 1.28，无云）。鉴权用「签名 + 时间戳 + nonce」三件套：客户端带 "ts"、"nonce"、"sign=HMAC(secr

一、现象：一个「看起来随机」的 8 位重置 token，被 208 次请求还原了 去年给一家电商客户做安全加固复盘，目标是「找回密码」接口：用户填邮箱，后端生成一个 8 位 token 写进数据库、拼进重置链接 "https://reset

【背景】 我负责一个 32 节点（16C64G，Kubernetes 1.28.4，Cilium 1.14，containerd 1.7）的生产集群，约 40 个 Service、8 个命名空间，混合部署（Java/Go/Node.js）。

一、现象：一条 kubectl 命令暴露了 3 个命名空间的数据库密码 去年 9 月，安全团队做一次内部红蓝对抗演练。蓝队（我们）的 "payment-service" 跑在 "prod-payment" 命名空间，部署了 4 个 Pod（

【背景】 我们在 K8s 1.27 + Istio 1.20（ambient/waypoint 未启用，走 sidecar 模式）里给一批内部服务开了 STRICT mTLS，服务间走 gRPC。目标是"证书到期自动轮换、业务无感知"。CA

一、现象：一条 @type 字段，30 秒内拿到了一个 WebShell 上个月给一家做金融 SaaS 的客户做渗透评估，目标是一套 Spring Boot 2.7 + fastjson 1.2.80 的后台，其中有个「第三方回调通知」接口