1 of 72

Security

Secure your MariaDB Server. This section provides comprehensive guidance on user management, encryption, authentication, auditing, and other crucial security measures.

Securing MariaDB

Running mariadbd as root

Understand the implications of running MariaDB Server as root. This section highlights security risks and provides guidance on configuring MariaDB Server to operate with less privileged user accounts.

MariaDB should never normally be run as the system's root user (this is unrelated to the MariaDB root user). If it is, any user with the FILE privilege can create or modify any files on the server as root.

MariaDB will normally return the error Fatal error: Please read "Security" section of the manual to find out how to run mariadbd as root! if you attempt to run mariadbd as root. If you need to override this restriction for some reason, start mariadbd with the user=root option.

Better practice, and the default in most situations, is to use a separate user, exclusively used for MariaDB. In most distributions, this user is called mysql.

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

Encryption

Enhance MariaDB Server security with encryption. This section covers data-at-rest and in-transit encryption, helping you protect sensitive information and meet compliance requirements.

Data-in-Transit Encryption

Secure MariaDB Server data in transit with encryption. This section covers configuring SSL/TLS to protect communication between clients and the database, ensuring confidentiality and integrity.

Certificate Creation with OpenSSL

Warning: the instructions below generate version 1 certificates only. These work fine with servers and clients using OpenSSL, but fail if WolfSSL is used instead, as is the case for our Windows MSI packages and our binary tarballs for Linux. WolfSSL requires version 3 certificates instead when using TLS v1.2 or higher, and so won't work with certificates generated as shown here when using two-way TLS with explicit client certificates. Generating version 3 certificates requires a few more minor steps, we will upgrade the instructions below soon to include these. See also:

In order to secure communications with the MariaDB Server using TLS, you need to create a private key and an X509 certificate for the server. You may also want to create additional private keys and X509 certificates for any clients that need to connect to the server with TLS. This guide covers how to create a private key and a self-signed X509 certificate with OpenSSL.

Certificate Creation

The library provides a command-line tool called

Requiring TLS on MariaDB Server

Overview

and MariaDB Community Server support data-in-transit encryption, which secures data transmitted over the network. The server and the clients encrypt data using the Transport Layer Security (TLS) protocol, which is a newer version of the Secure Socket Layer (SSL) protocol.

TLS must be manually enabled on the server.

Using TLSv1.3

OpenSSL 1.1.1 introduced support for TLSv1.3. TLSv1.3 is a major rewrite of the TLS protocol. Some even argued it should've been called TLSv2.0. One of the changes is that it introduces a new set of cipher suites that only work with TLSv1.3. Additionally, TLSv1.3 does not support cipher suites from previous TLS protocol versions.

This incompatible change had a non-obvious consequence. If a user had been explicitly specifying cipher suites to disable old and obsolete TLS protocol version, then that user may have also inadvertently prevented TLSv1.3 from working, unless the user remembered to add the TLSv1.3 cipher suites to their cipher list. After upgrading to OpenSSL 1.1.1, this user might believe they are using TLSv1.3, when their existing cipher suite configuration might be preventing it.

To avoid this problem, OpenSSL developers decided that TLSv1.3 cipher suites should not be affected by the normal cipher-selecting API. This means that ssl_cipher system variable has no effect on the TLSv1.3 cipher suites.

See this OpenSSL blog post and GitHub issue for more information.

Data-at-Rest Encryption

Secure MariaDB Server data at rest with encryption. This section details how to protect your sensitive information stored on disk, ensuring data confidentiality and compliance.

Why Encrypt MariaDB Data?

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}

Aria Encryption

Learn about Aria encryption in MariaDB Server for data at rest. This section details how to encrypt Aria tablespaces, providing enhanced security for your stored data.

Aria Encryption Overview

MariaDB can encrypt data in tables that use the Aria storage engine. This includes both user-created tables and internal on-disk temporary tables that use the Aria storage engine. This ensures that your Aria data is only accessible through MariaDB.

For encryption with the InnoDB and XtraDB storage engines, see Encrypting Data for InnoDB/XtraDB.

Basic Configuration

In order to enable encryption for tables using the Aria storage engine, there are a couple server system variables that you need to set and configure. Most users will want to set aria_encrypt_tables and encrypt_tmp_disk_tables.

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

Determining Whether a Table is Encrypted

The has the that can be used to get information about which tables are encrypted. Aria does not currently have anything like that (see about that).

To determine whether an Aria table is encrypted, you currently have to search the data file for some plain text that you know is in the data.

For example, let's say that we have the following table:

Then, we could search the data file that belongs to db1.aria_tab for str1 using a command-line tool, such as :

If you can find the plain text of the string, then you know that the table is not encrypted.

Encryption and the Aria Log

Only Aria tables are currently encrypted. The is not yet encrypted. See about that.

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

Aria Disabling Encryption

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 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

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

Aria Encryption Keys

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}

InnoDB Encryption

Learn about InnoDB encryption for data at rest. This section details how to encrypt InnoDB tablespaces, ensuring strong data security and compliance for your mission-critical applications.

Key Management and Encryption Plugins

Explore key management and encryption plugins for MariaDB Server. This section details how to manage encryption keys and leverage plugins for robust data-at-rest protection.

Disabling Data-at-Rest Encryption for Standalone Servers

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.

This procedure is only intended for standalone MariaDB Enterprise Server environments.
For replication or Galera Cluster setups, additional considerations are required and are not covered here.
Always back up your data before performing encryption or decryption operations.

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.

Decrypt Aria Tables

This page describes how to decrypt datdata at resta-at-rest for tables that use the Aria storage engine.

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

Repeat this for each Aria table that is encrypted.

For more information, refer to MDEV-17268.

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.

Decrypt InnoDB Tables

When data-at-rest encryption is enabled, InnoDB tables and tablespaces are transparently encrypted and decrypted by the storage engine. In some cases, administrators may need to decrypt an InnoDB table—for example, when migrating data to an environment where encryption is not required, or when disabling encryption to simplify configuration.

For more information, refer to, MDEV-17269.

Decrypting a Table

To decrypt a specific InnoDB table, use the ENCRYPTION clause with ALTER TABLE:

This statement rewrites the table in an unencrypted format.

If the table is stored in a file-per-table tablespace, the corresponding .ibd file is decrypted and rewritten.
If the table resides in the system tablespace, the data is also rewritten unencrypted.

Decrypting All Tables in a Schema

To decrypt all tables in a schema, you can generate and run ALTER TABLE statements programmatically:

Copy and execute the generated statements.

Verifying Decryption

After decryption, you can verify the encryption status of a table with:

If the table is unencrypted, the create_options column will not include ENCRYPTION="Y".

Decrypt InnoDB Redo Logs

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.

For more information, refer to .

Stop MariaDB Enterprise Server

Decrypt Binary Logs

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.

For more information, refer to MDEV-17271.

Approaches to decrypt binary logs

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

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:

Uninstall Key Management Plugins

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:

User Account Management

Master user account management in MariaDB Server. This section covers creating, modifying, and revoking user privileges to ensure secure and controlled access to your databases.

Roles

Manage roles in MariaDB Server for streamlined user access control. This section explains how to create, assign, and manage roles to simplify privilege management and enhance security.

Roles Overview CREATE ROLE DROP ROLE CURRENT_ROLE SET ROLE SET DEFAULT ROLE GRANT REVOKE mysql.roles_mapping Table Information Schema APPLICABLE_ROLES Table Information Schema ENABLED_ROLES Table

System`s Users, Roles, and Privileges

{% hint style="info" %} Important: The PUBLIC role is created implicitly by GRANT statements and its creation is not logged, distinguishing it from standard system principals. {% endhint %}

MariaDB automatically creates several users and roles for administrative and internal server functions.

System Users

These user accounts are created by the mariadb-install-db script during the initial server setup.

Incrementing of the access_denied_errors status variable

The access_denied_errors status variable is incremented when someone tries to access something they do not have rights to.

This happens in the following cases:

When accessing a database, table, or column that the user does not have rights to access. The error is sent to the client.
When a login fails because of the wrong user/password, etc. The error is printed to the general log.
When the require_secure_transport option is enabled on the server, and the user has not used a secure transport. The error is sent to the client.
Users try to change to a database/schema they do not have access to. A warning is written to the error log if log_warnings > 1.
Users try to use a SHOW command to access an object they do not have rights to see. The error is sent to the client.
Users access something that requires global access, like "CREATE SERVER". The error is sent to the client.

Login failures can be found in the . Errors that are sent to the client can be found by using the . The plugin captures all errors sent to the client. Starting from , it can also optionally capture all warnings sent to the client.

Catalogs

Catalogs are a user account management feature. This section explains their role in organizing database objects and controlling access permissions.

Starting with Catalogs

Background

mariadb-install-db initializes the MariaDB data directory and creates the system tables in the mysql database.

When used with the --catalog options it will initialize MariaDB server to use catalogs. The mariadbd server will automatically discover if catalogs are used or not.

Note that one cannot change a 'normal server' to a server with catalogs or a server with catalogs to a 'normal server'. In the future we will add tools that will allow one to easily move an existing server inside a catalog or move an server inside a catalog to a standalone server.

Initializing a New Server with Catalog Support

To initialize a server with 4 catalogs (the def catalog, that holds the catalog root user (CRU) is automatically created):

The above will create a directory /my/data and the 4 directories under it, one for each catalog.

Adding More Catalogs to a Running Server

Creating Catalogs with CREATE CATALOG

One can create a new catalog with

Creating Catalogs with mariadb_install_db

When adding more catalogs to an existing server, mariadb_install_db will start the to execute the needed commands on the running server. This is why one has to supply user and password to mariadb_install_db.

One benefit of using mariadb_install_db is that it's possible to create many catalogs with one command.

Catalog-Specific Functions and Variables

Catalog Functions

catalog()

`catalog()

returns the name of the current catalog.`

Catalog Variables

@@catalogs

One can check if a server supports catalogs with:

1 means that the server is configured for catalogs.

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

Catalog Status Variables

When using a MariaDB Server with support, all status information is collected for the whole server, per catalog and per session.

shows the status for the whole server. Note that only the super user in the 'def' catalog has privileges for the above statement.

Both commands show the status for the current catalog. The reason that GLOBAL shows catalog status is that because catalogs are 'multi-tenant', a catalog user should not be able to see the status from other users (for most things).

Shows the status for the current connection.

The main "new thing" is that catalogs enable SAS providers to see the status for a single tenant (catalog user). This makes it much easier to find 'bad neighbors' (tenants that cause problems for other tenants) so that they can be moved to other servers.

When the MariaDB server is not configured for catalogs, the following commands are equivalent:

Connecting to a Server Configured for Catalogs

When connecting to a MariaDB server configured for , one has to provide the catalog to connect to. There are several ways to do this:

All new native MariaDB clients will support the --catalog option:

New and old clients can use the 'catalog_name.database_name' syntax to connect:

This will connect the user to the 'mine' catalog and the database 'test'.

Note that one consequence of this is that one should not have a database that contains '.' in the name. If such a database exists, one can still connect to it by using the --catalog= option or prefixing the database with the catalog, like in def.data.base.name.

One will also be able to configure the MariaDB server to automatically choose catalogs depending on the port or IP they are using to connect to the server. This is done by adding the following to the catalog specific my.cnf file, residing in the catalog directory:

CREATE CATALOG

Define external catalogs for data integration. This statement configures connections to remote storage systems, allowing query access to external data sources.

Syntax

Description

Creates a and the mysql

SHOW CREATE CATALOG

Syntax

Description

Shows the statement that creates the given .

SHOW CATALOGS

Syntax

Description

SHOW CATALOGS lists the catalogs on the MariaDB server host. The LIKE clause, if present on its own, indicates which catalog names to match. The WHERE and LIKE clauses can be given to select rows using more general conditions, as discussed in .

You see only use SHOW CATALOGS have the . Only users of the 'def' schema can have this privilege.

If the server was started with the option, you cannot use this statement unless you have the .

The list of results returned by SHOW CATALOGS is based on directories in the data directory, which is how MariaDB implements catalogs. It only list directories that have a mysql directory.

The also contains catalog information.

Examples

USE CATALOG

Syntax

Description

Changes to another . Can only be done by a super user in the 'def' catalog. Changing catalog will update catalog status and reset all session status.

A tenant (a user in any other catalog than 'def') cannot change to another catalog. However tenants can execute

DROP CATALOG

Syntax

DROP CATALOG catalog_name

Description

Deletes a catalog.

Limitations:

DROP CATALOG can only be performed by a super user in the 'def' catalog.
The current catalog cannot be dropped.
The 'def' catalog cannot be dropped.

When dropping a catalog, all databases and files within that catalog will be deleted.

Authentication with Enterprise Server

Learn about authentication with MariaDB Enterprise Server. This section covers advanced authentication methods & plugins to enhance security and integrate with enterprise identity management systems.

Authentication for MariaDB Enterprise Server

Overview

MariaDB Enterprise Server authentication is performed by database user accounts. Database user accounts are specified by user name, the hostname from which the account is connecting, and the authentication plugins configured for the account, such as mysql_native_password, pam, or unix_socket.

Change Password

The password for a can be changed using the , , and statements.

Password Validation Plugins

If your MariaDB Enterprise Server node has a password validation plugin installed, then the password should also meet the configured requirements. When you try to set or change a user's password and the password validation plugin rejects the password, the following error message will be shown:

By default, the MariaDB Enterprise Server installs the plugin, but the plugin is also available.

For , the password requirements are configured by several system variables:

Authentication Plugins

MariaDB Enterprise Server uses authentication plugins to support different authentication methods. The default authentication plugin is mysql_native_password.

Authentication with gssapi

Overview

The gssapi authentication plugin validates user credentials against a GSSAPI-based authentication service, like Kerberos or NTLM.

Install Package

The gssapi authentication plugin requires an additional package to be installed on Linux. On CentOS, RHEL, and Rocky Linux:

On Debian and Ubuntu:

On SLES:

Configure

The gssapi requires some system variables to be configured, including:

gssapi_keytab_path
gssapi_principal_name

For example:

Install Plugin

The gssapi must be installed before it can be used.

To install with the INSTALL SONAME statement:

To install in a configuration file with the plugin_load_add option:

Create User

To create a user account that uses the gssapi , specify the plugin in the CREATE USER statement:

An optional realm can be specified:

Limiting Size of Created Disk Temporary Files and Tables

The ability to limit the size of created disk temporary files and tables was introduced in MariaDB 11.5.

max_tmp_session_space_usage System Variable

`max_tmp_session_space_usage`

Description: The maximum total size of temporary file and temporary table usage. A value of 0 disables this feature. Set in blocks of 65536, rounded down if not a multiple of 65536. See Limiting Size of Created Disk Temporary Files and Tables Overview for details. Named max_tmp_space_usage in only.
Commandline: --max-tmp-session-space-usage=num
Scope: Global, Session
Dynamic: Yes
Data Type: numeric (bigint unsigned)
Default Value: 1099511627776
Range: 0 to 18446744073709551615 (blocks of 65536)
Introduced:

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

max_tmp_total_space_usage System Variable

`max_tmp_total_space_usage`

Description: The maximum total size in bytes of all temporary file and temporary table usage over all connections. A value of 0 disables this feature. Set in blocks of 65536, rounded down if not a multiple of 65536. See Limiting Size of Created Disk Temporary Files and Tables Overview for details. Called max_total_tmp_space_usage in only.
Commandline: --max-tmp-total-space-usage=num
Scope: Global
Dynamic: Yes
Data Type: numeric (bigint unsigned)
Default Value: 1099511627776
Range: 0 to 18446744073709551615 (blocks of 65536)
Introduced:

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

SSL/TLS System Variables

The system variables listed on this page relate to encrypting data during transfer between servers and clients using the Transport Layer Security (TLS) protocol. Often, the term Secure Sockets Layer (SSL) is used interchangeably with TLS, although strictly speaking the SSL protocol is the predecessor of TLS and is no longer considered secure.

For compatibility reasons, the TLS system variables in MariaDB still use the ssl_ prefix, but MariaDB only supports its more secure successors. For more information on SSL/TLS in MariaDB, see Secure Connections Overview.

Variables

`have_openssl`

Description: This variable shows whether the server is linked with rather than MariaDB's bundled TLS library, which might be or .
- I this system variable shows YES, the server is linked with OpenSSL.
- See for more information about which libraries are used on which platforms.

`have_ssl`

Description: This variable shows whether the server supports using to secure connections.
- If the value is YES, then the server supports TLS, and TLS is enabled.
- If the value is DISABLED, then the server supports TLS, but TLS is not enabled.

`ssl_ca`

Description: Defines a path to a PEM file that should contain one or more X509 certificates for trusted Certificate Authorities (CAs) to use for . This system variable requires that you use the absolute path, not a relative path. This system variable implies the option.
- See for more information.
Command line: --ssl-ca=file_name

`ssl_capath`

Description: Defines a path to a directory that contains one or more PEM files that should each contain one X509 certificate for a trusted Certificate Authority (CA) to use for . This system variable requires that you use the absolute path, not a relative path. The directory specified by this variable needs to be run through the command. This system variable implies the option.
- See for more information.
Command line: --ssl-capath=directory_name

`ssl_cert`

Description: Defines a path to the X509 certificate file to use for . This system variable requires that you use the absolute path, not a relative path. This system variable implies the option.
Command line: --ssl-cert=name
Scope: Global
Dynamic: No

`ssl_cipher`

Description: List of permitted ciphers or cipher suites to use for . Besides cipher names, if MariaDB was compiled with OpenSSL, this variable could be set to "SSLv3" or "TLSv1.2" to allow all SSLv3 or all TLSv1.2 ciphers. Note that the TLSv1.3 ciphers cannot be excluded when using OpenSSL, even by using this system variable. See for details. This system variable implies the option.
Command line: --ssl-cipher=name
Scope: Global

`ssl_crl`

Description: Defines a path to a PEM file that should contain one or more revoked X509 certificates to use for . This system variable requires that you use the absolute path, not a relative path.
- See for more information.
- This variable is only valid if the server was built with OpenSSL. If the server was built with or , then this variable is not supported. See for more information about which libraries are used on which platforms.

`ssl_crlpath`

Description: Defines a path to a directory that contains one or more PEM files that should each contain one revoked X509 certificate to use for . This system variable requires that you use the absolute path, not a relative path. The directory specified by this variable needs to be run through the command.
- See for more information.
- This variable is only supported if the server was built with OpenSSL. If the server was built with or , then this variable is not supported. See for more information about which libraries are used on which platforms.

`ssl_key`

Description: Defines a path to a private key file to use for . This system variable requires that you use the absolute path, not a relative path. This system variable implies the option.
Command line: --ssl-key=name
Scope: Global
Dynamic: No

`ssl_passphrase`

Description: SSL certificate key passphrase. Works similarly to the --passout/--passin openssl command-line parameters. The pass phrase value can be formatted as follows:
- pass:password — Provide the actual password.
- env:

`tls_version`

Description: This system variable accepts a comma-separated list (with no whitespaces) of TLS protocol versions. A TLS protocol version will only be enabled if it is present in this list. All other TLS protocol versions will not be permitted.
- See for more information.
Command line: --tls-version=value

`version_ssl_library`

Description: The version of the library that is being used. Note that the version returned by this system variable does not always necessarily correspond to the exact version of the OpenSSL package installed on the system. OpenSSL shared libraries tend to contain interfaces for multiple versions at once to allow for backward compatibility. Therefore, if the OpenSSL package installed on the system is newer than the OpenSSL version that the MariaDB server binary was built with, then the MariaDB server binary might use one of the interfaces for an older version.
- See for more information.
Scope: Global

Catalogs Overview

Catalogs are planned for an upcoming release, and don't yet appear in any current releases.

MariaDB catalogs will be a multi-tenancy feature where a single instance MariaDB server handles multiple independent tenants (customers), who have their own users, schemas etc. See MDEV-31542 "Add multi-tenancy catalogs to MariaDB" for details.

Background

For hosting providers, a common solution, to drive down cost, is to have one MariaDB server support several different customers by creating one named schema for each of them.

This has however a lot of limitations:

The user cannot have exactly the same schema(s) on the cloud as they have on premise.
The user cannot use multiple schemas.
The user cannot take a backup of all their data (not even with ). This is because the ‘mysql’ schema, which includes users, stored procedures etc. cannot be copied as its data is shared among all server users.
The user cannot access the or .

The other option is to have a MariaDB container for each tenant. The problem with this is that, because of the memory needed per container, one can only have a very limited number of tenants per computer.

The suggested solution is to solve all of the above and thus create a better multi-tenant database is to add support for catalogs to MariaDB.

The following picture shows the change:

By each user having their own catalog, they will get very close to the same user experience as if they would have the MariaDB server for themselves.

Catalogs make it possible for hosting providers to have 10-100x more 'not that active' database users on a server compared to having a container or MariaDB server per customer (which limits a 192G server to about 100 customers with a 1G InnoDB buffer each).

User Experience With Catalogs

Each user is assigned one catalog. The user can specify their catalog in their my.cnf file or as an argument to clients or when connecting to MariaDB server.
Users can of all their tables (including the ‘mysql’ database) and apply it on their own on premise MariaDB or to another ‘MariaDB catalog’ to duplicate their setup.
Each catalog has its own privilege system. This allows a MariaDB admin to create users independently in their catalog to users in any other catalog. This also implies that the catalog has to be part of the connect information as otherwise the server does not know which user table to use.

For the end user, the MariaDB server will act as a normal a standalone server, with the following differences:

When connecting to the server, a normal user must specify the catalog. If the connector software does not support catalogs, then the catalog should be specified in the database string. If the catalog is not specified, the 'def' catalog is assumed.
and can be configured to only be used with the catalog directory or a directory in it.
command is only for the 'catalog root users'
Replication (MASTER and SLAVE commands) are only for 'catalog root users'

New 'catalog root user'

The 'def' catalog is reserved to store permissions for 'catalog root users', which can access any catalog. * These are meant for admin users that need to do tasks like shutdown, upgrade, create/drop catalogs, managing primaries and replicas etc.
Only the ‘catalog root user’ can change to another catalog with ‘set catalog catalog_name’.
A normal user can do ‘set catalog current-catalog’. This will be needed to be able to execute a that includes this command.

New Storage Layout

MariaDB server will be able to run either on 'original mode', where the data layout is exactly as it was before, or on 'catalog' mode, with a new data layout:

When running with --use-catalogs, it will create the following new data structure:

data_directory/
- engine system data files
- system files
- replication files

The disk structure when not using catalogs is:

data_directory/
- engine system data files
- system files
- replication files

The above shows:

There is a 'mariadb' catalog that stores admin users that can access all catalogs, shutdown servers, create new catalogs etc. The 'system root' user uses this when connecting.
Each catalog has their own users, privilege tables, databases, error log and general logs

The MariaDB server will automatically start in catalog mode if it notices the new directory structure.

Catalog SQL Commands/Functions

;
CREATE CATALOG
ALTER CATALOG

Changes Needed in MariaDB Codebase

Client changes:

Add --catalog option to all standard MariaDB clients
Add support for looping over all existing catalogs to:

Changes to :

Allow one to create multiple catalogs at once: -–catalogs=”catalog1,catalog2”
Init MariaDB with catalog support: —use-catalogs

Changes to mariadb (mysql client):

Add support for 'USE CATALOG xxx’' (and later 'use database xxx').

Changes to mysql-test-run:

Add support of running tests with catalogs (normal tests are run without catalogs)

Changes to MariaDB server (See ):

Add support for 'catalog' in the connection string. For old clients, the user can specify the catalog as part of the database. If catalog is not specified, the 'def' catalog (like now) is assumed.
Add CATALOG() function that returns the current catalog.
Add ‘USE CATALOG xxx’
Add 'USE DATABASE xxx'

Notes:

The storage handler calls will probably not be changed. The storage engine will get the catalog name as part of the database name (catalog/database).
We don't need a 'catalog' column for tables in the 'mysql' schema (like mysql.proc) as these are stored per catalog.

Some Implementation Ideas

Instead of sending a catalog string to function, use a pointer to the global catalog object. Do the same later for databases. This allows use to precompute things like 'filename' for catalogs and databases and we don't have to do this for every table open. It also allows us to later support logging information at a catalog and database level.
Don't take a MDL lock for the catalog for each table. The metadata lock for the catalog will be taken when a user logs in or changes catalog.
Add system variables ‘current_catalog’ and ‘current_database’ and allow users to change these.
Add support for ‘catalog ports’ that are connected to catalog. This allows users to connect to a specific catalog from any client software.

Limitations (in addition to limitations listed in “User experience with catalogs”)

Database names cannot contain ‘.’ when connecting from clients without the new catalog connect option.
One cannot refer to other catalogs in triggers, stored procedures, events etc. This is because a transaction cannot span catalogs.
Only the catalog root user can use mariadb-backup. This is a normal restriction as one has to be system root to be able to use mariadb-backup.
Events are global (to save resources). Catalog users can enable/disable events for their catalog.

Stage 2 (not in first release)

Support usage statistics per catalog and whole server (the last for the ‘catalog root user’). This allows the DBA to see the number of queries, type of queries etc. Some ‘system’ and ‘global innodb’ statistics will only be shown globally (number of open files, number of sync calls etc).
Support a my.cnf file in each catalog directory to handle catalog (customer) unique defaults.
Add quotas per catalog for tables and temporary files.
Add more support to limit users from overusing resources (cpu, tables, databases, number of connections etc)

Stage 3

Allow users to manage their own replication stream (maybe?).
Allow users to have different options for the S3 engine
More things will be added later.

Appendix

Legacy Connector Support

SQLALchemy test:

The following tests ensured that inside the server (mysql_change_db), the “catalog/test” was picked up as the database.

PHP PDO test:

PHP mysqli test:

Nodejs test:

(need to map out a few other connectors here to make sure it’s supported well in this form).

Ref:

Migration of Existing MariaDB Original Mode to the New Catalog Layout

As shared hosting services have a naming scheme from user/schema to database name in MariaDB, to provide a migration to the new catalog layout, the following steps will be required:

Use to dump the original data
On the new server execute:
mariadb –catalog catalog_name < dump_file

This is needed as InnoDB needs to know where the new files are located.

Migration of One Catalog User to Another MariaDB Server

Create a migration tool set / procedure that does the following

Execute for all tables in a catalog.
Take a copy of the catalog directory
Copy the data to a new catalog directory to the new server
Run on each InnoDB table

Note that for partitioned tables the process will be a bit more complex, see above link.

This procedure will be a bit easier after an in-the-works patch for InnoDB related to IMPORT will be pushed. (Should happen before we start on the catalog project)

Other Things

Drizzle’s default catalog was called "local". MariaDB’s default will be called ‘def’, as this is what we already have as the default catalog in information_schema, in current connectors and other places.
CONNECT engine will need testing against catalogs and maybe a small code change to support them. It could also be a way to join from one catalog to another.

File Key Management Encryption Plugin

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.

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

Overview

The File Key Management plugin is the key management and encryption plugin for users who want to use data-at-rest encryption. Some of the plugin's primary features are:

It reads encryption keys from a plain-text key file.
As an extra protection mechanism, the plain-text key file can be encrypted.
It supports multiple encryption keys.
It supports key rotation with MariaDB Enterprise Server from MariaDB Enterprise Server 11.8.

It can also serve as an example and as a starting point when developing a key management and encryption plugin with the .

Installing the File Key Management Plugin's Package

The File Key Management plugin is included in MariaDB packages as the file_key_management.so or file_key_management.dll shared library. The shared library is in the main server package, so no additional package installations are necessary. The plug-in must be installed into MariaDB however as follows.

Installing the Plugin

Although the plugin's shared library is distributed with MariaDB by default, the plugin is not actually installed by MariaDB by default. The plugin can be installed by providing the or the options. This can be specified as a command-line argument to or it can be specified in a relevant server in an . For example:

Uninstalling the Plugin

Before you uninstall the plugin, you should ensure that is completely disabled, and that MariaDB no longer needs the plugin to decrypt tables or other files.

You can uninstall the plugin dynamically by executing or . For example:

If you installed the plugin by providing the or the options in a relevant server in an , then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Creating the Key File

In order to encrypt your tables with encryption keys using the File Key Management plugin, create the file containing the encryption keys. File name and location don't matter; see in the following what configuration is needed.

For each encryption key, the file contains these options, separated by a semicolon:

The key identifier (format: 32-bit integer)
The key version (optional, and only available as of Enterprise Server 11.8)
The key itself (format: hex-encoded)

Entries look like this:

You can also optionally encrypt the key file to make it less accessible from the file system. That is explained further in the section below.

The File Key Management plugin uses to encrypt data. It supports 128-bit, 192-bit, and 256-bit encryption keys, just like the plugin does.

Generate random encryption keys using the command. To create a random 256-bit (32-byte) encryption key, run the following command:

The key file needs to have a key identifier for each encryption key added to the beginning of each line. Key identifiers do not have to be contiguous. For example, to append three new encryption keys to a new key file, issue this command:

The resulting key file looks like this:

The key identifiers give you a way to reference the encryption keys from MariaDB. In the example above, you could reference these encryption keys using the key identifiers 1, 2 or 100 with the table option or with system variables such as . You do not necessarily need multiple encryption keys; an encryption key with the key identifier 1 is the only mandatory one.

If the key file is left unencrypted, the File Key Management plugin only requires the system variable to be configured.

This system variable can be specified as a command-line argument to mariadbd , or it can be specified in a server of an , like this:

Encrypting the Key File

This step is optional, but highly recommended.

If you use an unencrypted key file, keys are stored in plain text on your system, posing a security risk. It's recommended to encrypt the key file, with these hints in mind:

MariaDB only supports the mode of .
The encryption key size can be 128-bits, 192-bits, or 256-bits.
The encryption key is created from the hash of the encryption password.
The encryption password has a maximum length of 256 characters.

Generate a random encryption password using the command. To create a random 256 character encryption password, execute the following:

Encrypt the key file using the command. To encrypt the key file with the encryption password created in the previous step, execute, for example, one of the following commands:

The resulting keys.enc file is the encrypted version of keys.txt file. Delete the unencrypted key file.

Having the key file encrypted requires both the and the system variables to be configured.

The file_key_management_filekey variable can be provided in two forms:

As a plain-text encryption password. This is not recommended, since the plain-text encryption password would be visible in the output of the statement.
Prefixed with FILE:, it can be a path to a file that contains the plain-text encryption password.

These variables can be specified as command-line arguments to mariadbd, or they can be specified in a relevant server in an :

Choosing an Encryption Algorithm

The File Key Management plugin currently supports two encryption algorithms for encrypting data: AES_CBC and AES_CTR. Both of these algorithms use in different modes. AES uses 128-bit blocks, and supports 128-bit, 192-bit, and 256-bit keys. The modes are:

The AES_CBC mode uses AES in the mode.
The AES_CTR mode uses AES in two slightly different modes in different contexts. When encrypting tablespace pages (such as pages in InnoDB, XtraDB, and Aria tables), it uses AES in the mode. When encrypting temporary files (where the cipher text is allowed to be larger than the plain text), it uses AES in the authenticated .

The recommended algorithm is AES_CTR, but this algorithm is only available when MariaDB is built with . If the server is built with then this algorithm is not available. See for more information about which libraries are used on which platforms.

Configuring the Encryption Algorithm

The encryption algorithm can be configured by setting the system variable.

This system variable can be set to one of the following values:

System Variable Value

Description

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

Note that the option prefix is specified. This option prefix is used in case the plugin hasn't been installed yet.

Note that this variable does not affect the algorithm that MariaDB uses to decrypt the key file. This variable only affects the encryption algorithm that MariaDB uses to encrypt and decrypt data. The only algorithm that MariaDB currently supports to encrypt the key file is mode of .

Using the File Key Management Plugin

Once the File Key Management Plugin is enabled, you can use it by creating an encrypted table:

Now, table t will be encrypted using the encryption key from the key file. For more information on how to use encryption, see .

Using Multiple Encryption Keys

The File Key Management Plugin supports . Each encryption key can be defined with a different 32-bit integer as a key identifier.

When , the key that is used to encrypt tables . When , the key that is used to encrypt tables .

Key Rotation

The plugin supports key rotation and allows an optional key version in the key file. The keys can be rotated using the FLUSH FILE_KEY_MANAGEMENT_KEYS statement, without needing to restart the server. The plugin remains compatible with old key file format, and when version is not specified, it defaults to version 1.

Generation of New Key Versions

How would new key versions be generated?

The plugin doesn't generate any encryption keys itself, and it doesn't have a backend KMS to generate encryption keys for it either.

Any encryption keys need to be generated by the user with external tools, such as OpenSSL. For example:

Keys need to be manually saved to the key file. See .

The format of the key file is simplistic. It stores encryption keys in a plain-text file.

Versions

Version

Status

Introduced

System Variables

`file_key_management_encryption_algorithm`

This system variable is used to determine which algorithm the plugin will use to encrypt data.
- The recommended algorithm is AES_CTR, but this algorithm is only available when MariaDB is built with . If the server is built with then this algorithm is not available. See for more information about which libraries are used on which platforms.
Command line: --file-key-management-encryption-algorithm=value

`file_key_management_digest`

Specifies the digest function to use in key derivation of the key used for decrypting the key file.
Command line: --file-key-management-digest=value
Scope: Global
Dynamic: No

`file_key_management_filekey`

Used to determine the encryption password that is used to decrypt the key file defined by .
- If this system variable's value is prefixed with FILE:, then it is interpreted as a path to a file that contains the plain-text encryption password.
- If this system variable's value is not prefixed with FILE:, then it is interpreted as the plain-text encryption password. However, this is not recommended.

`file_key_management_filename`

Used to determine the path to the file that contains the encryption keys. If is set, this file can be encrypted with mode of .
Command line: --file-key-management-filename=value
Scope: Global

`file_key_management_use_pbkdf2`

Specifies whether pbkdf2 is used in key derivation, and if so, how many iterations.
Command line: --file-key-management-use-pbkdf2=number
Scope: Global
Dynamic: No

Options

`file_key_management`

Controls how the server should treat the plugin when the server starts up.
- Valid values are:
  - OFF - Disables the plugin without removing it from the table.

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

Amazon Web Services (AWS) Key Management Service (KMS) Encryption Plugin Advanced Usage

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.

Load the IAM console at.
Click "Encryption Keys" in the left-hand sidebar.
Click the name of your encryption key to view its details.
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.

Click "Save Changes".
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.

Load the IAM console at.
Click "Encryption Keys" in the left-hand sidebar.
Click the name of your encryption key to view its details.
Click the link labeled "Switch to policy view", to the right of the heading of the "Key Policy" section.

Click "Save Changes".
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.

Click "Users" in the left-hand sidebar.
Click the name of your user.
Click the "Security Credentials" tab.
In the "Sign-In Credentials" section, click the "Manage MFA Device" button.

Now, set up the wrapper program.

Copy the iam-kms-wrapper file to /usr/local/bin/, and ensure that it is executable.
Create a drop-in systemd config file in /etc/systemd/system/mariadb.service.d/:

Execute systemctl daemon-reload.
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.

Load the IAM console at.
Click "Users" in the left-hand sidebar.
Click "Create New Users".
Enter a new user name. (The examples will use "MDBEncAdmin".)

Click "Close".
Click "Close" again if prompted.
Click the name of your new user to open the details view.
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.

Click "Encryption Keys" in the left-hand sidebar.
Click the name of your key to open the details view.
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.)
Create a new item in the Statement array with this structure:

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

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.

Load the CloudTrail console at.
If you've never used CloudTrail before, click "Get Started Now".
Enter a value for "trail name". This example uses "mariadb-encryption-key".
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.

Load the CloudTrail console at.
Click "Trails" in the left-hand navigation sidebar.
Click the name of your trail to open the Configuration view.
In the "CloudWatch Logs" section, click "Configure".

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

Open.
Make sure the region in the console (look in the upper-right corner) is the same as the region where you created your key!
Click "Get Started" is prompted.
Click "Events" in the left-hand sidebar.

Now, configure CloudWatch and create an Event Rule.

Open.
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!
Click "Events" in the left-hand sidebar.
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}

Security Vulnerabilities Fixed in Oracle MySQL That Did Not Exist in MariaDB

About

CVE stands for "Common Vulnerabilities and Exposures". It is a publicly available and free to use database of known software vulnerabilities maintained at

CPU stands for "Critical Patch Update". Oracle publishes Critical Patch Update Advisories four times a year, on the Tuesday closest to the 17th day of January, April, July and October. MySQL vulnerabilities are included in these CPU Advisories.

Some vulnerabilities found in MySQL apply to MariaDB as well, they are listed on the Security page.

Other vulnerabilities found in MySQL do not apply to MariaDB.

This page lists all CVEs that were fixed in MySQL and mentioned in Oracle CPU Advisories, but that — to the best of our knowledge — were never present in MariaDB.

Full List of CVEs Fixed in Oracle MySQL That Never Existed in MariaDB

Not a vulnerability:

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

Security

Securing MariaDB

Running mariadbd as root

Encryption

Data-in-Transit Encryption

Certificate Creation with OpenSSL

Certificate Creation

Requiring TLS on MariaDB Server

Overview

Using TLSv1.3

See Also

Data-at-Rest Encryption

Why Encrypt MariaDB Data?

When Does Encryption Help to Protect Your Data?

When is Encryption No Help?

What to Encrypt?

How to Handle Key Management?

Aria Encryption

Aria Encryption Overview

Basic Configuration

Determining Whether a Table is Encrypted

Encryption and the Aria Log

Aria Disabling Encryption

Disabling Encryption on User-created Tables

Aria Encryption Keys

Encryption Keys

Key Rotation

InnoDB Encryption

Key Management and Encryption Plugins

Disabling Data-at-Rest Encryption for Standalone Servers

Prerequisites

Related Documentation

Decrypt Aria Tables

Decrypt InnoDB Tables

Decrypting a Table

Decrypting All Tables in a Schema

Verifying Decryption

Decrypt InnoDB Redo Logs

Decrypt Binary Logs

Approaches to decrypt binary logs

Using mysqlbinlog to decrypt

Decrypting compressed or rotated logs

Decrypt local binlog to file:

Decrypt and decode row events verbosely:

Decrypt from a compressed backup:

Uninstall Key Management Plugins

User Account Management

Roles

System`s Users, Roles, and Privileges

System Users

Incrementing of the access_denied_errors status variable

See Also

Catalogs

Starting with Catalogs

Background

Initializing a New Server with Catalog Support

Adding More Catalogs to a Running Server

Creating Catalogs with CREATE CATALOG

Creating Catalogs with mariadb_install_db

See Also

Catalog-Specific Functions and Variables

Catalog Functions

catalog()

returns the name of the current catalog.`

Catalog Variables

@@catalogs

Catalog Status Variables

Connecting to a Server Configured for Catalogs

CREATE CATALOG

Syntax

Description

SHOW CREATE CATALOG

Syntax

Description

SHOW CATALOGS

Syntax

Description

Examples

See Also

USE CATALOG

Using `mysqlbinlog` to decrypt

`max_tmp_session_space_usage`

`max_tmp_total_space_usage`