You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Per Otterström (JIRA)" <ji...@apache.org> on 2018/05/08 11:26:00 UTC
[jira] [Comment Edited] (CASSANDRA-12151) Audit logging for
database activity
[ https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467079#comment-16467079 ]
Per Otterström edited comment on CASSANDRA-12151 at 5/8/18 11:25 AM:
---------------------------------------------------------------------
bq. This is an intersting idea. However, I'm reticent to introduce CQL grammar changes this late into this ticket. As a followup, I think this could be worth exploring.
Sure, I understand we seek to close this ticket. I'm just a bit concerned with the timing. If this ticket is merged as is and we take a cut for 4.0, then I assume we will have to stick to this way of configure audit logs for some time.
bq. While there's some conceptual overlap, I don't think it's a good idea to try to force the concepts of 'audit logging' and 'auth' onto one another here.
I believe it depends on the use case for doing audits. In some cases it would make perfect sense to have these two concepts in sync. E.g. I want to grant a user to have SELECT permission on a specific table. Then I would grant the same user to have NOAUDIT for SELECT on the very same table. Should the user try to read somethign else, or write to that table, an audit entry would be created. In a case like this it is very helpful for the admin to use the same concepts for these two "permissions".
To verify accuracy, should we create some dtests for this as well?
was (Author: eperott):
bq. This is an intersting idea. However, I'm reticent to introduce CQL grammar changes this late into this ticket. As a followup, I think this could be worth exploring.
Sure, I understand we seek to close this ticket. I'm just a bit concerned with the timing. If this ticket is merged as is and we take a cut for 4.0, then I assume we will have to stick to this way of configure audit logs for some time.
bq. While there's some conceptual overlap, I don't think it's a good idea to try to force the concepts of 'audit logging' and 'auth' onto one another here.
I believe it depends on the use case for doing audits. In some cases it would make perfect sense to have these two concepts in sync. E.g. I want to grant a user to have SELECT permission on a specific table. Then I would grant the same user to have NOAUDIT for SELECT on the very same table. Shoudl the user try to read somethign else, or write to that table, and audit entry would be created. In a case like this it is very helpful for the admin to use the same concepts for these two "permissions".
To verify accuracy, should we create some dtests for this as well?
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org