A scoped MariaDB security audit by senior DBAs against published control sets. We review privileges, authentication, TLS, data-at-rest encryption, server_audit logging, CVE posture, and Galera and MaxScale configuration. Every finding maps directly to compliance standards with clear severity and remediation paths.
Reviewed on Clutch 4.9 Verified client reviews.avif)
Privileges, encryption, audit logging, and the Galera and MaxScale layer. Each is reviewed by a DBA who can explain why it is a risk in your architecture: not a checkbox that passed.
The most common critical finding we write is not exotic. It is a set of accounts with privileges nobody can account for, created for a migration or a batch job years ago, still live, still holding SUPER or ALL PRIVILEGES, and frequently shared.
We produce a privilege matrix: every account, every grant, where it connects from, when it was last used, and which of them a reviewer would have to defend. Alongside it we review authentication posture: unix_socket for local admin, ed25519 over the legacy password plugin, and PAM, LDAP or GSSAPI integration where your identity provider expects it.
In transit: whether TLS is available is not the question: whether it is enforced is. We check require_secure_transport, per-account TLS requirements, certificate validity and rotation, cipher policy, and whether replication and Galera traffic is encrypted rather than only client traffic.
At rest: which tablespaces are encrypted, whether binary logs and the redo log are covered, where the keys live, and whether the key management plugin (file_key_management, AWS KMS or HashiCorp Vault) gives you the key custody separation your framework requires. We state plainly what MariaDB encryption at rest does not cover, because that gap is what an assessor will find.
Most estates we review either have no audit logging or have server_audit loaded with a default event set that records less than the framework requires. The gap is usually discovered during an assessment rather than before one.
We review whether the plugin is loaded, what SERVER_AUDIT_EVENTS is set to, whether that event set covers what your framework asks for, whether logs leave the host, whether rotation is silently discarding evidence, and whether log loss would be noticed. On Amazon RDS there is a specific trap: MARIADB_AUDIT_PLUGIN cannot be deactivated, only removed, and its default set is CONNECT, QUERY: usually narrower than an assessor expects. We also tell you whether community server_audit is sufficient or whether you need MariaDB Enterprise Audit, a paid feature.
A Galera cluster is audited as a system, not as three servers. A cluster is only as secure as the node whose configuration nobody checked, and that is usually the one added last.
We review whether wsrep traffic is encrypted, which SST method is in use and what it exposes during a transfer, how wsrep_sst_auth credentials are stored, whether the donor node is reachable from anywhere it should not be, and whether the gcache is protected at rest. Where MaxScale sits in front, it is an audit surface in its own right: admin interface exposure, REST API authentication, whether masking filter rules actually cover the columns they are believed to, and whether firewall filter rules cover the statements they are believed to.
| Framework | Control | MariaDB artefact we produce |
|---|---|---|
| PCI DSS 4.0 | 3.5.1 / 3.5.1.2 | Tablespace and binary log encryption state, key custody, and what remains in cleartext |
| PCI DSS 4.0 | 7.2.4 | A repeatable GRANT extract and a documented privilege review |
| PCI DSS 4.0 | 8.3 / 8.6.x | Service account inventory, authentication plugin posture, credentials out of config files |
| PCI DSS 4.0 | 10.2 / 10.4.1.1 | server_audit event coverage, off-host shipping, and failure detection |
| ISO 27001:2022 | A.8.15, A.8.16 | Log coverage mapped to Annex A clause numbers |
| ISO 27001:2022 | A.8.24 | TLS enforcement, cipher policy, key management |
| GDPR | Art. 32(1)(c) | Tested restores with a measured RTO and RPO, not a documented intention |
| GDPR | Art. 32(1)(d) | Why a recurring database review is an obligation, not discretionary spend |
| India DPDP 2025 | Rule 6(1)(a) | Column encryption and masked non-production copies |
| India DPDP 2025 | Rule 6(1)(c), 6(1)(e) | Audit log configuration and retention |
| RBI IT 2023 | Para 19, Para 26 | Privileged access review; independent assessment evidence |
| HIPAA | §164.312(a)(1), (b) | Unique user identification and a demonstrable audit mechanism |
The Center for Internet Security publishes two MariaDB benchmarks: MariaDB 10.11 v1.0.0 and MariaDB 10.6 v1.1.0. There is no CIS Benchmark for MariaDB 11.4, 11.8 or 12.3.
If you run 10.6 or 10.11 we assess against the benchmark directly, Level 1 and Level 2, and the report carries a conformance table. If you run 11.x or 12.x we map the controls that still apply, derive the rest from MariaDB's own published PCI and STIG guidance, and mark every derived item as derived. You will always be able to tell which findings come from a published benchmark and which come from our judgement.
| Series | GA | Community EOL | RDS standard support ends |
|---|---|---|---|
| 10.5 | n/a | 24 Jun 2025 | 31 Aug 2026 (passed) |
| 10.6 LTS | 6 Jul 2021 | 6 Jul 2026 (passed) | 31 Dec 2026 |
| 10.11 LTS | 16 Feb 2023 | 16 Feb 2028 | Feb 2028 |
| 11.4 LTS | 29 May 2024 | 29 May 2029 | May 2029 |
| 11.8 LTS | 4 Jun 2025 | 4 Jun 2028 | Jun 2028 |
| 12.3 LTS | 28 May 2026 | 12 Jun 2029 | Jun 2029 |
We check your exact build against the MariaDB advisory record rather than handing you a generic list. For scale: CVE-2026-49261 carries a CVSS score of 10.0 and was fixed in 11.8.8, 11.4.12, 10.11.18 and 10.6.27, published 11 June 2026. CVE-2026-48163 and CVE-2026-48165 both score 8.0 and were fixed in the same releases. A further four advisories landed on 21 July 2026, fixed in 12.3.3, 11.8.9, 11.4.13, 10.11.19 and 10.6.28.
The report gives you the advisories your build is exposed to, the minimum version that closes each, and an upgrade path that accounts for whether you can take an in-place upgrade or need a rolling Galera upgrade.
The work on your side is small and bounded, and it is written into the statement of work before anything begins.
| Step | Who | Your time |
|---|---|---|
| Scoping call | You and the lead DBA | 45 min |
| Read-only access provisioning | Your DBA or platform team | 30 min |
| Collection and review | Mydbops | None |
| Report and live walkthrough | You, your security owner, our engineer | 60 min |
| Remediation | Optional, separate engagement | Scoped separately |
Scope is bounded in the statement of work: one MariaDB deployment, standalone or a single Galera cluster. Multi-cluster and multi-region estates are quoted separately. Implementation is not included, and that is deliberate.
Eight artefacts, each written so the person reading it: an executive, a DBA, or an assessor: can act on it without asking you what it means.
Written for the person who will not read the rest.
Each finding with a severity, the affected hosts, and the control it answers to.
Level 1 and Level 2, with derived items marked as derived.
The minimum fixed version and an upgrade path for your exact build.
Extractable and repeatable, so your next review is cheaper than this one.
Where they are in scope.
Split into 0-30 days, 1-6 months, and 6-24 months.
With the engineer who did the work, not an account manager.
Every finding ships with its severity and a coverage column: the control it answers to and the hosts it affects.
A scanner tells you which checks failed. It cannot tell you that a privilege exists because a nightly job needs it, that a node is exposed because of an SST method chosen three years ago by someone who has left, or that your audit configuration passes its check while recording nothing your assessor will accept.
It also cannot tell you which of its four hundred findings matters on Tuesday. Every finding in our report has been looked at by a DBA who can explain why it is a risk in your architecture specifically: and several of them will be things no scanner has a check for.
A mutual NDA is signed before access is even discussed. Credentials are never sent over email or chat.
We work from a read-only account with the minimum grants the checks require, over a channel you control. No schema changes, no writes; load-bearing collection comes from a replica or scheduled with you first.
We do not copy application data out of your environment. What we retain is configuration, privilege and log metadata: and in the scoping call we tell you exactly what leaves your network and how long we keep it.
...enhancing the stability and disaster recovery of our critical services, supporting over 100,000 customers across Spain and Europe.
Mydbops has been a reliable DBA partner for our production database, supporting our growing traffic with monthly optimization reports, query tuning, and automated backups.
Mydbops has been a reliable partner for Shiprocket, expertly managing our critical databases with round-the-clock support. Their team of database specialists ensures seamless operations 24/7. Highly recommended for businesses of all sizes.
Exceeded all expectations! Mydbops team performed our migration in just 24 hours (where others had quoted this as a 2 - 4 week project). Their services were the most cost-effective by far, and their skill set, performance, and quality are unmatched. We will be retaining this team for ongoing 24/7 server monitoring and support.
server_audit is loaded, what it is configured to record, whether the events captured match what your framework requires, whether logs are shipped off-host, and whether log loss would be detected. On Amazon RDS there is a specific trap: the MARIADB_AUDIT_PLUGIN option cannot be turned off once added, only removed, and the default event set is CONNECT and QUERY, which is usually narrower than an assessor expects. We also tell you whether community server_audit is sufficient for your requirement or whether you would need MariaDB Enterprise Audit, which is a paid feature.wsrep traffic encryption, SST and IST transfer security, the SST method and the credentials it uses, donor node exposure, and whether the gcache is protected at rest. For MaxScale we look at admin interface exposure, REST API authentication, masking filter coverage, and whether the firewall filter rules actually cover the statements they are believed to cover. A cluster is only as secure as the node with the weakest configuration, and in practice that is rarely the one anyone checks.A 45-minute scoping call with a senior MariaDB DBA maps your estate, versions and frameworks to a bounded statement of work: read-only, non-destructive, under NDA.
