> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > USER に関するドキュメント # CREATE USER [ユーザーアカウント](/ja/concepts/features/security/access-rights#user-account-management) を作成します。 構文: ```sql theme={null} CREATE USER [IF NOT EXISTS | OR REPLACE] name1 [, name2 [,...]] [ON CLUSTER cluster_name] [{VALID UNTIL datetime | VALID FOR interval}] [NOT IDENTIFIED | IDENTIFIED {[WITH {plaintext_password | sha256_password | sha256_hash | double_sha1_password | double_sha1_hash}] BY {'password' | 'hash'}} | WITH NO_PASSWORD | {WITH ldap SERVER 'server_name'} | {WITH kerberos [REALM 'realm']} | {WITH ssl_certificate CN 'common_name' | SAN 'TYPE:subject_alt_name'} | {WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa|...'} | {WITH http SERVER 'server_name' [SCHEME 'Basic']} [{VALID UNTIL datetime | VALID FOR interval}] [GRANTS (privilege ON object [,...])] [, {[{plaintext_password | sha256_password | sha256_hash | ...}] BY {'password' | 'hash'}} | {ldap SERVER 'server_name'} | {...} | ... [,...]]] [HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE] [IN access_storage_type] [ROLE role [,...]] [DEFAULT ROLE role [,...]] [DEFAULT DATABASE database | NONE] [GRANTEES {user | role | ANY | NONE} [,...] [EXCEPT {user | role} [,...]]] [SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY | WRITABLE] | PROFILE 'profile_name'] [,...] ``` `ON CLUSTER` 句を使用すると、クラスター内にユーザーを作成できます。詳細は [Distributed DDL](/ja/reference/statements/distributed-ddl) を参照してください。
## 識別
ユーザーの識別方法には、複数の種類があります。 * `IDENTIFIED WITH no_password` * `IDENTIFIED WITH plaintext_password BY 'qwerty'` * `IDENTIFIED WITH sha256_password BY 'qwerty'` or `IDENTIFIED BY 'password'` * `IDENTIFIED WITH sha256_hash BY 'hash'` or `IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'` * `IDENTIFIED WITH double_sha1_password BY 'qwerty'` * `IDENTIFIED WITH double_sha1_hash BY 'hash'` * `IDENTIFIED WITH bcrypt_password BY 'qwerty'` * `IDENTIFIED WITH bcrypt_hash BY 'hash'` * `IDENTIFIED WITH ldap SERVER 'server_name'` * `IDENTIFIED WITH kerberos` or `IDENTIFIED WITH kerberos REALM 'realm'` * `IDENTIFIED WITH ssl_certificate CN 'mysite.com:user'` * `IDENTIFIED WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa', KEY 'another_public_key' TYPE 'ssh-ed25519'` * `IDENTIFIED WITH http SERVER 'http_server'` or `IDENTIFIED WITH http SERVER 'http_server' SCHEME 'basic'` * `IDENTIFIED BY 'qwerty'` パスワード複雑性の要件は、[config.xml](/ja/concepts/features/configuration/server-config/configuration-files) で変更できます。以下は、パスワードを 12 文字以上とし、数字を 1 つ含むことを必須にする設定例です。各パスワード複雑性ルールでは、パスワードに対して照合する正規表現と、そのルールの説明が必要です。 ```xml theme={null} .{12} be at least 12 characters long \p{N} contain at least 1 numeric character ``` ClickHouse Cloud では、デフォルトで、パスワードは以下の複雑性要件を満たす必要があります。 * 12文字以上であること * 数字を1文字以上含むこと * 大文字を1文字以上含むこと * 小文字を1文字以上含むこと * 特殊文字を1文字以上含むこと
## 例
1. 次のユーザー名は `name1` で、パスワードは不要です。これは当然ながら、ほとんどセキュリティになりません。 ```sql theme={null} CREATE USER name1 NOT IDENTIFIED ``` 2. 平文パスワードを指定するには、次のようにします。 ```sql theme={null} CREATE USER name2 IDENTIFIED WITH plaintext_password BY 'my_password' ``` パスワードは `/var/lib/clickhouse/access` 内の SQL テキストファイルに保存されるため、`plaintext_password` の使用は推奨されません。代わりに、次に示す `sha256_password` を使用してください。 3. 最も一般的なのは、SHA-256 でハッシュ化されたパスワードを使用する方法です。`IDENTIFIED WITH sha256_password` を指定すると、ClickHouse がパスワードをハッシュ化します。例: ```sql theme={null} CREATE USER name3 IDENTIFIED WITH sha256_password BY 'my_password' ``` これで `name3` ユーザーは `my_password` でログインできますが、パスワードは上記のハッシュ値として保存されます。次の SQL ファイルが `/var/lib/clickhouse/access` に作成され、サーバーの起動時に実行されます。 ```bash theme={null} /var/lib/clickhouse/access $ cat 3843f510-6ebd-a52d-72ac-e021686d8a93.sql ATTACH USER name3 IDENTIFIED WITH sha256_hash BY '0C268556C1680BEF0640AAC1E7187566704208398DA31F03D18C74F5C5BE5053' SALT '4FB16307F5E10048196966DD7E6876AE53DE6A1D1F625488482C75F14A5097C7'; ``` ユーザー名に対応するハッシュ値と salt 値をすでに作成済みであれば、`IDENTIFIED WITH sha256_hash BY 'hash'` または `IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'` を使用できます。`SALT` を使って `sha256_hash` で識別する場合、ハッシュは 'password' と 'salt' を連結した値から計算する必要があります。 4. `double_sha1_password` は通常は不要ですが、それを必要とするクライアント (MySQL インターフェイス など) を扱う場合に便利です。 ```sql theme={null} CREATE USER name4 IDENTIFIED WITH double_sha1_password BY 'my_password' ``` ClickHouse は次のクエリを生成して実行します。 ```response theme={null} CREATE USER name4 IDENTIFIED WITH double_sha1_hash BY 'CCD3A959D6A004B9C3807B728BC2E55B67E10518' ``` 5. `bcrypt_password` は、パスワード保存において最も安全なオプションです。[bcrypt](https://en.wikipedia.org/wiki/Bcrypt) アルゴリズムを使用しており、パスワードハッシュが漏えいした場合でも、総当たり攻撃に強いという特長があります。 ```sql theme={null} CREATE USER name5 IDENTIFIED WITH bcrypt_password BY 'my_password' ``` この方式では、パスワードの長さは 72 文字までに制限されます。 ハッシュの計算とパスワード検証に必要な計算量と時間を定義する bcrypt の work factor パラメーターは、サーバー設定で変更できます。 ```xml theme={null} 12 ``` work factor は 4 から 31 の範囲でなければならず、デフォルト値は 12 です。 高頻度の認証を行うアプリケーションでは、 work factor が高い場合の bcrypt の 計算オーバーヘッドを考慮し、 別の認証方式を検討してください。 6. パスワードの種類は省略することもできます。 ```sql theme={null} CREATE USER name6 IDENTIFIED BY 'my_password' ``` この場合、ClickHouse はサーバー設定で指定されたデフォルトのパスワード種類を使用します。 ```xml theme={null} sha256_password ``` 使用できるパスワード種類は次のとおりです: `plaintext_password`, `sha256_password`, `double_sha1_password`. 7. 複数の認証方式を指定できます。 ```sql theme={null} CREATE USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'' ``` 注記: 1. 古いバージョンの ClickHouse では、複数の認証方式の構文がサポートされていない場合があります。したがって、ClickHouse serverにそのようなユーザーが存在する状態で、これを未対応のバージョンにダウングレードすると、そのようなユーザーは使用できなくなり、一部のユーザー関連の操作も正常に機能しなくなります。問題なくダウングレードするには、事前にすべてのユーザーが単一の認証方式のみを持つように設定しておく必要があります。あるいは、適切な手順を踏まずにサーバーをダウングレードしてしまった場合は、問題のあるユーザーを削除する必要があります。 2. セキュリティ上の理由から、`no_password` は他の認証方式と共存できません。したがって、`no_password` を指定できるのは、それがクエリ内で唯一の認証方式である場合に限られます。
## ユーザーホスト
ユーザーホストとは、ClickHouse server への接続を確立できるホストです。ホストは、`HOST` クエリセクションで次の方法により指定できます。 * `HOST IP 'ip_address_or_subnetwork'` — ユーザーは、指定した IP アドレスまたは [サブネットワーク](https://en.wikipedia.org/wiki/Subnetwork) からのみ ClickHouse server に接続できます。例: `HOST IP '192.168.0.0/16'`、`HOST IP '2001:DB8::/32'`。本番環境で使用する場合は、`host` や `host_regexp` を使用すると余分な遅延が発生する可能性があるため、`HOST IP` 要素 (IP アドレスとそのマスク) のみを指定してください。 * `HOST ANY` — ユーザーは任意の場所から接続できます。これはデフォルトのオプションです。 * `HOST LOCAL` — ユーザーはローカルからのみ接続できます。 * `HOST NAME 'fqdn'` — ユーザーホストは FQDN として指定できます。たとえば、`HOST NAME 'mysite.com'` です。 * `HOST REGEXP 'regexp'` — ユーザーホストを指定する際に、[pcre](http://www.pcre.org/) 正規表現を使用できます。たとえば、`HOST REGEXP '.*\.mysite\.com'` です。 * `HOST LIKE 'template'` — [LIKE](/ja/reference/functions/regular-functions/string-search-functions#like) 演算子を使用してユーザーホストを絞り込めます。たとえば、`HOST LIKE '%'` は `HOST ANY` と同等で、`HOST LIKE '%.mysite.com'` は `mysite.com` ドメイン内のすべてのホストを絞り込みます。 ホストを指定する別の方法として、ユーザー名の後に `@` 構文を続けて使用する方法があります。例: * `CREATE USER mira@'127.0.0.1'` — `HOST IP` 構文と同等です。 * `CREATE USER mira@'localhost'` — `HOST LOCAL` 構文と同等です。 * `CREATE USER mira@'192.168.%.%'` — `HOST LIKE` 構文と同等です。 ClickHouse は `user_name@'address'` を全体で 1 つのユーザー名として扱います。したがって、技術的には同じ `user_name` で `@` の後ろの記述だけが異なる複数のユーザーを作成できます。ただし、その方法は推奨しません。
## VALID UNTIL 句
認証方式の有効期限の日付と、必要に応じて時刻を指定できます。パラメータには文字列を指定します。datetime には `YYYY-MM-DD [hh:mm:ss] [timezone]` フォーマットを使用することを推奨します。`[timezone]` には、`+09:00` のような数値オフセット、または `UTC`、`GMT`、`Z`、`MSK`、`MSD` のいずれかを指定する必要があります。`Asia/Tokyo` のような名前付き IANA ゾーンは認識されません (以下の注記を参照) 。デフォルトでは、このパラメータは `'infinity'` です。指定できるデッドラインの範囲は、`1900-01-01 00:00:00 UTC` から `9999-12-31 09:59:59 UTC` までです。これは、すべてのタイムゾーンで年 9999 内に収まる最新の時点であるため、格納された時点が表示時にクランプされることはありません。過去のデッドラインは、認証情報 がすでに期限切れであることを意味します。`1970-01-01 00:00:01 UTC` より前のデッドラインは、「すでに期限切れ」を示すマーカーとしてのみ受け入れられます。これらは Unix epoch の 1 秒後 (`1970-01-01 00:00:01 UTC`) にあたる、期限切れの最小時点へ正規化されます。そのため、`SHOW CREATE USER` では指定したデッドラインではなく、この時点が表示されます。この時点以降のデッドラインは正確に格納されます。 デッドラインは絶対時点として格納されますが、`SHOW CREATE USER` と [`system.users`](/ja/reference/system-tables/users) ではサーバーまたは session time zone で表示されます。そのため、同じ格納時点でも、設定が異なるサーバーでは異なるローカル時刻の文字列として表示されます。たとえば、上記の正規化された期限切れ時点は、`UTC` のサーバーでは `1970-01-01 00:00:01`、`Pacific/Kiritimati` のサーバーでは `1970-01-01 14:00:01` と表示されます。実際の適用では常に格納時点が使用され、表示結果は使用されません。 句 の配置によって、適用先の認証方式が決まります。 * `IDENTIFIED` 句 より前に指定した場合 (またはクエリで認証方式をまったく指定しない場合) : デッドラインはユーザーレベルのデッドラインとなり、そのユーザーのすべての認証方式に適用されます。 * 認証方式の後に指定した場合: デッドラインはその方式にのみ適用されます。したがって、`IDENTIFIED` リスト全体の後に記述した 句 は最後の方式にのみ関連付けられ、それ以前の方式には有効期限が設定されません。 例: * `CREATE USER name1 VALID UNTIL '2025-01-01'` * `CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 UTC'` * `CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 +09:00'` * `CREATE USER name1 VALID UNTIL 'infinity'` * `CREATE USER name1 VALID UNTIL '2025-01-01' IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'` — ユーザーレベルのデッドラインが両方の方式に適用されます。 * `CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01'` — デッドラインは `bcrypt_password` 方式にのみ適用されます。`plaintext_password` は期限切れになりません。 datetime 文字列は `parseDateTimeBestEffort` によって解析されます。この関数が認識する timezone トークンは、`UTC`、`GMT`、`Z`、`MSK`、`MSD`、および `+09:00` や `-05:00` のような数値オフセットのみです。`Asia/Tokyo` や `Europe/London` のような名前付き IANA タイムゾーンはサポートされていません。また、夏時間を採用する地域では固定オフセットは IANA ゾーンと同等ではないため、エンコードする特定の日付に対応する正しいオフセットを計算する必要があります。
## VALID FOR 句
`VALID FOR`句は、`VALID UNTIL`の簡便な短縮記法です。絶対的な日付と時刻の代わりに[インターバル](/ja/reference/data-types/special-data-types/interval)を指定でき、クエリの実行時点の現在時刻にそのインターバルを加算して有効期限のデッドラインを算出します。結果は`VALID UNTIL`形式で保存されるため、`SHOW CREATE USER`では常に解決後の絶対デッドラインが表示されます。`VALID UNTIL`を使用できるすべての場所で使用でき、配置規則も同じです。`IDENTIFIED`の前に指定した場合 (または認証方式を指定しない場合) は、すべての方式に適用されるユーザーレベルのデッドラインとなります。一方、認証方式の後に指定した場合は、その方式にのみ適用されます。デッドラインは秒精度で保存・適用されるため、秒未満のインターバル (`NANOSECOND`、`MICROSECOND`、`MILLISECOND`) は受け付けられません。指定できる最小単位は`SECOND`です。負のインターバルは、認証情報がすでに期限切れであることを示すために使用できます。結果のデッドラインが`1970-01-01 00:00:01 UTC`より前になる場合は、期限切れとなる最小の時点に正規化されます。`SHOW CREATE USER`ではその値が表示され、[`VALID UNTIL`](#valid-until-clause)で説明しているとおり、serverまたはsessionのtime zoneで表示されます。 例: * `CREATE USER name1 VALID FOR INTERVAL 1 DAY` * `CREATE USER name1 VALID FOR INTERVAL 3 MONTH` * `CREATE USER name1 VALID FOR INTERVAL 1 DAY + INTERVAL 12 HOUR` * `CREATE USER name1 VALID FOR INTERVAL 30 DAY IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'` — ユーザーレベルのデッドラインは両方の方式に適用されます。 * `CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY` — デッドラインは`bcrypt_password`方式にのみ適用されます。`plaintext_password`は期限切れになりません。
## GRANTS 句
特定の認証方式で認証されたセッションで使用可能なアクセス権を制限できます。括弧内に、[GRANT](/ja/reference/statements/grant) ステートメントと同じ形式で権限のリストを指定します。この句は認証方式の後 (`VALID UNTIL` 句がある場合はその後) に指定し、その方式にのみ適用されます。 ユーザーがこのような認証方式でログインすると、セッションのアクセス権は、ユーザーのアクセス権 (付与されたロールによる権限を含む) と句に列挙された権限の積集合になります。この句によってアクセス権が追加されることはありません。列挙された権限がユーザーに付与されていない場合、セッションはその権限を持ちません。このような方式で認証されたセッションでは、権限の付与 (`GRANT OPTION` は積集合を取ると必ず失われます) やロールの管理もできません。ロールの管理には、ロールの作成、変更、削除、付与、取り消しだけでなく、ユーザーに対してデフォルトで有効化されるロールの変更 (`SET DEFAULT ROLE` および `ALTER USER ... DEFAULT ROLE`) も含まれ、これも拒否されます。 `EXECUTE AS` はセッションのプリンシパルを切り替えるため、権限借用中に実行されるステートメントは、ログインしたユーザーの権限ではなく、**対象**ユーザーのアクセス権と列挙された権限の積集合によって制限されます。制限自体が解除されることはなく、権限借用には `IMPERSONATE ON target` がユーザーに付与され、かつ句にも列挙されている必要があります。そのため、制限付き認証情報で同じユーザーの無制限の認証情報より広い権限を得ることはできません。 これにより、アプリケーション用トークンを簡単に作成できます。つまり、有効期限と限定された権限セットを持ち、ユーザーに紐付けられた追加の認証情報です。これは `system.query_log` および `system.processes` ではそのユーザーとして表示され、ユーザーが削除されると使用できなくなり、ユーザーがアクセス権を失うとトークンもそのアクセス権を失います。 **強制適用はイニシエーターでのみ行われます。** 認証方式の `GRANTS` 制限と `VALID UNTIL` の有効期限は、クエリを受信するノード (イニシエーター) でのみ強制適用されます。これらはクラスター内の他のノードには伝播されないため、この句でクラスター全体の実行を制限できるとは考えないでください。リモートノードでは通常どおりロールのスコープが適用されます。この句は `users.xml` では使用できません。[クエリ結果キャッシュ](/ja/concepts/features/performance/caches/query-cache) は、ユーザーのすべての認証方式で共有されます。エントリはユーザーとロールごとに分離されますが、キャッシュヒット時には、セッションがログインに使用した方式の `GRANTS` に対する再チェックは行われません。 例: * `CREATE USER name1 IDENTIFIED BY 'qwerty' GRANTS (SELECT ON db.*)` * `ALTER USER name1 ADD IDENTIFIED WITH plaintext_password BY 'app_token' VALID UNTIL '2026-12-31' GRANTS (SELECT ON db.table, INSERT ON db.table)` この制限は認証方式のプロパティであり、ログイン時に確定されることに注意してください。`ALTER USER` で句を変更しても影響するのは新しいセッションのみで、すでに確立されているセッションには影響しません。 `READ ON S3('s3://bucket/.*')` のようなフィルター付きログソースの grant は、まだこの句ではサポートされていません。積集合ではログソースフィルターを不透明な文字列として比較するため、あるフィルターを別のフィルターに絞り込むことができません。そのため、このような grant はアクセス権が暗黙的に付与されないのではなく、拒否されます。 この句は、認証情報がサーバーによって完全にローカルで検証される認証方式でのみサポートされます。検証時に外部システムに接続する方式 (または `jwt` の場合、たとえば署名キーを取得するために接続する可能性がある方式) (`ldap`、`kerberos`、`http`、`jwt`) では、この句は拒否されます。複数の認証方式が同じ認証情報を受け入れる場合、制限は他の方式に対して認証情報を再検証することで強制されますが、外部システムへの追加の照会は安全ではありません。そのため、同じ認証情報を受け入れる別の方式が制限を回避する可能性があります。 同じ実効認証情報が複数の認証方式で受け入れられる場合、ログインはそれらすべてによってフェイルクローズで制限されます。セッションには一致するすべての方式の `GRANTS` の積集合が適用され、有効期限はそれらの `VALID UNTIL` のうち最も早いものになります。最も早い `VALID UNTIL` は、すでに過ぎている場合でも優先されます。単一の一致した方式が期限切れになった場合とまったく同様にログインは拒否されるため、トークンの期限切れによって共有認証情報に、より広範な方式の権限や有効期間が暗黙的に与えられることはありません。 この組み合わせは、server によってローカルで検証される認証方式間でのみ確認されます。これは、上記の外部で検証される method で句自体が拒否されるのと同じ理由によるものです。つまり、その認証情報を再確認するには、外部システムに対する安全でない追加の照会が必要になるためです。したがって、同じ認証情報が同じ USER の外部で検証される method (`ldap`、`kerberos`、`http`、`jwt`) でも受け入れられる場合でも、その method 固有の `VALID UNTIL` はこの組み合わせの対象には含まれず、そこに設定されたより早い有効期限によって、ローカルで検証される method を通じて取得されたセッションが短縮されることはありません。
## GRANTEES 句
このユーザーが [GRANT OPTION](/ja/reference/statements/grant#granting-privilege-syntax) 付きで必要なすべてのアクセス権も付与されている場合に、このユーザーから [権限](/ja/reference/statements/grant#privileges) を受け取ることができるユーザーまたはロールを指定します。`GRANTEES` 句のオプションは次のとおりです。 * `user` — このユーザーが権限を付与できるユーザーを指定します。 * `role` — このユーザーが権限を付与できるロールを指定します。 * `ANY` — このユーザーは誰にでも権限を付与できます。デフォルト設定です。 * `NONE` — このユーザーは誰にも権限を付与できません。 `EXCEPT` 式を使用すると、任意のユーザーまたはロールを除外できます。たとえば、`CREATE USER user1 GRANTEES ANY EXCEPT user2` と指定します。これは、`user1` が `GRANT OPTION` 付きでいくつかの権限を付与されている場合、それらの権限を `user2` を除く誰にでも付与できることを意味します。
## 例
パスワード `qwerty` を設定したユーザーアカウント `mira` を作成します: ```sql theme={null} CREATE USER mira HOST IP '127.0.0.1' IDENTIFIED WITH sha256_password BY 'qwerty'; ``` `mira` は、ClickHouse server が稼働しているホスト上でクライアントアプリを起動する必要があります。 ユーザーアカウント `john` を作成し、ロールを割り当てます: ```sql theme={null} CREATE USER john ROLE role1, role2; ``` ユーザーアカウント `john` を作成し、ロールを割り当て、その一部をデフォルトロールにします: ```sql theme={null} CREATE USER john ROLE role1, role2 DEFAULT ROLE role1; ``` または ```sql theme={null} CREATE USER john ROLE role1, role2 DEFAULT ROLE ALL EXCEPT role2; ``` ユーザーアカウント `john` を作成し、`jack` アカウントのユーザーに自身の権限を付与できるようにします: ```sql theme={null} CREATE USER john GRANTEES jack; ``` `john` のユーザーアカウントを作成するには、クエリパラメータを使用します: ```sql theme={null} SET param_user=john; CREATE USER {user:Identifier}; ```