Real MySQL 7장 정리

이론 정리/Database

철매존 2023. 12. 28. 12:58

728x90

데이터 암호화

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

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

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

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