共计 2616 个字符，预计需要花费 7 分钟才能阅读完成。
随着大型模型技术的日益成熟，越来越多企业踊跃尝试在外部利用这一前沿技术，上线各类翻新的 AI 利用，这标记着科技领域的一大飞跃。在这个发展趋势中，向量数据库凭借其弱小的数据反对，成为 RAG（Retrieval-Augmented Generation）、智能体等 AI 利用的关键技术。
然而，随着企业应用和数据的一直蓬勃增长以及多样化倒退，对于数据拜访的安全性需要也逐步升高。如何隔离不同我的项目、不同用户之间的数据和资源，使团队合作更加高效，成为许多企业面临的一项重要挑战。在这篇文章中，咱们将摸索 Zilliz Cloud 基于角色的访问控制及不同场景下的最佳实际。
01. 理解 Zilliz Cloud RBAC
Zilliz Cloud 的 RBAC（角色权限访问控制）性能提供了一种结构化和可扩大的办法来治理数据拜访权限，保障数据安全。RBAC 通过以下层面实现访问控制：用户账户、组织、我的项目。
其中，组织是将领有独特指标的多个我的项目汇聚在一起，例如，将某个特定业务单元下的所有我的项目整合在同一组织中。
在一个组织下，用户能够创立若干我的项目，并治理组织级别的资源，包含账单、组织成员、事件、零碎设置以及回收站等。
我的项目是组织外部用于归类集群和其余相干资源的逻辑分组单位。在一个我的项目中，你能够创立若干集群，并治理集群级别的资源，包含我的项目成员、API 密钥、平安设置和监控等。
02.Zilliz Cloud RBAC 是如何工作的？
Zilliz Cloud 权限设计遵循 RBAC 准则，分为管控层和数据层 2 层角色。在管控层，角色主持集群、我的项目、用户和账单等资源的操作权限，而在数据层，角色则专一于管制对 Cluster 数据的增、删、改、查的能力。
在管控层，Zilliz Cloud 反对 4 种角色（组织管理员、我的项目所有者和我的项目成员是 3 种罕用的角色）:
- 组织管理员：领有对组织的全副管理权限，包含组织设置、治理领取形式及账单、API Key、组织中的所有我的项目以及相干资源。
- 组织成员：在组织中具备无限的拜访权限，能够查看组织设置并邀请用户退出组织。组织成员对组织层面、我的项目层面和集群层面的资源的具体权限范畴由其在我的项目中的角色确定。
- 我的项目所有者：领有对我的项目的全副管理权限，包含我的项目设置、我的项目内的 API Key、我的项目内的所有集群以及相干资源。
- 我的项目成员：对我的项目内的所有集群具备读写权限，能够查看集群详情并治理 Collection 和 Index。
在数据层，Zilliz Cloud 提供了 3 种内建角色：Admin、Read-Only 和 Read-Write，用于管制对 Cluster 数据的读写和管理权限：
- Admin（管理员）：领有 Cluster 的最高权限，能够执行所有操作。
- Read-write（读写）：具备对 Cluster 数据进行读写的权限，实用于须要批改数据的场景。
- Read-only（只读）：具备对 Cluster 下所有数据进行只读拜访的权限，实用于只须要查看数据而不批改的场景。
然而，思考到特定业务需要，例如，只容许受权人员拜访敏感数据或者心愿应用 Collection 作为多租户隔离单元以确保安全隔离数据拜访，Zilliz Cloud 容许用户创立自定义角色。这些自定义角色可能定义对特定 Collection、Partition 或操作的权限，确保在应用 Zilliz Cloud 时实现数据权限最小化准则。
以上概述了 Zilliz Cloud 权限设计框架和多种角色，具体能力比照可参考（https://docs.zilliz.com.cn/docs/user-roles）。
03.Zilliz Cloud RBAC 的最佳实际
中小型团队协同的最佳实际
例如，你是公司的 infra 团队负责人，专一于运维向量数据库，以满足 3-5 个业务团队举荐、搜寻相干的 AI 利用需要，如电商、客服部门。
你心愿能够具备创立集群、执行扩缩容操作，同时反对所有集群用量监控能力，Infra 团队成员能够监控集群衰弱状态，对所有集群进行建表、数据删改；对于业务团队而言，他们冀望反对对 Collection 进行数据的增删改查，不同业务之间数据不可见；而财务共事则须要具备治理领取形式以及收取账单的能力。
针对这类场景，咱们举荐你将本人和财务共事设为 Zilliz Cloud 的组织管理员角色，将 Infra 团队成员邀请为我的项目成员角色。对于有数据隔离需要的电商、客服等业务，通过自定义角色，只需创立一个集群即可满足，进一步降低成本。
步骤如下：
- 首先，创立一个 Enterprise Plan 集群，通过 SDK 创立两个自定义角色，用于电商和客服，限定它们仅可能读写电商和客服相干的表。
- 其次，创立两个 Cluster 用户并与电商和客服自定义角色别离绑定。
- 最初，将集群 Endpoint 和 Cluster 用户名明码提供给业务团队，即满足数据操作的安全性和独立性。
企业知识库的最佳实际
例如，作为一家面向企业的 SaaS 服务提供商，你心愿推出知识库利用：容许用户上传常识文件，联合大模型进行智能问答。
在后盾，你打算将这些常识文件存储在向量数据库中。你的小型客户预计有 2 万家，其中单个客户的数据量绝对较小，不超过 10 万条；而你的大型客户大略有 50 个，他们的数据量较大，在千万到亿不等，对数据隔离和服务稳定性有严格的要求，心愿反对知识库数据的对外集成。
在这类场景下，你的客户无需登录 Zilliz Cloud，管控层的组织管理员和我的项目管理员均应设置在你的团队。
针对小型客户，咱们倡议创立共享集群以节省成本，雷同构造的文件，存储在同一个 Collection 下，每个客户以 Partition Key 做数据隔离，客户搜寻时，仅返回该 Partition Key 下的数据。
针对大型客户，倡议基于数据规模为不同客户创立不同规格的独立集群，满足隔离性。而后，为每个客户创立指定 Cluster 的 Custmized API Key，角色为 built-in Read-Write，以连贯专属集群，灵便满足各类内部利用的数据集成。
04. 论断
总结来看，Zilliz Cloud 基于角色的权限设计，为用户提供了高度灵便和精密的权限管制。联合自定义角色，无论是个人用户、小型企业，还是中大型企业的各类简单场景需要，Zilliz Cloud 都可能满足，欢送各位注册应用（https://cloud.zilliz.com.cn/signup）。
本文由 mdnice 多平台公布
