云安全组件没配好，防护等于零

防护这事最尴尬的地方不是没买，是买了没开。见过一台云主机，云防火墙开了、主机安全的 Agent 也装了、前面还挂着 WAF，看着挺齐活，结果一次端口扫描下来，数据库的 3306 对着全网敞着，安全组规则的备注栏还留着”临时测试”四个字。这就是标题那句话的意思——云安全组件本身不干活，干活的是它里头那几行配置。配置没落地，你在控制台里点过的每一分钟，基本都变成了心理安慰。

装完不点开启，它就是个图标

控制台里那一排开关，默认状态是有讲究的。组件安装，只是把进程跑起来了，真正决定拦不拦的是”防护模式”。常见就那么几档：仅监控、拦截、关闭，默认多半停在监控档上，厂商怕误伤业务，先让你观察一阵。你不知道这件事，就会以为它在拦，实际上它只是把攻击记在小本子上，一条都没挡。上线前建议把模式切到拦截，或者至少把高危规则单独设成拦截，切完拿自己的域名打两下试试，别嫌麻烦，这一步省不得。

云安全组件的默认策略，通常是全放行

安全组、网络 ACL 这类的默认逻辑，一般是出方向全放、入方向按需配。有人图省事，入方向直接写 0.0.0.0/0，端口一栏填 1-65535，一劳永逸。这恰恰是最坑的一条，因为业务一切正常，你收不到任何异常提示，只有外面的扫描器知道你家门没锁。合理的做法是只放业务口，比如 80 和 443，SSH 换个非标端口并限定来源 IP，数据库端口只对应用服务器的内网地址开。云安全组件里那些”一键放通””快速开通”的按钮，能用就别用，图一时爽的代价后面都要还。

白名单写错，比不开还危险

这里有个反常识的点。白名单的威力在于”只放行这些”，所以往里塞一条 0.0.0.0/0，等于把黑名单的思路反过来用，同时给了自己一种”我配了白名单”的错觉，比压根没配还容易出事。另一个常见混乱是回源段和办公网 IP 混着写，时间一长谁也说不清哪条能删、哪条删了会掉线。我的习惯是每次改动都写清楚备注和日期，再加一个到期提醒。备注不是形式主义，它是给三个月后已经忘光的自己看的。

日志不告警，等于没装

组件都会产出日志：拦截记录、登录失败、异常进程。问题从来不是没日志，是没人看。控制台默认把告警丢进站内信，站内信谁天天点？至少把高危事件推到你会看的地方，短信、IM 机器人、邮件都行，然后自己触发一次验证一下，确认真能收到。阈值别定太低，不然一天几十条消息，你会直接静音，那比不设还糟糕。顺便看一眼日志留存时间，默认 7 天的挺常见，出事之后想回溯就没数据了。要长期留，得开日志服务或者转存到对象存储，这块钱不太建议省。

组件之间打架，也是常事

多层防护叠在一起，互相挡是家常便饭。WAF 拦下的请求，主机安全又记一遍；手动在 iptables 里封掉的 IP，和上层安全组策略对着干；改了 SSH 端口，结果登录告警还盯着 22 不放，正常登录被标成异常。排查顺序一般是从外往里走：CDN 或 WAF、云防火墙或安全组、主机防火墙、最后才是应用自身。一层层确认谁在拦，别上来就把组件关掉——关掉问题确实”消失”了，但你也不知道到底是哪个环节干的活，下次还得再折腾一遍。

上线前能顺手做的几件事

给个粗糙的清单，不用照抄：扫一遍自己机器的开放端口，默认密码全部换掉，后台路径别用 /admin 这种一眼猜到的，防护模式确认在拦截档，告警通道打通并且验证过一次，日志留存时间心里有数，备份做过恢复演练。这几件事加起来花不了多少时间，但能挡掉绝大多数自动化扫描和批量爆破。真要压缩，就保底做前四件。

别指望一劳永逸

配置是会漂移的。上了个新服务忘了收口，换了 CDN 忘了更新回源白名单，同事离职带走一把 SSH 密钥，这些都是慢慢积累出来的洞。建议每个季度，或者每次上线新功能之后，把清单过一遍。各家云厂商的产品迭代都挺快，控制台位置、默认值、规则写法都可能变，具体还是以服务商官方文档和控制台里的实际说明为准，别照着一篇两年前的教程硬套。

所以先别急着买新的组件。把已经买的那几个挨个点开看一眼：模式在不在拦截档、规则里有没有 0.0.0.0/0、告警到底发到了哪儿。这三件事弄利索，防护水平大概率比再堆一个高级版提升得更多。