Loading...
MySQL 9.5 Reference Manual 9.5의 8.3.1 Configuring MySQL to Use Encrypted Connections의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
암호화된 연결을 사용할지 여부를 지정하고, 적절한 certificate 및 key 파일을 지정하기 위한 여러 구성 파라미터가 제공됩니다. 이 섹션은 암호화된 연결을 위해 서버 및 클라이언트를 구성하는 방법에 대한 일반적인 지침을 제공합니다:
암호화된 연결은 다음의 추가 섹션에서 설명하는 것처럼 다른 컨텍스트에서도 사용될 수 있습니다:
source 및 replica 복제 서버 간. Section 19.3.1, “Setting Up Replication to Use Encrypted Connections”를 참조하십시오.
Group Replication 서버 간. Section 20.6.2, “Securing Group Communication Connections with Secure Socket Layer (SSL)”를 참조하십시오.
MySQL C API를 기반으로 하는 클라이언트 프로그램에서. Support for Encrypted Connections를 참조하십시오.
필요한 certificate 및 key 파일을 생성하는 방법에 대한 설명은 Section 8.3.3, “Creating SSL and RSA Certificates and Keys”에 나와 있습니다.
클라이언트가 암호화된 연결을 사용하여 접속하도록 요구하려면, require_secure_transport 시스템 변수를 활성화하십시오. Configuring Encrypted Connections as Mandatory를 참조하십시오.
서버 측의 다음 시스템 변수는 클라이언트가 암호화된 연결을 설정할 수 있도록 허용할 때 서버가 사용하는 certificate 및 key 파일을 지정합니다:
ssl_ca: Certificate Authority (CA) certificate 파일의 경로명. (ssl_capath는 유사하지만 CA certificate 파일들이 있는 디렉터리의 경로명을 지정합니다.)
ssl_cert: 서버 공개키 certificate 파일의 경로명. 이 certificate는 클라이언트로 전송될 수 있으며, 클라이언트가 가지고 있는 CA certificate에 대해 인증을 수행할 수 있습니다.
ssl_key: 서버 개인키 파일의 경로명입니다.
예를 들어, 서버에서 암호화된 연결을 활성화하려면, my.cnf 파일에 다음과 같이 설정하여 서버를 시작합니다. 필요에 따라 파일 이름을 변경하십시오:
1[mysqld] 2ssl_ca=ca.pem 3ssl_cert=server-cert.pem 4ssl_key=server-key.pem
추가로 클라이언트가 암호화된 연결을 사용하도록 요구하려면, require_secure_transport 시스템 변수를 활성화하십시오:
1[mysqld] 2ssl_ca=ca.pem 3ssl_cert=server-cert.pem 4ssl_key=server-key.pem 5require_secure_transport=ON
각 certificate 및 key 시스템 변수는 PEM 포맷의 파일을 지정합니다. 필요한 certificate 및 key 파일을 생성해야 하는 경우, Section 8.3.3, “Creating SSL and RSA Certificates and Keys”를 참조하십시오. OpenSSL을 사용하여 컴파일된 MySQL 서버는 시작 시 누락된 certificate 및 key 파일을 자동으로 생성할 수 있습니다. Section 8.3.3.1, “Creating SSL and RSA Certificates and Keys using MySQL”를 참조하십시오. 또는 MySQL 소스 배포본이 있는 경우, mysql-test/std_data 디렉터리에 있는 demonstration certificate 및 key 파일을 사용해 설정을 테스트할 수 있습니다.
서버는 certificate 및 key 파일 자동 검색을 수행합니다. 암호화된 연결을 설정하기 위한 명시적인 옵션이 제공되지 않으면, 서버는 시작 시 암호화된 연결 지원을 자동으로 활성화하려고 시도합니다:
서버가 데이터 디렉터리에서 ca.pem, server-cert.pem, server-key.pem이라는 이름의 유효한 certificate 및 key 파일을 발견하면, 클라이언트의 암호화된 연결 지원을 활성화합니다. (파일이 자동으로 생성되었는지는 중요하지 않습니다. 중요한 것은 파일 이름이 이와 같고 유효해야 한다는 점입니다.)
서버가 데이터 디렉터리에서 유효한 certificate 및 key 파일을 찾지 못하면, 암호화된 연결 지원 없이 실행을 계속합니다.
서버가 자동으로 암호화된 연결 지원을 활성화하면, 에러 로그에 노트를 기록합니다. 서버가 CA certificate가 self-signed임을 발견하면, 에러 로그에 경고를 기록합니다. (certificate가 서버에 의해 자동으로 생성된 경우 self-signed입니다.)
MySQL은 서버 측 암호화된 연결 제어를 위해 다음 시스템 변수도 제공합니다:
ssl_cipher: 연결 암호화를 위한 허용 cipher 목록입니다.
ssl_crl: certificate revocation list가 포함된 파일의 경로명. (ssl_crlpath는 유사하지만 certificate revocation-list 파일들이 있는 디렉터리의 경로명을 지정합니다.)
tls_version, tls_ciphersuites: 서버가 암호화된 연결을 위해 허용하는 암호화 프로토콜 및 ciphersuite입니다. Section 8.3.2, “Encrypted Connection TLS Protocols and Ciphers”를 참조하십시오. 예를 들어, tls_version을 구성하여 클라이언트가 보안 수준이 낮은 프로토콜을 사용하지 못하도록 할 수 있습니다.
서버가 서버 측 암호화된 연결 제어를 위한 시스템 변수로부터 유효한 TLS 컨텍스트를 생성할 수 없는 경우, 암호화된 연결 지원 없이 실행됩니다.
tls_xxx 및 ssl_xxx 시스템 변수는 동적이며 시작 시뿐 아니라 런타임에도 설정할 수 있습니다. SET GLOBAL로 변경하면, 새로운 값은 서버가 재시작될 때까지만 적용됩니다. SET PERSIST로 변경하면, 새로운 값은 이후 서버 재시작에도 적용됩니다. Section 15.7.6.1, “SET Syntax for Variable Assignment”를 참조하십시오. 그러나 이 변수들에 대한 런타임 변경은, 이 섹션에서 나중에 설명하는 것처럼, 새로운 연결에 대한 TLS 컨텍스트에 즉시 영향을 주지 않습니다.
TLS 컨텍스트 관련 시스템 변수에 대한 런타임 변경을 허용하는 변경과 함께, 서버는 새로운 연결에 대해 사용되는 실제 TLS 컨텍스트에 대한 런타임 업데이트도 허용합니다. 이 기능은 예를 들어, SSL certificate가 만료될 만큼 오랫동안 실행 중인 MySQL 서버를 재시작하지 않기 위해 유용할 수 있습니다.
초기 TLS 컨텍스트를 생성하기 위해, 서버는 시작 시 컨텍스트 관련 시스템 변수가 가진 값을 사용합니다. 컨텍스트 값을 노출하기 위해, 서버는 해당하는 상태 변수 집합도 초기화합니다. 다음 표는 TLS 컨텍스트를 정의하는 시스템 변수와 현재 활성 컨텍스트 값을 노출하는 대응 상태 변수를 보여줍니다.
Table 8.12 System and Status Variables for Server Main Connection Interface TLS Context
이 활성 TLS 컨텍스트 값은 Performance Schema tls_channel_status 테이블에서도 프로퍼티로 노출되며, 다른 활성 TLS 컨텍스트의 프로퍼티와 함께 제공됩니다.
런타임에 TLS 컨텍스트를 재구성하려면, 다음 절차를 사용하십시오:
변경해야 할 각 TLS 컨텍스트 관련 시스템 변수를 새로운 값으로 설정합니다.
ALTER INSTANCE RELOAD TLS를 실행합니다. 이 구문은 TLS 컨텍스트 관련 시스템 변수의 현재 값에서 활성 TLS 컨텍스트를 재구성합니다. 또한 컨텍스트 관련 상태 변수를 설정하여 새로운 활성 컨텍스트 값을 반영합니다. 이 구문에는 CONNECTION_ADMIN 권한이 필요합니다.
ALTER INSTANCE RELOAD TLS 실행 이후에 설정된 새로운 연결은 새로운 TLS 컨텍스트를 사용합니다. 기존 연결은 영향을 받지 않습니다. 기존 연결을 종료해야 하는 경우, KILL 구문을 사용하십시오.
재구성 절차가 동작하는 방식 때문에, 각 시스템 및 상태 변수 쌍의 멤버는 일시적으로 서로 다른 값을 가질 수 있습니다:
ALTER INSTANCE RELOAD TLS 이전의 시스템 변수 변경은 TLS 컨텍스트를 변경하지 않습니다. 이 시점에서 이러한 변경은 새로운 연결에 영향을 주지 않으며, 대응되는 컨텍스트 관련 시스템 및 상태 변수는 다른 값을 가질 수 있습니다. 이로 인해 개별 시스템 변수에 필요한 변경을 수행한 후, 모든 시스템 변수 변경이 완료된 뒤 ALTER INSTANCE RELOAD TLS로 활성 TLS 컨텍스트를 원자적으로 업데이트할 수 있습니다.
ALTER INSTANCE RELOAD TLS 이후에는, 대응되는 시스템 및 상태 변수가 동일한 값을 가집니다. 이는 다음 시스템 변수 변경까지 유지됩니다.
일부 경우에는, 시스템 변수를 변경하지 않고도 ALTER INSTANCE RELOAD TLS만으로 TLS 컨텍스트를 재구성할 수 있습니다. 예를 들어, ssl_cert에 의해 지정된 파일의 certificate가 만료된 경우를 가정해 봅니다. 기존 파일 내용을 만료되지 않은 certificate로 교체하고, ALTER INSTANCE RELOAD TLS를 실행하는 것만으로도 새로운 파일 내용이 읽혀서 새로운 연결에 사용되도록 할 수 있습니다.
서버는 administrative connection interface에 대해 독립적인 connection-encryption 구성을 구현합니다. Administrative Interface Support for Encrypted Connections를 참조하십시오. 또한 ALTER INSTANCE RELOAD TLS는 TLS 컨텍스트를 재로드할 채널(interface)을 지정할 수 있도록 FOR CHANNEL 절로 확장되었습니다. Section 15.1.5, “ALTER INSTANCE Statement”를 참조하십시오. administrative interface TLS 컨텍스트를 노출하는 상태 변수는 없지만, Performance Schema tls_channel_status 테이블은 main 및 administrative interface 모두에 대한 TLS 프로퍼티를 노출합니다. Section 29.12.22.11, “The tls_channel_status Table”를 참조하십시오.
main interface TLS 컨텍스트를 업데이트하면 다음과 같은 효과가 있습니다:
업데이트는 main connection interface에서 새로운 연결에 사용되는 TLS 컨텍스트를 변경합니다.
업데이트는 또한 administrative interface에서 새로운 연결에 사용되는 TLS 컨텍스트도 변경합니다. 단, 해당 interface에 대해 nondefault TLS 파라미터 값이 구성되어 있지 않은 경우에만 그렇습니다.
업데이트는 Group Replication이나 X Plugin과 같은 다른 활성화된 서버 플러그인 또는 컴포넌트가 사용하는 TLS 컨텍스트에는 영향을 주지 않습니다:
main interface 재구성을 Group Replication의 group communication 연결에 적용하려면, 해당 연결이 서버의 TLS 컨텍스트 관련 시스템 변수 설정을 사용하므로, Group Replication을 중지 및 재시작하기 위해 STOP GROUP_REPLICATION 다음에 START GROUP_REPLICATION를 실행해야 합니다.
X Plugin은 Section 22.5.3, “Using Encrypted Connections with X Plugin”에 설명된 대로 플러그인 초기화 시 TLS 컨텍스트를 초기화합니다. 이 컨텍스트는 이후 변경되지 않습니다.
기본적으로, RELOAD TLS 액션은 configuration 값으로 인해 새로운 TLS 컨텍스트를 생성할 수 없는 경우 에러와 함께 롤백되며 아무런 효과도 발생시키지 않습니다. 이 경우 이전 컨텍스트 값이 새로운 연결에 대해 계속 사용됩니다. 선택적인 NO ROLLBACK ON ERROR 절이 주어졌는데 새 컨텍스트를 생성할 수 없는 경우, 롤백은 발생하지 않습니다. 대신 경고가 생성되며, 구문이 적용되는 interface에 대해 새로운 연결의 암호화가 비활성화됩니다.
connection interface에서 암호화된 연결을 활성화 또는 비활성화하는 옵션은 시작 시에만 효과가 있습니다. 예를 들어, --tls-version 및 --admin-tls-version 옵션은 main 및 administrative interface가 해당 TLS 버전을 지원하는지 여부를 시작 시에만 영향을 줍니다. 이러한 옵션은 런타임에서 ALTER INSTANCE RELOAD TLS 동작에 영향을 주지 않으며 무시됩니다. 예를 들어, tls_version=''으로 설정하여 main interface에서 암호화된 연결이 비활성화된 상태로 서버를 시작한 다음, TLS를 재구성하고 ALTER INSTANCE RELOAD TLS를 실행하여 런타임에 암호화된 연결을 활성화할 수 있습니다.
암호화된 연결 수립과 관련된 클라이언트 옵션의 전체 목록은 Command Options for Encrypted Connections을 참조하십시오.
기본적으로, MySQL 클라이언트 프로그램은 서버가 암호화된 연결을 지원하면 암호화된 연결을 수립하려고 시도하며, --ssl-mode 옵션을 통해 추가 제어가 가능합니다:
--ssl-mode 옵션이 없는 경우, 클라이언트는 암호화를 사용하여 연결을 시도하며, 암호화된 연결을 수립할 수 없으면 암호화되지 않은 연결로 폴백합니다. 이는 명시적으로 --ssl-mode=PREFERRED 옵션을 사용했을 때의 동작과 동일합니다.
--ssl-mode=REQUIRED를 사용하면, 클라이언트는 암호화된 연결을 요구하며, 암호화된 연결을 수립할 수 없는 경우 실패합니다.
--ssl-mode=DISABLED를 사용하면, 클라이언트는 암호화되지 않은 연결을 사용합니다.
--ssl-mode=VERIFY_CA 또는 --ssl-mode=VERIFY_IDENTITY를 사용하면, 클라이언트는 암호화된 연결을 요구하며, 서버 CA certificate에 대한 검증을 수행하고, VERIFY_IDENTITY의 경우 certificate의 서버 호스트 이름에 대해서도 검증을 수행합니다.
주의
기본 설정인 --ssl-mode=PREFERRED는 다른 기본 설정이 변경되지 않은 경우 암호화된 연결을 생성합니다. 그러나 고급 man-in-the-middle 공격을 방지하려면, 클라이언트가 서버의 identity를 검증하는 것이 중요합니다. --ssl-mode=VERIFY_CA 및 --ssl-mode=VERIFY_IDENTITY는 이러한 유형의 공격을 방지하는 데 기본 설정보다 더 좋은 선택입니다. VERIFY_CA는 클라이언트가 서버 certificate가 유효한지 확인하도록 합니다. VERIFY_IDENTITY는 클라이언트가 서버 certificate가 유효한지 확인할 뿐만 아니라, 클라이언트가 사용하는 호스트 이름이 서버 certificate의 identity와 일치하는지도 확인하도록 합니다. 이러한 설정 중 하나를 구현하려면, 먼저 해당 서버에 대한 CA certificate를 이 환경에서 이를 사용하는 모든 클라이언트가 신뢰할 수 있는 방식으로 사용할 수 있도록 보장해야 하며, 그렇지 않으면 가용성 문제가 발생합니다. 이러한 이유로 이들은 기본 설정이 아닙니다.
암호화되지 않은 연결을 설정하려는 시도는, 서버 측에서 require_secure_transport 시스템 변수가 활성화되어 서버가 암호화된 연결을 요구하도록 설정된 경우 실패합니다. Configuring Encrypted Connections as Mandatory를 참조하십시오.
클라이언트 측의 다음 옵션은 서버에 대한 암호화된 연결을 설정할 때 클라이언트가 사용하는 certificate 및 key 파일을 식별합니다. 이들은 서버 측에서 사용하는 ssl_ca, ssl_cert, ssl_key 시스템 변수와 유사하지만, --ssl-cert 및 --ssl-key는 클라이언트의 공개 및 개인키를 지정합니다:
--ssl-ca: Certificate Authority (CA) certificate 파일의 경로명입니다. 이 옵션을 사용하는 경우, 서버에서 사용하는 certificate와 동일한 certificate를 지정해야 합니다. (--ssl-capath는 유사하지만 CA certificate 파일들이 있는 디렉터리의 경로명을 지정합니다.)
--ssl-cert: 클라이언트 공개키 certificate 파일의 경로명입니다.
--ssl-key: 클라이언트 개인키 파일의 경로명입니다.
기본 암호화가 제공하는 것보다 추가적인 보안을 위해, 클라이언트는 서버가 사용하는 것과 일치하는 CA certificate를 제공하고 호스트 이름 identity 검증을 활성화할 수 있습니다. 이렇게 하면, 서버와 클라이언트는 동일한 CA certificate에 신뢰를 두고, 클라이언트는 연결 대상 호스트가 의도된 대상인지 확인합니다:
CA certificate를 지정하려면 --ssl-ca (또는 --ssl-capath)를 사용하고, --ssl-mode=VERIFY_CA를 지정하십시오.
호스트 이름 identity 검증도 활성화하려면 --ssl-mode=VERIFY_CA 대신 --ssl-mode=VERIFY_IDENTITY를 사용하십시오.
참고
VERIFY_IDENTITY를 사용한 호스트 이름 identity 검증은 서버에 의해 자동으로 생성되는 self-signed certificate에서는 동작하지 않습니다 (Section 8.3.3.1, “Creating SSL and RSA Certificates and Keys using MySQL”를 참조하십시오). 이러한 self-signed certificate에는 서버 이름이 Common Name 값으로 포함되어 있지 않습니다.
MySQL은 클라이언트 측 암호화된 연결 제어를 위해 다음 옵션도 제공합니다:
--ssl-cipher: 연결 암호화를 위한 허용 cipher 목록입니다.
--ssl-crl: certificate revocation list가 포함된 파일의 경로명입니다. (--ssl-crlpath는 유사하지만 certificate revocation-list 파일들이 있는 디렉터리의 경로명을 지정합니다.)
--tls-version, --tls-ciphersuites: 허용되는 암호화 프로토콜 및 ciphersuite입니다. Section 8.3.2, “Encrypted Connection TLS Protocols and Ciphers”를 참조하십시오.
클라이언트가 사용하는 MySQL 계정의 암호화 요구 사항에 따라, 클라이언트는 MySQL 서버에 암호화된 연결로 접속하기 위해 특정 옵션을 지정해야 할 수 있습니다.
특별한 암호화 요구 사항이 없는 계정 또는 REQUIRE SSL 절을 포함하는 CREATE USER 구문을 사용해 생성된 계정을 사용해 접속하려 한다고 가정해 봅니다. 서버가 암호화된 연결을 지원한다고 가정하면, 클라이언트는 --ssl-mode 옵션 없이 또는 명시적인 --ssl-mode=PREFERRED 옵션으로 암호화된 연결을 사용할 수 있습니다:
1mysql
또는:
1mysql --ssl-mode=PREFERRED
REQUIRE SSL 절로 생성된 계정의 경우, 암호화된 연결을 수립할 수 없으면 연결 시도가 실패합니다. 특별한 암호화 요구 사항이 없는 계정의 경우, 암호화된 연결을 수립할 수 없으면 시도는 암호화되지 않은 연결로 폴백합니다. 폴백을 방지하고 암호화된 연결을 수립할 수 없는 경우 실패하도록 하려면, 다음과 같이 접속하십시오:
1mysql --ssl-mode=REQUIRED
계정에 더 엄격한 보안 요구 사항이 있는 경우, 암호화된 연결을 수립하려면 다른 옵션을 지정해야 합니다:
REQUIRE X509 절로 생성된 계정의 경우, 클라이언트는 최소한 --ssl-cert 및 --ssl-key를 지정해야 합니다. 또한, 서버가 제공하는 공개 certificate를 검증할 수 있도록 --ssl-ca (또는 --ssl-capath)를 사용하는 것이 권장됩니다. 예를 들어 (커맨드는 한 줄로 입력합니다):1mysql --ssl-ca=ca.pem 2 --ssl-cert=client-cert.pem 3 --ssl-key=client-key.pem
REQUIRE ISSUER 또는 REQUIRE SUBJECT 절로 생성된 계정의 경우, 암호화 요구 사항은 REQUIRE X509와 동일하지만, certificate는 각각 계정 정의에 지정된 issuer 또는 subject와 일치해야 합니다.REQUIRE 절에 대한 추가 정보는 Section 15.7.1.3, “CREATE USER Statement”를 참조하십시오.
MySQL 서버는 클라이언트가 MySQL 서버 인스턴스에 접속하는 데 사용할 수 있는 클라이언트 certificate 및 key 파일을 생성할 수 있습니다. Section 8.3.3, “Creating SSL and RSA Certificates and Keys”를 참조하십시오.
주의
MySQL 서버 인스턴스에 접속하는 클라이언트가 extendedKeyUsage extension(X.509 v3 extension)을 포함하는 SSL certificate를 사용하는 경우, extended key usage에는 클라이언트 인증(clientAuth)이 포함되어야 합니다. SSL certificate가 서버 인증(serverAuth) 및 기타 non-client certificate 목적에 대해서만 지정된 경우, certificate 검증이 실패하며 MySQL 서버 인스턴스에 대한 클라이언트 연결도 실패합니다. MySQL 서버가 생성한 SSL certificate에는 (Section 8.3.3.1, “Creating SSL and RSA Certificates and Keys using MySQL”에 설명된 대로) extendedKeyUsage extension이 없으며, Section 8.3.3.2, “Creating SSL Certificates and Keys Using openssl”의 지시에 따라 openssl 커맨드를 사용해 생성한 SSL certificate에도 없습니다. 다른 방법으로 생성한 자체 클라이언트 certificate를 사용하는 경우, 모든 extendedKeyUsage extension에 클라이언트 인증이 포함되어 있는지 확인하십시오.
암호화 사용을 방지하고 다른 --ssl-xxx 옵션을 오버라이드하려면, 다음과 같이 --ssl-mode=DISABLED로 클라이언트 프로그램을 실행하십시오:
1mysql --ssl-mode=DISABLED
현재 서버와의 연결이 암호화를 사용하는지 확인하려면, Ssl_cipher 상태 변수의 세션 값을 확인하십시오. 값이 비어 있으면 연결은 암호화되지 않은 것입니다. 그렇지 않으면, 연결은 암호화된 것이며 값은 사용 중인 암호화 cipher를 나타냅니다. 예:
1mysql> SHOW SESSION STATUS LIKE 'Ssl_cipher'; 2+---------------+---------------------------+ 3| Variable_name | Value | 4+---------------+---------------------------+ 5| Ssl_cipher | DHE-RSA-AES128-GCM-SHA256 | 6+---------------+---------------------------+
mysql 클라이언트의 경우, 대안으로 STATUS 또는 \s 커맨드를 사용하고 SSL 라인을 확인할 수 있습니다:
1mysql> \s 2... 3SSL: Not in use 4...
또는:
1mysql> \s 2... 3SSL: Cipher in use is DHE-RSA-AES128-GCM-SHA256 4...
--tls-certificates-enforced-validation 옵션은 서버 시작 시 서버 공개키 certificate 파일, Certificate Authority(CA) certificate 파일, certificate revocation-list 파일에 대한 validation을 활성화합니다:
1mysqld --tls-certificates-enforced-validation
ON으로 설정된 경우, certificate가 유효하지 않으면 서버는 시작 실행을 중지합니다. 서버는 certificate의 상태에 따라 적절한 디버그 메시지, 에러 메시지 또는 둘 다를 제공하여 DBA에게 알립니다. 이 기능은 예를 들어, SSL certificate가 만료될 만큼 오랫동안 실행 중인 MySQL 서버를 재시작하지 않기 위해 유용할 수 있습니다.
마찬가지로, 런타임에 TLS 컨텍스트를 변경하기 위해 ALTER INSTANCE RELOAD TLS 구문을 실행하는 경우, validation이 실패하면 새로운 서버 및 CA certificate 파일은 사용되지 않습니다. 이 경우 서버는 이전 certificate를 계속 사용합니다. TLS 컨텍스트를 동적으로 변경하는 방법에 대한 자세한 내용은 Server-Side Runtime Configuration and Monitoring for Encrypted Connections을 참조하십시오.
Validating CA Certificates
서버 main interface를 사용하는 연결의 경우:
--ssl_ca가 지정된 경우, 서버는 해당 CA certificate를 검증하고 DBA에게 적절한 경고 메시지를 제공합니다.
--ssl_capath가 지정된 경우, 서버는 해당 폴더의 모든 CA certificate를 검증하고 DBA에게 적절한 경고 메시지를 제공합니다.
SSL 파라미터가 지정되지 않은 경우, 기본적으로 서버는 데이터 디렉터리에 있는 CA certificate를 검증하고 DBA에게 적절한 경고 메시지를 제공합니다.
서버 administrative interface를 사용하는 연결의 경우:
--admin_ssl_ca가 지정된 경우, 서버는 해당 CA certificate를 검증하고 DBA에게 적절한 경고 메시지를 제공합니다.
--admin_ssl_capath가 지정된 경우, 서버는 해당 폴더의 모든 CA certificate를 검증하고 DBA에게 적절한 경고 메시지를 제공합니다.
administrative SSL 파라미터가 지정되지 않은 경우, 기본적으로 서버는 데이터 디렉터리에 있는 CA certificate를 검증하고 DBA에게 적절한 경고 메시지를 제공합니다.
Validating the Server Certificate
서버 main interface를 사용하는 연결의 경우:
--ssl_cert가 지정되지 않은 경우, 서버는 기본 데이터 디렉터리에 있는 서버 certificate를 검증합니다.
--ssl_cert가 지정된 경우, 서버는 서버 certificate를 검증하며, 지정된 경우 --ssl_crl을 고려합니다.
DBA가 certificate validation을 위한 커맨드라인 옵션을 설정한 경우, certificate가 유효하지 않으면 서버는 중지되며 DBA에게 적절한 에러 메시지가 표시됩니다. 그렇지 않으면, 서버는 DBA에게 경고 메시지를 출력하고 시작을 계속합니다.
서버 administrative interface를 사용하는 연결의 경우:
--admin_ssl_cert가 지정되지 않은 경우, 서버는 기본 데이터 디렉터리에 있는 서버 certificate를 검증합니다.
--admin_ssl_cert가 지정된 경우, 서버는 administrative interface의 서버 certificate를 검증하며, 지정된 경우 --admin_ssl_crl을 고려합니다.
DBA가 certificate validation을 위한 커맨드라인 옵션을 설정한 경우, certificate가 유효하지 않으면 서버는 중지되며 DBA에게 적절한 에러 메시지가 표시됩니다. 그렇지 않으면, 서버는 DBA에게 경고 메시지를 출력하고 시작을 계속합니다.
일부 MySQL 배포 환경에서는 암호화된 연결을 사용하는 것이 바람직할 뿐만 아니라 (예: 규제 요건을 만족시키기 위해), 필수적일 수 있습니다. 이 섹션에서는 이를 가능하게 하는 configuration 설정에 대해 설명합니다. 다음과 같은 수준의 제어가 가능합니다:
클라이언트가 암호화된 연결을 사용하여 서버에 접속해야 하도록 서버를 구성할 수 있습니다.
서버가 암호화를 허용하지만 요구하지 않더라도, 개별 클라이언트 프로그램이 암호화된 연결을 요구하도록 실행할 수 있습니다.
개별 MySQL 계정을 암호화된 연결을 통해서만 사용할 수 있도록 구성할 수 있습니다.
클라이언트가 암호화된 연결을 사용하여 접속하도록 요구하려면, require_secure_transport 시스템 변수를 활성화하십시오. 예를 들어, 서버 my.cnf 파일에 다음과 같이 설정하십시오:
1[mysqld] 2require_secure_transport=ON
또는 런타임에 값을 설정하고 지속시키려면, 다음 구문을 사용하십시오:
1SET PERSIST require_secure_transport=ON;
SET PERSIST는 실행 중인 MySQL 인스턴스에 대해 값을 설정합니다. 또한 이 값을 저장하여 이후 서버 재시작 시 사용되도록 합니다. Section 15.7.6.1, “SET Syntax for Variable Assignment”를 참조하십시오.
require_secure_transport가 활성화되면, 클라이언트의 서버에 대한 연결은 어떤 형태로든 보안 전송을 사용해야 하며, 서버는 SSL을 사용하는 TCP/IP 연결 또는 소켓 파일(Unix) 또는 공유 메모리(Windows)를 사용하는 연결만 허용합니다. 서버는 보안되지 않은 연결 시도를 거부하며, 해당 시도는 ER_SECURE_TRANSPORT_REQUIRED 에러와 함께 실패합니다.
서버가 암호화를 요구하는지 여부와 상관없이 클라이언트 프로그램이 암호화된 연결을 요구하도록 실행하려면, --ssl-mode 옵션 값을 REQUIRED, VERIFY_CA, VERIFY_IDENTITY로 사용하십시오. 예:
1mysql --ssl-mode=REQUIRED 2mysqldump --ssl-mode=VERIFY_CA 3mysqladmin --ssl-mode=VERIFY_IDENTITY
MySQL 계정을 암호화된 연결을 통해서만 사용할 수 있도록 구성하려면, CREATE USER 구문에 REQUIRE 절을 포함하고, 해당 절에서 요구하는 암호화 특성을 지정하십시오. 예를 들어, 암호화된 연결과 유효한 X.509 certificate 사용을 요구하려면 REQUIRE X509를 사용합니다:
1CREATE USER 'jeffrey'@'localhost' REQUIRE X509;
REQUIRE 절에 대한 추가 정보는 Section 15.7.1.3, “CREATE USER Statement”를 참조하십시오.
암호화 요구 사항이 없는 기존 계정을 수정하려면, ALTER USER 구문을 사용하십시오.
8.3 Using Encrypted Connections
8.3.2 Encrypted Connection TLS Protocols and Ciphers