Skip to content
Rime Docs

Encryption

Rime encrypts all data both in transit and at rest. This page covers each layer of encryption, from browser connections through to data stored in Snowflake and S3.

In transit

All network connections to, from, and within Rime use TLS 1.3. There are no unencrypted communication paths.

ConnectionProtocolDetails
Browser to RimeTLS 1.3All HTTP traffic is encrypted. HTTP requests are redirected to HTTPS. HSTS headers are set to prevent downgrade attacks
Rime to SnowflakeTLS 1.3Rime connects to Snowflake’s SQL API over HTTPS. Snowflake enforces TLS on all connections
Rime to S3TLS 1.3All S3 API calls (upload, download, list) use HTTPS endpoints
Rime to identity providersTLS 1.3SAML and OIDC flows communicate with IdPs over HTTPS
Internal service communicationTLS 1.3Communication between Rime’s internal services (API, scheduler, connector runner) is encrypted

TLS 1.2 and earlier versions are not accepted. Clients that do not support TLS 1.3 will not be able to connect.

At rest — Rime-managed data

Rime stores sensitive configuration data in its own PostgreSQL databases. Credentials and secrets are encrypted before storage using AES-256-GCM (Galois/Counter Mode).

What is encrypted

DataStorageEncryption
Snowflake credentials (passwords, private keys)PostgreSQL BYTEA columnAES-256-GCM
Connector credentials (database passwords, API keys)PostgreSQL BYTEA columnAES-256-GCM
SSO client secretsPostgreSQL BYTEA columnAES-256-GCM
Webhook secretsPostgreSQL BYTEA columnAES-256-GCM

Non-sensitive configuration (resource names, schedules, pipeline definitions) is stored as plaintext in PostgreSQL. This data does not contain secrets and does not require field-level encryption.

AES-256-GCM

Rime uses AES-256-GCM for symmetric encryption of stored credentials. AES-256-GCM provides both confidentiality and integrity:

  • AES-256 — 256-bit key, considered secure against all known attacks including theoretical quantum computing attacks at current key sizes
  • GCM (Galois/Counter Mode) — an authenticated encryption mode that produces a ciphertext and an authentication tag. Any tampering with the ciphertext is detected on decryption
  • Nonce — a unique 96-bit nonce is generated for each encryption operation and prepended to the ciphertext. This ensures that encrypting the same value twice produces different ciphertext

Key management

Encryption keys are derived from a master secret configured during Rime deployment. The key derivation process:

  1. A master secret is set in the Rime deployment configuration (environment variable or secret store)
  2. The master secret is processed through a key derivation function to produce the 256-bit AES key
  3. The derived key is held in memory during the application’s lifetime and is never written to disk

Key rotation is supported by deploying a new master secret. When the key changes:

  1. Deploy the new master secret alongside the old one
  2. Rime re-encrypts all stored credentials using the new key
  3. Once re-encryption completes, the old master secret can be removed

Key rotation does not cause downtime. During the rotation window, Rime can decrypt with either key.

PostgreSQL encryption

In addition to field-level encryption of credentials, the PostgreSQL database itself should be configured with encryption at rest at the storage layer. When running on AWS, this means enabling encryption on the RDS instance or EBS volumes. Rime’s deployment configuration enables this by default.

At rest — Snowflake data

Data stored in your Snowflake account is encrypted by Snowflake’s built-in encryption:

  • Standard Edition — AES-256 encryption with automatic key rotation
  • Enterprise Edition — adds support for customer-managed keys (Tri-Secret Secure) and periodic re-encryption
  • Business Critical Edition — adds support for AWS PrivateLink and Azure Private Link for private network connectivity

Rime does not manage Snowflake’s encryption keys. Snowflake handles key management, rotation, and re-encryption automatically. If your organisation requires customer-managed keys, configure Tri-Secret Secure directly in Snowflake.

At rest — S3 staged files

Parquet files staged in S3 during the extraction process are encrypted using S3 server-side encryption:

  • SSE-S3 (default) — Amazon manages the encryption keys. Files are encrypted with AES-256 before being written to disk
  • SSE-KMS — available if you configure a customer-managed KMS key in your AWS infrastructure settings. Provides audit trail of key usage through AWS CloudTrail

Staged Parquet files are temporary. After Snowpipe has loaded the data into Snowflake, the files are either archived or deleted according to your retention configuration. Even before deletion, the files are encrypted at rest.

To configure SSE-KMS:

  1. Navigate to Infrastructure > AWS Resources
  2. Select the S3 bucket used for staging
  3. Under Encryption, select SSE-KMS and provide the KMS key ARN
  4. Select Save and apply the infrastructure change

Certificate management

TLS certificates for the Rime web interface ({tenant}.rimedata.io) are managed automatically. Certificates are provisioned and renewed through automated certificate management (ACME/Let’s Encrypt or equivalent) with no manual intervention required.

If your organisation requires a custom domain (e.g., data.yourcompany.co.nz), provide the domain and a valid TLS certificate during onboarding. Rime will configure the custom domain with your certificate and notify you before the certificate expires.

Verifying encryption

To verify that encryption is active:

  • In transit — check the browser’s address bar for the lock icon and TLS 1.3 in the certificate details. API responses include Strict-Transport-Security headers
  • At rest (Rime) — credential fields are stored as encrypted BYTEA values in PostgreSQL. The audit log records all credential access events
  • At rest (Snowflake) — run SELECT SYSTEM$SHOW_ENCRYPTION() in Snowflake to verify encryption status
  • At rest (S3) — check the bucket’s default encryption configuration in the AWS console or through Rime’s infrastructure view

Next steps