Real MySQL 7장 정리

데이터 암호화

• MySQL5.7부터 암호화 기능 지원
  • 이거는 데이터 파일(테이블스페이스)에 대해서만 지원됨
• MySQL8.0부터는 더 지원된다.
  • 리두로그, 언두로그
  • 복제를 위한 바이너리 로그 등

이게 핀케트처럼 중요한 정보를 저장하는곳에서는 응용프로그램에서 암호화 한걸 다시 DB서버에서 암호화하는 이중 암호화를 하기도 한다 함

• 어플리케이션에는 중요정보 컬럼 단위
• DB에서는 테이블 단위로 한다 한다.

MySQL 데이터 암호화

• DB서버랑 디스크 사이의 데이터 읽고쓰는 지점에서 암호화 / 복호화 수행됨
  • 디스크 입출력 이외에서는 암호화 처리가 필요X
  • 즉 InnoDB스토리지 엔진의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행된다.

2단계 키 관리

• TDE(Trasparent Data Encryption) -> 위에서 설명한 암호화 여부를 사용자가 알 필요 없는 에서 암호화 키는 키링 플러그인에 의해 관리
• 뭔가 이것저것 있기는 한데 마스터키 관리 방법만 다를 뿐 MySQL내부적으로 작동하는 방식은 동일하다.
• 그게 2-Tier 키 관리임
  • 마스터키랑 테이블스페이스키 두개를 갖고 있는데 테이블스페이스키는 프라이빗 키라고도 불린다.
    • 테이블 생성 때마다 테이블스페이스 키를 발급함
      • 마스터 키를 이용해 테이블스페이스키를 암호화해서 테이블의 테이블 파일 헤더에 저장
      • 얘는 그래서 서버 외부로 노출 자체가 안돼서 안바뀌어도 보안 취약점은 되지 않음
    • 마스터키는 vault같은 외부 키 관리 솔루션에 저장
      • 그래서 이거는 외부파일을 써서 노출 가능성이 있다.
      • 주기적으로 바꿔야한다.
        • 이걸 변경하면 테이블스페이스키를 복호화한 다음에 다시 새로운 마스터키로 암호화
          • 이렇게 하는 이유는 최대한 테이블스페이스키를 변경할 여지가 없게(바뀔 때마다 데이터파일 모든 데이터를 다시 복호화 -> 암호화 해야하니까

암호화와 성능

• 암호화한걸 가져오면 그냥 쓰는(암호화 여부 알필요 X) TDE방식이라 한번 가져오면 데이터 페이지가 복호화되어 InnoDB 버퍼 풀에 적재된다.
• 그래서 한번 복호화하고나면 암호화되지 않은 테이블이랑 동일한 성능이다. 근데 그렇지 않으면 복호화 과정 중에는 쿼리 처리가 지연된다.
• 암호화된 테이블 변경 시 다시 디스크 동기화 때 암호화해야돼서 시간소모 ㅇㅇ
  • 근데 이게 데이터 페이지 저장은 사용자 쿼리 처리 스레드가 아니라 MySQL 백그라운드 스레드가 수행
    • 그래서 실제로 시간지연은 없다.
• 같은 테이블에 암호화랑 압축이 동시에 적용되면 MySQL은 압축->암호화 순서로 한다.
  • 그 이유는
    • 암호문은 보통 랜덤한 바이트의 배열을 가지기 때문(이거를 압축하면 압축 효율 낮음)
    • 암호화된 테이블의 데이터 페이지는 복호화된 상태로 InnoDB버퍼 풀에 저장된다.
      • 압축된 데이터 페이지는 압축/압축해제 모든 상태로 InnoDB버퍼 풀에 존재 가능
        • 그래서 암호화를 먼저 하고 압축이 적용된다면 MySQL서버는 InnoDB 버퍼 풀에 존재하는 데이터 페이지에 대해서도 매번 암/복호화 수행해야한다.

암호화와 복제

• MySQL복제할 때 레플리케이션 서버에서 TDE이용 암호화 시 마스터 키랑 테이블스페이스 키는 마스터서버랑 다르다.
• 기본적으로 모든 노드는 각자의 마스터키를 할당해야 한다.
  • 로컬/원격 상관X
• 그래서 암호화하면 실제 데이터파일은 같아도 저장된(암호화된) 데이터파일은 다르다는것