DataStax Studio security best practices

Best security practices for deploying DataStax Studio.

DataStax Studio does not provide a multi-user experience, which means that any user that has access to the Studio instance can use any connection or notebook associated with that instance. As for any application that has access to the database, security best practices prevent potential security risks.

Restrict user access

For all Studio installations, grant access only to:
  • Users who need to see and edit the Studio notebooks
  • Users who have the right to access the database connections associated with that Studio instance

Secure ports

DataStax recommends Securing DataStax Enterprise ports. When centrally deploying DataStax Studio, deploy all Studio instances behind a VPN.

Secure a centrally deployed instance of DataStax Studio behind a firewall, accessible only through a bastion node. This architecture assumes that only users that have been granted access can remote desktop to the DataStax Studio machine. The remote desktop enables privileged users to access the Studio browser client using localhost as its bind address.

Use an authentication proxy

Enable and protect Studio server access by using:
  • An authentication proxy to access the Studio browser client
  • HTTPS for the Studio browser client

Bind address

Because DataStax Studio is designed to be a local desktop application, a warning in configuration.yaml describes the risks of changing the bind address configuration from localhost.

Warning: Changing the setting from the default (localhost) can pose a security risk as other users on external machines can gain access to notebooks and the DSE clusters to which those notebooks are connected.

Authentication proxy

If the bind address must be changed from localhost, use NGINX as an authentication proxy in front of DataStax Studio to authenticate users to the DataStax Studio browser client. This solution integrates with LDAP and has been tested by NGINX against OpenLDAP and Microsoft Windows Server Active Directory versions 2003 and 2012. This option is available as open-source or paid subscription.

In this model, restrict the DataStax Studio browser client port to the local network with firewall rules and open only the authentication-protected NGINX port to the outside network. This solution combined with enabling HTTPS between the browser client and Studio server help secure this deployment model.

Secure connections

See Securing connections from DataStax Studio to DataStax Enterprise.