云计算需要运营门控——尤其是安全方面
其中包括现在臭名昭著的 CloudPets 闹剧，其中孩子和父母之间的语音信息（假定是私人的）对任何足够精明的人都是公开可访问的，只要他们能抓取数据库（MongoDB 的非安全实例）或了解应用程序架构及其对 Amazon S3 的使用。 Cloud Pets 使用 S3 来存储个人资料图片和语音记录，并且显然放弃了任何类型的安全性，任何有适当参考的人都可以访问它们。
现在，以免您认为我在挑剔 CloudPets，让我指出， RedLock CSI 团队最近发现“公共云计算环境（例如 Amazon Relational Database Service 和 Amazon RedShift）中的 82% 的数据库未加密”。
[戏剧性停顿]
此外，“31% 的数据库正在接受来自互联网的入站连接请求。”
我还需要指出的是，2017 年 1 月的第一周，有超过 27,000 台 MongoDB 服务器遭到入侵。 在这次事件中，CloudPets 受到的损失远远大于他们自身糟糕的安全措施。 正如MongoDB 在首次攻击被披露时在其博客中所指出的那样，“这些攻击可以通过 MongoDB 内置的广泛安全保护措施来预防。 您需要正确使用这些功能，我们的安全文档将帮助您做到这一点。[强调我的]”
MongoDB 并不是不安全，只是根本不安全。 问题实际上不在于产品，而在于那些急于通过云将物联网和移动应用程序送到消费者手中的人的糟糕做法。
云计算是导致不安全行为的催化剂
在数据中心（内部）中，存在着物理门（防火墙等）和操作门（流程和批准），软件在向世界发布并用于提供数据之前必须通过这些门。 从设计上来说，云具有更少的物理门，而且——不幸的是，它经常出现——在应用程序向全世界提供之前，需要通过的操作门也更少。 运营门槛的减少实际上就是“流氓 IT”或“影子 IT”概念的消失。 业务线利益相关者对于较长的交付周期和长达数年而不是数月的项目时间表感到沮丧，最初开始采用云计算来“绕过”IT。 但这意味着他们还要绕过已设置的操作门来确保这些applications的安全性和性能。
这不是云的问题，而是采用云的人的问题。 因为这不仅仅是十年来我们一直听到的“配置物理硬件花费的时间太长”的说法，而且“通过 IT 审批流程花费的时间太长”的说法也确实让那些只想在竞争对手之前进入市场的业务利益相关者感到沮丧。
2017 年 Arxan/IBM 赞助的移动和物联网安全调查的受访者证实了这一点。 受访者表示，应用程序开发团队面临的压力是造成物联网和移动应用程序安全性不佳的原因，其中 69% 的受访者指出，仓促开发移动应用程序是漏洞代码的根源，75% 的受访者认为，物联网应用程序也存在漏洞。
同样的压力还延伸到设置和保护数据库和云存储，这使得一切变得有用。 Cloud Pets 的整个前提不是建立在玩具上，而是建立在玩具通过互联网发送和接收数据的能力上。 这意味着它的成功取决于那些正在云端匆忙开发和部署的物联网应用程序之一，以便赶在圣诞节当天发布。
开发人员并不是唯一负责保护他们所交付的applications的人。 无论是谁负责提供支持该应用程序的云服务（无论是数据库、文件共享还是一般的应用服务），都必须承担部分安全责任。 商业利益相关者也应该设定不切实际的期限，并鼓励最终交付的最低限度的操作门槛。
是的，IT 必须接受数字化转型并简化运营环节，以便成功且安全地向消费者交付产品。 但企业和开发人员不能继续简单地避开云中的那些操作门槛，而让不仅消费者而且企业利益相关者面临依赖“默认”配置的劣质安全实践的风险。 这不仅仅与产品有关，还与流程有关；这是为了确保在将应用程序及其用户暴露于可预防的危害之前部署策略并正确配置。
如果您要避免令人尴尬的事件，您必须首先通过定义（和执行）至少一些在进入市场之前必须通过的基本操作门槛来设置一些基本的安全门槛。
组织比以往任何时候都更需要这些运营门户，因为支持生产力和利润的应用程序向公共云迁移的步伐正在加快。 并且随着迁移速度的加快，攻击者利用这些漏洞的机会也随之增加。