[
https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386137#comment-16386137
]
Stefan Podkowinski commented on CASSANDRA-12151:
------------------------------------------------
[~eanujwa] wrote:
{quote}If auditing for a database application user is only at application
level, what would happen in case direct queries are executed on the database
using the the application user credentials (using tools such as cqlsh)?
{quote}
If the operator decided not to enable audit logging for the application users,
nothing would get logged. If someone steals the credentials, none of the
activities would show up in the logs. If you think that this is unacceptable,
then you can enable auditing for the app user as well, which I would not, but
it’s really up to you.
[~jolynch] wrote:
{quote}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}
Although I understand the motivation behind the query categories from a
developer perspective, it’s probably a feature that is not as easy to
understand and handled by operators. Let alone managers and compliance
officers, who lack the technical understanding for discussing which categories
needs to be enabled for which tables. Once you’ll notice that you have to limit
the audit logging due to the performance impact, it’s going to be a rather
painful discussion how categories and tables should be configured in this
regard. I’d rather give ops people more simpler options that are easy to
understand and reason about, when discussed between ops and non-technical
stakeholders. Offering “all or nothing” audit logging on user basis would fit
this requirements for me (at least for CQL, login events could be a different
story).
I'd also really like to avoid luring people into the idea that Cassandra would
be a one-stop solution for audit logging and you don't have to implement your
own logging on application level anymore, since Cassandra does handle this for
you. It probably won't, as logging all statements for applications will be too
much of a performance impact. Now the question for me is to offer operators
options to optimize their way out of this situation, or simply tell people that
it's not possible to handle this use-case (audit logging for application users
on high-load systems) in Cassandra. I'd clearly go with the later, as many
users think that Cassandra already puts too much of a burden on operators.
{quote}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?
{quote}
Can you really “prove” unauthorised data manipulation did *not* happen through
the audit logs? Say I have an application that is updating a credit score and
now I use that user to do an update manually, how would you ever notice that
from the audit logs? My manual statement looks just like the million others
executed by the app. IP based access restrictions should be in place anyways,
that’s also not something that would necessarily give you additional clues.
As was already suggested, let’s take an incremental approach that will allow us
to introduce a simple audit logging that can be understood by both technical
and non-technical people and configured in little time. If any external
compliance authority raises some concerns, e.g. that DCL statements need to be
handled differently from queries, we can take care of that. But any 90%
solutions would still be a big win over what we currently have.
> 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
