アクセス制御の概要

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 をデフォルトのベースラインとして使用します。

• アイデンティティプロバイダーのメンバーシップに従う必要があるチームベースのアクセスには、SCIM グループを推奨します。

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

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

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

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

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

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