배경 🐈

책 'Real MySQL 8.0'과 'MySQL을 더 빠르게, 성능 최적화 선택과 집중' 이라는 책을 가지고 현업 개발자 2분과 스터디를 진행하고 있습니다.
오늘은 'Real MySQL 8.0'의 '데이터 암호화'을 읽고 진행했던 스터디의 핵심 내용과 스터디를 하며 고민했던 부분 위주로 정리하고자 합니다.

📍 데이터 암호화

데이터베이스 서버 자체에서도 데이터의 보안을 위해 신경쓰긴 하지만 그럼에도 불구하고 유출될 위험이 존재하고, 절대 유출되어서는 안되는 중요한 데이터가 존재한다. 예를 들면 우리가 사용자 비밀번호를 애플리케이션 레벨에서 암호화하여 저장하는 것도 유출 위험을 방지하기 위한 추가적인 보안 장치다.

MySQL에서는 이 같이 중요한 데이터에 대해 MySQL 서버 차원에서 데이터 암호화 기능을 제공한다.

📌 MySQL 서버의 데이터 암호화

MySQL 서버에 InnoDB 스토리지 엔진 I/O 레이어에서만 데이터 암호화와 복호화가 실행된다.

2-Tier 키 관리 방식

MySQL 서버는 2번의 암호화를 거치는 방식으로 테이블 단위 암호화를 한다.

암호화할 테이블을 테이블스페이스 키(private key)로 한번 암호화 한 후, 마스터 키로 테이블스페이스 키를 다시 한번 더 암호화하는 방식이다.

이때 테이블스페이스 키는 테이블의 데이터파일 헤더에 저장하는데, 반면 마스터 키는 외부 파일에 저장하기 때문에 보안 위협이 발생할 수 있어 주기적인 변경이 필요하다.

그리고 마스터 키를 어디서 관리하는 지가 조금씩 달라질 수 있는데, keyring 플러그인을 사용하거나 Vault 같은 외부 솔루션을 이용할 수 있다.

언두 로그 및 리두 로그, 바이너리 로그 암호화

MySQL 8.0 버전 부터는 리두 로그나 언두 로그, 바이너리 로그 등도 모두 암호화 기능을 지원하기 시작했다.

📌 애플리케이션 암호화 vs 데이터베이스 암호화

MySQL 서버에서 암호화를 진행하는 방식처럼 데이터베이스 레벨에서 암호화를 진행하는 것 말고도 애플리케이에서 직접 암호화하는 방식도 있다.

애플리케이션에서 암호화를 진행한 경우 MySQL 서버는 그 값이 암호화된 값인지를 인지하지 못하기 때문에 그 값에 대해 인덱스 기능을 잘 활용하지 못한다. 반면 MySQL 서버에서 암호화를 진행한 경우, 인덱스 관련 작업을 처리한 후 디스크에 데이터를 저장할 때만 암호화하기 때문에 인덱스를 충분히 사용할 수 있다.

또한 애플리케이션 암호화는 칼럼 단위로 암호화를 진행하고, 데이터베이스 암호화는 테이블 단위로 암호화를 진행한다는 점도 다르다.

MySQL 서버 접속 권한이 있을 때 데이터를 확인할 수 있는지 여부도 다르다. MySQL 서버 암호화는 MySQL 서버 접속 권한이 있으면 복호화된 데이터를 확인할 수 있지만, 애플리케이션 암호화는 MySQL 서버 접속 권한이 있어도 암호화된 데이터만 확인할 수 있다.

이렇게 두 암호화는 다른 특징을 가지고 있기 때문에 목적에 따라 다르게 사용된다.

MySQL 서버의 암호화 방식은 사용자 입장에서 아무런 차이가 없는 기술이라고는 하지만 마스터 키를 관리한다거나 테이블스페이스 이동이나 복제 시에 이것저것 챙겨야 할 것이 많은 꽤 복잡한 기술이라고 느껴졌다. 그럼에도 불구하고 암호화가 필요한 도메인이 있고, 보안이 필요한 일부 데이터에만 적용할 수 있기 때문에 잘 공부한 후 적용해야겠다고 생각했다.

---

[참고 자료]
Real MySQL 8.0 (1권)