Jul18

How to Combat Data Breaches Before They Happen: Scylla’s Native Security

Share on facebook
Share on twitter
Share on print
Share on email
Share on linkedin

Subscribe to Our Blog

Combat Data Breaches

 

Last week, we announced support for encryption-at-rest in Scylla Enterprise, beginning with the Scylla Enterprise 2019.1.1 release. This is a huge step forward in security for you, since it enables you to lock-down your data even in multi-tenant and hybrid deployments of Scylla.

With this new feature, we thought it’d be a good time to do a quick overview of security in Scylla, and to share how you can approach it holistically using the array of capabilities that Scylla provides.

1. The Basics

To take advantage of new security features and bug fixes, you need to stay up-to-date with the latest software. Before you do anything else, update your cluster with latest version of Scylla. Also take the time to ensure that  your operating system and libraries are up-to-date as well.

2. Enable Authentication

Authentication is the building block of all access into the system. Every user, either human or machine, is issued a username/password combination. Scylla enforces authentication internally, without relying on external or third-party services.

You need to take a few steps to enable authentication, since it is not turned on by default. To prevent disruptions, Scylla lets you enable and disable authentication without downtime. First, you enable authentication in the scylla.yaml file. Then, you need to change the default username and password to a secure setting.

To enable password authentication, edit the scylla.yaml file, setting the value authenticator: PasswordAuthenticator.
A typical multi-datacenter configuration will have a system_auth keyspace configured as follows:

A typical multi-datacenter configuration will have a system_auth keyspace configured as follows:

ALTER KEYSPACE system_auth WITH REPLICATION =

{'class' : 'NetworkTopologyStrategy', 'dc1' : <new_rf>, 'dc2' : <new_rf>};

Before enabling authentication, configure replication factor greater than 1 to the system_auth keyspace. That will prevent any chance of being locked out of your cluster. Once authentication is enabled, Scylla will authenticate clients to determine their permission to access to the cluster.

Complete documentation can be found in the Authentication section of Scylla docs.

3. Segment Client Applications and Users into Roles

Role-Based Access Control (RBAC), also referred to as Authorization, is really where defense in depth can come into play. Your team will need to come up with a strategy for defining an authorization policy that takes into account the principle of least privilege; no user should be provisioned with any more capabilities than required by their corporate responsibilities. That means you need to do some planning up front. For insight into the nuances of RBAC, we provide some detail in Role Based Access Control (RBAC).

In Scylla, users and passwords are created with roles using a GRANT statement. Granting permissions to users requires the use of a role such as Database Administrator and requires a user who has been authenticated.  The best way to approach this is to start by granting no permissions to all roles, then grant read access only to roles who need it, write access to roles who need to write, and so on. It’s better to have more roles, each with fewer permissions.

The permissions available for each role are CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESCRIBE. You can grant permissions on keyspaces, tables and users. For example, if you need a role for analytics users, let’s call it the data_reader role, who will be reading but not writing data, the role would be configured as follows:

GRANT SELECT ON ALL KEYSPACES TO data_reader;.

Note that permissions are automatically granted to any user who creates a new keyspace, table or user. If needed, an administrator can revoke, add, or modify permissions on any role.

The Grant Permission is fully documented here.

Scylla supports two authorization modes: the all-permissive default AllowAllAuthorizer, and the CassandraAuthorizer, which implements permission management functionality and stores its data in Scylla system tables.

Complete documentation can be found in the Authorization Section of Scylla docs.

Note that roles have another function in Scylla Enterprise that is unrelated to security: they also provide the basis of Workload Prioritization.

4. Protect Your Data In-transit

Data needs to move over the network. Scylla will send data from the cluster to client applications and vice versa, and data is also transferred among nodes over the network. You need to secure both channels from eavesdropping and data theft using transport level encryption (TLS).

To do so, configure Scylla to use TLS/SSL encryption for all node-to-node and client-cluster connections..

Scylla supports PEM certificates, which can be either self-signed or issued by a certificate authority. The PEM can be referenced as a keyfile or a truststore. Scylla defaults to the system truststore if none is specified.

Securing Application Traffic

Client applications that need to query Scylla must be configured to use encryption on the wire. To enable encryption, configurations and credentials need to be set up on both the Scylla nodes and on the client application. Authenticated certificates need to be accessible to both your Scylla nodes and your application clients.

Securing Internode Traffic

Scylla enables you to encrypt data on the wire among all nodes in a Scylla cluster, across data centers, across racks, or all of the above. There is only one configuration parameter in scylla.yaml to set up internode encryption: server_encryption_options. This parameter has a few options, including the mode as well as the location of the PEM encoded key or certificate, or a dedicated truststore. If not specified, Scylla defaults to the system trustore, as expected.

Complete instructions can be found in two sections of the Scylla docs: Data in Transit to Client Node and Data in Transit Node to Node.

5. Minimize Network Exposure

One of the simplest and most important practices to secure your database is to keep it off the public internet. Millions of malicious bots continuously scan the network looking for open, unprotected ports. A surprising number of database users have yet to take this seemingly obvious step.

A related best practice is to maintain a list of ports used by Scylla and monitor them to ensure that only trusted clients access those network interfaces and ports.  The diagram below shows a single datacenter cluster deployment, with the list of ports used for each connection type. You should periodically check to make sure that only these ports are open. A variety of third-party tools, both open and closed source, can be used to scan the list of open ports and compare it to your whitelist. Most of the ports settings are configurable in the scylla.yaml file, allowing you to change the port numbers to a different number than the defaults.

 

Scylla Ports

6. Recording Activity via System Audits

When things do go wrong, it’s important to have robust auditing capabilities to prove who did what, and when. Even when things don’t go wrong, auditing can help IT work with compliance groups to provide ongoing reports that demonstrate good security policies, with appropriate roles and authorized activities on the system. Such reporting is critical in today’s age of increased regulation — in particular, GDPR.

Scylla Enterprise 2018.1 introduced an auditing system that enables teams to support compliance by generating reports on system activity. The auditing feature enables administrators to report on “who did / looked at / changed what and when.” Auditing also logs the activities that an application user performs on a Scylla cluster.

Scylla auditing enables you to record login events, DML events (insert, update, delete, and so on), DDL events (object and role create, alter, drop, and so on), role management (grant, revoke, create role, drop role). You can also log all queries made to the system, though that can have a significant impact on overall performance.

Audit messages can either be sent to syslog or stored in a Scylla table. In either case, it is better to export audit data to an external system for security and storage efficiencies.

For the same reason, you should also enable-OS level auditings.

Complete instructions can be found in Auditing section of the Scylla docs

Conclusion

As you can see, there’s no single switch for data security. With attackers becoming increasingly sophisticated and coordinated, IT teams need to step up and make use of all the capabilities at their disposal. We hope you find this security checklist to be a helpful reminder.

Keep in mind that Scylla Cloud covers most of this checklist for you!

Eyal GutkindAbout Eyal Gutkind

Eyal Gutkind is a solution architect for Scylla. Prior to Scylla Eyal held product management roles at Mirantis and DataStax. Prior to DataStax Eyal spent 12 years with Mellanox Technologies in various engineering management and product marketing roles.Eyal holds a BSc. degree in Electrical and Computer Engineering from Ben Gurion University, Israel and MBA from Fuqua School of Business at Duke University, North Carolina.


Tags: cybersecurity, Scylla Enterprise 2019.1, Security