Audit MariaDB Users, Privileges, and Security Events

A useful MariaDB privilege audit must answer two different questions. First, who could access which data or administrative capability right now? Second, what did identities actually do, including failed attempts and changes to security controls? Account inventories and SHOW GRANTS answer the first question. Event logs and the MariaDB Audit Plugin help answer the second. Neither one replaces the other.

This guide builds a repeatable production audit process: define an access baseline, inventory host-qualified accounts and authentication methods, expand roles and object grants, find dangerous drift, deploy MariaDB's Community Audit Plugin, protect and forward evidence, create alerts, test the pipeline with canary events, and conduct periodic reviews. It also covers log volume, privacy, plugin failures, emergency access, and safe remediation.

Examples use current MariaDB terminology, but privilege names, plugin features, and variables can change between releases. Run discovery commands on the exact server and compare them with documentation matching its version. Audit output contains sensitive infrastructure and query information; store it only in approved protected locations.

Define audit objectives before collecting everything

Logging every query indefinitely is not an audit strategy. It can expose sensitive values, consume storage, reduce database performance, and bury meaningful events in routine traffic. Begin with risks and evidence requirements.

A production policy commonly needs to detect:

• New, altered, locked, unlocked, or removed accounts.
• Global administrative privileges and WITH GRANT OPTION.
• Wildcard host access and anonymous accounts.
• Direct grants that bypass the approved role model.
• Dormant migration, vendor, or former employee identities.
• Failed logins, unexpected sources, and unusual login times.
• DDL, user-management, privilege, and security-variable changes.
• Access to sensitive databases or tables.
• Attempts to disable, reconfigure, delete, or overwhelm audit logs.
• Use of emergency or break-glass credentials.

For each requirement, document:

Compliance requirements may dictate scope and retention, but the operational design must still account for volume, sensitive data, availability, and investigation quality.

Separate state auditing from event auditing

State auditing takes a point-in-time snapshot of accounts, authentication methods, roles, privileges, TLS requirements, resource limits, and locks. Comparing snapshots identifies drift.

Event auditing records activity such as connections, disconnections, failed authentication, statements, and table access. It can show when and by whom a change occurred, provided the event was collected and preserved.

An account can acquire a dangerous grant between two monthly snapshots and lose it before the next review. Event auditing may reveal the change. Conversely, an audit log can start after an old excessive grant was created and never show its origin. State inspection still finds it.

Use both, then correlate with:

• Deployment and change-management records.
• Identity-provider and PAM logs.
• Secret-manager access logs.
• Host firewall and cloud flow logs.
• Application release identifiers.
• Kubernetes or infrastructure audit logs.

MariaDB does not know why a role was approved or whether a source IP belongs to the expected workload. Context belongs in the wider control system.

Establish a protected administrative session

Run privilege discovery through a named, audited administrative path or controlled local socket. Verify the matched account:

SELECT VERSION();
SELECT USER() AS client_identity,
       CURRENT_USER() AS matched_account,
       CURRENT_ROLE() AS active_role;

Capture server identity alongside every export:

SELECT @@hostname AS server_host,
       @@port AS server_port,
       @@server_id AS server_id,
       VERSION() AS server_version,
       UTC_TIMESTAMP() AS captured_at_utc;

Without this metadata, two snapshots from different replicas or environments can look like drift. Use UTC consistently and synchronize host clocks.

Do not run audit exports with an application credential. The export account needs enough metadata visibility to produce a complete result, but it should not receive unrelated DDL or data-modification privileges.

Inventory every host-qualified account

MariaDB accounts are 'user'@'host' pairs. Start with a sorted inventory:

SELECT User, Host, plugin, account_locked, password_expired
FROM mysql.user
ORDER BY User, Host;

mysql.user is a compatibility view on modern MariaDB. It is convenient for review, but do not edit it. Use supported account-management statements.

For complete authentication definitions, generate and run SHOW CREATE USER for each account. An administrator can first create the statement list:

SELECT CONCAT(
  'SHOW CREATE USER ',
  QUOTE(User), '@', QUOTE(Host), ';'
) AS review_statement
FROM mysql.user
ORDER BY User, Host;

Review exact definitions for:

• Authentication plugin and alternative methods.
• TLS requirements such as REQUIRE SSL or X509.
• Account lock and password-expiry state.
• Resource limits.
• Duplicate usernames with broader host patterns.
• Empty usernames representing anonymous accounts.

Find obvious host-scope concerns:

SELECT User, Host, plugin
FROM mysql.user
WHERE User = ''
   OR Host = '%'
   OR Host LIKE '%.%'
ORDER BY User, Host;

That query is a review lead, not a verdict. A host containing dots may be an exact address or hostname, and % inside a narrowly documented pattern may be intentional. Human review must compare it with the approved flow matrix.

Capture direct grants with SHOW GRANTS

SHOW GRANTS is the safest human-readable representation of an account's grants. Generate statements:

SELECT CONCAT(
  'SHOW GRANTS FOR ',
  QUOTE(User), '@', QUOTE(Host), ';'
) AS review_statement
FROM mysql.user
ORDER BY User, Host;

For a specific account:

SHOW CREATE USER 'orders_api'@'10.20.30.25';
SHOW GRANTS FOR 'orders_api'@'10.20.30.25';

Search the exported baseline for:

• ALL PRIVILEGES ON *.*.
• WITH GRANT OPTION.
• Broad db_name.* access where table or view scope was approved.
• DDL privileges on runtime service accounts.
• Global FILE, process visibility, replication, or administrative privileges.
• Access to mysql, audit, or security metadata.
• Roles assigned with delegation capability.
• Grants to PUBLIC, when supported and unintended.

Privilege names are release-dependent. Run:

SHOW PRIVILEGES;

Do not classify an unfamiliar modern privilege as harmless. Map it to official documentation for that server version.

Query structured privilege metadata

Information Schema exposes structured privilege views useful for comparison and reporting. Global privileges:

SELECT GRANTEE, PRIVILEGE_TYPE, IS_GRANTABLE
FROM information_schema.USER_PRIVILEGES
ORDER BY GRANTEE, PRIVILEGE_TYPE;

Database-level privileges:

SELECT GRANTEE, TABLE_SCHEMA, PRIVILEGE_TYPE, IS_GRANTABLE
FROM information_schema.SCHEMA_PRIVILEGES
ORDER BY GRANTEE, TABLE_SCHEMA, PRIVILEGE_TYPE;

Table-level privileges:

SELECT GRANTEE, TABLE_SCHEMA, TABLE_NAME,
       PRIVILEGE_TYPE, IS_GRANTABLE
FROM information_schema.TABLE_PRIVILEGES
ORDER BY GRANTEE, TABLE_SCHEMA, TABLE_NAME, PRIVILEGE_TYPE;

Column privileges may be relevant in tightly scoped systems:

SELECT GRANTEE, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME,
       PRIVILEGE_TYPE, IS_GRANTABLE
FROM information_schema.COLUMN_PRIVILEGES
ORDER BY GRANTEE, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME;

These tables represent their documented privilege levels. They do not automatically give a simple single-row “effective access” answer across roles, direct grants, definer objects, and every server capability. Keep SHOW GRANTS, role inspection, and object definitions in the audit package.

Audit roles and role activation

Roles reduce repetitive grants but can hide effective privilege behind several relationships. List roles applicable to the reviewing account:

SELECT *
FROM information_schema.APPLICABLE_ROLES
ORDER BY GRANTEE, ROLE_NAME;

Inspect enabled roles in the current session:

SELECT *
FROM information_schema.ENABLED_ROLES;
SELECT CURRENT_ROLE();

For every production role, capture:

SHOW GRANTS FOR orders_readonly;

Then record which accounts receive it and whether it is the default. Review for:

• Roles nesting into unexpectedly powerful roles.
• Direct privileges added beside an approved role.
• A role assigned to more environments or teams than intended.
• Delegation or administrative options on role assignment.
• Service accounts whose required default role is not active.
• Roles that no longer have an owner.

Test effective access by connecting as a representative account and checking CURRENT_ROLE(). An assigned role that is not active may cause an outage; an unintended default role may create excess access.

Include stored objects and definers

Views, triggers, events, and routines can execute under definer-related security semantics. A definer account may be missing, overly powerful, shared between environments, or scheduled for deletion.

Inventory view definers and security type:

SELECT TABLE_SCHEMA, TABLE_NAME, DEFINER, SECURITY_TYPE
FROM information_schema.VIEWS
WHERE TABLE_SCHEMA NOT IN
  ('mysql','information_schema','performance_schema','sys')
ORDER BY TABLE_SCHEMA, TABLE_NAME;

Inventory routines:

SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE,
       DEFINER, SECURITY_TYPE
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN
  ('mysql','information_schema','performance_schema','sys')
ORDER BY ROUTINE_SCHEMA, ROUTINE_NAME;

Inventory triggers and scheduled events:

SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, DEFINER
FROM information_schema.TRIGGERS
ORDER BY TRIGGER_SCHEMA, TRIGGER_NAME;

SELECT EVENT_SCHEMA, EVENT_NAME, DEFINER, STATUS
FROM information_schema.EVENTS
ORDER BY EVENT_SCHEMA, EVENT_NAME;

Do not change definers as a bulk textual rewrite. Understand execution semantics, deployment ownership, replication, and application behavior, then test a controlled migration.

Create a reproducible privilege baseline

A baseline is a declared desired state, not merely yesterday's snapshot. Store sanitized account definitions and grants in a protected, reviewed repository or access-governance system. Do not store plaintext passwords or authentication hashes in ordinary source control.

Normalize exports before comparison:

• Sort accounts by User, then Host.
• Sort privilege rows by grantee, scope, and privilege.
• Include server version and capture timestamp separately.
• Preserve quoted account identities exactly.
• Treat expected package or version changes as reviewed baseline updates.
• Exclude volatile session values that create meaningless diffs.

A scheduled job can write tabular exports without embedding a password on the command line:

umask 077
mariadb 
  --defaults-file=/etc/mariadb-audit/client.cnf 
  --batch --raw --skip-column-names 
  --execute="SELECT User, Host, plugin, account_locked, password_expired
             FROM mysql.user ORDER BY User, Host" 
  > accounts.tsv

The option file is itself a secret-bearing asset. Restrict ownership, use a dedicated read-only metadata account where feasible, and keep output in an encrypted protected location.

Diff a new normalized export against the approved baseline:

diff -u approved/accounts.tsv current/accounts.tsv
diff -u approved/user-privileges.tsv current/user-privileges.tsv
diff -u approved/schema-privileges.tsv current/schema-privileges.tsv
diff -u approved/table-privileges.tsv current/table-privileges.tsv

An automated difference is a finding, not always an incident. Link approved deployment changes automatically where possible, then require an owner and disposition for unexplained drift.

Define an access review cadence

Use frequency based on risk:

• Continuous or daily checks for new global administrators, wildcard accounts, grant delegation, and audit disablement.
• Weekly review of failed authentication and unexpected source patterns.
• Monthly or quarterly attestation of application, human, vendor, and operational access.
• Immediate review after incidents, topology changes, acquisitions, and major upgrades.
• Expiration-driven review for temporary migration or vendor accounts.

Every account should have an owner, purpose, environment, source path, privilege specification, secret or authentication lifecycle, and review date. An unowned account is a finding even when its grants appear narrow.

Inspect MariaDB Audit Plugin availability

The MariaDB Community Audit Plugin can record connection, query, and table-access activity to a file or syslog. Check installation before configuring variables:

SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_TYPE, PLUGIN_LIBRARY
FROM information_schema.PLUGINS
WHERE PLUGIN_NAME = 'SERVER_AUDIT';

Inspect package contents and plugin directory:

sudo mariadb -NBe "SHOW VARIABLES LIKE 'plugin_dir';"
dpkg -L mariadb-server 2>/dev/null | grep server_audit || true

Install only the plugin library shipped for the exact MariaDB package. On a staging server, the dynamic installation command is commonly:

INSTALL SONAME 'server_audit';

Confirm:

SHOW PLUGINS;
SHOW GLOBAL VARIABLES LIKE 'server_audit%';
SHOW GLOBAL STATUS LIKE 'server_audit%';

Do not assume dynamic installation alone describes rebuild behavior. Document package dependency and startup persistence, then test a controlled restart. Never uninstall the plugin before disabling dependent configuration and preserving required evidence.

Choose events based on use cases and volume

MariaDB Audit Plugin event groups include connection, query, and table-related events, with exact options depending on plugin and server version. A staged starting point can focus on connections:

SET GLOBAL server_audit_events = 'CONNECT';

Then add query or table events after measuring volume and sensitive-data exposure:

SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';

Query events can contain SQL text and sensitive literals. Table events can generate one record for each accessed table. High-throughput workloads may produce substantial I/O and central-ingestion cost. Benchmark with representative concurrency, prepared statements, long queries, replication, backup, and failover.

User include and exclude lists can reduce volume, but exclusions create visibility gaps. According to MariaDB's documented behavior, CONNECT records are not suppressed by these user filters. Confirm actual output using canary events on the installed plugin version.

Avoid excluding administrative and audit-maintenance identities merely because they are noisy. Changes made by powerful users are among the most important events to preserve.

Configure file output safely

For local file output, create a dedicated directory with ownership compatible with the MariaDB service:

sudo install -d -o mysql -g adm -m 0750 /var/log/mariadb-audit

Create a late-loading option file such as /etc/mysql/mariadb.conf.d/z-server-audit.cnf:

[mariadb]
plugin_load_add = server_audit

server_audit_output_type = FILE
server_audit_file_path = /var/log/mariadb-audit/server_audit.log
server_audit_file_rotate_size = 104857600
server_audit_file_rotations = 10
server_audit_events = CONNECT,QUERY
server_audit_logging = ON

The values are examples, not universal retention recommendations. Calculate expected events per second, average record size, burst factor, local capacity, central forwarding delay, and required retention.

Validate option parsing, restart in staging, and inspect startup:

my_print_defaults mariadb server mysqld
sudo systemctl restart mariadb
sudo systemctl --no-pager --full status mariadb
sudo journalctl -u mariadb -n 100 --no-pager

Inspect variables and file metadata:

SHOW GLOBAL VARIABLES LIKE 'server_audit%';
SHOW GLOBAL STATUS LIKE 'server_audit%';

sudo namei -l /var/log/mariadb-audit/server_audit.log
sudo stat -c '%U %G %a %s %n' 
  /var/log/mariadb-audit/server_audit.log

Do not make the file world-readable. The log can contain account names, hosts, SQL, schema details, and application data.

Consider syslog and remote forwarding

The plugin can send events to syslog instead of a local audit file. This can make evidence harder for the MariaDB service account to alter and integrate with an existing secure logging pipeline.

Example server configuration:

[mariadb]
plugin_load_add = server_audit
server_audit_output_type = SYSLOG
server_audit_syslog_facility = LOG_LOCAL6
server_audit_syslog_priority = LOG_INFO
server_audit_syslog_ident = mariadb-audit
server_audit_syslog_info = db01-production
server_audit_events = CONNECT,QUERY
server_audit_logging = ON

Configure rsyslog, syslog-ng, journald forwarding, or another agent through the organization's supported logging stack. Use authenticated encrypted transport to the collector, disk-assisted queues for temporary network failure, rate and loss monitoring, and destination access controls.

Syslog is not automatically remote, encrypted, immutable, or lossless. The local daemon, forwarding configuration, network, collector, and storage all need separate verification.

Protect audit evidence and retention

An attacker with database administration or host root access may try to disable logging or delete evidence. Use defense in depth:

• Forward events off-host quickly to a separately administered system.
• Restrict who can change plugin variables and collector configuration.
• Separate database administration from audit-storage administration.
• Encrypt forwarding and archives.
• Use append-oriented or write-once retention where required.
• Generate integrity metadata for closed archives.
• Monitor gaps, sequence anomalies, agent backlog, and clock drift.
• Back up configuration and parsing rules with change history.
• Test search and export during recovery exercises.

Do not apply Linux immutable or append-only attributes to an active rotating file without testing MariaDB's rotation behavior. A protection that prevents rotation can fill the filesystem and stop the database.

Retention is not “keep everything.” Define searchable hot retention, protected archive retention, legal holds, and deletion. Query logs may contain personal or regulated data, so data-minimization and access-audit requirements apply to the audit system itself.

Prove the pipeline with canary events

Checking server_audit_logging=ON proves configuration state, not end-to-end collection. Generate safe, recognizable events through a dedicated test account in a non-sensitive schema.

Create a canary account and object in staging:

CREATE DATABASE audit_canary;
CREATE TABLE audit_canary.events (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  marker VARCHAR(64) NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE USER 'audit_canary'@'10.20.30.90'
  IDENTIFIED BY 'temporary-secret'
  REQUIRE SSL;

GRANT SELECT, INSERT
ON audit_canary.*
TO 'audit_canary'@'10.20.30.90';

Connect from the approved test source and insert a non-secret marker:

INSERT INTO audit_canary.events(marker)
VALUES ('audit-pipeline-check-20260825');

Then verify:

1. MariaDB plugin status shows no relevant errors.
2. The local file or syslog receives the event.
3. The forwarder ships it without parsing loss.
4. The central index assigns correct host, user, database, event type, and UTC time.
5. A test detection rule creates and routes an alert where expected.
6. Authorized investigators can retrieve it after rotation.

Also perform a failed login canary with an account created for testing, without locking a real service account or placing a password in logs. Remove the canary account and schema when the validation program ends.

Build high-signal detections

Useful detections combine event, identity, source, timing, and approved-change context:

• Any CREATE USER, ALTER USER, DROP USER, GRANT, or REVOKE outside an approved deployment.
• New account with % host or unexpected authentication plugin.
• WITH GRANT OPTION assigned to a service account.
• Audit logging disabled or event scope reduced.
• Repeated authentication failures followed by success from the same source.
• Administrator login from a new network or outside the maintenance window.
• Runtime account attempting DDL, user management, FILE, or cross-schema access.
• Break-glass account use.
• Sudden disappearance of events from an otherwise active server.
• Collector queue growth, parse failures, or storage rejection.

Avoid alerting on a SQL keyword substring without parsing context. Comments, routine definitions, prepared statements, and ordinary data can contain the same text. Build detections from structured audit fields where possible and test known false-positive cases.

Every alert needs a runbook: identify server, match account, find source, confirm change ticket, contain access if required, preserve evidence, and record disposition.

Troubleshoot common audit failures

Plugin is not loaded

Check exact version, plugin directory, package contents, and startup log:

SELECT VERSION();
SHOW VARIABLES LIKE 'plugin_dir';
SHOW PLUGINS;

sudo journalctl -u mariadb -b --no-pager

Do not copy a .so from another server version. Install the matching package and follow its documented plugin lifecycle.

Logging is ON but no file appears

Inspect output type, file path, directory ownership, AppArmor or SELinux denials, and plugin status:

SHOW GLOBAL VARIABLES LIKE 'server_audit%';
SHOW GLOBAL STATUS LIKE 'server_audit%';

sudo namei -l /var/log/mariadb-audit
sudo journalctl -k --since '-15 minutes' --no-pager

Generate a canary connection after confirming the intended event type is enabled.

Events exist locally but not in the SIEM

Check forwarder service, queue depth, TLS trust, collector availability, parsing errors, timestamps, index routing, and retention filters. Preserve the local file while repairing forwarding; do not repeatedly restart MariaDB.

Audit volume is too high

Measure which event types, accounts, and queries dominate. Tighten scope according to documented requirements, optimize collection, and scale the pipeline. Do not exclude administrators or disable all auditing under pressure. Retain CONNECT events and high-risk changes at minimum according to policy.

Log rotation loses events

Use the plugin's supported internal rotation for its file output or a vendor-documented coordination method. Validate under load and track file identity, forwarding offsets, and rotation counters. Copy-truncate and external renames can race with active writes.

Account baseline changes every run

Normalize ordering and remove volatile capture metadata from the diff body. Confirm snapshots come from the same server role and version. Keep meaningful changes such as authentication plugin, account lock, default role, and grant scope.

SHOW GRANTS misses expected effective access

Inspect role grants, active/default roles, views and routines, direct table or column grants, and the exact host-qualified account. Test with a new session as the representative identity.

Remediate findings without destroying evidence

For an unexplained powerful account:

1. Capture SHOW CREATE USER, SHOW GRANTS, relevant events, sessions, and change records.
2. Identify the owner and live dependencies.
3. Lock the account when containment is necessary and operationally safe.
4. Revoke specific excess grants or roles through reviewed SQL.
5. Test expected application behavior and negative permissions.
6. Update the approved baseline only after approval.
7. Preserve the finding and disposition.

Locking is reversible:

ALTER USER 'legacy_vendor'@'10.20.30.95' ACCOUNT LOCK;

Revoke the exact capability rather than rebuilding all grants from memory:

REVOKE DROP
ON orders.*
FROM 'orders_api'@'10.20.30.25';

DROP USER is destructive and can break unknown jobs. Use it after dependency validation and an observation window, not as the first audit reaction.

Audit emergency access

Break-glass accounts require stronger controls because normal approval may be bypassed during an incident:

• Store credentials in a separately controlled emergency vault.
• Require multiple-party approval or produce immediate access notifications.
• Restrict source network and authentication method.
• Grant only the capabilities required for defined scenarios.
• Alert on every authentication attempt and successful use.
• Rotate after every use and test the replacement.
• Require retrospective review linked to incident evidence.
• Test access periodically without performing destructive actions.

An emergency account that has never been tested is not a recovery control. An emergency account used routinely is not emergency access.

Production checklist

• Maintain a complete inventory of 'user'@'host' accounts and owners.
• Capture SHOW CREATE USER, SHOW GRANTS, roles, and structured privilege views.
• Include views, routines, triggers, events, and definers.
• Compare normalized current state with an approved baseline.
• Review global grants, delegation, wildcards, direct grants, and dormant identities.
• Deploy the Audit Plugin through version-matched packages and configuration.
• Select events from documented risks and measured volume.
• Protect logs from broad read access and forward them off-host.
• Monitor retention, rotation, queue loss, parser failures, and clock drift.
• Generate safe canary events to prove collection and alerts end to end.
• Correlate findings with deployments, identity systems, networks, and secret access.
• Remediate through reversible account locks and precise revocations.
• Audit break-glass use and rotate after activation.
• Re-run the complete audit after upgrades and topology changes.

FAQ

Is SHOW GRANTS enough for a MariaDB security audit?

No. It is essential for account state, but also inspect roles, authentication definitions, object definers, event logs, ownership, and observed usage.

Does the MariaDB Audit Plugin log activity by default?

Audit logging is normally off until configured. Verify plugin installation, server_audit_logging, event scope, output destination, and an end-to-end canary.

Should production audit logging include every query?

Only when requirements justify the volume and sensitive-data exposure. Start from explicit use cases, benchmark impact, and protect query content carefully.

Can user exclusions hide failed MariaDB logins?

MariaDB documents that CONNECT records are not affected by audit include/exclude user lists. Confirm behavior on the installed plugin using safe tests.

Is syslog output automatically secure?

No. Configure authenticated encrypted forwarding, durable queues, restricted collectors, retention, monitoring, and access control separately.

How often should MariaDB privileges be reviewed?

Continuously monitor critical drift and audit disablement, review security events regularly, and perform formal access attestation monthly or quarterly according to risk.

What is the safest first action for an unknown account?

Capture its definition, grants, activity, owner, and dependencies. Lock it for reversible containment when risk warrants, then revoke or drop it after validation.

How can I prove the audit pipeline works?

Generate a recognizable non-sensitive canary event and verify it through MariaDB, local output, forwarder, central parser, retention, search, and alert routing.

Conclusion

A defensible MariaDB privilege audit combines desired access state with trustworthy event evidence. Inventory every host-qualified account, expand direct and role-based grants, review definers and powerful capabilities, then compare normalized output against an approved baseline with clear ownership.

Event collection completes the picture only when it is scoped, protected, forwarded, retained, and tested. A canary that reaches the investigator is stronger evidence than an enabled variable. With continuous drift checks, high-signal detections, and reversible remediation, access reviews become an operational control rather than a periodic spreadsheet exercise.

Suggested Internal Links

• Secure a New MariaDB Server: Production Hardening Guide
• MariaDB Users and Grants: A Least-Privilege Production Guide
• MariaDB Authentication Plugins Explained for Linux Admins
• Harden MariaDB Against SQL Injection and Credential Leaks
• Configure the MariaDB Firewall and Network Controls
• Use the MariaDB Slow Query Log for Real Diagnosis

Suggested External Sources

• MariaDB Community Audit Plugin
• MariaDB Audit Plugin overview
• MariaDB Audit Plugin configuration
• MariaDB Audit Plugin log settings
• MariaDB audit log location and rotation
• MariaDB Audit Plugin variables
• MariaDB Information Schema tables
• MariaDB GRANT documentation