Running MariaDB and MySQL securely: Network, users and backups

The database rarely needs to face the whole internet

If the application and database share a server, a local socket or loopback connection is often enough. Across separate systems, expose the database port only to the application network, a private network or a VPN. A firewall rule for one trusted source is much safer than a public allow rule.

Use one account per application

Do not put an administrative account into a web application. Create a dedicated database user with access only to the required schema and actions. Reporting, migrations and backups can use separate accounts. A stolen credential then has a much smaller blast radius.

Transport encryption and secrets

Connections across shared or untrusted networks should use TLS and validate the certificate. Keep passwords in a secret store or tightly readable configuration, not source code, container images or tickets. Define a credential-rotation procedure before an incident forces you to invent one.

Create consistent backups

Copying a live data directory does not automatically produce a consistent backup. Use logical exports, database-aware backup tools or correctly coordinated snapshots. Encrypt off-server copies and test recovery including users, character sets and application migrations.

Test updates realistically

• Track supported database releases and security updates.
• Monitor slow queries, connections and memory use.
• Test schema changes against an anonymized copy first.
• Document emergency access without writing passwords into the document.

Our guide to remote MariaDB and MySQL access covers the mechanics. Restrict that access to trusted source networks.