MariaDB Server can encrypt the server's binary logs and relay logs. This ensures that your binary logs are only accessible through MariaDB.
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.
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 .
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.
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 .
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.
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.
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 .
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
[mariadb]
...
# File Key Management
plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/encryption/keyfile.enc
file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key
file_key_management_encryption_algorithm = AES_CTR
# Binary Log Encryption
encrypt_binlog=ON