> ## 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 に関するドキュメント

# ALTER USER

ClickHouse のユーザーアカウントを変更します。

構文:

```sql theme={null}
ALTER USER [IF EXISTS] name1 [RENAME TO new_name |, name2 [,...]]
    [ON CLUSTER cluster_name]
    [{VALID UNTIL datetime | VALID FOR interval}]
    [NOT IDENTIFIED | RESET AUTHENTICATION METHODS TO NEW | {IDENTIFIED | ADD 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'} | {...} | ... [,...]]]
    [[ADD | DROP] HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
    [IN access_storage_type]
    [DEFAULT ROLE role [,...] | ALL | ALL EXCEPT role [,...] ]
    [GRANTEES {user | role | ANY | NONE} [,...] [EXCEPT {user | role} [,...]]]
    [DROP ALL PROFILES]
    [DROP ALL SETTINGS]
    [DROP SETTINGS variable [,...] ]
    [DROP PROFILES 'profile_name' [,...] ]
    [ADD|MODIFY SETTINGS variable [=value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE|CONST|CHANGEABLE_IN_READONLY] [,...] ]
    [SET variable [=value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE|CONST|CHANGEABLE_IN_READONLY] [,...] ]
    [ADD PROFILES 'profile_name' [,...] ]
```

`ALTER USER` を使用するには、[ALTER USER](/ja/reference/statements/grant#access-management) 権限を持っている必要があります。

`SET variable = value` は `MODIFY SETTING variable = value` の別名です。これは 1 つの設定だけをその場で変更し、ほかの設定はそのまま維持します。設定リスト全体を置き換え、さらにすべての継承元 (親) プロファイルも削除してしまう、裸の `SETTINGS` 句よりも、こちら (または `MODIFY SETTING`) を優先してください。

<div id="grantees-clause">
  ## GRANTEES 句
</div>

このユーザーが [GRANT OPTION](/ja/reference/statements/grant#granting-privilege-syntax) 付きで必要なすべてのアクセス権を付与されていることを条件に、このユーザーから [権限](/ja/reference/statements/grant#privileges) を受け取ることが許可されるユーザーまたはロールを指定します。`GRANTEES` 句のオプションは次のとおりです。

* `user` — このユーザーが権限を付与できるユーザーを指定します。
* `role` — このユーザーが権限を付与できるロールを指定します。
* `ANY` — このユーザーは誰にでも権限を付与できます。これはデフォルト設定です。
* `NONE` — このユーザーは誰にも権限を付与できません。

`EXCEPT` 式を使用すると、任意のユーザーまたはロールを除外できます。たとえば、`ALTER USER user1 GRANTEES ANY EXCEPT user2` です。これは、`user1` が `GRANT OPTION` 付きでいくつかの権限を付与されている場合、それらの権限を `user2` を除く誰にでも付与できることを意味します。

<div id="examples">
  ## 例
</div>

割り当てられたロールをデフォルトに設定します:

```sql theme={null}
ALTER USER user DEFAULT ROLE role1, role2
```

事前にユーザーにロールが割り当てられていない場合、ClickHouse では例外が発生します。

割り当てられているすべてのロールをデフォルトに設定します:

```sql theme={null}
ALTER USER user DEFAULT ROLE ALL
```

今後ユーザーにロールが割り当てられた場合、そのロールは自動的にデフォルトになります。

`role1` と `role2` を除き、割り当てられているすべてのロールをデフォルトに設定します。

```sql theme={null}
ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2
```

`john` アカウントのユーザーが、自身の権限を `jack` アカウントのユーザーに付与できるようにします。

```sql theme={null}
ALTER USER john GRANTEES jack;
```

既存の認証方式は保持したまま、ユーザーに新しい認証方式を追加します。

```sql theme={null}
ALTER USER user1 ADD IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'
```

注記:

1. 古いバージョンのClickHouseでは、複数の認証方式の構文がサポートされていない場合があります。そのため、ClickHouse serverにそのようなユーザーが存在する状態で、その構文をサポートしていないバージョンにダウングレードすると、それらのユーザーは使用不能になり、一部のユーザー関連操作も正常に行えなくなります。問題なくダウングレードするには、事前にすべてのユーザーが単一の認証方式のみを持つように設定しておく必要があります。あるいは、適切な手順を踏まずにserverをダウングレードしてしまった場合は、問題のあるユーザーを削除する必要があります。
2. `no_password` は、セキュリティ上の理由から他の認証方式と併用できません。
   そのため、`no_password` 認証方式を `ADD` することはできません。以下のクエリはエラーになります:

```sql theme={null}
ALTER USER user1 ADD IDENTIFIED WITH no_password
```

ユーザーの認証方式を削除して `no_password` を使用する場合は、以下の置換形式で指定する必要があります。

認証方式をリセットし、クエリで指定したものを追加します (ADD キーワードを伴わない先頭の IDENTIFIED の効果) :

```sql theme={null}
ALTER USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'
```

認証方式をリセットし、最後に追加した方式のみを保持します:

```sql theme={null}
ALTER USER user1 RESET AUTHENTICATION METHODS TO NEW
```

<div id="valid-until-clause">
  ## VALID UNTIL 句
</div>

認証方式の有効期限の日付と、必要に応じて時刻を指定できます。パラメータには文字列を指定します。日時には `YYYY-MM-DD [hh:mm:ss] [timezone]` フォーマットの使用を推奨します。デフォルトでは、このパラメータは `'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) ではサーバーまたはセッションのタイムゾーンで表示されます。そのため、同じ保存済みの時点でも、設定が異なるサーバーでは異なる現地時刻の文字列として表示されます。たとえば、上記の正規化された期限切れ時点は、`UTC` のサーバーでは `1970-01-01 00:00:01`、`Pacific/Kiritimati` のサーバーでは `1970-01-01 14:00:01` と表示されます。適用時には、表示結果ではなく保存された時点が常に使用されます。

句の配置によって、適用対象となる認証方式が決まります。

* `IDENTIFIED` 句の前に配置した場合 (またはクエリで認証方式をまったく指定しない場合) : デッドラインは、ユーザーのすべての認証方式に適用されるユーザーレベルのデッドラインです。
* 認証方式の後に配置した場合: デッドラインはその方式にのみ適用されます。したがって、`IDENTIFIED` リスト全体の後に記述した句は最後の方式にのみ適用され、先行する方式には有効期限が設定されません。

例:

* `ALTER USER name1 VALID UNTIL '2025-01-01'`
* `ALTER USER name1 VALID UNTIL '2025-01-01 12:00:00 UTC'`
* `ALTER USER name1 VALID UNTIL 'infinity'`
* `ALTER USER name1 VALID UNTIL '2025-01-01' IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'` — ユーザーレベルのデッドラインは両方の方式に適用されます。
* `ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01'` — デッドラインは `bcrypt_password` 方式にのみ適用されます。`plaintext_password` に有効期限はありません。

<div id="valid-for-clause">
  ## VALID FOR 句
</div>

`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)で説明されているとおり、サーバーまたはセッションタイムゾーンで表示されます。

例:

* `ALTER USER name1 VALID FOR INTERVAL 1 DAY`
* `ALTER USER name1 VALID FOR INTERVAL 3 MONTH`
* `ALTER USER name1 VALID FOR INTERVAL 30 DAY IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'` — ユーザーレベルのデッドラインは両方の認証方式に適用されます。
* `ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY` — デッドラインは`bcrypt_password`認証方式にのみ適用されます。`plaintext_password`は期限切れになりません。

<div id="grants-clause">
  ## GRANTS 句
</div>

特定の認証方式で認証されたセッションで利用可能なアクセス権を制限できます。詳細については、[CREATE USER の GRANTS 句](/ja/reference/statements/create/user#grants-clause)を参照してください。

`ADD IDENTIFIED` と組み合わせることで、有効期限と限定された権限セットを持つ追加の認証情報として、アプリケーション用トークンを簡単に作成できます。

例:

* `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)`