2011年，API密钥的重要性逐渐被意识到，各企业对全力保护这些密钥的认识也加深了。毕竟，API密钥与访问云中的敏感信息有着直接关联。如果一家企业的API密钥管理松散，那么企业就处于这些威胁之下：1.未验证用户使用密钥访问秘密信息;2。对费用支用拨款制服务的未授权访问可能形成巨额信用卡账单。

　　事实上，容易获取的API密钥意味着任何人都可以使用这些密钥，且能够在虚拟机上产生巨额费用。这类似于使用某人的信用卡然后进行未授权的消费。

　　API

　　如你所知，许多云服务都是通过简单的REST Web服务界面访问。通常我们将之称为API，因为它们与C++或VB中重量级API的概念类似。不过用户更易于在Web页面或移动手机上使用这些API。简而言之，API密钥是用来访问云服务的。Gartner公司的Darryl Plummer认为云技术要将各种服务综合起来。各公司想将本地运行的应用与云服务连接，将云服务与云服务连接。所有这些连接都应该是安全的，且其性能应得到监管。

　　显然API密钥控件是触及云服务重要内容的工具，但是这些密钥经常通过邮件发送或是保存在文件服务器中供多数人使用。例如，如果某企业正使用SaaS产品，如Gmail，他们通常回从Google获取API密钥。这一API密钥仅对该企业有效，且能让员工登录和访问公司邮箱。

　　如何保护API密钥?

　　API密钥必须当成密码和私人密钥一样保护。也就是说它们应该像文件一样保存在文件系统中，或是放在分析起来相对较容易的应用中。以Cloud Service Broker为例，API密钥以加密方式保存，使用Hardware Security Module (HSM)的时候，它提供了在硬件上保存API密钥的选项，因为HSM供应商包括：Sophos-Utimaco，nCipher，Thales，Safenet和Bull，现在支持材料存储而不仅仅是RSA/DSA密钥。安全的API密钥存储意味着操作人员可以将策略应用到密钥使用中。而且与隐私相关的准则与关键通信的保护到了一块。

▲图一：保护API密钥的Broker 模式

　　下面是处理API密钥的常用办法：

　　1、开发员用邮件发送API密钥：企业通常用邮件把API密钥发送给开发人员，而开发人员再将其复制粘贴到代码中。这种松散的操作存在安全隐患因而应尽量避免。此外，如果某开发员将API密钥复制到代码中，对新密钥的请求会对代码提出更换请求从而带来额外的工作量。

　　2、配置文件：另一种常见情况是，开发员将API密钥放在容易被找到的系统配置文件中。人们应该将API密钥与私人SSL密钥同等对待。事实上，如果API密钥到了不法之徒手中，那么它比私有SSL密钥的危害更大。例如，如果有人用企业API密钥，那么企业要为其买单。解决办法是将密钥交给专门的安全网络架构。这就涉及云服务代理架构，即通过代理产品管理API密钥。

　　3、密钥目录：避免API管理的一个方法是部署与密钥相关的明确的安全策略。理想情况下，这应该属于Corporate Security Policy的控制之下，实施明确的监管和问责制度。这一方法的基础是保留API密钥的详细目录。虽然这类目录有自己的优势，但是许多企业仍然要采用机动方法来追踪API密钥。

　　这些企业应该在开发API密钥目录时询问下列问题：

　　a) 密钥用来做什么，出于何种目的?

　　b) 谁对专属密钥负责?

　　c) 密钥的使用有没有有效期?有效期到来前如何通知用户?过期密钥有没有明确的方案?以为呢密码过期时可能造成大混乱。

　　该目录可放到自己的加密Excel数据表或是数据库中管理又或者是通过其他专用产品来管理。此方法的缺点是管理数据表或数据的时间会稍长，且会出现人为失误。替换的方法是利用现成产品，如云服务代理。除了提供其他服务外，代理还可以让企业轻松查看API密钥的关键信息，包括识别谁应对API负责，以及提供API的使用信息和有效期。

　　4、加密的文件存储：更大的威胁出现在开发员试图为API密钥部署自己的安全策略时。例如，开发员知道应保护API密钥，而且会选择将密钥保存在难被找到的地方——有时是使用加密运算法则或是将密钥藏在文件或注册表中。无疑刚开始的确会有人找不到这些密钥藏匿处，但不久这些信息就会在企业内公之于众。这种错误恰恰印证了“通过隐藏是无法获得安全”的谚语。

　　总而言之，由于企业使用云服务的情况越来越多，因此这就可能出现API密钥的使用太松散或是共享的情况。不论企业是选择自己管理API密钥还是使用现成产品管理，关键都是要保护好密钥的存取和使用。

　　此处我们要鼓励CIO和CSO们将API密钥看作是与SSL私有密钥地位等同的安全策略。建议把API密钥视为敏感资源，因为它们可以直接访问敏感信息。API密钥的有效管理可以改善企业云安全，避免未授权的收费或是敏感信息的泄露。