cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anuj Wadehra (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12151) Audit logging for database activity
Date Fri, 02 Mar 2018 15:08:00 GMT


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 auditor?
What are your thoughts on this?


> Audit logging for database activity
> -----------------------------------
>                 Key: CASSANDRA-12151
>                 URL:
>             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:
For additional commands, e-mail:

View raw message