Last week, we announced support for encryption-at-rest in ScyllaDB Enterprise, beginning with the ScyllaDB 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 ScyllaDB.
With this new feature, we thought it’d be a good time to do a quick overview of security in ScyllaDB, and to share how you can approach it holistically using the array of capabilities that ScyllaDB 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 ScyllaDB. 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. ScyllaDB 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, ScyllaDB 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' : , 'dc2' : };
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, ScyllaDB will authenticate clients to determine their permission to access to the cluster.
Complete documentation can be found in the Authentication section of ScyllaDB 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 ScyllaDB, 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.
ScyllaDB supports two authorization modes: the all-permissive default AllowAllAuthorizer, and the CassandraAuthorizer, which implements permission management functionality and stores its data in ScyllaDB system tables.
Complete documentation can be found in the Authorization Section of ScyllaDB docs.
Note that roles have another function in ScyllaDB 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. ScyllaDB 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 ScyllaDB to use TLS/SSL encryption for all node-to-node and client-cluster connections..
ScyllaDB 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. ScyllaDB defaults to the system truststore if none is specified.
Securing Application Traffic
Client applications that need to query ScyllaDB must be configured to use encryption on the wire. To enable encryption, configurations and credentials need to be set up on both the ScyllaDB nodes and on the client application. Authenticated certificates need to be accessible to both your ScyllaDB nodes and your application clients.
Securing Internode Traffic
ScyllaDB enables you to encrypt data on the wire among all nodes in a ScyllaDB 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, ScyllaDB defaults to the system trustore, as expected.
Complete instructions can be found in two sections of the ScyllaDB 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 ScyllaDB 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.
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.
ScyllaDB 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 ScyllaDB cluster.
ScyllaDB 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 ScyllaDB 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 ScyllaDB 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 ScyllaDB Cloud covers most of this checklist for you!
