Apache Cassandra Data Security Management

Security Management

In all the NOSQL DATABASES, Security has been a weak point. No NoSQL database provides complete security.

After recognizing this weak point in Cassandra and due to very high demands from customers and the open source community, Apache Cassandra and Datastax enterprise decided to provides a security feature in Apache Cassandra and DATASTAX enterprise.

Authentication

Cassandra supports internal-based authentication that allows you to easily create users who can be authenticated to Cassandra database clusters. You’ll find the authentication framework extremely familiar – it uses the RDBMS-style CREATE/ALTER/DROP USER commands to create/manage with passwords that will then be internally handled by Cassandra. A default superuser, ‘cassandra’, is supplied by default to initially enable the security authentication definition process.

You can also use external, 3rd party security packages like Kerberos to manage security in DataStax Enterprise.

Permission Management

Object permission/authorization capabilities for Cassandra utilize the very familiar GRANT/REVOKE security paradigm – something you should have no problem using as a DBA. Control over DDL, DML, and SELECT operations are all handled via the granting and revoking of user privileges.

Note that a GRANT may be done with or without the GRANT OPTION, which allows the user receiving the grant to grant the same privileges on that object to other users just as it occurs in the RDBMS world.

Encryption

There are multiple levels of encryption offered in both Cassandra and DataStax Enterprise that you can use to protect data. First, Cassandra includes an optional encrypted form of communication from a client machine to a database cluster. Client to server SSL ensures data in flight is not compromised and is securely transferred back/forth from client machines.

Frequently asked Cassandra Interview Questions & Answers

Next, node-to-node encryption can be used as well to ensure data is protected as it is transferred between nodes in a database cluster.

Lastly, transparent data encryption (TDE) in DataStax Enterprise protects data at rest from being stolen and used in an unauthorized manner. You can encrypt tables with AES 128 being the default, although other encryption algorithms can be used.

Encryption is transparent to all end user activities; data may be read, inserted, updated, etc., with nothing having to change on the application end.

Data Auditing

DataStax Enterprise 3.0 and above supports the ability to perform data auditing on a database cluster. Data auditing allows an administrator to understand “who looked at what/when” and “who changed what/when”. It basically enables the logging of some or all the user activity that occurs on a database.

Many businesses and organizations today have either external mandates or internal security policies that require the auditing of user actions on a database, so having a built-in way to accomplish this with DataStax Enterprise is helpful to administrators in such environments.

The granularity of activities that can be audited include:

• All activity (DDL, DML, queries, errors)
• DML only
• DDL only
• Security changes (assigning/revoking privileges, dropping users, etc.)
• Queries only
• Errors only (e.g. login failures, etc.)

You can also omit certain key spaces from being audited if you choose and only focus on keyspaces in production or those that are of particular interest. Audit data can be written to log files or Cassandra tables and queried via CQL.