小程序服务器安全配置：端口管控与数据保护实战

　　去年秋天，我蹲在客户机房换防火墙规则的时候，窗外下着雨，雨点砸在空调外机上像弹珠蹦跳——就那种闷响，一下一下，敲得人太阳穴发紧。老张叼着没点着的烟，在旁边抠服务器机柜缝里的灰，指甲缝里全是黑的。我原以为只要关掉非必要端口、TLS1.3拉满、JWT密钥轮转搞成小时级，这事就算闭环了。结果第十七次压测刚过，小程序登录态崩了，前端报错是“网络异常”，后端日志里却连 SYN 包都没捕到。

文章配图，仅供参考

　　不是防火墙挡的。是那个被我们所有人当装饰品用的云安全组——它默认允许所有内网流量。运维小王下午两点十五分接了个电话，讲的是他家小孩肺炎住院的事，手一滑，把整个 172.16.0.0/12 的出方向策略全设成了“允许”。这事儿跟端口管控有毛关系？没直接关系。但它让所有端口管控都成了纸糊的窗花。我们花了六小时查路由表，最后发现漏洞不在 iptables，在一张 Excel 里——安全组配置导出表里，“Outbound”列被人用 Ctrl+D 拖满了“Allow”，连注释栏都写着“（小孩退烧后补）”。

　　数据保护？呵。客户数据库的 binlog 路径是 /data/mysql/binlog/，权限 755，属主是 mysql，但备份脚本跑在 root 下，每次 tar -czf 之后顺手 chmod 644，然后 scp 到一台“专用中转机”上——那台机器 SSH 密钥还在 root 的 .ssh/authorized_keys 里明文存着三个人的公钥，其中一个是实习生三个月前离职时忘删的。这个我敢打包票：我在现场用 tail -f /var/log/secure 看见那台中转机凌晨三点二十一分被连了四十七秒，IP 是阿里云华北五的弹性公网，User-Agent 里带了 curl/7.68.0，没走任何代理链。至于是不是扫描器……我说不准。反正第二天早上八点，那台中转机上的 .tar.gz 文件 md5 值变了，变之前最后一次 touch 是昨天下午四点零七分，桌上那盒酸辣粉已经凉透，汤面浮着一层油膜，筷子斜插在纸盖上。

　　优胜劣汰？对。真淘汰。不是淘汰配置漏项的人，是淘汰那些还信“配完就稳”的人。我们组前两天砍掉了一个做“AI 防刷”的中间件模块，不是因为它没效果，是因为它强制所有请求走 Redis 队列——结果某天 Redis 实例内存突增三百七十二 MB，监控报警延时十七秒，而真实攻击流量其实只触发了队列头三个请求；后面五百个排队的，全是正常用户卡在 loading 状态里刷新出来的重试。那个中间件写得特别漂亮，Go 写的，接口文档生成率百分百，metrics 指标导出也规范。可它没解决“用户按两次提交键就发俩订单”这事儿，反而把问题从前端抖到了后端队列积压层。后来我们改用最土的方案：前端加 disable + 时间戳防抖 + 后端幂等键前置校验。三行 SQL 解决的，比那套微服务架构少启八个 Pod。

　　说到Pod……上周五我去隔壁楼帮他们调一个 webhook 超时问题，发现他们把小程序回调地址绑在了 NodePort 上，Service 类型是 ClusterIP，但 YAML 里写了 hostNetwork: true。我没好意思当场说破——这玩意儿连 kube-proxy 都绕过了，iptables 规则根本不进它的眼。我就站在他们工位边上看着，手里捏着半块风干的桃酥，掉渣掉得键盘缝隙里全是碎末。他们组长一边敲 kubectl get pods --all-namespaces | grep 'webh'，一边问：“会不会是 TLS 握手慢？” 我把桃酥渣吹到地上，没接话。雨早停了，但机房顶棚还在滴水，嗒、嗒、嗒，跟那天一模一样。

　　哦对，数据加密那块我们最终没上国密 SM4。倒不是成本或性能问题，是小程序端 JS SDK 不支持硬件加速解密——安卓端能用 Trusted Execution Environment，iOS 得靠 Secure Enclave，但这两个东西在微信 WebView 里压根不暴露 API。我们试过硬塞 asm.js 轮子，首屏加载时间涨了四倍。最后妥协：敏感字段用 AES-GCM 加密，密钥由小程序从后端动态取，取完立刻销毁；同时要求所有手机号、身份证号在落库前脱敏为 hash(原始值 + 随机 salt)，salt 每月换一次，存 redis。听起来严谨吧？其实第一次上线当晚，有个运营同学用 Excel 导出用户列表时，顺手把 hash 字段当成明文复制粘贴进了微信群。没人拦，因为群名就叫“日常数据同步”。

　　我现在每天早上第一件事，不是看 Prometheus，是翻一遍客户服务器的 last -i 日志。不查 root 登录，专查有没有陌生 IP 在凌晨两点前后连过 22 端口超过三次。连过一次算心跳，两次算试探，三次——哪怕就输错密码，我也要马上 ssh 进去改 sshd_config，把 MaxAuthTries 改成 1，PasswordAuthentication 改成 no，改完 reload，不 restart。这不是 paranoid，是上次有个客户说“我们从来没被黑过”，结果审计方用他的小程序源码反编译出一个埋了两年的 debug 接口，路径是 /api/v1/internal/debug/userinfo?token=xxxxx，token 是 base64 编的固定字符串，解出来是 “admin123”。那个接口连 nginx access_log 都没记，因为 upstream 配的是 if ($request_uri ~ "debug") { return 404; } ——可它忘加 break，rewrite 模块优先级更高，直接透传给了后端。

　　所以现在我改主意了。下次再碰这种事，不先写 config，先拍张照：拍机柜顶部散热风扇的型号标签，拍桌角那包抽了一半的黄山烟，拍墙上挂着的消防责任公示牌——上面印着物业电话和责任人签名。这些照片我存在离线相册里，不上传。等哪天又下雨，我又蹲在机柜前面，手指沾着灰和冷凝水，再翻出来看看。看什么？看自己有没有记住，上一次踩坑时，也是这么湿的指腹，也是这么哑的嗓子，也是这么想“这次肯定没问题”的念头。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!