[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
MariaDB uses the encryption key with ID 1 to encrypt binary logs.
Some key management and encryption plugins 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 background encryption threads 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 MDEV-20098.
In order for key rotation to work, both the backend key management service (KMS) and the corresponding key management and encryption plugin have to support key rotation. See Encryption Key Management: Support for Key Rotation in Encryption Plugins to determine which plugins currently support key rotation.
Encryption of binary logs can be enabled by doing the following process.
encrypt_binlog=ONin the MariaDB configuration file.
Encryption of binary logs can be disabled by doing the following process.
encrypt_binlog=OFFin the MariaDB configuration file.
From that point forward, any new binary logs will be unencrypted. If you would like the server to continue to have access to old encrypted binary logs, then make sure to keep your key management and encryption plugin 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 replication, 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 binary log dump thread 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 TLS with the replication connection.
mysqlbinlog does not currently have the ability to decrypt encrypted binary logs on its own (see MDEV-8813 about that). In order to use mysqlbinlog with encrypted binary logs, you have to use the
--read-from-remote-server command-line option, so that the server can decrypt the binary logs for mysqlbinlog.
--read-from-remote-server option on versions of the
mysqlbinlog utility that do not have the MDEV-20574 fix, can corrupt binlog positions when the binary log is encrypted.
© 2019 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.