DSE Advanced Security FAQs

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, for a list of ports used by DSE see Securing DataStax Enterprise ports.

All permissions granted to roles that reflect LDAP groups to which the user belongs – directly or indirectly – are inherited. The inherited permissions include login permission, scheme permissions, proxy execution permissions, and object permissions.

The cassandra default account has access to all database resources. When logging in or performing an action, DSE sets the consistency level to QUORUM for this account. In a production environment, using the cassandra account may negatively affect performance and encounter failures. DataStax recommends Creating superuser accounts immediately after enabling DSE Unified Authentication with role based access control.

Superuser permissions allow creation and deletion of other users, and the ability to grant or revoke permissions. Use the default cassandra user only to assist with the initial setup of new users and superusers, and then disable it. The DSE Role Manager determines which roles to assign to authenticated users. See About roles.

DSE supports role management based on LDAP group membership. Configure an LDAP scheme with group lookup, set the Role Management mode option to LDAP, and create roles that match the group names and then assign permissions. See Defining an LDAP scheme.

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

Microsoft Active Directory, OpenLDAP, and Oracle Directory Server Enterprise Edition, see Defining an LDAP scheme.

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.

Authorization is granted or revoked at the row level for data.

Role-based access control (RBAC) refers to authorization to any database resource including row-level access control (RLAC). Row-level access control refers to the feature that allows permissions to be granted/revoked on rows within a table by filtering a text-based partition column.

Each table can have a single UTF-8 partition key column on which you build filters to grant access (separate command) to rows within the table. RESTRICT only sets the filtering column name:

RESTRICT ROWS ON [<keyspace_name>.]<table_name>
USING <partition_key>;

The partition key to filter on using GRANT can be unselected from the table:

UNRESTRICT ROWS ON [<keyspace_name>.]<table_name>
USING <partition_key>;

Configure access to rows within a table by specifying a filtering string that is applied to the partition key column selected in the RESTRICT command. Use case-sensitive literal text in the filter string. Row-level authorization applies only to rows that exactly match the filtering_data. You can create as many RLAC grant variations as required by your security policies. To allow access to rows within a table:

GRANT <permission>
on '<filtering_data>' ROWS IN <keyspace_name>.<table_name>
to <role_name>;

Row permissions are stored based on the filtering string, to remove a permission use the REVOKE command with the exact filtering string you want to remove:

REVOKE <permission> on '<filtering_data>' ROWS IN <keyspace_name>.<table_name>;

Tables have only a single restriction. Running the RESTRICT command replaces the existing restriction. Use DESCRIBE TABLE to view the existing restrictions on the table.

Permission is hierarchical, if permission was also granted to the keyspace or table the user has access to all rows in the table. The RLAC permissions have no affect.

No. Although permissions are shown and errors are not thrown with this statement:

GRANT SELECT ON 'custom_key' ROWS IN graph_keyspace.graph_table to 'alice';

Encryption keys can be managed off-server or locally:

Yes, although the client certificate DN is not used as a database user principal.

Protects sensitive at-rest data using a local encryption key file or remotely stored and managed KMIP encryption key.

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.

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.

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

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

Audit logs can be written to either file system log files using logback, or to a database 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