Database Security & Hardening

The most common finding we report is an application connecting to its database as a near-admin user. It works, so nobody questions it, but it means a single SQL injection or a leaked connection string gives an attacker the ability to read every table, write to any of them, and often run administrative commands. Right-sizing that account to the exact tables and operations the app needs turns a catastrophic flaw into a contained one.

Internet-wide scans constantly find MySQL on 3306, PostgreSQL on 5432 and MongoDB on 27017 answering to anyone. Unauthenticated or weakly-authenticated MongoDB instances in particular have leaked billions of records over the years. A database should almost never be reachable from the public internet, and closing that exposure is one of the highest-value changes we make. Attackers do not need to find you; automated tooling indexes every open database service on the internet and lists them for anyone to browse, so an exposed instance is discovered in hours, not months. Pulling it behind the application tier removes it from that map entirely.

We measure your configuration against the CIS Benchmark for your engine and version, covering authentication, privileges, network settings, logging, encryption and file permissions. The output is a ranked list of gaps with the real-world impact of each, so you can see what is a genuine risk versus what is cosmetic.

We map who and what connects to each database, then rebuild the grants around least privilege. Application accounts get only the tables and operations they use. Administrative access is separated from day-to-day access, default and anonymous accounts are removed, and strong authentication is enforced. For an Oracle database security review, that includes profile and role work specific to the platform; for MongoDB it means role-based access control done properly rather than an open admin user.

Secrets out of plaintext config

Database passwords sitting in a readable configuration file or committed to a repository undo the rest of the work. We move credentials into a secrets manager or protected store and rotate anything that has been exposed, so a leaked file no longer equals a leaked database.

We put the database behind the application tier where the internet cannot reach it, restrict access to known hosts, and require TLS for connections so credentials and data are not readable on the wire. Encryption at rest protects the underlying files and backups, which matters both for a stolen disk and for GDPR obligations around data-at-rest.

A database that keeps no record of access cannot tell you whether it was breached, or what was taken if it was. We enable audit logging appropriate to the engine, capture privileged actions and failed logins, and route those logs somewhere they cannot be quietly wiped by an intruder covering their tracks.

We address the classic weak spots: the validate-password plugin, removal of the anonymous and test accounts left by a default install, secure-file-priv to stop file-based data theft, and grants that are almost always broader than the application needs.

Here the focus is the host-based authentication configuration, role and schema privileges, connection encryption, and turning on the logging that ships disabled. Public schema permissions in particular catch a lot of teams out.

The recurring disaster is an instance with authentication effectively off and a public bind address. We enforce authentication, apply role-based access control, bind to internal interfaces only, and enable TLS, which together close the exposure behind the majority of MongoDB data leaks.

For these enterprise engines we work through the platform’s own security model: server and database roles, transparent data encryption, secure authentication modes, surface-area reduction, and the audit features each provides. An Oracle database security hardening pass covers profiles, privilege analysis and the settings that a CIS Benchmark for Oracle calls out.

You receive a findings report that ranks each gap by real impact, explains why it matters in plain terms, and gives the exact configuration change to close it. Where we implement the fixes ourselves, the report records what changed and confirms the state afterwards. There is an executive summary for leadership and the technical detail for whoever owns the database, so nobody has to translate between the two.

Beyond the immediate fixes, you get a documented secure configuration for your engine that new databases can be built against. That turns hardening from a one-time cleanup into a standard your team applies going forward, which is what keeps the next database from starting life with the same weak defaults.

Verification retest

After you apply the remediation, we retest to confirm the gaps are genuinely closed and nothing regressed. This is included, not billed as a second engagement, because a fix you cannot prove is a fix you cannot trust.

Encryption at rest and in transit, access control and logging are core to ISO 27001, and they satisfy PCI DSS 4.0 requirements for any database that stores or processes cardholder data. GDPR expects appropriate technical measures for personal data, which encryption and least-privilege access directly address, and SOC 2 auditors look for exactly this kind of documented control over data stores. The assessment report is written so it can support those reviews rather than sitting on a shelf.