MariaDB Server can encrypt the server's binary logs and relay logs. This ensures that your binary logs are only accessible through MariaDB.

Basic Configuration

Since , MariaDB can also encrypt binary logs (including relay logs). Encryption of binary logs is configured by the encrypt_binlog system variable.

Users of data-at-rest encryption will also need to have a key management and encryption plugin configured. Some examples are the File Key Management Plugin and AWS Key Management Plugin.

Encryption Keys

support . Each encryption key can be defined with a different 32-bit integer as a key identifier.

MariaDB uses the encryption key with ID 1 to encrypt .

Key Rotation

Some allow you to automatically rotate and version your encryption keys. If a plugin supports key rotation, and if it rotates the encryption keys, then InnoDB's can re-encrypt InnoDB pages that use the old key version with the new key version. However, the binary log does not have a similar mechanism, which means that existing binary logs remain encrypted with the older key version, but new binary logs will be encrypted with the new key version. For more information, see .

In order for key rotation to work, both the backend key management service (KMS) and the corresponding have to support key rotation. See to determine which plugins currently support key rotation.

Enabling Encryption

Encryption of binary logs can be enabled by following the process:

• First, stop the server.

• Then, set in the MariaDB configuration file.

• Then, start the server.

From that point forward, any new will be encrypted. To delete old unencrypted , you can use or .

Disabling Encryption

Encryption of can be disabled by following the process:

• First, stop the server.

• Then, set in the MariaDB configuration file.

• Then, start the server.

From that point forward, any new will be unencrypted. If you would like the server to continue to have access to old encrypted , then make sure to keep your loaded.

Understanding Binlog Encryption

When starting with binary log encryption, MariaDB Server logs a Format_descriptor_log_event and a START_ENCRYPTION_EVENT, then encrypts all subsequent events for the binary log.

Each event's header and footer are created and processed to produce encrypted blocks. These encrypted blocks are produced before transactions are committed and before the events are flushed to the binary log. As such, they exist in an encrypted state in memory buffers and in the IO_CACHE files for user connections.

Effects of Data-at-Rest Encryption on Replication

When using encrypted binary logs with , it is completely supported to have different encryption keys on the master and slave. The master decrypts encrypted binary log events as it reads them from disk, and before its sends them to the slave, so the slave actually receives the unencrypted binary log events.

If you want to ensure that binary log events are encrypted as they are transmitted between the master and slave, then you will have to use .

Effects of Data-at-Rest Encryption on mariadb-binlog

does not currently have the ability to decrypt encrypted on its own (see about that). In order to use mariadb-binlog with encrypted , you have to use the command-line option, so that the server can decrypt the for mariadb-binlog.

Note, using the --read-from-remote-server option on versions of the mariadb-binlog utility that do not have the fix (<=, , ) can corrupt binlog positions when the binary log is encrypted.

_{This page is licensed: CC BY-SA / Gnu FDL}

Nearly everyone owns data of immense value: customer data, construction plans, recipes, product designs and other information. These data are stored in clear text on your storage media. Everyone with file system access is able to read and modify the data. If this data falls into the wrong hands (criminals or competitors) this may result in serious consequences.

With encryption you protect Data At Rest (see the Wikipedia article). That way, the database files are protected against unauthorized access.

When Does Encryption Help to Protect Your Data?

Encryption helps in case of threats against the database files:

• An attacker gains access to the system and copies the database files to avoid the MariaDB authorization check.

• MariaDB is operated by a service provider who should not gain access to the sensitive data.

When is Encryption No Help?

Encryption provides no additional protection against threats caused by authorized database users. Specifically, SQL injections aren’t prevented.

What to Encrypt?

All data that is not supposed to fall into possible attackers hands should be encrypted. Especially information, subject to strict data protection regulations, is to be protected by encryption (e.g. in the healthcare sector: patient records). Additionally, data being of interest for criminals should be protected. Data which should be encrypted are:

• Personal related information

• Customer details

• Financial and credit card data

• Public authorities' data

How to Handle Key Management?

There are currently three options for key management:

See for details.

_{This page is licensed: CC BY-SA / Gnu FDL}

As with other storage engines that support data-at-rest encryption, Aria relies on an Encryption Key Management plugin to handle its encryption keys. Where the support is available, Aria can use multiple keys.

Encryption Keys

MariaDB keeps track of each encryption key internally using a 32-bit integer, which serves as the key identifier. Unlike InnoDB, Aria does not support the ENCRYPTION_KEY_ID table option (for more information, see MDEV-18049), which allows the user to specify the encryption key to use. Instead, Aria defaults to specific encryption keys provided by the Encryption Key Management plugin.

• When working with user-created tables, Aria encrypts them to disk using the ID 1 key.

• When working with internal temporary tables written to disk, Aria encrypts them to disk using the ID 2 key, unless there is no ID 2 key, then it falls back on the ID 1 key.

Key Rotation

Some allow you to automatically rotate and version your encryption keys. If a plugin support key rotation, and if it rotates the encryption keys, then InnoDB's can re-encrypt InnoDB pages that use the old key version with the new key version. However, Aria does not have a similar mechanism, which means that the tables remain encrypted with the older key version. For more information, see .

In order for key rotation to work, both the backend key management service (KMS) and the corresponding have to support key rotation. See to determine which plugins currently support key rotation.

_{This page is licensed: CC BY-SA / Gnu FDL}

Once all data and logs have been decrypted, you can safely remove key management plugins, if desired. For example, if using the file key management plugin:

Comment out or remove the following lines 
plugin_load_add = file_key_management 
file_key_management_filename = /etc/mysql/encryption/keyfile

Restart the server after editing the configuration.

• Ensure that all tables no longer report encryption in CREATE_OPTIONS.

• Confirm that redo logs and binary logs are unencrypted by checking server variables and log headers.

• Confirm that no key management plugin is loaded:

In order to enable data-at-rest encryption for tables using the storage engine, you first need to configure the server to use an plugin. Once this is done, you can enable encryption by setting the relevant system variables.

Encrypting User-created Tables

With tables that the user creates, you can enable encryption by setting the system variable to ON, then restart the Server. Once this is set, Aria automatically enables encryption on all tables you create after with the table option set to PAGE.

Currently, Aria does not support encryption on tables where the

The process involved in safely disabling data-at-rest encryption for your Aria tables is very similar to that of enabling encryption. To disable, you need to set the relevant system variables and then rebuild each table into an unencrypted state.

Don't remove the Encryption Key Management plugin from your configuration file until you have unencrypted all tables in your database. MariaDB cannot read encrypted tables without the relevant encryption key.

Disabling Encryption on User-Created Tables

For user-created tables, you can disable encryption by setting the aria_encrypt_tables system variable to OFF. Once this is set, MariaDB no longer encrypts new tables created with the Aria storage engine.

To find the encrypted tables, query the Information Schema, filtering the table for those that use the Aria storage engine and the PAGE .

Each table in that result set was written to disk in an encrypted state.

To remove the encryption of those tables,

• Set the aria_encrypt_tables variable to OFF;

• Leave the configuration for the encryption keys in place (otherwise, you cannot decrypt tables!);

• Run the following statement for each encrypted table.

Once all of the Aria tables are rebuilt, they're unencrypted.

Optionally, you can remove the configuration for the encryption keys now.

Disabling Encryption for Internal On-Disk Temporary Tables

MariaDB routinely creates internal temporary tables. When these temporary tables are written to disk and the system variable is set to ON, MariaDB uses the Aria storage engine.

To decrypt these tables, set the to OFF. Once set, all internal temporary tables that are created from that point on are written unencrypted to disk.

_{This page is licensed: CC BY-SA / Gnu FDL}

This page covers how to confirm that binlogs are encrypted, recommended approaches for getting decrypted output.

When binary log encryption is enabled, the server writes binlog files to disk in encrypted form. This ensures that anyone with direct access to the filesystem cannot read the contents.

The encryption keys are managed through a keyring or key-management plugin. Whenever the server itself needs to access a binlog—such as during replication, recovery, or when tools like mysqlbinlog connect to it—the server transparently decrypts the events using the appropriate active keys.

Since the keys are stored in a server-accessible keyring, the most reliable and secure method to access decrypted binlog data is to request it directly from the running server. In other words, instead of trying to decrypt raw encrypted files offline, you should allow the server to stream already-decrypted events to you.

Approaches to decrypt binary logs

There are two common approaches depending on where you run the decryption and how keys are stored:

1. Run mysqlbinlog on a server that already has access to the key material (recommended).

   • The server's key provider configuration (for example, a mounted key file or KMS credentials) is already present, so mysqlbinlog inherits the ability to open and decrypt logs.

   • This reduces key distribution since the keys remain on the server.

Using mysqlbinlog to decrypt

mysqlbinlog will attempt to decrypt binary logs when launched in an environment that allows it to access the same key provider configuration used by the server.

Basic example (server with key access):

If the environment is correctly configured, mysqlbinlog will read, decrypt, and write the plaintext SQL (events) to decrypted.sql.

Decrypting compressed or rotated logs

If your environment compresses or rotates binary logs outside the standard server rotation, decompress the file before passing to mysqlbinlog (or use process substitution):

Decrypt local binlog to file:

Decrypt and decode row events verbosely:

Decrypt from a compressed backup:

When data-at-rest encryption is enabled in MariaDB Enterprise Server, InnoDB can encrypt redo logs. If you later disable encryption or need to recover data from encrypted redo logs, you may need to decrypt the redo log files before MariaDB can process them.

1. Stop MariaDB Enterprise Server

2. Locate the redo log files By default, InnoDB redo log files are stored in the data directory, typically as:

   or in the #innodb_redo directory for MariaDB versions using the new redo log format.

3. Prepare configuration for decryption

   • Make sure innodb_redo_log_encrypt is set to ON (to ensure the redo logs are recognized as encrypted).

   • Ensure that the key management plugin (such as file_key_management or aws_key_management) is configured exactly as it was when the redo logs were created.

4. Start MariaDB with decryption enabled

   • Start the server normally. MariaDB will automatically attempt to decrypt redo logs at startup using the configured key management plugin.

   • If successful, the redo logs are decrypted on-the-fly and crash recovery proceeds.

5. Disable redo log encryption if no longer required After recovery or once you confirm that decrypted redo logs are no longer needed, you can disable redo log encryption in the configuration:

   Then restart the server. New redo logs will be created in plaintext.

Verification

You can verify the redo log encryption status with:

Example output:

In certain situations, you may need to turn off data-at-rest encryption in a standalone or single-node MariaDB Enterprise Server deployment. For instance, you might have originally enabled encryption using a key management plugin, but later determine that encryption is no longer necessary.

This page explains how to safely disable data-at-rest encryption on a single server. The steps assume that your server already contains encrypted tables or logs, and that your goal is to revert the system to an unencrypted state without losing any data.

Prerequisites

Before you can disable data-at-rest encryption in MariaDB Enterprise Server, ensure the following:

• MariaDB Enterprise Server with Encryption Enabled The server must currently be running with data-at-rest encryption enabled.

• Key Management Access You must have access to the same key management plugin and configuration that were originally used to encrypt the data.

• Sufficient Disk Space Make sure adequate free disk space is available to decrypt and rewrite all affected data files.

Related Documentation

MariaDB supports data-at-rest encryption for tables using the InnoDB storage engines. When enabled, the server encrypts data when it writes it to and decrypts data when it reads it from the file system. You can configure InnoDB encryption to automatically have all new InnoDB tables automatically encrypted, or specify encrypt per table.

For encrypting data with the Aria storage engine, see Encrypting Data for Aria.

InnoDB Encryption and Decryption Behavior

When data-at-rest encryption is enabled for InnoDB, encryption and decryption occur at specific points during disk I/O operations.

When is InnoDB data encrypted?

When InnoDB pages are written to disk, they are automatically encrypted.

When is InnoDB data decrypted?

InnoDB pages are decrypted before they are read from disk and stored in the InnoDB buffer pool. A page remains decrypted in memory while it is in the buffer pool. As a result, decrypted memory pages may include data from rows, columns, or even tables that the current query does not directly access.

Basic Configuration

Using data-at-rest encryption requires that you first configure an plugin, such as the or plugins. MariaDB uses this plugin to store, retrieve and manage the various keys it uses when encrypting data to and decrypting data from the file system.

Once you have the plugin configured, you need to set a few additional system variables to enable encryption on InnoDB tables, including , , , and .

For more information on system variables for encryption and other features, see the InnoDB page.

Creating Encrypted Tables

To create encrypted tables, specify the table options ENCRYPTED=YES and ENCRYPTION_KEY_ID= with a corresponding key id;

Finding Encrypted Tables

When using data-at-rest encryption with the InnoDB storage engine, it is not necessary that you encrypt every table in your database. You can check which tables are encrypted and which are not by querying the table in the . This table provides information on which tablespaces are encrypted, which encryption key each tablespace is encrypted with, and whether the background encryption threads are currently working on the tablespace. Since the can also contain tables, it can be helpful to join the INNODB_TABLESPACES_ENCRYPTION table with the table to find out the encryption status of each specific table, rather than each tablespace. For example:

Redo Logs

Using data-at-rest encryption with InnoDB, the system variable only encrypts the InnoDB tablespaces. In order to also encrypt the InnoDB Redo Logs, you also need to set the system variable.

Where the encryption key management plugin supports key rotation, the InnoDB Redo Log can also rotate encryption keys. In previous releases, the Redo Log can only use the first encryption key.

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}

InnoDB performs some encryption and decryption operations with background encryption threads. The innodb_encryption_threads system variable controls the number of threads that the storage engine uses for encryption-related background operations, including encrypting and decrypting pages after key rotations or configuration changes, and scrubbing data to permanently delete it.

Background Operations

InnoDB performs the following encryption and decryption operations using background encryption threads:

• When rotating encryption keys, InnoDB's background encryption threads re-encrypt pages that use key versions older than to the new key version.

• When changing the system variable to FORCE, InnoDB's background encryption threads encrypt the tablespace and any tablespaces that have the table option set to DEFAULT.

• When changing the system variable to OFF, InnoDB's background encryption threads decrypt the tablespace and any tablespacs that have the ENCRYPTED table option set to DEFAULT.

The system variable can be used to configure how many I/O operations you want to allow for the operations performed by InnoDB's background encryption threads.

Whenever you change the value on the system variable, InnoDB's background encryption threads perform the necessary encryption or decryption operations. Because of this, you must have a non-zero value set for the system variable. InnoDB also considers these operations to be key rotations internally. Because of this, you must have a non-zero value set for the system variable. For more information, see .

Non-Background Operations

InnoDB performs the following encryption and decryption operations without using background encryption threads:

• When a tablespaces and using to manually set the table option to YES, InnoDB does not use background threads to encrypt the tablespaces.

• Similarly, when using file-per-table tablespaces and using to manually set the table option to NO, InnoDB does not use background threads to decrypt the tablespaces.

In these cases, InnoDB performs the encryption or decryption operation using the server thread for the client connection that executes the statement. This means that you can update encryption on tablespaces with an statement, even when the and/or the system variables are set to 0.

InnoDB does not permit manual encryption changes to tables in the tablespace using . Encryption of the tablespace can only be configured by setting the value of the system variable. This means that when you want to encrypt or decrypt the tablespace, you must also set a non-zero value for the system variable, and you must also set the system variable to 1 to ensure that the system tablespace is properly encrypted or decrypted by the background threads. See for more information.

Checking the Status of Background Operations

InnoDB records the status of background encryption operations in the table in the database.

For example, to see which InnoDB tablespaces are currently being decrypted or encrypted on by background encryption, you can check which InnoDB tablespaces have the ROTATING_OR_FLUSHING column set to 1:

And to see how many InnoDB tablespaces are currently being decrypted or encrypted by background encryption threads, you can call the aggregate function.

And to see how many InnoDB tablespaces are currently being decrypted or encrypted by background encryption threads, while comparing that to the total number of InnoDB tablespaces and the total number of encrypted InnoDB tablespaces, you can join the table with the table in the database:

_{This page is licensed: CC BY-SA / Gnu FDL}

MariaDB's data-at-rest encryption requires the use of a key management and encryption plugin. These plugins are responsible both for the management of encryption keys and for the actual encryption and decryption of data.

MariaDB supports the use of multiple encryption keys. Each encryption key uses a 32-bit integer as a key identifier. If the specific plugin supports key rotation, then encryption keys can also be rotated, which creates a new version of the encryption key.

Supported Key Management Plugins list

Choosing an Encryption Key Management Solution

How MariaDB manages encryption keys depends on which encryption key management solution you choose. Currently, MariaDB has three options:

File Key Management Plugin

The File Key Management plugin that ships with MariaDB is a basic key management and encryption plugin that reads keys from a plain-text file. It can also serve as an example and as a starting point when developing a key management plugin.

For more information, see .

Hashicorp Key Management Plugin

Integrates MariaDB encryption with Vault for secure key management.

For more information, refer to the .

AWS Key Management Plugin

The AWS Key Management plugin is a key management and encryption plugin that uses the Amazon Web Services (AWS) Key Management Service (KMS). The AWS Key Management plugin depends on the , which uses the . The license is not compatible with MariaDB Server's , so we are not able to distribute packages that contain the AWS Key Management plugin. Therefore, the only way to currently obtain the plugin is to install it from the source.

For more information, see .

Using Multiple Encryption Keys

Key management and encryption plugins support using multiple encryption keys. Each encryption key can be defined with a different 32-bit integer as a key identifier.

The support for multiple keys opens up some potential use cases. For example, let's say that a hypothetical key management and encryption plugin is configured to provide two encryption keys. One encryption key might be intended for "low security" tables. It could use short keys, which might not be rotated, and data could be encrypted with a fast encryption algorithm. Another encryption key might be intended for "high security" tables. It could use long keys, which are rotated often, and data could be encrypted with a slower but more secure encryption algorithm. The user would specify the identifier of the key that they want to use for different tables, only using high-level security where it's needed.

There are two encryption key identifiers that have special meanings in MariaDB. An encryption key 1 is intended for encrypting system data, such as InnoDB redo logs, binary logs, and so on. It must always exist when is enabled. An encryption key 2 is intended for encrypting temporary data, such as temporary files and temporary tables. It is optional. If it doesn't exist, then MariaDB uses an encryption key 1 for these purposes instead.

When , the key that is used to encrypt tables .

When , the key that is used to encrypt tables .

Key Rotation

Encryption key rotation is optional in MariaDB Server. Key rotation is only supported if the backend key management service (KMS) supports key rotation and if the corresponding key management and encryption plugin for MariaDB also supports key rotation. When a key management and encryption plugin supports key rotation, users can opt to rotate one or more encryption keys, which creates a new version of each rotated encryption key.

Key rotation allows users to improve data security in the following ways:

• If the server is configured to automatically re-encrypt table data with the newer version of the encryption key after the key is rotated, then that prevents an encryption key from being used for long periods of time.

• If the server is configured to simultaneously encrypt table data with multiple versions of the encryption key after the key is rotated, then that prevents all data from being leaked if a single encryption key version is compromised.

The has that can .

The does .

Support for Key Rotation in Encryption Plugins

Encryption Plugins with Key Rotation Support

• The supports encryption key rotation, and the corresponding also supports encryption key rotation.

• HashiCorp Key Management Plugin: The HashiCorp Key Management Plugin integrates MariaDB with for centralized encryption key storage and lifecycle management. environments.

Encryption Plugins without Key Rotation Support

• The does not support encryption key rotation because it does not use a backend key management service (KMS).

Encryption Plugin API

New key management and encryption plugins can be developed using the .

_{This page is licensed: CC BY-SA / Gnu FDL}

Wrong Create Options

With InnoDB tables using encryption, there are several cases where a or statement can throw Error 1005, due to the InnoDB error 140, Wrong create options. For instance,

When this occurs, you can usually get more information about the cause of the error by following it with a statement.

This error is known to occur in the following cases:

InnoDB uses encryption key management plugins to support the use of multiple encryption keys.

Encryption Keys

Each encryption key has a 32-bit integer that serves as a key identifier.

The default key is set using the innodb_default_encryption_key_id system variable.

Encryption keys can also be specified with the ENCRYPTION_KEY_ID table option for tables that use file-per-table tablespaces.

InnoDB encrypts the temporary tablespace using the encryption key with the ID 1.

InnoDB encrypts the using the encryption key with the ID 1.

Keys with Manually Encrypted Tablespaces

With tables that use enabled encryption, one way to set the specific encryption key for the table is to use the table option. For example:

If the table option is not set for a table that uses enabled encryption, then it will inherit the value from the system variable. For example:

Keys with Automatically Encrypted Tablespaces

With tables that use enabled encryption, one way to set the specific encryption key for the table is to use the system variable. For example:

InnoDB tables that are part of the tablespace can only be encrypted using the encryption key set by the system variable.

If the table is in a tablespace, and if is set to ON or FORCE, and if is set to a value greater than 0, then you can also set the specific encryption key for the table by using the table option. For example:

However, if is set to OFF or if is set to 0, then this will not work. See for more information.

Key Rotation

Some allow you to automatically rotate and version your encryption keys. If a plugin support key rotation, and if it rotates the encryption keys, then InnoDB's can re-encrypt InnoDB pages that use the old key version with the new key version.

You can set the maximum age for an encryption key using the system variable. When this variable is set to a non-zero value, background encryption threads constantly check pages to determine if any page is encrypted with a key version that's too old. When the key version is too old, any page encrypted with the older version of the key is automatically re-encrypted in the background to use a more current version of the key. Bear in mind, this constant checking can sometimes result in high CPU usage.

Key rotation for the InnoDB is only supported in and later. For more information, see .

In order for key rotation to work, both the backend key management service (KMS) and the corresponding have to support key rotation. See to determine which plugins currently support key rotation.

Disabling Background Key Rotation Operations

In the event that you encounter issues with background key encryption, you can disable it by setting the system variable to 0. You may find this useful when the constant key version checks lead to excessive CPU usage. It's also useful in cases where your encryption key management plugin does not support key rotation, (such as with the plugin). For more information, see .

There are, however, issues that can arise when the background key rotation is disabled.

Pending Encryption Operations

When updating the value on the system variable, InnoDB internally treats the subsequent to encrypt and decrypt tablespaces as background key rotations. See for more information.

You can check the status of background encryption operations by querying the table in the database.

See for some example queries.

For more information, see .

_{This page is licensed: CC BY-SA / Gnu FDL}

The Hashicorp Key Management Pugin is used to implement encryption using keys stored in the Hashicorp Vault KMS. For more information, see Hashicorp Vault and MariaDB, and for how to install Vault, see Install Vault, as well as MySQL/MariaDB Database Secrets Engine.

The current version of this plugin implements the following features:

• Authentication is done using the Hashicorp Vault's token authentication method.

• If additional client authentication is required, then the path to the CA authentication bundle file may be passed as a plugin parameter;

• The creation of the keys and their management is carried out using the Hashicorp Vault KMS and their tools.

• The plugin uses libcurl (https) as an interface to the HashiCorp Vault server;

• JSON parsing is performed through the JSON service (through the include/mysql/service_json.h);

• HashiCorp Vault 1.2.4 was used for development and testing.

• As of MariaDB 10.6.24, the plugin is configured to use cached keys for all communication errors, not just for timeouts. This ensures continuous operation when the Vault server is temporarily unreachable.

• As of MariaDB 10.6.24, the default setting for cache usage on error is ON.

Since we require support for key versioning, the key-value storage must be configured in Hashicorp Vault as a key-value storage that uses the interface of the second version. For example, you can create it as follows:

Key names must correspond to their numerical identifiers. Key identifiers itself, their possible values and rules of use are described in more detail in the MariaDB main documentation.

From the point of view of the key-value storage (in terms of Hashicorp Vault), the key is a secret containing one key-value pair with the name "data" and a value representing a binary string containing the key value, for example:

Keys values are strings containing binary data. MariaDB currently uses the AES algorithm with 256-bit keys as the default encryption method. In this case, the keys that will be stored in the Hashicorp Vault should be 32-byte strings. Most likely you will use some utilities for creating and administering keys designed to work with Hashicorp Vault. But in the simplest case, keys can be created from the command line through the vault utility, for example, as follows:

If you use default encryption (AES), you should ensure that the key length is 32 bytes, otherwise it may fail to use InnoDB as a data storage.

The plugin currently does not unseal Hashicorp Vault on its own, you must do this in advance and on your own.

To use Hashicorp Vault KMS, the plugin must be preloaded and activated on the server. Most of its parameters should not be changed during plugin operation and therefore must be preconfigured as part of the server configuration through configuration file or command line options:

Options

The plugin supports the following parameters, which must be set in advance and cannot be changed during server operation:

hashicorp-key-management-vault-url

• Description: HTTP[s] URL that is used to connect to the Hashicorp Vault server. It must include the name of the scheme (https:// for a secure connection) and, according to the API rules for storages of the key-value type in Hashicorp Vault, after the server address, the path must begin with the "/v1/" string (as prefix), for example: https://127.0.0.1:8200/v1/my_secrets. By default, the path is not set, therefore you must replace with the correct path to your secrets.

• Command line: --[loose-]hashicorp-key-management-vault-url="<url>"

hashicorp-key-management-token

• Description: Authentication token that passed to the Hashicorp Vault in the request header. By default, this parameter contains an empty string, so you must specify the correct value for it, otherwise the Hashicorp Vault server will refuse authorization. Alternatively, you can define an environment variable VAULT_TOKEN and store the token there.

• Command line: --[loose-]hashicorp-key-management-token="<token>"

hashicorp-key-management-vault-ca

• Description: Path to the Certificate Authority (CA) bundle (is a file that contains root and intermediate certificates). By default, this parameter contains an empty string, which means no CA bundle.

• Command line: --[loose-]hashicorp-key-management-vault-ca="<path>"

hashicorp-key-management-timeout

• Description: Set the duration (in seconds) for the Hashicorp Vault server connection timeout. The default value is 15 seconds. The allowed range is from 1 to 86400 seconds. The user can also specify a zero value, which means the default timeout value set by the libcurl library (currently 300 seconds).

• Command line: --[loose-]hashicorp-key-management-timeout=<timeout>

hashicorp-key-management-max-retries

• Description: Number of server request retries in case of timeout. Default is three retries.

• Command line: ----[loose-]hashicorp-key-management-max-retries=<retries>

hashicorp-key-management-caching-enabled

• Description: Enable key caching (storing key values received from the Hashicorp Vault server in the local memory). By default caching is enabled.

• Command line: --[loose-]hashicorp-key-management-caching-enabled="on"|"off"

hashicorp-key-management-use-cache-on-timeout

• Description: This parameter instructs the plugin to use the key values or version numbers taken from the cache in the event of a timeout when accessing the vault server. By default this option is disabled. Please note that key values or version numbers will be read from the cache when the timeout expires only after the number of attempts to read them from the storage server that specified by the parameter has been exhausted.

• Command line: --[loose-]hashicorp-key-management-use-cache-on-timeout="on"|"off"

hashicorp-key-management-cache-timeout

• Description: The time (in milliseconds) after which the value of the key stored in the cache becomes invalid and an attempt to read this data causes a new request send to the vault server. By default, cache entries become invalid after 60,000 milliseconds (after one minute). If the value of this parameter is zero, then the keys will always be considered invalid, but they still can be used if the vault server is unavailable and the corresponding cache operating mode (--[loose-]hashicorp-key-management-use-cache-on-timeout="on") is enabled.

• As of MariaDB 10.6.24, the default value is 1 year (specified in milliseconds).

• Command line: --[loose-]hashicorp-key-management-cache-timeout=<timeout>

hashicorp-key-management-cache-version-timeout

• Description: The time (in milliseconds) after which the information about latest version number of the key (which stored in the cache) becomes invalid and an attempt to read this information causes a new request send to the vault server. If the value of this parameter is zero, then information about latest key version numbers always considered invalid, unless there is no communication with the vault server and use of the cache is allowed when the server is unavailable. By default, this parameter is zero, that is, the latest version numbers for the keys stored in the cache are considered always invalid, except when the vault server is unavailable and use of the cache is allowed on server failures.

• Command line: --[loose-]hashicorp-key-management-cache-version-timeout=<timeout>

hashicorp-key-management-check-kv-version

• Description: This parameter enables ("on", this is the default value) or disables ("off") checking the kv storage version during plugin initialization. The plugin requires storage to be version 2 or older in order for it to work properly.

• Command line: --[loose-]hashicorp-key-management-check-kv-version="on"|"off"

Key Rotation and Cache Flushing

Available as of MariaDB 12.3

The HashiCorp Key Management plugin supports key versioning provided by the HashiCorp Vault Server. In previous versions, rotating keys required a server restart to clear the internal cache. As of MariaDB 12.3, you can flush the plugin cache manually while the server is running.

Flushing the Cache

To rotate keys, you must flush the cached keys using the FLUSH command. This clears the local cache, forcing the server to re-fetch the latest key versions from the HashiCorp Vault server upon the next access.

Executing this command requires the RELOAD privilege.

Verifying Key Versions

To view the current Key IDs and Key Versions stored in the latest version cache, you can query the Information Schema table or use the SHOW command.

See for table details.

Using the SHOW command:

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}

In order to enable data-at-rest encryption for tables using the InnoDB storage engines, you first need to configure the Server to use an Encryption Key Management plugin. Once this is done, you can enable encryption by setting the innodb_encrypt_tables system variable to encrypt the InnoDB system and file tablespaces and setting the innodb_encrypt_log system variable to encrypt the InnoDB Redo Log.

Setting these system variables enables the encryption feature for InnoDB tables on your server. To use the feature, you need to use the ENCRYPTION_KEY_ID table option to set what encryption key you want to use and set the ENCRYPTED table option to enable encryption.

When encrypting any InnoDB tables, the best practice is also enable encryption for the Redo Log. If you have encrypted InnoDB tables and have not encrypted the Redo Log, data written to an encrypted table may be found unencrypted in the Redo Log.

Enabling Encryption for Automatically Encrypted Tablespaces

The system variable controls the configuration of automatic encryption of InnoDB tables. It has the following possible values:

When is set to ON, InnoDB tables are automatically encrypted by default. For example, the following statements create an encrypted table and confirm that it is encrypted:

When is set to ON, an unencrypted InnoDB table can be created by setting the table option to NO for the table. For example, the following statements create an unencrypted table and confirm that it is not encrypted:

When is set to FORCE, InnoDB tables are automatically encrypted by default, and unencrypted InnoDB tables can not be created. In this scenario, if you set the table option to NO for a table, then you will encounter an error. For example:

When is set to ON or FORCE, then you must ensure that is set to a non-zero value, so that InnoDB can perform any necessary encryption operations in the background. See for more information about that. must also be set to a non-zero value for the initial encryption operations to happen in the background. See for more information about that.

Enabling Encryption for Manually Encrypted Tablespaces

If you do not want to automatically encrypt every InnoDB table, then it is possible to manually enable encryption for just the subset of InnoDB tables that you would like to encrypt. MariaDB provides the and table options that can be used to manually enable encryption for specific InnoDB tables. These table options can be used with and statements. These table options can only be used with InnoDB tables that have their own , meaning that tables that were created with set.

You can manually enable or disable encryption for a table by using the table option. If you only need to protect a subset of InnoDB tables with encryption, then it can be a good idea to manually encrypt each table that needs the extra protection, rather than encrypting all InnoDB tables globally with . This allows you to balance security with speed, as it means the encryption and decryption performance overhead only applies to those tables that require the additional security.

If a manually encrypted InnoDB table contains a , then the internal table for the full-text index will not also be manually encrypted. To encrypt internal tables for InnoDB full-text indexes, you must by setting to ON or FORCE.

You can also manually specify a for a table by using the table option. This allows you to use different encryption keys for different tables. For example, you might create a table using a statement like this:

If the table option is not specified, then the table will be encrypted with the key identified by the system variable. For example, you might create a table using a statement like this:

In the event that you have an existing table and you want to manually enable encryption for that table, then you can do the same with an statement. For example:

InnoDB does not permit manual encryption changes to tables in the tablespace using . Encryption of the tablespace can only be configured by setting the value of the system variable. This means that when you want to encrypt or decrypt the tablespace, you must also set a non-zero value for the system variable, and you must also set the system variable to 1 to ensure that the system tablespace is properly encrypted or decrypted by the background threads. See for more information.

Enabling Encryption for Temporary Tablespaces

The system variable controls the configuration of encryption for the . It has the following possible values:

This system variable can be specified as a command-line argument to or it can be specified in a relevant server in an . For example:

Enabling Encryption for the Redo Log

InnoDB uses the in crash recovery. By default, these events are written to file in an unencrypted state. In configuring MariaDB for data-at-rest encryption, ensure that you also enable encryption for the Redo Log.

To encrypt the Redo Log, first the server process. Then, set the to ON in a relevant server in an . For example:

Then, start MariaDB. When the server starts back up, it checks to recover InnoDB in the event of a crash. Once it is back online, it begins writing encrypted data to the Redo Log.

Key rotation for the Redo Log is supported. See for more information.

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}

Overview

MariaDB contains a robust, full instance, at-rest encryption. This feature uses a flexible plugin interface to allow actual encryption to be done using a key management approach that meets the customer's needs. MariaDB Server includes a plugin that uses the Amazon Web Services (AWS) Key Management Service (KMS) to facilitate separation of responsibilities and remote logging & auditing of key access requests.

Rather than storing the encryption key in a local file, this plugin keeps the master key in AWS KMS. When you first start MariaDB, the AWS KMS plugin will connect to the AWS Key Management Service and ask it to generate a new key. MariaDB will store that key on-disk in an encrypted form. The key stored on-disk cannot be used to decrypt the data; rather, on each startup, MariaDB connects to AWS KMS and has the service decrypt the locally-stored key(s). The decrypted key is stored in-memory as long as the MariaDB server process is running, and that in-memory decrypted key is used to encrypt the local data.

This guide is based on CentOS 7, using systemd with SELinux enabled. Some steps will differ if you use other operating systems or configurations.

Overview

Having tables encrypted makes it almost impossible for someone to access or steal a hard disk and get access to the original data. This functionality is also known as Transparent Data Encryption (TDE).

Encryption and Decryption Lifecycle

MariaDB performs data-at-rest encryption at specific points during disk I/O operations. When data is written to disk, encryption usually takes place; when data is read back into memory, decryption takes place. Data stored in memory (for example, in buffer pools) is often decrypted while in use.

Which Storage Engines Does MariaDB Encryption Support?

MariaDB encryption is fully supported for the storage engines. Encryption is also supported for the Aria storage engine, but only for tables created with ROW_FORMAT=PAGE (the default), and for the binary log (replication log).

MariaDB allows the user to configure flexibly what to encrypt. In or InnoDB, one can choose to encrypt:

• everything — all tablespaces (with all tables) (with )

• individual tables

• everything, excluding individual tables

Additionally, one can choose to encrypt InnoDB log files (recommended, with ) and InnoDB Temporary Tables (with ).

When or an encryption key of 1 must be defined. See .

Limitations

These limitations exist in the data-at-rest encryption implementation:

• Only data and only at rest is encrypted. Metadata (for example .frm files) and data sent to the client are not encrypted (but see ).

• Only the MariaDB server knows how to decrypt the data, in particular

  • can read encrypted binary logs only when --read-from-remote-server is used ().

Encryption Key Management

MariaDB's data-at-rest encryption requires the use of a . These plugins are responsible both for the management of encryption keys and for the actual encryption and decryption of data.

MariaDB supports the use of . Each encryption key uses a 32-bit integer as a key identifier. If the specific plugin supports , then encryption keys can also be rotated, which creates a new version of the encryption key.

How MariaDB manages encryption keys depends on which encryption key management solution you choose. Currently, MariaDB has three options:

Once you have an key management and encryption plugin set up and configured for your server, you can begin using encryption options to better secure your data.

Encrypting Data

Encryption occurs whenever MariaDB writes pages to disk. Encrypting table data requires that you install a , such as the plugin. Once you have a plugin set up and configured, you can enable encryption for your InnoDB and Aria tables.

Encrypting Table Data

MariaDB supports data-at-rest encryption for InnoDB and Aria storage engines. Additionally, it supports encrypting the and internal on-disk temporary tables that use the Aria storage engine..

Encrypting Temporary Files

MariaDB also creates temporary files on disk. For example, a binary log cache will be written to a temporary file if the binary log cache exceeds or , and temporary files are also often used for filesorts during query execution. These temporary files can also be encrypted if is set.

Temporary files created internally by InnoDB, such as those used for merge sorts and row logs can also be encrypted if is set. These files are encrypted regardless of whether the tables involved are encrypted or not, and regardless of whether is set or not.

Encrypting Binary Logs

MariaDB can also encrypt (including ).

Binary and Relay Log Encryption Behavior

When is an event encrypted?

When binary log and relay log events are written to the IO_CACHE, they are encrypted. This happens regardless of whether the cache is stored on disk or in memory, depending on the transaction size and the values of binlog_cache_size and binlog_stmt_cache_size. Hence, before events are written to the actual binary log and relay log files, they are encrypted.

When is an event decrypted?

When a START_ENCRYPTION_EVENT appears in the binary log or relay log, events are decrypted as they are read. This event comes right after the FORMAT_DESCRIPTION_EVENT in encrypted binary logs and relay logs, making it the second event in the log file.

Encryption and Page Compression

Data-at-rest encryption and can be used together. When they are used together, data is first compressed, and then it is encrypted. In this case you save space and still have your data protected.

Thanks

• Tablespace encryption was donated to the MariaDB project by Google.

We are grateful to these companies for their support of MariaDB!

See Also

• A with benchmark results

_{This page is licensed: CC BY-SA / Gnu FDL}

Due to license incompatibilities between the MariaDB server source code and the Amazon AWS C++ SDK, we can only distribute the plugin in source code form, and not as ready-to-use binaries. See for details.

MariaDB's requires the use of a . These plugins are responsible both for the management of encryption keys and for the actual encryption and decryption of data.

MariaDB supports the use of . Each encryption key uses a 32-bit integer as a key identifier. If the specific plugin supports , then encryption keys can also be rotated, which creates a new version of the encryption key.

The AWS Key Management plugin is a that uses the .

Overview

If you have Aria tables encrypted, you must first decrypt them:

Repeat this for each Aria table that is encrypted.

• Ensure the server can currently read encrypted data Keep your key management/encryption plugin configured and loaded so MariaDB can read existing encrypted Aria tables. Don’t remove the plugin yet. MariaDB

• Turn off Aria encryption for future writes Set the global variable to off and restart if set in config:

  Also set in the option file to persist:

  With encryption disabled, any newly rebuilt Aria table will be written unencrypted.

• Rebuild Aria tables to rewrite them unencrypted Rebuilding causes MariaDB to rewrite data and index files (.MAD/.MAI) in the current (now unencrypted) mode. Typical ways to rebuild:

  • ALTER TABLE t ENGINE=Aria;

  • ALTER TABLE t ALGORITHM=COPY; (forces a copy/rebuild)

• Repeat for all Aria tables you want decrypted Generate statements for every Aria table:

  Review and run the generated DDL. (System tables may use Aria in newer releases—handle with care.)

• Verify and then remove encryption dependencies (optional) Once all targeted Aria tables are rebuilt and unencrypted, and you have no other encrypted assets relying on the plugin (e.g., InnoDB encryption, binlog encryption), you can remove or disable the key management/encryption plugin.

MariaDB's requires the use of a . These plugins are responsible both for the management of encryption keys and for the actual encryption and decryption of data.

MariaDB supports the use of . Each encryption key uses a 32-bit integer as a key identifier. If the specific plugin supports , then encryption keys can also be rotated, which creates a new version of the encryption key.

The File Key Management plugin that ships with MariaDB is a that reads encryption keys from a plain-text file.

Overview

The File Key Management plugin is the for users who want to use . Some of the plugin's primary features are:

This document assumes you've already set up an Amazon Web Services (AWS) account, created a master key in the Key Management Service (KMS), and have done the basic work to set up the MariaDB AWS KMS plugin. These steps are all described in Amazon Web Services (AWS) Key Management Service (KMS) Encryption Plugin Setup Guide.

Ultimately, keeping all the credentials required to read the key on a single host means that a user who has gained access to the host has enough information to read the encrypted files in the datadir, read the encrypted keys from the datadir, interact with AWS KMS to decrypt the encrypted keys, and then used the decrypted keys to decrypt the encrypted data.

Theoretically, a superuser can read the memory of the MariaDB server process to read the decrypted keys or restart MariaDB with password authentication disabled in order to dump data, or add new users to MariaDB in order to allow a user to connect and dump the data. Resolving these issues is beyond the scope of this document. A user who gains root access to your operating system or root access to your MariaDB server will have the ability to decrypt your data. Plan accordingly.

Managing AWS credentials

Putting the AWS credentials in a file inside the MariaDB home directory is not ideal. By default, any user with the FILE privilege can read any files that the MariaDB server has permission to read, which would include the credentials file. To protect against this, you should set secure_file_priv to restrict the location the server will allow a user to read from when executing LOAD DATA INFILE or the LOAD_FILE() function.

But putting them in other locations requires passing additional data to the server, which in the case of CentOS 7 requires customizing the systemd startup procedure. This is most easily done by creating a "drop-in" file in /etc/systemd/system/mariadb.service.d/. The file should end in ".conf" but can otherwise be named whatever you like. After making any changes to systemd files, execute systemctl daemon-reload and then start (or restart) the service as usual.

You can place the credentials file in a location of your choosing and then refer to that file by setting the AWS_CREDENTIAL_PROFILES_FILE environment variable in the drop-in file:

The credentials file will need to be readable by the "mysql" user, but it does not need to be readable by any other user.

AWS credentials can also be put directly into a "drop-in" systemd file that will be read when starting the MariaDB service:

However, any OS user can read this information from systemd, which could be considered a security risk. Another solution is to put the credentials in a separate file that is only readable by root and then refer to that file using an EnvironmentFile directive in a drop-in systemd file.

That has the advantage the credentials can only be read directly by root. systemd adds those variables to the environment of the MariaDB server when starting it, and MariaDB can use the credentials to interact with AWS. Note, though, that any process running as the "mysql" user can still read the credentials from the proc filesystem on Linux.

AWS KMS Key Policy

AWS KMS allows flexible, user-editable key policy. This offers fine-grained control over which users can operate on keys. The possibilities range from simply restricting which IP addresses are allowed to perform operations on the key, to requiring a MFA (Multi-Factor Authentication) device to use the key, to enforcing separation of responsibilities by creating an additional user with limited privileges to enable and disable the key. All 3 of these options will be outlined in this section.

For more details about customizing the Key Policy for your master keys, please consult the documentation.

Source IP restrictions

A simple, common-sense restriction to put in place is to restrict the range of IP addresses that are allowed to use your master key. This way, even if someone obtains API credentials, they'll be unable to use them to decrypt your encryptions keys from a different host.

To restrict API access from only a specific IP address or range of IP addresses, you'll need to manually edit the key policy.

1. Load the IAM console at.

2. Click "Encryption Keys" in the left-hand sidebar.

3. Click the name of your encryption key to view its details.

4. Click the link labeled "Switch to policy view", to the right of the heading of the "Key Policy" section.

... replacing 10.1.2.3/32 above with an IP address or range of IP addresses in CIDR format. For example, a single address would be 192.168.12.34/32, while a range of addresses might be 192.168.0.0/24.

1. Click "Save Changes".

2. Click "Proceed" if prompted with a warning about using the default view in the future.

Access to the API will now be restricted to requests coming from the IP address or range of IP addresses specified in the policy.

Using a Multi-Factor Authentication (MFA) device

One approach is to modify the key policy for the master key so that MFA (Multi-Factor Authentication) is required in order to use the key. This is achieved with a wrapper that handles prompting the user for an MFA token, acquires temporary, limited-privilege credentials from the AWS Security Token Service (STS), and puts those credentials into the environment of the MariaDB server process. The credentials can expire after as little as 15 minutes.

To require an MFA token for users of the key, you'll need to manually edit the key policy.

1. Load the IAM console at.

2. Click "Encryption Keys" in the left-hand sidebar.

3. Click the name of your encryption key to view its details.

4. Click the link labeled "Switch to policy view", to the right of the heading of the "Key Policy" section.

1. Click "Save Changes".

2. Click "Proceed" if prompted with a warning about using the default view in the future.

Now, add an MFA device for your user. You'll need to have a hardware MFA device or an application such as Google Authenticator installed on your smartphone.

1. Click "Users" in the left-hand sidebar.

2. Click the name of your user.

3. Click the "Security Credentials" tab.

4. In the "Sign-In Credentials" section, click the "Manage MFA Device" button.

Now, set up the wrapper program.

1. Copy the iam-kms-wrapper file to /usr/local/bin/, and ensure that it is executable.

2. Create a drop-in systemd config file in /etc/systemd/system/mariadb.service.d/:

1. Execute systemctl daemon-reload.

2. Create a file at /etc/my.cnf.d/iam-kms-wrapper.config with these contents, using the ARN for your MFA device as the value for kms_mfa_id:

When you start the MariaDB service now, the wrapper will temporarily create a socket file at the location given by the kms_mfa_socket option. The wrapper will read the MFA code from the socket and will use it to authenticate to KMS. To give the MFA code, simply write the digits to the socket file using echo: echo 111676 > /tmp/kms_mfa_socket.

The systemctl command will block until MariaDB starts, so you will need to write the code to the socket file via a separate terminal.

Note that the temporary credentials put into the environment of the MariaDB process will expire after a period of time defined by the request to the AWS Security Token Service (STS). In the example below, they will expire after 900 seconds. After that time, MariaDB may be unable to generate new encrypted data keys, which means that, for example, an attempt to create a table with a previously-unused key ID would fail.

Wrapper program example

Here's an example wrapper program written in go. Build this into an executable named iam-kms-wrapper and use it as instructed above. This could of course be written in any language for which an appropriate AWS SDK exists, but go has the benefit of compiling to a static binary, which means you do not have to worry about interpreter versions or installing complex dependencies on the host that runs your MariaDB server.

Disabling keys when not needed

Another possibility is to use the API to disable access to the master key and enable it only when a trusted administrator knows that the MariaDB service needs to be started. A specialized tool on a separate host could be used to enable the key for a very short period of time while the service starts and then quickly disable the key.

To do this, you can create an extra IAM User that can only use the kms:EnableKey and kms:DisableKey API endpoints for your key. This user will not be able to encrypt or decrypt any data using the key.

First, create a new user.

1. Load the IAM console at.

2. Click "Users" in the left-hand sidebar.

3. Click "Create New Users".

4. Enter a new user name. (The examples will use "MDBEncAdmin".)

1. Click "Close".

2. Click "Close" again if prompted.

3. Click the name of your new user to open the details view.

4. Copy the "User ARN" value for your user (for example "arn:aws:iam::551888181234:user/MDBEncAdmin"). You will need this for the next step.

Now, give the new user permission to perform API operations on your key.

1. Click "Encryption Keys" in the left-hand sidebar.

2. Click the name of your key to open the details view.

3. Click "Switch to policy view" if it is not already open. (The "policy view" is a large text field that contains JSON describing the key policy.)

4. Create a new item in the Statement array with this structure:

...so that your Key Policy looks like this:

1. Click "Save Changes".

You've now added a new IAM user and you've given that user privileges to enable and disable your key. This user will be able to perform those operations using the AWS CLI or via a script of your own design using the AWS API. For example, using the :

In order for MariaDB to start, this new user will have to enable the master key, then the DBA can start MariaDB, and this user can once again disable the master key after the service has started. Note that in this workflow, MariaDB will be unable to create new encryption keys, such as would be done when a user creates a table that refers to a non-existent key ID. The AWS KMS plugin will encounter an error if it tries to generate a new encryption key while the master key is disabled. In that scenario, the key administrator would have to enable the key before the operation could succeed. Here's what you should expect to see in the journal if MariaDB tries to interact with a disabled master key:

Adding MFA

It's also possible to add MFA to this technique so that the user that enables & disables the master key has to authenticate using an MFA device. Adapt the instructions in the MFA section above to add MFA to the policy section for the user with EnableKey and DisableKeys privileges, add an MFA device for that user, use Security Token Service (STS) to get temporary security credentials, and then use those credentials to make the API calls. Here's an example Python script that follows that workflow:

Logging and auditing

CloudTrail

Amazon's CloudTrail service creates JSON-formatted text log files for every API interaction. Enabling CloudTrail requires S3, which incurs additional fees.

First, enable CloudTrail and add a trail.

1. Load the CloudTrail console at.

2. If you've never used CloudTrail before, click "Get Started Now".

3. Enter a value for "trail name". This example uses "mariadb-encryption-key".

4. Create a new S3 bucket, using a globally unique name, or use an existing S3 bucket, according to your needs.

If you navigate to the S3 bucket you created, you should find log files that contain JSON-formatted descriptions of your API interactions.

CloudWatch

Amazon's CloudWatch service allows you to create alarms and event rules that monitor log information.

First, send your CloudTrail logs to CloudWatch.

1. Load the CloudTrail console at.

2. Click "Trails" in the left-hand navigation sidebar.

3. Click the name of your trail to open the Configuration view.

4. In the "CloudWatch Logs" section, click "Configure".

Now, set up an SNS topic to facilitate email notifications.

1. Open.

2. Make sure the region in the console (look in the upper-right corner) is the same as the region where you created your key!

3. Click "Get Started" is prompted.

4. Click "Events" in the left-hand sidebar.

Now, configure CloudWatch and create an Event Rule.

1. Open.

2. Make sure the region in the console (look in the upper-right corner) is the same as the region where you created your key and your SNS topic!

3. Click "Events" in the left-hand sidebar.

4. Click "Create rule".

You should now get emails any time someone executes API calls on the KMS service in the region where you've created the CloudWatch Event rule. That means you should get email any time the key is enabled or disabled, and any time the AWS KMS plugin generates new keys or decrypts the keys stored on disk on the MariaDB server.

You may also wish to create an event rule (or an additional event) that matches only when an unauthorized user tries to access the key. You might accomplish that by manually editing the Event selector of the rule to look something like this:

The emails are formatted as JSON. Further customization of the CloudWatch email workflow is beyond the scope of this document.

There are many other workflows available using CloudWatch, including workflows with alarms and dashboards. Those are beyond the scope of this document.

_{This page is licensed: CC BY-SA / Gnu FDL}

The process involved in safely disabling encryption for your InnoDB tables is a little more complicated than that of enabling encryption. Turning off the relevant system variables doesn't decrypt the tables. If you turn it off and remove the encryption key management plugin, it'll render the encrypted data inaccessible.

In order to safely disable encryption, you first need to decrypt the tablespaces and the Redo Log, then turn off the system variables. The specifics of this process depends on whether you are using automatic or manual encryption of the InnoDB tablespaces.

Disabling Encryption for Automatically Encrypted Tablespaces

When an InnoDB tablespace has the ENCRYPTED table option set to DEFAULT and the innodb_encrypt_tables system variable is set to ON or FORCE, the tablespace's encryption is automatically managed by the background encryption threads. When you want to disable encryption for these tablespaces, you must ensure that the background encryption threads decrypt the tablespaces before removing the encryption keys. Otherwise, the tablespace remains encrypted and becomes inaccessible once you've removed the keys.

To safely decrypt the tablespaces, first, set the system variable to OFF:

Next, set the system variable to a non-zero value:

Then, set the system variable to 1:

Once set, any InnoDB tablespaces that have the table option set to DEFAULT will be in the background by the InnoDB .

Decryption Status

You can of the decryption process using the table in the database.

This query shows the number of InnoDB tablespaces that currently using background encryption threads. Once the count reaches 0, then all of your InnoDB tablespaces are unencrypted. Be sure to also remove encryption on the and the storage engine before removing the encryption key management settings from your configuration file.

Disabling Encryption for Manually Encrypted Tablespaces

In the case of manually encrypted InnoDB tablespaces, (that is, those where the table option is set to YES), you must issue an statement to decrypt each tablespace before removing the encryption keys. Otherwise, the tablespace remains encrypted and becomes inaccessible without the keys.

First, query the Information Schema table to find the encrypted tables. This can be done with a WHERE clause filtering the CREATE_OPTIONS column.

For each table in the result-set, issue an statement, setting the table option to NO.

Once you have removed encryption from all the tables, your InnoDB deployment is unencrypted. Be sure to also remove encryption from the as well as and any other storage engines that support encryption before removing the encryption key management settings from your configuration file.

InnoDB does not permit manual encryption changes to tables in the tablespace using . Encryption of the tablespace can only be configured by setting the value of the system variable. This means that when you want to encrypt or decrypt the tablespace, you must also set a non-zero value for the system variable, and you must also set the system variable to 1 to ensure that the system tablespace is properly encrypted or decrypted by the background threads. See for more information.

Disabling Encryption for Temporary Tablespaces

The system variable controls the configuration of encryption for the . To disable it, remove the system variable from your server's , and then restart the server.

Disabling Encryption for the Redo Log

InnoDB uses the in crash recovery. By default, these events are written to file in an unencrypted state. In removing data-at-rest encryption for InnoDB, be sure to also disable encryption for the Redo Log before removing encryption key settings. Otherwise the Redo Log can become inaccessible without the encryption keys.

First, set the system variable to OFF in a server in an . Once this is done, restart the MariaDB Server. When the Server comes back online, it begins writing unencrypted data to the Redo Log.

After the server has been successfully restarted with encryption disabled, you may remove the that had been used. If you try to disable encryption for the Redo Log and remove the plugin in a single step, InnoDB will be unable to decrypt the log in order to remove the encryption.

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}