책너두 (Real MySQL 8.0 1권) 18일차 (~203p)

현재 책너두 1.5기 모집 링크 입니다 : https://breakbook.notion.site

요약

• MySQL 데이터 암호화 방식을 이해하게 됨.
  • 암호화 방식을 TDE 로 부르는 이유에 대해 이해하게 됨.
    • 암호화 여부와 성관없이 사용자 쿼리를 동일하게 처리함.
• MySQL 에서 암호화 키를 2단계 키 관리 방식으로 관리한다는 것을 알게 됨.
  • 마스터키 & 테이블스페이스 키
• 암호화 했을 때, 고려해야할 성능에 대한 내용을 알게 됨.
  • AES 암호화 알고리즘으로 암호화하는 부분에 대한 내용을 이해하지 못함.. (199p)
• 테이블 동시 암호 & 압축 시, 압축 후 암호화 해야하는 이유에 대해 이해하게 됨.
• 암호화했을때 데이터베이스의 복제와 관련한 내용을 이해하게 됨.
  • 마스터 키와, 키링 파일의 백업을 함께 고려해야 함.
• keyring_file 플러그인 설치 방법과 내용들을 이해하게 됨.

메모

데이터 암호화

• 데이터 암호화 기능은 5.7 버전부터 지원되기 시작함
  • 처음에는 데이터 파일(테이블스페이스)에 대해서만 암호화 기능이 제공됨
• 8.0으로 업그레이드 되면서 데이터 파일뿐만 아니라 리두 로그, 언두 로그, 복제를 위한 바이너리 로그 등도 모두 암호화 기능을 지원하기 시작함.
• 데이터 암호화 여부는 보안 감사에 필수적으로 언급되는 부분임.
  • 핀테크 서비스처럼 중요한 정보를 저장하는 서비스에서는 응용 프로그램에서 암호화한 데이터를 데이터베이스 서버에서 다시 암호화하는 이중 암호화 방법을 선택하기도 함.
  • 응용 프로그램의 암호화는 주로 중요 정보를 가진 칼럼 단위로 암호화를 수행함.
  • 데이터베이스 수준에서는 테이블 단위로 암호화를 적용함.

MySQL 서버의 데이터 암호화

• 위 그림과 같이 데이터베이스 서버와 디스크 사이의 데이터 읽고 쓰기 지점에서 암호화 또는 복호화를 수행한다.
  • 그래서 MySQL 서버에서 디스크 입출력 이외의 부분에서는 암호화 처리가 전혀 필요하지 않음.
  • MySQL 서버(InnoDB 스토리지 엔진)의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행됨.
• MySQL 서버에서 사용자의 쿼리를 처리하는 과정에서, 테이블의 데이터가 암호화 여부를 식별할 필요가 없음.
  • 암호화된 테이블과 그렇지 않은 테이블이 동일한 처리 과정을 거침.
  • 데이터 암호화 기능이 활성화되어 있더라도 MySQL 내부와 사용자 입장에서는 아무런 차이가 없기 때문.
  • 이러한 암호화 방식을 TDE(Transparent Data Encryption) 라고 함.
    • 또는, “Data at Rest Encryption” 라고도 함.
      • 여기서 “Data at Rest” 는, 메모리(In-Progress)나 네트워크 전송(In-Transit) 단계가 아닌, 디스크에 저장(At Rest)된 단계에서만 암호화 된다는 의미로 사용되는 표현임.

2단계 키 관리

• MySQL 서버의 TDE 에서 암호화 키는 키링(KeyRing) 플러그인에 의해 관리됨.
  • 8.0 버전에서 지원되는 플러그인은 다음과 같음.
    • keyring_file : File-Based 플러그인
    • keyring_encrypted_file : Keyring 플러그인
    • keyring_okv : KMIP 플러그인
    • keyring_aws : Amazon Web Services Keyring 플러그인
  • MySQL 커뮤니티 에디션에서는 keyring_file 플러그인만 사용함.
    • 나머지 플러그인은 모두 MySQL 엔터프라이즈 에디션에서만 사용 가능함.
• 위와 같이 다양한 플러그인이 제공되지만 마스터 키를 관리하는 방법만 다를 뿐, MySQL 서버 내부적으로 작동하는 방식은 모두 동일함.
• MySQL 서버의 키링 플러그인은 2단계 (2-Tier) 키 관리 방식을 사용함.

• 위 그림은 2단계 키 관리 아키텍처를 보여줌
• MySQL 서버의 데이터 암호화는 마스터 키(master key)와 테이블스페이스 키(tablespace key) 라는 두 가지 종류의 키를 가지고 있음.
  • 테이블스페이스 키는 프라이빗 키(private key) 라고도 함.
• 그림에서 보듯, MySQL 서버는 HashiCorp Valut 같은 외부 키 관리 솔루션(KMS, Key Management Service) 또는 디스크의 파일(keyring_file 또는 keyring_encrypted_file 플러그인 사용 시)에서 마스터 키를 가져오고, 암호화된 테이블이 생성될 때마다 해당 테이블을 위한 임의의 테이블스페이스 키를 발급한다.
• MySQL 서버는 마스터 키를 이용해 테이블스페이스키를 암호화해서 각 테이블의 데이터 파일 헤더에 저장한다.
  • 이렇게 생성된 테이블스페이스 키는 테이블이 삭제되지 않는이상 절대 변경되지 않음.
  • 테이블스페이스 키는 절대 MySQL 서버 외부로 노출되지 않기 때문에 테이블스페이스 키를 주기적으로 변경하지 않아도 보안상 취약점이 되지 않음.
  • 하지만, 마스터 키는 외부의 파일을 이용하기 때문에 노출될 가능성이 있음.
    • 그래서 마스터 키는 주기적으로 변경해야 함.
• MySQL 서버의 마스터 키는 다음과 같이 변경 가능하다.

mysql> ALTER INSTANCE ROTATE INNODB MASTER KEY;

• 마스터 키를 변경하면 MySQL 서버는 기존의 마스터 키를 이용해 각 테이블의 테이블스페이스 키를 복호화한 다음, 새로운 마스터 키로 다시 암호화한다.
  • 마스터 키가 변경되는 동안 MySQL 서버의 테이블스페이스 키 자체와 데이터 파일의 데이터는 전혀 변경되지 않음.
• MySQL 서버에서 이렇게 2단계 암호화 방식을 사용하는 이유는 암호화 키 변경으로 인한 과도한 시스템 부하를 피하기 위함이다.
  • 만약 테이블스페이스 키가 변경된다면 MySQL 서버는 데이터 파일의 모든 데이터를 다시 복호화했다가 다시 암호화 해야함.
    • 이로 인해 키를 변경할 때마다 엄청난 작업을 해야 하며, 사용자 쿼리를 처리하는 데도 상당한 영향을 미침.
• MySQL 서버의 TDE 에서 지원되는 암호화 알고리즘은 AES 256 qlxmdla.
  • 이외의 알고리즘은 지원되지 않음.
  • 테이블스페이스 키는 AES-256 ECB(Electronic CodeBook) 알고리즘을 이용해 암호화 되고, 실제 데이터 파일은 AES-256 CBC(Cipher Block Chaining) 알고리즘을 이용해 암호화됨.

암호화와 성능

• MySQL 서버의 암호화는 TDE 방식이기 때문에 디스크로부터 한 번 읽은 데이터 페이지는 복호화되어 InnoDB의 버퍼풀에 적재됨.
  • 그래서 데이터 페이지가 한 번 메모리에 적재되면 암호화되지 않은 테이블과 동일한 성능을 보임
  • 하지만 쿼리가 InnoDB 버퍼 풀에 존재하지 않는 데이터 페이지를 읽어야 하는 경우에는 복호화 과정을 거치기 때문에 복호화 시간 동안 쿼리 처리가 지연되게 됨.
  • 그리고, 암호화된 테이블이 변경되면 다시 디스크로 동기화될 때 암호화돼야 하기 때문에 디스크에 저장할 대도 추가 시간이 걸림.
  • 하지만, 데이터 페이지 저장은 사용자의 쿼리를 처리하는 스레드가 아닌 MySQL 서버의 백그라운드 스레드가 수행하므로 실제 사용자 쿼리가 지연되는 것은 아님.
• AES(Adavanced Encryption Standard) 암호화 알고리즘은 암호화하고자 하는 평문의 길이가 짧은 경우, 암호화 키의 크기에 따라 암호화된 결과의 용량이 더 커질 수도 있지만, 이미 데이터 페이지는 암호화 키보다 훨씬 크기 때문에 암호화 결과가 평문의 결과와 동일한 크기의 암호문을 반환함. (무슨말 일까 ..)
  • 그래서 TDE를 적용한다고 해도 데이터 파일의 크기는 암호화되지 않은 테이블과 동일한 크기를 가짐.
  • 즉, 암호화한다고 해서 InnoDB 버퍼 풀의 효율이 달라지거나 메모리 사용 효율이 떨어지는 현상은 발생하지 않음.
• 같은 테이블에 대해 암호화와 압축이 동시에 적용되면 MySQL 서버는 압축을 먼저 실행하고 암호화를 적용한다.
• 압축이 암호화보다 먼저 실행되는 이유는 다음과 같다.
  • 일반적으로 암호화된 결과문은 랜덤한 바이트 배열을 가지게됨. → 이는 압축률을 상당히 떨어뜨림.
    • 그래서 최대한 압축 효율을 높이기 위해 사용자의 데이터를 그대로 압축해서 용량을 최소화한 후 암호화를 적용함.
  • 암호화된 테이블의 데이터 페이지는 복호화된 상태로 InnoDB 버퍼 풀에 저장되지만, 압축된 데이터 페이지는 압축 또는 압축 해제의 모든 상태로 InnoDB 버퍼 풀에 존재할 수 있다.
    • 그래서 암호화가 먼저 실행되고 압축이 적용된다면 MySQL 서버는 InnoDB 버퍼 풀에 존재하는 데이터 페이지에 대해서도 매번 암복호화 작업을 수행해야 된다.
• 암호화된 테이블과 그렇지 않은 테이블의 디스크 읽고 쓰기 시간을 비교한 예시가 잘 설명되어 있음.(199-200p)

암호화와 복제

• MySQL 서버의 복제에서 레플리카 서버는 소스 서버의 모든 사용자 데이터를 동기화하기 때문에 실제 데이터 파일도 동일할 것이라 생각할 수 있음.
  • 하지만, TDE 를 이용한 암호화 사용 시, 마스터 키와 테이블스페이스 키는 그렇지 않음.
• MySQL 서버에서 기본적으로 모든 노드는 각자의 마스터 키를 할당해야 한다.
• 데이터베이스 서버의 로컬 디렉터리에 마스터 키를 관리하는 경우, 소스 서버와 레플리카 서버가 다른 키를 가질 수밖에 없음.
  • 원격으로 키 관리 솔루션을 사용하는 경우에도 소스 서버와 레플리카 서버는 서로 다른 마스터 키를 갖도록 설정해야 함.
• 마스터 키 자체가 레플리카로 복제되지 않기 때문에 테이블스페이스 키 또한 레플리카로 복제되지 않음.
  • 결국, 소스 서버와 레플리카 서버는 서로 각자의 마스터 키와 테이블 스페이스 키를 관리함.
  • 그래서, 복제 멤버들의 데이터 파일은 암호화 되기 전의 값이 동일하더라도 실제 암호화된 데이터가 저장된 데이터 파일의 내용은 완전히 달라짐.
• 복제 소스 서버의 마스터 키를 변경할 때는 ALTER INSTANCE ROTATE INNODB MASTER KEY 명령을 실행 한다.
  • 이 명령 자체는 레플리카 서버로 복제되지만, 실제 소스 서버의 마스터 키 자체가 레플리카 서버로 전달되는 것은 아님.
  • 그래서, 마스터 키 로테이션을 실행하면 소스 서버와 레플리카 서버가 각각 서로 다른 마스터 키를 새로 발급 받는다.
• MySQL 서버의 백업에서 TDE의 키링(Key Ring) 파일을 백업하지 않는 경우가 있는데, 이 경우 키링 파일을 찾지 못하면 데이터를 복구 할 수 없게 됨.
  • 키링 파일을 데이터 백업과 별도로 백업한다면, 마스터 키 로테이션 명령으로 TDE의 마스터 키가 언제 변경됐는지까지 기억하고 있어야 함.
• 보안을 위해 키링 파일을 데이터 파일과 별도로 보관하는 것을 권장함.
  • 복구를 감안하고 백업 방식을 선택해야함.
• 마스터 키도 계속 변경될 수 있기 때문에 백업마다 키링 파일의 백업도 함께 고려하자.

keyring_file 플러그인 설치

• MySQL 서버의 데이터 암호화 기능인 TDE 의 암호화 키 관리는 플러그인 방식으로 제공됨.
• keyring_file 플러그인은 MySQL 커뮤니티 에디션에서만 사용 가능함.
• keyring_file 플러그인은 테이블스페이스 키를 암호화하기 위한 마스터 키를 디스크의 파일로 관리함.
  • 이때, 마스터 키는 평문으로 디스크에 저장됨.
  • 즉, 마스터 키가 저장된 파일이 외부에 노출된다면 데이터 암호화는 무용지물됨.

keyring_file 플러그인은 마스터 키를 암호화하지 않은 상태의 평문으로 로컬 디스크에 저장하기 때문에 보안 요건을 충족시켜주진 않음. 그래도 꼭 keyring_file 플러그인을 사용하고자 한다면 MySQL 서버가 시작될 때만 키링 파일을 다른 서버로부터 다운로드해서 로컬 디스크에 저장한 후 MySQL 서버를 시작하는 방법을 고려해 보자.
그리고, 일단 MySQL 서버가 시작되면 MySQL 서버가 마스터 키를 메모리에 캐시하기 때문에 로컬 디스크의 키링 파일을 삭제해도 MySQL 서버가 작동하는 데는 아무 문제가 없음.
마스터 키를 로테이션 하는 경우, 로컬의 키링 파일이 최신이 되므로 다시 외부 서버에 복사해 둬야 함.”
Percona Server 는 HashiCorp Vault 를 연동하는 키 관리 플러그인을 오픈 소스로 제공함. → MySQL 커뮤니티 에디션에서도 문제 없이 사용할 수 있음.

• MySQL 서버의 다른 플러그인과 달리, TDE 플러그인의 경우 MySQL 서버가 시작되는 단계에서도 가장 빨리 초기화돼야 함.
  • 그래서 MySQL 서버의 설정 파일(my.cnf)에서 early-plugin-load 시스템 변수에 keyring_file 플러그인을 위한 라이브러리 (”keyring_file.so”)를 명시하면 된다.
  • keyring_file 플러그인이 마스터 키를 저장할 키링 파일의 경로를 kering_file_data 설정에 명시하면 됨.
  • keyring_file_data 설정의 경로는 오직 하나의 MySQL 서버만 참조해야 함.
  • 하나의 리눅스 서버에 MySQl 서버가 2개 이상 실행 중이라면 각 MySQL 서버가 서로 다른 키링 파일을 사용하도록 설정해야 함.

early-plugin-load = keyring_file.so
keyring_file_data = /very/secure/directory/tde_master.key

• MySQl 서버의 설정 파일이 준비되면 MySQL 서버 재시작시 자동으로 keyring_file 플러그인이 초기화됨.
• keyring_file 플러그인 초기화 여부는 SHOW PLUGINS 명령으로 확인 가능함.
• keyring_file 플러그인이 초기화되면 MySQL 서버는 플러그인의 초기화와 동시에 keyring_file_data 시스템 변수의 경로에 빈 파일을 생성함.
  • 플러그인만 초기화된 상태일 뿐, 아직 마스터 키를 사용한 적이 없기 때문에 실제 키링 파일의 내용은 비어있음.
  • 데이터 암호화 기능을 사용하는 테이블을 생성하거나 마스터 로테이션을 실행하면 키링 파일의 마스터 키가 초기화된다.