Backblaze B2: Verschlüsselung lässt ältere Objekte unverändert
Backblaze B2 verschlüsselt neue Uploads und Kopien ab dem 14. September 2026 automatisch. Bereits gespeicherte ältere Daten werden durch diese Änderung jedoch nicht verschlüsselt. In seiner Ankündigung vom 27. August erklärte Backblaze, dass die Standardeinstellung zum Start in jeder B2-Region für neue Buckets gelten wird – also für die Container, in denen gespeicherte Dateien organisiert werden. Bei bestehenden Buckets wird sie schrittweise eingeführt. Für deren Besitzer ist daher entscheidend, wann die Einstellung für ihren jeweiligen Bucket aktiviert wurde.
Die Änderung nutzt die serverseitige Verschlüsselung mit von Backblaze verwalteten Schlüsseln (SSE-B2). Das bedeutet, dass der Speicheranbieter die Daten verschlüsselt und die zum Lesen erforderlichen Schlüssel verwaltet. Sie schützt Objektdaten, also die im Cloud-Objektspeicher abgelegten Dateien, mithilfe von AES-256, dem Advanced Encryption Standard mit 256-Bit-Schlüsseln. Dabei handelt es sich um Verschlüsselung ruhender Daten, also um den Schutz von Daten während ihrer Speicherung. Laut Backblaze sind dafür keine Änderungen an Anwendungen erforderlich, es fallen keine zusätzlichen Verschlüsselungsgebühren an, und die Leistung beim Hoch- oder Herunterladen bleibt unverändert. Die üblichen Gebühren für Speicher und die Anwendungsprogrammierschnittstelle (API) gelten weiterhin. Eine API ist die Schnittstelle, über die Software Vorgänge bei einem Dienst anfordert.
Bisher konnten Kunden SSE-B2 für einen Bucket aktivieren oder für einen bestimmten Upload anfordern. Sobald die neue Standardeinstellung für einen Bucket aktiv ist, erhält jeder neue Upload und jede am Ziel erstellte Kopie SSE-B2, sofern die Anfrage nicht ausdrücklich SSE-C auswählt, also die serverseitige Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel. Bereits für SSE-B2 konfigurierte Buckets behalten ihre Konfiguration. Die serverseitige Verschlüsselung lässt sich nach der Aktivierung für neue Schreibvorgänge nicht mehr abschalten: Das Zurücksetzen oder Löschen einer ausdrücklich festgelegten Bucket-Verschlüsselungseinstellung stellt keinen unverschlüsselten Standard wieder her.
Damit entfällt für jede Anwendung und jeden Bereitstellungsprozess eine Konfigurationsentscheidung. Der übertragbare Vorteil liegt in der Einheitlichkeit: Der Schutz gespeicherter Daten hängt nicht mehr davon ab, dass jedes Upload-Werkzeug die Verschlüsselung auch tatsächlich anfordert. Zudem gibt es weniger Einstellungen, die im Laufe der Zeit voneinander abweichen können. Ebenso wichtig ist jedoch die Grenze dieser Änderung. Eine automatische Standardeinstellung für künftige Daten ist kein Beleg dafür, dass jede früher gespeicherte Datei denselben Schutz besitzt.
Backblaze beschreibt dies als eine Verhaltensänderung und nicht als Änderung des API-Vertrags, also der Regeln für Softwareanfragen und -antworten. Bestehende Vorgänge zum Hochladen, Kopieren und Herunterladen sowie Multipart-Uploads, bei denen eine Datei in einzelnen Teilen übertragen wird, bleiben gültig. B2 entschlüsselt SSE-B2-Objekte bei autorisierten Lesezugriffen automatisch, sodass Anwendungen Dateien wie bisher abrufen. Mit der Einführung wird außerdem die Unterstützung für SSE-B2-verschlüsselte Dateien in B2 Snapshots und für Downloads über die Backblaze-Webkonsole ergänzt, ohne dass Nutzer diese Arbeitsabläufe ändern müssen.
Für Entwickler, die die S3-Compatible API verwenden, eine mit Speicheranfragen an Amazon S3 kompatible Schnittstelle, erhalten Uploads ohne Verschlüsselungsheader automatisch SSE-B2. Header sind zusätzliche Anweisungen, die einer Anfrage beigefügt werden. Laut Backblaze wenden PutObject, CopyObject und Multipart-Uploads die Standardeinstellung jeweils auf das Zielobjekt an, wobei gültige SSE-C-Header Vorrang haben. Die S3-kompatible Darstellung der Verschlüsselung lautet AES256. Im Befehlszeilenbeispiel von Backblaze verwendet ein Upload mit aws s3api put-object ein Profil, einen regionalen Endpunkt, einen Bucket, einen Objektnamen und eine lokale Datei, lässt jedoch --server-side-encryption weg. Das separate Beispiel mit aws s3api get-bucket-encryption gibt "SSEAlgorithm": "AES256" aus.
Die B2 Native API, Backblazes eigene Anfrageschnittstelle, folgt demselben Prinzip. Anwendungen können SSE-B2-Felder und -Header bei gewöhnlichen Uploads, beim Hochladen großer Dateien und beim Erstellen von Zielkopien weglassen. Das curl-Beispiel von Backblaze nutzt ein Befehlszeilenwerkzeug zum Senden von Webanfragen und enthält Angaben zur Autorisierung, den Dateinamen, den Inhaltstyp und eine SHA-1-Prüfsumme, also einen Wert zur Überprüfung der Dateiintegrität. X-Bz-Server-Side-Encryption wird weggelassen, dennoch meldet die Antwort serverSideEncryption mit dem Modus SSE-B2 und dem Algorithmus AES256. SSE-B2 ausdrücklich anzufordern, wird weiterhin unterstützt, ist aber nicht mehr notwendig, um ruhende Daten zu verschlüsseln, sobald die Standardeinstellung aktiv ist.
Da B2 den Schutz anwendet, benötigen vorhandene Software Development Kits (SDKs), also Codesammlungen zur Anbindung von Anwendungen an einen Dienst, und Command Line Interfaces (CLIs), also über eingegebene Befehle bediente Werkzeuge, für diese Änderung kein Upgrade. Auch bestehende Integrationen benötigen keinen speziellen Verschlüsselungsparameter. Laut Backblaze werden die Webkonsolen SSE-B2 oder AES256 als wirksame Standardeinstellung des Buckets anzeigen und zugleich weiterhin die tatsächlich für jedes Objekt verwendete Verschlüsselung ausweisen. Diese Unterscheidung hilft Nutzern, die aktuelle Standardeinstellung eines Buckets nicht mit dem Zustand älterer darin gespeicherter Dateien zu verwechseln.
Vom Kunden kontrollierte Schlüssel bleiben eine Option. Eine Anfrage mit gültigen SSE-C-Headern verwendet für das betreffende Objekt den bereitgestellten AES-256-Schlüssel anstelle der von Backblaze verwalteten Verschlüsselung. Kunden müssen die erforderlichen Header beim Hochladen, Kopieren oder beim Zugriff auf SSE-C-Objekte mitliefern. Backblaze bewahrt diese Schlüssel nicht auf und kann einen verlorenen Schlüssel nicht wiederherstellen. Die Verantwortung für ihren Schutz und ihre Aufbewahrung liegt somit bei den Kunden. Auch eine clientseitige Verschlüsselung der Daten vor dem Hochladen bleibt möglich. SSE-KMS, die serverseitige Verschlüsselung mit Anbindung an einen Schlüsselverwaltungsdienst, ist nicht Bestandteil dieses Updates.
Für bestehende Daten ändert sich rückwirkend nichts. Backblaze erklärt, weder gespeicherte Kundendateien im Hintergrund neu zu schreiben noch bisherige Verschlüsselungsmetadaten zu ändern – also die beschreibenden Informationen, die festhalten, wie ein Objekt geschützt ist. Ältere Objekte behalten den Zustand, den sie beim Schreiben hatten. Um ein älteres unverschlüsseltes Objekt mit SSE-B2 zu schützen, laden Sie es erneut hoch oder erstellen Sie eine neue Zielkopie, nachdem die Standardeinstellung des Buckets aktiviert wurde. Antworten auf Objektinformations- und Downloadanfragen beschreiben weiterhin die tatsächlich für das jeweilige Objekt verwendete Verschlüsselung.
Für Unternehmen, die eine verwaltete Infrastruktur in Betracht ziehen, umfassen die europäischen Cloud- und Dateninfrastrukturdienste von AEU Data verwaltete Datenbanken, Backups und verschlüsselten Speicher – Funktionen, die für den Schutz gespeicherter Geschäftsdaten relevant sind. Die praktische Lehre aus der Einführung bei Backblaze lautet, sowohl die aktive Standardeinstellung als auch den Schutz vorhandener Dateien zu überprüfen: Eine stärkere Einstellung für die Uploads von morgen verändert für sich genommen nicht die Daten von gestern.