Details

    Description

      The set of desired features for the Auditing Plugin is big enough.
      And we need to recode the existing plugin significantly to make it all working.
      So v2.0

      Features planned to include in it:
      1. filter rules defined per user/role using a system table

      • this will make the parameters server_audit_events, server_audit_excl_users and server_audit_incl_users obsolete
      • thew default behavior without having filter rules defined will be to log all events and for all users
      • user should be user@host for different filtering per host

      2. Propagating Auditing Setting to log files
      For Auditing it is of value to know the settings an audit log is based on.
      When creating a new file, current settings should be added. A new event type could be used, like AUDIT_CONFIG and can be enabled via a system variable.

      In the same format current used for the auditing rows it could look like:

      20180307 22:57:20,,,,,,AUDIT_CONFIG,,'server_audit_syslog_priority=LOG_INFO',0

      3. Logging for changes of auditing settings
      As audit logging settings can be changed dynamically, should be possible to log changes to the audit settings itself, although events like QUERY are disabled ( a SET command used). The same format could be used as above, but just reporting the new value.

      4. Placeholders instead of the real values for Query Logging.
      That's needed usually for the security reasons. Particularly important for passwords.

      5. Log rotation based on days

      6. PRIVILEGES event type.

      Attachments

        Issue Links

          Activity

            danblack Daniel Black added a comment - - edited

            What i'd like in 2.0 is:

            • global variable changes
            • flush status
            • grants/revokes/create user/alter user/drop user
            • replication changes (CHANGE MASTER, STOP SLAVE..., START SLAVE) though some of these are in general error log they aren't tied to a user.
            • generally anything that required a SUPER priv

            Happy for this all to be under a the same event server_audit_events=super

            danblack Daniel Black added a comment - - edited What i'd like in 2.0 is: global variable changes flush status grants/revokes/create user/alter user/drop user replication changes (CHANGE MASTER, STOP SLAVE..., START SLAVE) though some of these are in general error log they aren't tied to a user. generally anything that required a SUPER priv Happy for this all to be under a the same event server_audit_events=super
            sujunmin Su, Jun-Ming added a comment -

            Could you consider to merge this issue? https://jira.mariadb.org/browse/MDEV-13421

            sujunmin Su, Jun-Ming added a comment - Could you consider to merge this issue? https://jira.mariadb.org/browse/MDEV-13421
            ralf.gebhardt Ralf Gebhardt added a comment -

            MDEV-11109 includes to be able to also exclude CONNECT events from logging for given users. With having user/role based filters the event CONNECT also can be excluded from logging them

            ralf.gebhardt Ralf Gebhardt added a comment - MDEV-11109 includes to be able to also exclude CONNECT events from logging for given users. With having user/role based filters the event CONNECT also can be excluded from logging them
            McMillen Ricky added a comment -

            Placeholders

            >Placeholders instead of the real values for Query Logging.
            >That's needed usually for the security reasons. Particularly important for passwords.

            I think this is a great idea! Our current use case involves the audit plugin to provide visibility of the queries executed against our databases for our data engineers. Ideally, we would like for the audit logs to be scrubbed of any sensitive data (not just passwords) before they leave our servers. Having this query redaction as first class support would be brilliant. Some sort of query fingerprinting, similar to what mysqldumpslow generates is perfect for our use case.

            Friendlier log format

            On a similar note, I have tried to parse the FILE format audit logs myself to redact queries and have found it difficult due to the log format. The format could be mistaken for CSV parsable but due to "object" portion of the log format appearing in single quotes it trips us many parsers which strictly adhere to RFC 4180. I see there is a ticket open requesting JSON support - https://jira.mariadb.org/browse/MDEV-17879. I would be interested in any improvement which makes machine parsing of these logs more straightforward.

            Is it worthwhile to have a separate ticket tracking any of these requests? Many thanks.

            McMillen Ricky added a comment - Placeholders >Placeholders instead of the real values for Query Logging. >That's needed usually for the security reasons. Particularly important for passwords. I think this is a great idea! Our current use case involves the audit plugin to provide visibility of the queries executed against our databases for our data engineers. Ideally, we would like for the audit logs to be scrubbed of any sensitive data (not just passwords) before they leave our servers. Having this query redaction as first class support would be brilliant. Some sort of query fingerprinting, similar to what mysqldumpslow generates is perfect for our use case. Friendlier log format On a similar note, I have tried to parse the FILE format audit logs myself to redact queries and have found it difficult due to the log format. The format could be mistaken for CSV parsable but due to "object" portion of the log format appearing in single quotes it trips us many parsers which strictly adhere to RFC 4180. I see there is a ticket open requesting JSON support - https://jira.mariadb.org/browse/MDEV-17879 . I would be interested in any improvement which makes machine parsing of these logs more straightforward. Is it worthwhile to have a separate ticket tracking any of these requests? Many thanks.
            ralf.gebhardt Ralf Gebhardt added a comment -

            I am closing this task, which was a collection for possible new features for the audit plugin. Separate tasks might be created

            1. filter rules defined per user/role using a system table
            2. Propagating Auditing Setting to log files
            3. Logging for changes of auditing settings

            Implemented as a new feature available in MariaDB Enterprise Audit

            4. Placeholders instead of the real values for Query Logging.
            That's needed usually for the security reasons. Particularly important for passwords.
            5. Log rotation based on days
            6. PRIVILEGES event type.

            Will be reviewed and separate tasks created

            ralf.gebhardt Ralf Gebhardt added a comment - I am closing this task, which was a collection for possible new features for the audit plugin. Separate tasks might be created 1. filter rules defined per user/role using a system table 2. Propagating Auditing Setting to log files 3. Logging for changes of auditing settings Implemented as a new feature available in MariaDB Enterprise Audit 4. Placeholders instead of the real values for Query Logging. That's needed usually for the security reasons. Particularly important for passwords. 5. Log rotation based on days 6. PRIVILEGES event type. Will be reviewed and separate tasks created

            People

              Unassigned Unassigned
              holyfoot Alexey Botchkov
              Votes:
              8 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.