美国服务器租用，别把权限开给不该开的人

这两天好几个客户来问：看到新闻说有人用 AWS 的权限偷数据，这事会不会发生在自己租的美国服务器上？问得挺准，因为出事的不是某家公司自己的云环境，而是它们信任的第三方平台——Qubole，一个大数据分析服务商。

据公开报道，攻击者拿到了 Qubole 平台的 AWS IAM 凭据，时间大概在 10 月 14 日到 26 日之间，直接通过这个合法身份访问了多个客户的 AWS 账户，把里面存储的密钥和数据都拖走了。同期的 Fireworks AI 也披露了一次泄露，同样是第三方云提供商被攻陷，导致他们内部的开发机器被入侵。

凭什么一个第三方账号被攻破，你的数据就出去了

这件事的麻烦之处在于，攻击者没有硬碰硬打你的登录密码，也没有撞大运扫描端口。他用的是 Qubole 本来就应该有的访问权限。为了帮你处理数据，这类平台通常需要读你的对象存储、写回结果，甚至调用一些计算资源。你开通服务的那一刻，就等于把它拉进了你的云环境，配了 IAM 角色，开了策略——而且很多人开的还是接近完全的读写权限。

不少客户租完美国服务器会觉得，租的是独立物理机，总不会碰到这种多租户的坑吧。但实际上，只要你把服务器的远程管理、日志监控、自动备份交给第三方 SaaS，就等于给这家服务商开了一扇门。万一它自己的凭保管不好，攻击者进到你服务器的难度，可能比你想的低得多。

独立服务器是不是就安全了？得看权限收在哪一层

给出否定答案之前，先把一个常见的误解说清楚：美国独立服务器、多 IP 站群服务器，天然隔离了硬件资源，确实不存在公有云那种“弹性计算层被捅穿”的横向移动风险。但是，软件层面的访问权限仍然可以一层层穿透过来。如果你把一个监控 agent 装在所有服务器上，agent 回连的是一台被控制的那个第三方主控端，接下来会发生什么，不需要太多技术想象。

所以我跟客户解释的时候习惯分两层讲：硬件隔离解决的是“邻居失火不烧到你”，权限隔离解决的是“你的帮手被人冒充了不害到你”。租美国服务器的时候，两个都得照顾到。

多 IP、大带宽，挡不住权限上的口子

有一种反应我遇到很多次：客户听到这类事件，第一件事是想加高防、买更大的带宽，觉得挨打是因为入口没守住。但根据现在公开的细节，这几次入侵跟 DDoS 没关系，流量没异常，攻击者完全是拿着钥匙从正门走进来的。大带宽和高防在这些场景里不解决问题。

多 IP 服务器也是一样。每个站点绑一个独立 IP，对 SEO 和流量调度确实有用，可如果你把所有站点的运维都交给同一个被攻破的控制面板或者同一个拥有 root 权限的远程管理通道，那攻击者一旦进来，非常方便通吃。所以给美国站群服务器规划多 IP 的时候，我习惯提醒一句：IP 分了，账号和权限也得分，不然工作量做了，风险没降。

现在马上能做的，是翻翻权限清单

每次这类新闻出来，我都会跟维护中的老客户同步一个建议：趁着还记得都开过哪些第三方接入，尽快做一次权限检查。公有云用户就看 IAM 策略里有没有多余的读写权限、有没有长期不用的访问密钥。如果是租的美国服务器，检查三点就够了：

• 哪些外部 IP 可以免密 SSH 或者 WinRM 登录，里面有没有已经停用的那个加入过监控平台的地址。
• 服务器上安装的第三方 agent 和面板，是直连你的账号，还是用了统一的平台凭据——后者的风险会和这次 Qubole 事件完全一样。
• 自动备份推送的目标存储桶或者 FTP，登录凭据是不是跟其他系统共享的，并且有没有多余的删除权限。

做完这一步，很多“不知道从哪丢的数据”的问题，答案就出来了。

如果手上的业务确实需要一个独立、可完整掌控的环境，美联科技的美国独立服务器提供了全 root 管理权限和物理隔离，你可以完全按最小权限原则去配置 IAM 策略和安全组，不给任何第三方多留一扇不必开的门。具体的机房——洛杉矶、圣何塞、达拉斯、弗吉尼亚都有——怎么选要看你的用户主要分布在哪，线路和延迟的取舍可以单独聊。

不想折腾权限清单的，也可以直接联系顾问帮你做一遍安全评估，看看现在的美国服务器架构里，哪些信任关系该收紧、哪些不该开。