上个月我写了 一篇文章 关于低代码/无代码平台提供凭证共享作为服务的方式，他们这样做的原因，以及这看起来如何 攻击者的视角. 在本文中，我将重点关注这种妥协的含义以及它如何影响当今的企业。
这就是为什么与其他人共享您的企业凭据是不好的做法的原因。 假设我想将我的凭据传递给一位同事，以便查询生产日志以进行一次性用户行为分析。 在典型的企业中，授予某人查询新数据源的权限可能意味着漫长的访问审查过程，尤其是在涉及生产或敏感数据时。 我的同事很容易感到沮丧。 “我只想做这个小小的一次性查询，我已经等了一个月了！” 他们可以说。 我可以为他们运行查询，但我被自己的日常任务淹没了，一次性查询往往会变得复杂。
我只剩下一个快速的解决方案：我可以与我的同事分享我的用户名/密码。 如果他们收到 MFA 挑战，我会很乐意批准。 我不必花时间运行查询，我的同事就会畅通无阻。 每个人都赢了！ 正确的？
好吧，你的分析是对的，但你错过了更大的图景。 虽然您的同事完成用户行为分析对企业很重要，但同样重要的是，您的企业必须遵守一系列隐私和安全标准，并通过维护公司对安全的承诺来维护客户信任.
如果高层企业目标不能说服您，请考虑 IT 或安全领域的中央管理团队。 这些团队的运营和安全策略基于每个用户都有自己独特的身份这一事实。 IT 团队正在设置网络和访问策略，假设每个用户将同时从一个公司 IP 或公司笔记本电脑登录； 安全团队正在根据用户 ID 关联事件； 财务团队可以汇总每个用户及其个人云环境的成本报告。 除其他外，凭证共享破坏了所有这些假设。 它剥夺了在线身份的基本含义。
一个真实的例子
让我们转向低代码/无代码的世界，并检查一个真实世界的场景。 在一家大型企业中，来自客户服务团队的受启发员工 Jane 意识到，当整个组织的员工参与客户案例时，他们通常会丢失有关客户的关键信息，例如他们的支持案例历史记录和最新购买。 这会降低客户的体验，因为他们必须一次又一次地解释他们的问题，同时将案例发送给能够解决问题的合适员工。
为了改进这一点，Jane 创建了一个应用程序，当公司员工是负责处理客户支持案例的团队的一员时，该应用程序允许公司员工查看有关客户的关键信息。 首先，让我们花点时间了解低代码/无代码的强大功能，它使 Jane 能够识别需求并自行解决，而无需询问预算或等待 IT 资源分配。
在构建应用程序时，Jane 必须解决多个问题，其中最大的问题是权限。 整个组织的员工没有直接访问权限来查询客户数据库以获取他们需要的信息。 如果他们这样做了，那么 Jane 就不必构建这个应用程序。 为了克服这个问题，Jane 登录到数据库并将她经过身份验证的会话直接嵌入到应用程序中。 当应用程序收到一个用户的请求时，它将使用 Jane 的身份执行该查询，然后将结果返回给用户。 这种凭证嵌入功能， 正如我们上个月探索的那样, 是低代码/无代码平台的一个关键特性。 Jane 确保在应用程序中设置基于角色的访问控制 (RBAC)，以便每个用户只能访问分配给他们的客户案例。
该应用程序解决了一个重要的业务问题，因此它很快获得了整个企业的用户采用。 人们很高兴他们可以通过正确的对话环境为客户提供更好的服务。 顾客也很高兴。 Jane 创建该应用程序一个月后，该应用程序已被整个组织的数百名用户使用，客户满意度不断提高。
与此同时，在 SOC 中，显示生产客户数据库周围异常活动的高严重性警报被触发并分配给经验丰富的安全分析师 Amy。 Amy 的初步调查显示，一名内部用户试图抓取整个数据库，从整个组织的多个 IP 地址查询有关多个客户的信息。 查询模式非常复杂； 与您期望在抓取数据库时看到的简单枚举模式不同，同一客户的数据被多次查询，有时通过不同的 IP 地址和不同的日期。 这可能是试图混淆安全监控系统的攻击者吗？
经过快速调查，Amy 发现了一条关键信息：所有 IP 地址和日期的所有查询都使用一个用户身份，即客户服务团队的 Jane。
艾米向简伸出手，问她发生了什么事。 起初，简不知道。 她的证件被盗了吗？ 她是否单击了错误的链接或相信了错误的传入电子邮件？ 但当简告诉艾米她最近构建的应用程序时，他们都意识到可能存在联系。 SOC 分析师 Amy 不熟悉低代码/无代码，因此他们联系了 AppSec 团队。 在 Jane 的帮助下，团队发现 Jane 的应用程序中嵌入了 Jane 的凭据。 从数据库的角度来看，没有应用程序——只有 Jane 执行了大量的查询。
Jane、Amy 和 AppSec 团队决定关闭应用程序，直到找到解决方案。 整个组织的应用程序用户都对依赖它感到沮丧，而客户也感受到了这一点。
虽然 Amy 结束了问题并记录了他们的发现，但客户服务副总裁看到客户满意度下降并不高兴，因此他们要求 Jane 寻找永久解决方案。 在平台的文档和组织的卓越中心团队的帮助下，Jane 从应用程序中删除了她的嵌入式身份，将应用程序更改为使用每个用户的身份来查询数据库，并确保用户只获得与他们相关联的客户案例的权限. 在其新的改进版本中，该应用程序使用每个用户的身份来查询客户数据库。 Jane 和应用程序用户对应用程序重新上线感到高兴，Amy 和 AppSec 团队对 Jane 的身份不再共享感到高兴，企业看到客户满意度再次开始攀升。 一切都好。
两周后，SOC 收到了另一个关于生产客户数据库异常访问的警报。 它看起来与同一数据库上的先前警报非常相似。 同样，来自整个组织的 IP 地址都使用单个用户的身份来查询数据库。 同样，该用户是 Jane。 但这一次，安全团队和 Jane 知道该应用程序使用了其用户的身份。 这是怎么回事？
调查显示，原来的应用程序有 隐式共享 Jane 与应用程序用户的经过身份验证的数据库会话。 通过与用户共享应用程序，该用户可以直接访问 地都，由低代码/无代码平台提供的经过身份验证的数据库会话的包装器。 使用该连接，用户可以直接利用经过身份验证的会话——他们不再需要通过应用程序。 事实证明，有几个用户发现了这一点，并认为这是预期的行为，他们正在使用 Jane 的经过身份验证的数据库会话来运行他们的查询。 他们喜欢这个解决方案，因为直接使用连接可以让他们完全访问数据库，而不仅仅是分配给他们的客户案例。
连接被删除，事件结束。 SOC 分析师联系了使用 Jane 连接的用户，以确保他们丢弃了他们存储的任何客户数据。
应对低代码/无代码安全挑战
上面的故事是来自一家跨国 B2C 公司的真实场景。 一些细节被省略或调整以保护隐私。 我们已经看到一个好心的员工如何在不知不觉中与其他用户共享他们的身份，从而在 IT、安全和业务中造成一系列问题。 正如我们上个月探讨的那样，凭证共享是低代码/无代码的一个关键特性。 这是常态，不是例外。
As 低代码/无代码在企业中持续开花，有意或无意，对于安全和 IT 团队来说，加入业务开发对话至关重要。 低代码/无代码应用程序带有 一系列独特的安全挑战，而且它们多产的性质意味着这些挑战变得比以往任何时候都快。
