安全分析主要云提供商基础设施上托管的资产表明，许多公司正在急于构建和部署人工智能应用程序而打开安全漏洞。常见的发现包括对人工智能相关服务使用默认设置和可能不安全的设置、部署易受攻击的人工智能包以及不遵循安全强化指南。
该分析由 Orca Security 的研究人员执行，涉及扫描工作负载和配置1 月至 8 月期间托管在 AWS、Azure、Google Cloud、Oracle Cloud 和阿里云上的数十亿资产的数据。研究人员发现：暴露的 API 访问密钥、暴露的 AI 模型和训练数据、权限过高的访问角色和用户、配置错误、静态和传输中的数据缺乏加密、存在已知漏洞的工具等等。
根据 Orcas 分析，超过一半 (56%) 的云资产接受测试的组织已采用 AI 模型来为特定用例构建应用程序。这通常意味着使用提供对 AI 模型的访问的云服务、在本地部署模型以及训练数据、部署关联的存储桶或使用特定的机器学习工具。
最受欢迎的服务 Azure OpenAI 是39% 的组织使用 Microsoft Azure。在使用 AWS 的组织中，29% 部署了 Amazon SageMaker，11% 部署了 Amazon Bedrock。对于 Google Cloud，24% 的组织选择了 Google Vertex AI。
就模型流行度而言，79% 采用 AI 的组织使用 GPT-35，其次是 Ada（60%），GPT-4o (56%)、GPT-4 (55%)、DALL-E (40%) 和 WHISPER (14%)。其他模型，例如 CURIE、LLAMA 和 Davinci，使用率均低于 10%。
用于自动创建、训练和部署 AI 模型的流行软件包包括 Python scikit-learn、Natural Language工具包 (NLTK)、PyTorch、TensorFlow、Transformers、LangChain、CUDA、Keras、PyTorch Lighting 和 Streamlit。大约 62% 的组织至少使用了一个包含未修补漏洞的机器学习软件包。
尽管未修补版本数量较多，但发现的大多数漏洞都属于低到中风险，最高严重性评分为十分之 6.9 的人发布了漏洞利用程序，只有 0.2% 的人发布了该漏洞。研究人员推测，这一点以及对破坏兼容性的担忧可能是组织尚未急于修补它们的原因。
值得注意的是，即使是低风险或中等风险的 CVE，如果它们是 CVE 的一部分，也可能构成严重风险。研究人员写道，高严重性攻击路径是一系列相互关联的风险，攻击者可以利用这些风险来危及高价值资产。
暴露机器学习模型或相关训练数据的代码可能会引发各种特定于 AI 的攻击，包括数据中毒、模型倾斜、模型逆向工程、模型中毒、输入操纵以及图书馆或整个模型都被恶意模型所取代。
攻击者可能会通过威胁公开其机器学习模型或专有数据来勒索公司，或者他们可能会对数据进行加密以导致停机。训练人工智能模型的系统通常可以访问大量的计算机能力，因此攻击者可以破坏它们来部署加密货币挖掘恶意软件。
例如，用于机器学习的开源计算平台 Jupyter Notebook 的不安全部署和数据可视化，在加密货币挖矿活动中经常受到攻击。这些实例通常部署在 Amazon SageMaker 等云服务上。
今年早些时候，Aqua Security 的研究人员发现了一种名为“影子存储桶”的攻击技术，这种攻击技术之所以可行，是因为包括 SageMaker 在内的六种 Amazon AWS 服务创建了名为 S3 的内容。数据存储桶。尽管 AWS 此后改变了 SageMaker 的行为，在新的存储桶名称中引入了随机数，但 45% 的 SageMaker 存储桶仍然具有可预测的名称，可能使用户面临这种攻击。
组织还定期公开与 AI 相关的 API 访问代码存储库和提交历史记录中的密钥。根据 Orcas 报告，20% 的组织公开了 OpenAI 密钥，35% 的组织公开了 Hugging Face 机器学习平台的 API 密钥，13% 的组织公开了 Anthropic（Claude 大语言模型家族背后的人工智能公司）的 API 密钥。
虽然大多数组织都在云中运行人工智能工具时实践了最小特权原则，但有些组织仍然继续使用特权过高的角色。例如，4% 的 Amazon SageMaker 实例使用具有管理权限的 IAM 角色来部署笔记本实例。这是一种风险，因为这些服务中的任何未来漏洞都可能因权限升级而危及整个 AWS 帐户。
组织也不会很快采用其云服务提供商提供的安全改进措施。一个例子是 Amazon 实例元数据服务 (IMDS)，它使实例能够安全地交换元数据。IMDSv2 比 v1 提供了显着改进，具有基于会话的临时身份验证令牌，但大量 SageMaker 用户 (77%) 尚未为其笔记本实例启用它。对于 AWS EC2 计算实例，Orca 扫描的组织中有 95% 尚未配置 IMDSv2。
Azure OpenAI 中的专用端点功能是另一个例子，它可以保护云资源和 AI 服务之间的传输通信。根据 Orcas 的调查结果，三分之一的 Azure OpenAI 用户尚未启用专用端点。
大多数组织似乎没有利用云提供商提供的加密功能来使用自我管理的密钥加密其 AI 数据，包括AWS Key Management Service (KMS)、Google 客户管理的加密密钥 (CMEK) 和 Azure 客户管理的密钥 (CMK)。
虽然我们的分析未确认组织数据是否通过其他方法加密，但选择研究人员写道，不使用自我管理的密钥进行加密会增加潜在攻击者利用暴露数据的可能性。
大多数组织也无法更改不安全的默认配置。例如，98% 的测试组织未能禁用 AWS SageMaker 上部署的 Jupyter Notebook 实例的 root 访问权限，这意味着如果攻击者获得了对资产的未经授权的访问权限，则可以访问其中运行的所有模型和服务。
Orca 研究人员确定了可以进行重大改进以保护人工智能模型和数据的几个领域。首先，应审查所有默认设置，因为它们可能会在生产环境中带来安全风险。组织还应该阅读服务提供商和工具开发人员提供的安全强化和最佳实践文档，并应用最严格的设置。
其次，与任何 IT 系统一样，漏洞管理很重要。机器学习框架和自动化工具应包含在漏洞管理计划中，任何缺陷都应进行映射并计划进行修复。
限制和控制对人工智能资产的网络访问可以帮助减轻不可预见的风险和漏洞，特别是因为许多研究人员表示，其中一些系统相对较新且未经测试。同样的道理也适用于限制这些环境中的权限，以防止资产受到损害时的横向移动。
最后，人工智能模型构建和摄取的数据是一项非常有价值的资产。因此，它应该在服务和工具之间传输以及静态时受到保护，并使用自我管理的加密密钥进行保护，以防止未经授权的访问和盗窃。