如今各家雲廠商都通過給使用者提供API呼叫的方式來實現一些自動化編排方面的需求。為了解決呼叫API過程中的通訊加密和身份認證問題，大多數雲廠商會使用同一套技術方案—基於非對稱金鑰演算法的鑑權金鑰對，這裡的“金鑰對”即API憑證，是雲上使用者呼叫雲服務API、訪問雲上資源的唯一身份憑證。
在資訊保安領域有一個廣為認可的假定，即所有系統都是可攻破的，這裡的“攻破”是廣義的，可以是外部攻擊，也可以是惡意內部威脅（insider threat），當然也可能是無心洩漏導致的潛在威脅。API憑證（在阿里雲被稱為AccessKey）作為使用者訪問內部資源最重要的身份憑證，被外部人員惡意獲取或被內部員工無心洩露的案例時有發生，其導致的資料洩露非常嚴重，因此如何做好API憑證管理和監測就顯得非常重要。
一、API憑證的安全現狀
API憑證相當於登入密碼，只是使用場景不同。前者用於程式方式呼叫雲服務API，而後者用於登入控制檯。
在阿里雲，使用者可以使用AccessKey構造一個API請求（或者使用雲服務SDK）來操作資源。AccessKey包括AccessKeyId和AccessKeySecret。其中AccessKeyId用於標識使用者，AccessKeySecret是用來驗證使用者的金鑰。AccessKeySecret必須保密。在阿里雲，它們看起來像這個樣子：
（圖1）阿里雲AK樣式（圖1）阿里雲AK樣式
在大多數AK洩露的案例中，都是開發者不小心將自己的AccessKey提交到了任何人都可以訪問的公共程式碼託管平臺，導致安全防線毀於一旦。
筆者做了一個簡單的測試，在開原始碼託管網站Github上搜尋一些特定的關鍵字，可以看到搜尋結果近3萬條，稍微進一步查詢，就能發現某個使用者在專案裡將自己的AccessKey直接寫在程式碼中。
（圖2）洩漏的憑證（圖2）洩漏的憑證
筆者曾在不同的程式碼託管平臺搜尋了不同雲平臺的憑證格式，都能發現存在或多或少的憑證漏，這已經是一個普遍的安全問題。
北卡羅萊納州立大學的一篇研究報告則直接指出，“我們在涉及到的10萬開源專案中發現，憑證洩漏問題不是一次性偶然問題，而是每天都在發生的，有數千新的、不重複的機密憑證公佈到了網站”。
大家應該還記得，2018年波蘭某招聘網站被曝洩漏近千份使用者簡歷，內容包含郵件、照片、電話和職業生涯等隱私資訊。
（圖3）洩漏的簡歷（圖3）洩漏的簡歷
相比歷史上大型使用者密碼、信用卡資訊洩露之類的事件，這千份私人簡歷顯得有點微不足道。但是因為歐盟新出臺的GDPR政策，這類資料洩露可能會導致運營公司面臨數千萬歐元的罰款。更為嚴重的是，即使該公司加強在資料安全方面的建設，使用者也很難會繼續信任該網站，流失的使用者數造成的收入減少更是雪上加霜。
事後覆盤資料洩漏原因發現，正是因為該公司管理員不慎將雲伺服器的憑證配置不當，導致黑客未授權訪問到了其中一個儲存容器而造成的大範圍資料洩露。
從漏洞賞金獵人網站Hackerone公開的案例中筆者也能查詢到Grab、SnapChat、Starbucks、Uber、Yelp等著名網站也存在過憑證洩漏的問題。
（圖4）Hackerone上面公開的案例（圖4）Hackerone上面公開的案例
所幸這些問題被白帽黑客直接報告給了網站管理方，沒有造成事態進一步的惡化。由此可見，當業務發展到一定程度，在使用AccessKey的過程中極有可能會遇到類似的安全問題。
二、阿里雲安全中心實現AK安全自動化檢測閉環
作為國內最大的雲服務提供商，阿里雲率先和最大的開原始碼託管服務商Github合作，引入Token scan機制。
（圖5）Token scan流程（圖5）Token scan流程
整個流程完全自動化，可以實現高效且精準的檢測到在Github上洩漏的AccessKey。實際場景中，阿里雲能夠做到在含有AccessKey的程式碼提交到Github的數秒之內就通知使用者並且做出響應，儘可能減少對使用者產生的負面影響。
使用者可以在“雲安全中心—AK&賬密洩露檢測”模組中檢視到洩漏的詳情：
（圖6）AK洩漏檢測詳情（圖6）AK洩漏檢測詳情
在日常使用雲產品的過程中為了防患於未然，使用者也可以在“雲安全中心—雲安全最佳安全實踐”檢查當前雲產品的配置項：
- 確保雲產品的操作審計日誌處於開啟狀態，有助於分析是否有異常的呼叫行為。
- 確保使用Ram使用者的AK而不是主賬號AK，遵守最小許可權原則，一旦發生洩漏問題不至於失去整個雲賬號的控制許可權。
- 確保開啟MFA認證。有資料統計顯示，當開啟多因素
認證後能夠顯著降低因為密碼洩漏導致的未授權訪問。
（圖7）雲安全最佳實踐（圖7）雲安全最佳實踐
除了洩漏前的提前預防，在“雲安全中心—待處理告警—雲產品威脅檢測”中，系統將對使用者日常的業務呼叫基線做學習，在出現疑似黑客異常AK呼叫行為時進行告警，及時提醒使用者做出響應，做到洩漏後及時檢測。
（圖8）雲產品呼叫威脅檢測（圖8）雲產品呼叫威脅檢測
雲安全中心為了應對使用者不慎洩漏AccessKey造成惡劣影響，設計了全方位檢測理念，從洩漏前配置檢查——洩漏行為檢測——黑客異常呼叫三點完成檢測閉環，為使用者的雲上業務安全保駕護航。
（圖9）雲安全中心檢測理念（圖9）雲安全中心檢測理念
三、安全建議
除了上述的措施外，筆者還建議使用者在阿里雲產品使用過程中遵循以下幾點安全規範，從不同角度緩解憑證洩漏造成的影響：
不要將AccessKey嵌入程式碼中：嵌入程式碼中的憑證容易被人忽視，經驗豐富的開發者會將其寫入資料庫或者獨立的檔案中，使得其管理起來更方便。
- 定期輪換AccessKey：定期更新程式碼中存在的AccessKey能夠保證一些舊的程式碼洩漏出去後不會影響線上業務。
- 定期吊銷不需要的AccessKey：從控制檯可以看見最後一次AccessKey的訪問時間，記得把不用的AccessKey都禁用。
- 遵循最小許可權原則，使用RAM賬戶：根據不同業務需要授予不同子賬戶的讀寫許可權，給不同業務使用不同子賬戶的AccessKey。
- 開啟操作日誌審計，並將其投遞至OSS和SLS長期儲存和審計：將操作日誌存至OSS，遇到異常情況可以起到固證的作用，投遞至SLS可以在日誌量十分龐大的時候也能夠高效檢索。
上述措施對API憑證洩漏安全風險的防範和收斂有很大的效果，雖然具有一定的運維成本，但正是因為從一次次洩漏事故中我們看見了憑證洩漏對於一個企業的巨大傷害，相比這些鉅額的經濟損失，運維成本就顯得微不足道。希望各位讀者能夠提早發現風險，提早防範風險，安全的享受API給我們帶來的便利。
本文為雲棲社群原創內容，未經允許不得轉載。