7. 데이터 암호화

Mysql 5.7 이후 암호화 기능은 처음에 데이터 파일에 대해서만 암호화 기능이 제공됐다. 8.0 버전부터는 추가로 리두 로그, 언두 로그, 복제를 위한 바이너리 로그 등 모두 암호화 기능을 지원하기 시작했다.

 

7.1 Mysql 서버의 데이터 암호화

Mysql 서버의 디스크 입출력

 Mysql 서버 암호화 기능은 데이터베이스 서버와 디스크 사이의 데이터 읽고 쓰기 지점에서 암호화 또는 복호화를 수행한다. 별도의 Mysql 서버에서 디스크 입출력 이외의 부분에서는 암호화 처리가 전혀 필요 없다. 즉 Mysql 서버의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행되는 것이다. 

 

 MySQL 서버에서는 사용자의 쿼리를 처리하는 과정에서 테이블의 데이터가 암호화 되어있는지 확인할 필요가없다. 왜냐하면, 스토리지에서 데이터를 쓰기전에 실시간으로 암호화하고 데이터를 읽을때도 실시간으로 복호화를 하기 때문이다. 이러한 암호화 방식을 TDE(Transparent Data Encryption) 라고 한다.

 

 

7.1.1 2단계 키 관리

: Mysql 서버의 TDE에서 암호화 키는 키링 플러그인에 의해 관리된다. 다양한 플러그인이 제공되지만, 마스터 키를 관리하는 방법만 다를 뿐 Mysql 서버 내부적으로 작동하는 방식은 모두 동일한다. 아래 그림은 2단계 키관리 아키텍처를 보여준다.

2단계 암호화 아키텍처

 Mysql 서버의 데이터 암호화는 마스터 키와 테이블스페이스(프라이빗) 키라는 2가지 종류의 키를 가지고 있다. Mysql 서버는 HashCorp Vault  같은 외부 키 관리 솔루션 or 디스크의 파일에서 마스터 키를 가져오고, 암호화된 테이블이 생성될 때마다 해당 테이블을 위한 임의의 테이블스페이스 키를 발급한다. 그리고 Mysql 서버는 마스터 키를 이용해 테이블스페이스키를 암호화해서 각 테이블의 데이터 파일 헤더에 저장한다. 이처럼 생성된 테이블스페이스 키는 테이블이 삭제되지 않는 이상 절대 변경되지 않는다. 특히 테이블스페이스 키는 외부로 노출되지 않기 때문에 보안상 취약점이 되지는 않는다.

 

 하지만 마스터 키는 외부의 파일을 이용하기 때문에 노출될 가능성이 있다. 그래서 주기적으로 변경해야 하고 아래가 명령어다.

mysql> ALTER INSTANCE ROTATE INNODB MASTER KEY;

마스터 키를 변경하면 Mysql 서버는 기존의 마스터 키를 이용해 각 테이블의 테이블스페이스 키를 복호화한 다음 다음 새로운 마스터 키로 다시 암호화한다.

 

 이렇게 2단계 암호화 방식을 사용하는 이유는 암호화 키 변경으로 인한 과도한 시스템 부하를 피하기 위해서다. Mysql 서버의 TDE에서 지원하는 암호화 알고리즘은 AES 256 비트이며, 이외는 없다. 테이블스페이스 키는 AES-256 ECB 알고리즘을 이용해 암호화되고, 실제 데이터 파일은 AES-256 CBC 알고리즘을 이용해 암호화 된다.

 

 

7.1.2 암호화와 성능

: Mysql 서버의 암호화는 TDE 방식이기 때문에 디스크로부터 한 번 읽은 데이터 페이지는 복호화되어 InnoDB의 버퍼 풀에 적재된다. 그래서 데이터 페이지가 한 번 메모리에 적대되면 암호화되지 않은 테이블과 동일한 성능을 보이는데, 쿼리가 InnoDB 버퍼 풀에 존재하지 않는 데이터 페이지를 읽어야 하는 경우 복호화 과정을 거치기 때문에 복호화 시간 동안 쿼리 처리가 지연될 것이다.

 

 데이터를 암호화한다고 해서 InnoDB 버퍼 풀의 효율이 달라지거나 메모리 사용 효율이 떨어지는 현상은 발생하지 않는다. 같은 테이블에 암호화, 압축이 동시에 적용되면 Mysql 서버는 1. 압축 2. 암호화를 적용한다. 암호화된 테이블의 데이터 페이지는 복호화된 상태로 InnoDB 버퍼 풀에 저장되지만, 압축된 데이터 페이지는 압축 또는 압축 해제의 모든 상태로 InnoDB 버퍼 풀에 존재할 수 있다. 그래서 압축 후 암호화를 수행한다.

 

 

7.1.3 암호화와 복제

: Mysql 서버의 복제에서 레플리카 서비스는 소스 서버의 모든 사용자 데이터를 동기화하기 때문에 실제 데이터 파일도 동일할 것이라 생각할 수 있다. 하지만 TDE를 이용한 암호화 사용시 마스터 키, 테이블스페이스 키는 그렇지 않다. Mysql 서버에서 기본적으모 만든 노드는 각자의 마스터 키를 할당해야 한다. 데이터 서버의 로컬 디렉터리에 마스터 키를  보관하는 경우 소스 서버와 레플리카 서버가 다른 키를 가질 수 밖에 없지만 원격으로 키 관리 솔루션을 사용하는 경우에도 소스 서버와 레플리카 서버는 서로 다른 마스터 키를 갖도록 설정해야 한다.

 

 마스터 키 자체가 레플리카로 복제되지 않기 때문이고, Mysql 서버의 백업에서 TDE의 키링 파일을 백업하지 않거나 키링 파일을 찾지 못하면 데이터를 복구할 수 없기 때문에 주의해야 한다.

 

 응용 프로그램에서 직접 암호화해서 Mysql 서버에 저장하는 경우도 있는데, 저장되는 칼럼의 값이 이미 암호화 된 것인지 여부를 Mysql 서버는 인지하지 못한다. 응용 프로그램에서 암호화된 칼럼은 인덱스를 생성하더라도 인덱스의 기능을 100% 활용할 수 없다.

 

 

7.2 언두 로그 및 리두 로그 암호화

: 테이블의 암호화를 적용해도 디스크로 저장되는 데이터만 암호화되고, Mysql 서버의 메모리에 존재하는 데이터는 복호화된 평문으로 저장되며, 이 평문 데이터가 테이블의 데이터 파일 이외의 디스크 파일로 기록되는 경우에는 여전히 평문으로 저장된다. 그래서 테이블 암호화를 적용해도 리두 로그나 언두 로그, 그리고 복제를 위한 바이너리 로그에는 평문으로 저장되는 것이다.

 

 테이블의 암호화는 일단 테이블 하나에 암호화가 적용되면 해당 테이블의 모든 데이터가 암호화 돼야 한다. 하지만 리두 로그, 언두 로그는 그렇게 적용할 수 없다. 실행중인 Mysql 서버에서 언두 로그나 리두 로그를 활성화한다고 하더라도 모든 리두 로그나 언두 로그의 데이터를 해당 시점에 한 번에 암호화해서 다시 저장할 수 없다. 

 

 그래서 Mysql 서버는 리두 로그나 언두 로그를 평문으로 저장하다가 암호화가 활성화되면 그때부터 생성되는 리두 로그나 언두 로그만 암호화해서 저장한다. 반대로 비활성화되면, 저장되는 로그만 평문으로 저장한다. 리두 로그와 언두 로그 데이터 모두 각각의 테이블스페이스 키로 암호화되고, 테이블스페이스 키는 다시 마스터 키로 암호화된다. 이때 테이블스페이스 키는 실제 테이블의 암호화에 테이블스페이스 키가 아니라 두 로그 파일을 위한 프라이빗 키를 의미한다.

 

 

7.3 바이너리 로그 암호화

: 위에서 말했듯이 테이블 암호화가 적용되어도 리두, 언두, 바이너리 로그는 평문을 저장한다. 바이너리 로그와 릴레이 로그 파일 암호화 기능은 디스크에 저장된 로그 파일에 대한 암호화만 담당하고, Mysql 서버의 메모리 내부 또는 소스 서버와 레플리카 서버 간의 네트워크 구간에서 로그 데이터를 암호화하지는 않는다.

 

 

7.3.1 바이너리 로그 암호화 키관리

: 바이너리 로그와 릴레이 로그 파일 데이터의 암호화를 위해서라도 Mysql 서버는 2단계 암호화 키 관리 방식을 이용한다. 바이너리 로그와 릴레이 로그 파일의 데이터는 파일 키로(File Key) 암호화해서 각 바이너리 로그와 릴레이 로그 파일의 헤더에 저장된다. 즉 "바이너리 로그 암호화 키"는 테이블 암호화의 마스터 키와 동일한 역할을 하며, 파일 키는 바이너리 로그와 릴레이 로그 파일 단위로 자동으로 생성되어 해당 로그 파일의 데이터 암호화에만 사용된다.

 

 Mysql 서버에서는 트랜잭션의 내용을 추적하거나 백업 복구를 위해 암호화된 바이너리 로그를 평문으로 복호화할 일이 많다. 하지만 한 번  바이너리 로그 파일이 암호화되면 바이너리 로그 암호화 키 없이는 복호화 할 수 없다. 바이너리 로그 암호화 키는 Mysql 서버만 가지고 있어 복호화가 불가능하다. mysqlbinlog 도구가 Mysql 서버에 접속해서 바이너리 로그를 가져오는 방법이면 복호화가 가능하다.