应对 Copilot 在使用过程中的潜在安全风险与挑战
越来越多的企业正在使用 Copilot 和低代码平台，使员工（即使是那些技术专业知识很少或没有技术知识的员工）能够制作强大的 Copilot 和业务应用程序，以及处理大量数据。Zenity 的一份新报告《2024 年企业 Copilots 和低代码开发现状》发现，企业平均有大约 80,000 个应用程序和 Copilot 是在标准软件开发生命周期 （SDLC） 之外创建的。
这一发展带来了新的机遇，但也带来了新的风险。在这 80,000 个应用程序和 Copilot 中，大约有 50,000 个漏洞。该报告指出，这些应用程序和 Copilot 正在以惊人的速度发展。因此，它们正在制造大量漏洞。
通常，软件开发人员会按照定义的 SDLC（安全开发生命周期）仔细构建应用程序，其中每个应用程序都会不断被设计、部署、测量和分析。但今天，这些护栏已不复存在。没有开发经验的人现在可以在 Power Platform、Microsoft Copilot、OpenAI、ServiceNow、Salesforce、UiPath、Zapier 等中构建和使用高性能的 Copilot 和业务应用程序。这些应用程序在传输和存储敏感数据时有助于业务运营。这一领域的增长非常显著;该报告发现，低代码开发和 Copilot 的采用率同比增长了 39%。
由于绕过了 SDLC，漏洞无处不在。许多企业热情地接受这些功能，却没有充分认识到他们需要掌握正在创建的 copilot 和应用程序的数量以及他们的业务环境这一事实。例如，他们需要了解应用程序和 copilot 的用途、应用程序与哪些数据交互以及他们的商业目的是什么。他们还需要知道谁在开发它们。由于他们通常不会这样做，并且由于绕过了标准开发实践，这创造了一种新形式的影子 IT。
这使得安全团队处于困难的境地，因为各种 LoB 中的业务用户在他们不知情的情况下构建了大量的副驾驶、应用程序、自动化和报告。该报告发现，所有 OWASP （Open Web Application Security Project） 前 10 大风险类别在整个企业中无处不在。平均而言，一个企业有 49,438 个漏洞。这意味着 62% 的 copilot 和应用程序通过低代码构建，其中包含某种安全漏洞。
Copilot 存在如此重大的潜在威胁，因为他们使用凭据、访问敏感数据并拥有难以遏制的内在好奇心。事实上，使用低代码平台构建的 Copilot 中有 63% 与他人过度共享，其中许多人接受未经身份验证的聊天。这为可能的即时注入攻击带来了很大的风险。
由于 copilot 的运作方式以及 AI 的一般运作方式，必须实施严格的安全措施，以防止最终用户与 copilot 共享交互、与太多或错误的人共享应用程序、通过 AI 不必要地授予对敏感数据的访问权限等。如果不采取这些措施，企业将面临数据泄露和恶意提示注入的风险增加。
另外两个重大风险是：
远程 Copilot 执行 （RCE） – 这些漏洞代表了特定于 AI 应用程序的攻击途径。此 RCE 版本使外部攻击者能够完全控制 M365 的 Copilot，并通过发送一封电子邮件、日历邀请或 Teams 消息来强制其服从其命令。
来宾帐户：攻击者只需使用一个来宾帐户和低代码平台的试用许可证（通常可通过多种工具免费获得），则只需登录企业的低代码平台或 Copilot。进入后，攻击者会切换到目标目录，然后在平台上拥有域管理员级别的权限。因此，攻击者会寻找这些来宾帐户，从而导致安全漏洞。以下数据点应该让企业领导者及其安全团队感到恐惧：典型的企业有超过 8,641 个不受信任的来宾用户实例，这些用户可以访问通过低代码和副驾驶开发的应用程序。
安全团队可以做些什么来应对这种无处不在、无定形的关键风险？他们需要确保他们已经实施了控制措施，以提醒他们注意任何在凭证检索过程中存在不安全步骤或硬编码密钥的应用程序。他们还必须为正在创建的任何应用程序添加上下文，以确保对于任何也可以访问敏感内部数据的业务关键型应用程序，都有适当的身份验证控制。
部署这些策略后，下一个优先事项是确保为需要访问敏感数据的应用程序设置适当的身份验证。之后，最佳实践是设置凭证，以便可以从凭证或机密文件库中安全地检索它们，这将保证密码不会以明文或纯文本形式存在。
低代码和 copilot 开发的精灵已经从瓶子里出来了，所以试图把它放回去是不现实的。相反，企业需要意识到风险并采取控制措施来确保其数据安全和适当管理。在这个以业务为导向的开发新时代，安全团队面临着许多挑战，但通过遵守上述建议，他们将处于最佳位置，以安全地将企业副驾驶和低代码开发平台提供的创新和生产力带入一个大胆的新未来。
发表评论