View a markdown version of this page

Aurora MySQL 버전 3에서 버전 8.4로 업그레이드하기 위한 보안 고려 사항 - Amazon Aurora

Aurora MySQL 버전 3에서 버전 8.4로 업그레이드하기 위한 보안 고려 사항

Aurora MySQL 버전 3(MySQL 8.0 호환)에서 Aurora MySQL 버전 8.4로 마이그레이션할 때 몇 가지 중요한 보안 관련 변경 사항을 신중하게 계획하고 고려해야 합니다. 이 가이드에서는 주요 보안 변경 사항을 간략하게 설명하고 원활한 마이그레이션을 위한 권장 사항을 제공합니다.

인증 정책(8.4의 새로운 기능)

Aurora MySQL 버전 3(MySQL 8.0과 호환)은 default_authentication_plugin 파라미터를 사용하여 데이터베이스 사용자를 생성할 때 사용되는 기본 인증 플러그인을 구성합니다. Aurora MySQL 버전 8.4에서 이 파라미터는 authentication_policy 파라미터로 대체되며 기본적으로 *:caching_sha2_password로 설정됩니다.

Aurora MySQL에서 지원되는 값:

  • *:caching_sha2_password(기본값. 지정된 경우 caching_sha2_password를 사용하여 단일 요소 인증 플러그인 허용)

  • *:mysql_native_password (지정된 경우 mysql_native_password를 사용하여 단일 요소 인증 플러그인 허용)

참고

다중 인증 구성은 Aurora MySQL 버전 8.4에서 지원되지 않습니다.

업그레이드 사전 확인 deprecatedDefaultAuth는 소스 클러스터가 default_authentication_pluginmysql_native_password로 설정한 경우 경고합니다. 이 경고를 검토하고 업그레이드할 때 대상 클러스터 파라미터 그룹에서 authentication_policy 파라미터를 구성합니다.

마스터 사용자 동작

새 클러스터

마스터 사용자는 클러스터 생성 시 authentication_policy 파라미터에 의해 설정된 인증 플러그인으로 생성됩니다. 기본 파라미터 그룹을 사용하는 경우 마스터 사용자는 caching_sha2_password 인증 플러그인으로 생성됩니다. authentication_policy 파라미터가 *:mysql_native_password로 설정된 사용자 지정 파라미터 그룹을 사용하는 경우 마스터 사용자는 mysql_native_password 인증 플러그인으로 생성됩니다.

마스터 사용자 암호 재설정

AWS Management Console, CLI(modify-db-cluster --master-user-password) 또는 API를 통해 마스터 사용자 암호를 재설정하는 경우 Aurora는 재설정 시 authentication_policy 파라미터로 정의된 현재 기본 플러그인을 사용합니다.

Secrets Manager 및 암호 교체

AWS Secrets Manager를 사용하여 마스터 사용자 암호를 관리할 때 authentication_policy 파라미터 값을 업데이트하면 다음 암호 교체 시 마스터 사용자의 인증 플러그인이 새 authentication_policy 파라미터 값과 일치하도록 설정됩니다.

업그레이드 후 생성된 데이터베이스 사용자

mysql_native_password 인증 플러그인을 사용하는 기존 데이터베이스 사용자는 업그레이드 후에도 계속 작동합니다. IDENTIFIED WITH 절을 지정하지 않고 업그레이드 후 생성하는 데이터베이스 사용자는 authentication_policy 파라미터로 정의된 인증 플러그인을 사용합니다. 파라미터가 기본값인 *:caching_sha2_password이면 caching_sha2_password 인증 플러그인을 사용하여 새 사용자가 생성됩니다.

모든 새 사용자의 기본 인증 플러그인을 변경하려면 authentication_policy 값을 업데이트합니다. 지원되는 값에 대한 자세한 내용은 인증 정책(8.4의 새로운 기능) 섹션을 참조하세요.

기본값과 다른 인증 플러그인이 있는 사용자를 생성하려면 CREATE USER 문에 명시적으로 지정합니다.

CREATE USER 'username'@'host' IDENTIFIED WITH authentication-plugin BY 'password';

암호화 및 TLS 변경

Aurora MySQL DB 클러스터에 대한 모든 사용자 연결에 TLS를 요구하려면 require_secure_transport DB 클러스터 파라미터를 사용하세요. Aurora MySQL 버전 8.4에서는 기본적으로 이 파라미터가 ON으로 설정되어 있습니다.

Aurora MySQL 버전 8.4는 ssl_ciphers(TLS 1.2) 및 tls_ciphersuites(TLS 1.3) DB 클러스터 파라미터의 최신 보안 요구 사항에 따라 더 엄격한 암호화 표준을 적용합니다. 자세한 내용은 Amazon Aurora MySQL를 사용한 보안 섹션을 참조하세요.

연결 중단을 방지하려면 마이그레이션하기 전에 MySQL 클라이언트 및 대상 DB 클러스터의 TLS 구성을 확인합니다.

암호 검증 구성 요소 마이그레이션

Aurora MySQL 버전 8.4에는 validate_password 구성 요소를 활성화하거나 비활성화하는 aurora_enable_validate_password_component 클러스터 파라미터가 도입되어 수동으로 설치하거나 제거할 필요가 없습니다. 이전에 validate_password 플러그인을 설치했고 업그레이드 후 구성 요소를 활성화한 경우 구성 요소만 유효하며 플러그인은 무시됩니다.

Aurora MySQL 버전 8.4부터 이전에 INSTALL PLUGIN 명령을 통해 validate_password 플러그인을 설치한 경우 aurora_enable_validate_password_component 파라미터를 활성화하여 validate_password 구성 요소로 마이그레이션한 다음 라이터 인스턴스의 UNINSTALL PLUGIN 명령을 통해 플러그인을 제거할 수 있습니다.

이전에 INSTALL COMPONENT 'file://component_validate_password'를 사용하여 validate_password 구성 요소를 수동으로 설치한 경우 업그레이드할 때 대상 DB 클러스터 aurora_enable_validate_password_component 파라미터 그룹에서 파라미터를 설정해야 합니다. 업그레이드 후에는 구성 요소가 더 이상 mysql.component 테이블에 나열되지 않습니다. aurora_enable_validate_password_component 전역 변수를 사용하여 구성 요소의 상태를 확인할 수 있습니다.

업그레이드 후 첫 번째 DB 엔진을 시작할 때 이전에 구성 요소를 수동으로 설치한 경우 MySQL 오류 로그에 다음 메시지가 표시됩니다.

Component 'file://component_validate_password' is being removed from mysql.component table. validate_password component can be enabled/disabled through 'aurora_enable_validate_password_component' cluster parameter.

업그레이드 사전 확인 auroraValidatePasswordPluginCheckvalidate_password 플러그인이 소스 클러스터에 설치되어 있는지 여부를 경고합니다. 이 경고는 업그레이드를 차단하지 않지만 업그레이드 후 구성 요소로 전환할 계획을 세워야 합니다.

새로운 동적 권한

Aurora MySQL 버전 8.4는 다음과 같은 새로운 권한을 지원합니다.

  • ALLOW_NONEXISTENT_DEFINER

  • FLUSH_PRIVILEGES

  • OPTIMIZE_LOCAL_TABLE

  • SET_ANY_DEFINER

이러한 권한은 업그레이드 시 마스터 사용자 계정에 대해 마스터 사용자 계정 권한에 자동으로 부여됩니다.

rdsproxyadmin에 대한 보호된 사용자 적용

Aurora MySQL 버전 8.4.7부터 rdsproxyadmin은 보호 대상 사용자입니다. 엔진은 모든 호스트에서 rdsproxyadmin에 대한 CREATE, DROP, RENAME, GRANT, REVOKESET PASSWORD 작업을 거부합니다. 거부된 작업 및 예제 오류의 전체 목록은 Aurora MySQL의 예약 사용자 섹션을 참조하세요.

Aurora MySQL 버전 3은 rdsproxyadmin 이름을 예약하지 않습니다. (프록시 대상을 등록할 때 시스템이 생성하도록 허용하는 대신) 버전 3에서 rdsproxyadmin이라는 데이터베이스 사용자를 생성한 경우 버전 8.4로 업그레이드하기 전에 이 섹션을 검토하세요.

업그레이드 전에

버전 3 클러스터에서 rdsproxyadmin 사용자를 생성한 경우 버전 8.4로 업그레이드하기 전에 계정의 이름을 바꾸거나 삭제합니다. 버전 3 연결을 사용하여 다음 명령문 중 하나를 실행할 수 있습니다.

-- Rename the existing account to a non-reserved name RENAME USER 'rdsproxyadmin'@'host' TO 'new_user'@'host'; -- Or drop the account if it is no longer needed DROP USER 'rdsproxyadmin'@'host';

업그레이드를 시작하기 전에 이전 사용자 이름을 참조하는 애플리케이션 또는 저장된 자격 증명을 업데이트합니다.

업그레이드하기 전에 사용자의 이름을 바꾸거나 삭제하지 않는 경우

이미 생성한 rdsproxyadmin 사용자가 있는 클러스터를 업그레이드하면 업그레이드가 성공적으로 완료됩니다. 계정은 기존 암호와 권한으로 보존되며 원래 암호를 사용하여 rdsproxyadmin으로 클러스터에 연결할 수 있습니다.

그러나 업그레이드 후에는 계정을 수정할 수 없습니다. rdsproxyadmin의 암호를 삭제, 이름 바꾸기, 권한 변경 또는 변경하려고 하면 문이 오류를 반환합니다.

업그레이드 후 계정을 제거하거나 사용할 RDS Proxy의 rdsproxyadmin 이름을 회수하려면 AWS Support에 문의하세요. AWS 지원은 버전 3에서 이전된 기존 rdsproxyadmin 사용자를 제거할 수 있습니다.