企业把业务搬到云上以后，网站、接口和数据库的入口都直接暴露在公网。机房时代，很多服务只对内网开放，攻击者要先穿过几层网络边界。上云之后，这层边界变薄了，攻击面比以前大得多。阿里云盾是阿里云为云上资源提供的一组安全防护服务，主要覆盖流量清洗、应用层防护、安全监控和数据保护。这篇文章先说明它包含哪些能力，再用三个场景讲怎么配。
阿里云盾包含哪些能力
阿里云盾由几项按防护对象拆分的服务组成，各自解决不同的问题。选型时先找出最主要的风险，再逐项开通，没必要一次全开。
- DDoS防护：攻击流量在到达源站前被清洗。如果网站经常因流量突增而变慢，或者业务对连续可用性要求高，优先考虑这一项。开通前要确认域名解析和源站 IP 的切换方式。
- Web应用防火墙（WAF）：识别 SQL 注入、跨站脚本、恶意爬虫这类应用层攻击，支持按规则拦截或放行。有登录、下单、评论等表单和接口的站点，最需要它。
- 云安全中心：集中查看服务器、账号和配置的安全状态，能发现弱口令、高危漏洞和异常登录。账号多、主机分散的团队，可以把它当作日常巡检入口。
- 数据安全与证书服务：提供 SSL 证书管理，并结合数据分级和访问审计，减少敏感数据外泄的可能。证书快到期却没人续，也是常见的线上故障，建议把到期提醒一并设置好。
案例一：电商大促期间的流量冲击
某服装电商在大促前一周收到勒索邮件，对方威胁说不付款就发起流量攻击。团队之前只在源站配了基础带宽，没有专门的清洗能力，接到邮件后有些慌。
他们分三步处理。第一步，把域名解析切到阿里云 DDoS 防护，让业务流量经过清洗节点。第二步，在 WAF 里给登录接口和下单接口设置请求频率限制，对异常来源弹出验证码。第三步，在云安全中心配置告警，攻击峰值出现时通知值班人员。
大促当天，攻击流量在清洗节点被过滤，源站负载保持平稳。复盘时团队发现，提前演练切换流程，比临时调规则省事得多。如果切换是临时做的，就会遇到解析要等一段时间才全面生效、证书还没配好等问题，这些都会变成新的故障。
案例二：内容平台的恶意爬虫与撞库
一家资讯网站发现，夜间登录接口的请求量明显高于白天。大量请求用同一批用户名尝试不同密码，部分账号随后出现异常评论。
团队在 WAF 中给登录接口加了规则，依据请求频率和设备特征判断。同一 IP 在短时间内失败登录超过阈值，就自动拦截。对爬虫，他们先用观察模式跑了一周，只记录不拦截，确认搜索引擎爬虫和正常用户没有被误伤，再切换为拦截模式。
这个案例里，观察期是最值得照做的一步。规则直接上拦截，很容易挡住合法流量，搜索引擎抓取和合作方的接口调用都可能受影响。上线前把白名单理清楚，能省掉很多排查时间。
案例三：小团队的账号与权限治理
一家十人左右的 SaaS 公司，服务器账号由几个人共用，离职同事的访问密钥也一直没有回收。云安全中心扫描发现多台主机存在弱口令，还有一个访问密钥长期没有轮换。
团队的处理顺序如下。先为每个人创建独立子账号，按最小权限分配角色，不再共用登录。再轮换全部访问密钥，把新密钥存进密钥管理服务，代码仓库里的明文密钥全部删除。最后开启多因素认证，并在安全中心设置每周一次的基线检查。
整改大约用了两周。之后的扫描中，高危项从最初的十余项降到个位数。高危项能降下来，主要因为每个人的权限有了记录，离职时也知道该回收哪些东西。
落地建议
- 先盘点对外暴露的域名、接口和服务器，并标注每项的负责人。后面调整规则时，才知道该找谁确认。
- 按风险优先级开通服务。一般先开 DDoS 防护和 WAF，它们直接挡住外部流量；云安全中心可以紧跟着上，用来查漏洞和弱口令。
- 所有新规则先用观察模式运行，确认没有误伤后再改为拦截。
- 每季度演练一次流量切换和应急响应，把操作步骤写成文档，让值班人员能照着做。
- 每季度检查一次子账号、访问密钥和告警记录，及时回收离职人员的权限，清理长期不用的资源。
常见误区
第一个误区是以为开了服务就安全了。规则不调整、告警没人看，防护效果会打很大折扣。第二个误区是把所有规则都设成拦截。短期看起来很严格，实际可能挡住正常用户和合作伙伴的请求。第三个误区是忽视账号管理。很多安全事件的起点，常常是一把长期有效、没人记得的密钥，而不是什么复杂的技术漏洞。
阿里云盾能承担大部分基础防护工作。它能发挥多大作用，取决于团队是否清楚自己业务的风险点，并且持续维护这些配置。
