DataStax Enterprise security checklists

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

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

DSE database security checklist

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

DataStax Enterprise supports secure enterprise search. All of the DataStax Enterprise security checklists in this section summarize the security features of DSE Search as well as 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 [Configuring SSL].

    To satisfy specific security requirements with SSL, you can https:/docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/search/changingTomcatWebSettings.html[change the IP address for client connections to DSE Search]. You can do this, for example, to isolate a subnet.

    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

    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 server.xml 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.

About HTTP Basic Authentication and DSE Search clusters

Only use HTTP Basic Authentication with DSE Search clusters in your testing and development environments. Do not use internal authentication on DSE Search clusters in production.

You can use HTTP Basic Authentication with DSE Search clusters, however it’s not recommended for production.

To secure DSE Search in production, enable DataStax Enterprise Kerberos authentication, or search using CQL.

If instead you enable Cassandra internal authentication, by specifying authenticator: org.apache.Cassandra.auth.PasswordAuthenticator in cassandra.yaml, clients must use HTTP Basic Authentication to provide credentials to Solr services. Due to the stateless nature of HTTP Basic Authentication, this option can have a significant performance impact because the authentication process must be executed on each HTTP request. For this reason, DataStax does not recommend using internal authentication on DSE Search clusters in production.

DSE Analytics Security Checklist

DataStax recommends the following security practices:

  • Enable client-to-node encryption using SSL.

  • Run Spark ports for internode communications from within a secured network that has no exposure to outside traffic.

Secure DataStax Enterprise Analytics nodes as follows:

  • Authentication:

    • Distinct secrets for internode and per application, see https:/docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/spark/sparkConfiguration.html[Configuring Spark nodes].

    • Native authentication for users of each application executor (run as) and isolation of related data, see https:/docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/spark/sparkConfiguration.html[Configuring Spark nodes].

    • Spark UI internal or LDAP authentication, see https:/docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/spark/sparkWebInterface.html[Monitoring Spark with the web interface].

    • 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 https:/docs.datastax.com/en/dse/6.8/dse-dev/datastax_enterprise/spark/sparkInternalAuth.html[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 https:/docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/spark/sparkConfiguration.html#sparkConfiguration__spark_authorization[role-based access control] (RBAC). The user running the request must have permission to access the data through their role assignment.

    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 https:/docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/spark/sparkLogging.html[Configuring Spark logging options].

    • 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

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.

    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

  • Authorization:

    Limit access to graph data by defining roles for DSE Graph keyspaces and tables. See Controlling access to DataStax Graph keyspaces.

    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

    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.

    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

To configure the Gremlin console to use SSL when SSL is enabled on the Gremlin Server, edit the connectionPool section of remote.yaml. See https:/docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/config/configRemoteYaml.html#configRemoteYaml__enableSslParameter[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 https:/docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/graph/config/configGraphOverview.html#configGraphSecuritySettings__sandbox[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.

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000, info@datastax.com