Database security audit for a high-traffic data platform
A database security audit tells you, with evidence, where your data can be reached, changed or lost. For an online data platform running MariaDB 10.11 on AlmaLinux 9 and Apache Solr 8 on Ubuntu, Quensulting ran a read-only audit across the operating system, database and search tiers. We benchmarked it against CIS controls and delivered a risk-rated findings register with a prioritised remediation roadmap. No production changes were made during the audit.
At a glance
- Industry
- Information services (B2B data platform)
- Stack
- MariaDB 10.11 · AlmaLinux 9 · Apache Solr 8.11 · Ubuntu 22.04
- Benchmark
- CIS Oracle MySQL Enterprise 8.0 Benchmark v1.3.0, adapted to MariaDB
- Access model
- Read-only, least privilege, no production changes
- Deliverables
- OS audit, DB security audit, findings register, roadmap
- Engagement
- Audit-first, followed by hardening
Context
The client runs a subscription data platform. Customers search and download time-sensitive records all day, so the database and search tiers are the business.
The systems had been built and extended by a small team over several years. They worked, but nobody had looked at them through a security lens since they were first set up.
Problem
- There was no written baseline of who could log in, from where, or with what privileges.
- Configuration defaults from the original install had never been reviewed against a recognised standard.
- The search tier ran an end-of-life release, and the team was not sure how exposed it was.
- The business owner wanted assurance before adding more automation and AI workloads on top of the same data.
Approach
- 1
Kick-off and access
Agreed scope (database and search systems only), named contacts and a read-only access model. Credentials were never shared over chat or email.
- 2
Evidence snapshot
Captured configuration, accounts, grants, listening ports, firewall rules, OS patch level and service inventory, so every finding traces back to evidence.
- 3
OS security audit
Reviewed SSH settings, SELinux or AppArmor state, firewall posture, running services, file permissions and patch cadence on each server.
- 4
Database security audit
Checked authentication, accounts and privileges, network exposure, encryption in transit and at rest, audit logging, file and import settings, and version support. Each check was mapped to the CIS benchmark, with the MariaDB-native equivalent where MariaDB behaves differently from MySQL.
- 5
Search tier review
Assessed Solr authentication and authorisation, network reachability, admin surface and support status. Interim mitigations were separated from the longer-term upgrade decision.
- 6
Risk rating and readout
Rated every finding Critical, High, Medium or Low by likelihood and business impact, then walked the owner and the technical team through it in plain language.
What we checked
| Area | What we looked at | Risk it addresses |
|---|---|---|
| Accounts and privileges | Anonymous and test users, remote root, shared app accounts, excess GRANTs | Over-privileged access to production data |
| Authentication | Password policy, auth plugins, account lockout | Weak or reused credentials |
| Network exposure | Bind address, open ports, firewall rules, remote admin paths | Database reachable from more places than needed |
| Encryption | TLS for client connections, data-at-rest encryption, backup encryption | Data readable in transit or from copies |
| Audit and logging | Audit plugin, error and slow logs, retention | No trail when something goes wrong |
| Server configuration | local_infile, secure_file_priv, symbolic links, SQL mode | File-system abuse through the database |
| Patching and support | Engine, OS and search versions against vendor support windows | Known vulnerabilities with no vendor fix |
| Search tier | Authentication, admin endpoints, network access | Unauthenticated access to indexed data |
Outcomes
- A single findings register: each item with evidence, business impact, recommended fix, effort and owner
- Controls mapped to the CIS MySQL benchmark, with MariaDB-native alternatives where the two engines differ
- End-of-life search engine risk made visible, with interim mitigations and a separate upgrade recommendation
- A two-page executive summary the business owner could act on without a DBA in the room
- A ready-to-run hardening plan, delivered as the next phase
Client name withheld per NDA. No production changes were made during the audit.
Deliverables
- Operating system security audit (per server)
- Database security audit with CIS control mapping
- Risk-rated findings register
- Prioritised remediation roadmap
- Executive summary and readout session
Most database risk isn't exotic. It comes from defaults nobody revisited and access that was never taken back. An evidence-based audit makes it visible and puts it in priority order, so the fixes become a short, calm list rather than a fire drill.
Frequently asked questions
What is a database security audit?
A structured, evidence-based review of who can access a database, how it is configured, how data is protected in transit and at rest, and whether activity is logged. The output is a risk-rated list of findings with recommended fixes.
Will a security audit affect my production database?
No. We work read-only, using queries and configuration reads. No settings are changed during the audit. Changes happen only in the hardening phase, with your approval and a rollback plan.
Which databases do you audit?
MySQL, MariaDB and PostgreSQL, plus cloud-managed versions of these, and search engines such as Apache Solr and Elasticsearch. We use CIS benchmarks as the reference and adapt the controls where an engine differs.
How long does a database security audit take?
For a few servers, typically one to three weeks from access to readout, depending on how many systems are in scope and how quickly access is arranged.
Do you also fix the issues you find?
Yes. Hardening is a separate, optional phase. We can implement the changes, or document them so your team or managed provider can carry them out.
Not sure how exposed your database is?
Tell us your engine and setup. We'll suggest a read-only audit scope that fits your systems and your risk appetite.