[
https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383672#comment-16383672
]
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
{quote}
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?
{quote}
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.
{quote}
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
{quote}
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?
{quote}
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?
{quote}
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?
{quote}
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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
