只想着一直調用一直爽， 那API憑證泄漏風險如何破？

現在各家雲廠商都經過給用戶提供API調用的方式來實現一些自動化編排方面的需求。爲了解決調用API過程當中的通訊加密和身份認證問題，大多數雲廠商會使用同一套技術方案—基於非對稱密鑰算法的鑑權密鑰對，這裏的「密鑰對」即API憑證，是雲上用戶調用雲服務API、訪問雲上資源的惟一身份憑證。

在信息安全領域有一個廣爲承認的假定，即全部系統都是可攻破的，這裏的「攻破」是廣義的，能夠是外部攻擊，也能夠是惡意內部威脅（insider threat），固然也多是無意泄漏致使的潛在威脅。API憑證（在阿里雲被稱爲AccessKey）做爲用戶訪問內部資源最重要的身份憑證，被外部人員惡意獲取或被內部員工無意泄露的案例時有發生，其致使的數據泄露很是嚴重，所以如何作好API憑證管理和監測就顯得很是重要。

1、API憑證的安全現狀

API憑證至關於登陸密碼，只是使用場景不一樣。前者用於程序方式調用雲服務API，然後者用於登陸控制檯。

在阿里雲，用戶可使用AccessKey構造一個API請求（或者使用雲服務SDK）來操做資源。AccessKey包括AccessKeyId和AccessKeySecret。其中AccessKeyId用於標識用戶，AccessKeySecret是用來驗證用戶的密鑰。AccessKeySecret必須保密。在阿里雲，它們看起來像這個樣子：

（圖1）阿里雲AK樣式

在大多數AK泄露的案例中，都是開發者不當心將本身的AccessKey提交到了任何人均可以訪問的公共代碼託管平臺，致使安全防線毀於一旦。

筆者作了一個簡單的測試，在開源代碼託管網站Github上搜索一些特定的關鍵字，能夠看到搜索結果近3萬條，稍微進一步查找，就能發現某個用戶在項目裏將本身的AccessKey直接寫在代碼中。

（圖2）泄漏的憑證

筆者曾在不一樣的代碼託管平臺搜索了不一樣雲平臺的憑證格式，都能發現存在或多或少的憑證漏，這已是一個廣泛的安全問題。

北卡羅萊納州立大學的一篇研究報告則直接指出，「咱們在涉及到的10萬開源項目中發現，憑證泄漏問題不是一次性偶然問題，而是天天都在發生的，有數千新的、不重複的機密憑證公佈到了網站」。

你們應該還記得，2018年波蘭某招聘網站被曝泄漏近千份用戶簡歷，內容包含郵件、照片、電話和職業生涯等隱私信息。

（圖3）泄漏的簡歷

相比歷史上大型用戶密碼、信用卡信息泄露之類的事件，這千份私人簡歷顯得有點微不足道。可是由於歐盟新出臺的GDPR政策，這類數據泄露可能會致使運營公司面臨數千萬歐元的罰款。更爲嚴重的是，即便該公司增強在數據安全方面的建設，用戶也很難會繼續信任該網站，流失的用戶數形成的收入減小更是雪上加霜。

過後覆盤數據泄漏緣由發現，正是由於該公司管理員不慎將雲服務器的憑證配置不當，致使黑客未受權訪問到了其中一個存儲容器而形成的大範圍數據泄露。

從漏洞賞金獵人網站Hackerone公開的案例中筆者也能查詢到Grab、SnapChat、Starbucks、Uber、Yelp等著名網站也存在過憑證泄漏的問題。

（圖4）Hackerone上面公開的案例

所幸這些問題被白帽黑客直接報告給了網站管理方，沒有形成事態進一步的惡化。因而可知，當業務發展到必定程度，在使用AccessKey的過程當中極有可能會遇到相似的安全問題。

2、阿里雲安全中心實現AK安全自動化檢測閉環

做爲國內最大的雲服務提供商，阿里雲率先和最大的開源代碼託管服務商Github合做，引入Token scan機制。

（圖5）Token scan流程

​整個流程徹底自動化，能夠實現高效且精準的檢測到在Github上泄漏的AccessKey。實際場景中，阿里雲可以作到在含有AccessKey的代碼提交到Github的數秒以內就通知用戶而且作出響應，儘量減小對用戶產生的負面影響。

用戶能夠在「雲安全中心—AK&帳密泄露檢測」模塊中查看到泄漏的詳情：

（圖6）AK泄漏檢測詳情

在平常使用雲產品的過程當中爲了防患於未然，用戶也能夠在「雲安全中心—雲安全最佳安全實踐」檢查當前雲產品的配置項：

• 確保雲產品的操做審計日誌處於開啓狀態，有助於分析是否有異常的調用行爲。
• 確保使用Ram用戶的AK而不是主帳號AK，遵照最小權限原則，一旦發生泄漏問題不至於失去整個雲帳號的控制權限。
• 確保開啓MFA認證。有數據統計顯示，當開啓多因素
  認證後可以顯著下降由於密碼泄漏致使的未受權訪問。

（圖7）雲安全最佳實踐

除了泄漏前的提早預防，在「雲安全中心—待處理告警—雲產品威脅檢測」中，系統將對用戶平常的業務調用基線作學習，在出現疑似黑客異常AK調用行爲時進行告警，及時提醒用戶作出響應，作到泄漏後及時檢測。

（圖8）雲產品調用威脅檢測

雲安全中心爲了應對用戶不慎泄漏AccessKey形成惡劣影響，設計了全方位檢測理念，從泄漏前配置檢查——泄漏行爲檢測——黑客異常調用三點完成檢測閉環，爲用戶的雲上業務安全保駕護航。

（圖9）雲安全中心檢測理念

3、安全建議

除了上述的措施外，筆者還建議用戶在阿里雲產品使用過程當中遵循如下幾點安全規範，從不一樣角度緩解憑證泄漏形成的影響：

不要將AccessKey嵌入代碼中：嵌入代碼中的憑證容易被人忽視，經驗豐富的開發者會將其寫入數據庫或者獨立的文件中，使得其管理起來更方便。

• 按期輪換AccessKey：按期更新代碼中存在的AccessKey可以保證一些舊的代碼泄漏出去後不會影響線上業務。
• 按期吊銷不須要的AccessKey：從控制檯能夠看見最後一次AccessKey的訪問時間，記得把不用的AccessKey都禁用。
• 遵循最小權限原則，使用RAM帳戶：根據不一樣業務須要授予不一樣子帳戶的讀寫權限，給不一樣業務使用不一樣子帳戶的AccessKey。
• 開啓操做日誌審計，並將其投遞至OSS和SLS長期保存和審計：將操做日誌存至OSS，遇到異常狀況能夠起到固證的做用，投遞至SLS能夠在日誌量十分龐大的時候也可以高效檢索。

上述措施對API憑證泄漏安全風險的防範和收斂有很大的效果，雖然具備必定的運維成本，但正是由於從一次次泄漏事故中咱們看見了憑證泄漏對於一個企業的巨大傷害，相比這些鉅額的經濟損失，運維成本就顯得微不足道。但願各位讀者可以提前發現風險，提前防範風險，安全的享受API給咱們帶來的便利。

 

---

本文做者：雲安全專家

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。