[
https://issues.apache.org/jira/browse/CASSANDRA-14471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16515729#comment-16515729
]
Per Otterström commented on CASSANDRA-14471:
--------------------------------------------
Thanks for your feedback.
bq. Trying to treat audit logging in a similar way to the roles/permissions
seems wrong to me. The 2 have completely different logic and should be clearly
separated at the code level.
To me there is a clear connection since Auditing (or Accounting) is often
related to Authentication and Authorization -
([AAA|https://en.wikipedia.org/wiki/AAA_(computer_security)]). However, to make
sure it is working as a stand-alone feature for other use cases we could
persist things in a separate keyspace, and keep it separate at code level.
bq. The MUTE/UNMUTE syntax is in my opinion confusing.
I'm not really happy with {{MUTE/UNMUTE}} either, but it's what I've come up
with so far. I'm open to better suggestions.
bq. It is also limited because it only allow you to do a white list approach.
Actually, that was intentional. IMO it is hard to overlook the result when
setting up filters using the current mix of includes/excludes on
keyspaces/categories/users. Having everything included by default, and then
whitelist selected parts seem much more straight forward. Also this fit the
primary purpose of audits well. IMO everything should be accounted for, unless
explicitly excluded.
bq. The approach that you would like to use for persisting the whitelists is
risky. If one of your node cannot get the data from the configuration table it
might be unable to start (this problem is an existing one with the current auth
framework).
There is no reason to prevent it from starting up just because data is not
accessible at startup. At worst the filter component would not be able to load
whitelists from the database which would lead to unwanted audit records. From a
AAA perspective this is a reasonable fallback solution. Considering the
caching-solution we in place for the auth framework, is this a problem for
users in production?
bq. I would rather prefer a syntax similar to what Transact-SQL is doing.
Interesting reference! So from what I can understand the administrator can do
{{CREATE SERVER AUDIT}} which roughly corresponds to the settings we have for
{{logger}} and {{audit_logs_dir}} in the yaml file and then {{CREATE DATABASE
AUDIT SPECIFICATION}} which corresponds to the filtering part that we're
addressing in this ticket.
Here is a simple but expressive example I've found (slightly modified):
{{CREATE DATABASE AUDIT SPECIFICATION Audit_Pay_Tables}}
{{FOR SERVER AUDIT Payrole_Security_Audit}}
{{ ADD (SELECT , INSERT ON HumanResources.EmployeePayHistory BY dbo )}}
{{ ,ADD (SELECT , INSERT ON HumanResources.EmployeeSalary BY dbo )}}
{{WITH (STATE = ON) ;}}
Basically, this syntax make it possible to group conditions together under a
label and associate that with a "backend".
One thing I don't like with this approach is the fact that everything is exempt
from audit logging until the administrator explicitly creates and audit
specification for the operation/resource/role combination.
> Manage audit whitelists with CQL
> --------------------------------
>
> Key: CASSANDRA-14471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14471
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Per Otterström
> Priority: Major
> Labels: audit, security
> Fix For: 4.0
>
>
> Since CASSANDRA-12151 is merged we have support for audit logs in Cassandra.
> With this ticket I want to explore the idea of managing audit whitelists
> using CQL.
> I can think of a few different benefits compared to current yaml-based
> whitelist/blacklist approach.
> * Nodes would always be aligned - no risk that node configuraiton go out of
> sync as tables are added and whitelists updated.
> * Easier to manage whitelists in large clusters - change in one place and
> apply cluster wide.
> * Changes to the whitelists would be in the audit log itself.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
