ScyllaDB Trust Center

ScyllaDB Security Vulnerability Reporting

ScyllaDB maintains a vulnerability reporting process that provides, at ScyllaDB’s security team’s discretion, a “bug bounty” to the first person who identifies a previously unreported security issue Vulnerabilities should be reported via email to [email protected].

ScyllaDB Data Privacy and Compliance

ScyllaDB is fully committed to being transparent about how we collect, use, and protect data received by ScyllaDB. Please see the ScyllaDB Privacy Policy and ScyllaDB Policies and Agreements for more information.

ScyllaDB undergoes independent third-party audits to confirm that it meets strict industry standards for security, availability, processing integrity, confidentiality, and privacy.

ScyllaDB has been certified to be compliant with the following standards:

SOC 2

ISO 27001

ISO 27017

ISO 27018

ScyllaDB Security Features

ScyllaDB Cloud clusters run within dedicated, isolated environments, including:

Dedicated virtual private service (VPS)
Dedicated VMs for ScyllaDB Database
Dedicated VMs for ScyllaDB Monitoring and ScyllaDB Manager servers

Inter-cluster access is not permitted.

The data plane is fully isolated from the control plane. Customer data is limited to the ScyllaDB cluster. The control plane does not store, query, or access customer data.

The Control Plane access to ScyllaDB Clusters is limited to

Monitoring information (metrics)
Operations, such as add node and upgrades

Principle of Least Privilege invariants

All access rights are granted based on business needs and on a need-to-know basis
All access points between elements are closed by default. Relevant connections and API are explicitly enabled.
ScyllaDB database users can only access ScyllaDB over CQL or via the REST API (Alternator)
Users cannot login to ScyllaDB nodes, monitoring, or manager servers; enforced using IP/port whitelist.
ScyllaDB Monitoring can only access ScyllaDB servers monitoring and log collection APIs; enforced using IP/port whitelist.
ScyllaDB Manager can only access ScyllaDB 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

Access Control

ScyllaDB Cloud team access to the system is:

Granted based on business needs and on a need-to-know basis
Limited to a minimal subset of ScyllaDB Support engineered
Only permitted via tools/scripts
Audited

Data confidentiality

ScyllaDB node-to-node in the same region, AWS VPC encryption in transit or Google Cloud 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. ScyllaDB-managed encryption in transit is optional.

Encryption at rest on AWS

ScyllaDB cluster uses NVMe to store data. 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.

Encryption at rest on Google Cloud

ScyllaDB Cluster uses SSD to store information. Compute Engine automatically encrypts data when it is written to local SSD storage space.

ScyllaDB Best Practices for Security

The ScyllaDB Security Checklist is a list of security recommendations that should be implemented to protect your ScyllaDB cluster. These guidelines cover the following topics:

Use VPC peering
Minimizing whitelisted IP addresses
Using a dedicated AWS sub-account for ScyllaDB Cloud Bring Your Own Account (BYOA)
Security Recommendations for ScyllaDB Database User
Recommendations for Role Based Access per keyspace/table.
Password policy

Curious about cost?

Level Up Your Skills