cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Lynch (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12151) Audit logging for database activity
Date Sat, 03 Mar 2018 06:37:00 GMT


Joseph Lynch commented on CASSANDRA-12151:

There are a lot of competing desires in this ticket, and I want to firmly +1 an incremental
approach where we get the basic interface in and start adding new implementations or configuration
options in follow up items. If I understand the comments above we're trying to solve the following
all in one ticket:
 # Logging for security
 # Logging for business accounting compliance (e.g. SOX).
 # Logging for monetary transaction compliance (e.g. PCI).
 # Logging for replay later (e.g. for correctness testing)

These require different implementations because they require different tradeoffs, and they
may not all get done in this ticket. For example, CASSANDRA-13983 is focused on use case #4
and appears to use a highly optimized binary format which is lower overhead but does not meet
requirements for #1/2/3 and requires custom parsers (you can't just hand the file to the auditors),
whereas the patch [~vinaykumarcse] has provided I believe aims more for #1/2/3. Generally
#2/3 require guarantees of logging if a query was attempted, regardless of it succeeded, and
#2/3 generally require a lot more context than #1/#4 do. I think it would be great if in this
ticket we can commit the basic interface and starting points of the configuration options
(e.g. is it controlled through the cassandra.yaml or table options), and we can work on improving
performance, configuration flexibility, etc in follow up tickets.

[~jasobrown] wrote:
{quote}I agree with [~djoshi3] and [~jjordan]: this functionality should really leverage the
existing behavior of FQL (CASSANDRA-13893). There is no need to create a parallel or duplicate
set of behaviors, unless it's completely warranted - and I have heard no arguments here that
it is.
Do you think the patch creates a parallel or duplicate set of behaviors? It provides a different
query logging implementation that makes different tradeoffs and targets a different use case,
but I think everyone is agreeing that we can unify the two behind one interface (we just have
to make sure that interface has enough query context for all use cases which might be tough
as FQL really doesn't need all the session context like user info but #1,2,3 do).

[~eanujwa] wrote:
{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?
Generally speaking secure applications exclusively use prepared statements as simple statements
are vulnerable to injection. Also, if you're using audit logging for PCI (or even SOX) the
data in DML could easily be sensitive (e.g. credit cards or user's names), which you probably
want to avoid by default. It could certainly be an option though.

[] wrote:
{quote}Usually you'll see two kind of users on production systems: privileged users and application
users. Auditing privileged users (admins or developers) will almost always make sense, in
order to be able to detect unauthorized access and data manipulation. There's only a limited
amount of statements to log, as these will be executed manually. It also shouldn't matter
which keyspaces or tables are access by the users; he is either monitored or not.
Doesn't the category filter adequately achieve this (you could exclude DML or QUERY)? Do we
need per user query logging when there is already per user permissions limiting their access
to the database in the first place?
{quote}However, auditing queries of application users has a very limited security and data
privacy benefit, but adds a great deal of load to the database. Those queries will be automatically
generated by the application and there will be no way to tell if the query or statement was
authorized, as you don't know on behalf of whom it was executed. Any auditing functionality
for these operations must therefor take place at application level.
While I agree use case #1 (security) does not require this, use cases #2 and #3 very much
do. For #2 or similar you typically have to prove that only authorized applications manipulated
the database and a typical way to do that is to produce query logs showing that only trusted
application IP addresses and specific credentials made DML statements (but QUERY is less important).
For #3 the requirements are even greater, e.g. you may have to be able to prove that user
data was not exfiltrated at all, requiring auditing of QUERY statements. Yes it's higher overhead
but if you can turn it off with the category filters I think it's fine don't you?

> 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