MariaDB Audit Plugin – Logging Only DML Queries

auditmariadb-10.1

I was testing the "server_audit" plugin of MariaDB, which I configured like this:

plugin-load-add = server_audit
server_audit_logging = ON
server_audit_events = QUERY_DML
server_audit_output_type = FILE
server_audit_file_path = /path/to/audit.log
server_audit_query_log_limit = 1048576
server_audit_file_rotate_size = 1073741824
server_audit_file_rotations = 1

and I am currently running MariaDB 10.1.29 with MariaDB Audit Plugin version 1.4.3.

Based on the docs, the value QUERY_DML should be

Same as QUERY, but filters only DML-type queries (DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER and REPLACE statements)

emphasis mine.

After restarting the server, the log files has correctly been created, however it is logging also other queries, like for example plain SELECTs.

Is my configuration somewhat incorrect, or is it perhaps an error on MariaDB side?

Best Answer

As of version 1.4.4 of the plugin, there is now a QUERY_DML_NO_SELECT type that should give you what you are expecting.

Same as QUERY_DML, but doesn't log SELECT queries. (since version 1.4.4) (DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER and REPLACE statements)

This was introduced in MariaDB 5.5.42, MariaDB 10.0.17, and MariaDB 10.1.4.

Related Solutions

SQL Server Audit Specification – Filter DML by All But One User

You can't do this at the audit specification level, but you can do it at the server audit level. So, if this audit does other things too, and you don't want to filter out those events by login, you will need to create a separate audit. Assuming you want to filter out all activity of any kind by this service account, you can do this:

ALTER SERVER AUDIT OurAudit WITH (STATE = OFF);
GO
ALTER SERVER AUDIT OurAudit WHERE server_principal_name <> N'service account name';
GO
ALTER SERVER AUDIT OurAudit WITH (STATE = ON);
GO

Depending on how they connect, authenticate, perhaps impersonate, and how the login is mapped to the database user, you may need to experiment with this and filter against database_principal_name or session_server_principal_name instead of server_principal_name. I just tested this on SQL Server 2012 and it seems to work as you would expect. I don't believe it will work on 2008 or 2008 R2 (not relevant for you, but for future readers).

I still think that filtering a large portion of your activity seems suspect and not really in the spirit of auditing. You must have pretty laissez-faire auditors if they just trust that you protect your passwords for service accounts. Someone must know them, right? An auditor's job is to not inherently trust anyone.

MySQL Security – Audit DML Operations on Tables

The least disruptive method would be to use the general query log. The query log output can be a database table or a log (text) file; however it does not support filtering by DML operation or database so all SELECT statements on all databases will be logged as well. Obviously you can filter the logging output later.

Also note:

The session sql_log_off variable can be set to ON or OFF to disable or enable general query logging for the current connection.

This means that with some injected logic, you could conceivably disable logging for SELECTs.

Another solution is to use triggers on UPDATE, INSERT, DELETE. This will directly affect the database in question but not other databases running in the same instance.

Best Answer

Related Solutions

SQL Server Audit Specification – Filter DML by All But One User

MySQL Security – Audit DML Operations on Tables

Related Question