Architecture Note: Implementing InnoDB Data‑at‑Rest Encryption in MariaDB

Requirements

The goal is to protect all InnoDB data files (table spaces, redo/undo logs, and temporary tables) from unauthorized access when they reside on disk or in backups. The solution must:

• Encrypt data transparently without application changes.
• Store the master encryption key outside the database process to limit exposure.
• Allow verification that encryption is active and that keys are available at startup.
• Support backup/restore workflows that preserve key material.

Smallest Suitable Design

Enable the built‑in InnoDB encryption flags and point MariaDB to a single keyring file that holds the master key. This design satisfies the requirements with minimal moving parts.

# /etc/mysql/mariadb.conf.d/encryption.cnf
[mysqld]
innodb_encrypt_tables=ON
innodb_encrypt_log=ON
keyring_file_data=/var/lib/mysql-keyring/keyring
keyring_plugin=keyring_file

When innodb_encrypt_tables and innodb_encrypt_log are ON, MariaDB automatically encrypts:

• All file‑per‑table and general tablespaces.
• The system tablespace (ibdata1).
• Redo logs (ib_logfile*) and undo logs.
• Internal temporary tables created for queries.

The keyring_file plugin reads/writes a single file (/var/lib/mysql-keyring/keyring) that contains the master key in an encrypted form protected by the file’s OS permissions.

Trust and Data Boundaries

Encryption protects data at rest; the trust boundary shifts to the keyring file and the OS account that can read it.

• Keyring trust: The keyring must be stored on a filesystem with strict permissions (e.g., 0600 owned by the mysql user). No other system user should be able to read the file.
• Process isolation: The MariaDB server process is the only entity that should have read access to the keyring during startup and runtime. If an attacker gains the ability to read the keyring file, they can decrypt all data.
• Backup boundary: Physical backups (e.g., mysqlbackup or file‑system snapshots) contain encrypted data; they are safe as long as the keyring is also backed up and stored separately.

Operational Checks

After configuring encryption, verify that the server starts with the expected settings and that the keyring is accessible.

1. Check variables: Run the following SQL as a user with SHOW VARIABLES privilege (typically root or a monitoring account):

   SHOW VARIABLES LIKE 'innodb_encrypt_tables';
   SHOW VARIABLES LIKE 'innodb_encrypt_log';
   SHOW VARIABLES LIKE 'keyring_plugin';
   SHOW VARIABLES LIKE 'keyring_file_data';

   Expected output: ON for the two encryption variables, keyring_file for the plugin, and the path you set for keyring_file_data.
2. Confirm tablespace encryption:

   SELECT TABLESPACE_NAME, ENCRYPTION
   FROM INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION
   WHERE ENCRYPTION = 'YES' LIMIT 5;

   If encryption is active, each InnoDB tablespace should list ENCRYPTION = YES. Temporary tables appear with names like #sql2b3_1_0 and will also show YES when they exist.
3. Test keyring dependency: Stop the server, rename the keyring file, then attempt to start MariaDB:

   systemctl stop mariadb
   mv /var/lib/mysql-keyring/keyring /var/lib/mysql-keyring/keyring.bak
   systemctl start mariadb

   The service should fail to start, and the error log will contain a message such as "Cannot find keyring file" or "Keyring plugin initialization failed". Restore the keyring and restart to return to normal operation.
4. Backup/restore validation: After taking a physical backup, verify that the backup directory contains the keyring file (or store it separately). Restore the backup on a test server, ensuring the keyring is placed at the same path before starting MariaDB.

Failure Modes

• Keyring loss or corruption: If the keyring file is missing or unreadable, MariaDB will refuse to start, rendering all encrypted data inaccessible. There is no built‑in recovery mechanism; you must restore a known‑good keyring from backup.
• Mis‑configured keyring plugin: Specifying an incorrect path or using an unsupported plugin causes startup failure with a clear error in the log.
• Performance overhead: Encryption adds CPU cost for each page read/write. For I/O‑bound workloads the overhead is typically 3‑5 %; CPU‑bound workloads may see a larger impact. Monitor Innodb_buffer_pool_reads and Innodb_buffer_pool_writes before and after enabling encryption to assess impact.
• Replication mismatch: If a replica uses a different keyring (different master key) it cannot decrypt relay logs or encrypted tables copied from the source, causing replication to stop with errors like "Decryption failed". Ensure the keyring file is identical on source and replica, or use a keyring solution that supports key versioning and sharing.

Conditions That Would Change the Design

Revisit the architecture when any of the following occur:

• Regulatory requirement for key rotation: If policies demand periodic master key rotation, consider a keyring plugin that supports versioned keys (e.g., keyring_aws or keyring_okv) and plan a re‑encryption workflow using ALTER TABLE ... ENCRYPTION='Y' or ALTER TABLESPACE ... ENCRYPTION='Y'.
• Adoption of a managed MariaDB service: Some cloud providers encrypt data at rest transparently and may discourage double encryption. In that case, rely on the provider’s encryption and disable InnoDB encryption to avoid unnecessary overhead.
• Need for hardware‑based key protection: If the environment requires HSM‑backed keys, replace keyring_file with a plugin that talks to an HSM (e.g., keyring_okv) and adjust trust boundaries accordingly.
• Shift to column‑level encryption for specific PII: If only a subset of columns must be encrypted, consider using MariaDB’s AES_ENCRYPT/AES_DECRYPT functions or the data_masking plugin instead of full tablespace encryption.

Practical Verification Checklist

1. Confirm innodb_encrypt_tables=ON and innodb_encrypt_log=ON after restart.
2. Query INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION for ENCRYPTION=YES on sample tablespaces.
3. Simulate keyring loss and verify the server fails to start with a keyring‑related error.
4. Validate that backups include the keyring (or store it separately) and that a restore works when the keyring is present.
5. Monitor CPU and I/O metrics before and after enabling encryption to ensure overhead stays within acceptable limits.