Server-Side Encryption

ARTESCA supports object encryption at rest through Server-Side Encryption (SSE). When enabled, objects are automatically encrypted before storage and decrypted before delivery to clients.

SSE is disabled by default, even when an external KMS is configured. It can be enabled at the bucket level (using PutBucketEncryption) or per object (using the x-amz-server-side-encryption header on PutObject).

ARTESCA uses envelope encryption. For each object:

  1. ARTESCA generates a unique data encryption key (data key).

  2. ARTESCA encrypts the object data with the data key.

  3. ARTESCA encrypts the data key with a master encryption key (master key).

  4. ARTESCA stores the encrypted data key and a reference to the master key (the master key ID) in the object’s metadata.

On download, ARTESCA reverses the process, meaning that the master key decrypts the data key, and the data key decrypts the object content.

For more information on envelope encryption, refer to the AWS envelope encryption documentation.

Each object is encrypted independently with its own data key, whether SSE is requested per object or applied through a bucket-level configuration.

Configure SSE

Reference Documentation on SSE

Understanding Internal vs External Encryption

Internal Encryption

When no external Key Management System (KMS) is configured, ARTESCA uses internal encryption where master keys are stored directly in the object metadata. This is the default KMS backend and requires no additional infrastructure setup but the encryption still needs to be enabled explicitly, either at the bucket level (using PutBucketEncryption) or per object (using the x-amz-server-side-encryption header).

Warning

Internal encryption does not meet production security standards. The master key is stored alongside the encrypted data in the metadata, which means anyone with access to the metadata storage can retrieve the key. Internal SSE is only suitable for development and testing.

External Encryption (KMIP or AWS KMS)

With external encryption, ARTESCA delegates master key storage to an external KMS. Only a reference to the master key (the key ID) is stored in the object metadata; the actual key material never leaves the KMS.

ARTESCA does not offload the encryption or decryption of object data to the KMS. It only uses the KMS to encrypt and decrypt the data keys. Object payloads are never transferred to the external KMS, which limits the bandwidth and latency requirements of the KMS.

Important

When using external SSE, ARTESCA sends requests to the KMS for every encrypted object upload or download. This means:

  • The KMS must be sized to handle the expected request load

  • If the KMS is unavailable, all operations on encrypted objects (uploads and downloads) fail

  • Unencrypted objects are not affected by KMS availability

Choosing Between Internal and External Encryption

Security: If you must adhere to security compliance standards, you must use an external KMS. Internal SSE is not designed to meet these standards.

Scalability and high availability: When using external SSE, ensure the KMS can handle the expected concurrent request volume. Consider KMIP cluster mode (multiple endpoints) for high availability.

Supported external KMS backends:

  • Tested and supported KMIP-compliant KMS providers:

    • Thales CipherTrust Manager

    • Hashicorp Vault (KMIP interface)

    • Hytrust KeyControl

  • AWS KMS API-compliant KMS

Note

ARTESCA supports only one KMS backend at a time (internal, or a single external KMS). Configuring multiple external KMS backends simultaneously is not supported.