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.
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.