Use server-side encryption
Suggest changes
PDFs
Server-side encryption allows you to protect your object data at rest. StorageGRID encrypts the data as it writes the object and decrypts the data when you access the object.
If you want to use server-side encryption, you can choose either of two mutually exclusive options, based on how the encryption keys are managed:
-
SSE (server-side encryption with StorageGRID-managed keys): When you issue an S3 request to store an object, StorageGRID encrypts the object with a unique key. When you issue an S3 request to retrieve the object, StorageGRID uses the stored key to decrypt the object.
-
SSE-C (server-side encryption with customer-provided keys): When you issue an S3 request to store an object, you provide your own encryption key. When you retrieve an object, you provide the same encryption key as part of your request. If the two encryption keys match, the object is decrypted and your object data is returned.
While StorageGRID manages all object encryption and decryption operations, you must manage the encryption keys you provide.
The encryption keys you provide are never stored. If you lose an encryption key, you lose the corresponding object. 
If an object is encrypted with SSE or SSE-C, any bucket-level or grid-level encryption settings are ignored.
Use SSE
To encrypt an object with a unique key managed by StorageGRID, you use the following request header:
x-amz-server-side-encryption
The SSE request header is supported by the following object operations:
-
PUT Object
-
PUT Object - Copy
-
Initiate Multipart Upload
Use SSE-C
To encrypt an object with a unique key that you manage, you use three request headers:
| Request header | Description |
|---|---|
|
Specify the encryption algorithm. The header value must be |
|
Specify the encryption key that will be used to encrypt or decrypt the object. The value for the key must be 256-bit, base64-encoded. |
|
Specify the MD5 digest of the encryption key according to RFC 1321, which is used to ensure the encryption key was transmitted without error. The value for the MD5 digest must be base64-encoded 128-bit. |
The SSE-C request headers are supported by the following object operations:
-
GET Object
-
HEAD Object
-
PUT Object
-
PUT Object - Copy
-
Initiate Multipart Upload
-
Upload Part
-
Upload Part - Copy
Considerations for using server-side encryption with customer-provided keys (SSE-C)
Before using SSE-C, be aware of the following considerations:
-
You must use https.
StorageGRID rejects any requests made over http when using SSE-C. For security considerations, you should consider any key you send accidentally using http to be compromised. Discard the key, and rotate as appropriate. -
The ETag in the response is not the MD5 of the object data.
-
You must manage the mapping of encryption keys to objects. StorageGRID does not store encryption keys. You are responsible for tracking the encryption key you provide for each object.
-
If your bucket is versioning-enabled, each object version should have its own encryption key. You are responsible for tracking the encryption key used for each object version.
-
Because you manage encryption keys on the client side, you must also manage any additional safeguards, such as key rotation, on the client side.
The encryption keys you provide are never stored. If you lose an encryption key, you lose the corresponding object. -
If CloudMirror replication is configured for the bucket, you cannot ingest SSE-C objects. The ingest operation will fail.