데브러너 (DevRunner)

19.3.3 Replication Privilege Checks

19.3.3.1 Privileges For The Replication PRIVILEGE_CHECKS_USER Account 19.3.3.2 Privilege Checks For Group Replication Channels 19.3.3.3 Recovering From Failed Replication Privilege Checks

기본적으로, MySQL 복제(여기에는 Group Replication 포함)는 다른 서버에서 이미 승인된 트랜잭션이 레플리카나 그룹 멤버에서 적용될 때 권한 검사를 수행하지 않습니다. 채널에서 일반적으로 복제되는 트랜잭션을 적용하기 위한 적절한 권한을 가진 사용자 계정을 생성하고, 이를 CHANGE REPLICATION SOURCE TO 문을 사용하여 복제 적용기의 PRIVILEGE_CHECKS_USER 계정으로 지정할 수 있습니다. 그러면 MySQL은 해당 채널에 대해 해당 작업을 허가했는지 확인하기 위해 각 트랜잭션을 그 사용자 계정의 권한에 대해 검사합니다. 이 계정은 또한 예를 들어 채널에서 발생한 복제 오류로부터 복구하기 위해 mysqlbinlog 출력에서 트랜잭션을 적용하거나 재적용하는 용도로 관리자가 안전하게 사용할 수 있습니다.

PRIVILEGE_CHECKS_USER 계정을 사용하면 권한이 부여된 또는 원치 않는 작업이 무단으로 또는 실수로 사용되는 것에 대해 복제 채널을 보호할 수 있습니다. PRIVILEGE_CHECKS_USER 계정은 다음과 같은 상황에서 추가적인 보안 계층을 제공합니다:

조직의 네트워크에 있는 서버 인스턴스와 클라우드 서비스 제공자가 제공하는 인스턴스와 같은 다른 네트워크의 서버 인스턴스 간에 복제를 수행하는 경우.
여러 개의 온프레미스 또는 오프사이트 배포를 각각 별도의 단위로 관리하려 하지만, 하나의 관리자 계정에 모든 배포에 대한 권한을 부여하고 싶지 않은 경우.
관리자가 서버 인스턴스에 대한 광범위한 권한을 갖는 대신, 복제 채널과 그 채널이 복제하는 데이터베이스에 직접적으로 관련된 작업만 수행할 수 있는 관리자 계정을 두고자 하는 경우.

권한 검사가 적용되는 복제 채널의 보안을 강화하기 위해, 채널에 대해 PRIVILEGE_CHECKS_USER 계정을 지정할 때 CHANGE REPLICATION SOURCE TO 문에 다음 옵션들 중 하나 또는 둘 모두를 추가할 수 있습니다:

REQUIRE_ROW_FORMAT 옵션은 복제 채널이 로우 기반 복제 이벤트만 허용하도록 합니다. REQUIRE_ROW_FORMAT이 설정되면, 소스 서버에서 로우 기반 바이너리 로깅(binlog_format=ROW)을 사용해야 합니다. 스테이트먼트 기반 바이너리 로깅을 사용하는 경우, 일부 관리자 수준 권한이 트랜잭션을 성공적으로 실행하기 위해 PRIVILEGE_CHECKS_USER 계정에 필요할 수 있습니다.
REQUIRE_TABLE_PRIMARY_KEY_CHECK 옵션은 복제 채널이 프라이머리 키 검사에 대해 자체 정책을 사용하도록 합니다. ON으로 설정하면 프라이머리 키가 항상 필요하며, OFF로 설정하면 프라이머리 키가 전혀 필요 없습니다. 기본 설정인 STREAM은 각 트랜잭션마다 소스에서 복제되는 값을 사용하여 sql_require_primary_key 시스템 변수의 세션 값을 설정합니다. PRIVILEGE_CHECKS_USER가 설정된 상태에서 REQUIRE_TABLE_PRIMARY_KEY_CHECK를 ON 또는 OFF로 설정하면, 제한된 세션 변수의 값을 변경하는 데 필요한 세션 관리자 수준 권한 없이도 사용자 계정이 해당 설정을 변경할 수 있습니다. 또한 서로 다른 소스에 대한 복제 채널 전반에서 동작을 표준화합니다.

REPLICATION_APPLIER 권한을 부여하면 사용자 계정이 복제 적용기 스레드의 PRIVILEGE_CHECKS_USER로 지정될 수 있고, mysqlbinlog에서 사용하는 내부 용도의 BINLOG 문들을 실행할 수 있습니다. PRIVILEGE_CHECKS_USER 계정의 사용자 이름과 호스트 이름은 Section 8.2.4, “Specifying Account Names”에 설명된 구문을 따라야 하며, 사용자는 익명 사용자(빈 사용자 이름을 가진 사용자)나 CURRENT_USER이어서는 안 됩니다. 새 계정을 생성하려면 CREATE USER를 사용합니다. 이 계정에 REPLICATION_APPLIER 권한을 부여하려면 GRANT 문을 사용합니다. 예를 들어, example.com 도메인의 어떤 호스트에서도 관리자가 수동으로 사용할 수 있고, 암호화된 커넥션이 필요한 사용자 계정 priv_repl을 생성하려면 다음 문들을 실행합니다:

1mysql> SET sql_log_bin = 0;
2mysql> CREATE USER 'priv_repl'@'%.example.com' IDENTIFIED BY 'password' REQUIRE SSL;
3mysql> GRANT REPLICATION_APPLIER ON *.* TO 'priv_repl'@'%.example.com';
4mysql> SET sql_log_bin = 1;

SET sql_log_bin 문은 계정 관리 문이 바이너리 로그에 추가되어 복제 채널로 전송되지 않도록 하기 위해 사용됩니다(자세한 내용은 Section 15.4.1.3, “SET sql_log_bin Statement” 참조).

주의

caching_sha2_password 인증 플러그인은 새 사용자에 대한 기본값입니다(자세한 내용은 Section 8.4.1.1, “Caching SHA-2 Pluggable Authentication” 참조). 이 플러그인으로 인증하는 사용자 계정을 사용하여 서버에 연결하려면, Section 19.3.1, “Setting Up Replication to Use Encrypted Connections”에 설명된 대로 암호화된 커넥션을 설정하거나, 암호화되지 않은 커넥션에서 RSA 키 페어를 사용한 비밀번호 교환을 지원하도록 설정해야 합니다.

사용자 계정 설정을 마친 후, GRANT 문을 사용하여, 예를 들어 서버에 존재하는 특정 테이블을 갱신하는 등 적용기 스레드가 수행하기를 기대하는 데이터베이스 변경 작업을 이 사용자 계정이 수행할 수 있도록 추가 권한을 부여합니다. 동일한 권한을 사용하여 관리자가 복제 채널에서 해당 트랜잭션을 수동으로 실행해야 할 때 이 계정을 사용할 수 있습니다. 예상치 못한 작업이 시도되었는데 해당 작업에 필요한 권한을 부여하지 않은 경우, 그 작업은 허용되지 않고 복제 적용기 스레드는 오류와 함께 중지됩니다. 계정에 필요한 추가 권한에 대해서는 Section 19.3.3.1, “Privileges For The Replication PRIVILEGE_CHECKS_USER Account”에서 설명합니다. 예를 들어, priv_repl 사용자 계정에 db1의 cust 테이블에 로우를 추가하기 위한 INSERT 권한을 부여하려면 다음 문을 실행합니다:

1mysql> GRANT INSERT ON db1.cust TO 'priv_repl'@'%.example.com';

복제 채널에 대한 PRIVILEGE_CHECKS_USER 계정 지정은 CHANGE REPLICATION SOURCE TO 문을 사용하여 수행합니다. 복제가 실행 중이라면, CHANGE REPLICATION SOURCE TO 문 전에 STOP REPLICA를 실행하고, 이후에 START REPLICA를 실행합니다. PRIVILEGE_CHECKS_USER가 설정된 경우 로우 기반 바이너리 로깅을 사용하는 것이 강력히 권장되며, 이를 강제하기 위해 문에서 REQUIRE_ROW_FORMAT을 설정할 수 있습니다.

복제 채널을 다시 시작하면, 동적 권한에 대한 검사는 그 시점부터 적용됩니다. 그러나 정적 글로벌 권한은 연결된 클라이언트에 대해 변경되지 않기 때문에, 적용기의 컨텍스트에서는 권한 테이블을 다시 로드할 때까지 활성화되지 않습니다. 정적 권한을 활성화하기 위해서는 플러시-권한 작업을 수행해야 합니다. 이는 FLUSH PRIVILEGES 문을 실행하거나, mysqladmin flush-privileges 또는 mysqladmin reload 명령을 실행함으로써 수행할 수 있습니다.

예를 들어, 실행 중인 레플리카에서 channel_1 채널에 대해 권한 검사를 시작하려면 다음 문들을 실행합니다:

1mysql> STOP REPLICA FOR CHANNEL 'channel_1';
2mysql> CHANGE REPLICATION SOURCE TO
3     >    PRIVILEGE_CHECKS_USER = 'priv_repl'@'%.example.com',
4     >    REQUIRE_ROW_FORMAT = 1 FOR CHANNEL 'channel_1';
5mysql> FLUSH PRIVILEGES;
6mysql> START REPLICA FOR CHANNEL 'channel_1';

채널을 지정하지 않고 다른 채널도 존재하지 않는 경우, 문은 기본 채널에 적용됩니다. 채널의 PRIVILEGE_CHECKS_USER 계정에 대한 사용자 이름과 호스트 이름은 Performance Schema의 replication_applier_configuration 테이블에 표시되며, 개별 트랜잭션을 실행하기 위한 SQL 문에 직접 복사할 수 있도록 적절히 이스케이프 처리되어 있습니다.

Rewriter 플러그인을 사용하는 경우, PRIVILEGE_CHECKS_USER 사용자 계정에 SKIP_QUERY_REWRITE 권한을 부여해야 합니다. 이는 이 사용자가 실행하는 문이 리라이트되는 것을 방지합니다. 자세한 내용은 Section 7.6.4, “The Rewriter Query Rewrite Plugin”을 참조하십시오.

REQUIRE_ROW_FORMAT이 복제 채널에 설정된 경우, 복제 적용기는 임시 테이블을 생성하거나 삭제하지 않으므로, pseudo_thread_id 세션 시스템 변수를 설정하지 않습니다. 또한 LOAD DATA INFILE 지시문을 실행하지 않으므로, 데이터 적재와 연관된 임시 파일에 접근하거나 이를 삭제하기 위한 파일 작업을 시도하지 않습니다(이는 Format_description_log_event로 로깅됩니다). 또한 스테이트먼트 기반 복제에서 클라이언트의 커넥션 상태를 재현하는 데 사용되는 INTVAR, RAND, USER_VAR 이벤트를 실행하지 않습니다(예외적으로, DDL 쿼리와 연관된 USER_VAR 이벤트는 실행됩니다). DML 트랜잭션 내에서 로깅되는 문도 실행하지 않습니다. 복제 적용기가 트랜잭션을 큐에 넣거나 적용하려는 동안 이러한 유형의 이벤트를 감지하면, 해당 이벤트는 적용되지 않고 복제는 오류와 함께 중지됩니다.

PRIVILEGE_CHECKS_USER 계정을 설정했는지 여부와 관계없이 복제 채널에 대해 REQUIRE_ROW_FORMAT을 설정할 수 있습니다. 이 옵션을 설정할 때 적용되는 제한 사항은 권한 검사가 없더라도 복제 채널의 보안을 향상시킵니다. 또한 mysqlbinlog를 사용할 때 --require-row-format 옵션을 지정하여, mysqlbinlog 출력에서 로우 기반 복제 이벤트를 강제할 수 있습니다.

Security Context.
기본적으로, 복제 적용기 스레드가 PRIVILEGE_CHECKS_USER로 지정된 사용자 계정과 함께 시작되면, 보안 컨텍스트는 기본 역할을 사용하여, 또는 activate_all_roles_on_login이 ON으로 설정된 경우 모든 역할을 사용하여 생성됩니다.

역할을 사용하여 PRIVILEGE_CHECKS_USER 계정으로 사용되는 계정에 대한 일반적인 권한 집합을 제공할 수 있으며, 다음 예제와 같습니다. 여기에서는 앞선 예제에서처럼 사용자 계정에 직접 db1.cust 테이블에 대한 INSERT 권한을 부여하는 대신, 이 권한과 REPLICATION_APPLIER 권한을 역할 priv_repl_role에 부여합니다. 그런 다음 이 역할을 사용하여 권한 집합을 두 개의 사용자 계정에 부여하며, 이 둘 모두 이제 PRIVILEGE_CHECKS_USER 계정으로 사용할 수 있습니다:

1mysql> SET sql_log_bin = 0;
2mysql> CREATE USER 'priv_repa'@'%.example.com'
3                  IDENTIFIED BY 'password'
4                  REQUIRE SSL;
5mysql> CREATE USER 'priv_repb'@'%.example.com'
6                  IDENTIFIED BY 'password'
7                  REQUIRE SSL;
8mysql> CREATE ROLE 'priv_repl_role';
9mysql> GRANT REPLICATION_APPLIER TO 'priv_repl_role';
10mysql> GRANT INSERT ON db1.cust TO 'priv_repl_role';
11mysql> GRANT 'priv_repl_role' TO
12                  'priv_repa'@'%.example.com',
13                  'priv_repb'@'%.example.com';
14mysql> SET DEFAULT ROLE 'priv_repl_role' TO
15                  'priv_repa'@'%.example.com',
16                  'priv_repb'@'%.example.com';
17mysql> SET sql_log_bin = 1;

복제 적용기 스레드가 보안 컨텍스트를 생성할 때, PRIVILEGE_CHECKS_USER 계정에 대한 권한은 검사하지만, 비밀번호 검증은 수행하지 않으며, 계정이 잠겨 있는지 여부를 확인하는 등 계정 관리와 관련된 검사도 수행하지 않습니다. 생성된 보안 컨텍스트는 복제 적용기 스레드의 수명 동안 변경되지 않고 유지됩니다.