别人的问题？不要依赖云服务网络安全

道格拉斯·亚当斯在他的《银河系漫游指南》一书中向观众介绍了“SEP领域“，它甚至能够渲染巨大的物体，例如太空飞船，人眼几乎看不见。他解释说，这是可能的，因为 SEP 是“别人的问题”，因此只能从眼角瞥见，甚至被忽视。

在云计算领域，网络安全以及在某种程度上数据可行性本身都成为 SEP。公共云提供商服务的用户习惯于忽视围绕云安全和数据保护的许多问题——其中一些是关键任务，或者代表着无价的 IP（知识产权）。

如果是在 AWS 上，那么安全性是 AWS 的问题，而不是创建存储桶的 IT 部门的问题。

人们很容易责怪最终用户，他们在公民发展概念或创建新服务的便利性的支持下，为自己、他们的部门或他们的客户开发新的工具和服务。但责任归咎于 IT 部门：IT 现在可能是新一代精通技术的最终用户的推动者和支持者，但当出现问题时，承担责任的将是 IT 部门。

云安全调查

并根据Unit 42的研究作为 Palo Alto Networks 的一部分，通常由 IT 部门设置远程平台的实例，特别是因为远程公共云的许多用例不涉及在线注册有用的应用程序，而是设置 IaaS/PaaS 实例。在旧式服务器场中租赁裸机硬件或虚拟机在网络安全方面存在复杂性（需要有能力的处理），那么为什么 EC2 或同等产品会有什么不同呢？

Unit 42 的研究人员发现，所有主要提供商的服务中都存在几个“开放”的潜在漏洞，Unit 42 推测，只有几个差异是由注册和初始配置例程的细节引起的。

其中最主要的担忧（至少就问题数量而言）是不受密钥对保护且依赖密码访问的 SSH 服务的暴露。虽然 SSH 是一种相对安全的“拨入”远程服务器的方法，但当协议可以使用简单的密码保护时，暴力攻击是可能的。

该公司发现，由于此问题，Microsoft Azure 的服务尤其面临风险，可能是因为新 Azure 实例的配置过程让潜在的系统管理员可以在使用公私密钥对和密码之间进行选择。其他提供商对密钥对的坚持可能可以解释这种异常现象，尽管愤世嫉俗者也可能指出这样一个事实：微软自己的文档指出 Windows 桌面上用于创建密钥对的最佳工具位于 WSL 2 中； Windows 用户对基本的安全概念感到困惑，这是潜台词。

云安全与裸机网络安全

Unit 42 的 Jay Chen 说道：

“用户需要有最低限度的安全意识才能在云中工作。虽然功能即服务为用户减轻了很多维护负担，但开发人员仍然需要编写代码并为每个功能分配适当的权限。如果功能使用的库中发现新漏洞，只有开发人员可以修补和更新源代码。如果 CSP 向暴露的 SSH 服务发出警报并建议防火墙配置来限制入站流量，只有系统管理员知道防火墙应将哪些 IP 列入白名单。这些琐碎的任务太麻烦了。”经常被忽视，这可能会导致灾难性的后果。”

他接着说：“不同的组织只是在不同的云服务提供商那里重复同样的错误。”

您是否知道一个不安全的配置会导致整个＃云基础设施面临风险？我们的最新博客分享了更多详细信息：https://t.co/ardFSfoGQ2 pic.twitter.com/D0HNYB4a62

— 第 42 单元（@Unit42_Intel）2019 年 8 月 13 日

正如道格拉斯·亚当斯所解释的，SEP“场”依赖于“人们的自然倾向，不会看到任何他们不想看到、没有期待或无法解释的东西。如果埃弗拉法克斯把这座山漆成粉红色，并在上面建立一个廉价而简单的“别人的问题”场，那么人们就会走过这座山，绕过它，甚至越过它，根本不会注意到那个东西在那里。”

这个故事的寓意很简单，即远程“东西即服务”与组织总部服务器机房中的物理服务器一样受到在线审查：对于寻找弱点的机器人和算法来说，两者都只是 IP 地址。同样，当责任归咎于哪个平台上——远程谷歌云还是离家更近的平台上——都是无关紧要的。