: MySQL 서버의 암호화 기능은 데이터베이스 서버와 디스크 사이의 데이터를 읽고 쓰는 지점에서 암호화 또는 복호화를 수행, MySQL 서버에서 디스크 입출력 이외의 부분에선 X
: MySQL 서버에서 사용자의 쿼리를 처리하는 과정에서 테이블의 데이터가 암호화되어 있는지 여부를 식별할 필요가 없으며 그렇지 않은 테이블 동일한 과정을 거침
: 이 경우 데이터 암호화 기능이 활성화되어 있다고 하더라도 MySQL 내부와 사용자 입장에서는 아무런 차이가 없기 때문에 이를 TDE라고 한다.
1. 2단계 키 관리
: MySQL 서버의 TDE에서 암호화 키는 키링 플러그인에 의해 관리되며 MySQL 8.0 버전에서 지원되는 키링 플러그인은 아래와 같으나 커뮤니티 에디션에서는 keyring_file만 사용 가능하며 나머지는 엔터프라이즈 에디션에서 사용 가능
•
keyring_file : File-Based 플러그인
•
keyring_encrypted_file : Keyring 플러그인
•
keyring_okv : KMIP 플러그인
•
keyring_aws : Amazon Web Services Keyring 플러그인
: 각 플러그인들은 마스터 키를 관리하는 방법만 다를 뿐 MySQL 서버 내부적으로 작동하는 방식은 모두 동일
: MySQL 서버의 키링 플러그인은 2단계 (2-Tier) 키 관리 방식을 사용
: MySQL 서버에서는 마스터 키와 테이블 스페이스 키 두 가지 키로 암호화
1.
디스크의 keyring_file에서 마스터 키를 가져온다.
2.
암호화된 테이블이 생성되면 테이블 스페이스 키를 발급한다. (테이블 스페이스 키는 절대 변경되지 않는다.)
3.
마스터 키를 이용해서 테이블 스페이스 키를 암호화해서 각 테이블의 데이터파일 헤더에 저장한다.
4.
테이블의 데이터가 저장될 때 테이블 스페이스 키를 이용해서 암호화하여 저장한다.
: MySQL TDE 에서 지원되는 암호화 알고리즘은 AES 256이다.
•
마스터키는 주기적으로 변경해주는 것이 좋다. 파일로 관리하므로 유출될 수 있음 ALTER INSTANCE ROTATE INNODB MASTER KEY;
2. 암호화와 성능
: MySQL 서버의 암호화 방식은 TDE 방식으로 한 번 메모리 버퍼 풀에 적재하면 암호화되지 않은 테이블과 동일한 성능을 보인다.
: 하지만 InnoDB 버퍼 풀에 존재하지 않는 데이터 페이지를 읽어야 한다면 복호화하는 시간이 더 발생하며 암호화된 테이블이 변경된다면 디스크로 동기화할 때 암호화하는
시간이 더 발생, 이는 백그라운드 스레드가 수행하기 때문에 쿼리가 지연되지는 않는다.
: AES 암호화 알고리즘은 평문의 데이터가 충분히 크다면 파일의 크기는 암호화 전과 후가 크게 다르지 않아 메모리 효율이 차이가 나지 않는다.
: 암호화와 압축이 동시에 적용되면 MySQL 서버는 압축을 먼저 실행하고 암호화를 진행, 암호화된 결과문은 아주 랜덤한 바이트 배열을 가지게 되어 압축률을 상당히 저하
3. 암호화와 복제
: MySQL 서버의 복제에서 레플리카 서버는 TDE를 이용한 암호화 사용 시 마스터 키와 테이블스페이스 키는 기본적으로 새로 할당
: 소스 서버와 레플리카 서버는 서로 각자의 마스터 키와 테이블스페이스 키를 관리하기 때문에 복제 멤버들의 데이터 파일은 암호화 되기 전의 값이 동일하더라도
실제 암호화된 데이터가 저장된 데이터 파일의 내용은 완전히 달라짐
: 마스터키 로테이션을 실행하면 소스 서버와 레플리카 서버가 서로 다른 마스터 키를 새로 발급,
: 백업을 할 경우 TDE의 키링 파일을 백업하지 않으면 데이터를 복구 할 수 없게 되므로 꼭 마스터 키를 같이 백업
