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

New features include:
  • Row level access control (RLAC)
  • Role-based access control for search indexes
  • DSE proxy authentication for database clients
  • Integrated LDAP role management
  • JMX authentication with internal or LDAP

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 store 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 Managing roles and Authorizing access to database resources.

  • Audit activity:

    Log and monitor activity for database resources, see Enabling data auditing in DataStax Enterprise.

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

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

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

cassandra.yaml

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

Package installations
Installer-Services installations

/etc/dse/cassandra/cassandra.yaml

Tarball installations
Installer-No Services installations

installation_location/resources/cassandra/conf/cassandra.yaml

dse.yaml

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

Package installations
Installer-Services installations

/etc/dse/dse.yaml

Tarball installations
Installer-No Services installations

installation_location/resources/dse/conf/dse.yaml

Tomcat server.xml

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

Package installations
Installer-Services installations

/etc/dse/tomcat/conf/server.xml

Tarball installations
Installer-No Services installations

installation_location/resources/tomcat/conf/server.xml

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 Configuring Spark nodes.
    • Native authentication for users of each application executor (run as) and isolation of related data, see Configuring Spark nodes.
    • Spark UI internal or LDAP authentication, see 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 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:
  • 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.yaml

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

    Package installations
    Installer-Services installations

    /etc/dse/dse.yaml

    Tarball installations
    Installer-No Services installations

    installation_location/resources/dse/conf/dse.yaml

DSE Graph security checklist

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

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 Providing credentials for DSE Graph.

  • Authorization:
    Limit access to graph data by defining roles for DSE Graph keyspaces and tables, see Managing access to DSE 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 Enabling data auditing in DataStax Enterprise.

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

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

cassandra.yaml

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

Package installations
Installer-Services installations

/etc/dse/cassandra/cassandra.yaml

Tarball installations
Installer-No Services installations

installation_location/resources/cassandra/conf/cassandra.yaml