Real My SQL 8.0 읽고 공부하기 - ⑦-③,④,⑤데이터 암호화

3) 테이블 암호화

키링 플러그인은 마스터 키를 생성하고 관리하는 부분까지만 담당하기 때문에 어떤 키링 플러그인을 사용하든 암호화된 

테이블을 생성하고 활용하는 방법 모두 동일하다.

 

테이블 생성은 다음과 같이 할 수 있다.

CREATE TABLE tab_encrypted (
  id INT,
  data VARCHAR(100),
  PRIMARY KEY(id)
) ENCRYPTION='Y';

기존 테이블 생성 구문과 동일하며 마지막에 ENCRYPTION ='Y' 옵션만 추가로 넣으면 된다.

 

응용프로그램에서 직접 암호화해서 MySQL 서버에 저장하는 경우가 있는데, MySQL은 이 컬럼이 암호화된것인지

여부를 판단하지 못한다.

 

이에 따라서 해당 컬럼을 인덱스를 생성하더라도 인덱스 기능을 100% 활용 할 수 없다.

응용프로그램의 암호화를 사용하지 않고 MySQL의 암호화기능을 사용한다면 인덱스 관련된 작업을 모두  처리 한 후

최종 디스크에 저장할때만 암호화하기 때문에 이 같은 제약이 없다.

둘 중 어느 암호화를 선택해야할지 결정해야한다면 MySQL서버의 암호화를 권장한다.

 

TDE가 적용되어 암호화된 테이블의 경우 원본 MySQL서버와 목적지 MySQL서버의 암호화 키가 다르기 때문에 테이블 스페이스

이동시 신경 써야할 부분이 하나 더 있다.

FLUSH TABLES source_table FOR EXPORT명령을 실행하면 테이블 스페이스의 키를 현재 마스터 키로 복호화하고 새로

발급한 임시 마스터키로 암호화해서 데이터 파일의 헤더 부분에 저장한다.

반드시 데이터 파일과 함께 임시 마스터키가 저장된 *.cfp파일을 함께 복사해야한다.

만약 *.cfp파일이 없어진다면 복구가 불가능해진다.

 

 

---

 

4) 언두 로그 및 리두 로그 암호화

테이블 암호화를 진행해도 디스크로 저장되는 데이터만 암호화하고 MySQL서버 메모리에 존재하는 데이터는 복호화된 평문으로 

관리된다. 만약, 이 데이터를 데이터 파일 이외의 디스크 파일로 기록되는 경우 여전히 평문으로 저장된다.

그래서 리두 로그 , 언두로그, 복제를 위한 바이너리 로그도 평문으로 저장된다.

 

8.0.16버전부터는 리두로그, 언두로그를 암호화된 상태로 저장할 수 있게 개선되었다.

그러나 암호화가 활성화되는 시점부터 암호화를 하여 저장하기 때문에 이전에 저장했던 로그들은 평문으로 저장되어있다.

그 반대의 경우도 마찬가지인데 만약, 암호화 -> 비활성화과정을 거치는 경우 암호화된 로그때문에 암호화에

사용된 키(프라이빗키)가 장기간 필요할 수 있다. (복호화를 위함)

 

만약 암호화가 되었는지 여부를 확인하려면 리두 로그에 INSERT된 문자열이 보이는지 확인하며 된다.

## linux
## grep 명령 결과가 문자열이 존재하면 matches라는 메시지를 보여준다.
## 검색한 문자열이 존재한다면 grep 명령은 반환 값으로 "0"을 리턴한다.
grep 'Real-MySQL' ib_logfile0 ib_logfile1
echo $?

위에 내용은 책에서 찾아본 내용이고

윈도우에서 찾아보니 해당 파일을 찾아보지 못해서 공식 문서를 확인해보니

MySQL :: MySQL 8.0 Reference Manual :: 15.6.5 Redo Log

 

8.0.30 버전 이후 부터는 해당 파일이 존재하지 않고

#innodb_redo 에서 분할해서 저장한다. 

 

 

 

인코딩방식이 다른건지 지금 확인해보면 전혀 알아볼 수 없는 문자열로 보이고, 새로운 버전에 대한 정보가 없어서

어떻게 확인하는지는 추후에 알아보아야겠다.

 

---

 

 

5) 바이너리 로그 암호화

 

바이너리 로그와 릴레리 로그 파일 또한 평문을 저장한다. 바이너리 로그는 의도적으로 상당히 긴 시간 동안 보관하는 서비스도

존재하고 증분 백업을 위해 바이너리 로그를 보관하기도 한다. 이러한 이유로 암호화는 중요도가 높아질 수 있다.

 

바이너리 로그와 릴레리로그의 로그파일 암호화 기능은 디크스에 저장된 로그파일에 대한 암호화만 담당한다.

메모리 내부 또는 소스 서버와 레플리카 서버 간의 네트워크 구간에서 로그 데이터를 암호화 하지는 않는다.

네트워크 구간에서 암호화하고자 한다면 복제를 위한 계정이 SSL를 사용하면 된다.

 

바이너리 로그와 릴레이 로그 파일의 데이터는 파일 키로 암호화해서 디스크로 저장하고

파일 키는 "바이너리 로그 암호화 키"로 암호화해서 각 바이너리 로그와 릴레이 로그 파일의 헤더에 저장한다.

즉, 테이블 암호화의 마스터키와 동일한 역할을 한다.

 

바이너리 로그 암호화 키는 다음과 같이 변경할 수 있는데

ALTER INSTANCE ROTATE BINLOG MASTER KEY;

변경 과정은 다음과 같다.

 

1. 증가된 시퀀스 번호와 함께 새로운 바이너리 로그 암호화 키 발급 후 키링 파일 저장

2. 바이너리 로그 파일과 릴레리 로그 파일 스위치 (새로운 로그 파일로 로테이션)

3. 새로 생성되는 바이너리 로그와 릴레리 로그 파일의 암호화를 위해 파일 키를 생성하고, 파일 키는 바이너리 로그 파일키(마스터 키)

로 암호화 해서 각 로그 파일에 저장

4. 기존 바이너리 로그와 릴레리 로그 파일의 파일 키를 읽어서 새로운 바이너리 로그 파일 키로 암호화 해서 다시 저장

(암호화되지 않은 로그파일 무시)

5. 모든 바이너리 로그와 릴레리 로그 파일이 새로운 바이너리 로그 암호화 키로 다시 암호화 되었다면 기존 바이너리 로그 암호화키 제거

 

4번과정에서 시간이 걸리는 작업이 될 수 있는데, 이를 위해 키링 파일에서 내부적으로 (시퀀스 번호)버전 관리가 이루어진다.

 

mysqlbinlog도구를 활용해서 암호화된 바이너리 로그 파일의 내용을 SQL문장으로 한번 풀어보면 암호화된 바이너리 로그 파일을

직접 열어 볼 수 없다는 메시지를 출력한다.

MySQL서버를 거쳐서 가져오는 방법이 유일한데 mysqlbinlog로 MySQL서버를 접속해서 바이너리 로그를 가져와야한다.

이때 bin파일을 읽는것이아니라 MySQL서버에 요청하는 것이다.

다음과 같이 서버에 접속해서 읽어올 수 있다.

mysqlbinlog --read-from-remote-server -uroot -p -vv mysql-bin파일