企业急于接纳人工智能，忽视了安全强化

对主要云提供商基础设施上托管的资产的安全分析显示，许多公司为了急于构建和部署 AI 应用程序而打开安全弊端。常见的发现包括对 AI 干系服务利用默认且可能不安全的设置、部署易受攻击的 AI 软件包以及不遵循安全强化指南。
这项分析由 Orca Security 的研究人员进行，涉及在 1 月至 8 月期间扫描托管在 AWS、Azure、Google Cloud、Oracle Cloud 和阿里云上的数十亿资产的工作负载和设置数据。
研究人员的发现包括：袒露的 API 访问密钥、袒露的 AI 模型和训练数据、特权过高的访问脚色和用户、错误设置、静态和传输中数据缺乏加密、存在已知弊端的工具等等。
Orca 的研究人员在其2024 年人工智能安全状态报告中写道：“人工智能发展的速率不停加快，人工智能创新引入的功能更注重易用性，而非安全性。资源设置错误通常伴随着新服务的推出。用户忽视了与脚色、存储桶、用户和其他资产干系的准确设置设置，这会给环境带来庞大风险。”
人工智能工具的接纳：快速、广泛，但有点马虎
根据 Orca 的分析，凌驾一半（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、天然语言工具包 (NLTK)、PyTorch、TensorFlow、Transformers、LangChain、CUDA、Keras、PyTorch Lighting 和 Streamlit。约 62% 的组织利用了至少一个包罗未修补弊端的机器学习软件包。
只管未打补丁的版本数目浩繁，但发现的大多数弊端风险都较低到中等，最高严峻性评分为 6.9（满分 10 分），只有 0.2% 的弊端已发布弊端利用程序。研究人员推测，这种情况以及对兼容性粉碎的担忧可能是组织尚未急于修补这些弊端的原因。
研究人员写道：“值得留意的是，纵然是低风险或中等风险的 CVE，假如它们是高严峻性攻击路径的一部门，也可能构成严峻风险——高严峻性攻击路径是一系列相互关联的风险，攻击者可以利用这些风险来危及高价值资产。”
不安全的设置可能会袒露模型和数据
袒露机器学习模型或干系训练数据的代码可能会导致各种针对人工智能的攻击，包括数据中毒、模型扭曲、模型逆向工程、模型中毒、输入操纵以及人工智能供应链弊端，其中一个库或整个模型被恶意模型替换。
攻击者可能会威胁要公布机器学习模型或专有数据，以此勒索公司，大概加密数据以造成停机。训练人工智能模型的体系通常拥有强大的盘算能力，因此攻击者可能会利用这些体系部署加密钱币挖掘恶意软件。
例如，用于机器学习和数据可视化的开源盘算平台 Jupyter Notebook 的不安全部署经常在加密挖矿活动中受到攻击。这些实例通常部署在 Amazon SageMaker 等云服务上。
本年早些时候，Aqua Security 的研究人员发现了一种名为影子存储桶的攻击技术，这种攻击之所以可行，是因为包括 SageMaker 在内的六项 Amazon AWS 服务创建了可猜测名称的 S3 数据存储存储桶。只管 AWS 今后改变了 SageMaker 的行为，将随机数引入新的存储桶名称中，但 45% 的 SageMaker 存储桶仍旧具有可猜测的名称，可能会让用户遭受这种攻击。
组织还定期在代码存储库和提交历史记载中公开与 AI 干系的 API 访问密钥。根据 Orca 的报告，20% 的组织公开了 OpenAI 密钥，35% 的组织公开了 Hugging Face 机器学习平台的 API 密钥，13% 的组织公开了 Claude LLM 家族背后的 AI 公司 Anthropic 的 API 密钥。
研究人员发起：“遵循最佳实践来包管 API 密钥的安全，例如安全存储密钥、定期轮换密钥、删除未利用的密钥、制止硬编码密钥以及利用机密管理器来管理其利用情况。”
虽然大多数组织在云中运行 AI 工具时都遵循最小权限原则，但有些组织仍在利用权限过高的脚色。例如，4% 的 Amazon SageMaker 实例利用具有管理权限的 IAM 脚色来部署条记本实例。这是一种风险，因为这些服务中的任何将来弊端都可能因权限提升而危及整个 AWS 账户。
组织也不愿敏捷接纳其云服务提供商提供的安全改进。一个例子是亚马逊的实例元数据服务 (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 实例的根访问权限，这意味着假如攻击者获得对资产的未经授权的访问权限，他们就可以访问其中运行的全部模型和服务。
提高人工智能安全性的发起
Orca 研究人员确定了几个可以做出庞大改进以保护 AI 模型和数据的范畴。首先，应检查全部默认设置，因为它们可能会在生产环境中带来安全风险。组织还应阅读服务提供商和工具开辟人员提供的安全强化和最佳实践文档，并应用最严酷的设置。
其次，与任何 IT 体系一样，弊端管理非常紧张。机器学习框架和自动化工具应纳入弊端管理筹划，任何弊端都应被映射并安排修复。
研究人员发起，限定和控制对人工智能资产的网络访问有助于缓解不可预见的风险和弊端，尤其是因为其中许多体系相对较新且未经测试。限定这些环境内的权限以防止资产受到侵害时发生横向移动也是云云。
末了，AI 模型所依赖和采集的数据是一项非常宝贵的资产。因此，无论是在服务和工具之间传输，还是在静止状态下，都应该利用自我管理的加密密钥进行保护，以防未经授权的访问和偷窃。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。