MySQL의 암호화

데이터베이스에는 보안이 중요한 정보들이 저장되는 경우가 있다.
이러한 경우 애플리케이션에서 알고리즘을 이용해 데이터를 암호화해서 넣기도 하지만 MySQL 서버 자체에서도 실제 디스크에 저장된 데이터를 읽고 쓰는 단계(I/O레이어)에서 데이터의 암호화 및 복호화를 지원해준다. 이러한 방법을 TDE(Transparent Data Encryption)이라고 한다.

따라서 데이터베이스 사용자는 암호화 여부와 상관 없이 기능을 똑같이 이용할 수 있다.

내부 구조

MySQL에서 암호화는 키링 플러그인에 의해 관리되며 아래의 두개의 키에 의해 동작한다.

테이블스페이스 키
프라이빗 키라고도 불리며 외부 키 관리 솔루션(HashiCorp Vault), 마스터 키를 가져와 암호화된 테이블이 생성될 때마다 해당 테이블을 위한 임의의 테이블스페이스 키가 마스터 키를 이용해 암호화되어 발급된다.
테이블이 삭제되기 전까지 처음 발급된 유일한 키가 사용되지만 내부적으로만 사용하기에 보안 취약점에 노출 되지는 않는다.

마스터 키
마스터 키는 외부의 파일을 이용해서 보안 취약점에 노출 될 수 있다. 따라서 주기적으로 변경하기를 권장하며 다음과 같이 변경 할 수 있다.

ALTER INSTANCE ROTATE INNODB MASTER KEY;

테이블스페이스 키는 마스터 키를 이용해 생성된다 하였는데 마스터 키가 변경되면 기존 키를 복호화 한 다음 새로운 마스터 키로 암호화 한다.

성능 문제가 있지 않을까?

먼저 결과부터 말하면 배수로 보면 10~30배, 초로 보면 0.1~0.5ms로 차이가 있지만 사용자가 체감할 정도의 차이는 없어 운영에 큰 문제는 없다.

MySQL의 InnoDB는 버퍼 풀을 사용하고 있다했는데 버퍼 풀에서는 디스크에서 복호화한 데이터를 가지고 있고 사용자스레드(포그라운드 스레드)에서 반영하는 쿼리는 버퍼 풀에 넣어지고 관리되기 때문에 암호화 또는 복호화가 이루어지지 않는다. 단지 백그라운드 스레드가 버퍼풀에서 디스크로 동기화되거나 디스크에서 데이터를 가져올 때 암호화, 복호화 과정에서 발생한다.

또한 AES 알고리즘을 이용해서 암호화를 하는데 길이가 짧을 경우는 암호화의 키에 따라 크기가 커질 수있지만 데이터 페이지의 크기는 일반적으로 키 값보다 크기 때문에 일반적으로 사이즈에 문제는 발생하지 않는다.

왜 사용해야할까?

나의 경우 DB에 암호화를 애플리케이션 레벨에서 한 다음 저장하는 방법을 주로 사용했었는데 이는 비밀번호에 경우만 사용해서 문제가 없었다.
근데 만약 암호화된 문자가 검색 필터 또는 정렬 필터를 적용해서 조회한다면 어떻게 되는것일까?
이러한 경우가 문제가 되기 때문에 MySQL에서 제공하는 암호화 기능을 이용하면 실제 저장되는 디스크에는 암호화가 되어있고 버퍼 풀에는 원문이 있으니 검색 및 정렬필터를 적용할 수 있다.

따라서 암호화되는 필드에 따라 다르겠지만 MySQL의 암호화 또는 애플리케이션 + MySQL에 암호화를 이중으로 사용하는 것도 방법이 될 수 있다.