云安全防御措施，这三层漏了白花钱

云安全防御措施这件事，能省钱的思路是先把三层摆明白，再决定哪层花钱、哪层用免费的顶住。缺一层，前面花掉的那部分基本等于白扔。听着像废话，但把管理端口挂在公网上、密码还是弱口令的站点，出事往往比谁都早，防火墙买得再贵也拦不住。

云安全防御措施的三层，先弄清楚谁管谁

我的分法不按厂商的 PPT 来，按攻击者进门的路子分。最外面那层管「谁能连上你」——安全组规则、暴露在公网的端口、SSH 和数据库允许从哪来。中间那层管「连上之后能干什么」——系统补丁、账号权限、登录和操作日志。最里面那层管「出事了还剩什么」——备份、快照、密钥、数据本身的访问控制。

这三层不是并列关系，是串起来的。任何一环断了，另外两环就只剩心理安慰。便宜的往往是最外面那层，偏偏也是被省得最多的那层。

入口这层最省钱，也最容易被放过去

云厂商给的安全组和基础防火墙，一般不用额外掏钱。把默认全放通的规则改掉，只留 80、443 和确实要用的业务端口；数据库和管理后台只允许固定 IP，或者干脆只走内网——这是性价比最高的一个动作。SSH 别用密码登录，换成密钥，root 直接禁掉，要用的时候再提权。

还有个小习惯挺管用：隔段时间翻一遍安全组规则列表，看有没有为了临时调试随手加上的 0.0.0.0/0。这种口子加的时候图方便，忘了删就是长期裸奔，而且自己完全没感觉。

第二层：机器里面，装完面板不等于完事

面板装完能打开，不代表系统就安全了。系统镜像和面板自身的更新要跟上，尤其是那些对外提供服务的组件，补丁落后一两个版本就可能被人扫到。账号上做最小权限，能不用 root 就不用，能只给某个目录的权限就别给整个盘。

日志这块很多人嫌占地方关掉了，登录日志和操作日志恰恰是出事之后唯一能回头查的东西。留着，定期转走或者存到别的机器上，本地被人清掉的时候还能留一份。

第三层：备份没恢复过，就不叫作数

备份最容易自我欺骗。快照和备份不是一回事，快照通常和原盘在同一个账号甚至同一个可用区，账号被人端了，快照多半一起没。真正能救命的备份要满足两个条件：离线或者异地，以及你亲手恢复过一次。

我自己的做法是重要数据留多份，其中至少一份放在别的云账号下，权限互相隔离。就算主账号的控制权丢了，那一份也删不掉。至于多久备一次、保留多久，看你的业务能接受丢多少数据，别照搬别人的方案。

免费的先做满，再谈加预算

云厂商自带的基础能力——默认安全组、镜像漏洞提示、登录告警、基础 DDoS 防护——具体有哪些、能用多少，以各家的官方页面说明为准，别听转述。这些通常不额外收费，先全部打开、把告警配到手机上，再考虑买不买高级服务。

顺序搞反就是白花钱：WAF 挡得住应用层攻击，挡不住有人拿弱密码登 SSH；高防扛得住流量，救不了已经通过合法入口被拖走的数据库。缺口没堵，买什么都是事后安慰。

出现这几个信号，再考虑掏钱

一个是业务开始被人针对性地刷，正常用户进不来，这时候高防或者 WAF 该上了。二是你手里握着大量用户信息，一旦泄露的代价远大于防护开销，那合规审计这块值得花。三是团队里没人专职盯安全，那就买个托管检测，比彻底放着不管强。

反过来说，一个访问量不大的展示站，把三层基础动作做扎实基本够用，不必一上来就堆产品。防护不是买得越多越安全。

几种我看了就头疼的做法

备份放在同一台机器上，还写了个定时任务往本地 sql 文件里导，被人拿到权限顺手就删了。告警一个没配，被打了两三天才从客户嘴里知道。密钥和数据库密码直接写进代码提交到仓库，私有仓库也一样——只要有人拉过代码，就等于泄露过一次。

这些都不是技术难题，是习惯问题。改起来也不难，就是没人提醒的时候总想着以后再弄。

要落地的话按这个顺序走：先把安全组和公网端口清一遍，再把 SSH 和数据库的登录方式收紧，接着配好登录告警，然后做一份异地备份并亲手恢复一次，最后才评估要不要上 WAF 和高防。不用一次做完，但每一步都要清楚它挡的是哪一层的风险。

漏掉的那层迟早会被人找到，攻击者不会比我们笨，只会比我们更有耐心。