▲圖一：保護(hù)API密鑰的Broker 模式

下面是處理API密鑰的常用辦法：

1、開發(fā)員用郵件發(fā)送API密鑰：企業(yè)通常用郵件把API密鑰發(fā)送給開發(fā)人員，而開發(fā)人員再將其復(fù)制粘貼到代碼中。這種松散的操作存在安全隱患因而應(yīng)盡量避免。此外，如果某開發(fā)員將API密鑰復(fù)制到代碼中，對(duì)新密鑰的請(qǐng)求會(huì)對(duì)代碼提出更換請(qǐng)求從而帶來額外的工作量。

2、配置文件：另一種常見情況是，開發(fā)員將API密鑰放在容易被找到的系統(tǒng)配置文件中。人們應(yīng)該將API密鑰與私人SSL密鑰同等對(duì)待。事實(shí)上，如果 API密鑰到了不法之徒手中，那么它比私有SSL密鑰的危害更大。例如，如果有人用企業(yè)API密鑰，那么企業(yè)要為其買單。解決辦法是將密鑰交給專門的安全網(wǎng)絡(luò)架構(gòu)。這就涉及云服務(wù)代理架構(gòu)，即通過代理產(chǎn)品管理API密鑰。

3、密鑰目錄：避免API管理的一個(gè)方法是部署與密鑰相關(guān)的明確的安全策略。理想情況下，這應(yīng)該屬于Corporate Security Policy的控制之下，實(shí)施明確的監(jiān)管和問責(zé)制度。這一方法的基礎(chǔ)是保留API密鑰的詳細(xì)目錄。雖然這類目錄有自己的優(yōu)勢(shì)，但是許多企業(yè)仍然要采用機(jī)動(dòng)方法來追蹤API密鑰。

這些企業(yè)應(yīng)該在開發(fā)API密鑰目錄時(shí)詢問下列問題：

a) 密鑰用來做什么，出于何種目的?

b) 誰對(duì)專屬密鑰負(fù)責(zé)?

c) 密鑰的使用有沒有有效期?有效期到來前如何通知用戶?過期密鑰有沒有明確的方案?以為呢密碼過期時(shí)可能造成大混亂。

該目錄可放到自己的加密Excel數(shù)據(jù)表或是數(shù)據(jù)庫中管理又或者是通過其他專用產(chǎn)品來管理。此方法的缺點(diǎn)是管理數(shù)據(jù)表或數(shù)據(jù)的時(shí)間會(huì)稍長，且會(huì)出現(xiàn)人為失誤。替換的方法是利用現(xiàn)成產(chǎn)品，如云服務(wù)代理。除了提供其他服務(wù)外，代理還可以讓企業(yè)輕松查看API密鑰的關(guān)鍵信息，包括識(shí)別誰應(yīng)對(duì)API負(fù)責(zé)，以及提供API的使用信息和有效期。

4、加密的文件存儲(chǔ)：更大的威脅出現(xiàn)在開發(fā)員試圖為API密鑰部署自己的安全策略時(shí)。例如，開發(fā)員知道應(yīng)保護(hù)API密鑰，而且會(huì)選擇將密鑰保存在難被找到的地方——有時(shí)是使用加密運(yùn)算法則或是將密鑰藏在文件或注冊(cè)表中。無疑剛開始的確會(huì)有人找不到這些密鑰藏匿處，但不久這些信息就會(huì)在企業(yè)內(nèi)公之于眾。這種錯(cuò)誤恰恰印證了“通過隱藏是無法獲得安全”的諺語。

總而言之，由于企業(yè)使用云服務(wù)的情況越來越多，因此這就可能出現(xiàn)API密鑰的使用太松散或是共享的情況。不論企業(yè)是選擇自己管理API密鑰還是使用現(xiàn)成產(chǎn)品管理，關(guān)鍵都是要保護(hù)好密鑰的存取和使用。

此處我們要鼓勵(lì)CIO和CSO們將API密鑰看作是與SSL私有密鑰地位等同的安全策略。建議把API密鑰視為敏感資源，因?yàn)樗鼈兛梢灾苯釉L問敏感信息。API密鑰的有效管理可以改善企業(yè)云安全，避免未授權(quán)的收費(fèi)或是敏感信息的泄露。

zhangcun