外网网站和应用软件五层管理

去年我帮一家做跨境电商的朋友排查问题，他们一个部署在AWS新加坡节点的用软后台系统，连续三天被来自东欧的管理IP刷接口，每秒两千次请求，外网网站数据库连接池直接打满。用软运维团队一开始只封IP，管理封了三百多个，外网网站结果对方换C段继续打。用软后来他们才意识到，管理问题不在“封得够不够快”，外网网站而在于整个外网资产的用软管理根本没有分层——所有东西混在一起，出事只能被动救火。管理

这件事让我把外网管理拆成了五个层次。外网网站不是用软理论模型，是管理实际排障时一层层剥出来的。

L1 网络接入层

这一层管的是“谁能连进来”。防火墙规则、WAF、DDoS清洗、IP白名单，都属于这里。很多团队犯的错是把WAF当成万能盾，规则配了几百条，结果一个误杀把正常用户挡在外面。我见过最离谱的配置是某SaaS后台，WAF规则里有一条“拦截所有包含select字样的请求”，直接把所有带搜索功能的页面干掉了。

接入层的核心不是堆设备，是流量基线。你得知道正常时段每秒多少请求、来自哪些地区、UA分布什么样。没有基线，任何告警都是噪音。我习惯用nginx日志跑一个简单的awk统计，每五分钟看一次TOP 20 IP和URI，成本极低，但能提前发现异常。

L2 域名与证书层

域名是外网资产的“门牌号”，但很多人连自己有多少个门牌号都说不清。子域名爆破、证书透明度日志、DNS历史记录，这三样东西拼起来，基本能还原一个组织的完整外网轮廓。我做过一次资产梳理，用crt.sh查一个客户的证书日志，发现他们三年前上线的一个测试环境域名还在解析，指向一台早已无人维护的服务器，上面跑着phpMyAdmin弱口令。

证书管理同样要命。Let's Encrypt自动续期方便，但一旦某个域名不再使用却忘了删DNS记录，续期失败就是连锁反应。我建议把所有证书到期时间拉到一个表格里，提前30天告警。别依赖记忆，记忆在外网管理里是最不可靠的东西。

L3 应用与接口层

这一层是攻击面最集中的地方。API鉴权、参数校验、速率限制、错误处理，每一个点都可能成为入口。去年某社交App的/api/v1/user/export接口没有做权限校验，任何人传一个user_id就能导出别人的完整数据。问题出在开发阶段——接口文档里写了“需要登录”，但代码里忘了加中间件。

我的做法是给每个对外接口打三个标签：是否鉴权、是否限流、是否记录审计日志。三个标签缺一个，上线流程直接卡住。听起来很笨，但比事后写事故报告轻松得多。

L4 数据与存储层

外网应用最终要读写数据。数据库端口暴露公网、对象存储Bucket权限设为public-read、Redis未设密码——这三件事每年都在重复发生。我有个习惯，拿到一个新目标，先跑一遍nmap看开放端口，再用curl试几个常见路径。十次里有三次能撞到不该开放的东西。

存储层的管理原则很简单：默认拒绝，显式放行。但实际操作中，业务方为了“方便调试”，经常把安全组改成0.0.0.0/0，然后忘了改回来。我的经验是，任何临时放行必须带一个自动过期的标签，比如expire:2024-06-01，到期自动回收。

L5 监控与响应层

前四层做得再好，没有第五层就是瞎子。监控不是装个Zabbix看CPU，而是要有业务语义的告警。比如“登录接口失败率超过5%持续两分钟”比“服务器负载超过80%”有用得多。响应层面，我坚持一个原则：所有外网资产必须有明确的Owner。没有Owner的资产，要么下线，要么强制指派。去年清理一个客户的外网资产，发现17%的域名和IP没有责任人，其中三个还在跑着两年前的框架版本。

这五层不是瀑布式流程，是循环。L5发现的问题会倒逼L3改接口、L2删域名、L1调规则。我见过太多团队把精力全砸在L1买设备上，结果L3一个未鉴权接口就把所有投入清零。外网管理没有银弹，只有一层层剥开、一层层堵住。累，但有效。