アクセス制御の概要

Zilliz Cloud は、Zilliz Cloud 内のリソースへのアクセスをきめ細かく制御するために、ロールベースアクセス制御（RBAC）を実装しています。RBAC は、ユーザーに直接ではなくロールに対して権限を付与するセキュリティ対策です。リソースに対する特定の権限を含むロールをユーザーに付与することで、ユーザーのアクセス制御を効率的に管理できます。

Zilliz Cloud のアクセス制御モデルには、3つのレベルがあります。

• 組織レベル: 組織のメンバーシップ、組織ロール、請求へのアクセス、および SCIM 同期グループを管理します。

• プロジェクトレベル: プロジェクトのメンバーシップ、プロジェクトロール、およびクラスターなどのプロジェクトリソースへのアクセスを管理します。

• クラスターレベル: データベースユーザー、クラスターロール、およびデータベース、コレクション、その他のクラスターリソースに対するデータプレーン権限を管理します。

これらのレベルは連携して機能しますが、互いを置き換えるものではありません。ユーザーは、プロジェクトへのアクセス権がなくても組織にサインインできる場合があります。プロジェクトメンバーは、クラスター内のすべてのデータベース権限を自動的に持つことなく、プロジェクトリソースを管理できる場合があります。クラスターユーザーは、組織の管理者でなくてもデータの検索や挿入を行える場合があります。

アクセス制御の構成

Zilliz Cloud では、アクセス制御をプラットフォームアクセス（コントロールプレーン）とデータアクセス（データプレーン）に分離しています。

• プラットフォームアクセスは、Zilliz Cloud コンソールおよびコントロールプレーン API における組織レベルとプロジェクトレベルの操作を制御します。たとえば、メンバーの招待、請求の管理、プロジェクトの作成、クラスターの構成、プロジェクトレベルの権限の管理などです。

• データアクセスは、クラスター内の操作を制御します。たとえば、クラスターユーザーの作成、クラスターロールの作成、権限の付与、コレクションの作成、インデックスの構築、データの挿入、検索、クエリ、データの削除などです。

この分離により、チームは各担当業務に必要な最小限のアクセス権を付与できます。たとえば、財務担当のチームメンバーは請求へのアクセスは必要でも、クラスターデータへのアクセスは不要な場合があります。開発者は、1つのプロジェクトと1つのクラスターへのアクセスは必要でも、組織の管理権限は不要な場合があります。

組織レベルのアクセス

組織は、Zilliz Cloud アカウントへのアクセスにおける最上位の境界です。

以下は、Zilliz Cloud で組織レベルの RBAC を実装するためのワークフローです。

1

組織メンバーを招待する、または SCIM からグループを同期する。

2

メンバーまたはグループに事前定義された組織ロールを割り当てます。

各組織ロールには、割り当てられたメンバーまたはグループが組織レベルで実行できる操作を決定する、事前定義された権限セットが含まれています。

組織メンバーは、そのロールに含まれる権限を自動的に継承します。

プロジェクトレベルのアクセス

プロジェクトは、クラスターやプロジェクト固有のアクセスポリシーなどのクラウドリソースを整理するための主要な境界です。プロジェクトレベルのアクセスでは、誰がプロジェクトで作業できるか、およびプロジェクトリソースに対して何を実行できるかを制御します。

以下は、Zilliz Cloud でプロジェクトレベルの RBAC を実装するためのワークフローです。

1

カスタムプロジェクトロールを作成する、または事前定義されたプロジェクトロールを使用します。

各プロジェクトロールには、割り当てられたメンバーがプロジェクトレベルで実行できる操作を決定する、事前定義された権限セットが含まれています。

2

プロジェクトメンバーを招待し、ユーザーにプロジェクトロールを割り当てます。

プロジェクトメンバーは、そのロールに含まれる権限を自動的に継承します。

クラスターレベルのアクセス

クラスターレベルのアクセスは、クラスター内のデータプレーン権限を制御します。ここでは、クラスターユーザー、クラスターロール、権限、および権限グループを使用します。

プロジェクトアクセスとクラスターデータアクセスでは答える問いが異なるため、このレベルは重要です。

• プロジェクトアクセスの問い: 「このアカウントユーザーは、このプロジェクトとそのクラウドリソースを扱うことができますか？」

• クラスターアクセスの問い: 「このクラスターユーザーは、このデータベース、コレクション、またはクラスターリソースに対してこの操作を実行できますか？」

次の図は、Zilliz Cloud で RBAC を実装するための全体的なワークフローを示しています。

1

ユーザーを作成する: Zilliz Cloud のデフォルトユーザー db_admin に加えて、Web コンソールまたは SDK を使用して新しいユーザーを作成し、パスワードを設定することでデータセキュリティを保護できます。

2

ロールを作成する: Web コンソールから、または SDK を使用してカスタムロールを作成できます。ロールの具体的な機能は、そのロールに付与された権限によって決まります。

3

（オプション）権限グループを作成し、権限グループに権限を追加する: 複数の権限を 1つの権限グループにまとめることで、ロールに権限を付与するプロセスを効率化できます。Zilliz Cloud が提供する組み込みの権限グループに加えて、SDK を使用して独自のカスタム権限グループを作成することもできます。

4

ロールに権限または権限グループを付与する: このロールに権限または権限グループを付与することで、ロールの機能を定義します。現在、Web コンソールでロールに付与できるのは、組み込みの権限グループのみです。特定の権限またはカスタム権限グループをロールに付与するには、サポートチケットを作成したうえで、代わりに SDK を使用してください。

5

ユーザーにロールを付与する: 特定の権限を持つロールをユーザーに付与すると、ユーザーはロールの権限を利用できるようになります。1つのロールは複数のユーザーに付与できます。この手順は、Web コンソールまたは SDK を使用して実行できます。

有効なアクセス権の決定方法

ユーザーの有効なアクセス権とは、適用されるすべての割り当てから最終的に付与される権限の集合です。

実際には、次のようになります。

• 組織ロールは、ユーザーが組織レベルで実行できる操作を決定します。

• プロジェクトロールは、ユーザーが特定のプロジェクト内で実行できる操作を決定します。

• クラスターロールは、クラスターユーザーが特定のクラスター内で実行できる操作を決定します。

• グループベースの割り当てでは、同期されたグループに所属するユーザーに権限を追加できます。

• ユーザーへの直接割り当てとグループへの割り当ては組み合わされます。

ユーザーが複数のソースからアクセス権を付与されている場合、Zilliz Cloud はそれらの権限を組み合わせて評価する必要があります。たとえば、あるユーザーがプロジェクトへの Data Viewer アクセス権を直接付与されていて、さらに同じプロジェクトへの Data Operator アクセス権を持つ SCIM グループに所属している場合、そのユーザーの有効なアクセス権には、両方の割り当てによって付与された権限が含まれます。

アクセスパターンの例

• 財務ユーザー

  財務担当のチームメンバーは請求書を管理する必要がありますが、プロジェクトリソースやクラスターデータにアクセスする必要はありません。

  • ユーザーを組織に招待します。

  • Billing Admin を割り当てます。

  • ユーザーがプロジェクトへのアクセスも必要としない限り、プロジェクトロールを割り当てないでください。

  • ユーザーがデータプレーンへのアクセスも必要としない限り、クラスターユーザーを作成しないでください。

• プロジェクトオーナー

  チームリーダーは 1つのプロジェクトを所有し、ユーザー、ロール、クラスター、およびプロジェクトリソースを管理する必要があります。

  • ユーザーが組織のメンバーであることを確認します。

  • 対象のプロジェクトにユーザーを招待します。

  • そのプロジェクトに対して Project Admin を割り当てます。

  • ユーザーがクラスターに接続してデータプレーン操作を実行する必要もある場合にのみ、クラスターレベルのアクセスを付与してください。

• アプリケーションライター

  アプリケーションは本番クラスターでベクトルを挿入および更新する必要がありますが、組織やプロジェクトの設定を管理するべきではありません。

  • 本番クラスターが存在するプロジェクトを作成または特定します。

  • アプリケーションの認証情報の所有者に必要な、最小限のプロジェクトレベルのアクセス権のみを割り当てます。

  • アプリケーション用のクラスターユーザーを作成します。

  • 必要なデータベースまたはコレクションに対する書き込み権限を持つクラスターロールを作成または選択します。

  • そのクラスターロールをクラスターユーザーに付与します。

• 読み取り専用アナリスト

  アナリストはデータを検査またはクエリする必要がありますが、リソースを変更するべきではありません。

  • 対象のプロジェクトにユーザーを招待します。

  • Data Viewer または読み取り専用アクセス権を持つカスタムプロジェクトロールを割り当てます。

  • クラスターへの直接アクセスが必要な場合は、クラスターユーザーを作成し、読み取り専用のクラスターロールまたは必要なコレクションに限定したカスタムクラスターロールを割り当てます。

ベストプラクティス

• Org Owner は少数の管理者にのみ付与してください。

• 組織へのサインインのみが必要なユーザーには、デフォルトのベースラインとして Public を使用します。

• ID プロバイダーのメンバーシップに従うべきチーム単位のアクセスには、SCIM グループの使用を推奨します。

• プロジェクトロールを使用して、チーム間でプロジェクトの責務を分離します。

• 組み込みロールが実際の職務範囲よりも広い場合は、カスタムプロジェクトロールを作成します。

• データプレーン権限にはクラスターロールを使用します。特に、特定のデータベースやコレクションにアクセスを限定する必要がある場合に有効です。

• ユーザーが直接割り当てとグループベースの割り当ての両方を持つ場合は、有効なアクセス権を確認します。

• 可能な限り、人によるアクセスとアプリケーションによるアクセスを分離します。

• 定期的なアクセスレビューの一環として、古くなったユーザー、グループ、クラスターユーザーを削除します。