Enable Server Side Encryption

Server-Side Encryption (SSE) encrypts objects as MinIO AIStor writes them, protecting your data at rest without requiring clients to encrypt data themselves. SSE also underpins regulatory and compliance requirements around secure locking and erasure of data.

To perform SSE, AIStor Server connects to a key manager that stores and protects the encryption keys. This page introduces how AIStor encrypts data, how to choose a key manager, and the encryption types AIStor supports. When you are ready to enable SSE, follow the procedure for your key manager:

Server-Side Encryption with MinIO KMS — recommended for new deployments.
Server-Side Encryption with KES — to connect a supported third-party KMS.

How AIStor encrypts data

AIStor uses envelope encryption, a layered approach where keys protect other keys:

A master key (also called an external key) is a long-lived key stored in the key manager. AIStor never holds the plaintext master key on disk — it stays in the key manager.
For each object, AIStor requests a unique data key derived from a master key. It encrypts the object with the data key, then stores only an encrypted copy of the data key in the object metadata. To read the object, AIStor asks the key manager to decrypt the data key, then decrypts the object.

Because the plaintext master keys exist only inside the key manager, controlling access to the key manager controls access to every object it protects. This property is what makes secure erasure and locking possible.

When you enable SSE, AIStor also encrypts its own backend — identity and access management (IAM) data, configuration, and other internal state — using the default master key.

After you enable SSE, AIStor requires access to the key manager and the default master key to decrypt the backend and start. You cannot disable or reset backend encryption once enabled.

For a deeper explanation of the key manager itself, see the MinIO KMS documentation.

Choose a key manager

AIStor supports three key managers. Configure exactly one through the server-side encryption settings.

Key manager	Use it when	Learn more
MinIO KMS (recommended)	You want a dedicated root key manager with native AIStor integration. This is the default key manager for new deployments.	Enable with MinIO KMS
Key Encryption Service (KES)	You must store master keys in a supported third-party KMS, such as HashiCorp Vault, AWS, Azure, Google Cloud, Entrust, Fortanix, or Thales. Considered legacy.	Enable with KES
Static key	You are testing or evaluating SSE. Not for production.	`MINIO_KMS_SECRET_KEY`

MinIO KMS provides equivalent functionality to third-party KMS solutions for managing root encryption keys. If you run KES today, you can migrate to MinIO KMS without re-encrypting your data.

Supported encryption types

MinIO AIStor SSE is feature and API compatible with AWS Server-Side Encryption and supports the following encryption strategies:

MinIO AIStor automatically deploys with SSE-KMS encryption of all objects written to a bucket using a specific external key stored in an external key manager. Clients can override the bucket default by specifying an explicit key as part of the write operation.

For buckets without automatic SSE-KMS encryption, clients can specify a key as part of the write operation instead.

You cannot disable SSE-KMS encryption once enabled. MinIO AIStor encrypts backend data as part of enabling server-side encryption.

SSE-KMS provides more granular and customizable encryption compared to SSE-S3 and SSE-C.

MinIO AIStor supports automatic SSE-S3 encryption of all objects written to a bucket with an external key stored in the external key manager. MinIO AIStor SSE-S3 supports one external key for the entire deployment.

For buckets without automatic SSE-S3 encryption, clients can request SSE encryption as part of the write operation instead.

Clients specify an external key as part of the write operation for an object. MinIO AIStor uses the specified key to perform SSE-S3.

SSE-C does not support bucket-default encryption settings and requires clients to perform all key management operations.

SSE-C requires TLS/HTTPS

SSE-C requires a TLS/HTTPS-enabled deployment. The S3 client transmits the customer-provided encryption key in the HTTP request headers, so the key must never travel over plain HTTP.

SSE-C key rotation

S3 clients can change the client-provided key of an existing object. To rotate the key, the client performs an S3 COPY operation where the copy source and destination are the same object, supplying both the current and new keys in the request headers:

Header	Value
`X-Amz-Server-Side-Encryption-Customer-Key`	Base64-encoded new key
`X-Amz-Copy-Source-Server-Side-Encryption-Customer-Key`	Base64-encoded current key

Such a self-COPY request is also known as S3 SSE-C key rotation.

Secure erasure and locking

Because AIStor needs the encryption key — and therefore the key manager — to decrypt an object, you can securely lock or erase objects by controlling access to the key.

General strategies include, but are not limited to:

Seal the key manager so AIStor can no longer reach any keys. This locks all SSE-KMS and SSE-S3 encrypted objects. The objects remain unreadable as long as the key manager stays sealed.
Seal or unmount an encryption key. This locks all SSE-KMS or SSE-S3 encrypted objects protected by that key. The objects remain unreadable as long as the key remains sealed.
Delete an encryption key. This renders all SSE-KMS or SSE-S3 encrypted objects protected by the key permanently unreadable. Combining key deletion with data deletion may satisfy regulatory requirements for secure erasure.

Deleting a key is typically irreversible. Exercise extreme caution before intentionally deleting a master key.