Ihr Tenant, Ihr Bucket: eigene Instanz, eigener Speicher
Jeder Kunde erhält eine eigene Instanz, die verschlüsselten Dateien können in Ihrem eigenen Bucket liegen. Was das trennt, was ein Bucket-Betreiber sieht und wie der Wechsel zwischen Buckets abläuft.
Die meisten Cloud-Plattformen für Dokumente sind ein einziges großes System. Eine Spalte in der Datenbank legt fest, zu welchem Kunden eine Zeile gehört. Das ist effizient. Es bedeutet aber auch, dass die Sicherheit aller Kunden davon abhängt, dass derselbe Code zur Zugriffskontrolle nie einen Fehler macht. Sapherbox ist anders gebaut. Jeder Kunde erhält eine eigene Instanz, und der Objektspeicher mit den verschlüsselten Dateien kann ein Bucket sein, der dem Kunden selbst gehört. Dieser Artikel erklärt, was Sie damit gewinnen und was nicht, und wie das Einbinden und Wechseln eines Buckets technisch funktioniert.
Ein Tenant, eine Instanz
Ein Sapherbox-Tenant ist eine eigenständige Installation der gesamten Anwendung: eine eigene API, ein eigener Web-Client und eine eigene Datenbank, in der das Audit-Logging auf Datenbankebene aktiviert ist. Der Tenant hat einen eigenen Hostnamen und ein eigenes TLS-Zertifikat, eigene Secrets, eine eigene Absenderidentität für E-Mails und einen eigenen Bucket im Objektspeicher. Keine Datenbank enthält mehr als einen Kunden. Deshalb gibt es auch keine Abfrage, in der ein vergessener Filter einem Kunden die Zeilen eines anderen zeigen könnte.
Die Trennung gilt auch im Betrieb. Ein Tenant wird als Einheit aktualisiert, gesichert und, falls es so weit kommt, gelöscht. Ein Problem in der Installation eines Tenants betrifft genau diesen Tenant. Der Preis dafür: Wir betreiben mehr Installationen, als eine Multi-Tenant-Architektur bräuchte. Für ein Produkt, dessen Kern darin besteht, dass der Betreiber nicht hineinsehen kann, halten wir diesen Preis für angemessen.
Was im Bucket liegt
Der Bucket enthält eine Art von Objekten. Ebenso wichtig ist, was er nicht enthält.
Dateiinhalte, als Chiffrat. Jede Datei wird auf dem Gerät verschlüsselt, das sie hochlädt, und zwar mit einem Schlüssel, den der Server nie erhält. Der Bucket bekommt das Ergebnis unter einem zufälligen Objektschlüssel. Große Dateien werden in verschlüsselten Blöcken fester Größe abgelegt. Wer den Bucket betreibt, sieht nur Objektnamen ohne Aussagekraft, Objektgrößen und Zeitstempel. Das gilt für uns, für Amazon und für Ihr eigenes Speicherteam. Sonst nichts. Weder den Dateinamen, der ebenfalls verschlüsselt ist, noch ein einziges Byte des Inhalts.
Sonst nichts. Backups landen nicht hier. Die Datenbank des Tenants wird einmal täglich exportiert, komprimiert und mit age für einen öffentlichen Schlüssel verschlüsselt. Der zugehörige private Schlüssel wird offline aufbewahrt und liegt auf keinem Server. Dieses Archiv wird in einen separaten Backup-Bucket in unserem Konto geschrieben. Die Zugangsdaten des Tenants für diesen Bucket erlauben nur das Schreiben: Ein Objekt kann hinzugefügt, aber weder gelesen noch überschrieben noch gelöscht werden. Ein kompromittierter Tenant kommt also nicht an seine eigene Historie heran. Der Backup-Bucket selbst ist mit Object Lock geschützt: Niemand, auch wir nicht, kann eine Sicherung löschen, bevor ihre Aufbewahrungsfrist abgelaufen ist. Dateiobjekte werden nirgendwohin kopiert. Für ihre Dauerhaftigkeit ist der Speicher-Bucket zuständig, dazu gleich mehr. Wer die Zugangsdaten zum Backup-Bucket hat, könnte ein Datenbank-Backup herunterladen, aber nicht öffnen. Die Datenbank selbst enthält versiegelte Schlüssel, öffentliche Schlüssel, verschlüsselte Namen und die Metadaten, die wir als für den Server sichtbar ausweisen. Selbst ein entschlüsseltes Backup würde also keine Dokumente preisgeben. Wegen der age-Verschlüsselung kommt es darauf aber gar nicht erst an: Wer nur den Bucket hat, kann das Backup nicht öffnen.
Ein neuer Tenant beginnt mit einem Bucket, den wir bei AWS in Frankfurt einrichten, mit serverseitiger Verschlüsselung und gesperrtem öffentlichem Zugriff. Das ist eine zweite Schicht unter der clientseitigen Verschlüsselung. Es ist ein Startpunkt, keine Festlegung: Jeder Kunde kann eigene Buckets konfigurieren, wie der nächste Abschnitt beschreibt. Diese Schicht ist sinnvoll, aber man sollte sich nicht auf sie verlassen. Sie schützt vor einer Festplatte, die ein Rechenzentrum verlässt, nicht vor jemandem, der die Zugangsdaten zum Bucket hat.
Der eigene Bucket
Ein Administrator des Tenants kann unter „Unternehmenseinstellungen“ Speicherorte hinzufügen. Drei Arten werden unterstützt: Amazon S3, Google Cloud Storage mit dem Schlüssel eines Service-Accounts und jeder S3-kompatible Endpunkt. Letzteres umfasst Hetzner Object Storage, einen MinIO-Cluster im eigenen Rechenzentrum, Wasabi und das Speicherangebot der meisten europäischen Hoster. Bei Amazon S3 muss die Region eine der EU-Regionen sein, alles andere lehnt der Tenant ab. Bei den anderen Arten liegt der Speicherort dort, wo Sie den Bucket angelegt haben. Diesen Ort zu dokumentieren liegt bei Ihnen.
Die eingegebenen Zugangsdaten speichert der Tenant feldverschlüsselt in seiner Datenbank. Der Schlüssel dafür liegt im Secret-Speicher des Tenants, nicht in der Anwendungskonfiguration. Über die Schaltfläche „Testen“ baut der Tenant eine Verbindung zum Bucket auf und meldet das Ergebnis. So fällt ein Tippfehler auf, bevor ein Upload davon abhängt.
Es können mehrere Speicherorte gleichzeitig bestehen. Einer ist der Standard und nimmt alle neuen Uploads auf. Dateien, die schon anderswo liegen, bleiben dort und funktionieren weiter, denn zu jeder Datei ist gespeichert, an welchem Speicherort sie liegt. Genau das macht einen schrittweisen Wechsel möglich. Sie fügen Ihren Bucket hinzu, testen ihn und machen ihn zum Standard. Ab diesem Moment landen neue Dokumente in Ihrem Bucket, während die alten weiter aus unserem ausgeliefert werden.
Vorhandene Dateien umziehen
Dateien, die vor dem Wechsel hochgeladen wurden, lassen sich zwischen zwei beliebigen Speicherorten kopieren oder verschieben. Sie läuft im Hintergrund auf dem Tenant, Datei für Datei. Der Tenant liest das verschlüsselte Objekt aus der Quelle, schreibt es ins Ziel und trägt den neuen Speicherort im Datensatz der Datei ein. Beim Verschieben löscht er danach das Quellobjekt. Entschlüsselt wird dabei nichts, denn das kann der Tenant gar nicht. Fortschritt und etwaige Fehler einzelner Dateien sieht der Administrator, solange der Vorgang läuft. Eine Datei, bei der etwas schiefgeht, bleibt, wo sie war. Sie wird nicht halb verschoben.
Dieselbe Funktion arbeitet auch in die Gegenrichtung, und das ist für einen Ausstieg wichtig. Wenn Sie Sapherbox verlassen, oder auch nur unseren Bucket, liegt das Chiffrat bereits in einem Speicher, den Sie kontrollieren. Die Schlüssel dazu waren ohnehin immer auf den Geräten Ihrer Nutzer. Um Ihre Daten mitzunehmen, müssen Sie bei uns nichts anfordern. Was Sie ohne die Nutzer nicht können: das Chiffrat wieder in Dokumente verwandeln. Genau dafür haben Sie schließlich bezahlt.
Was sich für die Compliance ändert
In der Praxis drei Dinge.
Die Liste der Unterauftragsverarbeiter. Liegen die Dateien in Ihrem Bucket, ist der Anbieter des Objektspeichers Ihr Vertragspartner, nicht unserer. Für Ihren Tenant steht er deshalb nicht mehr auf unserer Liste. Unser Auftragsverarbeitungsvertrag deckt weiterhin den Tenant selbst ab, durch den das Chiffrat auf dem Weg zum Bucket und zurück läuft.
Datenresidenz, mit der richtigen Fußnote. Ihr Bucket steht dort, wo Sie ihn hinstellen, zu Bedingungen, die Sie ausgehandelt haben. Ehrlich gesagt gehört eine Fußnote dazu: Die Residenz von Chiffrat ist eine schwächere Aussage, als sie klingt, und zugleich eine stärkere als üblich. Schwächer, weil der Ort verschlüsselter Bytes für niemanden viel bedeutet, der sie nicht entschlüsseln kann. Stärker, weil die Schlüssel von Anfang an nirgendwo anders waren als auf den Geräten Ihrer Nutzer. Hosting in der EU ist ein Thema für sich. Dazu schreiben wir einen gesonderten Artikel.
Ihre Aufbewahrung, Ihre Dauerhaftigkeit. Der Bucket, den wir einrichten, hat Versionierung und einen Object Lock von 30 Tagen auf jeder Version, im sogenannten Governance-Modus von AWS. Löscht Sapherbox ein Objekt, behält der Bucket die vorherige Version 30 Tage lang, und in dieser Zeit kann keine Zugangsberechtigung sie entfernen, weder die des Tenants noch unsere im laufenden Betrieb. Nach 30 Tagen entfernt eine Lebenszyklusregel die Version, und die Löschung ist endgültig, wie im Artikel über das Löschen beschrieben. Den Zugangsdaten des Tenants sind die Aktionen, die diese Frist verkürzen würden, ausdrücklich verboten: Versionen löschen, den Lock umgehen, die Konfiguration des Buckets ändern. Nur wir können die Frist ändern, und wir tun das auf Anfrage in beide Richtungen, etwa um einem Löschverlangen früher nachzukommen oder um die Historie zu verlängern. Genau darum Governance-Modus und nicht Compliance-Modus: Der Backup-Bucket nutzt den Compliance-Modus, weil eine Sicherung nie vorzeitig löschbar sein darf, Ihr Speicher-Bucket aber muss dem Recht auf Löschung weiterhin nachkommen können. Eine Replikation in eine zweite Region richten wir auf demselben Weg ein. In Ihrem eigenen Bucket legen Sie all das selbst fest, nach Ihren eigenen Richtlinien und ohne dass der Tenant davon wissen muss. Das ist der Unterschied: nicht, was möglich ist, sondern wer die Kontrolle darüber hat.
Die Grenzen, klar benannt
- Ein Bucket pro Speicherort, eine Region pro Bucket. Sapherbox selbst repliziert nicht zwischen Regionen. Das ist eine Funktion des Buckets. Für den Bucket, den wir einrichten und der in unserem AWS-Konto liegt, richten wir die Replikation auf Wunsch für Sie ein. In Ihrem eigenen Bucket richten Sie sie selbst ein.
- Der Tenant verarbeitet weiterhin die Bytes. Uploads und Downloads laufen über die API des Tenants und nicht direkt zum Bucket. So wird jeder Zugriff an einer Stelle authentifiziert, autorisiert und protokolliert. Der Tenant sieht während der Übertragung nur Chiffrat. Er liegt aber im Datenpfad, und seine Bandbreite begrenzt den Durchsatz.
- Der Umzug läuft Datei für Datei und braucht Zeit. Bei einem großen Tenant dauert eine Migration Stunden. Währenddessen ist nichts unerreichbar, denn jede Datei wird von dem Speicherort ausgeliefert, der in ihrem Datensatz steht.
- Die Backups bleiben bei uns, das Chiffrat bleibt, wo es ist. Die tägliche Datenbanksicherung schreibt der Tenant in den separaten Backup-Bucket, der nur beschrieben werden kann, nicht in Ihren Speicherort. Sie ist für unseren Offline-Schlüssel verschlüsselt. Dateiinhalte werden nie aus dem Speicher-Bucket herauskopiert. Dort schützen Versionierung und Object Lock sie. Um einen Tenant wiederherzustellen, braucht es deshalb beide Seiten: unser Backup und unseren Schlüssel sowie den Bucket mit dem Chiffrat, unseren oder Ihren. Diese Abhängigkeit ist gewollt. Sie sollten sie kennen, bevor Sie eine Wiederherstellung brauchen.
Fragen?
Wenn Sie einen Tenant mit Ihrem eigenen Speicher betreiben möchten oder Ihr Sicherheitsteam die genaue Objektstruktur und die IAM-Policy sehen will, die der Tenant für Ihren Bucket braucht, schreiben Sie an hello@sapherbox.com.