最近读了一篇文章《一觉醒来，国产数据库云服务器被挖矿、勒索！》，原文作者帮助朋友维护的一个 OpenGauss 数据库，部署在阿里云上，被黑客植入挖矿程序，并且被删除数据表。作者杀掉了挖矿程序，用备份恢复了数据表，修改了密码，让系统重新上线。这是一个非常典型的 IT 生产事故，本身没有戏剧性。

不过，通过这个案例，我们可以看到一个明显的事实：大多数阿里云用户并不知道怎么使用云，还是把云平台当作 IDC。技术栈不仅没有因为上云尔提升，甚至系统的安全性和可用性都下降了。

过时的网络安全配置

作者的数据库是自行安装在阿里云虚拟机上的。从一开始它就在公网上暴露 TCP 22 的 SSH 端口，而且对0.0.0.0/0开放访问权限。作者自己也承认

由于服务器密码设置的很简单，ssh的端口使用的默认端口22，这样就很容易被别人暴力破解了

这个不良配置，我认为阿里云应该负主要责任。因为阿里云的控制台界面[1]上，虚拟机的默认配置就是对 0.0.0.0/0 开放 TCP: 22 端口。阿里云自己也很清楚这样做很危险，特意用“使用须知”的形式给客户告知风险，但是总所周知，我们这一行，99%的用户不会修改默认配置。所以阿里云的这个使用须知，其实只能用来甩锅，不会对用户的生产实践有实质影响。

上面阿里云控制台的截图还有另外一个危险的便捷配置：阿里云虚拟机鼓励用户开放 80 端口。作为古代互联网的遗产，80 端口非常容易被攻击. 云厂商应该只在确认了用户“你知道你在干什么，你已经采取措施控制风险”的时候，才应该让客户使用 80 端口。把 80 端口放在控制台，只会鼓励那些菜鸟滥用 80 端口。等到出安全事故的时候，菜鸟们被骂，云厂商也被骂，顺带着整个云计算也会背负骂名：“你看，我说了上云之后更不安全嘛。”

第二个主要责任人，显然就是用户。阿里云虚拟机默认用密钥对来鉴权，但是用户修改成密码鉴权，并且选择了一个弱密码，极大的降低了黑客入侵的成本。密码鉴权既不安全，也不方便。用户这样做，纯粹是由于老习惯不容易改。要改正广大从业者这种不良习惯，可能还是需要云厂商和其他机构多做宣传和教育。

中国 IT 用户流行一种说法：“云计算好是好，就是不太安全。” 通过一系列案例看下来，这句话确实有一定道理：用户如果继续沿用老习惯使用公有云，确实会降低系统的安全性。如果只是用云虚拟机替换 IDC 虚拟机，就像你用踩单车的习惯开机动车，毫无疑问会导致更多的安全事故。

被闲置的云访问管理

上述的SSH和密码配置主要用用于实施访问控制（Access Control）。实际上，在云数据库领域，有很多高级工具可以用来做更安全的访问控制。

AWS 有一个特性叫做 RDS Data API[2]。应用程序无需创建到数据库实例的连接，而是通过云厂商的 API 发送 SQL 和接收结果。这样 DB 的访问控制就脱离了 DB 本身的配置，而由云厂商的 IAM 接管。由于 IAM 是工作在应用层而不是网络层，其机制更符合现代软件的需求，配置更为简单。

目前大多数数据库已经支持 TLS 连接[3]了。如果在创建 RDS 实例的时候，指定 require_secure_transport，则所有客户端都必须有 ca_certificate 才能正确的连接上 DB，尽管这不是正式的 mTLS，也能极大的增大黑客入侵的门槛。

针对虚拟机的 SSH 访问，人人都知道堡垒机好，但是由于堡垒机会增加资源和管理成本，因此很多中小团队就省略掉它，让生产实例直接对公网开放，一直到出事才会感到心痛。AWS和阿里云都提供托管堡垒机，叫做 Session Manager[4]/会话管理[5]。AWS 宁夏区域的Session Manager 是免费，阿里云的文档没有提及会话管理的价格，但是应该也不会贵。如果原文作者使用了这个功能，就根本不需要在公网上开放 22 端口，消除了一个很大的暴露面。

上述三个技术其实都不是云服务发明的。第一个Data API 可以看作是托管的 Data Proxy，第二个是对数据库内置 TLS 功能的一个封装，第三个是堡垒机 as a service。云厂商的独特价值是，降低这些成本高昂的高级企业特性的使用成本，让其对中小企业也可用。很惋惜的是，阿里云们把这些产品拷贝过来之后，自己也不太会用（我打赌读这文章的阿里云员工有80%以上的没听说过会话管理这个服务），更没有教客户怎么用。看得出来，原文作者尽管把生产环境部署在阿里云上，但是对阿里云的这些高级服务一无所知。对阿里云来说，这也非常可惜，这些服务原本是创造价值的优秀产品，结果因为没人使用躺着吃灰，反而变成了阿里云的成本中心。

云审计：用时方恨审计少

这个案例中，系统被入侵了两次。一个是黑客在主机中植入挖矿程序，一个是黑客连接数据库删除数据表。我怀疑这是两批不同的黑客，至少是两次不同的入侵。植入挖矿程序的黑客显然希望苦主发现时间越短越好，他们会尽量的保持低调。而删除数据表的勒索黑客则希望苦主越早发现越好，他们给苦主发送了通知邮件。

不过我这只能是一种合理的猜测。如果用户开启了审计服务，则很容易写出时间线，并且验证这个猜想。但是可惜的是，原文作者没有提到任何审计和日志。这使得精确的复盘非常困难。而在云上，会话管理天然就有审计日志。顺便说一句，数据库本身的审计日志是不可靠的，因为它默认存储在本地，很容易被入侵者删除。

脆弱的数据库备份

原文作者运气比较好的一点是，第二次入侵的黑客也是个菜鸟，他删除了数据表，但是没有删除本机 /home/omm/probkp 目录下的备份文件。作者用几行命令就恢复了所有数据。如果这个黑客稍微专业一点，把备份文件删除掉，那么苦主恐怕只能掏钱买命了。

实际上，阿里云早就提供了更为可靠的 RDS PostgreSQL自动备份和手动备份[6]，那些要求高的客户还可以跨地域备份[7]。这两个备份机制显然比基于运气的本地备份靠谱多了。

复用被入侵的虚拟机，危险！

原文作者的恢复措施非常粗暴：就在被入侵的本机杀死挖矿程序，恢复数据，然后修改密码防止黑客再来。

这个措施有一个巨大的隐患：如果黑客在本机添加了另外一个 SSH 用户，那么一个礼拜后，苦主又要遭受一模一样的入侵。如果是我，我会利用云镜像服务重建一个干净的机器。在这个干净的机器上，再恢复数据，确认系统工作之后，再把原机器销毁掉。这样就可以更大程度的排除有遗留后门的风险。

这两个思路是云计算用户和非云用户的一个巨大的区别。由于云下重装系统成本高昂，非云用户倾向于把机器视作一个独特的宠物，能够不杀死尽量不要杀死，而云用户在云镜像服务[8]的帮助下，可以轻松重建机器，因此把所有机器视作可以随意替换的牲畜。

在这个意义上，阿里云高调宣传的单机高可用其实是一种前云计算时代的思路。

（2019年）12月13日，全球前三的云计算公司阿里云公布了最新的弹性计算服务等级协议SLA，单实例的可用性从99.95%提升至99.975%，多可用区多实例可用性从99.99%提升至99.995%，均为全球最高水准。

读者如果是 Kubernetes 用户，应该很容易看出：虚拟机的可用性无关紧要，反正所有的 pod 都可能被调度。数据库作为一种stateful组件，情况稍微复杂一些，但是也可以应用同样的原则。在云计算时代，还把虚拟机当宝贝哄着，确实过时了。

这是普遍现象

对于这个数据库入侵案例，阿里云实际上从早期防护，到事故调查，到后期补救都能提供更好的工具。在数据的机密性，完整性和可用性三角都有产品。可惜的是，用户一个都没用，甚至还因为公有云的联网特性面临更大的威胁，实在令人惋惜。

几个大云厂家一直缺乏精巧的用云案例。我的朋友倪海峰这篇《享道出行：容器弹性技术驱动下的智慧出行稳定性实践》算是比较优秀的案例了，但仍只解决一个扩展性的问题，只利用了云计算资源池这一个特性。另外一个朋友李令辉提出《云是一台新电脑》，提出应该把云平台视作一个操作系统，这种用法在云厂商案例中几乎没有看到过。

云产品的单纯搬运工

众所周知，阿里云腾讯云华为云都大量的借鉴了 AWS 的产品设计，搬运得也七七八八差不多了。但是总有一种“形似而神不似”的感觉，用户口碑差很多。

这其中原因固然很多，但是有一点是不可忽视的：阿里云自己也不会怎么用云。市场活动只能请网红罗永浩来卖九块九的虚拟机，用“你把阿里云价格表给你公司的 IT，他一定会大叫不可能”之类的大力丸腔推广专业产品。目前的云计算生态，类似一群骑惯了自行车的人去开汽车，拐弯的时候不会打转向灯，还把左手平伸出窗外，然后集体吐槽：“汽车真不安全，我右拐的都没法指示后车。” 这种奇葩状态怪谁呢？显然只能怪云计算带头大哥带歪了路。

参考资料

[1]

阿里云的控制台界面: https://ecs.console.aliyun.com/home

[2]

RDS Data API: https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/data-api.html

[3]

支持 TLS 连接: https://help.aliyun.com/zh/rds/apsaradb-rds-for-postgresql/connect-to-an-apsaradb-rds-for-postgresql-instance-over-ssl-connections

[4]

Session Manager: https://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/session-manager.html

[5]

会话管理: https://help.aliyun.com/zh/ecs/user-guide/session-manager

[6]

RDS PostgreSQL自动备份和手动备份: https://help.aliyun.com/zh/rds/apsaradb-rds-for-postgresql/back-up-an-apsaradb-rds-for-postgresql-instance

[7]

跨地域备份: https://www.alibabacloud.com/help/zh/rds/apsaradb-rds-for-postgresql/use-the-cross-region-backup-feature-for-an-apsaradb-rds-for-postgresql-instance

[8]

云镜像服务: https://help.aliyun.com/zh/ecs/user-guide/image-overview

Last update: 2024-7-31