Anuj Wadehra commented on CASSANDRA-12151:

[~vinaykumarcse] My comments are as follows:
{quote}I like the idea of keeping the auditing configurations to be simple at 
keyspace level
I think enabling/disabling auditing should be at table level rather than 
keyspace level. Reasoning-Keyspaces are designed based on data replication 
needs rather than auditing needs. 
Thus, a keyspace k1 may have two tables with same replication needs but 
different auditing requirements e.g. t1 with sensitive data which must be 
audited and t2 with some temporary data which need not be audited. With 
keyspace level auditing, users will end up doing unnecessary auditing and 
cluttering of audit logs.
{quote}if we are managing any configurations at table level, config file might 
not be a good place, table property?
Agree. We can have default auditing configuration for tables in cassandra.yaml 
(say enable_audit=true/false, categories=DDL,DCL etc.,extended=true/false etc.) 
and table level properties to override the default auditing options in yaml. 
This way we will not clutter cassandra.yaml with tables to be audited, there 
would not be any additional configuration file and Cassandra configuration 
files would not have any application schema awareness.
{quote}All the usecases that I see here are Auditing at the cluster or no 
auditing, but not specific to user.
If a Cassandra role defined for an application user has limited permissions, 
you may not want to audit everything from the application and clutter the 
auditing logs. 
But If you have a single powerful application user for database, the feature 
may not be that useful as the application user may be misused and you may 
easily bypass the application and directly login to cqlsh. I dont think 
Cassandra has an authentication mechanism to identify and restrict direct login 
for specific application users/roles. In case of direct login using an 
application user, you will log the operation but will not be able to fix the 
responsibility of the operation. More thoughts?
{quote}This would be a security concern to keep the actual data in logs
If you are logging the exact query with all the values in case of regular 
queries (not prepared), then how would logging bind values of a prepared 
statement becomes a security concern?
If we think logging individual statement in the batch might not come for free, 
I would rather approach it differently in case of batch, we just limit it to 
log only statement types and its count or just the prepared statement ids?
Can we only log unique query strings in a batch to restrict IO? In case of a 
batch with prepared statements and extended configuration set to true, audit 
log format could be:

Q1: INSERT INTO t1(variable1,variable2) values(?,?)
Q2: INSERT INTO t2(variable1,variable2,variable3) values(?,?,?)

Q1 [bind_value1,bind_value2]
Q2 [bind_value1,bind_value2,bind_value3]
Q1 [bind_value1,bind_value2]
Q1 [bind_value1,bind_value2]
If separate log statements are used, UUID may be associated with the batch 
(like it is done in your patch)
{quote}Why do you think logging CL is required? Is CL adding any value for the 
What are your thoughts on this?


> Audit logging for database activity
> -----------------------------------
>                 Key: CASSANDRA-12151
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12151
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: stefan setyadi
>            Assignee: Vinay Chella
>            Priority: Major
>             Fix For: 4.x
>         Attachments: 12151.txt, 
> DesignProposal_AuditingFeature_ApacheCassandra_v1.docx
> we would like a way to enable cassandra to log database activity being done 
> on our server.
> It should show username, remote address, timestamp, action type, keyspace, 
> column family, and the query statement.
> it should also be able to log connection attempt and changes to the 
> user/roles.
> I was thinking of making a new keyspace and insert an entry for every 
> activity that occurs.
> Then It would be possible to query for specific activity or a query targeting 
> a specific keyspace and column family.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to