The Ultimate Guide to High Availability with MariaDB

Data at Rest Encryption

You are viewing an old version of this article. View the current version here.
MariaDB starting with 10.1.3

Encryption of tables and tablespaces was added in MariaDB 10.1.3. There were substantial changes made in MariaDB 10.1.4, and the description below applies only to MariaDB 10.1.4 and later

Contents

  1. Overview
  2. Which storage engines does MariaDB encryption support?
  3. Limitations
  4. Encryption Key Management
  5. Encrypting Data
    1. XtraDB and InnoDB
    2. Encryption of Aria Tables
    3. Encryption of Aria temporary tables
    4. Encryption of temporary files
    5. Encryption of binary logs
  6. Encryption and compression
  7. Thanks
  8. See Also

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 assumes that encryption keys are stored on another system.

Using encryption has an overhead of roughly 3-5%.

Which storage engines does MariaDB encryption support?

MariaDB encryption is fully supported for the XtraDB and InnoDB storage engines. Additionally, encryption is supported for the Aria storage engine, but only for tables created with ROW_FORMAT=PAGE (the default).

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

  • everything — all tablespaces (with all tables)
  • individual tables
  • everything, excluding individual tables

Additionally, one can choose to encrypt XtraDB/InnoDB log files (recommended).

Limitations

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

  • Only data and only at rest is encrypted. Metadata (for example .frm files) and data sent to the client are not encrypted (but see Secure Connections).
  • Only the MariaDB server knows how to decrypt the data, in particular
  • The disk-based Galera gcache is not encrypted (MDEV-9639).
  • The Audit plugin cannot create encrypted output. Send it to syslog and configure the protection there instead.
  • File-based general query log and slow query log cannot be encrypted (MDEV-9639).
  • The Aria log is not encrypted (MDEV-9639). This affects only non-temporary Aria tables though.
  • The MariaDB error log is not encrypted. The error log can contain query text and data in some cases, including crashes, assertion failures, and cases where InnoDB/XtraDB write monitor output to the log to aid in debugging. It can be sent to syslog too, if needed.

Encryption Key Management

MariaDB Encryption supports the use of multiple encryption keys. Each key uses a 32-bit integer as a key identifier and can be versioned, allowing you to automatically re-encrypt data from older to newer versions of the key.

In order to use data-at-rest encryption, you need to load a plugin to manage the encryption keys.

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

Encrypting Data

Encrypting table data requires that you implement an encryption plugin, such as the File Key Management plugin. Once you have this plugin set up and configured, you can enable encryption on your InnoDB, XtraDB and Aria tables.

XtraDB and InnoDB

Both InnoDB and XtraDB use the same server system variables and table options to configure data-at-rest encryption. For more information on how to set up and configure encryption for these storage engines, see Encrypting Data for InnoDB and XtraDB.

Encryption of Aria Tables

Only tables created with ROW_FORMAT=PAGE can be encrypted. This is the default row format for Aria.

You can specify that all Aria tables of the above type are encrypted by specifying:

[mysqld]
aria-encrypt-tables=1

Encryption of Aria temporary tables

MariaDB uses Aria for on-disk temporary tables that don't fit into MEMORY tables.

To ensure that no one can access data stored in temporary tables created as part of query execution, you can encrypt the temporary data by specifying in your my.cnf/my.ini file:

encrypt-tmp-disk-tables=1

This works by creating and using a random encryption key for every new temporary table.

Encryption of temporary files

MariaDB might create temporary files on disk. For example, temporary files are created for binary log transactional caches and for filesort. Since MariaDB 10.1.5, these temporary files can also be encrypted if encrypt_tmp_files is set. From MariaDB 10.1.27, MariaDB 10.2.9 and MariaDB 10.3.2, temporary files created by merge sort and row log are encrypted if innodb_encrypt_log is set to 1, regardless of whether the table encrypted or not, or whether encrypt_tmp_files is set or not.

Encryption of binary logs

Since 10.1.7, MariaDB can also encrypt binary logs (including relay logs). Binary logs are encrypted if --encrypt-binlog is specified on the command line or in the my.ini or my.cnf file.

Encryption and compression

Encryption and compression (a feature usable with FusionIO) can be used together. This works by first compressing the data and then encrypting it. In this case you save space and still have your data protected.

Thanks

  • Tablespace encryption was donated to the MariaDB project by Google.
  • Per-table encryption and key identifier support was donated to the MariaDB project by eperi.

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

See Also

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.