Un valore predefinito, quando cambia, può passare inosservato finché qualcosa smette di funzionare. È il caso di un aggiornamento che Amazon Web Services (AWS) ha iniziato a distribuire ad aprile 2026 sul suo servizio di archiviazione S3: la cifratura con chiave fornita dal cliente, nota come SSE-C, non è più attiva per impostazione predefinita sui nuovi bucket. Un bucket è il contenitore di base in cui S3 conserva i file, che nel gergo del servizio si chiamano oggetti, lo stesso concetto ripreso anche dai più recenti vector bucket per la ricerca semantica. Per la maggior parte di chi usa S3 non cambia nulla. Ma chi ha automazioni o applicazioni che si appoggiano a SSE-C ha un buon motivo per controllare le proprie configurazioni prima che il cambiamento arrivi ovunque.

Cos’è SSE-C, e dove si colloca

S3 offre la cifratura lato server (server-side encryption): i dati vengono cifrati automaticamente quando vengono scritti su disco e decifrati alla lettura, senza che l’applicazione debba occuparsene. La differenza tra le varianti sta in una domanda sola: chi possiede e gestisce la chiave.

• SSE-S3 - la chiave la genera e la gestisce AWS. È l’opzione più semplice e quella predefinita.
• SSE-KMS - la chiave vive in AWS Key Management Service (KMS), il servizio dedicato alla gestione delle chiavi. In cambio si ottengono controlli d’accesso fini tramite le policy IAM (il sistema dei permessi di AWS) e una traccia di ogni uso della chiave in CloudTrail, il registro delle attività dell’account, un livello di tracciabilità che si allinea bene ai principi di accountability richiesti anche dal GDPR.
• SSE-C - la chiave la fornisce il cliente, e la invia a S3 a ogni richiesta di scrittura e di lettura. S3 la usa per cifrare o decifrare al volo, ma non la conserva da nessuna parte. Il controllo della chiave resta interamente in mano a chi la produce.

Proprio quest’ultimo punto è il tratto distintivo di SSE-C: siccome S3 non memorizza la chiave, senza quella chiave i dati non si leggono, nemmeno lato AWS. È una garanzia forte, ma anche un vincolo operativo pesante.

Cosa cambia, in concreto

L’aggiornamento riguarda i bucket “general purpose”, cioè quelli standard usati nella stragrande maggioranza dei casi.

• Nuovi bucket: SSE-C è disabilitato di default. Ogni bucket creato dopo il rollout parte con SSE-C bloccato.
• Bucket esistenti: dipende dall’account. Se l’account non contiene alcun oggetto cifrato con SSE-C, S3 ha disattivato SSE-C anche sui bucket già presenti. Se invece anche un solo bucket dell’account contiene oggetti SSE-C, S3 non ha toccato nessuna configurazione di quell’account, per non rompere ciò che è in uso.
• Tempi e regioni: la distribuzione è partita ad aprile 2026 e ha raggiunto 37 regioni AWS, comprese le regioni AWS China e AWS GovCloud (US). Fanno eccezione, almeno per ora, le regioni Middle East (Bahrain) e Middle East (UAE), dove il nuovo default non si applica. Il cambiamento non è arrivato a sorpresa: AWS aveva pubblicato un preavviso a novembre 2025.

Vale la pena sottolineare che si tratta di un cambiamento reale e già in corso, non di una beta né di una proposta: il default è cambiato davvero.

Perché AWS lo fa

La motivazione dichiarata è che SSE-C, oggi, offre pochi vantaggi rispetto alle alternative. Poiché S3 non conserva la chiave, questa va rispedita a ogni singola richiesta: condividere l’accesso ai dati con altri utenti o servizi diventa scomodo, e manca la tracciabilità che KMS offre in modo naturale con IAM e CloudTrail. Da quando esiste KMS - che permette di creare, possedere e gestire chiavi con controlli d’accesso e registrazione degli usi - il beneficio pratico di SSE-C si è di fatto assottigliato, e la maggior parte dei carichi di lavoro moderni ha smesso di usarlo.

Il cambio di default va quindi letto come una scelta di sicurezza per impostazione predefinita: disattivare una funzione poco usata riduce la superficie su cui possono nascere errori di configurazione, lasciando comunque a chi ne ha davvero bisogno la possibilità di riattivarla.

Cosa succede a chi usa ancora SSE-C

Su un bucket dove SSE-C è bloccato, ogni richiesta che chiede esplicitamente SSE-C viene rifiutata con un errore HTTP 403 AccessDenied, cioè un “accesso negato”. Riguarda i caricamenti (PutObject), le copie (CopyObject), le PostObject, i caricamenti multiparte e le repliche tra bucket.

Per un’applicazione che si aspetta di scrivere con SSE-C, questo si traduce in un errore improvviso e potenzialmente diffuso. Da qui l’importanza di accorgersene in anticipo, quando è una verifica pianificata e non un incidente in produzione.

Cosa conviene verificare prima

Conviene procedere per due domande, in ordine.

Prima domanda: si usa SSE-C da qualche parte? Non sempre è ovvio, soprattutto in automazioni scritte tempo fa. Per scoprirlo si può esaminare in CloudTrail quali metodi di cifratura compaiono nelle richieste verso S3, e usare i report di S3 Inventory per elencare gli oggetti già cifrati con SSE-C. Per controllare la configurazione di cifratura di un singolo bucket si può interrogare l’API con un comando di sola lettura:

aws s3api get-bucket-encryption --bucket nome-del-bucket

Seconda domanda: se SSE-C serve davvero, come si riattiva? Su un bucket nuovo va abilitato in modo esplicito chiamando l’API PutBucketEncryption (serve il permesso s3:PutEncryptionConfiguration), dopodiché le applicazioni continuano a includere le consuete intestazioni SSE-C nelle loro richieste. La stessa API gestisce anche l’impostazione a livello di bucket introdotta per l’occasione, che consente di bloccare o sbloccare SSE-C in modo controllato, bucket per bucket.

Per chi scopre di dipendere ancora da SSE-C, il momento è buono anche per una domanda più a monte: quel dato ha davvero bisogno di una chiave gestita fuori da AWS, o SSE-KMS coprirebbe l’esigenza offrendo in più tracciabilità e controlli d’accesso? La risposta cambia da caso a caso, ma vale la pena porsela ora, con calma, invece che davanti a un caricamento fallito.

In sintesi

Il messaggio operativo è semplice. Il cambiamento è già in distribuzione, era stato annunciato con mesi di anticipo e per la maggior parte degli utenti è trasparente, oltre a spingere verso un default più prudente. Per chi ha investito su SSE-C - spesso in pipeline o script che nessuno guarda da tempo - il compito è chiaro: individuare dove SSE-C è in uso, decidere se ha ancora senso o se conviene passare a SSE-KMS, e nel caso riabilitarlo esplicitamente sui bucket giusti prima che il default aggiornato faccia fallire una scrittura, esattamente come si testa un ripristino prima che serva davvero.

Fonti

• Amazon S3 starts rolling out new security best practice to new and existing buckets by default (AWS What’s New)
• Advanced notice: Amazon S3 to disable the use of SSE-C encryption by default (AWS Storage Blog)
• Default SSE-C setting for new buckets FAQ (Amazon S3 User Guide)