DSE Advanced Security FAQs
- 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, for a list of ports used by DSE see Securing DataStax Enterprise ports.
- What are the restrictions to the default cassandra user?
The cassandra default account has access to all database resources. When logging in or performing an action, DSE sets the consistency level to
QUORUMfor this account. In a production environment, using the cassandra account may negatively affect performance and encounter failures. DataStax recommends Adding a superuser login immediately after enabling DSE Unified Authentication with role based access control.
- How are user permissions managed?
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 Role Based Access Control.
- How are user groups supported?
DSE supports role management based on LDAP group membership.
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.
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.
For efficiency, DataStax recommends using the
memberofsearch method for group lookup; however DataStax also supports directory search.
- How are user-action permissions supported?
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 Setting up logins and users.
- What authentication mechanisms are supported?
Internal: Connections provide credentials for a role that has an internally stored password. No additional configuration is required. See Setting up logins and users.
LDAP: Connections provide LDAP credentials. DSE passes the credentials for verification to LDAP. See Defining an LDAP scheme.
Kerberos: Connections provide a Kerberos ticket. DSE is configured as a Service Principal (see Setting up Kerberos) and passes the tickets to the Key Dsitribution Service (KDS) for verification. See Defining a Kerberos scheme.
- What LDAP servers are supported?
Microsoft Active Directory, OpenLDAP, and Oracle Directory Server Enterprise Edition. See Defining an LDAP scheme.
- Can access be restricted using IP accesslisting and blocklisting?
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.
- What granularity of access to specific elements of data is supported?
Authorization is granted or revoked at the row level for data.
- What is the difference between RBAC and RLAC
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.
For details, see setting up row-level permissions.
- How do I restrict access to a row?
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>;
After setting the column name, use the GRANT command to configure access to rows.
- Can I unrestrict access to rows in a table with RLAC authorization?
The partition key to filter on using GRANT can be unselected from the table:
UNRESTRICT ROWS ON [<keyspace_name>.]<table_name> USING <partition_key>;
Use the LIST command on the table to display all roles that have been granted permissions.
Unrestricting the column does not grant access to all columns within the table; it invalidates existing filters. Users that are granted access with a filter are unable to access any rows within the table. To grant permissions to all rows, grant permission on the table to the role.
- How do I grant permissions for rows in a table?
Configure access to rows within a table by specifying a filtering string that is applied to the partition key column selected in the
RESTRICTcommand. 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
RLACgrant 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>;
Use the LIST command to display all permissions a role has on a resource.
- How do I revoke permissions for rows in a table?
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>;
LIST ALL PERMISSIONS ON TABLE <table_name> shows all filters granted to roles.
- What happens if you run a RESTRICT command on a table that already has a restriction?
Tables have only a single restriction. Running the
RESTRICTcommand replaces the existing restriction. Use
DESCRIBE TABLEto view the existing restrictions on the table.
- What happens if there a role has access to the keyspace/table level and I grant row access?
Permission is hierarchical, if permission was also granted to the keyspace or table the user has access to all rows in the table. The
RLACpermissions have no affect.
- Is RLAC supported for use with DSE Graph?
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';
Permissions are not enforced. RLAC is not supported for use with DSE Graph.
Granting access on rows in a table provides access to data in all graph keyspaces.
- How are encryption keys secured and managed?
Encryption keys can be managed off-server or locally:
- Can the client-to-node encryption be configured as a two-way SSL?
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.
- How is encryption of at-rest data supported?
Protects sensitive at-rest data using a local encryption key file or remotely stored and managed Key Management Interoperability Protocol (KMIP) encryption key.
- 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 TABLEstatement 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 when 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.
- Which user actions and events are logged?
- 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 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.