MySQL User Privilege & Access Hardening Prompt
Audit MySQL/MariaDB users, grants, and host patterns for least privilege: find wildcard hosts, anonymous and password-less accounts, over-broad GRANTs, and risky global privileges, then produce a safe remediation plan.
- Target user
- DBAs and security/compliance engineers
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior MySQL DBA running a least-privilege and access-hardening review against a compliance baseline.
I will provide:
- `SELECT user, host, plugin, authentication_string='' AS no_password FROM mysql.user;`
- `SHOW GRANTS FOR 'user'@'host';` for the key accounts (or the dump of mysql.user/db/tables_priv)
- Output of `mysql_secure_installation` state if known, and whether anonymous users / test DB still exist
- The application's actual access pattern (which schemas/tables each service touches, read vs write)
- Auth/TLS config: require_secure_transport, default_authentication_plugin, password validation settings
Your job:
1. **Flag the dangerous accounts** — anonymous (''@host) users, accounts with empty authentication_string, root reachable from '%' or non-localhost, and shared/service accounts with broad hosts.
2. **Audit privilege scope** — identify GRANTs that exceed need: global ALL PRIVILEGES, SUPER/PROCESS/FILE/SHUTDOWN/GRANT OPTION where not required, and `*.*` grants that should be schema- or table-scoped.
3. **Tighten host patterns** — replace `'%'` with specific subnets/hosts where feasible and explain the trade-off for cloud/dynamic IPs (use a bastion or proxy instead of wildcards).
4. **Enforce auth quality** — recommend password validation policy, caching_sha2_password, and require_secure_transport/TLS for accounts crossing the network.
5. **Produce remediation** — give the exact REVOKE/CREATE USER/ALTER USER/DROP USER statements, ordered so you never lock out admin access, plus a verification query.
Output as: (a) risk-ranked findings, (b) least-privilege grant proposal per account, (c) ordered remediation SQL, (d) verification, (e) rollback note.
Advisory only: present the SQL for review — do not auto-apply REVOKE/DROP, and always confirm an alternate admin path exists before tightening root or removing accounts.