Loading...
MySQL 9.5 Reference Manual 9.5의 8.2.15 Password Management의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
MySQL은 다음과 같은 패스워드 관리 기능을 지원합니다:
패스워드 만료를 통해 패스워드가 정기적으로 변경되도록 요구합니다.
패스워드 재사용 제한을 통해 예전에 사용한 패스워드를 다시 선택하지 못하게 합니다.
패스워드 검증을 통해 패스워드 변경 시 현재 패스워드를 함께 명시하여 교체하도록 요구합니다.
이중 패스워드를 통해 클라이언트가 기본(primary) 또는 보조(secondary) 패스워드를 사용해 접속할 수 있게 합니다.
패스워드 강도 평가를 통해 강력한 패스워드 사용을 요구합니다.
관리자에 의해 명시적으로 지정된 리터럴 패스워드를 요구하는 대신 대체 수단으로 랜덤 패스워드 생성을 지원합니다.
너무 많은 연속적인 잘못된 패스워드 로그인 실패 후 임시 계정 잠금을 가능하게 하는 패스워드 실패 추적 기능을 지원합니다.
다음 절에서는 이러한 기능들을 설명하며, 패스워드 강도 평가는 validate_password 컴포넌트를 사용하여 구현되며 Section 8.4.4, “The Password Validation Component”에 설명되어 있습니다.
주의
MySQL은 mysql 시스템 데이터베이스의 테이블들을 사용하여 패스워드 관리 기능을 구현합니다. 예전 버전에서 MySQL을 업그레이드한 경우 시스템 테이블이 최신 상태가 아닐 수 있습니다. 이 경우 서버는 시작 과정 동안 에러 로그에 다음과 유사한 메시지를 기록합니다(정확한 숫자는 달라질 수 있음):
1[ERROR] Column count of mysql.user is wrong. Expected 249, found 47. The table is probably corrupted 3[Warning] ACL table mysql.password_history missing. 4Some operations may fail.
이 문제를 수정하려면 MySQL 업그레이드 절차를 수행하십시오. Chapter 3, Upgrading MySQL을 참조하십시오. 이것이 완료될 때까지는 패스워드 변경이 불가능합니다.
일부 인증 플러그인은 계정 자격 증명을 MySQL 내부의 mysql.user 시스템 테이블에 저장합니다:
caching_sha2_password
sha256_password (deprecated)
이 절의 대부분의 설명은 이러한 인증 플러그인에 적용됩니다. 여기에서 설명하는 대부분의 패스워드 관리 기능이 MySQL 자체에 의해 처리되는 내부 자격 증명 저장에 기반하기 때문입니다. 다른 인증 플러그인은 계정 자격 증명을 MySQL 외부에 저장합니다. 외부 자격 증명 시스템에 대해 인증을 수행하는 플러그인을 사용하는 계정의 경우, 패스워드 관리는 해당 시스템에 대해 외부에서 처리되어야 합니다.
예외적으로, 로그인 실패 추적 및 임시 계정 잠금 옵션은 내부 자격 증명 저장을 사용하는 계정뿐만 아니라 모든 계정에 적용됩니다. 이는 계정이 내부 또는 외부 자격 증명 저장을 사용하는지 여부에 관계없이 MySQL이 모든 계정에 대한 로그인 시도의 상태를 평가할 수 있기 때문입니다.
개별 인증 플러그인에 대한 정보는 Section 8.4.1, “Authentication Plugins”를 참조하십시오.
MySQL은 데이터베이스 관리자가 계정 패스워드를 수동으로 만료시킬 수 있게 하며, 자동 패스워드 만료에 대한 정책을 설정할 수 있게 합니다. 만료 정책은 전역으로 설정할 수 있고, 개별 계정은 전역 정책을 따르도록 설정하거나, 계정별 동작을 구체적으로 지정하여 전역 정책을 오버라이드하도록 설정할 수 있습니다.
계정 패스워드를 수동으로 만료시키려면 ALTER USER 문을 사용합니다:
1ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE;
이 작업은 mysql.user 시스템 테이블의 해당 행에서 패스워드를 만료된 것으로 표시합니다.
정책에 따른 패스워드 만료는 자동으로 이루어지며, 특정 계정의 패스워드 사용 기간을 기준으로 합니다. 패스워드 사용 기간은 해당 계정에 대해 가장 최근 패스워드 변경의 날짜와 시간으로부터 평가됩니다. mysql.user 시스템 테이블은 각 계정에 대해 패스워드가 마지막으로 변경된 시점을 나타내며, 서버는 클라이언트 접속 시점에 패스워드 사용 기간이 허용된 수명보다 큰 경우 패스워드를 자동으로 만료된 것으로 처리합니다. 이는 명시적인 수동 패스워드 만료 없이 동작합니다.
자동 패스워드 만료 정책을 전역으로 설정하려면 default_password_lifetime 시스템 변수를 사용합니다. 이 값의 기본값은 0이며, 자동 패스워드 만료를 비활성화합니다. default_password_lifetime의 값이 양의 정수 _N_이면 허용된 패스워드 수명을 나타내며, 패스워드는 _N_일마다 변경되어야 합니다.
예:
my.cnf 파일에 다음 줄을 추가하여 서버를 시작합니다:1[mysqld] 2default_password_lifetime=180
default_password_lifetime을 0으로 설정합니다:1[mysqld] 2default_password_lifetime=0
default_password_lifetime은 런타임에 설정하고 영구 저장할 수도 있습니다:1SET PERSIST default_password_lifetime = 180; 2SET PERSIST default_password_lifetime = 0;
SET PERSIST는 실행 중인 MySQL 인스턴스에 대해 값을 설정합니다. 또한 해당 값을 저장하여 이후 서버 재시작 시에도 유지되도록 합니다. Section 15.7.6.1, “SET Syntax for Variable Assignment”를 참조하십시오. 실행 중인 MySQL 인스턴스에 대해서만 값을 변경하고 이후 재시작 시에는 반영되지 않게 하려면 PERSIST 대신 GLOBAL 키워드를 사용하십시오.
전역 패스워드 만료 정책은 이를 오버라이드하도록 설정되지 않은 모든 계정에 적용됩니다. 개별 계정에 대한 정책을 설정하려면 CREATE USER 및 ALTER USER 문의 PASSWORD EXPIRE 옵션을 사용합니다. Section 15.7.1.3, “CREATE USER Statement” 및 Section 15.7.1.1, “ALTER USER Statement”를 참조하십시오.
계정별 문 예:
1CREATE USER 'jeffrey'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY; 2ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
이 만료 옵션은 문에 의해 지정된 모든 계정에 대해 전역 정책을 오버라이드합니다.
1CREATE USER 'jeffrey'@'localhost' PASSWORD EXPIRE NEVER; 2ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE NEVER;
이 만료 옵션은 문에 의해 지정된 모든 계정에 대해 전역 정책을 오버라이드합니다.
1CREATE USER 'jeffrey'@'localhost' PASSWORD EXPIRE DEFAULT; 2ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE DEFAULT;
클라이언트가 성공적으로 접속하면, 서버는 계정 패스워드가 만료되었는지 여부를 판단합니다:
서버는 먼저 패스워드가 수동으로 만료되었는지 확인합니다.
그렇지 않으면 서버는 패스워드 사용 기간이 자동 패스워드 만료 정책에 따른 허용 수명보다 큰지 확인합니다. 그렇다면 서버는 패스워드를 만료된 것으로 간주합니다.
패스워드가(수동 또는 자동으로) 만료된 경우 서버는 클라이언트를 접속 해제하거나 허용되는 작업을 제한합니다(Section 8.2.16, “Server Handling of Expired Passwords” 참조). 제한된 클라이언트가 수행하는 작업은 사용자가 새로운 계정 패스워드를 설정할 때까지 에러를 발생시킵니다:
1mysql> SELECT 1; 2ERROR 1820 (HY000): You must reset your password using ALTER USER 3statement before executing this statement. 4 5mysql> ALTER USER USER() IDENTIFIED BY 'password'; 6Query OK, 0 rows affected (0.01 sec) 7 8mysql> SELECT 1; 9+---+ 10| 1 | 11+---+ 12| 1 | 13+---+ 141 row in set (0.00 sec)
클라이언트가 패스워드를 재설정한 후에는 서버가 해당 세션뿐만 아니라 그 계정을 사용하는 이후 접속에 대해서도 정상적인 액세스를 복원합니다. 또한 관리자 사용자가 계정 패스워드를 재설정할 수도 있지만, 해당 계정에 대한 기존 제한된 세션은 계속 제한된 상태로 남습니다. 계정을 사용하는 클라이언트는 문을 성공적으로 실행하기 전에 접속을 끊고 다시 접속해야 합니다.
참고
만료된 패스워드를 현재 값으로 설정함으로써 “재설정”하는 것이 가능하긴 하지만, 정책상으로는 다른 패스워드를 선택하는 것이 바람직합니다. DBA는 적절한 패스워드 재사용 정책을 설정하여 재사용을 금지할 수 있습니다. Password Reuse Policy를 참조하십시오.
MySQL은 이전 패스워드 재사용에 제한을 둘 수 있게 합니다. 재사용 제한은 패스워드 변경 횟수, 경과 시간 또는 둘 다를 기준으로 설정할 수 있습니다. 재사용 정책은 전역으로 설정할 수 있고, 개별 계정은 전역 정책을 따르거나 계정별 동작으로 전역 정책을 오버라이드하도록 설정할 수 있습니다.
계정의 패스워드 이력은 과거에 해당 계정에 할당된 패스워드로 구성됩니다. MySQL은 새 패스워드가 이 이력에서 선택되는 것을 제한할 수 있습니다:
계정이 패스워드 변경 횟수 기준으로 제한되는 경우, 새 패스워드는 지정된 개수만큼의 가장 최근 패스워드에서 선택될 수 없습니다. 예를 들어 최소 패스워드 변경 횟수를 3으로 설정하면, 새 패스워드는 가장 최근 3개의 패스워드 중 어느 것과도 같을 수 없습니다.
계정이 경과 시간 기준으로 제한되는 경우, 새 패스워드는 이력에서 지정된 일수보다 더 최근인 패스워드에서 선택될 수 없습니다. 예를 들어 패스워드 재사용 기간을 60으로 설정하면, 새 패스워드는 지난 60일 이내에 선택되었던 패스워드 중 하나일 수 없습니다.
참고
빈 패스워드는 패스워드 이력에 포함되지 않으며, 언제든지 재사용될 수 있습니다.
패스워드 재사용 정책을 전역으로 설정하려면 password_history 및 password_reuse_interval 시스템 변수를 사용합니다.
예:
my.cnf 파일에 다음 줄을 추가합니다:1[mysqld] 2password_history=6 3password_reuse_interval=365
1SET PERSIST password_history = 6; 2SET PERSIST password_reuse_interval = 365;
SET PERSIST는 실행 중인 MySQL 인스턴스에 대해 값을 설정합니다. 또한 해당 값을 저장하여 이후 서버 재시작 시에도 유지되도록 합니다. Section 15.7.6.1, “SET Syntax for Variable Assignment”를 참조하십시오. 실행 중인 MySQL 인스턴스에 대해서만 값을 변경하고 이후 재시작 시에는 반영되지 않게 하려면 PERSIST 대신 GLOBAL 키워드를 사용하십시오.
전역 패스워드 재사용 정책은 이를 오버라이드하도록 설정되지 않은 모든 계정에 적용됩니다. 개별 계정에 대한 정책을 설정하려면 CREATE USER 및 ALTER USER 문의 PASSWORD HISTORY 및 PASSWORD REUSE INTERVAL 옵션을 사용합니다. Section 15.7.1.3, “CREATE USER Statement” 및 Section 15.7.1.1, “ALTER USER Statement”를 참조하십시오.
계정별 문 예:
1CREATE USER 'jeffrey'@'localhost' PASSWORD HISTORY 5; 2ALTER USER 'jeffrey'@'localhost' PASSWORD HISTORY 5;
이 이력 길이 옵션은 문에 의해 지정된 모든 계정에 대해 전역 정책을 오버라이드합니다.
1CREATE USER 'jeffrey'@'localhost' PASSWORD REUSE INTERVAL 365 DAY; 2ALTER USER 'jeffrey'@'localhost' PASSWORD REUSE INTERVAL 365 DAY;
이 경과 시간 옵션은 문에 의해 지정된 모든 계정에 대해 전역 정책을 오버라이드합니다.
PASSWORD HISTORY 및 PASSWORD REUSE INTERVAL을 함께 사용합니다:1CREATE USER 'jeffrey'@'localhost' 2 PASSWORD HISTORY 5 3 PASSWORD REUSE INTERVAL 365 DAY; 4ALTER USER 'jeffrey'@'localhost' 5 PASSWORD HISTORY 5 6 PASSWORD REUSE INTERVAL 365 DAY;
이 옵션들은 문에 의해 지정된 모든 계정에 대해 두 종류의 전역 정책 재사용 제한을 모두 오버라이드합니다.
1CREATE USER 'jeffrey'@'localhost' 2 PASSWORD HISTORY DEFAULT 3 PASSWORD REUSE INTERVAL DEFAULT; 4ALTER USER 'jeffrey'@'localhost' 5 PASSWORD HISTORY DEFAULT 6 PASSWORD REUSE INTERVAL DEFAULT;
계정 패스워드를 변경하려는 시도가 교체 대상인 현재 패스워드를 명시하여 검증되도록 요구할 수 있습니다. 이를 통해 DBA는 사용자가 현재 패스워드를 알고 있음을 증명하지 않고 패스워드를 변경하는 것을 방지할 수 있습니다. 그렇지 않으면 다음과 같은 상황에서 변경이 가능할 수 있습니다. 한 사용자가 터미널 세션에서 로그아웃하지 않은 채 잠시 자리를 비우고, 악의적인 사용자가 해당 세션을 사용하여 원래 사용자의 MySQL 패스워드를 변경하는 경우입니다. 이는 좋지 않은 결과를 초래할 수 있습니다:
원래 사용자는 관리자가 계정 패스워드를 재설정할 때까지 MySQL에 액세스할 수 없게 됩니다.
패스워드 재설정이 이루어지기 전까지 악의적인 사용자는 선량한 사용자로부터 변경된 자격 증명을 사용해 MySQL에 액세스할 수 있습니다.
패스워드 검증 정책은 전역으로 설정할 수 있으며, 개별 계정은 전역 정책을 따르거나 계정별 동작으로 전역 정책을 오버라이드하도록 설정할 수 있습니다.
각 계정에 대해, 해당 mysql.user 행은 패스워드 변경 시도에 대해 현재 패스워드 검증이 필요한 계정별 설정이 있는지 여부를 나타냅니다. 이 설정은 CREATE USER 및 ALTER USER 문의 PASSWORD REQUIRE 옵션에 의해 설정됩니다:
계정 설정이 PASSWORD REQUIRE CURRENT이면, 패스워드 변경 시 현재 패스워드를 명시해야 합니다.
계정 설정이 PASSWORD REQUIRE CURRENT OPTIONAL이면, 패스워드 변경 시 현재 패스워드를 명시할 수도 있고 하지 않을 수도 있습니다.
계정 설정이 PASSWORD REQUIRE CURRENT DEFAULT이면, password_require_current 시스템 변수가 해당 계정에 대한 검증 요구 정책을 결정합니다:
password_require_current가 활성화되어 있으면, 패스워드 변경 시 현재 패스워드를 명시해야 합니다.
password_require_current가 비활성화되어 있으면, 패스워드 변경 시 현재 패스워드를 명시할 수도 있고 하지 않을 수도 있습니다.
즉, 계정 설정이 PASSWORD REQUIRE CURRENT DEFAULT가 아닌 경우 계정 설정이 password_require_current 시스템 변수에 의해 설정된 전역 정책보다 우선합니다. 그렇지 않으면 계정은 password_require_current 설정을 따릅니다.
기본적으로 패스워드 검증은 선택 사항입니다. password_require_current는 비활성화 상태이며, PASSWORD REQUIRE 옵션 없이 생성된 계정은 기본적으로 PASSWORD REQUIRE CURRENT DEFAULT로 설정됩니다.
다음 테이블은 계정별 설정이 password_require_current 시스템 변수 값과 어떻게 상호 작용하여 계정 패스워드 검증 요구 정책을 결정하는지 보여줍니다.
Table 8.10 Password-Verification Policy
| Per-Account Setting | password_require_current System Variable | Password Changes Require Current Password? |
|---|---|---|
PASSWORD REQUIRE CURRENT | OFF | Yes |
PASSWORD REQUIRE CURRENT | ON | Yes |
PASSWORD REQUIRE CURRENT OPTIONAL | OFF | No |
PASSWORD REQUIRE CURRENT OPTIONAL | ON | No |
PASSWORD REQUIRE CURRENT DEFAULT | OFF | No |
PASSWORD REQUIRE CURRENT DEFAULT | ON | Yes |
참고
검증 요구 정책과 상관없이, 권한 있는 사용자는 현재 패스워드를 명시하지 않고도 모든 계정 패스워드를 변경할 수 있습니다. 권한 있는 사용자는 전역 CREATE USER 권한을 갖거나 mysql 시스템 데이터베이스에 대한 UPDATE 권한을 가진 사용자를 의미합니다.
패스워드 검증 정책을 전역으로 설정하려면 password_require_current 시스템 변수를 사용합니다. 이 값의 기본값은 OFF이며, 계정 패스워드 변경 시 현재 패스워드를 명시할 필요가 없습니다.
예:
my.cnf 파일에 다음 줄을 추가하여 서버를 시작합니다:1[mysqld] 2password_require_current=ON
password_require_current을 설정하고 영구 저장하려면 다음과 같은 문을 사용합니다:1SET PERSIST password_require_current = ON; 2SET PERSIST password_require_current = OFF;
SET PERSIST는 실행 중인 MySQL 인스턴스에 대해 값을 설정합니다. 또한 해당 값을 저장하여 이후 서버 재시작 시에도 유지되도록 합니다. Section 15.7.6.1, “SET Syntax for Variable Assignment”를 참조하십시오. 실행 중인 MySQL 인스턴스에 대해서만 값을 변경하고 이후 재시작 시에는 반영되지 않게 하려면 PERSIST 대신 GLOBAL 키워드를 사용하십시오.
전역 패스워드 검증 요구 정책은 이를 오버라이드하도록 설정되지 않은 모든 계정에 적용됩니다. 개별 계정에 대한 정책을 설정하려면 CREATE USER 및 ALTER USER 문의 PASSWORD REQUIRE 옵션을 사용합니다. Section 15.7.1.3, “CREATE USER Statement” 및 Section 15.7.1.1, “ALTER USER Statement”를 참조하십시오.
계정별 문 예:
1CREATE USER 'jeffrey'@'localhost' PASSWORD REQUIRE CURRENT; 2ALTER USER 'jeffrey'@'localhost' PASSWORD REQUIRE CURRENT;
이 검증 옵션은 문에 의해 지정된 모든 계정에 대해 전역 정책을 오버라이드합니다.
1CREATE USER 'jeffrey'@'localhost' PASSWORD REQUIRE CURRENT OPTIONAL; 2ALTER USER 'jeffrey'@'localhost' PASSWORD REQUIRE CURRENT OPTIONAL;
이 검증 옵션은 문에 의해 지정된 모든 계정에 대해 전역 정책을 오버라이드합니다.
1CREATE USER 'jeffrey'@'localhost' PASSWORD REQUIRE CURRENT DEFAULT; 2ALTER USER 'jeffrey'@'localhost' PASSWORD REQUIRE CURRENT DEFAULT;
현재 패스워드 검증은 사용자가 ALTER USER 또는 SET PASSWORD 문을 사용하여 패스워드를 변경할 때 발생합니다. 예제에서는 ALTER USER를 사용하며, 이는 SET PASSWORD보다 권장됩니다. 그러나 여기서 설명하는 원칙은 두 문 모두에 동일하게 적용됩니다.
패스워드 변경 문에서 REPLACE 절은 교체 대상인 현재 패스워드를 지정합니다. 예:
1ALTER USER USER() IDENTIFIED BY 'auth_string' REPLACE 'current_auth_string';
1ALTER USER 'jeffrey'@'localhost' 2 IDENTIFIED BY 'auth_string' 3 REPLACE 'current_auth_string';
1ALTER USER 'jeffrey'@'localhost' 2 IDENTIFIED WITH caching_sha2_password BY 'auth_string' 3 REPLACE 'current_auth_string';
REPLACE 절은 다음과 같이 동작합니다:
계정에 대해 패스워드 변경 시 현재 패스워드를 명시해야 하는 경우, REPLACE는 변경을 시도하는 사용자가 실제로 현재 패스워드를 알고 있음을 검증하기 위해 반드시 지정되어야 합니다.
계정에 대해 패스워드 변경 시 현재 패스워드를 명시할 수도 있고 하지 않을 수도 있는 경우, REPLACE는 선택 사항입니다.
REPLACE가 지정된 경우, 올바른 현재 패스워드를 지정해야 하며, 그렇지 않으면 에러가 발생합니다. 이는 REPLACE가 선택 사항인 경우에도 마찬가지입니다.
REPLACE는 현재 사용자의 계정 패스워드를 변경할 때만 지정할 수 있습니다. (이는 앞의 예에서 jeffrey 계정을 명시적으로 지정하는 문은 현재 사용자가 jeffrey가 아닌 경우 실패한다는 의미입니다.) 이는 권한 있는 사용자가 다른 사용자에 대해 변경을 시도하는 경우에도 마찬가지입니다. 그러나 이러한 사용자는 REPLACE를 지정하지 않고도 모든 패스워드를 변경할 수 있습니다.
REPLACE는 바이너리 로그에 평문 패스워드를 기록하지 않기 위해 바이너리 로그에서 생략됩니다.
사용자 계정은 기본(primary) 및 보조(secondary) 패스워드로 지정되는 이중 패스워드를 가질 수 있습니다. 듀얼 패스워드 기능을 사용하면 다음과 같은 시나리오에서 자격 증명 변경을 원활하게 수행할 수 있습니다:
시스템에 많은 수의 MySQL 서버가 있으며, 복제가 포함될 수 있습니다.
여러 개의 애플리케이션이 서로 다른 MySQL 서버에 접속합니다.
애플리케이션이 서버에 접속하는 데 사용하는 계정의 자격 증명을 주기적으로 변경해야 합니다.
계정에 단일 패스워드만 허용되는 앞선 시나리오에서 자격 증명 변경을 수행하는 방법을 생각해 보십시오. 이 경우 계정 패스워드 변경이 이루어져 모든 서버에 전파되는 시점과, 해당 계정을 사용하는 모든 애플리케이션이 새 패스워드를 사용하도록 업데이트되는 시점 사이에 긴밀한 조율이 필요합니다. 이 과정에서는 서버 또는 애플리케이션이 사용 불가능한 다운타임이 발생할 수 있습니다.
이중 패스워드를 사용하면, 긴밀한 조율이나 다운타임 없이 여러 단계에 걸쳐 자격 증명 변경을 더 쉽게 수행할 수 있습니다:
영향받는 각 계정에 대해 현재 패스워드를 보조 패스워드로 유지하면서 서버에 새로운 기본 패스워드를 설정합니다. 이렇게 하면 서버가 각 계정에 대해 기본 또는 보조 패스워드를 모두 인식할 수 있고, 애플리케이션은 이전과 동일한 패스워드(이제 보조 패스워드)를 사용해 서버에 계속 접속할 수 있습니다.
패스워드 변경이 모든 서버로 전파된 후, 영향받는 계정을 사용하는 애플리케이션을 수정하여 계정의 기본 패스워드를 사용해 접속하도록 합니다.
모든 애플리케이션이 보조 패스워드에서 기본 패스워드로 마이그레이션되면, 보조 패스워드는 더 이상 필요하지 않으므로 폐기할 수 있습니다. 이 변경이 모든 서버에 전파된 후에는 각 계정의 기본 패스워드만 사용해 접속할 수 있습니다. 자격 증명 변경이 이제 완료된 것입니다.
MySQL은 보조 패스워드를 저장하고 폐기하는 구문을 사용하여 듀얼 패스워드 기능을 구현합니다:
ALTER USER 및 SET PASSWORD 문의 RETAIN CURRENT PASSWORD 절은 새 기본 패스워드를 할당할 때 계정의 현재 패스워드를 보조 패스워드로 저장합니다.
ALTER USER의 DISCARD OLD PASSWORD 절은 계정의 보조 패스워드를 폐기하여 기본 패스워드만 남깁니다.
앞서 설명한 자격 증명 변경 시나리오에서, 'appuser1'@'host1.example.com'이라는 계정이 애플리케이션이 서버에 접속하는 데 사용되고, 계정 패스워드를 'password_a'에서 'password_b'로 변경해야 한다고 가정합니다.
이 자격 증명 변경을 수행하려면 ALTER USER를 다음과 같이 사용합니다:
'password_b'를 appuser1의 새 기본 패스워드로 설정합니다:1ALTER USER 'appuser1'@'host1.example.com' 2 IDENTIFIED BY 'password_b' 3 RETAIN CURRENT PASSWORD;
패스워드 변경이 모든 레플리카를 포함한 시스템 전체에 복제될 때까지 기다립니다.
appuser1 계정을 사용하는 각 애플리케이션을 수정하여 'password_a' 대신 'password_b' 패스워드를 사용해 서버에 접속하도록 합니다.
이제 보조 패스워드는 더 이상 필요하지 않습니다. 레플리카가 아닌 각 서버에서 보조 패스워드를 폐기합니다:
1ALTER USER 'appuser1'@'host1.example.com' 2 DISCARD OLD PASSWORD;
RETAIN CURRENT PASSWORD 및 DISCARD OLD PASSWORD 절은 다음과 같은 효과를 가집니다:
RETAIN CURRENT PASSWORD는 계정의 현재 패스워드를 보조 패스워드로 유지하며, 기존 보조 패스워드가 있는 경우 이를 대체합니다. 새 패스워드는 기본 패스워드가 되지만, 클라이언트는 기본 또는 보조 패스워드를 사용해 계정으로 서버에 접속할 수 있습니다. (예외: ALTER USER 또는 SET PASSWORD 문에서 지정한 새 패스워드가 빈 값인 경우, RETAIN CURRENT PASSWORD가 지정되었더라도 보조 패스워드 역시 빈 값이 됩니다.)
기본 패스워드가 빈 값인 계정에 대해 RETAIN CURRENT PASSWORD를 지정하면 문은 실패합니다.
계정에 보조 패스워드가 있고, RETAIN CURRENT PASSWORD를 지정하지 않고 기본 패스워드를 변경하는 경우, 보조 패스워드는 변경되지 않은 채 유지됩니다.
ALTER USER의 경우, 계정에 할당된 인증 플러그인을 변경하면 보조 패스워드는 폐기됩니다. 인증 플러그인을 변경하면서 동시에 RETAIN CURRENT PASSWORD를 지정하면 문은 실패합니다.
ALTER USER에서 DISCARD OLD PASSWORD는 보조 패스워드가 존재할 경우 이를 폐기합니다. 계정은 기본 패스워드만 유지하며, 클라이언트는 기본 패스워드로만 계정을 사용해 서버에 접속할 수 있습니다.
보조 패스워드를 수정하는 문에는 다음 권한이 필요합니다:
자신의 계정에 적용되는 ALTER USER 및 SET PASSWORD 문에 대해 RETAIN CURRENT PASSWORD 또는 DISCARD OLD PASSWORD 절을 사용하려면 APPLICATION_PASSWORD_ADMIN 권한이 필요합니다. 대부분의 사용자는 하나의 패스워드만 필요하므로, 자신의 보조 패스워드를 조작할 때 이 권한이 필요합니다.
계정이 모든 계정의 보조 패스워드를 조작할 수 있도록 하려면, APPLICATION_PASSWORD_ADMIN 대신 CREATE USER 권한을 부여해야 합니다.
CREATE USER, ALTER USER, SET PASSWORD 문은 사용자 계정에 대해 랜덤 패스워드를 생성하는 기능을 제공합니다. 이는 관리자가 명시적으로 리터럴 패스워드를 지정해야 하는 요구에 대한 대체 수단입니다. 구문에 대한 자세한 내용은 각 문 설명을 참조하십시오. 이 절에서는 생성된 랜덤 패스워드의 공통 특성을 설명합니다.
기본적으로 생성된 랜덤 패스워드는 길이가 20자입니다. 이 길이는 범위가 5에서 255인 generated_random_password_length 시스템 변수에 의해 제어됩니다.
문이 특정 계정에 대해 랜덤 패스워드를 생성하면, 해당 문은 mysql.user 시스템 테이블에 계정 인증 플러그인에 맞게 해시된 형태로 패스워드를 저장합니다. 또한 문은 결과 집합의 행으로 평문 패스워드를 반환하여 문을 실행하는 사용자 또는 애플리케이션이 이 값을 사용할 수 있도록 합니다. 결과 집합 컬럼 이름은 user, host, generated password, auth_factor이며, 각각 mysql.user 시스템 테이블에서 영향을 받는 행을 식별하는 사용자 이름과 호스트 이름 값, 평문 생성 패스워드, 표시된 패스워드 값이 적용되는 인증 팩터를 나타냅니다.
1mysql> CREATE USER 2 'u1'@'localhost' IDENTIFIED BY RANDOM PASSWORD, 3 'u2'@'%.example.com' IDENTIFIED BY RANDOM PASSWORD, 4 'u3'@'%.org' IDENTIFIED BY RANDOM PASSWORD; 5+------+---------------+----------------------+-------------+ 6| user | host | generated password | auth_factor | 7+------+---------------+----------------------+-------------+ 8| u1 | localhost | iOeqf>Mh9:;XD&qn(Hl} | 1 | 9| u2 | %.example.com | sXTSAEvw3St-R+_-C3Vb | 1 | 10| u3 | %.org | nEVe%Ctw/U/*Md)Exc7& | 1 | 11+------+---------------+----------------------+-------------+ 12mysql> ALTER USER 13 'u1'@'localhost' IDENTIFIED BY RANDOM PASSWORD, 14 'u2'@'%.example.com' IDENTIFIED BY RANDOM PASSWORD; 15+------+---------------+----------------------+-------------+ 16| user | host | generated password | auth_factor | 17+------+---------------+----------------------+-------------+ 18| u1 | localhost | Seiei:&cw}8]@3OA64vh | 1 | 19| u2 | %.example.com | j@&diTX80l8}(NiHXSae | 1 | 20+------+---------------+----------------------+-------------+ 21mysql> SET PASSWORD FOR 'u3'@'%.org' TO RANDOM; 22+------+-------+----------------------+-------------+ 23| user | host | generated password | auth_factor | 24+------+-------+----------------------+-------------+ 25| u3 | %.org | n&cz2xF;P3!U)+]Vw52H | 1 | 26+------+-------+----------------------+-------------+
계정에 대해 랜덤 패스워드를 생성하는 CREATE USER, ALTER USER, SET PASSWORD 문은 바이너리 로그에 CREATE USER 또는 ALTER USER 문 형태로 기록되며, IDENTIFIED WITH auth_plugin AS 'auth_string' 절을 포함합니다. 여기서 _auth_plugin_은 계정 인증 플러그인이고, 'auth_string'은 계정의 해시된 패스워드 값입니다.
validate_password 컴포넌트가 설치된 경우, 해당 컴포넌트가 구현하는 정책은 생성된 패스워드에 영향을 주지 않습니다. (패스워드 검사의 목적은 사람이 더 나은 패스워드를 만들 수 있도록 돕는 것입니다.)
관리자는 너무 많은 연속적인 로그인 실패가 발생할 경우 계정이 임시로 잠기도록 사용자 계정을 구성할 수 있습니다.
이 문맥에서 “로그인 실패”는 접속 시도 동안 클라이언트가 올바른 패스워드를 제공하지 못한 경우를 의미합니다. 알 수 없는 사용자 또는 네트워크 문제와 같은 이유로 인한 접속 실패는 포함되지 않습니다. 이중 패스워드를 가진 계정의 경우(Dual Password Support 참조), 계정의 두 패스워드 중 어느 것이라도 올바른 것으로 인정됩니다.
필요한 로그인 실패 횟수와 잠금 시간은 CREATE USER 및 ALTER USER 문의 FAILED_LOGIN_ATTEMPTS 및 PASSWORD_LOCK_TIME 옵션을 사용하여 계정별로 설정할 수 있습니다. 예:
1CREATE USER 'u1'@'localhost' IDENTIFIED BY 'password' 2 FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 3; 3 4ALTER USER 'u2'@'localhost' 5 FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME UNBOUNDED;
너무 많은 연속적인 로그인 실패가 발생하면, 클라이언트는 다음과 같은 에러를 받습니다:
1ERROR 3957 (HY000): Access denied for user user. 2Account is blocked for D day(s) (R day(s) remaining) 3due to N consecutive failed logins.
옵션 사용 방법은 다음과 같습니다:
FAILED_LOGIN_ATTEMPTS N이 옵션은 잘못된 패스워드를 지정하는 계정 로그인 시도를 추적할지 여부를 나타냅니다. 숫자 _N_은 연속된 잘못된 패스워드 횟수가 계정 임시 잠금을 유발하는지를 지정합니다.
PASSWORD_LOCK_TIME {N | UNBOUNDED}이 옵션은 너무 많은 연속적인 로그인 시도가 잘못된 패스워드를 제공할 경우 계정을 얼마나 오랫동안 잠글지를 나타냅니다. 값은 계정이 잠긴 상태로 유지되는 일수를 나타내는 숫자 _N_이거나, 계정이 임시 잠금 상태에 들어가면 해당 상태의 지속 시간이 무한하며 계정이 잠금 해제될 때까지 종료되지 않음을 나타내는 UNBOUNDED입니다. 잠금 해제가 발생하는 조건은 이후에 설명합니다.
각 옵션에 대한 허용되는 N 값의 범위는 0에서 32767입니다. 값이 0이면 해당 옵션을 비활성화합니다.
로그인 실패 추적 및 임시 계정 잠금에는 다음과 같은 특징이 있습니다:
계정에 대해 로그인 실패 추적과 임시 잠금이 발생하려면, 해당 계정의 FAILED_LOGIN_ATTEMPTS 및 PASSWORD_LOCK_TIME 옵션이 모두 0이 아니어야 합니다.
CREATE USER에서 FAILED_LOGIN_ATTEMPTS 또는 PASSWORD_LOCK_TIME를 지정하지 않으면, 해당 옵션의 암시적 기본값은 문에 의해 지정된 모든 계정에 대해 0입니다. 이는 로그인 실패 추적과 임시 계정 잠금이 비활성화된다는 의미입니다.
ALTER USER에서 FAILED_LOGIN_ATTEMPTS 또는 PASSWORD_LOCK_TIME를 지정하지 않으면, 해당 옵션 값은 문에 의해 지정된 모든 계정에 대해 변경되지 않은 상태로 유지됩니다.
임시 계정 잠금이 발생하려면 패스워드 실패가 연속적이어야 합니다. FAILED_LOGIN_ATTEMPTS에 도달하기 전에 성공적인 로그인 시도가 하나라도 발생하면 실패 횟수 카운트가 리셋됩니다. 예를 들어 FAILED_LOGIN_ATTEMPTS가 4이고 세 번 연속 패스워드 실패가 발생한 경우, 잠금을 시작하려면 하나의 실패가 더 필요합니다. 그러나 그다음 로그인이 성공하면 계정에 대한 로그인 실패 카운트가 리셋되며, 잠금이 발생하려면 다시 4번의 연속 실패가 필요합니다.
일단 임시 잠금이 시작되면, 잠금 기간이 지나거나 계정이 이후에 나열된 계정 리셋 방식 중 하나를 통해 잠금 해제될 때까지 올바른 패스워드를 사용하더라도 성공적인 로그인을 할 수 없습니다.
서버가 권한 부여 테이블을 읽을 때, 각 계정에 대해 로그인 실패 추적이 활성화되어 있는지, 계정이 현재 임시 잠금 상태인지와 그럴 경우 잠금이 시작된 시점, 계정이 잠겨 있지 않은 경우 임시 잠금이 발생하기 전까지의 실패 횟수에 대한 상태 정보를 초기화합니다.
계정 상태 정보는 리셋될 수 있으며, 이는 로그인 실패 카운트가 리셋되고, 계정이 현재 임시 잠금 상태라면 잠금 해제됨을 의미합니다. 계정 리셋은 모든 계정에 대한 전역 리셋이거나 계정별 리셋일 수 있습니다:
다음 조건 중 하나가 발생하면 모든 계정에 대한 전역 리셋이 발생합니다:
서버 재시작.
FLUSH PRIVILEGES 실행. (--skip-grant-tables 옵션으로 서버를 시작하면 권한 부여 테이블을 읽지 않으므로 로그인 실패 추적이 비활성화됩니다. 이 경우 FLUSH PRIVILEGES를 처음 실행하면 서버가 권한 부여 테이블을 읽고 로그인 실패 추적을 활성화하며, 모든 계정을 리셋합니다.)
다음 조건 중 하나가 발생하면 계정별 리셋이 발생합니다:
해당 계정에 대한 성공적인 로그인.
잠금 기간이 경과. 이 경우, 다음 로그인 시도 시점에 로그인 실패 카운트가 리셋됩니다.
해당 계정에 대해 ALTER USER 문을 실행하여 FAILED_LOGIN_ATTEMPTS 또는 PASSWORD_LOCK_TIME(또는 둘 다)을 어떤 값(현재 옵션 값 포함)으로 설정하거나, 해당 계정에 대해 ALTER USER ... UNLOCK 문을 실행하는 경우.
계정에 대한 다른 형태의 ALTER USER 문은 해당 계정의 현재 로그인 실패 카운트나 잠금 상태에 아무런 영향을 주지 않습니다.
로그인 실패 추적은 자격 증명을 확인하는 데 사용되는 로그인 계정에 연결됩니다. 사용자 프록시가 사용되는 경우, 추적은 프록시된 사용자가 아니라 프록시 사용자에 대해 이루어집니다. 즉, 추적은 CURRENT_USER()가 나타내는 계정이 아니라 USER()가 나타내는 계정에 연결됩니다. 프록시 및 프록시된 사용자 간의 차이에 대한 정보는 Section 8.2.19, “Proxy Users”를 참조하십시오.
8.2.14 Assigning Account Passwords
8.2.16 Server Handling of Expired Passwords