> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-detect-table-modification.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](/ko/reference/statements/grant#access-management) 권한이 필요합니다.

`SET variable = value`는 `MODIFY SETTING variable = value`의 별칭입니다: 나머지 설정은 유지한 채 단일 설정만 제자리에서 변경합니다. 전체 설정 목록을 대체하고 상속된 모든 (parent) 프로필도 제거하는 단독 `SETTINGS` 절보다 이것(또는 `MODIFY SETTING`)을 사용하는 것이 좋습니다.

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

이 사용자가 [권한](/ko/reference/statements/grant#privileges)을 부여할 수 있는 사용자 또는 역할을 지정합니다. 단, 그러려면 이 사용자에게도 필요한 모든 접근 권한이 [GRANT OPTION](/ko/reference/statements/grant#granting-privilege-syntax)과 함께 부여되어 있어야 합니다. `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 서버에 이러한 사용자가 있는 상태에서 이를 지원하지 않는 버전으로 다운그레이드하면 해당 사용자는 더 이상 사용할 수 없게 되며, 일부 사용자 관련 작업도 정상적으로 동작하지 않게 됩니다. 다운그레이드를 안전하게 수행하려면, 다운그레이드 전에 모든 사용자가 단일 인증 메서드만 사용하도록 설정해야 합니다. 또는 적절한 절차 없이 서버를 다운그레이드한 경우 문제가 있는 사용자를 삭제해야 합니다.
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`](/ko/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`의 편의 약식 표현입니다. 절대 날짜 및 시간 대신 [인터벌](/ko/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 절](/ko/reference/statements/create/user#grants-clause)을 참조하십시오.

`ADD IDENTIFIED`와 함께 사용하면 애플리케이션용 token, 즉 만료일과 제한된 권한 집합을 가진 추가 자격 증명을 편리하게 생성할 수 있습니다.

예시:

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