直面 Copilot 的安全风险

企业越来越多地使用 Copilot 和低代码平台，使得即使没有技术专长的员工也能创建强大的 Copilot 和业务应用，以及处理大量数据。Zenity 的一份新报告 2024 年企业 Copilot 和低代码开发现状 发现，平均而言，企业有大约 80,000 个应用和 Copilot 是在标准软件开发生命周期（SDLC）之外创建的。

这种发展带来了新的机会，但也带来了新的风险。在这 80,000 个应用和 Copilot 中，大约有 50,000 个漏洞。报告指出，这些应用和 Copilot 正在以极快的速度演变，因此它们正在创建大量的漏洞。

企业 Copilot 和应用的风险

通常，软件开发人员会仔细按照定义的 SDLC（安全开发生命周期）构建应用，每个应用都会不断被设计、部署、测量和分析。但是，如今，这些防护措施不再存在。没有开发经验的人现在可以在 Power Platform、Microsoft Copilot、OpenAI、ServiceNow、Salesforce、UiPath、Zapier 等平台上构建和使用高功率的 Copilot 和业务应用。这些应用帮助业务运营，因为它们传输和存储敏感数据。该领域的增长非常显著；报告发现，低代码开发和 Copilot 的采用率年增长率为 39%。

由于绕过了 SDLC，漏洞无处不在。许多企业热情地拥抱这些功能，而没有充分理解他们需要掌握正在创建的 Copilot 和应用的数量，以及它们的业务背景。例如，他们需要了解这些应用和 Copilot 是为谁设计的、它们与哪些数据交互以及它们的业务目的是什么。他们还需要知道谁正在开发它们。由于他们通常不知道，并且由于标准的开发实践被绕过，这就形成了一种新的影子 IT。

这使得安全团队面临着许多 Copilot、应用、自动化和报告被业务用户在各个 LoB 之外构建的困难处境。报告发现，所有 OWASP（开放网络应用安全项目）前 10 个风险类别 都遍布整个企业。平均而言，一个企业有 49,438 个漏洞。这意味着 62% 通过低代码构建的 Copilot 和应用包含某种安全漏洞。

了解不同类型的风险

Copilot 表现出如此显著的潜在威胁，因为它们使用凭据、访问敏感数据并具有内在的好奇心，使得它们难以控制。事实上，63% 使用低代码平台构建的 Copilot 与他人过度共享，并且其中许多 Copilot 接受未经身份验证的聊天。这使得可能的提示注入攻击风险很大。

由于 Copilot 的运行方式和 AI 一般的运行方式，必须施加严格的安全措施，以防止与 Copilot 的最终用户交互、与过多或错误的人共享应用、通过 AI 不必要地授予对敏感数据的访问权限等。如果这些措施不在位，企业将面临数据泄露和恶意提示注入的风险增加。

其他两个重大风险是：

远程 Copilot 执行（RCEs）- 这些漏洞代表了特定于 AI 应用的攻击路径。这种 RCE 版本可以让外部攻击者仅通过发送一封电子邮件、日历邀请或 Teams 消息，就可以完全控制 M365 的 Copilot 并强制它遵循他们的命令。

客座账户：使用仅一个客座账户和低代码平台的试用许可（通常可以在多个工具上免费获得），攻击者只需登录到企业的低代码平台或 Copilot。一旦进入，攻击者就可以切换到目标目录，并在平台上拥有域管理员级别的权限。因此，攻击者寻找这些客座账户，这导致了安全漏洞。以下是一个数据点，应该让企业领导者和他们的安全团队感到恐惧：典型的企业有超过 8,641 个不受信任的客座用户，可以访问通过低代码和 Copilot 开发的应用。

需要新的安全方法

安全团队可以对这种无处不在、模糊且关键的风险做什么？他们需要确保他们已经建立了控制措施，以便在应用的凭据检索过程中发现任何不安全的步骤或硬编码的秘密。他们还必须为正在创建的应用添加上下文，以确保对任何具有对敏感内部数据访问权限的业务关键应用实施适当的身份验证控制。

当这些策略被部署后，下一个优先事项是确保适当的身份验证被设置为需要访问敏感数据的应用。之后，最佳实践是设置凭据，以便它们可以从凭据或秘密存储中安全地检索，这将保证密码不会以明文或纯文本形式存储。

保障您的未来

低代码和 Copilot 开发的魔力已经出瓶，所以试图把它放回去是不现实的。相反，企业需要意识到风险，并建立控制措施以保持他们的数据安全和适当管理。安全团队在这个业务主导的开发新时代面临了许多挑战，但通过遵循上述建议，他们将处于最佳位置，以安全地将企业 Copilot 和低代码开发平台带来的创新和生产力推向一个大胆的新未来。