Encryption

Overview

This document covers SingleStore Helios data encryption in transit and at rest.

Encryption in Transit

To ensure a secure connection to SingleStore Helios, SQL clients must be properly configured to require a secure connection, and to verify the supplied server certificate.

When a SingleStore Helios workspace has REQUIRE SSL enabled, users cannot connect to the workspace without using SSL. However, security can still be compromised with or without the use of SSL. Not using SSL can lead to a man-in-the-middle attack, where a would-be attacker can impersonate a server. Conversely, a secure connection can be established by using SSL, but perhaps to a server that’s using an illegitimate certificate.

To circumvent these potential issues, SingleStore supports TLS 1.2 for data in transit and for all connections to the database. Transport Layer Security (TLS) uses a combination of symmetric and asymmetric encryption which employs a pair of keys: a public key and a private key.

The SSL/TLS cipher suite used is AES128-GCM-SHA256, with SSL certificates on a one-year rotation for svc.singlestore.com and on a two-year rotation for the legacy db.memsql.com. The use of Let’s Encrypt, which will have a 90-day certificate rotation, is planned for the future.

Refer to Connect to SingleStore Helios using TLS/SSL for additional information.

Encryption at Rest

For data at rest, SingleStore uses best-practice AES-256 encryption with AWS, Azure, and GCP cloud-hosting partners. With a 256-bit key length, it is currently the strongest encryption algorithm available. In the standard edition of SingleStore Helios, the cloud provider managed key is used to encrypt all data at rest. For the dedicated edition of SingleStore Helios, a customer may use their own key, stored in their own key vault in the cloud key management service (KMS) to add an additional layer of security. Key access and use is captured using AWS CloudTrail. SingleStore cannot access the shared key material directly.

For the Data Plane, SingleStore logs all access to each SingleStore Helios workspace, and runs each workspace with audit logging enabled. The ADMIN-ONLY-INCLUDING-PARSE-FAILS audit logging level is used for completeness. Audit logs can be streamed to third-party audit tools. Refer to Audit Logging for more information.

In this section

Last modified: June 26, 2024

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined
  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined
  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
    cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
    --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
    --bundle undefined \
    --new-bundle-format -
    Verified OK