アクセス制御の概要
Zilliz Cloud は、Zilliz Cloud 内のリソースへのアクセスを細かく制御するため、ロールベースアクセス制御（RBAC）を実装しています。RBAC は、特権をユーザーに直接付与するのではなく、ロールに対して付与するセキュリティ対策です。リソースに対する特定の特権を持つロールをユーザーに割り当てることで、ユーザーのアクセス制御を効率的に管理できます。
Zilliz Cloud のアクセス制御モデルは、以下の 3 つのレベルで構成されます。
-
組織レベル: 組織のメンバーシップ、組織ロール、課金アクセス、SCIM 同期グループを管理します。
-
プロジェクトレベル: プロジェクトのメンバーシップ、プロジェクトロール、クラスターなどのプロジェクトリソースへのアクセスを管理します。
-
クラスターレベル: データベースユーザー、クラスターロール、およびデータベース、コレクション、その他のクラスターリソースに対するデータプレーン権限を管理します。
これらのレベルは連携して機能しますが、互いに代替するものではありません。たとえば、ユーザーはプロジェクトへのアクセス権がなくても組織にサインインできる場合があります。また、プロジェクトメンバーはクラスター内のすべてのデータベース権限を自動的に持つことなく、プロジェクトリソースを管理できる場合があります。さらに、クラスターユーザーは組織管理者でなくてもデータの検索や挿入を行える場合があります。
アクセス制御の仕組み
Zilliz Cloud では、アクセス制御を プラットフォームアクセス（コントロールプレーン）と データアクセス（データプレーン）に分離しています。
-
プラットフォームアクセス は、Zilliz Cloud コンソールおよびコントロールプレーン API における組織レベルとプロジェクトレベルの操作を制御します。これには、メンバーの招待、課金の管理、プロジェクトの作成、クラスターの設定、プロジェクトレベルの権限管理などが含まれます。
-
データアクセス は、クラスター内での操作を制御します。具体的には、クラスターユーザーの作成、クラスターロールの作成、権限の付与、コレクションの作成、インデックスの構築、データの挿入・検索・クエリ・削除などです。
この分離により、チームは各担当業務に必要な最小限のアクセス権のみを付与できます。たとえば、財務担当者は課金アクセスのみが必要で、クラスターデータへのアクセスは不要な場合があります。また、開発者は特定のプロジェクトとクラスターへのアクセスのみが必要で、組織全体の管理権限は不要な場合があります。
組織レベルのアクセス
組織は、Zilliz Cloud アカウントアクセスにおける最上位の境界です。
Zilliz Cloud で組織レベルの RBAC を実装するためのワークフローは以下のとおりです。
組織メンバーを招待するか、SCIM からグループを同期します。
メンバーまたはグループに事前定義された組織ロールを割り当てます。
各組織ロールには事前定義された権限セットが含まれており、割り当てられたメンバーやグループが組織レベルで実行できる操作が定まります。
組織メンバーは、割り当てられたロールに含まれる権限を自動的に継承します。
プロジェクトレベルのアクセス
プロジェクトは、クラスターなどのクラウドリソースやプロジェクト固有のアクセスポリシーを整理するための主要な境界です。プロジェクトレベルのアクセス制御により、誰がプロジェクト内で作業でき、プロジェクトリソースに対してどのような操作を行えるかが決まります。
Zilliz Cloud でプロジェクトレベルの RBAC を実装するためのワークフローは以下のとおりです。
カスタムプロジェクトロールを作成するか、事前定義されたプロジェクトロールを使用します。
各プロジェクトロールには事前定義された権限セットが含まれており、割り当てられたメンバーがプロジェクトレベルで実行できる操作が定まります。
プロジェクトメンバーを招待し、プロジェクトロールを割り当てます。
プロジェクトメンバーは、割り当てられたロールに含まれる権限を自動的に継承します。
クラスターレベルのアクセス
クラスターレベルのアクセス制御は、クラスター内のデータプレーン権限を管理するもので、クラスターユーザー、クラスターロール、権限、権限グループを使用します。
このレベルが重要である理由は、プロジェクトアクセスとクラスターデータアクセスがそれぞれ異なる問いに対する答えを提供するためです。
-
プロジェクトアクセスは「このアカウントユーザーは、当該プロジェクトとそのクラウドリソースを操作できるか」という問いに答えます。
-
クラスターアクセスは「このクラスターユーザーは、当該データベース、コレクション、またはクラスターリソースに対して特定の操作を実行できるか」という問いに答えます。
次の図は、Zilliz Cloud で RBAC を実装するための一連のワークフローを示しています。
ロールへの権限または権限グループの付与: ロールに権限または権限グループを付与することで、そのロールの機能を定義します。現在、Web コンソールでは組み込みの権限グループのみをロールに付与できます。特定の権限やカスタム権限グループを付与する場合は、サポートチケットを作成した上で、SDK をご使用ください。
実効アクセスの決定机制
ユーザーの実効アクセスとは、適用されるすべての割り当てに基づいて最終的に付与される権限セットのことです。
具体的には以下のようになります。
-
組織ロールは、ユーザーが組織レベルで実行できる操作を決定します。
-
プロジェクトロールは、ユーザーが特定のプロジェクト内で実行できる操作を決定します。
-
クラスターロールは、クラスターユーザーが特定のクラスター内で実行できる操作を決定します。
-
グループベースの割り当てにより、同期されたグループに属するユーザーに追加の権限が付与される場合があります。
-
ユーザーへの直接割り当てとグループ割り当てによる権限は統合されます。
ユーザーが複数のソースからアクセス権を受け取る場合、Zilliz Cloud はそれらの権限を組み合わせて評価します。たとえば、あるユーザーがプロジェクトに対して Data Viewer アクセス権を直接付与されており、かつ同じプロジェクトに対して Data Operator アクセス権を持つ SCIM グループにも所属している場合、そのユーザーの実効アクセスには両方の割り当てによる権限が含まれます。
アクセスパターンの例
-
財務ユーザー
財務チームのメンバーは請求書の管理が必要ですが、プロジェクトリソースやクラスターデータへのアクセスは不要です。
-
ユーザーを組織に招待します。
-
Billing Admin を割り当てます。
-
プロジェクトへのアクセスも必要でない限り、プロジェクトロールは割り当てません。
-
データプレーンへのアクセスも必要でない限り、クラスターユーザーは作成しません。
-
-
プロジェクト所有者
チームリーダーは 1 つのプロジェクトを所有し、ユーザー、ロール、クラスター、プロジェクトリソースを管理する必要があります。
-
ユーザーが組織のメンバーであることを確認します。
-
ユーザーを対象のプロジェクトに招待します。
-
該当プロジェクトに対して Project Admin を割り当てます。
-
クラスターへの接続やデータプレーン操作の実行も必要な場合にのみ、クラスターレベルのアクセスを付与します。
-
-
アプリケーション書き込み担当
アプリケーションは本番クラスターでベクトルの挿入・更新を行う必要がありますが、組織やプロジェクトの設定を管理すべきではありません。
-
本番クラスターが存在するプロジェクトを作成または特定します。
-
アプリケーションの資格情報所有者に対して、必要な最小限のプロジェクトレベルアクセスのみを割り当てます。
-
アプリケーション用のクラスターユーザーを作成します。
-
対象のデータベースまたはコレクションへの書き込み権限を持つクラスターロールを作成または選択します。
-
そのクラスターロールをクラスターユーザーに付与します。
-
-
読み取り専用アナリスト
アナリストはデータの参照やクエリを実行する必要がありますが、リソースを変更すべきではありません。
-
ユーザーを対象のプロジェクトに招待します。
-
Data Viewer または読み取り専用アクセスを持つカスタムプロジェクトロールを割り当てます。
-
クラスターへの直接アクセスが必要な場合は、クラスターユーザーを作成し、読み取り専用のクラスターロール、または必要なコレクションに限定したカスタムクラスターロールを割り当てます。
-
ベストプラクティス
-
Org Owner は少数の管理者にのみ付与します。
-
組織へのサインインのみが必要なユーザーには、デフォルトのベースラインとして Public を使用します。
-
ID プロバイダーのメンバーシップに連動させるチーム単位のアクセスには、SCIM グループの使用を推奨します。
-
プロジェクトロールを使用して、チーム間でプロジェクトの責務を分離します。
-
組み込みロールが実際の職務範囲よりも広い場合は、カスタムプロジェクトロールを作成します。
-
データプレーンの権限管理にはクラスターロールを使用します。特に、アクセスを特定のデータベースやコレクションに限定する場合に有効です。
-
ユーザーに直接割り当てとグループベースの割り当ての両方がある場合は、実効アクセス権を確認します。
-
可能な限り、人間によるアクセスとアプリケーションによるアクセスを分離します。
-
定期的なアクセスレビューの一環として、使用されなくなったユーザー、グループ、クラスターユーザーを削除します。