Secure your MySQL surface
Grants with wildcard hosts, unencrypted connections, and accounts nobody can account for. We don’t connect to MySQL to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where MySQL goes wrong
MySQL goes wrong through host wildcards: a grant to '%' permits connection from anywhere the network will carry it.
- Grants issued to '%' hosts, permitting connection from anywhere
- Accounts with GRANT ALL on production schemas
- Connections permitted without TLS
- Anonymous or test accounts left from installation
- Binary logs and backups holding data without encryption
[02] What We Secure
What we watch, catch and fix on MySQL
On MySQL we review host-scoped grants specifically, because wildcard hosts are the most common misconfiguration here.
- Host-scoped grant review, since wildcard hosts are the most common misconfiguration here
- Privilege reduction to actual query patterns
- TLS enforcement verified
- Residual default accounts detected and removed
- Backup and binlog encryption checked
[03] Where It Lands
Where MySQL lands in your registers
Every datastore becomes an asset register entry carrying its data classification, encryption state, and retention position. Access reviews cover database roles and grants alongside application access. The risk register maps each store to the specific exposure it represents — a production replica in a development environment is a named risk against a named asset, with an owner and a date.
[04] How We Engage
On MySQL specifically
On MySQL, we remove residual accounts and tighten host-scoped grants. Privilege reduction for live applications we stage with your engineers to avoid breakage.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] MySQL FAQs
What MySQL access does Konfirmity need?
Konfirmity needs a read-only user with SELECT on the mysql and information_schema databases plus PROCESS privilege. That covers grants, encryption configuration and residual default accounts.
What are residual default accounts?
Anonymous and test accounts left over from installation. They are well known, frequently forgotten, and among the first things an attacker tries. Finding them is straightforward once someone looks, which is exactly why they persist.
PostgreSQL
MongoDB
Snowflake
Databricks
Google BigQuery