## About Data-at-Rest Encryption 

•About Data-at-Rest Encryption 

•Encryption Prerequisites 

•Defining an Encryption Default for Schemas and General Tablespaces 

•File-Per-Table Tablespace Encryption 

•General Tablespace Encryption 

•Doublewrite File Encryption 

•mysql System Tablespace Encryption 

•Redo Log Encryption 

•Undo Log Encryption 

•Master Key Rotation 

•Encryption and Recovery 

•Exporting Encrypted Tablespaces 

•Encryption and Replication 

•Identifying Encrypted Tablespaces and Schemas 

•Monitoring Encryption Progress 

•Encryption Usage Notes 

•Encryption Limitations 

InnoDB  uses a two tier encryption key architecture, consisting of a master encryption key and tablespace keys. When a tablespace is encrypted, a tablespace key is encrypted and stored in the tablespace header. When an application or authenticated user wants to access encrypted tablespace data, InnoDB  uses a master encryption key to decrypt the tablespace key. The decrypted version of a tablespace key never changes, but the master encryption key can be changed as required. This action is referred to as master key rotation . 

The data-at-rest encryption feature relies on a keyring component or plugin for master encryption key management. 

All MySQL editions provide a component_keyring_file  component and keyring_file  plugin, each of which stores keyring data in a file local to the server host. 

MySQL Enterprise Edition offers additional keyring components and plugins: 

• component_keyring_encrypted_file : Stores keyring data in an encrypted, password-protected file local to the server host. 

• keyring_encrypted_file : Stores keyring data in an encrypted, password-protected file local to the server host. 

• keyring_okv : A KMIP 1.1 plugin for use with KMIP-compatible back end keyring storage products. Supported KMIP-compatible products include centralized key management solutions such as Oracle Key Vault, Gemalto KeySecure, Thales Vormetric key management server, and Fornetix Key Orchestration. 

