DataStax Enterprise security checklists

Lists of security measures required for protecting a DataStax Enterprise database.

DSE Advanced Security is a feature suite that fortifies DataStax Enterprise (DSE) databases against potential harm due to deliberate attack or user error. It includes advanced mechanisms for authentication and authorization, encryption of data in-flight and at-rest, and data auditing. In addition, DataStax Enterprise is compatible with various partner security solutions to meet industry specific requirements and other advanced requirements.

DSE Advanced Security leverages enterprise standards to integrate cohesively with existing technology such as Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Kerberos, Public Key Infrastructure (PKI), and Key Management Interoperability Protocol (KMIP).

DataStax Enterprise includes advanced data protection for enterprise-grade databases:


Feature	Database	Search	Analytics	Graph
Authentication (External LDAP or internal)	Yes	Yes	Yes	Partial
Kerberos authentication	Yes	Yes	Yes	Yes
Authorization (RBAC)	Yes	Partial	Partial	Yes
Row-level permissions (RLAC)	Yes	No	Yes	No
Client-to-node encryption	Yes	Yes	Yes	Yes
Node-to-node encryption	Yes	Yes	Yes	Yes
Transparent data encryption	Yes	Yes	No	Yes
Data auditing	Yes	Yes	Partial	Yes

Note: Some DataStax drivers provide Kerberos support and SSL for client/server communication. Download drivers from DataStax Academy.

DSE database security checklist

Secure transactional nodes using DataStax Enterprise security features.

Security for DataStax Enterprise database nodes:

Authentication:
Limit connections to the database to only known users. DSE supports user validation with the following authentication methods:
- Internal: Credentials stored in the internal database
- LDAP: External LDAP service, such as Active Directory
- Kerberos: MIT Kerberos tickets checked against an external Key Distribution Server (KDS)
See Configuring DSE Unified Authentication.
Restriction: DSE Unified Authentication is only supported for database connections. To authenticate internode communication, such as gossip, use node-to-node SSL certificates.
Authorization:
Restrict access to database resources for authenticated users with role-based access control (RBAC). DSE supports role management using the following methods:
- Internal database: 1-1 mapping of user name or principal name to roles
- LDAP: 1-many mapping, where users are assigned all roles that match groups they are members of in LDAP
DataStax only supports RBAC with authentication enabled. See Setting up logins and users and Assigning permissions.
Audit activity:
Log and monitor activity for database resources, see Setting up database auditing.
Transparent data encryption (TDE):
Protect data at-rest. DSE provides encryption for sensitive data by encrypting:
- Entire tables (except for partition keys which are always stored in plain text)
- SSTables containing data, including system tables (such as system.batchlog and system.paxos)
- Search indexes
- File-based Hints (in DSE 5.0 and later)
- Commit logs
- Sensitive properties in dse.yaml and cassandra.yaml
Encrypt data using an external KMIP or local service, see About Transparent Data Encryption.
Encrypt data in-flight using SSL
Secure communication between clients and the database and between nodes in a cluster, see Configuring SSL.

DSE Search security checklist

Securing DSE Search.

server.xml

The default location of the Tomcat server.xml file depends on the installation type:

Package installations	/etc/dse/tomcat/conf/server.xml
Tarball installations	`installation_location`/resources/tomcat/conf/server.xml

DataStax Enterprise supports secure enterprise search. DataStax Enterprise security checklists summarize the security features of DSE Search and other integrated components.

Authentication
DataStax recommends using Kerberos authentication with the Solr Admin UI and when running commands with cURL using the SolrJ API.
- To authenticate DSE Search clients with Kerberos authentication, use Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO).
- To use the SolrJ API against DSE Search clusters with Kerberos authentication, client applications must use the SolrJ-Auth library and the DataStax Enterprise SolrJ component as described in the solrj-auth-README.md file.
- Perform index management tasks with the CQL shell using Enabling DSE Unified Authentication.
Authorization
Use role-based access control (RBAC) for authenticated users to provide search index related permissions, see Setting up logins and users and Controlling access to search indexes. Setting row-level permissions with row-level access control (RLAC) is not supported for use with DSE Search or DSE Graph.
Audit activity
Log and monitor activity for database resources, see Setting up database auditing.
Transparent Data Encryption (TDE)
Protect data at-rest. DSE provides KMIP or local encryption for sensitive data in search indexes, see Encrypting Search indexes.
Encrypt data in-flight using SSL
Encrypt connections using SSL between HTTP clients and CQL shell to with client-to-node encryption on the DSE Search node. See Configuring SSL.
Note: To satisfy specific security requirements with SSL, you can change the IP address for client connections to DSE Search. For example, to isolate a subnet.

Note: Security configuration on a DSE Search node is managed by the DataStax Enterprise configuration. Additional configuration is not required for Tomcat and Solr. Change your web.xml or files only for custom advanced setups.

Restriction: DSE Search security features have the following limitations:

TDE: Cached data is not encrypted. Encryption occurs only in the DSE database and impacts performance slightly.
Authorization: Permissions apply only to CQL requests, such as search index management and access to data stored in the database. Permissions do not apply to search file resources such as the cache and index configuration.
Setting row-level permissions with row-level access control (RLAC) is not supported for use with DSE Search.
HTTP access to the DSE Search data is protected using SSL (client-to-node encryption). Node-to-node encryption using SSL protects internal Solr communication.

DSE Analytics security checklist

Securing DSE Analytics.

DataStax recommends the following security practices:

Enable client-to-node encryption using SSL.
Spark ports for internode communications should run within a secured network without exposure to outside traffic.

Secure DataStax Enterprise Analytics nodes as follows:

Authentication:
- Distinct secrets for internode and per application, see .
- Native authentication for users of each application executor (run as) and isolation of related data, see .
- Spark UI internal or LDAP authentication, see .
- User authentication for Spark jobs. DataStax Enterprise supports internal, LDAP, and Kerberos authentication for Spark.
  - Internal and LDAP: For DataStax Enterprise Spark applications and tools, use the Spark authentication commands to provide the authentication credentials, see Running spark-submit job with internal authentication.
  - Kerberos: Defining a Kerberos scheme applies to connecting Spark to DSE database, not authenticating Spark components between each other. The Spark Web UI is not secured, so some parameters passed to the executor in the command line might be visible. However, the DSE username, password, and delegation token are hidden. By default, when Kerberos is the only authentication scheme, the Spark UI is inaccessible, so UI authorization must be disabled.
Authorization:
Data pulled from the database for Spark jobs and access control for Spark application submissions is protected by role-based access control (RBAC). The user running the request must have permission to access the data through their role assignment.
Note: No authorization for the Spark UI master and workers is available.
Auditing:
- Analytic operations performed in Spark are recorded to the Spark Event log, to enable see .
- CQL requests are recorded in the database logs, see Setting up database auditing.
Transparent Data Encryption (TDE):
TDE applies only to data stored in the database. DSE does not support encrypting data that is used by Spark and stored in DSEFS or local temporary directories.
Encrypt data in-flight using SSL, TLS, or SASL:
SSL/TLS: Client-to-node encryption protects data in flight for the Spark Executor to DSE database connections by establishing a secure channel between the client and the coordinator node. SSL does not require setting up a shared authentication service. You need to prepare server certificates and enable client-to-node SSL.
SASL: Spark internode and client-to-cluster communication can be encrypted using the SASL Digest-MD5 mechanism for mutual authentication and encryption. SASL encryption is also available for communicating among Spark driver, Spark executors, and the external shuffle service (ExternalShuffleService). See Securing Spark connections for details.

DSE Graph security checklist

Secure DSE Graph data completely or partially using DataStax Enterprise security features.

cassandra.yaml

The location of the cassandra.yaml file depends on the type of installation:

Package installations	/etc/dse/cassandra/cassandra.yaml
Tarball installations	`installation_location`/resources/cassandra/conf/cassandra.yaml

remote.yaml

The location of the remote.yaml file depends on the type of installation:

Package installations	/etc/dse/graph/gremlin-console/conf/remote.yaml
Tarball installations	`installation_location`/resources/graph/gremlin-console/conf/remote.yaml

DataStax Enterprise supports secure enterprise graph-database operations. DSE Graph data is completely or partially secured by using DataStax Enterprise security features:

Authentication:
Allow only authenticated users to access DSE Graph data by enabling DSE Unified Authentication on the transactional database and configure credentials in the DSE Graph remote.yaml, see Using DSE Graph and Gremlin console with Kerberos.
Authorization:
Limit access to graph data by defining roles for DSE Graph keyspaces and tables, see Controlling access to Graph keyspaces.
Note: RBAC does not apply to cached data. Setting row-level permissions with row-level access control (RLAC) is not supported for use with DSE Search or DSE Graph.
Grant execute permissions for the DseGraphRpc object to the defined roles.
Audit activity:
Log and monitor activity for DSE Graph related database resources, see Setting up database auditing.
Transparent Data Encryption:
Encrypt data in DSE Graph index tables, see Transparent data encryption
Note: Cached data is not encrypted. Encryption may slightly impact performance.
Encrypted database connections using SSL:
Encrypt inflight DSE Graph data. Enable SSL client-to-node encryption on the DSE Graph node by setting the client_encryption_options in the cassandra.yaml file, see Client-to-node encryption.
Tip: To configure the Gremlin console to use SSL, when SSL is enabled on the Gremlin Server, edit the connectionPool section of remote.yaml. See remote.yaml configuration file. For related information, refer to the TinkerPop security documentation.
Graph sandbox:
Enabled by default, the Graph sandbox can be configured to allow or disallow execution of Java packages, superclasses, and types, see Graph sandbox.

Restriction:

DSE has the following limitations with Graph authorization:

Limited, as Gremlin queries are not distinguished between query types like CQL.
Permissions are enforced on a per vertex label and registered through CQL at the table level, using individual permissions using CQL.