테마
데이터 암호화
TDE(Transparent Data Encryption, 투명한 데이터 암호화)는 디스크에 든 데이터를 통째로 암호화하는 방식이다. 저장할 때 자동으로 암호화하고 읽을 때 자동으로 풀어 주므로 애플리케이션은 코드를 바꿀 필요가 없다. 전체 그림은 2단계 키, 키를 보관하는 키링(keyring), 그리고 데이터 파일뿐 아니라 로그까지 암호화하는 범위다.
2단계 키 관리
- 마스터 키(master key): 테이블마다 있는 테이블스페이스(tablespace) 키를 다시 암호화하는 최상위 키다. 키링 컴포넌트(component)1나 외부 KMS(Key Management Service, 키 관리 서비스)·Vault2에 보관하고, 주기적으로 교체하는 대상이다. MySQL 8.4에서는
keyring_file플러그인이 제거됐으므로 그 대신component_keyring_file같은 컴포넌트를 사용한다. - 테이블스페이스 키(tablespace key): 테이블마다 하나씩 있고, 실제 데이터 페이지(page)를 암호화하는 데 쓴다. 이 키 자체는 마스터 키로 암호화해 테이블스페이스 헤더에 저장한다.
- 평문 접근: 데이터를 평문으로 읽으려면 먼저 마스터 키로 테이블스페이스 키를 풀고, 풀린 테이블스페이스 키로 페이지를 푼다. 그래서 마스터 키만 지키면 된다.
sql
-- keyring 컴포넌트는 서버 시작 단계에서 manifest/config로 로드
CREATE TABLE t (...) ENCRYPTION='Y';암호화 범위와 주의점
- 테이블: 테이블을 만들 때
ENCRYPTION='Y'를 지정한다. 기존 테이블은ALTER ... ENCRYPTION='Y'로 전환하며, 이때 테이블 전체를 다시 쓰는 리빌드(rebuild)가 일어난다. - 언두·리두: 언두 로그(undo log)와 리두 로그(redo log)는
innodb_undo_log_encrypt·innodb_redo_log_encrypt설정으로 따로 켠다. 테이블만 암호화하면 변경 내용을 담은 이 로그들에 평문이 남는다. - 바이너리 로그(binary log)는
binlog_encryption=ON으로 켠다. 바이너리 로그용 키는ALTER INSTANCE ROTATE BINLOG MASTER KEY로 주기적으로 교체한다. 로그를 읽는 도구인mysqlbinlog로 서버에 접속해 읽으면 자동으로 복호화된 내용을 받는다. - 복제(replication): 일반 복제에서는 원본 서버인 소스(source)가 변경 이벤트를 전송하고, 이를 받아 따라 적용하는 레플리카(replica)가 자기 키링으로 자신의 로그를 암호화한다. 그래서 두 서버가 같은 키 파일을 공유하지 않는다. 다만 암호화된 데이터·로그 파일을 그대로 복사하는 물리 복제나 복원을 한다면 원본 키도 함께 보존해야 한다.
트레이드오프
- 비용: 페이지를 암호화·복호화하느라 CPU를 더 쓴다. 이 비용이 읽기·쓰기 경로에 붙으므로 측정한 뒤 판단한다.
- 앱 암호화와 비교: TDE는 디스크나 파일을 통째로 가져가는 디스크 탈취를 막는다. 하지만 DB에 정상 접속하면 평문으로 보이므로, DB 관리자나 덤프 유출까지 막으려면 애플리케이션이 값을 암호화해 저장해야 한다. 덤프(dump)는 DB 데이터를 파일로 통째로 내보낸 것이다. 그래서 주민번호 같은 민감 칼럼은 앱(칼럼) 암호화를 겹친다.
- 백업: 데이터 파일을 그대로 복사하는 물리 백업은 암호화된 상태 그대로 남는다(SQL로 뽑는 논리 덤프는 평문이다). 그래서 키 백업을 잃으면 물리 백업이 있어도 복구할 수 없다. 키를 잃으면 데이터를 쓸 수 없으므로, 키 관리가 곧 가용성(availability, 데이터를 계속 쓸 수 있는 상태)이다.
면접 포인트
- "2단계 키가 왜 필요한가요?" → 마스터 교체 시 테이블스페이스 키만 다시 암호화 → 전체 재암호화 없이 키 순환.
- "테이블만 걸면 되나요?" → 언두·리두·바이너리까지 봐야 평문 잔재가 없다.
- "키를 잃으면?" → 복구 불가. 키 백업·관리가 본체다.
참고