Loading...
MySQL 9.5 Reference Manual 9.5의 8.2.17 Pluggable Authentication의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
클라이언트가 MySQL 서버에 연결하면, 서버는 클라이언트가 제공한 사용자 이름과 클라이언트 호스트를 사용하여 mysql.user 시스템 테이블에서 적절한 계정 행을 선택합니다. 그런 다음 서버는 계정 행에서 어떤 인증 플러그인이 클라이언트에 적용되는지 확인하여 클라이언트를 인증합니다:
서버가 플러그인을 찾을 수 없으면 오류가 발생하고 연결 시도가 거부됩니다.
그렇지 않으면 서버는 해당 플러그인을 호출하여 사용자를 인증하고, 플러그인은 사용자가 올바른 패스워드를 제공했으며 연결이 허용되는지를 나타내는 상태를 서버에 반환합니다.
Pluggable authentication은 다음과 같은 중요한 기능을 가능하게 합니다:
Authentication method의 선택.
Pluggable authentication을 사용하면 DBA가 개별 MySQL 계정에 대해 사용되는 인증 방식을 쉽게 선택하고 변경할 수 있습니다.
External authentication.
Pluggable authentication을 사용하면 자격 증명을 mysql.user 시스템 테이블이 아닌 다른 곳에 저장하는 인증 방식에 적합한 자격 증명으로 클라이언트가 MySQL 서버에 연결할 수 있습니다. 예를 들어, PAM, Windows 로그인 ID, LDAP, Kerberos와 같은 외부 인증 방식을 사용하기 위한 플러그인을 생성할 수 있습니다.
Proxy users:
사용자가 연결을 허용받으면, 인증 플러그인은 연결하는 사용자의 이름과 다른 사용자 이름을 서버에 반환하여, 연결하는 사용자가 다른 사용자(proxyed user)의 프록시임을 나타낼 수 있습니다. 연결이 지속되는 동안, 프록시 사용자는 접근 제어의 목적상 proxyed user의 권한을 가진 것으로 취급됩니다. 사실상 한 사용자가 다른 사용자를 가장하는 것입니다. 자세한 내용은 Section 8.2.19, “Proxy Users”를 참조하십시오.
참고
서버를 --skip-grant-tables 옵션과 함께 시작하면, 서버는 어떠한 클라이언트 인증도 수행하지 않고 모든 클라이언트의 연결을 허용하므로, 로드되었더라도 인증 플러그인은 사용되지 않습니다. 이는 안전하지 않기 때문에, 서버가 --skip-grant-tables 옵션과 함께 시작되면, skip_networking을 활성화하여 원격 연결도 비활성화합니다.
MySQL 9.5는 다음과 같은 인증 플러그인을 제공합니다:
SHA-256 패스워드 해싱을 사용하여 인증을 수행하는 플러그인. 이는 기본 인증으로 제공되는 것보다 더 강력한 암호화입니다.
Section 8.4.1.1, “Caching SHA-2 Pluggable Authentication” 및
Section 8.4.1.2, “SHA-256 Pluggable Authentication”를 참조하십시오.
패스워드를 해싱이나 암호화 없이 서버로 전송하는 클라이언트 측 플러그인. 이 플러그인은 패스워드를 클라이언트 사용자가 제공한 그대로에 대한 접근을 필요로 하는 서버 측 플러그인과 함께 사용됩니다.
Section 8.4.1.3, “Client-Side Cleartext Pluggable Authentication”를 참조하십시오.
PAM(Pluggable Authentication Modules)을 사용하여 외부 인증을 수행하여 MySQL 서버가 PAM을 사용해 MySQL 사용자를 인증할 수 있게 하는 플러그인. 이 플러그인은 프록시 사용자도 지원합니다.
Windows에서 외부 인증을 수행하여 MySQL 서버가 기본 Windows 서비스를 사용해 클라이언트 연결을 인증할 수 있게 하는 플러그인. Windows에 로그인한 사용자는 추가 패스워드를 지정하지 않고, 환경에 있는 정보에 기반하여 MySQL 클라이언트 프로그램에서 서버로 연결할 수 있습니다. 이 플러그인은 프록시 사용자도 지원합니다.
Section 8.4.1.5, “Windows Pluggable Authentication”를 참조하십시오.
LDAP(Lightweight Directory Access Protocol)을 사용해 X.500과 같은 디렉터리 서비스에 접근하여 MySQL 사용자를 인증하는 플러그인. 이들 플러그인은 프록시 사용자도 지원합니다.
Kerberos를 사용해 Kerberos principal에 대응하는 MySQL 사용자를 인증하는 플러그인.
Section 8.4.1.7, “Kerberos Pluggable Authentication”를 참조하십시오.
OpenID Connect를 사용해 MySQL 사용자를 인증하는 플러그인.
Section 8.4.1.9, “OpenID Connect Pluggable Authentication”를 참조하십시오.
이를 사용하는 계정으로의 모든 클라이언트 연결을 차단하는 플러그인. 이 플러그인의 사용 사례에는 직접 로그인을 절대 허용해서는 안 되고 프록시 계정을 통해서만 접근되는 proxyed 계정과, 일반 사용자에게 그 권한을 노출하지 않고 상승된 권한으로 저장 프로그램과 뷰를 실행할 수 있어야 하는 계정이 포함됩니다.
Section 8.4.1.8, “No-Login Pluggable Authentication”를 참조하십시오.
Unix 소켓 파일을 통해 로컬 호스트에서 연결하는 클라이언트를 인증하는 플러그인.
Section 8.4.1.10, “Socket Peer-Credential Pluggable Authentication”를 참조하십시오.
FIDO/FIDO2 장치를 사용한 WebAuthn 포맷으로 MySQL 서버에 사용자를 인증하는 플러그인.
Section 8.4.1.11, “WebAuthn Pluggable Authentication”를 참조하십시오.
계정 자격 증명을 검사하고 성공 또는 실패를 서버 에러 로그에 기록하는 테스트 플러그인. 이 플러그인은 테스트 및 개발 목적으로, 그리고 인증 플러그인을 작성하는 방법의 예로 사용됩니다.
참고
어떤 커넥터가 어떤 플러그인을 지원하는지를 포함하여, pluggable authentication 사용에 대한 현재 제약 사항에 대한 정보는
Restrictions on Pluggable Authentication를 참조하십시오.
Third-party 커넥터 개발자는 커넥터가 pluggable authentication 기능을 어느 정도 활용할 수 있는지와 더 높은 호환성을 위해 어떤 단계를 밟아야 하는지 결정하기 위해 해당 섹션을 읽어야 합니다.
자체 인증 플러그인 작성에 관심이 있으면, Writing Authentication Plugins를 참조하십시오.
CREATE USER 및
ALTER USER 문에는 계정이 어떻게 인증되는지를 지정하기 위한 구문이 있습니다. 이 구문의 일부 형식은 인증 플러그인 이름을 명시적으로 지정하지 않습니다(IDENTIFIED WITH 절이 없음). 예를 들면 다음과 같습니다:
1CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'password';
이러한 경우 서버는 계정에 기본 인증 플러그인을 할당합니다. MySQL 9.5는 다중 요소 인증과, 계정이 어떻게 인증되는지를 지정하는 최대 세 개의 절을 지원합니다. 플러그인을 명명하지 않는 인증 방식에 대한 기본 인증 플러그인을 결정하는 규칙은 요소별입니다:
Factor 1:
authentication_policy 요소 1이 인증 플러그인을 명명하는 경우, 해당 플러그인이 기본값입니다.
authentication_policy 요소 1이 *이면, caching_sha2_password가 기본값입니다.
위 규칙에 따라, 다음 문장은 첫 번째 요소 인증 방식이
authentication_policy에 의해 결정되는 2요소 인증 계정을 생성합니다:
1CREATE USER 'wei'@'localhost' IDENTIFIED BY 'password' 2 AND IDENTIFIED WITH authentication_ldap_simple;
같은 방식으로, 다음 예제는 3요소 인증 계정을 생성합니다:
1CREATE USER 'mateo'@'localhost' IDENTIFIED BY 'password' 2 AND IDENTIFIED WITH authentication_ldap_simple 3 AND IDENTIFIED WITH authentication_fido;
SHOW CREATE USER를 사용하여 적용된 인증 방식을 볼 수 있습니다.
Factor 2 또는 3:
해당하는 authentication_policy 요소가 인증 플러그인을 명명하면, 그 플러그인이 기본값입니다.
authentication_policy 요소가 *이거나 비어 있으면 기본값이 없습니다. 이 요소에 대해 플러그인을 명명하지 않고 계정 인증 방식을 정의하려고 하면, 다음 예제와 같이 오류가 발생합니다:
1mysql> CREATE USER 'sofia'@'localhost' IDENTIFIED WITH authentication_ldap_simple 2 AND IDENTIFIED BY 'abc'; 3ERROR 1524 (HY000): Plugin '' is not loaded 4 5mysql> CREATE USER 'sofia'@'localhost' IDENTIFIED WITH authentication_ldap_simple 6 AND IDENTIFIED BY 'abc'; 7ERROR 1524 (HY000): Plugin '*' is not loaded
이 섹션은 인증 플러그인을 설치하고 사용하는 방법에 대한 일반적인 지침을 제공합니다. 개별 플러그인에 대한 구체적인 지침은
Section 8.4.1, “Authentication Plugins” 아래에서 해당 플러그인을 설명하는 섹션을 참조하십시오.
일반적으로 pluggable authentication은 서버 측과 클라이언트 측에 있는 쌍의 대응 플러그인을 사용하므로, 특정 인증 방식을 다음과 같이 사용합니다:
필요한 경우, 적절한 플러그인을 포함하는 플러그인 라이브러리를 설치합니다. 서버 호스트에는 서버 측 플러그인을 포함하는 라이브러리를 설치하여, 서버가 이를 사용해 클라이언트 연결을 인증할 수 있게 합니다. 마찬가지로, 각 클라이언트 호스트에는 클라이언트 프로그램에서 사용할 클라이언트 측 플러그인을 포함하는 라이브러리를 설치합니다. 내장 인증 플러그인은 설치할 필요가 없습니다.
생성하는 각 MySQL 계정에 대해, 인증에 사용할 적절한 서버 측 플러그인을 지정합니다. 계정이 기본 인증 플러그인을 사용하도록 할 경우, 계정 생성 문에서 플러그인을 명시적으로 지정할 필요가 없습니다. 서버는
The Default Authentication Plugin에 설명된 대로 결정되는 기본 인증 플러그인을 할당합니다.
클라이언트가 연결할 때, 서버 측 플러그인은 인증을 위해 어떤 클라이언트 측 플러그인을 사용할지 클라이언트 프로그램에 알려 줍니다.
계정이 서버와 클라이언트 프로그램 모두에 대해 기본인 인증 방식을 사용하는 경우, 서버는 클라이언트에 어떤 클라이언트 측 플러그인을 사용할지 통보할 필요가 없으며, 클라이언트/서버 협상에서 왕복을 피할 수 있습니다.
mysql 및 mysqladmin과 같은 표준 MySQL 클라이언트의 경우,
--default-auth=plugin_name 옵션을 커맨드라인에서 지정하여 프로그램이 사용할 것으로 예상하는 클라이언트 측 플러그인에 대한 힌트를 제공할 수 있습니다. 그러나 사용자 계정과 연관된 서버 측 플러그인이 다른 클라이언트 측 플러그인을 요구하는 경우, 서버가 이를 오버라이드합니다.
클라이언트 프로그램이 클라이언트 측 플러그인 라이브러리 파일을 찾지 못하면, 플러그인 라이브러리 디렉터리 위치를 나타내기 위해
--plugin-dir=dir_name 옵션을 지정하십시오.
Pluggable authentication은 MySQL 계정에 대한 인증 방식 선택에 유연성을 제공하지만, 경우에 따라 클라이언트와 서버 간 인증 플러그인 비호환성으로 인해 클라이언트 연결이 설정되지 못할 수 있습니다.
특정 계정에 대한 특정 서버로의 클라이언트 연결이 성공하기 위한 일반적인 호환성 원칙은, 클라이언트와 서버 둘 다 계정이 요구하는 인증 _방식_을 지원해야 한다는 것입니다. 인증 방식은 인증 플러그인에 의해 구현되므로, 클라이언트와 서버 둘 다 계정이 요구하는 인증 _플러그인_을 지원해야 합니다.
인증 플러그인 비호환성은 여러 방식으로 발생할 수 있습니다. 예:
MySQL 9.5 서버 계정에 caching_sha2_password로 인증하는 MySQL 5.7(5.7.22 이하) 클라이언트로 연결합니다. 이는 5.7 클라이언트가 해당 플러그인을 인식하지 못하기 때문에 실패합니다. (이 문제는 MySQL 클라이언트 라이브러리와 클라이언트 프로그램에 caching_sha2_password 클라이언트 측 지원이 추가된 MySQL 5.7.23부터 해결되었습니다.)
mysql_old_password로 인증하는 pre-5.7 서버 계정에 MySQL 5.7 클라이언트로 연결합니다. 이는 여러 이유로 실패합니다. 첫째, 이러한 연결에는 더 이상 지원되지 않는 옵션인 --secure-auth=0이 필요합니다. 설령 지원된다고 해도, 이 플러그인은 MySQL 5.7에서 제거되었기 때문에 5.7 클라이언트는 플러그인을 인식하지 못합니다.
Enterprise 전용 LDAP 인증 플러그인 중 하나를 사용해 인증하는 MySQL 5.7 Enterprise 서버 계정에 MySQL 5.7 Community 배포판 클라이언트로 연결합니다. 이는 Community 클라이언트가 Enterprise 플러그인에 접근할 수 없기 때문에 실패합니다.
일반적으로, 동일한 MySQL 배포판의 클라이언트와 서버 사이에서 연결이 이루어질 때는 이러한 호환성 문제가 발생하지 않습니다. 서로 다른 MySQL 시리즈의 클라이언트와 서버 사이에서 연결이 이루어질 때 문제는 발생할 수 있습니다.
이러한 문제는 MySQL이 새로운 인증 플러그인을 도입하거나 이전 것을 제거할 때 발생하는 개발 과정에 내재합니다. 비호환성 가능성을 최소화하려면, 서버, 클라이언트, 커넥터를 정기적으로 적시에 업그레이드하십시오.
MySQL 클라이언트/서버 프로토콜의 다양한 구현이 존재합니다. libmysqlclient C API 클라이언트 라이브러리는 한 가지 구현입니다. 일부 MySQL 커넥터(일반적으로 C로 작성되지 않은 것)는 자체 구현을 제공합니다. 그러나 모든 프로토콜 구현이 플러그인 인증을 동일한 방식으로 처리하는 것은 아닙니다. 이 섹션에서는 프로토콜 구현자가 고려해야 할 인증 관련 문제를 설명합니다.
클라이언트/서버 프로토콜에서, 서버는 연결하는 클라이언트에게 기본이라고 간주하는 인증 플러그인을 알려 줍니다. 클라이언트가 사용하는 프로토콜 구현이 기본 플러그인을 로드하려 시도하고, 해당 플러그인이 클라이언트 측에 존재하지 않으면, 로드 작업은 실패합니다. 기본 플러그인이 실제로 클라이언트가 연결하려는 계정에 요구되는 플러그인이 아닌 경우, 이는 불필요한 실패입니다.
클라이언트/서버 프로토콜 구현에 자체적인 기본 인증 플러그인 개념이 없고, 항상 서버에서 지정한 기본 플러그인을 로드하려고 하면, 해당 플러그인을 사용할 수 없을 때 오류로 실패합니다.
이 문제를 피하려면, 클라이언트에서 사용하는 프로토콜 구현은 자체 기본 플러그인을 가지고 있어야 하며, 이를 첫 번째 선택으로 사용해야 합니다(또는, 서버가 지정한 기본 플러그인을 로드하는 데 실패한 경우 이 기본값으로 폴백해야 합니다). 예:
MySQL 5.7에서, libmysqlclient는 기본 선택으로 mysql_native_password 또는 mysql_options()에 대한 MYSQL_DEFAULT_AUTH 옵션으로 지정된 플러그인을 사용합니다.
5.7 클라이언트가 9.5 서버에 연결을 시도할 때, 서버는 caching_sha2_password를 기본 인증 플러그인으로 지정하지만, 클라이언트는 여전히 자격 증명 정보를 mysql_native_password 또는 MYSQL_DEFAULT_AUTH로 지정된 플러그인에 따라 전송합니다.
클라이언트가 서버에 의해 지정된 플러그인을 로드하는 유일한 시점은 change-plugin 요청에 대해서이며, 이 경우 사용자 계정에 따라 어떤 플러그인이든 될 수 있습니다. 이 경우, 클라이언트는 플러그인을 로드하려고 시도해야 하며, 해당 플러그인을 사용할 수 없는 경우 오류가 발생하는 것은 피할 수 없습니다.
이 섹션의 첫 번째 부분에서는 Section 8.2.17, “Pluggable Authentication”에 설명된 pluggable authentication 프레임워크의 적용 가능성에 대한 일반적인 제약 사항을 설명합니다. 두 번째 부분에서는 third-party 커넥터 개발자가 커넥터가 pluggable authentication 기능을 어느 정도 활용할 수 있는지와 더 높은 호환성을 위해 어떤 단계를 밟아야 하는지를 결정하는 방법을 설명합니다.
여기서 사용되는 “native authentication”이라는 용어는 mysql.user 시스템 테이블에 저장된 패스워드에 대한 인증을 의미합니다. 이는 pluggable authentication이 구현되기 전의 이전 MySQL 서버가 제공하던 것과 동일한 인증 방식입니다. “Windows native authentication”은 Windows Native Authentication 플러그인(간단히 “Windows 플러그인”)이 구현한 대로, 이미 Windows에 로그인한 사용자의 자격 증명을 사용하여 인증하는 것을 의미합니다.
Connector/C++:
이 커넥터를 사용하는 클라이언트는 기본 인증을 사용하는 계정을 통해서만 서버에 연결할 수 있습니다.
예외: 커넥터가 libmysqlclient에 정적으로가 아니라 동적으로 링크되도록 빌드되고, 설치되어 있다면 현재 버전의 libmysqlclient를 로드하거나, 커넥터가 소스에서 재컴파일되어 현재 libmysqlclient에 링크된 경우, 해당 커넥터는 pluggable authentication을 지원합니다.
서버 측 기본 인증 플러그인에 대한 정보 처리를 위해 커넥터를 작성하는 방법에 대한 정보는
Authentication Plugin Connector-Writing Considerations를 참조하십시오.
Connector/NET:
Connector/NET을 사용하는 클라이언트는 기본 인증 또는 Windows 기본 인증을 사용하는 계정을 통해 서버에 연결할 수 있습니다.
Connector/PHP:
이 커넥터를 사용하는 클라이언트는 MySQL native driver for PHP(mysqlnd)로 컴파일된 경우, 기본 인증을 사용하는 계정을 통해서만 서버에 연결할 수 있습니다.
Windows native authentication:
Windows 플러그인을 사용하는 계정을 통한 연결에는 Windows 도메인 설정이 필요합니다. 도메인 설정 없이 사용하면 NTLM 인증이 사용되며, 이때 가능한 것은 로컬 연결뿐입니다. 즉, 클라이언트와 서버는 동일한 컴퓨터에서 실행되어야 합니다.
Proxy users:
프록시 사용자 지원은, 프록시 사용자 기능을 구현하는 플러그인(즉, 연결하는 사용자와 다른 사용자 이름을 반환할 수 있는 플러그인)으로 인증되는 계정을 통해 클라이언트가 연결할 수 있는 정도까지 가능합니다. 예를 들어, PAM과 Windows 플러그인은 프록시 사용자를 지원합니다. sha256_password 인증 플러그인은 기본적으로 프록시 사용자를 지원하지 않지만, 다음을 참조하여 이를 지원하도록 구성할 수 있습니다:
Replication:
레플리카는 기본 인증을 사용하는 레플리케이션 사용자 계정을 사용할 수 있을 뿐만 아니라, 필요한 클라이언트 측 플러그인이 사용 가능한 경우 비기본 인증을 사용하는 레플리케이션 사용자 계정을 통해서도 연결할 수 있습니다. 플러그인이 libmysqlclient에 내장되어 있으면 기본적으로 사용 가능합니다. 그렇지 않으면, 플러그인은 레플리카 측에서, 레플리카의 plugin_dir 시스템 변수에 지정된 디렉터리에 설치되어야 합니다.
FEDERATED tables:
FEDERATED 테이블은 원격 서버에서 기본 인증을 사용하는 계정을 통해서만 원격 테이블에 접근할 수 있습니다.
Third-party 커넥터 개발자는 다음 지침을 사용하여 커넥터가 pluggable authentication 기능을 활용할 준비가 되어 있는지와 더 높은 호환성을 위해 어떤 단계를 밟아야 하는지를 결정할 수 있습니다:
변경이 가해지지 않은 기존 커넥터는 기본 인증을 사용하며, 이 커넥터를 사용하는 클라이언트는 기본 인증을 사용하는 계정을 통해서만 서버에 연결할 수 있습니다.
그러나, 이러한 연결이 여전히 문제 없이 작동하는지 확인하기 위해 커넥터를 최신 버전의 서버에 대해 테스트해야 합니다.
예외: 커넥터가 libmysqlclient에 정적으로가 아니라 동적으로 링크되고, 설치되어 있다면 현재 버전의 libmysqlclient를 로드하는 경우, 변경 없이도 pluggable authentication에서 작동할 수 있습니다.
Pluggable authentication 기능을 활용하려면, libmysqlclient 기반 커넥터는 현재 버전의 libmysqlclient에 다시 링크되어야 합니다. 이렇게 하면, 이제 libmysqlclient에 내장된 클라이언트 측 플러그인(예: PAM 인증에 필요한 cleartext 플러그인과 Windows 기본 인증에 필요한 Windows 플러그인)을 요구하는 계정을 통해의 연결을 커넥터가 지원할 수 있습니다. 최신 libmysqlclient와 링크하면, 커넥터는 기본 MySQL 플러그인 디렉터리(일반적으로 로컬 서버의 plugin_dir 시스템 변수의 기본값으로 지정된 디렉터리)에 설치된 클라이언트 측 플러그인에 접근할 수 있게 됩니다.
커넥터가 libmysqlclient에 동적으로 링크되는 경우, 클라이언트 호스트에 최신 버전의 libmysqlclient가 설치되어 있고, 커넥터가 런타임에 이를 로드하도록 해야 합니다.
커넥터가 특정 인증 방식을 지원하는 또 다른 방법은 클라이언트/서버 프로토콜에 이를 직접 구현하는 것입니다. Connector/NET은 이 접근 방식을 사용하여 Windows 기본 인증 지원을 제공합니다.
커넥터가 기본 플러그인 디렉터리와 다른 디렉터리에서 클라이언트 측 플러그인을 로드할 수 있어야 하는 경우, 클라이언트 사용자가 디렉터리를 지정할 수 있는 수단을 구현해야 합니다. 이에 대한 가능성으로는 커넥터가 디렉터리 이름을 가져올 수 있는 커맨드라인 옵션 또는 환경 변수가 포함됩니다. mysql 및
mysqladmin과 같은 표준 MySQL 클라이언트 프로그램은 --plugin-dir 옵션을 구현합니다. 또한
C API Client Plugin Interface를 참조하십시오.
커넥터의 프록시 사용자 지원 여부는, 이 섹션 앞부분에서 설명한 대로, 해당 커넥터가 지원하는 인증 방식이 프록시 사용자를 허용하는지에 따라 달려 있습니다.
8.2.16 Server Handling of Expired Passwords
8.2.18 Multifactor Authentication
