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

認証と認可

Dorisの権限管理システムは、MySQLの権限管理メカニズムをモデルにしています。行と列レベルでの詳細な権限制御、ロールベースのアクセス制御をサポートし、また許可リストメカニズムもサポートしています。

用語集

  1. User Identity

    権限システム内では、ユーザーはUser Identityとして識別されます。User Identityは2つの部分から構成されます:usernamehostusernameはユーザーの名前で、英文字(大文字と小文字の両方)から構成されます。hostはユーザー接続の送信元IPを表します。User Identityはusername@'host'として表現され、これはhostからのusernameを示します。

    User Identityのもう一つの表現はusername@['domain']で、ここでdomainはDNSを通じて一連のIPに解決可能なドメイン名を指します。最終的には、これは一連のusername@'host'として表現されるため、以降は統一してusername@'host'を用いて示します。

  2. Privilege

    権限はノード、データディレクトリ、データベース、またはテーブルに適用されます。異なる権限は異なる操作許可を表します。

  3. Role

    Dorisでは、カスタム名のロールを作成することができます。ロールは権限の集合として見ることができます。新しく作成されたユーザーにはロールを割り当てることができ、自動的にそのロールの権限を継承します。その後のロールの権限変更は、そのロールに関連付けられたすべてのユーザーの権限にも反映されます。

  4. User Property

    ユーザープロパティはユーザーに直接関連付けられており、User Identityには関連付けられていません。つまり、user@'192.%'user@['domain']の両方は同じユーザープロパティのセットを共有し、これらはユーザーuserに属し、user@'192.%'user@['domain']には属しません。

    ユーザープロパティには、ユーザーの最大接続数、インポートクラスター設定などが含まれますが、これらに限定されません。

認証と認可のフレームワーク

ユーザーがApache Dorisにログインするプロセスは2つの部分に分かれています:認証認可

  • 認証:ユーザーが提供する資格情報(ユーザー名、クライアントIP、パスワードなど)に基づいて本人確認を行います。確認後、個人ユーザーはシステム定義のUser Identityにマッピングされます。
  • 認可:取得したUser Identityに基づいて、そのUser Identityに関連付けられた権限に従って、ユーザーが意図した操作に必要な権限を持っているかどうかをチェックします。

認証

Dorisは組み込み認証スキームとLDAP認証をサポートしています。

Doris組み込み認証スキーム

認証は、Doris自体に格納されているユーザー名、パスワード、その他の情報に基づいて行われます。

管理者はCREATE USERコマンドでユーザーを作成し、SHOW ALL GRANTSコマンドで作成されたすべてのユーザーを表示できます。

ユーザーがログインする際、システムはユーザー名、パスワード、クライアントIPアドレスが正しいかどうかを検証します。

パスワードポリシー

Dorisは以下のパスワードポリシーをサポートして、ユーザーがより良いパスワード管理を行えるよう支援します。

  1. PASSWORD_HISTORY

    ユーザーが現在のパスワードをリセットする際に過去のパスワードを再利用できるかどうかを決定します。例えば、PASSWORD_HISTORY 10は過去10個のパスワードを新しいパスワードとして再利用できないことを意味します。PASSWORD_HISTORY DEFAULTを設定すると、グローバル変数PASSWORD_HISTORYの値を使用します。0に設定するとこの機能が無効になります。デフォルトは0です。

    例:

    • グローバル変数を設定:SET GLOBAL password_history = 10
    • ユーザーに設定:ALTER USER user1@'ip' PASSWORD_HISTORY 10
  2. PASSWORD_EXPIRE

    現在のユーザーのパスワードの有効期限を設定します。例えば、PASSWORD_EXPIRE INTERVAL 10 DAYはパスワードが10日後に期限切れになることを意味します。PASSWORD_EXPIRE NEVERはパスワードが期限切れにならないことを示します。PASSWORD_EXPIRE DEFAULTを設定すると、グローバル変数default_password_lifetime(日数)の値を使用します。デフォルトはNEVER(または0)で、期限切れにならないことを示します。

    例:

    • グローバル変数を設定:SET GLOBAL default_password_lifetime = 1
    • ユーザーに設定:ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY
  3. FAILED_LOGIN_ATTEMPTSPASSWORD_LOCK_TIME

    パスワードの誤った試行回数を設定し、その回数を超えるとユーザーアカウントがロックされ、ロック期間を設定します。例えば、FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1 DAYは3回誤ったログインがあった場合、アカウントが1日間ロックされることを意味します。管理者はALTER USER文を使用してアカウントのロックを解除できます。

    例:

    • ユーザーに設定:ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1 DAY
  4. パスワード強度

    これはグローバル変数validate_password_policyによって制御されます。デフォルトはNONE/0で、パスワード強度チェックを行わないことを意味します。STRONG/2に設定すると、パスワードは大文字、小文字、数字、特殊文字のうち少なくとも3つを含み、最低8文字の長さが必要です。

    例:

    • SET validate_password_policy=STRONG

詳細なヘルプについては、ALTER USERを参照してください。

認可

権限操作

  • ユーザー作成:CREATE USER
  • ユーザー変更:ALTER USER
  • ユーザー削除:DROP USER
  • 権限付与/ロール割り当て:GRANT
  • 権限取り消し/ロール撤回:REVOKE
  • ロール作成:CREATE ROLE
  • ロール削除:DROP ROLE
  • ロール変更:ALTER ROLE
  • 現在のユーザーの権限とロールを表示:SHOW GRANTS
  • すべてのユーザーの権限とロールを表示:SHOW ALL GRANTS
  • 作成されたロールを表示:SHOW ROLES
  • ユーザープロパティ設定:SET PROPERTY
  • ユーザープロパティ表示:SHOW PROPERTY
  • パスワード変更:SET PASSWORD
  • サポートされているすべての権限を表示:[SHOW PRIVILEGES]
  • 行ポリシーを表示:[SHOW ROW POLICY]
  • 行ポリシーを作成:[CREATE ROW POLICY]

権限の種類

Dorisは現在以下の権限をサポートしています:

  1. Node_priv

    ノード変更権限。FE、BE、BROKERノードの追加、削除、オフライン化を含みます。

    Rootユーザーはデフォルトでこの権限を持ちます。Grant_privNode_privの両方を持つユーザーは、この権限を他のユーザーに付与できます。

    この権限はGlobalレベルでのみ付与できます。

  2. Grant_priv

    権限変更権限。権限の付与、取り消し、ユーザー/ロールの追加/削除/変更を含む操作の実行を許可します。

    バージョン2.1.2より前では、他のユーザー/ロールに権限を付与する際、現在のユーザーは該当するレベルのGrant_priv権限のみが必要でした。バージョン2.1.2以降、現在のユーザーは付与したいリソースに対する権限も必要です。

    他のユーザーにロールを割り当てる際は、GlobalレベルのGrant_priv権限が必要です。

  3. Select_priv

    データディレクトリ、データベース、テーブルの読み取り専用権限。

  4. Load_priv

    データディレクトリ、データベース、テーブルの書き込み権限。Load、Insert、Deleteなどを含みます。

  5. Alter_priv

    データディレクトリ、データベース、テーブルの変更権限。ライブラリ/テーブルの名前変更、列の追加/削除/変更、パーティションの追加/削除などを含みます。

  6. Create_priv

    データディレクトリ、データベース、テーブル、ビューの作成権限。

  7. Drop_priv

    データディレクトリ、データベース、テーブル、ビューの削除権限。

  8. Usage_priv

    ResourcesとWorkload Groupsの使用権限。

  9. Show_view_priv

    SHOW CREATE VIEWを実行する権限。

権限レベル

Global権限

*.*.*スコープでGRANT文を通じて付与される権限。これらの権限は任意のカタログ内の任意のテーブルに適用されます。

Catalog権限

ctl.*.*スコープでGRANT文を通じて付与される権限。これらの権限は指定されたカタログ内の任意のテーブルに適用されます。

Database権限

ctl.db.*スコープでGRANT文を通じて付与される権限。これらの権限は指定されたデータベース内の任意のテーブルに適用されます。

Table権限

ctl.db.tblスコープでGRANT文を通じて付与される権限。これらの権限は指定されたテーブル内の任意の列に適用されます。

Column権限

列権限は主にテーブル内の特定の列に対するユーザーアクセスを制限するために使用されます。具体的には、列権限により管理者は特定の列に対する表示、編集、その他の権利を設定でき、特定の列データに対するユーザーのアクセスと操作を制御します。

テーブルの特定の列に対する権限はGRANT Select_priv(col1,col2) ON ctl.db.tbl TO user1で付与できます。

現在、列権限はSelect_privのみをサポートしています。

行レベル権限

Row Policiesにより、管理者はデータ内のフィールドに基づいてアクセスポリシーを定義でき、どのユーザーがどの行にアクセスできるかを制御します。

具体的には、Row Policiesにより管理者は、データに実際に格納されている値に基づいてユーザーの行アクセスをフィルタリングまたは制限できるルールを作成できます。

バージョン1.2から、行レベル権限はCREATE ROW POLICYコマンドで作成できます。

Usage権限

  • Resource権限

    Resource権限はResourceに特化して設定され、データベースやテーブルの権限とは無関係で、Usage_privGrant_privのみを割り当てることができます。

    すべてのResourcesに対する権限はGRANT USAGE_PRIV ON RESOURCE '%' TO user1で付与できます。

  • Workload Group権限

    Workload Group権限はWorkload Groupに特化して設定され、データベースやテーブルの権限とは無関係で、Usage_privGrant_privのみを割り当てることができます。

    すべてのWorkload Groupsに対する権限はGRANT USAGE_PRIV ON WORKLOAD GROUP '%' TO user1で付与できます。

データマスキング

データマスキングは、元のデータを変更、置換、または隠すことで機密データを保護する方法で、マスクされたデータは特定の形式と特性を保持しながらも、機密情報を含まなくなります。

例えば、管理者はクレジットカード番号やID番号などの機密フィールドの数字の一部またはすべてをアスタリスク*や他の文字に置き換える、または実名を偽名に置き換えることを選択できます。

Doris組み込み認可スキーム

Dorisの権限設計は、RBAC(Role-Based Access Control)モデルに基づいており、ユーザーはロールと関連付けられ、ロールは権限と関連付けられます。ユーザーはロールを通じて間接的に権限とリンクされます。

ロールが削除されると、ユーザーは自動的にそのロールに関連するすべての権限を失います。

ユーザーがロールから関連付けを解除されると、自動的にそのロールのすべての権限を失います。

ロールに権限が追加または削除されると、そのロールに関連付けられたユーザーの権限が相応に変更されます。

┌────────┐        ┌────────┐         ┌────────┐
│ user1 ├────┬───► role1 ├────┬────► priv1 │
└────────┘ │ └────────┘ │ └────────┘
│ │
│ │
│ ┌────────┐ │
│ │ role2 ├────┤
┌────────┐ │ └────────┘ │ ┌────────┐
│ user2 ├────┘ │ ┌─► priv2 │
└────────┘ │ │ └────────┘
┌────────┐ │ │
┌──────► role3 ├────┘ │
│ └────────┘ │
│ │
│ │
┌────────┐ │ ┌────────┐ │ ┌────────┐
│ userN ├─┴──────► roleN ├───────┴─► privN │
└────────┘ └────────┘ └────────┘

上記で示したとおり:

User1とuser2は両方ともrole1を通じて権限priv1を持っています。

UserNはrole3を通じて権限priv1を持ち、roleNを通じて権限priv2privNを持っています。そのため、userNは権限priv1priv2、およびprivNを同時に持っています。

ユーザー操作を簡単にするため、ユーザーに直接権限を付与することが可能です。内部的には、各ユーザーに対して一意のデフォルトロールが作成されます。ユーザーに権限が付与される場合、実質的にはユーザーのデフォルトロールに権限を付与しています。

デフォルトロールは削除できず、他の人に割り当てることもできません。ユーザーが削除される時、そのデフォルトロールも自動的に削除されます。

よくある質問

権限の説明

  1. ADMIN権限またはGLOBALレベルでGRANT権限を持つユーザーは、以下の操作を実行できます:

    • CREATE USER
    • DROP USER
    • ALTER USER
    • SHOW GRANTS
    • CREATE ROLE
    • DROP ROLE
    • ALTER ROLE
    • SHOW ROLES
    • SHOW PROPERTY FOR USER
  2. GRANT/REVOKE

    • ADMIN権限を持つユーザーは、任意のユーザーに対して権限を付与または取り消すことができます。
    • ADMINまたはGLOBALレベルのGRANT権限を持つユーザーは、ユーザーにロールを割り当てることができます。
    • 対応するレベルのGRANT権限と割り当てられる権限を持つユーザーは、それらの権限をユーザー/ロールに配布できます。
  3. SET PASSWORD

    • ADMIN権限またはGLOBALレベルのGRANT権限を持つユーザーは、非rootユーザーのパスワードを設定できます。
    • 一般ユーザーは、対応するUser Identityのパスワードを設定できます。対応するUser IdentityはSELECT CURRENT_USER()コマンドで確認できます。
    • ROOTユーザーは自身のパスワードを変更できます。

追加情報

  1. Dorisが初期化される時、以下のユーザーとロールが自動的に作成されます:

    • operatorロール:このロールはNode_privAdmin_priv、すなわちDorisの全ての権限を持ちます。
    • adminロール:このロールはAdmin_priv、すなわちノード変更を除く全ての権限を持ちます。
    • root@'%':rootユーザー、任意のノードからのログインが許可され、operatorロールを持ちます。
    • admin@'%':adminユーザー、任意のノードからのログインが許可され、adminロールを持ちます。
  2. デフォルトで作成されたユーザー、ロール、またはユーザーの権限の削除や変更はサポートされていません。

    • ユーザーroot@'%'とadmin@'%'の削除はサポートされていませんが、root@'xxx'とadmin@'xxx'ユーザー(xxxは%以外の任意のホストを指す)の作成と削除は許可されています(Dorisはこれらのユーザーを一般ユーザーとして扱います)。
    • root@'%'とadmin@'%'のデフォルトロールの取り消しはサポートされていません。
    • ロールoperatorとadminの削除はサポートされていません。
    • ロールoperatorとadminの権限の変更はサポートされていません。
  3. operatorロールを持つユーザーはRootのみです。adminロールを持つユーザーは複数存在できます。

  4. 潜在的に競合する可能性のある操作について、以下で説明します:

    1. ドメインとIPの競合:

      以下のユーザーが作成されたとします:

      CREATE USER user1@['domain'];

      そして付与されたとします:

      GRANT SELECT_PRIV ON *.* TO user1@['domain']

      このドメインはip1とip2の2つのIPに解決されます。

      後で、user1@'ip1'に個別の権限を付与するとします:

      GRANT ALTER_PRIV ON . TO user1@'ip1';

      するとuser1@'ip1'はSelect_privとAlter_privの両方の権限を持つことになります。そして再びuser1@['domain']の権限を変更しても、user1@'ip1'はその変更に従いません。

    2. 重複IPの競合:

      以下のユーザーが作成されたとします:

      CREATE USER user1@'%' IDENTIFIED BY "12345";
      CREATE USER user1@'192.%' IDENTIFIED BY "abcde";

優先度の観点から、'192.%''%'より優先されるため、マシン192.168.1.1からユーザーuser1がパスワード'12345'を使ってDorisにログインしようとすると、アクセスは拒否されます。

  1. パスワードを忘れた場合

    パスワードを忘れてDorisにログインできない場合、FEの設定ファイルにskip_localhost_auth_check=trueを追加してFEを再起動することで、ローカルマシンからパスワードなしでrootとしてDorisにログインできます。

    ログイン後、SET PASSWORDコマンドを使ってパスワードをリセットできます。

  2. rootユーザー自身以外は、rootユーザーのパスワードをリセットできません。

  3. Admin_priv権限は、GLOBALレベルでのみ付与または取り消しができます。

  4. current_user()user()

    ユーザーはSELECT current_user()SELECT user()をそれぞれ実行することで、自分のcurrent_useruserを確認できます。ここで、current_userはユーザーが認証されたアイデンティティを示し、userは現時点での実際のUser Identityです。

    例:

    user1@'192.%'が作成され、その後ユーザーuser1192.168.10.1からログインした場合、current_useruser1@'192.%'となり、useruser1@'192.168.10.1'となります。

    すべての権限は特定のcurrent_userに付与され、実際のユーザーは対応するcurrent_userのすべての権限を持ちます。

ベストプラクティス

以下は、Doris権限システムのユースケース例です。

  1. シナリオ1

    Dorisクラスターのユーザーは、管理者(Admin)、開発エンジニア(RD)、ユーザー(Client)に分けられます。管理者はクラスター全体に対するすべての権限を持ち、主にクラスターのセットアップとノード管理を担当します。開発エンジニアは、データベースとテーブルの作成、データのインポートと変更を含むビジネスモデリングを担当します。ユーザーは異なるデータベースとテーブルにアクセスしてデータを取得します。

    このシナリオでは、管理者にはADMINまたはGRANT権限を付与できます。RDには任意または特定のデータベースとテーブルに対するCREATE、DROP、ALTER、LOAD、SELECT権限を付与できます。ClientsにはAnyまたは特定のデータベースとテーブルに対するSELECT権限を付与できます。さらに、複数のユーザーに対する認可プロセスを簡素化するため、異なるロールを作成できます。

  2. シナリオ2

    クラスターには複数のビジネスが含まれ、それぞれが1つ以上のデータセットを使用する可能性があります。各ビジネスは独自のユーザーを管理する必要があります。このシナリオでは、管理ユーザーが各データベースに対してDATABASEレベルのGRANT権限を持つユーザーを作成できます。このユーザーは指定されたデータベースに対してのみユーザーを認可できます。

  3. ブロックリスト

    Doris自体はブロックリストをサポートせず、許可リストのみですが、特定の方法でブロックリストをシミュレートできます。user@'192.%'という名前のユーザーが作成され、192.*からのユーザーのログインを許可しているとします。192.168.10.1からのユーザーのログインを禁止したい場合、新しいパスワードで別のユーザーcmy@'192.168.10.1'を作成できます。192.168.10.1192.%より高い優先度を持つため、192.168.10.1からのユーザーは古いパスワードでログインできなくなります。