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