云滲透測試需采取不一樣的方法

大多數公司都遵循類似的安全防護模式：只要攻擊者調整攻擊技術，防御人員就必須重新考慮自己的安全策略。如今，隨著攻擊面不斷擴大，隨著網絡罪犯開始盯上云環境，企業不得不扛起確保自身云基礎設施安全的壓力。

在今年的線上ISC2安全大會上，Fugue聯合創始人兼首席技術官Josh Stella表示，很多企業依靠滲透測試來找出存在于自身系統中的安全漏洞，但這一過程并不是一成不變的。面對傳統的數據中心，滲透測試人員主要關心的是獲取網絡設備訪問權限，透過TCP/IP網絡突破防御邊界，最終觸及數據庫等企業寶貴資產。

Stella稱：“滲透測試在云技術方面有點滯后了。攻擊面已然發生了變化。” 

由于重點放在數據中心技術而非云策略上，滲透測試人員往往錯過了很多云漏洞。合規框架未囊括安全漏洞，DevOps和安全團隊也沒識別出安全漏洞。安全缺陷往往只有放在整個環境中才會顯露出來，所以只要沒有了解全局，就有可能漏掉這些缺陷。

以Uber數據泄露事件為例。這起發生在2016年的網絡安全事件導致全球5700萬用戶和美國60萬名司機的個人信息失泄。而原因據稱是攻擊者盜取憑證入手了Uber在GitHub上的私有代碼，并從中挖掘出了硬編碼到代碼中的AWS S3存儲桶登錄憑證。于是，攻擊者就能利用這些憑證登錄Uber的AWS賬戶并下載文件了。

Stella表示：“對黑客而言，利用目標在用的多個云服務來跨越邊界并不是什么罕見的攻擊手法。”攻擊者不利用網絡和操作系統漏洞，因為他們不靠此類漏洞就能侵入云環境。

攻擊者用來突破云環境的渠道往往是架構性問題或流程問題，而不是存在缺陷的軟件庫。雖然這些問題在云端確實存在，但相比數據中心環境還是不那么常見。云環境中的很多滲透測試都是四處收集并拼湊內容來形成數據泄露。

傳統攻擊模式中，攻擊者選好目標后再查找或制造漏洞來形成數據泄露。但云環境中的數據泄露大多不是這個路數。即便是重大攻擊也往往會采用全新的模式：攻擊者利用自動化技術查找漏洞（通常是云資源API錯誤配置），然后再選擇要突破的目標。

Stella解釋道：“無論是S3存儲桶還是你自己的什么東西，到你推上云端并做好配置的時候，攻擊者都會探測有無錯誤配置和漏洞。”通常，攻擊者會在數分鐘之內找到你的云資源。

棘手的S3問題

S3數據滲漏是太過普遍的企業常見問題，Uber事件已經凸顯出其危害，而且出于一系列原因，這個問題還十分棘手：大多數情況下，數據不會穿過任何客戶可訪問的網絡，所以數據泄露相當難檢測到。數據滲漏發生在客戶公司實際上無權訪問的云提供商網絡上；而公司可以訪問的事件日志則只會在數據已經失竊后才會反映出這一悲傷的事實。

所以企業應該尤為關注S3列表，因為這是攻擊者用得最趁手的工具之一。

Stella指出，“讀取”權限錯誤配置構成了危險云錯誤配置的主體，常被攻擊者用來執行資源發現操作。例如，2019年的Imperva數據泄露事件中，攻擊者就是從可通過互聯網訪問的內部系統中盜取了AWS API密鑰。事件發生后，Imperva采取措施加強了對快照訪問的審計，也就是仔細檢查允許“讀取”的IAM策略和角色關聯。企業應努力找出存有API密鑰的所有位置，因為這些位置就是攻擊者的目標所在。（編者注：在數世咨詢統計的年度大事記中，配置錯誤是信息泄露事件的主要原因之一）

Imperva還推行登錄憑證輪換并鞏固了憑證管理流程。這些舉措也是企業改善自身云安全態勢所必須做的。所有憑證都應該輪換，即使是安全控制往往相對較弱的開發和測試環境中的那些。

Stella補充道：“對于云黑客攻擊而言，開發和測試環境可能比生產環境還誘人，其熱門程度至少不亞于生產環境。之所以會出現這種現象，很大程度上是由于開發和測試環境中的安全控制更加寬松。”

審查供應商安全狀況時要問的問題，與面對滲透測試人員時應該問的那些問題都是一樣的。他們了解漏洞面和自身暴露情況嗎？有沒有打算測試控制平面API，尤其是這些API托管在云上的情況下？這是企業在鞏固自身云安全態勢時必須謹記的又一個方面：數據幾乎總是通過控制平面API流出云環境。