Loading...
MySQL 9.5 Reference Manual 9.5의 8.2.19 Proxy Users의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
MySQL 서버는 인증 플러그인을 사용하여 클라이언트 연결을 인증합니다. 특정 연결을 인증하는 플러그인은 연결하는(외부) 사용자가 권한 검사 목적상 다른 사용자로 취급되도록 요청할 수 있습니다. 이는 외부 사용자가 두 번째 사용자의 proxy가 되도록, 즉 두 번째 사용자의 권한을 가정하도록 합니다:
외부 사용자는 “proxy user”(다른 사용자로 가장하거나 다른 사용자로 알려질 수 있는 사용자)입니다.
두 번째 사용자는 “proxied user”(그 신원과 권한이 proxy user에 의해 가정될 수 있는 사용자)입니다.
이 절에서는 proxy user 기능이 작동하는 방식을 설명합니다. 인증 플러그인에 대한 일반적인 정보는 Section 8.2.17, “Pluggable Authentication”을 참조하십시오. 개별 플러그인에 대한 정보는 Section 8.4.1, “Authentication Plugins”을 참조하십시오. proxy user를 지원하는 인증 플러그인을 작성하는 방법에 대한 정보는 Implementing Proxy User Support in Authentication Plugins를 참조하십시오.
참고
proxying으로 얻을 수 있는 하나의 관리상 이점은 DBA가 하나의 계정을 특정 권한 집합과 함께 설정한 다음, 여러 proxy user에게 개별적으로 권한을 할당하지 않고도 그 권한을 부여할 수 있다는 점입니다. proxy user의 대안으로, DBA는 role이 사용자를 특정 명명된 권한 집합에 매핑하는 데 적절한 방법이라고 판단할 수 있습니다. 각 사용자에게 특정 단일 role을 부여하여 사실상 적절한 권한 집합이 부여되도록 할 수 있습니다. Section 8.2.10, “Using Roles”을 참조하십시오.
특정 인증 플러그인에 대해 proxying이 발생하려면 다음 조건이 충족되어야 합니다:
Proxying은 플러그인 자체 또는 MySQL 서버가 플러그인을 대신하여 지원해야 합니다. 후자의 경우, 서버 지원을 명시적으로 활성화해야 할 수 있습니다. Server Support for Proxy User Mapping을 참조하십시오.
외부 proxy user용 계정은 플러그인에 의해 인증되도록 설정되어야 합니다. CREATE USER 구문을 사용하여 계정을 인증 플러그인과 연결하거나, ALTER USER를 사용하여 플러그인을 변경합니다.
proxied user용 계정은 존재해야 하고, proxy user가 가정할 권한을 부여받아야 합니다. 이를 위해 CREATE USER 및 GRANT 구문을 사용합니다.
일반적으로 proxied user는 직접 로그인 대신 proxying 시나리오에서만 사용되도록 구성됩니다.
proxy user 계정은 proxied 계정에 대한 PROXY 권한을 가져야 합니다. 이를 위해 GRANT 구문을 사용합니다.
proxy 계정에 연결하는 클라이언트가 proxy user로 취급되려면, 인증 플러그인은 클라이언트 사용자 이름과 다른 사용자 이름을 반환하여, proxy user가 가정해야 하는 권한을 정의하는 proxied 계정의 사용자 이름을 나타내야 합니다.
또는, 서버에 의해 proxy 매핑이 제공되는 플러그인의 경우, proxied user는 proxy user가 보유한 PROXY 권한으로부터 결정됩니다.
proxy 메커니즘은 외부 클라이언트 사용자 이름을 proxied 사용자 이름에 매핑하는 것만 허용합니다. 호스트 이름 매핑에 대한 지원은 없습니다:
클라이언트가 서버에 연결하면, 서버는 클라이언트 프로그램이 전달한 사용자 이름과 클라이언트가 연결하는 호스트를 기반으로 적절한 계정을 결정합니다.
해당 계정이 proxy 계정인 경우, 서버는 인증 플러그인이 반환한 사용자 이름과 proxy 계정의 호스트 이름을 사용하여 proxied 계정에 대한 일치 항목을 찾아 적절한 proxied 계정을 결정하려고 시도합니다. proxied 계정의 호스트 이름은 무시됩니다.
다음 계정 정의를 고려해 보십시오:
1-- create proxy account 2CREATE USER 'employee_ext'@'localhost' 3 IDENTIFIED WITH my_auth_plugin 4 AS 'my_auth_string'; 5 6-- create proxied account and grant its privileges; 7-- use mysql_no_login plugin to prevent direct login 8CREATE USER 'employee'@'localhost' 9 IDENTIFIED WITH mysql_no_login; 10GRANT ALL 11 ON employees.* 12 TO 'employee'@'localhost'; 13 14-- grant to proxy account the 15-- PROXY privilege for proxied account 16GRANT PROXY 17 ON 'employee'@'localhost' 18 TO 'employee_ext'@'localhost';
클라이언트가 로컬 호스트에서 employee_ext로 연결하면, MySQL은 my_auth_plugin이라는 플러그인을 사용하여 인증을 수행합니다. my_auth_plugin이 서버에 employee라는 사용자 이름을 반환한다고 가정해 봅시다. 이는 'my_auth_string'의 내용과, 필요하다면 일부 외부 인증 시스템을 참조하여 결정됩니다. 이름 employee는 employee_ext와 다르므로, employee를 반환하는 것은 서버에 대해, 권한 검사 목적상 외부 사용자 employee_ext를 로컬 사용자 employee로 취급해 달라는 요청 역할을 합니다.
이 경우, employee_ext는 proxy user이고 employee는 proxied user입니다.
서버는 employee_ext 사용자가 employee에 대해 proxy 인증을 수행할 수 있는지 확인하기 위해, employee_ext(proxy user)가 employee(proxied user)에 대한 PROXY 권한을 가지고 있는지 검사합니다. 이 권한이 부여되지 않았다면 에러가 발생합니다. 그렇지 않으면 employee_ext는 employee의 권한을 가정합니다. 서버는 클라이언트 세션 동안 employee_ext가 실행하는 구문을 employee에게 부여된 권한에 대해 검사합니다. 이 경우 employee_ext는 employees 데이터베이스의 테이블에 접근할 수 있습니다.
proxied 계정인 employee는 직접 로그인을 방지하기 위해 mysql_no_login 인증 플러그인을 사용합니다. (이는 플러그인이 설치되어 있다고 가정합니다. 설치 방법은 Section 8.4.1.8, “No-Login Pluggable Authentication”을 참조하십시오.) proxied 계정을 직접 사용하는 것에 대해 보호하는 대체 방법은 Preventing Direct Login to Proxied Accounts를 참조하십시오.
proxying이 발생하면, USER() 및 CURRENT_USER() 함수는 연결 사용자(proxy user)와 현재 세션 동안 권한이 적용되는 계정(proxied user) 간의 차이를 확인하는 데 사용할 수 있습니다. 방금 설명한 예제에서 이들 함수는 다음 값을 반환합니다:
1mysql> SELECT USER(), CURRENT_USER(); 2+------------------------+--------------------+ 3| USER() | CURRENT_USER() | 4+------------------------+--------------------+ 5| employee_ext@localhost | employee@localhost | 6+------------------------+--------------------+
proxy user 계정을 생성하는 CREATE USER 구문에서, proxy를 지원하는 인증 플러그인의 이름을 지정하는 IDENTIFIED WITH 절 뒤에는 선택적으로 AS 'auth_string' 절이 따라올 수 있으며, 여기서 서버는 사용자가 연결할 때 플러그인에 전달할 문자열을 지정합니다. 존재하는 경우, 이 문자열은 플러그인이 proxy(외부) 클라이언트 사용자 이름을 proxied 사용자 이름에 어떻게 매핑할지 결정하는 데 도움이 되는 정보를 제공합니다. AS 절의 필요 여부는 각 플러그인에 달려 있습니다. 그렇다면 인증 문자열의 형식은 플러그인이 이를 어떻게 사용할지에 따라 달라집니다. 특정 플러그인에 대해 허용되는 인증 문자열 값에 대한 정보는 해당 플러그인의 문서를 참조하십시오.
일반적으로 proxied 계정은 proxy 계정을 통해서만 사용되도록 의도됩니다. 즉, 클라이언트는 proxy 계정을 사용하여 연결한 다음, 적절한 proxied user로 매핑되어 그 권한을 가정합니다.
proxied 계정을 직접 사용할 수 없도록 보장하는 방법은 여러 가지가 있습니다:
계정을 mysql_no_login 인증 플러그인과 연결합니다. 이 경우, 어떤 상황에서도 계정을 사용하여 직접 로그인할 수 없습니다. 이는 플러그인이 설치되어 있다고 가정합니다. 설치 방법은 Section 8.4.1.8, “No-Login Pluggable Authentication”을 참조하십시오.
계정을 생성할 때 ACCOUNT LOCK 옵션을 포함합니다. Section 15.7.1.3, “CREATE USER Statement”를 참조하십시오. 이 방법을 사용하는 경우, 나중에 계정이 unlock되더라도 패스워드 없이 접근할 수 없도록 패스워드도 포함하십시오. (validate_password 컴포넌트가 활성화된 경우, 계정이 lock되어 있더라도 패스워드 없이 계정을 생성하는 것은 허용되지 않습니다. Section 8.4.4, “The Password Validation Component”를 참조하십시오.)
패스워드를 사용하여 계정을 생성하지만, 다른 누구에게도 패스워드를 알려주지 않습니다. 계정의 패스워드를 누구에게도 알리지 않으면, 클라이언트는 이를 사용하여 MySQL 서버에 직접 연결할 수 없습니다.
외부 사용자가 다른 사용자로 연결하고 그 사용자의 권한을 갖도록 하려면 PROXY 권한이 필요합니다. 이 권한을 부여하려면 GRANT 구문을 사용합니다. 예를 들면 다음과 같습니다:
1GRANT PROXY ON 'proxied_user' TO 'proxy_user';
이 구문은 mysql.proxies_priv 권한 테이블에 행을 생성합니다.
접속 시점에, _proxy_user_는 외부 인증된 유효한 MySQL 사용자를 나타내야 하고, _proxied_user_는 로컬로 인증된 유효한 사용자를 나타내야 합니다. 그렇지 않으면 연결 시도가 실패합니다.
이에 대응하는 REVOKE 구문은 다음과 같습니다:
1REVOKE PROXY ON 'proxied_user' FROM 'proxy_user';
MySQL GRANT 및 REVOKE 구문 확장은 평소와 같이 작동합니다. 예:
1-- grant PROXY to multiple accounts 2GRANT PROXY ON 'a' TO 'b', 'c', 'd'; 3 4-- revoke PROXY from multiple accounts 5REVOKE PROXY ON 'a' FROM 'b', 'c', 'd'; 6 7-- grant PROXY to an account and enable the account to grant 8-- PROXY to the proxied account 9GRANT PROXY ON 'a' TO 'd' WITH GRANT OPTION; 10 11-- grant PROXY to default proxy account 12GRANT PROXY ON 'a' TO ''@'';
PROXY 권한은 다음과 같은 경우에 부여될 수 있습니다:
_proxied_user_에 대해 GRANT PROXY ... WITH GRANT OPTION을 가진 사용자에 의해.
_proxied_user_가 자기 자신에 대해: USER()의 값은 사용자 이름과 호스트 이름 부분 모두에서 CURRENT_USER() 및 _proxied_user_와 정확히 일치해야 합니다.
MySQL 설치 중에 생성되는 초기 root 계정은 ''@'', 즉 모든 사용자와 모든 호스트에 대해 PROXY ... WITH GRANT OPTION 권한을 가집니다. 이는 root가 proxy user를 설정할 수 있게 할 뿐 아니라, 다른 계정에 proxy user를 설정할 권한을 위임할 수 있게 합니다. 예를 들어, root는 다음을 수행할 수 있습니다:
1CREATE USER 'admin'@'localhost' 2 IDENTIFIED BY 'admin_password'; 3GRANT PROXY 4 ON ''@'' 5 TO 'admin'@'localhost' 6 WITH GRANT OPTION;
이들 구문은 모든 GRANT PROXY 매핑을 관리할 수 있는 admin 사용자를 생성합니다. 예를 들어, admin은 다음을 수행할 수 있습니다:
1GRANT PROXY ON sally TO joe;
일부 또는 모든 사용자가 특정 인증 플러그인을 사용하여 연결하도록 지정하려면, 빈 사용자 이름과 호스트 이름(''@'')을 가진 “blank” MySQL 계정을 생성하여 해당 플러그인과 연결하고, 플러그인이 (blank 사용자와 다른 경우) 실제 인증된 사용자 이름을 반환하도록 합니다. LDAP 인증을 구현하고 연결 사용자를 developer 또는 manager 계정으로 매핑하는 ldap_auth라는 플러그인이 존재한다고 가정해 봅시다. 이 계정들로 사용자를 proxying하도록 설정하려면 다음 구문을 사용합니다:
1-- create default proxy account 2CREATE USER ''@'' 3 IDENTIFIED WITH ldap_auth 4 AS 'O=Oracle, OU=MySQL'; 5 6-- create proxied accounts; use 7-- mysql_no_login plugin to prevent direct login 8CREATE USER 'developer'@'localhost' 9 IDENTIFIED WITH mysql_no_login; 10CREATE USER 'manager'@'localhost' 11 IDENTIFIED WITH mysql_no_login; 12 13-- grant to default proxy account the 14-- PROXY privilege for proxied accounts 15GRANT PROXY 16 ON 'manager'@'localhost' 17 TO ''@''; 18GRANT PROXY 19 ON 'developer'@'localhost' 20 TO ''@'';
이제 클라이언트가 다음과 같이 연결한다고 가정합니다:
1$> mysql --user=myuser --password ... 2Enter password: myuser_password
서버는 myuser가 MySQL 사용자로 정의되어 있지 않음을 발견하지만, 클라이언트 사용자 이름과 호스트 이름에 일치하는 blank 사용자 계정(''@'')이 있기 때문에, 해당 계정에 대해 클라이언트를 인증합니다. 서버는 ldap_auth 인증 플러그인을 호출하고 myuser와 _myuser_password_를 사용자 이름과 패스워드로 플러그인에 전달합니다.
ldap_auth 플러그인이 LDAP 디렉터리에서 _myuser_password_가 myuser에 대한 올바른 패스워드가 아님을 발견하면, 인증은 실패하며 서버는 연결을 거부합니다.
패스워드가 올바르고 ldap_auth가 myuser가 developer임을 발견하면, 플러그인은 MySQL 서버에 myuser 대신 developer라는 사용자 이름을 반환합니다. 클라이언트 사용자 이름 myuser와 다른 사용자 이름을 반환하는 것은 서버에 myuser를 proxy로 취급해야 함을 알리는 신호입니다. 서버는 ''@''가 developer로 인증할 수 있는지( ''@''가 그렇게 할 PROXY 권한을 가지고 있기 때문에) 확인하고, 연결을 허용합니다. 세션은 myuser가 proxied user인 developer의 권한을 가진 채로 진행됩니다. (이 권한은 여기에는 표시되지 않은 GRANT 구문을 사용하여 DBA가 설정해야 합니다.) USER() 및 CURRENT_USER() 함수는 다음 값을 반환합니다:
1mysql> SELECT USER(), CURRENT_USER(); 2+------------------+---------------------+ 3| USER() | CURRENT_USER() | 4+------------------+---------------------+ 5| myuser@localhost | developer@localhost | 6+------------------+---------------------+
플러그인이 LDAP 디렉터리에서 myuser가 manager임을 대신 발견한다면, 플러그인은 사용자 이름으로 manager를 반환하고, 세션은 myuser가 proxied user manager의 권한을 가진 채로 진행됩니다.
1mysql> SELECT USER(), CURRENT_USER(); 2+------------------+-------------------+ 3| USER() | CURRENT_USER() | 4+------------------+-------------------+ 5| myuser@localhost | manager@localhost | 6+------------------+-------------------+
단순화를 위해, 외부 인증은 다단계가 될 수 없습니다. 앞선 예제에서 developer나 manager의 자격 증명은 고려되지 않습니다. 그러나 클라이언트가 developer나 manager 계정으로 직접 연결 및 인증을 시도하는 경우에는 여전히 사용되므로, 이러한 proxied 계정은 직접 로그인으로부터 보호되어야 합니다( Preventing Direct Login to Proxied Accounts 참조).
default proxy user를 생성하려는 경우, default proxy user가 의도한 대로 작동하지 못하게 할 수 있는, default proxy user보다 우선하는 다른 기존의 “어떤 사용자와도 일치”하는 계정이 있는지 확인하십시오.
앞선 설명에서, default proxy user 계정은 호스트 부분에 ''를 가지며, 이는 어떤 호스트와도 일치합니다. default proxy user를 설정하는 경우, 동일한 사용자 부분과 호스트 부분에 '%'를 가진 nonproxy 계정이 존재하는지도 확인해야 합니다. '%' 역시 모든 호스트와 일치하지만, 서버가 내부적으로 계정 행을 정렬하는 데 사용하는 규칙에 의해 ''보다 우선하기 때문입니다( Section 8.2.6, “Access Control, Stage 1: Connection Verification” 참조).
MySQL 설치에 다음 두 계정이 포함되어 있다고 가정해 봅시다:
1-- create default proxy account 2CREATE USER ''@'' 3 IDENTIFIED WITH some_plugin 4 AS 'some_auth_string'; 5-- create anonymous account 6CREATE USER ''@'%' 7 IDENTIFIED BY 'anon_user_password';
첫 번째 계정(''@'')은 default proxy user로, 보다 구체적인 계정과 일치하지 않는 사용자의 연결을 인증하는 데 사용됩니다. 두 번째 계정(''@'%')은 anonymous-user 계정으로, 예를 들어 자체 계정이 없는 사용자가 익명으로 연결할 수 있게 하려고 생성되었을 수 있습니다.
두 계정 모두 어떤 사용자와도 일치하는 동일한 사용자 부분('')을 가지고 있습니다. 그리고 각 계정은 어떤 호스트와도 일치하는 호스트 부분을 가집니다. 그럼에도 불구하고, 연결 시도에 대한 계정 매칭에는 우선순위가 있는데, 매칭 규칙은 호스트가 '%'인 계정을 ''보다 먼저 정렬합니다. 보다 구체적인 계정과 일치하지 않는 계정의 경우, 서버는 ''@''(default proxy user)보다 ''@'%'(anonymous user)에 대해 인증을 시도합니다. 결과적으로 default proxy 계정은 절대 사용되지 않습니다.
이 문제를 피하려면, 다음 전략 중 하나를 사용하십시오:
default proxy user와 충돌하지 않도록 anonymous 계정을 제거합니다.
anonymous user보다 앞서 일치하는 보다 구체적인 default proxy user를 사용합니다. 예를 들어, localhost proxy 연결만 허용하려면 ''@'localhost'를 사용합니다:
1CREATE USER ''@'localhost' 2 IDENTIFIED WITH some_plugin 3 AS 'some_auth_string';
또한, 모든 GRANT PROXY 구문을 수정하여 proxy user로 ''@'' 대신 ''@'localhost'를 지정하십시오.
이 전략은 localhost에서의 anonymous-user 연결을 방지한다는 점에 유의하십시오.
anonymous default 계정 대신 명명된 default 계정을 사용합니다. 이 기법의 예는 authentication_windows 플러그인 사용 지침을 참조하십시오. Section 8.4.1.5, “Windows Pluggable Authentication”를 참조하십시오.
하나는 로컬 연결용, 다른 하나는 “그 외 모든 것”(원격 연결)용 proxy user를 여러 개 생성합니다. 이는 특히 로컬 사용자가 원격 사용자와 다른 권한을 가져야 할 때 유용할 수 있습니다.
proxy user를 생성합니다:
1 -- create proxy user for local connections 2CREATE USER ''@'localhost' 3 IDENTIFIED WITH some_plugin 4 AS 'some_auth_string'; 5 -- create proxy user for remote connections 6CREATE USER ''@'%' 7 IDENTIFIED WITH some_plugin 8 AS 'some_auth_string';
proxied user를 생성합니다:
1 -- create proxied user for local connections 2CREATE USER 'developer'@'localhost' 3 IDENTIFIED WITH mysql_no_login; 4 -- create proxied user for remote connections 5CREATE USER 'developer'@'%' 6 IDENTIFIED WITH mysql_no_login;
각 proxy 계정에 대해 해당 proxied 계정에 대한 PROXY 권한을 부여합니다:
1GRANT PROXY 2 ON 'developer'@'localhost' 3 TO ''@'localhost'; 4GRANT PROXY 5 ON 'developer'@'%' 6 TO ''@'%';
마지막으로, 로컬 및 원격 proxied user에 적절한 권한을 부여합니다(표시하지 않음).
some_plugin/'some_auth_string' 조합이 some_plugin이 클라이언트 사용자 이름을 developer로 매핑하도록 한다고 가정합니다. 로컬 연결은 ''@'localhost' proxy user와 일치하며, 이는 'developer'@'localhost' proxied user로 매핑됩니다. 원격 연결은 ''@'%' proxy user와 일치하며, 이는 'developer'@'%' proxied user로 매핑됩니다.
일부 인증 플러그인은 (예: PAM 및 Windows 인증 플러그인) 자체적으로 proxy user 매핑을 구현합니다. 다른 인증 플러그인은 기본적으로 proxy user를 지원하지 않습니다. sha256_password는 MySQL 서버 자체가 부여된 proxy 권한에 따라 proxy user를 매핑하도록 요청할 수 있습니다. check_proxy_users 시스템 변수이 활성화되면, 서버는 그러한 요청을 하는 모든 인증 플러그인에 대해 proxy user 매핑을 수행합니다:
기본적으로 check_proxy_users는 비활성화되어 있으므로, 서버는 proxy user에 대한 서버 지원을 요청하는 인증 플러그인에 대해서도 proxy user 매핑을 수행하지 않습니다.
check_proxy_users가 활성화된 경우, 서버 proxy user 매핑 지원을 활용하려면 플러그인별 시스템 변수도 활성화해야 할 수 있습니다. sha256_password 플러그인의 경우, sha256_password_proxy_users를 활성화합니다.
앞서 언급한 모든 기능을 활성화하려면, my.cnf 파일에 다음 줄을 넣어 서버를 시작합니다:
1[mysqld] 2check_proxy_users=ON 3sha256_password_proxy_users=ON
관련 시스템 변수가 활성화되어 있다고 가정하고, 일반적으로 CREATE USER를 사용하여 proxy user를 생성한 다음, proxy user로 취급될 단일 다른 계정에 대한 PROXY 권한을 부여합니다. 서버가 proxy user에 대한 성공적인 연결 요청을 받으면, 해당 사용자가 PROXY 권한을 가지고 있음을 발견하고 이를 사용하여 적절한 proxied user를 결정합니다.
1-- create proxy account 2CREATE USER 'proxy_user'@'localhost' 3 IDENTIFIED WITH sha256_password 4 BY 'password'; 5 6-- create proxied account and grant its privileges; 7-- use mysql_no_login plugin to prevent direct login 8CREATE USER 'proxied_user'@'localhost' 9 IDENTIFIED WITH mysql_no_login; 10-- grant privileges to proxied account 11GRANT ... 12 ON ... 13 TO 'proxied_user'@'localhost'; 14 15-- grant to proxy account the 16-- PROXY privilege for proxied account 17GRANT PROXY 18 ON 'proxied_user'@'localhost' 19 TO 'proxy_user'@'localhost';
proxy 계정을 사용하려면, 해당 이름과 패스워드를 사용하여 서버에 연결합니다:
1$> mysql -u proxy_user -p 2Enter password: (enter proxy_user password here)
인증이 성공하면, 서버는 proxy_user가 proxied_user에 대한 PROXY 권한을 가지고 있음을 발견하고, 세션은 proxy_user가 proxied_user의 권한을 가진 채로 진행됩니다.
서버에 의해 수행되는 proxy user 매핑에는 다음과 같은 제한이 적용됩니다:
서버는 연관된 PROXY 권한이 부여되었다 하더라도 anonymous user로의 proxy 또는 anonymous user로부터의 proxy를 수행하지 않습니다.
단일 계정이 둘 이상의 proxied 계정에 대한 proxy 권한을 부여받은 경우, 서버 proxy user 매핑은 비결정적입니다. 따라서 단일 계정에 여러 proxied 계정에 대한 proxy 권한을 부여하는 것은 권장되지 않습니다.
두 개의 시스템 변수는 proxy 로그인 과정을 추적하는 데 도움이 됩니다:
proxy_user: proxying이 사용되지 않는 경우 이 값은 NULL입니다. 그렇지 않으면 proxy user 계정을 나타냅니다. 예를 들어, 클라이언트가 ''@'' proxy 계정을 통해 인증하는 경우, 이 변수는 다음과 같이 설정됩니다:1mysql> SELECT @@proxy_user; 2+--------------+ 3| @@proxy_user | 4+--------------+ 5| ''@'' | 6+--------------+
external_user: 때로 인증 플러그인은 MySQL 서버에 인증하기 위해 외부 사용자를 사용할 수 있습니다. 예를 들어, Windows 네이티브 인증을 사용할 때, Windows API를 사용하여 인증하는 플러그인은 전달된 로그인 ID를 필요로 하지 않을 수 있습니다. 그러나 여전히 Windows 사용자 ID를 사용하여 인증합니다. 플러그인은 이 외부 사용자 ID(또는 그 첫 512 UTF-8 바이트)를 external_user 읽기 전용 세션 변수를 사용하여 서버에 반환할 수 있습니다. 플러그인이 이 변수를 설정하지 않으면, 그 값은 NULL입니다.8.2.18 Multifactor Authentication
8.2.20 Account Locking