メインコンテンツまでスキップ

Overview of privileges

権限の概要

このトピックでは、StarRocksの権限システムの基本的な概念について説明します。権限は、どのユーザーがどのオブジェクトでどの操作を行うことができるかを決定し、データとリソースを細かく管理するためのセキュリティを高めることができます。

注意：このトピックで説明されている権限は、v3.0以降でのみ利用可能です。v3.0の権限フレームワークと構文は、以前のバージョンと後方互換性がありません。v3.0へのアップグレード後、特定の操作に関する以外のほとんどの元の権限は引き継がれます。詳細な違いについては、権限のサポートの[アップグレードノート]を参照してください。

StarRocksでは、次の2つの権限モデルが採用されています。

  • ロールベースのアクセス制御（RBAC）：権限はロールに割り当てられ、そのロールはユーザーに割り当てられます。この場合、権限はロールを介してユーザーに渡されます。
  • IDベースのアクセス制御（IBAC）：権限は直接ユーザーのIDに割り当てられます。

したがって、各ユーザーのIDの最大権限範囲は、自身の権限とこのユーザーのIDに割り当てられたロールの権限の結合です。

StarRocksの権限システムを理解するための基本的な概念：

  • オブジェクト：アクセスが許可されるエンティティです。グラントによって許可されない限り、アクセスは拒否されます。オブジェクトの例には、CATALOG、DATABASE、TABLE、VIEWなどがあります。詳細については、StarRocksでサポートされている権限を参照してください。
  • 権限：オブジェクトに対するアクセスレベルの定義です。複数の権限を使用して、オブジェクトに対して許可されるアクセスの細粒度を制御することができます。権限はオブジェクトごとに固有です。異なるオブジェクトには異なる権限があります。権限の例には、SELECT、ALTER、DROPなどがあります。
  • ユーザーID：ユーザーの固有のIDであり、権限を割り当てることができるエンティティでもあります。ユーザーIDはusername@'userhost'という形式で表され、ユーザー名とユーザーがログインするIPから構成されます。ユーザーIDを使用すると、属性の構成が簡素化されます。同じユーザー名を共有するユーザーIDは、同じ属性を共有します。ユーザー名に属性を設定した場合、この属性はこのユーザー名を共有するすべてのユーザーIDに適用されます。
  • ロール：権限を割り当てることができるエンティティです。ロールは権限の抽象的な集合体です。ロールはユーザーに割り当てることもできます。ロールは他のロールにも割り当てることができ、ロールの階層を作成することができます。データ管理を容易にするために、StarRocksはシステム定義のロールを提供しています。柔軟性を高めるために、ビジネスの要件に応じてカスタムのロールを作成することもできます。

以下の図は、RBACおよびIBACの権限モデルにおける権限管理の例を示しています。

これらのモデルでは、オブジェクトへのアクセスは、ロールとユーザーに割り当てられた権限を介して許可されます。ロールは他のロールまたはユーザーに割り当てることもできます。

権限管理

オブジェクトと権限​

オブジェクトは、関連する概念に関連する論理的な階層を持っています。たとえば、データベースはカタログに含まれ、テーブル、ビュー、マテリアライズドビュー、および関数はデータベースに含まれます。以下の図は、StarRocksシステムのオブジェクトの階層を示しています。

権限オブジェクト

各オブジェクトには、付与できる権限のセットがあります。これらの権限によって、これらのオブジェクト上で実行できる操作が定義されます。GRANTおよびREVOKEコマンドを使用して、権限をロールまたはユーザーに付与または取り消すことができます。

ユーザー​

ユーザーID​

StarRocksでは、各ユーザーは一意のユーザーIDによって識別されます。ユーザーIDは、IPアドレス（ユーザーホスト）とユーザー名からなり、「ユーザー名@'userhost'」の形式で表されます。StarRocksでは、異なるIPアドレスからログインした場合でも、同じユーザー名を持つユーザーを異なるユーザーIDとして識別します。例えば、「user1@'starrocks.com'」と「user1@'mirrorship.com'」は、2つの異なるユーザーIDです。

ユーザーIDの別の表現方法は「'domain'で構成されるusername @['domain']」です。ここで、「domain」はDNSで解決可能なドメイン名であり、一連のIPアドレスとして解決されます。username @['domain']は最終的にはusername@'userhost'のセットとして表されます。userhostの部分には%を使用して部分一致を行うことができます。userhostが指定されていない場合、デフォルトで'%'になります。つまり、同じ名前のユーザーが任意のホストからログインした場合でも、同じ名前のユーザーIDを持つユーザーです。

ユーザーへの権限の付与​

ユーザーは、権限やロールの両方を割り当てることができるエンティティです。各ユーザーIDの最大権限範囲は、自身の権限とこのユーザーIDに割り当てられたロールの権限の結合です。StarRocksは、各ユーザーが許可された操作のみを実行できるようにします。

ほとんどの場合、特権を渡すためにロールを使用することをお勧めします。たとえば、ロールを作成した後、そのロールに権限を付与し、次にユーザーにロールを割り当てることができます。一時的な特権や特別な特権を付与したい場合は、直接ユーザーに付与することもできます。これにより、特権の管理が簡素化され、柔軟性が向上します。

ロール​

ロールは権限を付与および取り消すことができるエンティティです。ロールは、必要なアクションを実行するためにユーザーに割り当てることができる権限のコレクションと見なすことができます。ユーザーは複数のロールを割り当てられるため、異なる権限のセットを使用して異なるアクションを実行できます。管理を簡素化するために、StarRocksではロールを介して権限を管理することをお勧めします。特別な一時的な権限は、ユーザーに直接付与することができます。

管理を容易にするために、StarRocksではいくつかのシステム定義のロールを提供しています。これらのロールには特定の権限が付与されており、日常の管理および保守の要件を満たすのに役立ちます。ビジネスの要件やセキュリティの要件に合わせて、カスタムロールも柔軟に作成できます。なお、システム定義のロールの権限範囲は変更できません。

ロールがアクティブになった後、ユーザーはそのロールによって許可された操作を実行できます。クラスターにログインする際に自動的にアクティブになるデフォルトロールを設定することができます。ユーザーは現在のセッションで所有するロールを手動でアクティブにすることもできます。

システム定義のロール​

StarRocksでは、いくつかのタイプのシステム定義のロールを提供しています。

ロール
  • root：グローバル権限を持っています。デフォルトでは、rootユーザーはrootロールを持っています。 StarRocksクラスターが作成されると、システムは自動的にルートユーザーをルート権限で生成します。ルートユーザーとロールはシステムのすべての権限を持っているため、後続の操作に対してリスクのある操作を防ぐために新しいユーザーとロールを作成することをお勧めします。ルートユーザーのパスワードを適切に管理してください。
  • cluster_admin：クラスター管理権限を持ち、ノードに関する操作（ノードの追加、削除など）を行うことができます。 cluster_adminはクラスターノードを追加、削除、および停止運用するための権限を持っています。cluster_adminまたはこのロールをデフォルトロールとして持つカスタムロールをユーザーに割り当てないようにすることをお勧めします。予期しないノードの変更を防ぐためです。
  • db_admin：カタログ、データベース、テーブル、ビュー、マテリアライズドビュー、関数、グローバル関数、リソースグループ、およびプラグインに対して、すべての操作を実行する権限を持ちます。
  • user_admin：ユーザーやロールに対する管理権限を持ちます。ユーザー、ロール、および権限を作成する権限を持ちます。上記のシステム定義のロールは、複雑なデータベースの権限を集約し、日常の管理を容易にするために設計されています。**上記のロールの権限範囲は変更できません。**また、特定の権限をすべてのユーザーに付与する必要がある場合、StarRocksはシステム定義のpublicロールも提供しています。
  • public：このロールはユーザーの所有物であり、任意のセッションでデフォルトでアクティブになります。publicロールはデフォルトではどの権限も持ちません。このロールの権限範囲を変更することができます。

カスタムロール​

ビジネスの要件に合わせてカスタムロールを作成し、その権限範囲を変更することができます。同時に、管理の便宜のためにロールを他のロールに割り当て、特権の階層と継承を作成することもできます。それによって、あるロールに関連する権限は別のロールによって継承されます。

ロールの階層と権限の継承​

次の図は、権限の継承の例を示しています。

注意：ロールの最大の継承レベルは16です。継承の関係は双方向にはできません。

ロールの継承

図に示すように、

  • role_sがrole_pに割り当てられています。role_pはrole_sのpriv_1を暗黙的に継承します。
  • role_pがrole_gに割り当てられています。role_gはrole_pのpriv_2とrole_sのpriv_1を暗黙的に継承します。
  • ロールがユーザーに割り当てられた後、ユーザーはこのロールの権限も持ちます。

アクティブなロール​

アクティブなロールは、ユーザーが現在のセッションでロールの権限を適用できるようにします。現在のセッションでアクティブなロールを表示するには、「SELECT CURRENT_ROLE();」を使用します。詳細については、current_roleを参照してください。

デフォルトのロール​

デフォルトのロールは、ユーザーがクラスターにログインしたときに自動的にアクティブになります。このデフォルトのロールは、1つまたは複数のユーザーが所有するロールである場合があります。管理者は、CREATE USERの「DEFAULT ROLE」キーワードを使用してデフォルトのロールを設定し、ALTER USERを使用してデフォルトのロールを変更できます。

ユーザーはSET DEFAULT ROLEを使用してデフォルトのロールを変更することもできます。

デフォルトのロールは、ユーザーに基本的な権限保護を提供します。たとえば、ユーザーAがrole_queryとrole_deleteを持っており、それぞれクエリと削除の権限を持っている場合、デフォルトのロールとしてrole_queryのみを使用することをお勧めします。これにより、DELETEやTRUNCATEなどのリスクのある操作によるデータの損失が防止されます。これらの操作を実行する必要がある場合は、アクティブなロールを手動で設定した後に行うことができます。

デフォルトロールを持たないユーザーは、自動的にpublicロールを持っています。クラスターにログインした後、このpublicロールが自動的にアクティブになります。

手動でロールをアクティブ化​

デフォルトロール以外に、ユーザーはセッション内で1つ以上の既存のロールを手動でアクティブにすることもできます。SHOW GRANTSを使用してアクティブ化できる権限とロールを表示し、SET ROLEを使用して現在のセッションで有効なアクティブなロールを設定します。

なお、SET ROLEコマンドは互いに上書きされます。たとえば、ユーザーがログインした後は、デフォルトでdefault_roleがアクティブになります。その後、ユーザーがSET ROLE role_sを実行すると、ユーザーはrole_sと自身の権限のみを持つことになります。default_roleは上書きされます。

参考​