ClickHouse/docs/ja/operations/access-rights.md
Ivan Blinkov cd14f9ebcb
SQL reference refactoring (#10857)
* split up select.md

* array-join.md basic refactoring

* distinct.md basic refactoring

* format.md basic refactoring

* from.md basic refactoring

* group-by.md basic refactoring

* having.md basic refactoring

* additional index.md refactoring

* into-outfile.md basic refactoring

* join.md basic refactoring

* limit.md basic refactoring

* limit-by.md basic refactoring

* order-by.md basic refactoring

* prewhere.md basic refactoring

* adjust operators/index.md links

* adjust sample.md links

* adjust more links

* adjust operatots links

* fix some links

* adjust aggregate function article titles

* basic refactor of remaining select clauses

* absolute paths in make_links.sh

* run make_links.sh

* remove old select.md locations

* translate docs/es

* translate docs/fr

* translate docs/fa

* remove old operators.md location

* change operators.md links

* adjust links in docs/es

* adjust links in docs/es

* minor texts adjustments

* wip

* update machine translations to use new links

* fix changelog

* es build fixes

* get rid of some select.md links

* temporary adjust ru links

* temporary adjust more ru links

* improve curly brace handling

* adjust ru as well

* fa build fix

* ru link fixes

* zh link fixes

* temporary disable part of anchor checks
2020-05-15 07:34:54 +03:00

9.3 KiB

machine_translated machine_translated_rev toc_priority toc_title
true 72537a2d52 48 アクセス制御とアカウント管理

アクセス制御とアカウント管理

ClickHouseはに基づくアクセス制御管理を支えます RBAC アプローチ

ClickHouseアクセス事業体:

を設定することができアクセスを用いた:

SQL駆動型ワークフローの使用をお勧めします。 両方の構成方法が同時に機能するため、アカウントとアクセス権を管理するためにサーバー構成ファイルを使用する場合は、sql駆動型ワークフローに簡単

!!! note "警告" 両方の構成方法で同じaccessエンティティを同時に管理することはできません。

使用法

既定では、ClickHouseサーバーはユーザーアカウントを提供します default SQL駆動型のアクセス制御とアカウント管理を使用することはできませんが、すべての権限と権限を持っています。 その default ユーザーアカウントは、クライアントからのログイン時や分散クエリなど、ユーザー名が定義されていない場合に使用されます。 分散クエリ処理のデフォルトのユーザーアカウントをお使いの場合、設定のサーバまたはクラスターを指定していないの ユーザとパスワード プロパティ。

ClickHouseの使用を開始したばかりの場合は、次のシナリオを使用できます:

  1. 有効にする のためのSQL駆動型アクセス制御およびアカウント管理 default ユーザー。
  2. の下でログイン default ユーザーアカウントを作成し、必要なすべてのユーザー 管理者アカウントの作成を忘れないでください (GRANT ALL ON *.* WITH GRANT OPTION TO admin_user_account).
  3. 権限の制限 のために default SQL駆動型のアクセス制御とアカウント管理をユーザーと無効にします。

現在のソリューションの特性

  • データベースとテーブルが存在しない場合でも、権限を付与できます。
  • テーブルが削除された場合、このテーブルに対応するすべての権限は取り消されません。 したがって、後で同じ名前で新しいテーブルが作成されると、すべての特権が再び実際になります。 削除されたテーブルに対応する権限を取り消すには、次のように実行する必要があります。 REVOKE ALL PRIVILEGES ON db.table FROM ALL クエリ。
  • 特権の有効期間の設定はありません。

ユーザー

ユーザーアカウントは、ClickHouseで誰かを承認できるアクセスエンティティです。 ユーザーアカウ:

  • 識別情報。
  • 特権 これは、ユーザーが実行できるクエリの範囲を定義します。
  • ClickHouseサーバーへの接続が許可されているホスト。
  • 付与された役割と既定の役割。
  • ユーザーのログイン時にデフォルトで適用される制約を含む設定。
  • 割り当ての設定を行います。

ユーザーアカウントに対する権限は、 GRANT クエリまたは割り当て 役割. ユーザーから特権を取り消すために、ClickHouseは REVOKE クエリ。 ユーザーの権限を一覧表示するには、 - SHOW GRANTS 声明。

管理クエリ:

設定の適用

設定は、さまざまな方法で設定できます。 ユーザーログイン時に、異なるアクセスエンティティで設定が設定されている場合、この設定の値および制約は、以下の優先順位によって適用されます():

  1. ユーザーアカウント設定。
  2. ユーザーアカウントの既定のロールの設定。 一部のロールで設定が設定されている場合、設定の適用順序は未定義です。
  3. ユーザーまたはその既定のロールに割り当てられた設定プロファイルの設定。 いくつかのプロファイルで設定が設定されている場合、設定適用の順序は未定義です。
  4. すべてのサーバーにデフォルトまたは 標準プロファイル.

役割

Roleは、ユーザーアカウントに付与できるaccessエンティティのコンテナです。

ロール:

  • 特権
  • 設定と制約
  • 付与されたロールのリスト

管理クエリ:

ロールに対する権限は、 GRANT クエリ。 ロールClickHouseから特権を取り消すには REVOKE クエリ。

行ポリシー

行ポリシーは、ユーザーまたはロールで使用できる行または行を定義するフィルターです。 行政政策を含むィのための特定のテーブルリストの役割および/またはユーザーはこの行政政策です。

管理クエリ:

設定プロファイル

設定プロファイルは 設定. 設定プロファイルには、設定と制約、およびこのクォータが適用されるロールやユーザーのリストが含まれます。

管理クエリ:

クォータ

クォータ制限資源利用に 見る クォータ.

定員の制限のために一部の時間、リストの役割および/またはユーザーはこの数量に達した場合。

管理クエリ:

SQL駆動型アクセス制御とアカウント管理の有効化

  • 設定ディレクトリ構成を保管します。

    ClickHouseは、アクセスエンティティ設定を access_control_path サーバー構成パラメータ。

  • SQL駆動型のアクセス制御とアカウント管理を有効にします。

    デフォルトのSQL型のアクセス制御及び特別口座の口座管理オのすべてのユーザー ユーザーを設定する必要があります。 users.xml に1を割り当てます。 access_management 設定。

元の記事