Information about configuring DataStax Enterprise, including using virtual nodes; setting up security; storing
and accessing data exclusively from memory; setting up distributed data replication from remote clusters;
running multiple DataStax Enterprise nodes on a single host machine, and automating the movement of data
across different types of storage media.

DSE Advanced Security FAQs

General

What communication protocols are used?

All communication occurs over TCP sockets and can be secured by using the standard
Java Security SSL/TLS implementation in the JVM. Additional application specific
protocols like gossip and the CQL Binary Protocol rely on these sockets for transport.

DataStax Enterprise supports secure enterprise search using Apache Solr and
Lucene. The security table summarizes the security
features of DSE Search and other integrated components. See Securing DSE Search

Authentication and authorization

What are the restrictions to the default cassandra user?

By default, each installation of Cassandra includes a superuser
account named cassandra whose password is also cassandra. DataStax recommends Changing the default superuser for non-development environments.

Logins for the cassandra user are performed with QUORUM consistency.

Do not use the default cassandra user in
production, because QUORUM consistency has significant performance
degradation for multiple datacenters.

Role-based access
authenticates users based on the user association with LDAP groups or Cassandra
roles. DSE supports assigning LDAP-based users to
database groups. Any users mapped to the LDAP group can authenticate
with the cluster. For efficiency,
DataStax recommends that the target LDAP directory server have memberof support. The
specific attribute that stores the role assignment in the LDAP is configurable by the
DSE administrator. See Configuring LDAP authentication.

How are user-action permissions supported?

DSE supports standard object permission
management to assign roles specific permissions at the table level. Permissions
to access all keyspaces, a named keyspace, a table, function, or MBean can be granted to
a role.

Use the familiar relational database GRANT/REVOKE paradigm to grant or
revoke permissions to access Cassandra data. A superuser grants initial permissions,
and subsequently a role may or may not be given the permission to grant/revoke
permissions.

In general, arbitrary client programs do not access the database. Database access by
the general user population is controlled at the application layer. Application node to
database node access should be controlled by using conventional firewall mechanisms,
such as Linux iptables. However, database administrators are an exception to allow
connections from DBA hosts.

Yes, although the client certificate DN is not used as a database user principal. Client-to-node encryption protects in-flight data from client
machines to a database cluster using SSL (Secure Sockets Layer) and establishes
a secure channel between the client and the coordinator node.

When
Java Cryptography Extension (JCE) is installed, the
cipher_algorithm options and acceptable secret_key_strength values for the algorithms
are:

cipher_algorithm

secret_key_strength

AES/CBC/PKCS5Padding

128, 192, or 256

AES/ECB/PKCS5Padding

128, 192, or 256

DES/CBC/PKCS5Padding

56

DESede/CBC/PKCS5Padding

112 or 168

Blowfish/CBC/PKCS5Padding

32-448

RC2/CBC/PKCS5Padding

40-128

Can encryption keys be changed for a particular table?

Yes, by designating transparent data encryption (TDE) on a per table basis. Using encryption, your application can read and
write to SSTables that use different encryption algorithms or use no encryption at all.
Use a single ALTER TABLE statement to set encryption and compression.

Would encryption of EBS in AWS be a good replacement for using TDE, or is EBS better
as a supplement to TDE (or neither)?

EBS encryption is another way to encrypt the data files. EBS encryption ensures
encryption of audit logs, system logs, and the SSTable index files, which have partition
keys in plain text if using TDE. In general, EBS encryption may be operationally
simpler. Primarily, use TDE when full disk encryption is cost prohibitive or not
feasible.

Is encryption supported at granular data layers? For example record-level or column-
or field-level?

No. Designate transparent data encryption (TDE) only on a per table basis.

Auditing

Which user actions and events are logged?

When you configure audit logging, you can
specify which categories of audit events
(administration, authentication, DML, DDL, DCL, and query operations) to log,
and whether to omit operations against specific keyspaces from audit
logging.

Where are audit logs stored and who has access?

Audit logs can be written to either file system log files using logback, or to a Cassandra table. Audit events
stored in database tables can be secured like any other database table using RBAC.
File-based audit logs are stored per-node and can be secured with standard Linux file
system permissions. See

Information about configuring DataStax Enterprise, including using virtual nodes; setting up security; storing
and accessing data exclusively from memory; setting up distributed data replication from remote clusters;
running multiple DataStax Enterprise nodes on a single host machine, and automating the movement of data
across different types of storage media.

DataStax is a registered trademark of DataStax, Inc. and its subsidiaries in the United States and/or other countries.

Apache Cassandra, Apache, Tomcat, Lucene, Solr, Hadoop, Spark, TinkerPop, and Cassandra are trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries.