7.1 MySQL 서버의 데이터 암호화

• 데이터베이스 서버와 디스크 사이의 데이터 읽고 쓰기 지점에서 암호화 또는 복호화를 수행한다.
• 디스크 입출력 이외의 부분에서는 암호화 처리가 전혀 필요치 않다. MySQL 서버(InnoDB 스토리지 엔진)의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행된다.
• 암호화 여부를 식별할 필요가 없고, 암호화 여부와 관계없이 테이블은 동일한 처리 과정을 거친다. 암호화 여부와 관계없이 MySQL 내부와 사용자 입장에서는 아무런 차이가 없으므로 이러한 암호화 방식을 TDE(Transparent Data Encryption)이라고 한다.

7.1.1 2단계 키 관리

• MySQL 서버의 암호화는 마스터 키와 테이블스페이스 키라는 두 가지 종류의 키를 가지고 있다.
• 테이블스페이스 키는 프라이빗 키이고, 마스터 키는 외부 키 관리 솔루션(KMS)나 디스크 파일에서 가져온다. 암호화된 테이블이 생성될 때마다 해당 테이블을 위한 임의의 테이블스페이스 키를 발급한다. 마스터 키를 이용해 테이블스페이스 키를 암호화해서 각 테이블의 데이터 파일 헤더에 저장한다.
• 테이블스페이스 키는 테이블이 삭제되지 않는 한 절대 변경되지 않고, 서버 외부로 노출되지 않는다.
• 마스터 키는 외부의 파일이므로 노출 가능성이 있어, 주기적으로 변경해야 한다. MySQL 서버의 마스터 키는 MySQL 명령으로 변경할 수 있다. ALTER INSTANCE ROTATE INNODB MASTER KEY;
  
• 마스터 키를 변경하면 MySQL 서버는 기존의 마스터 키를 이용해 각 테이블의 테이블스페이스 키를 복호화한 다음 다시 새로운 마스터 키로 암호화한다. 이때 테이블스페이스 키 자체와 데이터 파일의 데이터는 전혀 변경되지 않는다.
  
• 2단계 암호화를 사용하는 이유는 암호화 키 변경으로 인한 과도한 시스템 부하를 막기 위해서다. 테이블스페이스 키가 변경된다면 데이터 파일의 모든 데이터를 다시 복호화했다가 암호화해야하므로 엄청난 작업이 된다.
  
• MySQL 서버의 TDE에서 지원하는 암호화 알고리즘은 AES 256비트이며, 이외의 알고리즘은 지원되지 않는다.

7.1.2 암호화와 성능

• TDE 방식이므로 디스크로부터 한 번 읽은 데이터 페이지는 복호화되어 InnoDB의 버퍼 풀에 적재된다. 그래서 데이터 페이지가 한 번 메모리에 적재되면 암호화되지 않은 테이블과 동일한 성능을 보인다.
• 하지만 InnoDB 버퍼 풀에 존재하지 않는 데이터 페이지를 읽어야 하는 경우, 복호화 과정을 거치므로 복호화 시간동안 지연된다.
• TDE를 적용한다 해도 데이터 파일의 크기는 암호화되지 않은 테이블과 동일하다. 암호화한다고 해서 InnoDB 버퍼 풀의 효율이 달라지거나, 메모리 사용 효율이 떨이지진 않는다.
  
• 한 테이블에 대해 암호화와 압축이 동시에 적용된다면, 압축을 먼저 실행하고 암호화를 한다.
  • 이유
    • 암호화된 결과문은 랜덤 바이트열이라 압축률을 떨어뜨린다.
    • 압축된 데이터 페이지는 압축, 압축 해제의 모든 상태로 InnoDB 버퍼 풀에 존재한다.

7.1.3 암호화와 복제

• 모든 노드는 각자의 마스터 키를 할당해야 한다. 소스 서버와 레플리카 서버는 서로 다른 마스터 키를 갖도록 설정해야 한다.
• 소스 서버와 레플리카 서버는 서로 각자의 마스터 키와 테이블스페이스 키를 관리하기 때문에 복제 멤버들의 데이터 파일은 암호화되기 전의 값이 동일하더라도 실제 암호화된 데이터가 저장된 데이터 파일의 내용은 완전히 달라진다.
• 마스터 키도 계속 변경될 수 있으므로 백업마다 키링 파일의 백업도 함께 해야한다.

7.2 keyring_file 플러그인 설치

필요할 때 다시 보기

7.3 테이블 암호화

어떤 키링 플러그인을 사용하든 관계없이 암호화된 테이블을 생성하고 활용하는 방법은 동일하다.

7.3.1 테이블 생성

테이블 생성 구문과 동일하며, 마지막에 ENCRYPTION=’Y’ 옵션만 추가로 넣으면 된다.

그러면 테이블 데이터가 디스크에 기록될 때는 자동으로 암호화되고, 디스크에서 메모리로 읽어올 때 복호화된다.

7.3.2 응용 프로그램 암호화와의 비교

• 범위 검색 등을 하려면 MySQL 서버의 암호화를 사용해야 한다. 응용 프로그램 암호화를 하면, 암호화된 채로 정렬되기 때문에 범위 검색이 불가능하다.
• 응용 프로그램의 암호화와 MySQL 서버의 암호화 기능 중 선택해야한다면 MySQL 서버의 암호화 기능을 선택하는 것이 낫다.
• MySQL 서버의 TDE 기능으로 암호화하면 실행 중인 MySQL 서버에 로그인할 수 있다면 모든 데이터를 평문으로 확인할 수 있다. 하지만 응용 프로그램 암호화는 MySQL 서버에 로그인해도 평문의 내용을 확인할 수 없다.
• 서비스 요건에 따라 적합한 암호화를 선택하자.

7.3.3 테이블스페이스 이동

• 테이블을 다른 서버로 복사하는 경우 또는 특정 테이블의 데이터 파일만 백업했다가 복구하는 경우라면, 테이블스페이스 이동 기능이 레코드를 덤프했다가 복구하는 방식보다 훨씬 효율적이고 빠르다.
• TDE로 암호화된 테이블에 대해 FLUSH TABLES source_table FOR EXPORT 명령을 실행하면 MySQL 서버는 임시로 사용할 마스터 키를 발급해서 source_table.cfp라는 파일로 기록한다. 그리고 암호화된 테이블의 테이블스페이스 키를 기존 마스터 키로 복호화한 후, 임시로 발급한 마스터 키를 이용해 다시 암호화해서 데이터 파일의 헤더 부분에 저장한다. 그래서 암호화된 테이블의 경우, 테이블스페이스 이동 기능을 사용할 때는 반드시 데이터 파일과 임시 마스터 키가 저장된 cfp 파일을 함께 복사해야 한다.
  

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

• 테이블의 암호화는 일단 테이블 하나에 대해 암호화가 적용되면 해당 테이블의 모든 데이터가 암호화되야 하지만, 리두 로그나 언두 로그는 그렇게 적용할 수 없다. 실행 중인 MySQL 서버에서 언두 로그나 리두 로그를 활성화한다해도 모든 리두 로그나 언두 로그의 데이터를 해당 시점에 한 번에 암호화해서 다시 저장할 수 없다.
• 암호화가 활성화되면 그때부터 생성되는 리두 로그나 언두 로그만 암호화해서 저장한다. 암호화가 활성 상태였다가 비활성화되면 그때부터 저장되는 로그만 평문으로 저장한다.
• 리두 로그와 언두 로그를 위한 각각의 프라이빗 키가 발급되고, 해당 프라이빗 키는 마스터 키로 암호화되어 리두 로그 파일과 언두 로그 파일의 헤더에 저장된다.

7.5 바이너리 로그 암호화

• 바이너리 로그는 긴 시간 동안 보관하기도 하므로, 암호화가 중요할 수 있다.
• 바이너리 로그와 릴레이 로그 파일 암호화 기능은 디스크에 저장된 로그 파일에 대한 암호화만 담당하고, MySQL 서버의 메모리 내부 또는 소스 서버와 레플리카 서버 간의 네트워크 구간에서 로그 데이터를 암호화하진 않는다. 복제 멤버 간의 네트워크 구간에서도 바이너리 로그를 암호화하려면 MySQL 복제를 위한 계정이 SSL을 사용하도록 설정하면 된다.
  

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

• 2단계 암호화 키 관리 방식을 사용한다.
• 바이너리 로그 암호화 키는 테이블 암호화의 마스터 키와 동일한 역할
• 파일 키는 바이너리 로그와 릴레이 로그 파일 단위로 자동으로 생성되어 해당 로그 파일의 데이터 암호화에만 사용된다.

7.5.2 바이너리 로그 암호화 키 변경

• 다음 명령으로 변경할 수 있다. ALTER INSTANCE ROTATE BINLOG MASTER KEY;