Backblaze B2 rend le chiffrement AES-256 au repos par défaut sur chaque nouvel upload
Le 27 août 2026, Backblaze annonce que SSE-B2 chiffre automatiquement en AES-256 tout nouvel objet dès le 14 septembre, sans surcoût ni changement d’API. Pour l’auto-hébergeur qui sauvegarde sur B2, le chiffrement au repos cesse d’être une case à cocher à activer soi-même.
27 août 2026. Backblaze publie un billet annonçant que SSE-B2, son chiffrement côté serveur à clés gérées, devient le comportement par défaut. 14 septembre 2026. C’est la date d’entrée en vigueur du changement. AES-256. C’est l’algorithme appliqué à chaque nouvel objet, sans surcoût ni impact sur les performances. Pourquoi c’est important : une bonne partie des auto-hébergeurs qui sauvegardent sur Backblaze B2 n’ont jamais activé le chiffrement au repos, parce qu’il fallait y penser. Ce défaut supprime l’oubli.
Le chiffrement au repos sans case à cocher
Jusqu’ici, SSE-B2 était une option. Un client pouvait l’activer sur un bucket ou la demander upload par upload, mais rien ne l’y obligeait. La conséquence, c’est un parc de stockage où certains buckets sont chiffrés au repos et d’autres non, selon l’historique de chaque projet et la rigueur de la personne qui a créé le bucket.
À partir du 14 septembre 2026, Backblaze inverse la logique. Chaque objet nouvellement uploadé ou copié est chiffré automatiquement avec SSE-B2 et AES-256, que l’application le demande ou non. Le chiffrement au repos devient la base, et non plus l’exception. Les buckets neufs reçoivent le comportement immédiatement ; les buckets existants le reçoivent progressivement, et une fois le basculement effectué pour un bucket, ses nouveaux objets passent tous sous SSE-B2.
Le point central, c’est que rien ne change côté application. Pas de header à ajouter, pas de réglage de bucket à activer, pas de surcoût, et pas de perte de débit à l’upload ou au téléchargement. C’est ce que Backblaze appelle une mise à jour comportementale, pas un nouveau contrat d’API.
Ce qui change concrètement pour les intégrations S3
Backblaze B2 est un stockage objet compatible S3, et c’est par cette interface que passent la plupart des outils de sauvegarde auto-hébergés : restic, rclone, Duplicati, ou encore Borg poussé vers un remote via rclone. Tous ces outils parlent le protocole S3 sans nécessairement préciser une méthode de chiffrement côté serveur.
Avec le nouveau défaut, un PutObject qui n’envoie aucun header de chiffrement reçoit quand même SSE-B2. Dans les réponses compatibles S3, ce chiffrement effectif est représenté par la valeur AES256. L’exemple que publie Backblaze est sans ambiguïté : une commande aws s3api put-object dépourvue d’option --server-side-encryption produit un objet chiffré.
aws s3api put-object \
--profile backblaze \
--endpoint-url https://s3.YOUR-REGION.backblazeb2.com \
--bucket YOUR-BUCKET-NAME \
--key hello.txt \
--body ./hello.txt
# Aucun flag de chiffrement : l’objet est quand même chiffré en SSE-B2 (AES256)L’API native B2 suit la même logique : un upload qui omet le header X-Bz-Server-Side-Encryption reçoit une réponse contenant "serverSideEncryption": {"mode": "SSE-B2", "algorithm": "AES256"}. Les objets existants, eux, conservent leur état de chiffrement actuel : Backblaze ne re-chiffre pas rétroactivement des données déjà stockées.
Ce que SSE-B2 ne règle pas, et pourquoi SSE-C reste là
Il faut être précis sur ce que couvre ce défaut. SSE-B2 chiffre les données au repos, avec des clés gérées par Backblaze. Cela répond à l’exigence classique de chiffrement des sauvegardes stockées chez un tiers, et cela ferme la faille du bucket oublié en clair. Mais cela ne remplace pas le chiffrement de bout en bout : si vous voulez que Backblaze ne puisse jamais lire vos objets, il faut fournir vos propres clés.
C’est exactement ce que fait SSE-C, le chiffrement côté serveur avec clés fournies par le client. Il reste disponible, et il garde la priorité : un upload qui spécifie SSE-C continue d’utiliser SSE-C, sans basculer vers SSE-B2. Pour un auto-hébergeur, la règle de décision est simple. Si votre modèle de menace exige que le fournisseur ignore le contenu de vos sauvegardes, chiffrez côté client avec restic, rclone crypt ou Borg avant l’envoi, et gardez SSE-C pour les cas où vous voulez maîtriser la clé au niveau de l’objet. Sinon, SSE-B2 par défaut est déjà un progrès net sur l’état précédent.
Pourquoi cela compte pour l’auto-hébergé
Le cas d’usage dominant de B2 dans la communauté auto-hébergée, c’est la sauvegarde hors site. On héberge ses services sur un Proxmox ou un NAS, et on pousse des snapshots chiffrés vers B2 pour respecter la règle 3-2-1 sans gérer un second site physique. Le chiffrement au repos de B2 était techniquement disponible, mais dans la pratique beaucoup d’installations ne l’activaient pas, soit par méconnaissance, soit parce que l’outil de sauvegarde n’exposait pas l’option.
Concrètement, rien ne change pour les outils qui ciblent B2 via son interface S3. restic, rclone, Duplicati ou un Proxmox Backup Server pointé vers un stockage compatible S3 continuent d’envoyer leurs objets sans préciser de méthode de chiffrement côté serveur, et B2 chiffre désormais par défaut. Le seul cas où une action existait déjà — un outil qui transmettait explicitement le header SSE-B2 — continue de fonctionner à l’identique : la demande explicite et le défaut aboutissent au même résultat. Pour celui qui maintenait un mélange de buckets chiffrés et non chiffrés, ce défaut est aussi l’occasion de normaliser : à terme, tout ce qui entre dans B2 est chiffré, et la question ne se pose plus bucket par bucket.
En rendant le chiffrement automatique, Backblaze retire une décision de configuration de la chaîne. Le résultat est un meilleur socle de sécurité sans effort supplémentaire, et une réponse immédiate aux audits qui demandent « vos sauvegardes chez le tiers sont-elles chiffrées au repos ? ». C’est aussi un argument commercial : sur ce critère, B2 s’aligne désormais sur les grands clouds qui chiffrent par défaut, tout en restant nettement moins cher pour les gros volumes.
Ce qu’il faut vérifier après le 14 septembre
Le déploiement est progressif pour les buckets existants, ce qui ouvre une période où deux buckets voisins peuvent se comporter différemment. Le moyen de savoir si un bucket est passé sous le nouveau défaut est d’interroger sa configuration de chiffrement : en API compatible S3, un get-bucket-encryption renvoie SSEAlgorithm: AES256 une fois le basculement effectif ; en API native B2, la réponse d’un upload contient le champ serverSideEncryption avec le mode SSE-B2 et l’algorithme AES256.
Pour un auto-hébergeur qui pilote ses sauvegardes par script, ce point mérite un contrôle plutôt qu’une confiance aveugle. Un test après la date d’entrée en vigueur suffit : uploader un objet sans header de chiffrement, puis relire ses métadonnées pour confirmer que SSE-B2 a bien été appliqué. C’est le genre de vérification qu’un audit demandera, et la réponse tient en une commande.
# Vérifier que le chiffrement par défaut est actif sur un bucket
aws s3api get-bucket-encryption \
--profile backblaze \
--endpoint-url https://s3.YOUR-REGION.backblazeb2.com \
--bucket YOUR-BUCKET-NAME
# Attendu après basculement : "SSEAlgorithm": "AES256"Il faut aussi rappeler une limite du défaut : SSE-B2 couvre les objets nouvellement écrits, pas ceux écrits avant le basculement. Sur un bucket ancien, les données historiques restent dans l’état où elles ont été écrites. Si la conformité exige qu’un bucket entier soit chiffré, la migration consiste à recopier les objets via CopyObject, opération qui applique précisément le nouveau défaut à la destination.
Verdict
Si vous sauvegardez déjà sur B2, vous n’avez rien à faire : le basculement est transparent, gratuit et sans impact mesuré sur les performances. Vérifiez simplement, après le 14 septembre, que vos nouveaux objets remontent bien la valeur AES256 ou SSE-B2 dans les réponses, et gardez SSE-C pour les objets que vous devez chiffrer avec vos propres clés.
Si vous chiffrez déjà côté client avec restic, rclone crypt ou Borg, ce défaut ajoute une couche de chiffrement au repos qui ne vous coûte rien et ne crée pas de conflit : vos clés restent les vôtres, et B2 chiffre en plus ce qu’il stocke.
Si vous comparez des cibles de sauvegarde, notez que B2 vient de supprimer l’un des derniers reproches qu’on pouvait lui faire face aux hyperscalers, sans toucher à son prix. Le chiffrement au repos n’est plus un critère de différenciation.