分析：云API的安全性及亟待解决的问题

作为负责该报告的工作组的三位联席主席之一，针对名单上的第四种威胁，我提出了很多问题，比如“不安全的接口和API”到底代表什么？

所涉及的风险有哪些？

以及组织如何去评估并确保这些云API？

在这篇文章中，我们将探讨云API的安全性，并解答这些亟待解决的问题。

定义不安全API所带来的风险

首先，对于那些对云API是什么以及云API如何使用不熟悉的人来说，云API本质上只是软件接口，云提供商利用云API，让用户管理云服务，典型的如基于标准的云API。API能够让许多常见的云计算进程变得容易，让更复杂的业务需求实现自动化，例如在多个供应商之间配置各种云，以及为云和内部部署系统应用第三方管理平台。

然而，云API特别关注云提供商和云客户。如《九宗罪》报告中所述，在保密性、完整性、可用性和可说明性等方面，不安全的云API会带来多种风险。虽然所有的云服务提供商都应该密切关注其API的安全性，但是因人而异。因此，了解如何分析云API的安全性是很重要的。

分析云提供商API的一个很好的起点，可以查看Gunnar Peterson的Web服务安全清单(PDF)，此清单提出了许多与CSA报告同类的问题。以下包括一些客户应该关注的主要领域：

●传输安全性。多数API都通过多种不同的渠道提供，但是需要交互或者携带敏感数据的API，应该通过安全的渠道加以保护，如SSL / TLS或IPSec。在云服务提供商(CSP)与客户之间建立IPSec通道可能很困难或者根本不可能，因此，建立SSL / TLS通道较容易实现。然而这又带来大量潜在问题，如必须用代理平台作为中间介质时，会出现内部或者(更常见的)外部证书授权的有效证书的生成与管理问题、平台服务的配置问题、软件集成和端到端的保护问题。

●身份验证与授权。许多云API主要关注身份验证和授权，因此对许多客户而言，这也是关键关注领域。咨询CSP的问题包括：API可以管理用户名和密码的加密吗？可以管理双因素身份认证属性吗？可以创建并维护细粒度的授权策略吗？内部身份管理系统和属性之间具有连续性吗？以及内部身份管理系统和云提供商提供的API扩展属性之间具有连续性吗？

●代码和开发实践。通过JSON和XML消息传送的，或者接受用户和应用程序输入的任何API，都必须经过标准注入式攻击和跨站请求伪造(CSRF)攻击、模式验证、输入和输出编码等的严格测试。

●消息保护。除了确保编码的生成遵循最佳实践以外， API主要考虑的其他因素包括消息结构、完整性验证、加密或编码。

如何确保云API的安全

一旦组织很好的掌握了不安全API带来的问题，就能够采取最佳措施确保云API。首先，通过云提供商的API文档，确定其API安全性，包括现有的应用评估结果和报告，这些都以 鉴证业务准则第16号报告(Statement on Standards for Attestation Engagements No.16)或其他报告的形式，展示了安全最佳实践和审计结果。Dasein云API就是开源性的且可扩展性的云API文档很好的例子。

除了文档外，客户应该向云提供商提出要求，即能够对API进行渗透测试和漏洞评估，或者云提供商自己完成这些测试，也可以通过第三方供应商完成这些测试，客户与潜在客户达成保密协议，因此客户能够评估安全实践。利用网络和应用控制的结合，以及良好的发展实践和QA测试，保护Web服务的API，防止开放式Web应用程序安全项目中，常见应用程序安全漏洞名单的前10种漏洞。

此外，许多云服务提供商为客户提供利用API的访问和身份验证机制的加密密钥。对于客户和云服务提供商来说，保护这些密钥都至关重要。

安全策略能够保证密钥的产生、传输、储存和处理的合理化，并且密钥应该安全地存储在硬件安全模块或其它加密保护的文件存储中。应该避免密钥嵌入到配置文件或其他脚本中，或者直接嵌入到代码中，因为这些情况会更新密钥，使密钥成为开发者和其他人的噩梦。

云服务提供商，如亚马逊和微软的Azure，包括基于散列的带有对称密钥的消息认证码，既具有完整性，又能避免通过不可信的网络传输共享的秘密。构建基于CSP的API的任何第三方都应遵循这一建议，像CSP那样重视密钥(和一般的API安全性)。

结论

随着云应用的开发和集成的发展，毫无疑问，云用户正面临着不安全API带来的严重威胁。可幸的是，供应商也面临同样的问题，这个问题将不会出现在下一代CSA热门威胁列表中。