Orca Security對主要云基礎設施的分析揭示了廣泛存在的已知漏洞工具、暴露的AI模型和數據、配置錯誤的系統以及未加密的數據——這些問題都源于企業為了快速利用AI而導致的安全疏忽。

對托管在主要云提供商基礎設施上的資產進行的安全分析顯示，許多公司在匆忙構建和部署AI應用程序時，留下了安全漏洞。常見的問題包括AI相關服務使用默認且可能不安全的設置、部署存在漏洞的AI包，以及未遵循安全加固指南。

Orca Security的研究人員掃描了2024年1月至8月間托管在AWS、Azure、Google Cloud、Oracle Cloud和Alibaba Cloud上的數十億資產的工作負載和配置數據。研究結果發現：暴露的API訪問密鑰、暴露的AI模型和訓練數據、權限過多的訪問角色和用戶、配置錯誤、缺乏靜態數據和傳輸數據的加密、使用已知漏洞工具等。

“AI開發的速度持續加快，AI創新引入了更多強調易用性而非安全性的功能，”Orca的研究人員在他們的2024年《AI安全狀態報告》中寫道?！靶路胀瞥鰰r，資源配置錯誤往往隨之而來。用戶常常忽視正確配置與角色、存儲桶、用戶及其他資產相關的設置，從而為環境引入了重大風險?！?/p>

AI工具的采用：快速、廣泛且有些草率

根據Orca的分析，在被測試的云資產中，超過一半(56%)的企業已采用AI模型來構建特定用途的應用程序，這通常意味著使用云服務來訪問AI模型、部署本地模型及其訓練數據、部署相關的存儲桶，或使用特定的機器學習工具。

最受歡迎的服務是Azure OpenAI，39%的使用微軟Azure的企業采用了這一服務。在使用AWS的企業中，29%部署了Amazon SageMaker，11%使用了Amazon Bedrock。在使用Google Cloud的企業中，24%選擇了Google Vertex AI。

在模型的受歡迎程度上，GPT-35被79%采用AI的企業使用，其次是Ada(60%)、GPT-4o(56%)、GPT-4(55%)、DALL-E(40%)和WHISPER(14%)，其他模型如CURIE、LLAMA和Davinci的使用率都低于10%。

用于自動化創建、訓練和部署AI模型的熱門包包括Python scikit-learn、Natural Language Toolkit(NLTK)、PyTorch、TensorFlow、Transformers、LangChain、CUDA、Keras、PyTorch Lighting和Streamlit。大約62%的企業使用了至少一個包含未修補漏洞的機器學習包。

盡管未修補版本的數量很大，但發現的大多數漏洞風險屬于低到中等，最高的嚴重性評分為10分中的6.9，且只有0.2%的漏洞有已發布的攻擊利用程序。研究人員推測，這可能是企業沒有急于修補漏洞的原因之一，同時也擔心修補可能會破壞兼容性。

“值得注意的是，即使是低或中等風險的CVE，如果它們是高嚴重性攻擊路徑的一部分——一系列相互關聯的風險，攻擊者可以利用它們來危害高價值資產——也可能構成重大風險，”研究人員寫道。

不安全的配置可能暴露模型和數據

暴露機器學習模型的代碼或相關訓練數據可能導致各種AI特定攻擊，包括數據投毒、模型傾斜、模型逆向工程、模型投毒、輸入操控，以及AI供應鏈的妥協，其中庫或整個模型被替換為惡意版本。

攻擊者可能試圖通過威脅泄露企業的機器學習模型或專有數據來勒索公司，或者加密這些數據以造成停機。訓練AI模型的系統通常具有強大的計算能力，因此攻擊者可能會利用這些系統來部署加密貨幣挖礦惡意軟件。

例如，Jupyter Notebook(一個用于機器學習和數據可視化的開源計算平臺)的不安全部署經常在加密貨幣挖礦活動中受到攻擊，這些實例通常部署在云服務上，如Amazon SageMaker。

今年早些時候，Aqua Security的研究人員發現了一種名為“shadow buckets”的攻擊技術，這是因為包括SageMaker在內的六個Amazon AWS服務創建了可以預測名稱的S3數據存儲桶。盡管AWS后來更改了SageMaker的行為，在新桶名稱中引入了隨機數，但45%的SageMaker桶仍具有可預測的名稱，這可能使其用戶暴露于此類攻擊之下。

企業還經常在代碼庫和提交歷史中暴露與AI相關的API訪問密鑰。根據Orca的報告，20%的企業暴露了OpenAI密鑰，35%暴露了Hugging Face機器學習平臺的API密鑰，13%暴露了Anthropic(Claude大型語言模型背后的AI公司)的API密鑰。

研究人員建議：“通過遵循最佳實踐來保護API密鑰，例如安全存儲密鑰、定期輪換密鑰、刪除未使用的密鑰、避免硬編碼密鑰，并使用秘密管理器來管理其使用?！?/p>

雖然大多數企業在云中運行AI工具時遵循最小權限原則，但仍有一些企業使用了權限過高的角色。例如，4%的Amazon SageMaker實例使用了具有管理員權限的IAM角色來部署筆記本實例，這是一種風險，因為未來任何這些服務中的漏洞都可能通過權限提升危及整個AWS賬戶。

企業也未能快速采用云服務提供商提供的安全改進。例如，Amazon的Instance Metadata Service(IMDS)允許實例安全交換元數據。IMDSv2相較于v1有顯著改進，使用基于會話的臨時身份驗證令牌，但大量SageMaker用戶(77%)尚未在其筆記本實例上啟用它。對于AWS EC2計算實例，Orca掃描的95%的企業尚未配置IMDSv2。

Azure OpenAI的私有端點功能是另一個例子，它保護云資源和AI服務之間傳輸中的通信。根據Orca的調查，三分之一的Azure OpenAI用戶尚未啟用私有端點。

大多數企業似乎并未利用云提供商提供的加密功能來使用自管理密鑰加密其AI數據，包括AWS的密鑰管理服務(KMS)、Google的客戶管理加密密鑰(CMEK)以及Azure的客戶管理密鑰(CMK)。

研究人員寫道：“雖然我們的分析并未確認企業是否通過其他方法加密了其數據，但選擇不使用自管理密鑰進行加密，增加了攻擊者可能利用暴露數據的潛在風險。”

大多數企業也未能更改不安全的默認配置。例如，在測試的企業中，98%未能在其部署在AWS SageMaker上的Jupyter Notebook實例中禁用root訪問權限，這意味著如果攻擊者獲得未經授權的訪問，他們可以訪問所有在這些實例中運行的模型和服務。

更安全AI的建議

Orca的研究人員指出，有幾個領域可以顯著改進，以保護AI模型和數據。首先，應審查所有默認設置，因為它們可能在生產環境中帶來安全風險。企業還應閱讀服務提供商和工具開發者提供的安全加固和最佳實踐文檔，并應用最嚴格的設置。

其次，與任何IT系統一樣，漏洞管理非常重要。機器學習框架和自動化工具應納入漏洞管理計劃，任何缺陷都應被映射并安排修復。

限制和控制對AI資產的網絡訪問可以幫助減少意外風險和漏洞，特別是因為這些系統相對較新，尚未經過廣泛測試，研究人員建議。同樣，限制這些環境內部的權限也有助于防止橫向移動的攻擊，一旦資產遭到破壞，內部的權限限制將起到保護作用。

最后，AI模型使用和處理的數據是非常寶貴的資產。因此，在不同服務和工具之間傳輸時，以及數據處于靜止狀態時，都應通過使用自管理加密密鑰進行保護，并確保這些密鑰得到充分的防護，以防止未經授權的訪問和盜竊。