Database hardening recommendations without disrupting production
Database hardening means reducing what can go wrong by tightening access, configuration, network exposure, encryption and logging. Following a security audit of a production MariaDB 10.11, Linux and Apache Solr stack, Quensulting produced a phased hardening plan. Low-risk quick wins come first, then changes that need a maintenance window. Each step is documented with its purpose, the exact change, a test and a rollback.
At a glance
- Industry
- Information services (B2B data platform)
- Stack
- MariaDB 10.11 · AlmaLinux 9 · Apache Solr 8.11 · Ubuntu 22.04
- Reference
- CIS benchmarks (OS and MySQL), adapted to MariaDB
- Input
- Risk-rated findings from the security audit
- Principle
- Every change has a test and a rollback
- Deliverables
- OS hardening, DB hardening, backup strategy, verification checklist
Context
This engagement followed our database security audit for the same client. The audit showed where the risks were. This phase decided how to remove them safely.
The platform serves customers through the day, so any change that could drop connections or slow queries had to be planned around real usage.
Problem
- Audit findings ranged from one-line configuration fixes to changes that would affect every application connection.
- Some settings that are standard in MySQL guidance behave differently, or are named differently, in MariaDB.
- Backups existed, but nobody had checked whether they were encrypted, stored safely or restorable.
- The search tier needed protection immediately, even though a full version upgrade would take longer to plan.
Approach
- 1
Sort by risk and blast radius
Every audit finding was placed on two axes: how much risk it removes, and how much could break if the change goes wrong. This produced the order of work.
- 2
Quick wins first
Low-impact changes such as removing unused accounts, disabling unneeded features and tightening file permissions, applied with immediate verification.
- 3
Planned changes with rollback
Changes affecting connections (TLS enforcement, network binding, authentication) were scheduled for maintenance windows, tested on staging where available, and shipped with a rollback step.
- 4
MariaDB-native controls
CIS MySQL controls were translated into MariaDB equivalents for encryption at rest, audit logging and password validation, rather than copying MySQL settings that don't apply.
- 5
Backups as a security control
We designed a weekly full and daily incremental backup scheme with encrypted copies, off-server storage and a scheduled restore test, because an untested backup is a hope, not a control.
- 6
Verify against the baseline
We re-ran the audit checks after each phase and recorded before-and-after evidence, so the owner can see risk going down rather than take it on trust.
What the hardening plan covers
| Area | What we looked at | Risk it addresses |
|---|---|---|
| Operating system | SSH key-only access, root login off, firewall allow-lists, SELinux enforcing, unused services removed, patch schedule | Server-level compromise |
| Accounts and roles | Remove anonymous and test users, per-application accounts, least-privilege roles, no remote root | Over-privileged or shared access |
| Authentication | Password validation plugin, strong auth plugins, lockout policy | Credential guessing and reuse |
| Network | Bind to private interfaces, require secure transport (TLS), restrict admin paths | Exposure beyond the app tier |
| Encryption at rest | Key management and table/log encryption in MariaDB-native form | Data readable from disks or copies |
| Audit logging | Server audit plugin scope, log rotation, retention, protected log location | No evidence after an incident |
| Backup and recovery | Encrypted backups, off-server copies, restore drills, retention | Loss or leak through backups |
| Search tier | Authentication and authorisation, network restriction, admin surface, upgrade plan | Unauthenticated access to indexed data |
Outcomes
- A phased plan the team could execute safely, with quick wins separated from window-only changes
- Each recommendation documented with purpose, exact change, verification test and rollback
- MariaDB-specific guidance instead of generic MySQL checklists that don't apply
- A backup strategy that treats restore testing as part of security
- A re-audit checklist so the hardened baseline can be checked again after upgrades
Client name withheld per NDA. Recommendations are tailored per engine and version.
Deliverables
- Operating system hardening guide (per server)
- Database hardening guide with CIS control mapping
- Backup and restore strategy
- Change plan with maintenance-window schedule and rollbacks
- Post-hardening verification checklist
Hardening fails when it is handed over as a 200-line checklist. It works when each change has a reason, an owner, a test and a way back. Sequencing matters as much as the settings themselves.
Frequently asked questions
What is database hardening?
Database hardening is the process of reducing a database's attack surface: removing unnecessary accounts and features, enforcing least privilege, restricting network access, encrypting data, enabling audit logging and securing backups.
Will hardening break my application?
It can if changes are applied all at once. We sequence changes by risk, test where possible, schedule connection-affecting changes in maintenance windows and document a rollback for each step.
Can I apply a MySQL hardening checklist to MariaDB?
Partly. Many controls carry over, but encryption at rest, audit logging, password validation and some variables work differently in MariaDB. We map each CIS control to the MariaDB-native way of achieving it.
Do I need an audit before hardening?
We recommend it. An audit gives an evidence baseline, so hardening targets real risks and you can prove improvement afterwards. For small setups, both can be combined in one engagement.
Do you implement the changes or only recommend them?
Either. We can implement with your team during agreed windows, or hand over a step-by-step guide for your DBA or managed provider.
Have an audit report but no safe way to act on it?
Share your findings or your stack. We'll help you sequence the fixes so security improves without surprise downtime.