[
https://issues.apache.org/jira/browse/CASSANDRA-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145834#comment-13145834
]
Richard Lowe commented on CASSANDRA-2274:
-----------------------------------------
I'd forgotten about the encryption options. Enabling encryption would certainly
prevent against rogue nodes entering the cluster (unless they had a valid key)
but I can't see how it prevents attacks from trusted nodes, i.e. through a
malicious/erronous/compromised app or user action. Such nodes would still be
able to request an action that could (or should) require specific privileges.
In our particular use case a drop of a keyspace without the authority to do so
would be very bad, whilst it sounds like the original reporter of this issue is
concerned about the potential for leaking data through unauthorized reads. I'd
be surprised if there weren't other applications for which deleting the
database wouldn't cause a problem; at the very least it means downtime to
restore from the last set of snapshots.
Also, how would the use of encryption work in a multi-tenant environment? Would
each tenant have their own set of encryption keys? Does this sort of
segregation of the cluster cause problems in terms of gossip and thrift
messaging?
The standard practice of rolling encryption keys might be difficult as well,
requiring each node to be stopped and restarted for updates to its keystore to
take effect. This doesn't satisfy the desire for the provision of security to
be dynamically applied, as Andrew Scheifelbein described previously.
If a key becomes compromised then a receiving node will still honor a sender's
request because it doesn't attempt to do any verification that the sender has
the authority to performing the action it is requesting be executed.
Encryption gets us quite a lot of the way, but it doesn't get us the whole way
there in terms of ensuring a node is only able to perform the actions it is
authorized to do so upon the cluster.
> Restrict Cassandra cluster node joins to a list of named hosts
> --------------------------------------------------------------
>
> Key: CASSANDRA-2274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2274
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.2
> Environment: All
> Reporter: Andrew Schiefelbein
>
> Because firewalls and employees are not infallible it would be nice to
> restrict the ability of any node to join a cluster to a list of named hosts
> in the configuration so that someone would be unable to start a node and
> replicate all the data locally. I understand that in order to do this the
> person must know the seed servers and the cluster name and to extract the
> data they will need a userid and password but another level of security would
> be to force them to execute any brute force attack from a locked down server
> instead of replicating all the data locally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
