Encryption and SOS

Encryption with SOS is realized at various levels:

  • Data in transit
  • Data at rest

Encryption in transit

By default all data and metadata being sent or retrieved to buckets and objects using SOS endpoints is encrypted in transit using HTTPs TLS support.

Encryption at rest

In order to ensure data can be retrieved in a consistent shape, SOS does not take a default decision on data at rest encryption. Encryption at rest is however highly encouraged but in the responsibility domain of the customer in order to separate the duties.

It can be achieved using:

  • Client side encryption: data is encrypted before being sent to SOS by the client library, tool or code.
  • Server side encryption with customer key: data is encrypted on the server - on SOS - at reception and deciphered on the server at egress using keys provided by the customer.

Note

SSE-KMS while similar to SSE-C is currently not supported on Exoscale. A KMS implementation is planned for future release and this page will be updated accordingly when available.

SSE-C

To use SSE-C, you need to be able to manage your keys. Data can only be retrieved by providing the original key. Storing your keys must be achieved in a durable and higly available way.

The keys must be 256-bit AES keys and provided to the SOS API base64 encoded. An example command to generate such a key is:

openssl rand 32 -out my_personal_sse-c.key

Limitations:

SSE-C has no CLI or Portal support. The use of native tools supporting SSE-C is recommended. SOS does not allow copies of objects with different keys, to support this case, the object must first be retrieved locally, then re-uploaded.