La crittografia di Backblaze B2 lascerà invariati gli oggetti meno recenti
Backblaze B2 renderà automatica la crittografia per i nuovi caricamenti e le nuove copie a partire dal 14 settembre 2026, ma la modifica non crittograferà i dati meno recenti già archiviati. Nell'annuncio del 27 agosto, Backblaze ha dichiarato che al lancio l'impostazione predefinita si applicherà ai nuovi bucket, i contenitori utilizzati per organizzare i file archiviati, in tutte le regioni B2. I bucket esistenti la riceveranno gradualmente, quindi la domanda importante per i loro proprietari è quando verrà abilitata nel proprio bucket.
La modifica utilizza la crittografia lato server con chiavi gestite da Backblaze (SSE-B2): ciò significa che il fornitore dello spazio di archiviazione crittografa i dati e gestisce le chiavi necessarie per leggerli. Protegge i dati degli oggetti, ossia i file conservati nell'archiviazione a oggetti nel cloud, utilizzando AES-256, l'Advanced Encryption Standard con chiavi a 256 bit. Si tratta di crittografia dei dati a riposo, una protezione dei dati mentre sono archiviati. Backblaze afferma che la modifica non richiede interventi sulle applicazioni, non aggiunge costi per la crittografia e non influisce sulle prestazioni di caricamento o download. Restano applicabili le normali tariffe per l'archiviazione e per l'interfaccia di programmazione delle applicazioni (API); un'API è l'interfaccia che il software utilizza per richiedere operazioni a un servizio.
In precedenza, i clienti potevano abilitare SSE-B2 per un bucket o richiederla per un caricamento specifico. Una volta attivata la nuova impostazione predefinita in un bucket, ogni nuovo caricamento e ogni copia di destinazione riceve SSE-B2, a meno che la richiesta non selezioni esplicitamente SSE-C, la crittografia lato server che utilizza una chiave fornita dal cliente. I bucket già configurati per SSE-B2 mantengono la propria configurazione. La crittografia lato server non può essere disattivata per le nuove scritture dopo l'abilitazione: cancellare o eliminare un'impostazione esplicita di crittografia del bucket non ripristinerà un'impostazione predefinita priva di crittografia.
Questo elimina una scelta di configurazione da ogni applicazione e processo di distribuzione. Il vantaggio generalizzabile è l'uniformità: la protezione dei dati archiviati non dipende più dal fatto che ogni strumento di caricamento si ricordi di richiederla, e diminuiscono le impostazioni che possono divergere nel tempo. Il limite, tuttavia, è altrettanto importante. Un'impostazione predefinita automatica per i dati futuri non dimostra che tutti i file storici abbiano la stessa protezione.
Backblaze descrive questa novità come una modifica del comportamento, non del contratto API, ossia delle regole che disciplinano le richieste e le risposte del software. Le operazioni esistenti di caricamento, copia, download e caricamento multiparte, che inviano un file in parti separate, restano valide. B2 decrittografa automaticamente gli oggetti SSE-B2 per le letture autorizzate, quindi le applicazioni recuperano i file come prima. L'introduzione della novità aggiunge inoltre il supporto per i file crittografati con SSE-B2 a B2 Snapshots e ai download tramite la console web di Backblaze, senza richiedere agli utenti di modificare questi flussi di lavoro.
Per gli sviluppatori che utilizzano S3-Compatible API, un'interfaccia compatibile con le richieste di archiviazione di Amazon S3, i caricamenti senza intestazioni di crittografia ricevono automaticamente SSE-B2. Le intestazioni sono istruzioni aggiuntive allegate a una richiesta. Backblaze afferma che PutObject, CopyObject e i caricamenti multiparte applicano tutti l'impostazione predefinita all'oggetto di destinazione, mentre le intestazioni SSE-C valide hanno la precedenza. La rappresentazione della crittografia compatibile con S3 è AES256. Nell'esempio da riga di comando di Backblaze, un caricamento con aws s3api put-object utilizza un profilo, un endpoint regionale, un bucket, un nome dell'oggetto e un file locale, ma omette --server-side-encryption. Il suo esempio separato con aws s3api get-bucket-encryption restituisce "SSEAlgorithm": "AES256".
B2 Native API, l'interfaccia di richiesta proprietaria di Backblaze, segue lo stesso principio. Le applicazioni possono omettere i campi e le intestazioni SSE-B2 per i caricamenti ordinari, i caricamenti di file di grandi dimensioni e le copie di destinazione. L'esempio curl di Backblaze, che utilizza uno strumento da riga di comando per inviare richieste web, include l'autorizzazione, il nome del file, il tipo di contenuto e un checksum SHA-1, un valore utilizzato per verificare l'integrità del file. Omette X-Bz-Server-Side-Encryption, eppure la risposta riporta serverSideEncryption con modalità SSE-B2 e algoritmo AES256. La richiesta esplicita di SSE-B2 resta supportata, ma non è più necessaria per ottenere la crittografia dei dati a riposo una volta attivata l'impostazione predefinita.
Poiché è B2 ad applicare la protezione, i kit di sviluppo software (SDK) esistenti, raccolte di codice per collegare le applicazioni a un servizio, e le interfacce a riga di comando (CLI), strumenti utilizzati tramite comandi digitati, non richiedono aggiornamenti per questa modifica. Neppure le integrazioni esistenti necessitano di un'opzione specifica per la crittografia. Backblaze afferma che le sue console web mostreranno SSE-B2 o AES256 come impostazione predefinita effettiva del bucket, continuando al contempo a mostrare la crittografia realmente utilizzata da ciascun oggetto. Questa distinzione aiuta gli utenti a non confondere l'impostazione predefinita attuale di un bucket con lo stato dei file meno recenti al suo interno.
Le chiavi controllate dal cliente restano un'opzione. Una richiesta con intestazioni SSE-C valide utilizza la chiave AES-256 fornita anziché la crittografia gestita da Backblaze per quell'oggetto. I clienti devono fornire le intestazioni richieste quando caricano, copiano o accedono a oggetti SSE-C. Backblaze non conserva queste chiavi e non può recuperarle se vengono perse: spetta quindi ai clienti proteggerle e conservarle. Rimane inoltre possibile crittografare i dati lato client, prima del caricamento. SSE-KMS, la crittografia lato server integrata con un servizio di gestione delle chiavi, non è inclusa in questo aggiornamento.
Per i dati esistenti, nulla cambia retroattivamente. Backblaze afferma che non riscriverà in background i file archiviati dei clienti, né modificherà i metadati storici della crittografia, ossia le informazioni descrittive che registrano come un oggetto è protetto. Gli oggetti meno recenti mantengono lo stato che avevano al momento della scrittura. Per applicare la protezione SSE-B2 a un oggetto meno recente non crittografato, occorre caricarlo di nuovo o creare una nuova copia di destinazione dopo l'abilitazione dell'impostazione predefinita del bucket. Le risposte alle richieste di informazioni sugli oggetti e di download continueranno a descrivere la crittografia realmente utilizzata per quello specifico oggetto.
Per le aziende che valutano un'infrastruttura gestita, i servizi europei di cloud e infrastruttura dati di AEU Data includono database gestiti, backup e archiviazione crittografata, funzionalità rilevanti per la protezione dei dati aziendali archiviati. La lezione pratica dell'introduzione della novità di Backblaze è verificare sia l'impostazione predefinita attiva sia la protezione dei file esistenti: un'impostazione più sicura per i caricamenti di domani non modifica, da sola, i dati di ieri.