Vinay Chella commented on CASSANDRA-12151:

Hi [~spo...@gmail.com],

Sorry, was away from work for last few days. If we are filtering users, to log 
any of these failures/ failed attempts, we can include {{system}} user in 
include filters.
{quote}question regarding how we should go on with prepared statements. Cause I 
can't see how we can get away with not logging these, if we want to address any 
compliance or security use cases.
As you also suggested on this thread previously, either filtering based on log 
entry types or ParameterizedClass for logger should address this concern. I 
will open followup JIRAs as soon as we close this PR to keep the changeset 
moderate at this moment. 

Sounds like a plan?

> 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, CASSANDRA_12151-benchmark.html, 
> 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