Security beyond authentication and authorization

The security afforded by Cassandra-level authentication and authorization only applies to clients connecting directly to your Cassandra cluster. Anyone who has physical access to the machines running Cassandra can access the data stored on disk; the same goes for anyone with SSH access to machines in the Cassandra cluster. Cassandra itself does not offer encryption for on-disk data, but DataStax Enterprise, a commercial distribution of Cassandra, does offer encryption of at-risk data. For more information, consult http://www.datastax.com/documentation/datastax_enterprise/4.5/datastax_enterprise/sec/secTDE.html.

Data security can also be compromised in transit; anyone who can intercept traffic between your application and your Cassandra cluster can potentially gain unauthorized access to your data. Cassandra offers client-to-node SSL encryption that protects your data in transit between your application and your cluster. For information on setting up client-to-node encryption, see http://www.datastax.com/documentation/cassandra/2.1/cassandra/security/secureSSLClientToNode_t.html.

Finally, normal operation of Cassandra involves passing data between different nodes in the cluster; if attackers can intercept inter-node communication, they can gain access to your data. Cassandra has the ability to encrypt all node-to-node traffic; for information on configuring node-to-node encryption, see http://www.datastax.com/documentation/cassandra/2.1/cassandra/security/secureSSLNodeToNode_t.html.

Security protects against vulnerabilities

We've covered authentication and authorization in depth and also mentioned a few other security measures available in Cassandra or DataStax Enterprise. However, not every deployment will need every security measure in place. What security measures you need depends on the sensitivity of your data and the security characteristics of your deployment. As an application engineer, you likely leave the details of deployment security to your sysadmins, but this table can provide a quick reference to what sort of security measures you should think about:

Security measure	Vulnerability protected against	Alternative protections
Internal authentication & authorization	Direct access to Cassandra cluster via CQL binary protocol	Restrict access to the Cassandra cluster to secure the private network
On-disk data encryption	Shell access to machines hosting the Cassandra cluster	Restrict shell and physical access to Cassandra hosts
Client-to-node encryption	Network link between the application and the Cassandra cluster	Restrict access to private network traffic using encryption or physical isolation
Node-to-node encryption	Network link between Cassandra nodes	Restrict access to private network traffic using encryption or physical isolation

It's quite plausible that, with both your application and Cassandra deployment protected by a well-secured VPN, you may not need to concern yourself with any database-level security measures.