정리중-6

MySQL은 5.7부터 데이터 암호화 기능을 제공한다.

처음에는 데이터 파일(Table Space)에만 암호화를 제공했었으나, MySQL8.0으로 업그레이드 되며 리두, 언두로그와 바이너리 로그등 모든 것을 암호화 할 수 있게 변경되었다.

 

📌 암호화와 복호화가 진행되는 곳

MySQL 내부에서 암호화된 상태로 데이터를 사용하는건 아니다. 즉 MySQL 내부와 사용자 입장에서는 암호화를 하던 말던 별 차이가 없는데, 이를 TDE(Transparent Data Encryption, 투명한 데이터 암호화)이라 부른다.

 

디스크 <-> MySQL 서버 사이에서 암호화 및 복호화가 이루어진다고 생각하면 된다. 즉 디스크 입출력을 담당하는 InnoDB 스토리지 엔진의 I/O 레이어에서 암호 & 복호화가 진행된다.

 

암호화는 보통 메모리(In-Process), 네트워크 전송(In-Transit), 디스크 저장(At Rest)에서 사용하는데, MySQL은 AtRest 방식이라고 이해하면 되겠다.

 

 

📌 2단계 키 관리

MySQL 서버의 TDE에서, 암호화 키는 KeyRing이라는 2단계 키 관리 플러그인에 의해 관리된다.

참고로 엔터프라이즈를 사용하면 KeyRing 암호화 방식을 KMIP, AWS등으로 변경할 수 있다. 기본은 File-Based

물론 응용 프로그램에서 직접 암호화해서 MySQL에 저장하는 방법도 있다.

이는 MySQL은 암호화 여부를 인지하지 못하고, 인덱스가 제대로 작동하지 않기 때문에 추천하는 방법은 아니다.

 

하지만 MySQL 서버에 루트 권한을 가지고 로그인할 수 있다고 하더라도 평문의 내용을 확인할 수 없기 때문에, 어플리케이션 암호화를 적절히 혼합해서 사용한다면 더 안전한 서비스를 만들 수 있을 것이다. (ex 비밀번호 저장)

 

📌 암호화와 성능

 

위에도 언급했지만, TDE 방식의 경우 디스크로부터 이미 읽혀진 데이터는 복호화가 완료된 상태로 InnoDB 버퍼풀에 저장되기 때문에 성능에 전혀 영향이 없다.

 

물론 쿼리가 버퍼풀에 없는 데이터를 요청할 경우, 디스크에서 복호화 과정을 거치며 사용자 쿼리 성능이 저하될 것이다.

 

다만 암호화의 경우 큰 상관없다. 왜냐하면 데이터 페이지 저장은 스레드가 분리되어있기 때문이다. MySQL 백그라운드 스레드가 수행하기 때문에 서버의 성능은 더 사용하겠지만, 사용자 쿼리의 지연은 발생하지 않는다. 

 

그렇다면 사용자 쿼리 성능말고, 서버 자원. 즉 디스크 읽기/쓰기는 얼마나 느려질까? 서비스마다 다르겠지만, 보통 읽기는 3배, 쓰기는 5배 정도 느려진다. 물론 밀리초(ms)단위라서 큰 차이가 없다고 볼 수도 있겠다.

Real MySQL 8.0 - 백은빈, 이성욱 지음

 

실질적인 성능 저하를 알기위해서는, MySQL TDE에 사용되는 AES-256 알고리즘의 특징을 알아야 한다.

AES (Advanced Encryption Standard) 알고리즘은 암호화 대상의 크기가 작은 경우 용량이 더 커질 수 있지만, MySQL 페이지는 암호화 키보다 이미 훨씬 크기때문에 별 상관없다. 그래서 TDE를 적용해서 암호화 전/후 테이블의 크기는 동일하다. 

 

다만 같은 테이블에 대해 암호화와 압축이 동시에 적용될 때, MySQL은 압축을 먼저 실행하고 암호화를 실행한다.

이는 암호화된 결과물은 기본적으로 혼돈성(Chaos)을 가지기 때문에 압축 효율이 매우 떨어지고, 암호화를 먼저해버리면 결과값이 달라져 이미 존재하는 페이지도 암호화&복호화를 중복해서 할 수도 있기 때문이다.

 

 

📌 로그 암호화

Redo, Undo, 바이너리 로그 모두 암호화 가능하다. 암호화 방법은 나중에 추가로 작성하겠다-

 

참고로 바이너리 로그를 암호화하면 mysqlbinlog등의 도구로 바이너리 로그를 통한 복구가 어렵다.

기존에는 로그만 백업해두면 이를 이용해 DB 복구가 가능했지만, 이젠 암호화되어 로그를 읽을 수 없기 때문이다.

 

비밀키가 해당 로그를 만들어낸 MySQL이 가지고 있기 때문에, 아래와 같이 mysqlbinlog 도구가 해당 MySQL 서버로 접속해서 사용하는 방법 밖에는 없다. 만약 해당 서버에 접속이 불가능하다면 바이너리 로그를 통한 복구는 불가능하다.

$ mysqlbinlog --read-from-remote-server -uroot -p -vvv 바이너리로그파일
$ Enter password: