Your MariaDB Server Looks Secure… But Is It Really?

If there is one thing years of production database support have taught us, it is this:

Most security incidents don’t happen because MariaDB lacks security features. They happen because nobody verifies whether those features are still configured correctly after the server goes live.

That may sound surprising, especially when modern MariaDB versions provide authentication plugins, TLS support, encryption at rest, auditing capabilities, and role-based access control.

The problem is rarely the feature itself.

The problem is what happens six months later.

An application migration requires temporary administrative privileges. The migration completes, but the privileges remain.

A vendor support account is created for troubleshooting and nobody remembers removing it after the project ends.

SSL is enabled on the server, so everyone assumes network traffic is encrypted, yet every application continues using unencrypted sessions because the client configuration was never updated.

Nothing breaks.

The application keeps running.

Replication stays healthy.

Monitoring dashboards remain green.

From an operational perspective, the server looks perfectly healthy.

Then someone performs a security audit.

Over the years, our team has participated in many production health checks and security reviews. Although every customer environment is different, one pattern repeats itself surprisingly often.

The biggest risks are usually not sophisticated attacks.

They are forgotten configurations that quietly survive years of upgrades, migrations, application releases, and infrastructure changes.

That is exactly why every production security audit we perform follows a simple philosophy:

Don’t assume anything. Validate everything.

Every Security Audit Starts With a Simple Question

When people think about database security, they usually imagine encryption certificates, audit plugins, or vulnerability scanners.

Ironically, that is almost never where we start.

The first question we ask is much simpler.

Who can actually log in to this database?

It sounds obvious, but this single question has uncovered more security issues than many automated scanning tools.

The first command we normally execute is:

SELECT User, Host
FROM mysql.user
ORDER BY User;

The output is often more interesting than people expect.

You can almost read the server’s history from this table.Old migration accounts,Vendor support users,Temporary developer logins,Legacy applications that no longer exist and service accounts nobody has reviewed for years.

One production environment we audited contained more than forty database users.

Only fourteen of them were still being used.Nobody had intentionally left the others behind.They simply survived every infrastructure change because deleting them felt risky.

Unfortunately, every unnecessary account increases the attack surface.

A production database should not contain users simply because “they might be needed someday.”

If an account no longer serves a business purpose, it should not exist.

That principle sounds simple, yet it remains one of the most common findings during security reviews.

The Next Question Is Even More Important

Finding old users is only half of the story.

The more important question is:

What can those users actually do?

This is where security reviews become interesting.Many application teams believe their accounts have limited permissions because that was the original design.Production systems rarely stay that simple.

Applications evolve.

Emergency fixes happen.

Migrations require temporary permissions.

Developers request additional access for troubleshooting.

Months later, nobody remembers removing those permissions.

Whenever we investigate application accounts, one command almost always becomes part of the discussion:

SHOW GRANTS FOR 'app_user'@'localhost';

The SQL itself is straightforward.

Interpreting the result is where experience matters.

Does a reporting application really need DELETE permission?

Should an application that writes to a single schema have privileges across every database?

Why does a service account still have administrative capabilities after the migration finished last year?

One thing we have learned over time is that temporary production fixes have a habit of becoming permanent configurations.

The safest privilege is the one that was never granted unnecessarily.

That is why every production review should challenge every privilege rather than assuming it still has a valid purpose.

Roles Make Administration Easier, But They Also Hide Problems

Roles are one of the best features for managing privileges at scale.Instead of granting identical permissions to dozens of users individually, DBAs can manage everything through a shared role.Operationally, that is a huge improvement.

Security-wise, however, roles require periodic review.

Over time, it is common to see additional permissions quietly added to an existing role because “another application also needs this access.”Months later, nobody remembers why the role contains those permissions.

The role becomes a collection of historical decisions instead of a carefully designed security model.During audits, we therefore review both direct user grants and inherited privileges.

If your MariaDB version supports PUBLIC grants, those should also be reviewed carefully, although they are uncommon in most production environments.

The lesson here is simple:

Never review users without reviewing the mechanisms that grant them privileges.

Otherwise, the real source of access may remain hidden.

The Security Check That Almost Everyone Forgets

There is one topic that repeatedly surprises developers and junior DBAs.

DEFINER objects.

Views, stored procedures, triggers, and functions can execute with the privileges of the account defined during creation.

That sounds harmless until the underlying account changes.One customer contacted us after a routine upgrade because several reports had suddenly stopped working.

The application code had not changed.

The SQL had not changed.

The upgrade completed successfully.

The real problem was a DEFINER account that had been deleted months earlier.

The issue existed long before the upgrade.

The upgrade simply exposed it.

Since then, reviewing DEFINER objects has become a mandatory step in every security audit we perform.

A quick review can be done using:

SELECT DEFINER,
       ROUTINE_NAME
FROM information_schema.ROUTINES;

Objects owned by obsolete administrative accounts should always be reviewed.

This is not only a security concern but also a maintainability concern.

Forgotten DEFINER accounts have caused countless production surprises after migrations and upgrades.

And those surprises almost always happen at the worst possible time.

When SSL Is Enabled but Nothing Is Actually Encrypted

Once user accounts and privileges look reasonable, many DBAs naturally move toward encryption.

At this point, most people become confident.

“We already enabled SSL.”

I’ve heard that sentence many times during customer audits.

In fact, I remember one production environment where the infrastructure team proudly explained that the database server was fully secured because SSL support had been configured months earlier.

Everything looked correct.

The certificates existed.

The server started without errors.

Even this command returned a reassuring answer:

SHOW VARIABLES LIKE 'have_ssl';

The output showed YES.

If the audit had stopped there, everyone would have left the meeting believing that application traffic was encrypted.

Fortunately, production DBA work teaches you to ask one more question.

“Is the application actually using TLS?”

There is a huge difference between a server that supports SSL and clients that actively establish encrypted sessions.

That is why the next command we usually execute is:

SHOW STATUS LIKE 'Ssl_cipher';

If the value is empty for active sessions, the applications are still communicating without encryption.

The server supports TLS.The clients simply are not using it.

That discovery surprises many teams because they assume enabling SSL on the server automatically encrypts every connection.

It doesn’t.

The client must also negotiate an encrypted session.Otherwise, credentials and application traffic may still travel across the network in plaintext.

For internet-facing environments this is obviously dangerous, but even inside private networks it deserves attention.

Modern data centers contain many interconnected systems, and internal traffic should never be considered automatically trustworthy.

Whenever possible, application accounts that should always use encrypted communication can be restricted accordingly.

ALTER USER 'app_user'@'%' REQUIRE SSL;

Of course, enabling SSL should never be the final step.Reconnect the application and verify that encrypted sessions are actually being established.

A surprising number of production systems fail this simple validation.And that leads to another lesson we repeatedly learn during security audits:

Configuration is not proof. Validation is.

Encryption Solves One Problem but Creates Another

After reviewing network encryption, the discussion usually shifts toward data-at-rest encryption.

Most organizations understand why this matters.

Disks fail.

Storage snapshots are copied.

Backup files move between environments.

Cloud volumes are detached and reattached.

Protecting stored data has become an important part of production security.

MariaDB provides encryption capabilities for InnoDB tablespaces, redo logs, temporary files and other storage components.

Enabling encryption is usually straightforward.Managing it correctly is where things become interesting.

I once asked a customer where their encryption keys were stored.

The room became very quiet.The database was encrypted.The backups were encrypted.

But nobody could confidently explain the recovery process if the key management server disappeared.

That conversation completely changed the focus of the audit.

Because encryption is not only about protecting data.

It is equally about recovering that data when disaster strikes.

A quick review usually starts with:

SHOW VARIABLES LIKE 'innodb_encrypt%';
SHOW VARIABLES LIKE 'encrypt_tmp_files';

These variables provide an initial indication of whether encryption-related features have been configured.

Who manages the encryption keys?

Are the keys backed up?

Has recovery ever been tested?

What happens if the key management server becomes unavailable?

Those questions rarely appear in documentation, yet they determine whether encryption becomes a security feature or a future recovery problem.

One statement has stayed with me throughout many production engagements:

An encrypted database without recoverable keys is just another unavailable database.

That is why encryption projects should always include backup validation and disaster recovery testing.

Otherwise, organizations may unknowingly trade one risk for another.

The Files Nobody Thinks About

Ask someone where production data is stored and they will almost certainly answer:

“In the tables.”

Technically they are correct.

Operationally they are incomplete.

Production databases generate many other files that deserve equal attention.

Redo logs.

Binary logs.

Temporary files.

Relay logs.

Storage snapshots.

These files often contain enough information to reveal business activity, transactional history or sensitive operational details.Unfortunately, they receive far less attention than the primary tables themselves.

Binary logs deserve special attention because they support both replication and point-in-time recovery.

They are among the most valuable files on a production server.

During one audit, we found encrypted tables but completely unencrypted binary logs being copied to another storage location every hour.

The customer had invested heavily in protecting application data while unintentionally exposing transactional history elsewhere.

That experience reinforced another lesson:

Database security should protect the entire data lifecycle, not just the tables users query every day.

When reviewing storage protection, we therefore verify whether redo logs, binary logs and temporary files receive the same level of attention as primary database files.

It is surprisingly common to find that they do not.

Auditing Is Only Useful If Someone Can Read It

At some point during every security discussion, someone asks whether database auditing has been enabled.

That sounds like a simple question.It rarely has a simple answer.

Some environments log almost nothing.Others log everything.Neither approach is particularly helpful.

A production audit log should answer practical questions.

Who connected?

Who changed privileges?

Who modified the schema?

Who created a new account?

Who dropped an object?

The goal is not to collect every SQL statement ever executed.

The goal is to collect enough information to reconstruct an incident without overwhelming storage or operations teams.

MariaDB provides auditing capabilities through the server audit plugin, but enabling the plugin should only be the beginning.

The configuration deserves equal attention.

Which events are logged?

How quickly will audit files grow?

How long are they retained?

Who reviews them?

Are they being rotated?

A useful audit trail should support investigations rather than becoming another forgotten directory consuming disk space.

Over the years, we have found that many organizations enable auditing simply to satisfy compliance requirements.

Very few regularly validate whether those logs would actually help during a security incident.

The difference is significant.

One satisfies an auditor.

The other helps a DBA understand what really happened.

And those are not always the same thing.

Replication Security: The Silent Risk That Most Teams Never Review

If there is one part of MariaDB security that gets the least attention, it is replication.

Most administrators spend hours tuning replication performance, monitoring lag, or validating failover procedures.

Very few spend time asking a much simpler question:

“How secure is the replication itself?”

I still remember a customer who asked us to review their disaster recovery architecture.

Replication was working perfectly.Lag was almost zero.Automatic failover had been tested successfully.

From an availability perspective, the environment looked excellent.

Then we looked at the replication user.

It had far more privileges than replication required.

Even worse, it could connect from %, meaning any host capable of reaching the server could attempt to authenticate using that account.

Nobody had questioned it because replication had been stable for years.

The focus had always been availability.

Security had quietly taken a back seat.

That experience taught us something important.

A healthy replication topology does not automatically mean a secure replication topology.

The first thing we usually review is the replication account itself.

Does it really have only the permissions required for replication?

Can it connect only from the intended replica servers?

Has its password ever been rotated?

Is it being used anywhere else?

These questions often reveal more than expected.

Replication users should never become “general-purpose service accounts.”

They should exist for one purpose and one purpose only.

Another area that deserves attention is encrypted replication traffic.

Many organizations secure application traffic but forget that replication traffic is also transferring production data between servers.

If replication crosses networks, especially across data centers or cloud regions, encryption should be treated as equally important.

The replication channel itself is part of your production environment.

Protect it the same way you protect application connections.

One small security review of replication today may prevent a much larger investigation tomorrow.

Security Doesn’t End Inside MariaDB

One mistake we occasionally see during customer audits is treating database security as if it exists entirely inside the database engine.

It doesn’t.

A perfectly configured MariaDB server can still become vulnerable because of poor operating system practices.

Imagine spending weeks implementing least privilege, TLS, encryption, and auditing, only to discover that the backup directory is readable by every user on the server.

Or that SSH access has been shared among multiple administrators using the same credentials.

Or that the MariaDB data directory has unnecessarily broad filesystem permissions.

These issues rarely appear in database documentation because they belong to the operating system.

From a production DBA perspective, however, they are just as important.

Whenever we perform a security review, we always extend the audit beyond SQL configuration.

We review:

• File ownership of the MariaDB data directory
• Backup storage permissions
• Log directory permissions
• SSH access policies
• Firewall configuration
• Service account ownership
• SELinux or AppArmor policies where applicable

Many database breaches begin outside the database itself.

Database security and operating system security should never be treated as separate conversations.

The Upgrade Nobody Wants to Schedule

There is one sentence every DBA has heard.

“Let’s postpone the upgrade. Everything is working fine.”

From a business perspective, that sounds reasonable.

From a security perspective, it should make every DBA uncomfortable.

Attackers read release notes too.Every new MariaDB release fixes bugs, improves stability, and occasionally closes security vulnerabilities that already exist in older deployments.

Continuing to run unsupported versions simply because they appear stable creates unnecessary risk.

Whenever we audit a production environment, one of the simplest commands we execute is:

SELECT VERSION();

The command takes less than a second.

The discussion that follows can last an hour.

Is this version still supported?

Is it part of a Long-Term Support release?

Have important security fixes already been published?

Will the backup software remain compatible after an upgrade?

Will the connectors used by the applications continue to work correctly?

These questions matter far more than simply knowing the version number.

Patch management is often viewed as a maintenance activity.

In reality, it is one of the most effective security controls available to a DBA.Of course, upgrades should never be rushed.

Every production upgrade deserves proper testing.Replication should be validated.

Backup and restore procedures should be tested.

Application connectivity should be confirmed.

Encryption and authentication should continue to behave as expected.

A successful upgrade is not merely one that completes.It is one where the business notices nothing at all.

Final Thoughts

After participating in numerous production security assessments, one observation has remained remarkably consistent.

MariaDB security is rarely about enabling more features. It is about validating the features that are already there.

A server may support TLS but still transmit plaintext traffic.

Encrypted tables may exist while backup copies remain unprotected.

Audit logging may be enabled without anyone reviewing the logs.

Replication may work flawlessly while using an over-privileged account.

The danger lies in assuming that configuration equals protection.

It doesn’t.

Protection comes from continuous validation.

If there is one message we hope every DBA takes away from this article, it is this:

Never trust yesterday’s security decisions without reviewing them today.

The strongest production environments are not the ones with the most security settings enabled.

They are the ones where DBAs continue asking simple questions long after the server has gone live.

Who can connect?

What can they do?

Is the data really protected?

Can we recover if something goes wrong?

Those questions may seem ordinary.

But in our experience, they are exactly the questions that prevent extraordinary problems.

And perhaps that is the most valuable lesson production support teaches every DBA: security is not a feature you configure once—it is a habit you practice continuously.