不少团队先把云服务器和数据库放到公网上，出了问题才想起访问控制。白名单通常是最省事的第一道防线：只有名单里的 IP 或网段能连进来，其他请求直接拒绝。阿里云里叫白名单的设置不止一处，ECS 安全组、云数据库 RDS、Redis、OSS、WAF 各有各的规则。分清每一处管的是哪段流量，才能避免改了这里、那里还在拦。
黑名单拦的是已知的坏 IP，攻击者换个出口就能绕过去。白名单只放行已知的业务来源。数据库这类核心资产更适合用白名单，因为应用服务器、办公室出口和堡垒机的地址基本固定，而攻击来源没有边界。
阿里云里几种常见的白名单
云数据库 RDS 的 IP 白名单
RDS 实例默认不接受任意 IP 的连接。在控制台的白名单设置里添加应用服务器的内网 IP、办公室固定出口或运维堡垒机地址即可。这里要注意，RDS 白名单管的是数据库入口，ECS 安全组管的是 ECS 实例自身的出入站流量。应用从 ECS 连接 RDS 时，RDS 白名单必须放行 ECS 的地址。如果 ECS 的出方向规则收得比较紧，也要允许访问数据库端口。两边都检查一遍，不要只看其中一个。
ECS 安全组的端口白名单
安全组按规则放行指定协议和端口，比如只允许某个网段访问 22 端口做 SSH 登录。规则有方向（入方向、出方向）和优先级，冲突时优先级高的规则先生效。修改在线服务器的规则前，最好先在测试实例上验证一次。改错一条，就可能把自己的 SSH 连接也断掉。
OSS 的 Referer 白名单
OSS 常用来存放图片、视频和下载文件。如果不限制来源，别的网站可以直接引用你的文件，流量费用会被别人消耗。Referer 白名单只允许指定域名引用资源，能挡住大部分普通盗链。但 Referer 是 HTTP 请求头，有心人可以伪造，所以敏感下载还需要配合签名 URL 等机制。
白名单误拦截的三种常见情形
下面三种情况在日常运维中很常见，每种都有对应的处理办法。文中的场景是为说明问题而设想的典型情况，并不对应某个具体项目的数据。
开发阶段放开 0.0.0.0/0，之后忘了收回
联调时为了省事，把 RDS 白名单设成 0.0.0.0/0，即允许全网访问。项目上线后，这条规则没人再看。之后数据库日志里出现大量陌生 IP 的登录失败记录，排查、改密码、核对备份都要花不少时间。临时放行的规则应当在备注里写清用途和到期时间，上线检查单里也应该有一项是清理临时规则。
个人宽带动态 IP 导致连接失败
开发人员用家里的宽带连接测试库，家用宽带的公网 IP 会变。白名单里的旧地址失效后，连接就断了，每次都要找运维改规则。更稳的做法是让远程开发统一经过 VPN 或堡垒机，由固定出口访问云端。白名单只登记这一个出口地址，不必逐个登记个人网络。
出口 IP 变化导致服务间歇报错
服务跑在容器集群里，通过 NAT 网关访问云数据库。集群扩容后，出口公网 IP 变了，数据库白名单没有跟上。结果是部分请求报错、部分正常，排查起来很费劲。处理办法是给 NAT 网关绑定弹性公网 IP，把白名单收缩到这个固定地址上，并在发布流程里加一步白名单检查。
配置时的几条操作建议
- 只加业务需要的地址。能写具体 IP 就不写网段，能写一个网段就不要开到 0.0.0.0/0。
- 同 VPC 内优先用内网地址。ECS 访问 RDS 时填内网 IP，数据库就不用暴露在公网。
- 出口固定化。需要被白名单识别的服务，先绑定固定公网 IP 再填白名单。否则每换一次 IP，就要改一次规则。
- 每条规则写明用途、负责人和有效期。每个季度对照一次资产清单，删掉没人认领的条目。
- 修改要留记录。白名单变更走工单，记下谁加的、为什么加，出问题时能追溯。
- 定期看操作日志。在操作审计和安全中心里检查异常登录和规则变动。
白名单之外还需要什么
白名单只回答”谁能连进来”，无法判断连进来的人是否有权限。RAM 子账号要按职责分权，数据库账号只给应用需要的最小权限，传输层开启 SSL 加密。远程运维场景下，堡垒机或零信任接入能把人员身份、设备状态和操作行为串起来，比只看 IP 可靠得多。
控制台的菜单路径、规则数量上限和功能名称会随版本变化。实际操作以阿里云官方文档和当前控制台为准。
小结
阿里云白名单成本低、见效快。用好它主要靠三件事：范围尽量小，临时规则及时收回，修改有记录可追溯。白名单与身份认证、加密、审计配合使用，云上的访问控制才算扎实。
