Encryption at Rest and In Transit

As data security becomes increasingly critical in today’s digital landscape, organizations prioritize solutions protecting sensitive information. One key aspect is helping ensure encryption at rest and in transit, safeguarding data from potential threats, whether stored or transferred. IBM Storage Ceph Object Gateway offers comprehensive options for implementing both types of encryption, often relying on key management solutions like IBM GKLM to manage and store encryption keys securely. Use this information to understand how these encryption mechanisms work and the benefits they offer when used together.

Encryption at Rest with Ceph Object Gateway

Ceph Object Gateway offers robust encryption for data that is stored on disk, supporting granular object-level encryption. It is fully compatible with S3 encryption semantics and integrates with key management systems such as IBM GKLM, Hashicorp Vault, and Thales CipherTrust.

Encryption at Rest is essential for safeguarding stored data from unauthorized access by encrypting it while it resides on disk. Ceph facilitates this process through seamless integration with external Key Management Systems (KMS) like IBM Guardium Key Lifecycle Manager (GKLM). By doing so, Ceph can automatically retrieve encryption keys from the key manager, helping ensure that objects are encrypted as they are uploaded. This integration provides data security throughout its lifecycle while centralizing key management, simplifying key rotation, auditing, and overall compliance efforts.

Encryption in Transit with Ceph Object Gateway

Data can travel through various unknown, untrusted, or both unknown and untrusted networks as it moves between the object storage and the application. Encrypting the data as it travels over the network can effectively prevent tampering and helps ensure the security of the data, regardless of its path.

In Ceph Object, Encryption in Transit is typically achieved by using TLS/SSL encryption, which secures communication between clients and the RGW (RADOS Gateway). After the Object Gateways are configured, they provide an S3 RESTful API over HTTPS. The RESTful API encrypts and protects all data that is exchanged between clients and the object storage system.

From an architectural standpoint, SSL encryption can be applied at multiple layers: at the load balancer (ingress service), RGW level, or both. For full client-to-RGW HTTPS encryption, the two approaches for load balancer are pass-through and reencrypt.

Pass-through: Encrypted traffic is forwarded at level 3 directly to the Object Gateway service.
Reencrypt: The load balancer decrypts and reencrypts traffic before sending it to the RGW.

Server-Side Encryption (SSE) options with Ceph Object Gateway

Ceph RADOS Gateway (RGW) supports various Server-Side Encryption (SSE) methods to secure data stored in its object storage. These methods allow Ceph to automatically encrypt data as it is written, helping ensure that data at rest is protected without requiring the user to manage encryption independently. See the following for the supported SSE methods and their differences.

SSE-C (Server-Side Encryption with Customer-Provided Keys): SSE-C allows clients to manage their own encryption keys. The client provides Ceph with a key for each object request in this mode. Ceph then uses this key to encrypt the data before storing it and must decrypt it using the same key when data is requested.
This method suits users who require complete control over their encryption keys but are willing to manage them securely.
SSE-S3 (Server-Side Encryption with S3 Managed Keys): IBM Storage Ceph manages encryption and decryption in this configuration. The encryption and decryption are done by using external KMS to handle keys securely. SSE-S3 provides transparent encryption, automatically encrypting data when it is stored and decrypted when retrieved without requiring extra effort from the client. SSE-S3 is only supported with the HashiCorp Vault Integration Program.
SSE-KMS (Server-Side Encryption with Key Management Service): SSE-KMS provides server-side encryption where an external Key Management Service (KMS) keys, such as IBM GKLM, manage keys. When using this method, Ceph communicates with a KMS to retrieve the encryption keys for encrypting and decrypting data. The keys are stored and managed externally, which can simplify compliance with encryption standards.

Table 1 compares and contrasts the different options.

Table 1. SSE options advantages and disadvantages
	SSE-C	SSE-KMS	SSE-S3
Key management	Handled by the client. The key is provided on every read-and-write request.	Handled by the KMS. For example, IBM GKLM.	SSE-S3.
Advantages	Full control over the keys remains with the user, allowing for more custom security policies.	Centralized and secure key management. The KMS takes care of the entire lifecycle of the encryption keys, including auditing, rotation, and deletion.	Provides transparent encryption, automatically encrypting data when it is stored and decrypted when retrieved without requiring extra effort from the client
Disadvantages	The user bears the burden of key management. Losing the key results in the permanent loss of data.	Requires integration with an external KMS, which can add complexity to the setup.	SSE-S3 is only supported by the Hashicorp Vault Integration Program.