The security of data managed by Scylla is crucial. There are many aspects of systems and information security and Scylla includes features to address an important selection of them. In this talk, we'll discuss Scylla's support for managing identities and for defining schemes for limiting access to resources based on roles. We will discuss how these features tie in to principles of secure systems , briefly describe how the functionality is implemented, and finally demonstrate the user perspective.

1. Access Control in Scylla
Jesse Haber-Kucharsky
Software developer, ScyllaDB

2. Presenter bio
Jesse has a strong interest in systems programming, programming
languages, and applying math to solve engineering problems. He has
worked on the software platform for self-driving cars, NFC drivers for
smartphones, and large-scale distributed storage systems. He has a BSc
from the University of Waterloo in electrical engineering and an MS in
electrical and computer engineering from Carnegie Mellon University.

3. The security of your data
is important

4. If it were not, why store it in a database at all?

5. Business value is increasingly tied to data.

6. Security properties (or “principals”)
These help us to frame the discussion and analysis of the systems
we build.

7. Security properties (or “principals”)
Identity
Authentication
Confidentiality
Availability
Integrity
Non-repudiation

8. Managing identities with users

9. Identity
Who’s using the database?

10. Authentication
How do we know their identity is truthful?

11. Users and passwords
We can manage these within Scylla itself.

12. Users and passwords
CREATE USER jsmith WITH PASSWORD ’s3cret!’;
$ cqlsh -u jsmith

13. Users and passwords
Metadata for users is stored in tables in the system_auth keyspace
CREATE TABLE system_auth.roles (
role text PRIMARY KEY,
can_login boolean,
is_superuser boolean,
member_of set<text>,
salted_hash text)

14. Users and passwords
We feed the password through a one-way cryptographic hashing
function with “salt”.

15. Users and passwords
crypt_r, originally from the GNU C library, does the work: bcrypt
where available and SHA-512 on most Linux distributions.

16. Availability
If the replication factor (RF) of the metadata keyspace is N, then
users can authenticate themselves even if a node goes down.

17. Managing identities in enterprises
Large corporations often use directory services to manage
information about their employees.
LDAP is a common protocol for communicating with these services.

18. Managing identities in enterprises
The enterprise edition of ScyllaDB will soon support authenticating
via LDAP.

19. Managing identities in enterprises
1. Client provides user ID and password
1. Scylla queries the DS with the ID
1. The DS produces a matching – uniquely
identified – entry (DN)
1. Scylla tries to authenticate (“bind”) the
password to the matching DN
Directory
service (DS)
Scylla
cluster
Client
LDAP

20. Roles and permissions

21. Confidentiality
How can we limit which data particular users can access?

22. Non-repudiation
How can we know which users accessed particular data?

23. Authorization
We control access to resources in Scylla by granting
users permissions for them.

24. Resources
A particular table: <table events>
All tables in a keyspace: <keyspace foobar>
A particular role: <role jsmith>

25. Permissions
CREATE
ALTER
DROP
SELECT
MODIFY
AUTHORIZE
DESCRIBE

26. Authorization
Each kind of CQL operation is enabled by a particular combination
of resource and permission.

27. Authorization
“Joe Smith needs to be able to read from the events table.”
GRANT SELECT ON analytics.events TO jsmith;

28. Authorization
Internally, a table with a row for each pair of a user and resource.
Logically, a function:
(user, resource) ⇒ permissions

29. Authorization
All queries first must be verified to ensure that the executor has
the right permission.
A caching layer means that we don’t have to aggregate permission
sets for every query.

30. Things can get tricky
Adding appropriate permissions to new users can be cumbersome.
A change in permissions may have to be applied to many users.
Laziness will likely win.

31. Roles!
Users who have similar job roles probably have to access the same
kinds of data.
A role in Scylla is collection of permission sets for difference
resources.
Roles can be granted to other roles.

32. What about users?!
All users are roles, but not all roles are users.

33. Users and roles
CREATE ROLE analyst;
GRANT SELECT ON KEYSPACE customers TO analyst;
GRANT analyst TO jsmith;

34. Implementing roles
Internally, role metadata are stored in a table logically forming a
directed acyclic graph (DAG).

35. Implementing roles
CREATE ROLE jsmith WITH LOGIN=true;
CREATE ROLE tjones WITH LOGIN=true;
CREATE ROLE analyst;
CREATE ROLE team_lead;
GRANT analyst TO jsmith;
GRANT team_lead TO tjones;
GRANT analyst TO team_lead;
analyst
team_lead
jsmith
tjones
is a member of

36. Roles and auditing
Scylla can audit events and log them to tables or Syslog.
Fine-grained roles make this information more useful.

37. Roles and Auditing
SELECT date, username, operation FROM audit.audit_log;
date | operation | username |
-------------------------+------------------------------+----------+
2018-03-18 00:00:00+0000 | DROP TABLE nba.team_roster; | tjones |
(1 row)

38. Encryption
(briefly)

39. Integrity
How do we know our data are secure outside of a single node’s
memory?

40. Encryption during motion
Image by Marc Eschenlohr, CC BY 2.0

41. Encryption during motion
Scylla supports encrypted communication between nodes and
from client to node via TLS (OpenSSL)

42. Encryption at rest
Image by Alonso Inostrosa Psijas, CC BY-SA 2.0

43. Encryption at rest
sstable files can encrypted on-disk with a user-provided symmetric
key.
Each file is encrypted in blocks of 4096 B with the OpenSSL EVP
library.

44. Conclusions

45. Thank You
Any Questions ?
Please stay in touch
jhaberku@scylladb.com
@jhaberku