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安全状态报告》中写道。“新服务推出时，资源配置错误往往随之而来。用户常常忽视正确配置与角色、存储桶、用户及其他资产相关的设置，从而为环境引入了重大风险。”
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密钥，例如安全存储密钥、定期轮换密钥、删除未使用的密钥、避免硬编码密钥，并使用秘密管理器来管理其使用。”
虽然大多数企业在云中运行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模型使用和处理的数据是非常宝贵的资产。因此，在不同服务和工具之间传输时，以及数据处于静止状态时，都应通过使用自管理加密密钥进行保护，并确保这些密钥得到充分的防护，以防止未经授权的访问和盗窃。
