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).
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 |
Yes |
Yes |
Yes |
Yes |
|
Yes |
Yes |
Yes |
Yes |
|
Yes |
Yes |
No |
Yes |
|
Yes |
Yes |
Partial |
Yes |
|
Some DataStax drivers provide Kerberos support and SSL for client/server communication. Download drivers from DataStax Academy. |
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 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
DataStax Enterprise supports secure enterprise search. 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 Managing roles, 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 Enabling data auditing in DataStax Enterprise.
-
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.
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.
|
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.
-
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.
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 Configuring Spark logging options.
-
CQL requests are recorded in the database logs, see Enabling data auditing in DataStax Enterprise.
-
-
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. -
Authorization:
Limit access to graph data by defining roles for DSE Graph keyspaces and tables, see Managing access to DSE 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
DseGraphRpcobject 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
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_optionsin the cassandra.yaml file, see Client-to-node encryption.To configure the Gremlin console to use SSL, when SSL is enabled on the Gremlin Server, edit the
connectionPoolsection of remote.yaml. See Configuring the Gremlin console for Gremlin Server in the remote.yaml 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.
