Was this page helpful?
The following describes ScyllaDB Cloud security mechanism at a high level.
ScyllaDB Cloud security is built on four principles:
Principle of Least Privilege
Isolation
Auditing
Encryption
The following section will describe how these principles are used across different aspects of ScyllaDB Cloud. Everything below refers to both BYOA and ScyllaDB Account, unless explicitly stated otherwise.
Control Plane: ScyllaDB Cloud Backend, a collection of services and servers that manage ScyllaDB Cloud users, ScyllaDB Cloud application (site), manage and monitor all the ScyllaDB Database Clusters.
ScyllaDB Cluster: ScyllaDB Enterprise Servers, running in either ScyllaDB Account or, in case of BYOA, in the Customer Account.
Each ScyllaDB Cluster is running on a dedicated, isolated environment, including:
Dedicate VPC
Dedicated VMs for ScyllaDB Database
Dedicated VMs for ScyllaDB Monitoring and ScyllaDB Manager servers
The diagrams below describe the topology of a managed ScyllaDB cloud cluster, in ScyllaDB Account or Customer Account (BYOA)
ScyllaDB Cloud on AWS Architecture - ScyllaDB Account¶
ScyllaDB Cloud on AWS Architecture - BYOA¶
There is no access from one cluster to another
Customer data is limited to the ScyllaDB Cluster. The Control Plane does not store, query, or access the Customer Data.
The Control Plane access to ScyllaDB Clusters is limited to:
Monitoring information (metrics)
Operations, like add node, upgrade etc
Each cluster manage its own S3 backup bucket per DC (region)
All access points between elements are closed by default. Relevant connections and API are explicitly enabled.
ScyllaDB Database users can only access their ScyllaDB database over CQL or REST API (Alternator).
Users can not login to ScyllaDB nodes, Monitoring, or Manager servers; enforced using IP/port whitelist.
ScyllaDB Monitoring can only access ScyllaDB database servers monitoring and log collection APIs; enforce using IP/port whitelist.
ScyllaDB Manager can only access ScyllaDB database servers Manager Agent API; enforced using IP/port whitelist.
Access backup, stored on S3 (AWS) and Cloud Storage (GCP), is limited to the ScyllaDB cluster instances.
ScyllaDB Cloud team access to the system is:
Limited to a minimal subset of ScyllaDB Support engineered
Only does via tools / scripts
Audited
The above is valid to both ScyllaDB Clusters and Control Plan. In particular, direct access to the Database servers is done as a last resort.
The following channels are encrypted:
ScyllaDB Node to Node in the same region - using on AWS VPC Encryption in transit or GCP VPC Encryption in transit
ScyllaDB Node to Node between regions - All data flowing across AWS Regions over the AWS global network is automatically encrypted at the physical layer before it leaves AWS secured facilities. All traffic between AZs is encrypted.
ScyllaDB Client to Node - inside AWS, encrypted by default by AWS (see above). ScyllaDB-managed Encryption at transit is optional.
ScyllaDB Cluster uses NVMe to store information. The data on NVMe instance storage is encrypted using an XTS-AES-256 block cipher implemented in a hardware module on the instance. The encryption keys are managed by EC2 and generated using the hardware module and are unique to each NVMe instance storage device. ScyllaDB Cloud uses database-level encryption with customer-managed keys to encrypt all data stored in the database: database tables, commit logs, batch logs, and other places where customer data might reside.
ScyllaDB Cluster uses SSD to store information. Compute Engine automatically encrypts your data when it is written to local SSD storage space
Was this page helpful?