Scylla includes multiple features that collectively provide a robust security model. Most recently we announced support for encryption-at-rest in Scylla Enterprise. This enables you to lock-down your data even in multi-tenant and hybrid deployments of Scylla. Join Tzach and Dejan for an overview of security in Scylla and to see how you can approach it holistically using the array of Scylla capabilities. He will review Scylla Security features, from basic to more advanced, including: Reducing your attack surface Authorization & Authentication Role-Based Access Control Encryption at Transit Encryption at Rest, in 2019.1.1 and beyond LDAP authentication is a common requirement for any enterprise software. It gives users consistent login procedures across multiple components of the IT infrastructure, while centralizing the control of access rights. Scylla Enterprise now supports authentication via LDAP. We will look into how to configure Scylla Enterprise for LDAP interaction and how to fine-tune access control through it.

1. Secure Your Scylla
Deployment
Tzach Livyatan, VP product, ScyllaDB

2. Presenter
Tzach Livyatan, VP Product, ScyllaDB
Tzach Livyatan is ScyllaDB Product Manager, and has had a 15
year career in development, system engineering and product
management.
In the past he worked in the Telecom domain, focusing on
carrier grade systems, signalling, policy and charging
applications for Oracle and others.

3. A System is Never “Bullet-Proof”
Securing the system is an endless,
ongoing process

4. Security Risks Bingo
Sniffing on
Application-DB
Connection
Key Leak
Unauthorized
Server Access
Insider Data
Breach
Port Scanning DDoS CQL Injection OS Vulnerabilities
Unauthorized DB
Access
Man-in-the-
middle
Brute Force
Attack
Data Leak
Physical Theft
Non
Authenticated
Access
Sniffing on node-
node
Connection
Ransomware

5. Agenda
5
■ Authentication
■ Authorization
■ RBAC
■ Encryption In Transit
■ Encryption at Rest
■ Auditing
■ Minimal Exposure
■ Best Practices

6. ■ Limit access to the cluster to identified clients
■ Disabled by default (Enabled in Scylla Cloud)
■ Enable and Disable Authentication Without
Downtime
a. Move to a TransitionalAuthenticator
b. Enable Auth on each client
c. Move to PasswordAuthenticator
■ Best Practice : use a unique User per
application, for easier Auditing and Service
Level
Authentication

7. Authorization is the process by where users are granted
permissions which entitle them to access or change data
on specific keyspaces, tables or an entire datacenter.
Authorization is enabled using the authorizer setting in
scylla.yaml. Scylla has two authorizers available:
■ AllowAllAuthorizer (default setting) - which performs no
checking and so effectively grants all permissions to all roles.
■ CassandraAuthorizer - which implements permission
management functionality and stores its data in Scylla system
tables.
Authorization

8. Role-Based Access Control
■ Method of reducing lists of authorized users to a few roles
assigned to multiple users
■ Create the roles and their associated permissions
■ Roles can be granted to other roles
■ Users are Roles
■ Cassandra compatible CQL syntax (users, permissions,
roles) here
■ More info here

9. Users Are Roles (with login)
Roles Users

10. Users Are Roles (with login)
Customer
Trainer
Staff
Admin
TimDennisMaryLisa
schedule.cust
GRANT
SELECT
customer.info
schedule.train
SELECT
schedule
customer
SELECT
MODIFY
SUPERUSER
GRANT
GRANT

11. CREATE ROLE customer;
GRANT SELECT ON schedule.cust TO customer;
CREATE ROLE trainer;
GRANT customer TO trainer;
GRANT SELECT ON customer.info TO trainer;
GRANT SELECT ON schedule.train TO trainer;
Role Based Access Control - Example

12. CREATE ROLE lisa WITH PASSWORD = 'password' AND LOGIN = true;
CREATE ROLE mary WITH PASSWORD = 'password' AND LOGIN = true;
GRANT trainer TO mary;
GRANT customer TO lisa;
Role Based Access Control - Example

13. Granting Roles and Permissions
■ Permission: what the role is permitted to do
■ Resource: the scope over which the permission is granted for
GRANT (permission | "ALL PERMISSIONS") ON resource TO
role where:
• Where permission is CREATE, DESCRIBE, etc.
• A resource is one of
• “<ks>.<tab>”
• “KEYSPACE <ks>”
• “ALL KEYSPACES”
• “ROLE <role>”
• “ALL ROLES”
• Note that An unqualified table name assumes the current keyspace

15. ■ Encryption In Transit
● Client to Node
● Node to Node
■ Encryption At Rest
● Tables
● System
● Providers
Encryption

16. 16
■ SSL Encryption of Data In Flight is available in all
versions of Scylla
■ Client - Node Encryption - The available options
are:
● Enabled or Not Enabled
● When Enabled, all incoming CQL connections require
TLS/SSL connectivity.
■ Setting include:
● certificate - A PEM format certificate, either self-signed,
or provided by a CA authority.
● keyfile - The corresponding PEM format key for the
certificate
More Info
Encryption In Transit - Client to Node

17. 17
■ SSL Encryption of Data In Flight is available in all versions of
Scylla
■ Internode_encryption - The available options are:
● none (default) / all / dc/ rack
■ Settings include:
● certificate - A PEM format certificate, either self-signed, or provided by a
certificate authority (CA).
● keyfile - The corresponding PEM format key for the certificate
● truststore - Optional path to a PEM format certificate store of trusted
CA:s. If not provided, Scylla will attempt to use the system trust store to
authenticate certificates.
More Info
Encryption In Transit - Node to Node

18. Encryption at rest
cipher_algorithm secret_key_strength
AES/CBC/PKCS5Padding (default) 128 (default), 192, or 256
AES/ECB/PKCS5Padding 128, 192, or 256
Blowfish/CBC/PKCS5Padding 32-448
DES/CBC/PKCS5Padding 56
DESede/CBC/PKCS5Padding 112 or 168
RC2/CBC/PKCS5Padding 40-128
cipher_algorithims are available for use with Scylla using OpenSSL.

19. Encryption At Rest
■ Encryption of user data as stored on disk
● SSTables
● Commitlog
● Hints
● Batchlog
■ Invisible to client
● Transparent Data Encryption
■ Scylla Enterprise 2019.1
19
■ System level granularity
■ keyspace.table granularity

20. Encryption at Rest
■ Uses disk block encryption
● File level wrapping
● Divides file into 4k blocks and encrypts/decrypts on r/w
■ Uses hash of key + block position to derive init vector
for block cipher (ESSIV - cryptfs)
■ Hooked via extension points in sstables/commitlog/hints
● Wraps files depending on config/schema
20
Minimal Performance Impact (~5%)

21. CREATE TABLE data.atrest (pk text primary key, c0 int) WITH
scylla_encryption_options = {
'cipher_algorithm' : 'AES/ECB/PKCS5Padding',
'secret_key_strength' : 128,
'key_provider': 'LocalFileSystemKeyProviderFactory',
'secret_key_file': '/etc/scylla/encryption_keys/data_encryption_keys'
};
■ cipher_algoritm - The key type (algorithm)
■ secret_key_strength - The length of the key in bits
■ key_provider - Name of the provider for the key
21
Encryption at Rest

22. Enable/disable encryption of existing table
ALTER TABLE data.atrest (pk text primary key, c0 int) WITH
scylla_encryption_options = {
'cipher_algorithm' : 'AES/ECB/PKCS5Padding',
'secret_key_strength' : 192,
'key_provider': 'LocalFileSystemKeyProviderFactory',
'Secret_key_file': '/etc/scylla/encryption_keys/data_encryption_keys'
}
;
ALTER TABLE ks.test WITH
scylla_encryption_options = { 'key_provider' : 'none’ };
22

23. Enable/disable (cont)
■ Data is not encrypted or decrypted until SSTables are (re-
)written
● Must force rewrite to ensure all data is changed
● If you remove an encryption key before all data is
decrypted/rewritten
the data will be lost
> nodetool upgradesstables -a <keyspace> <table>
23

24. System Encryption
■ Encrypts “implicitly” stored user data
● Commitlog, hints, batch
■ Configured on node level (scylla.yaml)
system_info_encryption:
enabled: <bool>
key_provider: (optional) <key provider type>
■ Uses same key providers and options as table encryption
24

25. 25
Key Providers
KMIP
+ Centralized key
management
+ Replacement/
rotation functionality
in server
Local
+ Does not require an
external server
+ Persisted on the
node
+ Manual distribution
to all nodes
Scylla Tables
Distributes keys for
SSTables only (no
system keys)

26. Local key
file
System
Key file
Key
Key
KMIP
host
Keys
Scylla table
Local
provider
Replicated
provider
KMIP provider
Keys
Encryption
extension
..either
Encryption extension
encrypts
System table
(hints,
batchlog)
Commit log User table

27. ■ Who did / looked at / changed what and when
■ Logging activities a user performs on Scylla cluster
■ Enable on scylla.yaml (2018.1.x and later)
■ Three audit storage alternatives:
● None (default) - Audit is disabled
● Table - Enables audit, messages stored in a Scylla table:
audit.audit_log
● Syslog - Enables audit, messages are sent to syslog and to an
external server
27
Auditing

28. 28
What Can You Audit?
Parameter Logs Description
AUTH Logs login events
DML Logs insert, update, delete, and other Data
Manipulation Language events
DDL Logs object and role create, alter, drop, and other Data
Definition Language events
DCL Logs grant, revoke, create role, drop role, list roles, and
other Data Control Language events
QUERY Logs all Queries

29. 29
What Can You Audit?
■ List of tables that should be audited.
audit_tables: "mykespace.mytable"
■ List of keyspaces that should be fully audited.
■ All tables in those keyspaces will be audited
audit_keyspaces: "mykespace"

30. ■ Ensure that Scylla runs in a trusted network
environment.
■ Limit access to IP / Port by role.
■ Use the minimal privileges principle
■ Avoid Public IP if possible
■ Use VPC if possible
Minimize Network Exposure

31. Minimize Network Exposure

32. Scylla Cloud - Limit cluster access to min
32

34. Scylla Cloud Security
■ Integrated with AWS Secrets Manager (no local keys)
■ Clusters are isolated with security groups, Virtual Private Cloud
Network (VPC)
■ Applying the principle of least privilege per element (AMI, roles, ...)
■ Hotfix for Scylla, underline OS and relevant libraries
■ Encryption At Rest
AWS: encrypted using an XTS-AES-256 block cipher implemented in a hardware module on the instance[1]
34

35. ■ Routinely upgrade to latest Scylla and OS versions
■ Routinely check for network exposure
■ Routinely replace keys/passwords
■ Use 2FA (Scylla Cloud)
■ Use minimal privilege principle
■ Apply available security features
Security is an Ongoing Process
35https://twitter.com/Hackers_bot

36. More Security is Coming!
■ LDAP Integration
■ More Key Management APIs
■ Scylla Manager
● Role Based Access Control
● Audit
■ Bring your own Auth
■ Your suggestion here...

37. Security Risk Bingo
Sniffing on
Application-DB
Connection
Key Leak
Unauthorized
Server Access
Insider Data
Breach
Port Scanning DDoS CQL Injection OS Vulnerabilities
Unauthorized DB
Access
Man-in-the-
middle
Brute Force
Attack
Data Leak (logs)
Physical Theft
Non
Authenticated
Access
Sniffing on node-
node
Connection
Ransomware

38. Thank you Stay in touch
Any questions?
Tzach Livyatan
tzach@scylladb.co
m
@tzachL