不少企业把业务搬上云以后，会默认服务商已经替自己把安全兜住了。实际上，云服务器安全性是云厂商和使用者一起负责的事。机房、物理主机和虚拟化平台归厂商管；操作系统、应用程序、账号权限和数据本身，基本要靠使用者自己把关。
两起事故说明了什么
案例一：一处配置失误，泄露了上亿条客户信息
2019年，美国第一资本（Capital One）发生重大数据泄露，约一亿名美国客户的信息受到影响。攻击者利用Web应用防火墙的配置错误，发起服务端请求伪造（SSRF）攻击，进而访问了亚马逊云EC2实例的元数据服务，拿到了该实例所绑定IAM角色的临时凭证。这个角色权限过大，攻击者因此能读取多个存储桶里的数据。
问题其实出在两个地方：应用层有漏洞，实例权限又给得太宽。如果角色只拥有业务必需的权限，即使前面的漏洞被利用，能拿到的东西也会少很多。
案例二：管理控制台没有密码
据公开报道，某知名电动汽车公司的Kubernetes集群管理控制台没有设置访问密码，任何能联网的人都能直接进入。攻击者在集群里部署了挖矿容器，还从容器中读到了云账号凭证。挖矿程序占满计算资源，企业既多付了云费用，也要花大量人力去排查到底有哪些权限被动过。
两起事故有个共同点：管理入口暴露在公网上，又没有任何身份验证。很多团队花力气保护业务系统，却忘了管理界面同样是入口。
五项配置，上线前先逐一检查
- 最小权限：实例角色和子账号只授予业务真正用到的权限。每季度翻一遍授权记录，长期没人用的账号直接回收，不要留着“以后可能用得上”。
- 网络边界：安全组只放行必要端口。SSH、远程桌面和数据库端口不要对公网开放，需要远程管理时，通过堡垒机或VPN进入。
- 身份认证：日常操作不用根账号。所有管理员都要开启多因素认证，访问密钥定期轮换。代码仓库和镜像里不能留明文密码，这一点最容易在赶进度时出问题。
- 补丁与镜像：操作系统和依赖库要及时更新。基础镜像需要经过审核，上线前用漏洞扫描工具过一遍，别把带着已知漏洞的镜像直接推到生产环境。
- 日志与监控：开启云审计日志，并对异常登录、异常流量和高危API调用设置告警。日志最好存放在独立账号里，否则攻击者拿到主账号后，第一件事就可能是删掉痕迹。
三个常见误区
- 以为开了云厂商的默认防护就够了。默认防护通常只覆盖基础设施层。应用漏洞和错误配置，还是得自己查、自己修。
- 把测试环境当成低风险区域。测试实例经常接入真实数据，或者挂着高权限凭证。一旦暴露，它照样是入侵的突破口，甚至比生产环境更容易被忽视。
- 备份和安全分开考虑。备份要加密保存，并与生产环境隔离。如果备份和生产在同一套权限下，勒索软件可能连备份一起加密。
云服务器的安全性，最后还是落在一项项具体配置上。权限、端口、凭证和日志，都要有明确的负责人，并且定期检查，不能只在上线那天看一次。
