fbpx

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 27001

ISO 27017

ISO-27018

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 Scylla Monitoring and Scylla 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 Scylla 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 Scylla 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 Scylla 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 Scylla Database User
  • Recommendations for Role Based Access per keyspace/table. 
  • Password policy

ScyllaDB Security Resources