데브러너 (DevRunner)

17.13 InnoDB Data-at-Rest Encryption

InnoDB는 data-at-rest 암호화를 file-per-table 테이블스페이스, general 테이블스페이스, mysql 시스템 테이블스페이스, redo 로그, undo 로그에 대해 지원합니다.

스키마와 general 테이블스페이스에 대해 암호화 기본값을 설정할 수 있습니다. 이를 통해 DBA는 해당 스키마와 테이블스페이스에 생성되는 테이블이 암호화되는지 여부를 제어할 수 있습니다.

InnoDB data-at-rest 암호화의 기능과 기능 세트는 이 절의 다음 주제들에서 설명합니다.

About Data-at-Rest Encryption

InnoDB는 master encryption key와 테이블스페이스 키로 구성된 2단계 암호화 키 아키텍처를 사용합니다. 테이블스페이스가 암호화되면 테이블스페이스 키가 암호화되어 테이블스페이스 헤더에 저장됩니다. 애플리케이션 또는 인증된 사용자가 암호화된 테이블스페이스 데이터를 액세스하려고 할 때, InnoDB는 master encryption key를 사용하여 테이블스페이스 키를 복호화합니다. 테이블스페이스 키의 복호화된 버전은 변경되지 않지만, master encryption key는 필요에 따라 변경될 수 있습니다. 이 동작을 _master key rotation_이라고 합니다.

Data-at-rest 암호화 기능은 master encryption key 관리를 위한 키링 컴포넌트 또는 플러그인에 의존합니다.

모든 MySQL 에디션에는 키링 데이터를 서버 호스트의 로컬 파일에 저장하는 component_keyring_file 컴포넌트가 제공됩니다.

MySQL Enterprise Edition은 추가적인 키링 컴포넌트와 플러그인을 제공합니다:

component_keyring_encrypted_file: 키링 데이터를 서버 호스트의 로컬에 있는 암호화되고 패스워드로 보호되는 파일에 저장합니다.
keyring_okv: KMIP 호환 백엔드 키링 스토리지 제품과 함께 사용하기 위한 KMIP 1.1 플러그인입니다. 지원되는 KMIP 호환 제품에는 Oracle Key Vault, Gemalto KeySecure, Thales Vormetric 키 관리 서버, Fornetix Key Orchestration과 같은 중앙 집중식 키 관리 솔루션이 포함됩니다.
keyring_aws: Amazon Web Services Key Management Service (AWS KMS)와 통신하여 키 생성용 백엔드로 사용하고, 키 저장을 위해 로컬 파일을 사용합니다.
keyring_hashicorp: 백엔드 스토리지를 위해 HashiCorp Vault와 통신합니다.

주의

암호화 키 관리를 위해 component_keyring_file 및 component_keyring_encrypted_file 컴포넌트는 규제 준수 솔루션으로 사용하기 위한 것이 아닙니다. PCI, FIPS 등의 보안 표준은 키 볼트 또는 하드웨어 보안 모듈 (HSM)에 있는 암호화 키를 보호, 관리 및 보안하기 위해 키 관리 시스템 사용을 요구합니다.

안전하고 견고한 암호화 키 관리 솔루션은 보안과 다양한 보안 표준 준수를 위해 매우 중요합니다. Data-at-rest 암호화 기능이 중앙 집중식 키 관리 솔루션을 사용할 때 이 기능은 “MySQL Enterprise Transparent Data Encryption (TDE)”이라고 합니다.

Data-at-rest 암호화 기능은 Advanced Encryption Standard (AES) 블록 기반 암호화 알고리즘을 지원합니다. 테이블스페이스 키 암호화에는 Electronic Codebook (ECB) 블록 암호화 모드를 사용하고, 데이터 암호화에는 Cipher Block Chaining (CBC) 블록 암호화 모드를 사용합니다.

Data-at-rest 암호화 기능에 대한 FAQ는 Section A.17, “MySQL 9.5 FAQ: InnoDB Data-at-Rest Encryption”를 참고하십시오.

Encryption Prerequisites

키링 컴포넌트 또는 플러그인은 startup 시에 설치되고 구성되어야 합니다. 초기 로딩을 통해 해당 컴포넌트 또는 플러그인이 InnoDB 스토리지 엔진 초기화 이전에 사용 가능하도록 합니다. 키링 설치 및 구성 지침은 Section 8.4.5, “The MySQL Keyring”을 참조하십시오. 이 지침에서는 선택한 컴포넌트 또는 플러그인이 활성 상태인지 확인하는 방법을 보여 줍니다.

한 번에 하나의 키링 컴포넌트 또는 플러그인만 활성화해야 합니다. 여러 키링 컴포넌트 또는 플러그인을 활성화하는 것은 지원되지 않으며 결과가 예상과 다를 수 있습니다.

주의

MySQL 인스턴스에서 암호화된 테이블스페이스가 한 번 생성되면, 해당 암호화된 테이블스페이스를 생성할 때 로드되었던 키링 컴포넌트 또는 플러그인을 startup 시 계속 로드해야 합니다. 이를 수행하지 않으면 서버 시작 및 InnoDB 복구 중 오류가 발생합니다.

프로덕션 데이터를 암호화할 때는 master encryption key 손실을 방지하기 위한 조치를 반드시 수행해야 합니다. Master encryption key를 분실하면, 암호화된 테이블스페이스 파일에 저장된 데이터는 복구할 수 없습니다. component_keyring_file 또는 component_keyring_encrypted_file 컴포넌트를 사용하는 경우, 첫 번째 암호화된 테이블스페이스를 생성한 직후, master key rotation 이전, 그리고 master key rotation 이후에 키링 데이터 파일의 백업을 생성하십시오. 각 컴포넌트에 대해, 그 구성 파일이 데이터 파일 위치를 나타냅니다. keyring_okv 또는 keyring_aws 플러그인을 사용하는 경우, 필요한 구성을 수행했는지 확인하십시오. 지침은 Section 8.4.5, “The MySQL Keyring”을 참조하십시오.

Defining an Encryption Default for Schemas and General Tablespaces

default_table_encryption 시스템 변수는 스키마와 general 테이블스페이스에 대한 기본 암호화 설정을 정의합니다. CREATE TABLESPACE와 CREATE SCHEMA 연산은 ENCRYPTION 절이 명시적으로 지정되지 않은 경우 default_table_encryption 설정을 적용합니다.

ALTER SCHEMA 및 ALTER TABLESPACE 연산은 default_table_encryption 설정을 적용하지 않습니다. 기존 스키마 또는 general 테이블스페이스의 암호화를 변경하려면 ENCRYPTION 절을 명시적으로 지정해야 합니다.

default_table_encryption 변수는 SET 구문을 사용해 개별 클라이언트 연결에 대해 또는 글로벌하게 설정할 수 있습니다. 예를 들어, 다음 문장은 스키마와 테이블스페이스에 대한 기본 암호화를 글로벌하게 활성화합니다:

1mysql> SET GLOBAL default_table_encryption=ON;

스키마에 대한 기본 암호화 설정은 스키마를 생성하거나 변경할 때 DEFAULT ENCRYPTION 절을 사용하여 정의할 수도 있습니다. 예를 들면 다음과 같습니다:

1mysql> CREATE SCHEMA test DEFAULT ENCRYPTION = 'Y';

스키마를 생성할 때 DEFAULT ENCRYPTION 절이 지정되지 않은 경우, default_table_encryption 설정이 적용됩니다. 기존 스키마의 기본 암호화를 변경하려면 반드시 DEFAULT ENCRYPTION 절을 지정해야 합니다. 그렇지 않으면 스키마는 현재 암호화 설정을 유지합니다.

기본적으로 테이블은 생성되는 스키마 또는 general 테이블스페이스의 암호화 설정을 상속합니다. 예를 들어, 암호화가 활성화된 스키마에 생성된 테이블은 기본적으로 암호화됩니다. 이 동작을 통해 DBA는 스키마와 general 테이블스페이스의 암호화 기본값을 정의하고 강제하여 테이블 암호화 사용을 제어할 수 있습니다.

암호화 기본값은 table_encryption_privilege_check 시스템 변수를 활성화하여 강제할 수 있습니다. table_encryption_privilege_check가 활성화되어 있을 때, 암호화 설정이 default_table_encryption 설정과 다른 스키마 또는 general 테이블스페이스를 생성하거나 변경할 때, 혹은 기본 스키마 암호화와 다른 암호화 설정으로 테이블을 생성하거나 변경할 때 권한 검사가 발생합니다. table_encryption_privilege_check가 비활성화되어 있을 때(기본값), 권한 검사는 발생하지 않고 앞서 언급한 연산은 경고와 함께 수행이 허용됩니다.

TABLE_ENCRYPTION_ADMIN 권한은 table_encryption_privilege_check가 활성화되어 있을 때 기본 암호화 설정을 무시(override)하는 데 필요합니다. DBA는 이 권한을 부여하여 사용자가 스키마 또는 general 테이블스페이스를 생성하거나 변경할 때 default_table_encryption 설정과 다르게 동작하도록 하거나, 테이블을 생성 또는 변경할 때 기본 스키마 암호화에서 벗어나도록 할 수 있습니다. 이 권한은 테이블을 생성하거나 변경할 때 general 테이블스페이스의 암호화와 다르게 설정하는 것은 허용하지 않습니다. 테이블은 자신이 위치한 general 테이블스페이스와 동일한 암호화 설정을 가져야 합니다.

File-Per-Table Tablespace Encryption

File-per-table 테이블스페이스는 CREATE TABLE 문에서 ENCRYPTION 절이 명시적으로 지정되지 않으면 테이블이 생성되는 스키마의 기본 암호화를 상속합니다.

1mysql> CREATE TABLE t1 (c1 INT) ENCRYPTION = 'Y';

기존 file-per-table 테이블스페이스의 암호화를 변경하려면 ENCRYPTION 절을 지정해야 합니다.

1mysql> ALTER TABLE t1 ENCRYPTION = 'Y';

table_encryption_privilege_check가 활성화되어 있을 때, 기본 스키마 암호화와 다른 설정의 ENCRYPTION 절을 지정하려면 TABLE_ENCRYPTION_ADMIN 권한이 필요합니다. Defining an Encryption Default for Schemas and General Tablespaces를 참조하십시오.

General Tablespace Encryption

default_table_encryption 변수는 CREATE TABLESPACE 문에서 ENCRYPTION 절이 명시적으로 지정되지 않은 경우 새로 생성된 general 테이블스페이스의 암호화를 결정합니다.

1mysql> CREATE TABLESPACE `ts1` ADD DATAFILE 'ts1.ibd' ENCRYPTION = 'Y' Engine=InnoDB;

기존 general 테이블스페이스의 암호화를 변경하려면 ENCRYPTION 절을 지정해야 합니다.

1mysql> ALTER TABLESPACE ts1 ENCRYPTION = 'Y';

table_encryption_privilege_check가 활성화되어 있을 때, default_table_encryption 설정과 다른 설정의 ENCRYPTION 절을 지정하려면 TABLE_ENCRYPTION_ADMIN 권한이 필요합니다. Defining an Encryption Default for Schemas and General Tablespaces를 참조하십시오.

Doublewrite File Encryption

MySQL 9.5에서는 InnoDB가 암호화된 테이블스페이스에 속한 doublewrite 파일 페이지를 자동으로 암호화합니다. 따로 작업할 필요는 없습니다. Doublewrite 파일 페이지는 관련 테이블스페이스의 암호화 키를 사용하여 암호화됩니다. 테이블스페이스 데이터 파일에 기록되는 동일한 암호화된 페이지가 doublewrite 파일에도 기록됩니다. 암호화되지 않은 테이블스페이스에 속한 doublewrite 파일 페이지는 암호화되지 않은 상태로 유지됩니다.

복구 중에는 암호화된 doublewrite 파일 페이지가 복호화되고 손상 여부를 확인합니다.

mysql System Tablespace Encryption

mysql 시스템 테이블스페이스에는 mysql 시스템 데이터베이스와 MySQL 데이터 딕셔너리 테이블이 포함됩니다. 이 테이블스페이스는 기본적으로 암호화되어 있지 않습니다. mysql 시스템 테이블스페이스에 대한 암호화를 활성화하려면 ALTER TABLESPACE 문에서 테이블스페이스 이름과 ENCRYPTION 옵션을 지정합니다.

1mysql> ALTER TABLESPACE mysql ENCRYPTION = 'Y';

mysql 시스템 테이블스페이스에 대한 암호화를 비활성화하려면 ALTER TABLESPACE 문에서 ENCRYPTION = 'N'을 설정합니다.

1mysql> ALTER TABLESPACE mysql ENCRYPTION = 'N';

mysql 시스템 테이블스페이스에 대한 암호화를 활성화하거나 비활성화하려면 인스턴스의 모든 테이블에 대해 CREATE TABLESPACE 권한이 필요합니다 (CREATE TABLESPACE on *.*).

Redo Log Encryption

Redo 로그 데이터 암호화는 innodb_redo_log_encrypt 구성 옵션을 사용하여 활성화합니다. Redo 로그 암호화는 기본적으로 비활성화되어 있습니다.

테이블스페이스 데이터와 마찬가지로 redo 로그 데이터 암호화는 redo 로그 데이터가 디스크에 기록될 때 수행되고, redo 로그 데이터가 디스크에서 읽힐 때 복호화가 수행됩니다. Redo 로그 데이터가 메모리로 읽혀지면 암호화되지 않은 형태가 됩니다. Redo 로그 데이터는 테이블스페이스 암호화 키를 사용하여 암호화 및 복호화됩니다.

innodb_redo_log_encrypt가 활성화되면 디스크에 존재하는 암호화되지 않은 redo 로그 페이지는 암호화되지 않은 상태로 유지되며, 새 redo 로그 페이지는 암호화된 형태로 디스크에 기록됩니다. 마찬가지로 innodb_redo_log_encrypt가 비활성화되면 디스크에 존재하는 암호화된 redo 로그 페이지는 암호화된 상태로 유지되며, 새 redo 로그 페이지는 암호화되지 않은 형태로 디스크에 기록됩니다.

테이블스페이스 암호화 키를 포함한 redo 로그 암호화 메타데이터는 가장 최근 체크포인트 LSN을 가진 redo 로그 파일의 헤더에 저장됩니다. 암호화 메타데이터를 포함한 redo 로그 파일이 제거되면 redo 로그 암호화는 비활성화됩니다.

Redo 로그 암호화가 활성화되면, 키링 컴포넌트 또는 플러그인 없이, 또는 암호화 키 없이 일반 재시작(normal restart)을 수행할 수 없습니다. 이는 startup 시 InnoDB가 redo 페이지를 스캔해야 하는데, redo 로그 페이지가 암호화된 경우 이를 수행할 수 없기 때문입니다. 키링 컴포넌트 또는 플러그인, 혹은 암호화 키가 없는 경우, redo 로그 없이 강제 startup (SRV_FORCE_NO_LOG_REDO)만 가능합니다. Section 17.20.3, “Forcing InnoDB Recovery”를 참조하십시오.

Undo Log Encryption

Undo 로그 데이터 암호화는 innodb_undo_log_encrypt 구성 옵션을 사용하여 활성화합니다. Undo 로그 암호화는 undo tablespaces에 존재하는 undo 로그에 적용됩니다. Section 17.6.3.4, “Undo Tablespaces”를 참고하십시오. Undo 로그 데이터 암호화는 기본적으로 비활성화되어 있습니다.

테이블스페이스 데이터와 마찬가지로 undo 로그 데이터 암호화는 undo 로그 데이터가 디스크에 기록될 때 수행되고, undo 로그 데이터가 디스크에서 읽힐 때 복호화가 수행됩니다. Undo 로그 데이터가 메모리로 읽혀지면 암호화되지 않은 형태가 됩니다. Undo 로그 데이터는 테이블스페이스 암호화 키를 사용하여 암호화 및 복호화됩니다.

innodb_undo_log_encrypt가 활성화되면 디스크에 존재하는 암호화되지 않은 undo 로그 페이지는 암호화되지 않은 상태로 유지되며, 새 undo 로그 페이지는 암호화된 형태로 디스크에 기록됩니다. 마찬가지로 innodb_undo_log_encrypt가 비활성화되면 디스크에 존재하는 암호화된 undo 로그 페이지는 암호화된 상태로 유지되며, 새 undo 로그 페이지는 암호화되지 않은 형태로 디스크에 기록됩니다.

테이블스페이스 암호화 키를 포함한 undo 로그 암호화 메타데이터는 undo 로그 파일의 헤더에 저장됩니다.

참고

Undo 로그 암호화가 비활성화된 경우라도, 서버는 암호화된 undo 로그 데이터를 포함했던 undo 테이블스페이스가 truncate될 때까지, undo 로그 데이터를 암호화하는 데 사용되었던 키링 컴포넌트 또는 플러그인을 계속 필요로 합니다. (암호화 헤더는 undo 테이블스페이스가 truncate될 때에만 undo 테이블스페이스에서 제거됩니다.) Undo 테이블스페이스를 truncate하는 방법에 대한 정보는 Truncating Undo Tablespaces를 참조하십시오.

Master Key Rotation

Master encryption key는 주기적으로, 그리고 키가 손상되었다고 의심되는 경우마다 교체(rotation)해야 합니다.

Master key rotation은 원자적인 인스턴스 수준 연산입니다. Master encryption key가 교체될 때마다 MySQL 인스턴스의 모든 테이블스페이스 키는 다시 암호화되어 각자의 테이블스페이스 헤더에 다시 저장됩니다. 원자적 연산으로서, rotation 연산이 시작되면 모든 테이블스페이스 키에 대한 재암호화가 반드시 성공해야 합니다. Master key rotation이 서버 장애로 인해 중단되면, 서버를 재시작할 때 InnoDB가 해당 연산을 정방향(forward)으로 진행합니다. 자세한 내용은 Encryption and Recovery를 참조하십시오.

Master encryption key를 교체하는 것은 master encryption key를 변경하고 테이블스페이스 키를 재암호화하는 것만 수행합니다. 관련된 테이블스페이스 데이터를 복호화하거나 재암호화하지는 않습니다.

Master encryption key를 교체하려면 ENCRYPTION_KEY_ADMIN 권한(또는 더 이상 사용되지 않는 SUPER 권한)이 필요합니다.

Master encryption key를 교체하려면 다음을 실행합니다:

1mysql> ALTER INSTANCE ROTATE INNODB MASTER KEY;

ALTER INSTANCE ROTATE INNODB MASTER KEY는 동시에 DML을 지원합니다. 그러나 테이블스페이스 암호화 연산과 동시에 실행될 수 없으며, 동시에 실행될 때 발생할 수 있는 충돌을 방지하기 위해 락이 사용됩니다. ALTER INSTANCE ROTATE INNODB MASTER KEY 연산이 실행 중인 경우, 해당 연산이 완료되기 전에는 테이블스페이스 암호화 연산을 진행할 수 없으며, 그 반대도 마찬가지입니다.

Encryption and Recovery

암호화 연산 중에 서버 장애가 발생하면, 서버가 재시작될 때 해당 연산이 정방향으로 수행됩니다. General 테이블스페이스의 경우, 암호화 연산은 마지막으로 처리된 페이지부터 백그라운드 스레드에서 재개됩니다.

Master key rotation 중에 서버 장애가 발생하면, InnoDB는 서버 재시작 시 해당 연산을 계속 진행합니다.

키링 컴포넌트 또는 플러그인은 스토리지 엔진 초기화 이전에 로드되어야 합니다. 그래야 InnoDB 초기화 및 복구 작업이 테이블스페이스 데이터에 액세스하기 전에 테이블스페이스 헤더에서 테이블스페이스 데이터 페이지를 복호화하는 데 필요한 정보를 가져올 수 있습니다. (자세한 내용은 Encryption Prerequisites를 참조하십시오.)

InnoDB 초기화 및 복구가 시작되면, master key rotation 연산이 재개됩니다. 서버 장애로 인해 일부 테이블스페이스 키는 이미 새로운 master encryption key를 사용하여 암호화되어 있을 수 있습니다. InnoDB는 각 테이블스페이스 헤더에서 암호화 데이터를 읽고, 해당 데이터가 테이블스페이스 키가 기존 master encryption key로 암호화되었음을 나타내면, 키링에서 기존 키를 가져와 테이블스페이스 키를 복호화합니다. 그런 다음 InnoDB는 새로운 master encryption key를 사용하여 테이블스페이스 키를 다시 암호화하고, 재암호화된 테이블스페이스 키를 테이블스페이스 헤더에 다시 저장합니다.

Exporting Encrypted Tablespaces

테이블스페이스 export는 file-per-table 테이블스페이스에 대해서만 지원됩니다.

암호화된 테이블스페이스가 export될 때, InnoDB는 테이블스페이스 키를 암호화하는 데 사용되는 _transfer key_를 생성합니다. 암호화된 테이블스페이스 키와 transfer key는 tablespace_name.cfp 파일에 저장됩니다. 이 파일과 암호화된 테이블스페이스 파일이 import 연산을 수행하는 데 필요합니다. Import 시, InnoDB는 transfer key를 사용하여 tablespace_name.cfp 파일의 테이블스페이스 키를 복호화합니다. 관련 정보는 Section 17.6.1.3, “Importing InnoDB Tables”를 참조하십시오.

Encryption and Replication

ALTER INSTANCE ROTATE INNODB MASTER KEY 문은 소스와 레플리카가 모두 테이블스페이스 암호화를 지원하는 MySQL 버전을 실행하는 복제 환경에서만 지원됩니다.
성공한 ALTER INSTANCE ROTATE INNODB MASTER KEY 문은 레플리카에서 복제되도록 바이너리 로그에 기록됩니다.
ALTER INSTANCE ROTATE INNODB MASTER KEY 문이 실패한 경우, 바이너리 로그에 기록되지 않으며 레플리카에서 복제되지 않습니다.
ALTER INSTANCE ROTATE INNODB MASTER KEY 연산의 복제는 소스에 키링 컴포넌트 또는 플러그인이 설치되어 있지만 레플리카에는 설치되어 있지 않은 경우 실패합니다.

Identifying Encrypted Tablespaces and Schemas

Information Schema INNODB_TABLESPACES 테이블에는 암호화된 테이블스페이스를 식별하는 데 사용할 수 있는 ENCRYPTION 컬럼이 포함되어 있습니다.

1mysql> SELECT SPACE, NAME, SPACE_TYPE, ENCRYPTION FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
2       WHERE ENCRYPTION='Y'\G
3*************************** 1. row ***************************
4     SPACE: 4294967294
5      NAME: mysql
6SPACE_TYPE: General
7ENCRYPTION: Y
8*************************** 2. row ***************************
9     SPACE: 2
10      NAME: test/t1
11SPACE_TYPE: Single
12ENCRYPTION: Y
13*************************** 3. row ***************************
14     SPACE: 3
15      NAME: ts1
16SPACE_TYPE: General
17ENCRYPTION: Y

CREATE TABLE 또는 ALTER TABLE 문에서 ENCRYPTION 옵션이 지정되면, INFORMATION_SCHEMA.TABLES의 CREATE_OPTIONS 컬럼에 기록됩니다. 이 컬럼을 쿼리하여 암호화된 file-per-table 테이블스페이스에 존재하는 테이블을 식별할 수 있습니다.

1mysql> SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES
2       WHERE CREATE_OPTIONS LIKE '%ENCRYPTION%';
3+--------------+------------+----------------+
4| TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS |
5+--------------+------------+----------------+
6| test         | t1         | ENCRYPTION="Y" |
7+--------------+------------+----------------+

Information Schema의 INNODB_TABLESPACES 테이블을 쿼리하여 특정 스키마와 테이블에 연결된 테이블스페이스에 대한 정보를 가져올 수 있습니다.

1mysql> SELECT SPACE, NAME, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME='test/t1';
2+-------+---------+------------+
3| SPACE | NAME    | SPACE_TYPE |
4+-------+---------+------------+
5|     3 | test/t1 | Single     |
6+-------+---------+------------+

Information Schema SCHEMATA 테이블을 쿼리하여 암호화가 활성화된 스키마를 식별할 수 있습니다.

1mysql> SELECT SCHEMA_NAME, DEFAULT_ENCRYPTION FROM INFORMATION_SCHEMA.SCHEMATA
2       WHERE DEFAULT_ENCRYPTION='YES';
3+-------------+--------------------+
4| SCHEMA_NAME | DEFAULT_ENCRYPTION |
5+-------------+--------------------+
6| test        | YES                |
7+-------------+--------------------+

SHOW CREATE SCHEMA 또한 DEFAULT ENCRYPTION 절을 보여 줍니다.

Monitoring Encryption Progress

General 테이블스페이스와 mysql 시스템 테이블스페이스의 암호화 진행 상황은 Performance Schema를 사용하여 모니터링할 수 있습니다.

stage/innodb/alter tablespace (encryption) stage 이벤트 인스트루먼트는 general 테이블스페이스 암호화 연산에 대해 WORK_ESTIMATED와 WORK_COMPLETED 정보를 보고합니다.

다음 예제는 general 테이블스페이스 또는 mysql 시스템 테이블스페이스 암호화 진행 상황을 모니터링하기 위해 stage/innodb/alter tablespace (encryption) stage 이벤트 인스트루먼트와 관련 consumer 테이블을 활성화하는 방법을 보여 줍니다. Performance Schema stage 이벤트 인스트루먼트와 관련 consumer에 대한 자세한 내용은 Section 29.12.5, “Performance Schema Stage Event Tables”를 참조하십시오.

stage/innodb/alter tablespace (encryption) 인스트루먼트를 활성화합니다:

1mysql> USE performance_schema;
2mysql> UPDATE setup_instruments SET ENABLED = 'YES'
3          WHERE NAME LIKE 'stage/innodb/alter tablespace (encryption)';

Stage 이벤트 consumer 테이블을 활성화합니다. 여기에는 events_stages_current, events_stages_history, [events_stages_history_long](https://dev.mysql.com/doc/refman/9.5/en/performance-schema-events-stages-history-long-table.html "29.12.5.3 The events_stages_history_long Table)가 포함됩니다.

1mysql> UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%stages%';

테이블스페이스 암호화 연산을 실행합니다. 이 예제에서는 ts1이라는 general 테이블스페이스가 암호화됩니다.

1mysql> ALTER TABLESPACE ts1 ENCRYPTION = 'Y';

Performance Schema events_stages_current 테이블을 쿼리하여 암호화 연산의 진행 상황을 확인합니다. WORK_ESTIMATED는 테이블스페이스의 전체 페이지 수를 보고하고, WORK_COMPLETED는 처리된 페이지 수를 보고합니다.

1mysql> SELECT EVENT_NAME, WORK_ESTIMATED, WORK_COMPLETED FROM events_stages_current;
2+--------------------------------------------+----------------+----------------+
3| EVENT_NAME                                 | WORK_COMPLETED | WORK_ESTIMATED |
4+--------------------------------------------+----------------+----------------+
5| stage/innodb/alter tablespace (encryption) |           1056 |           1407 |
6+--------------------------------------------+----------------+----------------+

암호화 연산이 완료되면
[`events_stages_current`](https://dev.mysql.com/doc/refman/9.5/en/performance-schema-events-stages-current-table.html "29.12.5.1 The events_stages_current Table") 테이블은 빈 결과
집합을 반환합니다. 이 경우 완료된 연산의 이벤트 데이터를
확인하기 위해
[`events_stages_history`](https://dev.mysql.com/doc/refman/9.5/en/performance-schema-events-stages-history-table.html "29.12.5.2 The events_stages_history Table") 테이블을 확인할 수
있습니다. 예를 들면 다음과 같습니다:

1mysql> SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM events_stages_history;
2+--------------------------------------------+----------------+----------------+
3| EVENT_NAME                                 | WORK_COMPLETED | WORK_ESTIMATED |
4+--------------------------------------------+----------------+----------------+
5| stage/innodb/alter tablespace (encryption) |           1407 |           1407 |
6+--------------------------------------------+----------------+----------------+

Encryption Usage Notes

ENCRYPTION 옵션을 사용하여 기존 file-per-table 테이블스페이스를 변경할 때는 충분히 계획을 세우십시오. File-per-table 테이블스페이스에 존재하는 테이블은 COPY 알고리즘을 사용해 리빌드됩니다. General 테이블스페이스 또는 mysql 시스템 테이블스페이스의 ENCRYPTION 속성을 변경할 때는 INPLACE 알고리즘이 사용됩니다. INPLACE 알고리즘은 general 테이블스페이스에 존재하는 테이블에 대한 동시 DML을 허용합니다. 동시 DDL은 블록됩니다.
General 테이블스페이스 또는 mysql 시스템 테이블스페이스가 암호화된 경우, 해당 테이블스페이스에 존재하는 모든 테이블은 암호화됩니다. 마찬가지로, 암호화된 테이블스페이스에 생성된 테이블은 암호화됩니다.
서버가 정상 운영 중에 종료되거나 중지된 경우, 이전에 설정했던 동일한 암호화 설정으로 서버를 재시작하는 것이 권장됩니다.
첫 번째 master encryption key는 첫 번째 새 테이블스페이스 또는 기존 테이블스페이스가 암호화될 때 생성됩니다.
Master key rotation은 테이블스페이스 키를 재암호화하지만 테이블스페이스 키 자체를 변경하지는 않습니다. 테이블스페이스 키를 변경하려면 암호화를 비활성화한 후 다시 활성화해야 합니다. File-per-table 테이블스페이스의 경우, 테이블스페이스를 다시 암호화하는 것은 테이블을 리빌드하는 ALGORITHM=COPY 연산입니다. General 테이블스페이스와 mysql 시스템 테이블스페이스의 경우, 테이블스페이스에 존재하는 테이블을 리빌드할 필요가 없는 ALGORITHM=INPLACE 연산입니다.
테이블을 COMPRESSION 옵션과 ENCRYPTION 옵션을 모두 사용하여 생성하는 경우, 테이블스페이스 데이터가 암호화되기 전에 압축이 수행됩니다.
component_keyring_file 또는 component_keyring_encrypted_file 컴포넌트를 언인스톨해도 기존 키링 데이터 파일은 제거되지 않습니다.
키링 데이터 파일을 테이블스페이스 데이터 파일과 동일한 디렉토리 아래에 두지 않는 것이 권장됩니다.
암호화는 InnoDB가 FULLTEXT 인덱스를 추가할 때 암묵적으로 생성되는 FULLTEXT 인덱스 테이블에 대해 지원됩니다. 관련 정보는 InnoDB Full-Text Index Tables를 참조하십시오.

Encryption Limitations

Advanced Encryption Standard (AES)는 지원되는 유일한 암호화 알고리즘입니다. InnoDB 테이블스페이스 암호화는 테이블스페이스 키 암호화에 Electronic Codebook (ECB) 블록 암호화 모드를 사용하고, 데이터 암호화에 Cipher Block Chaining (CBC) 블록 암호화 모드를 사용합니다. CBC 블록 암호화 모드에서는 패딩을 사용하지 않습니다. 대신 InnoDB는 암호화할 텍스트가 블록 크기의 배수가 되도록 합니다.
암호화는 file-per-table 테이블스페이스, general 테이블스페이스, mysql 시스템 테이블스페이스에 대해서만 지원됩니다. 암호화는 InnoDB system tablespace를 포함한 다른 테이블스페이스 타입에 대해서는 지원되지 않습니다.
암호화된 file-per-table 테이블스페이스, general 테이블스페이스, 또는 mysql 시스템 테이블스페이스에서 암호화를 지원하지 않는 테이블스페이스 타입으로 테이블을 이동하거나 복사할 수 없습니다.
암호화된 테이블스페이스에서 암호화되지 않은 테이블스페이스로 테이블을 이동하거나 복사할 수 없습니다. 그러나 암호화되지 않은 테이블스페이스에서 암호화된 테이블스페이스로 테이블을 이동하는 것은 허용됩니다. 예를 들어, 암호화되지 않은 file-per-table 또는 general 테이블스페이스에서 암호화된 general 테이블스페이스로 테이블을 이동하거나 복사할 수 있습니다.
기본적으로 테이블스페이스 암호화는 테이블스페이스 내 데이터에만 적용됩니다. Redo 로그와 undo 로그 데이터는 innodb_redo_log_encrypt와 innodb_undo_log_encrypt를 활성화하여 암호화할 수 있습니다. Redo Log Encryption과 Undo Log Encryption을 참고하십시오. 바이너리 로그 파일과 릴레이 로그 파일 암호화에 대한 정보는 Section 19.3.2, “Encrypting Binary Log Files and Relay Log Files”를 참조하십시오.
암호화된 테이블스페이스에 존재하거나 과거에 존재했던 테이블의 스토리지 엔진을 변경하는 것은 허용되지 않습니다.