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

認証と認可

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

用語集​

  1. User Identity

    権限システム内では、ユーザーはUser Identityとして識別されます。User Identityは2つの部分で構成されます：usernameとhostです。usernameはユーザーの名前で、英字（大文字と小文字の両方）で構成されます。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@'192.%'やuser@['domain']ではなく、ユーザーuserに属します。

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

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

ユーザーが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_ATTEMPTSとPASSWORD_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_privとNode_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内の任意のテーブルに適用されます。

Catalog権限​

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

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権限はResourcesに特化して設定され、データベースやテーブルの権限とは無関係で、Usage_privとGrant_privのみを割り当てることができます。

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

  • Workload Group権限

    Workload Group権限はWorkload Groupsに特化して設定され、データベースやテーブルの権限とは無関係で、Usage_privとGrant_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を通して権限priv2とprivNを持っています。したがって、userNは権限priv1、priv2、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_privとAdmin_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']

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

      その後、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_userとuserを確認できます。ここで、current_userはユーザーが認証された身元を示し、userは現時点での実際のUser Identityです。

    例えば：

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

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

ベストプラクティス​

以下は、Doris権限システムの使用例です。

  1. シナリオ1

    Dorisクラスターのユーザーは管理者（Admin）、開発エンジニア（RD）、およびユーザー（Client）に分かれています。管理者はクラスター全体に対するすべての権限を持ち、主にクラスターの設定とノード管理を担当します。開発エンジニアはビジネスモデリングを担当し、データベースとテーブルの作成、データのインポートと変更を行います。ユーザーは異なるデータベースとテーブルにアクセスしてデータを取得します。

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

  2. シナリオ2

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

  3. ブロックリスト

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