Best practices for securing, backing up, and restoring MariaDB

Cyber Protect Cloud
for service providers

If your organization uses MariaDB to manage your databases as an alternative to MySQL, you probably already know that you have many different options when it comes to securing and backing up your databases or restoring data if you ever experience an issue. However, it’s not always clear what choices you should make to maximize your security and best protect your company’s assets.

To help, this article highlights many best practices and specific recommendations for critical parts of your MariaDB configuration. It will also offer a closer look at the best solution to protect mission-critical data — a well-designed combination of these configuration best practices as well as the use of an application-aware, granular backup and restore system.

Configuration options and considerations

There are many different configuration options to consider as you set up and maintain MariaDB. The following sections will discuss authentication, passwords, networking, using MariaDB as a Docker image, and additional considerations for future MariaDB upgrades.

Authenticating without passwords

If your organization prefers to let users authenticate without passwords, you have a few different options depending on your operating system (Linus or Windows).

1.       Linux: In Linux, use MariaDB’s Unix_socket authentication plugin. This enables users to log in to MariaDB via the Unix socket, but only if the user’s name matches the system user.

Additionally, the root user is effectively configured to use the Unix socket authentication by default, an important advantage that prevents the accidental granting of root access to outside connections via a listening port.

2.       Windows: In Windows environments, you can use the named pipe plugin, which provides similar functionality for Windows-based deployments. This plugin allows the user to use operating system credentials when connecting to MariaDB via named pipe on Windows.

Multiple authentication methods

MariaDB allows for multiple authentication methods per user. This provides greater flexibility where users can authenticate using Unix socket, or if that doesn’t work, to use a password.

Password complexity plugin

Additionally, you can install the cracklib-password-check plugin to make sure MariaDB users create complex, non-trivial passwords at all times — an important step in maximizing security.  

Thoughts on storing passwords

If you must store passwords, we suggest you follow these specific best practices:

·       Never store passwords in clear text.

·       Make sure server passwords are encrypted. Note that the default in MariaDB is sha 1, which is no longer considered secure.

·       Additionally, ed_25519 is not set by default but is highly recommended.

Secure MariaDB networking

If your deployment set-up allows it, it may be better to run with skip-networking on the server with Unix socket whenever possible. Yet if this is not possible, use specific hostnames for users to limit externally accepted IP addresses. Note that only connections coming from will be accepted.

Create application-specific users

One scenario to note: The default deployment is to allow the application root access. Not only is this not necessary but it’s not a good idea since it may lead to vulnerabilities in the future. For example, in the case of a security bug in the application, the whole database server can be compromised. Instead, you should create dedicated users and only grant rights as needed using the least privilege principle.

In the case of an untrusted network

In the case that you’re dealing with an untrusted network, make sure that client-server communications are encrypted. This requires SSL certificates for the server to be generated and configured. (Use the CREATE USER command for information on the specifying certificates.)

All of this helps you create a user that can connect locally without SSL required. At the same time, make sure to require SSL when connecting from an outside host.

MariaDB as a Docker image

MariaDB is also shipped as a Docker image. This means there are many ways to set up the server, including sharing the Unix socket via a volume or exposing the TCP/IP port (3306).

For useful environment variables, you can use MARIADB_ROOT_PASSWORD/MYSQL_ROOT_ PASSWORD.

MariaDB upgrades

With MariaDB, backwards compatibility is maintained across all versions. Features are rarely dropped, and when they are, it’s usually related to conflicts with the MySQL standard.  

You should do all you can to ensure the MariaDB server is kept up to date. This is important because MariaDB releases security fixes as soon as possible after Oracle’s MySQL release (usually 1–2 days), so updating the server will make sure you have access to all these patches as soon as possible.

Overview of the Acronis solution

The best solution for protecting your valuable data and databases is a partnership between application best practices and an application-aware, granular backup and restore solution.

Acronis delivers with a single-pass backup for MySQL and MariaDB workloads that enables complete recovery as well as granular recovery of MySQL / MariaDB databases and tables if data ever becomes corrupted. The solution performs backups at the server, VM, database, or even individual table levels. This becomes an important advantage for users running multiple websites or applications on a single instance.

Hosting and cloud service providers will also appreciate that the Acronis Cyber Protect Cloud solution is fully configurable and deployable via the control panels and automation systems they use now — cPanel  Plesk, DirectAdmin, WHMCS and more.

Combining cybersecurity, data protection and backup ensures better protection requiring fewer resources — critical to avoiding breaches and to ensure safe and malware-free recoveries. To learn more about the advantages of using Acronis Cyber Cloud as a MSP platform, visit our solutions for service providers page today.

More from Acronis