Das Bedrohungsmodell auf einer Seite

Jede Sicherheitsaussage richtet sich gegen jemanden. Ein Produkt „sicher“ zu nennen, sagt nichts, solange offen bleibt, wogegen es sicher ist und wogegen nicht. Diese Seite sagt genau das für Sapherbox. Sie ist in zehn Minuten gelesen und lässt sich an den ausführlicheren Dokumenten überprüfen. Das Whitepaper beschreibt die Mechanismen. Hier stehen die Grenzen.

Was geschützt wird

Drei Dinge, nach Wichtigkeit geordnet: der Inhalt Ihrer Dateien, die Namen von Dateien und Ordnern und die Schlüssel, die beides öffnen. Alle drei liegen nur auf Ihren Geräten im Klartext vor. Der Server speichert Chiffrat, versiegelte Schlüssel und öffentliche Schlüssel. Eine vierte Kategorie, die Metadaten, ist schwächer geschützt. Ehrlicherweise sagen wir auch genau, um wie viel schwächer.

Angreifer, gegen die wir schützen

Unsere eigenen Server und wer immer sie kontrolliert. Auf genau diesen Angreifer ist die Architektur ausgelegt. Nehmen Sie an, der Tenant-Server, seine Datenbank, der Objektspeicher und die Backups sind vollständig in fremder Hand. Ob durch einen Einbruch, einen Innentäter beim Hosting-Anbieter, eine gerichtliche oder behördliche Anordnung oder einen unredlichen Mitarbeiter bei uns, spielt keine Rolle. Der Angreifer erhält Chiffrat, versiegelte Schlüssel, öffentliche Schlüssel und Metadaten. Auf keinem Server liegt ein Schlüssel, der irgendeine Datei öffnet. Und es gibt keinen Codepfad, in dem der Server Klartext verarbeitet. Was der Angreifer erhält, bleibt also verschlossen. Die genaue Aufteilung steht in Was unsere Server sehen können und was nicht.

Ein Server, der lügt. Ein kompromittierter Server könnte versuchen, eine Freigabe an die falsche Person zu leiten, indem er einen untergeschobenen öffentlichen Schlüssel vorlegt. Jede Freigabe wird von der Person, die sie erteilt, mit ihrem eigenen Schlüssel signiert. Außerdem wird der Schlüssel jedes Empfängers nach dem ersten Kontakt gepinnt. Ein späterer Austausch fällt deshalb durch eine sichtbare Abweichung auf, statt unbemerkt zu bleiben. Wo das an Grenzen stößt, steht unten bei den Restrisiken.

Das Netzwerk. Jede Verbindung nutzt TLS 1.3 mit zeitgemäßer Auswahl der Verschlüsselungsverfahren. Alles, was übertragen wird, ist ohnehin schon Ende-zu-Ende-verschlüsselt. Selbst eine geknackte Verbindung liefert also nur Chiffrat und Metadaten, keine Inhalte.

Andere Kunden. Jeder Kunde läuft in einem eigenen Tenant, mit eigener virtueller Maschine, eigener Datenbank, eigenem Objektspeicher-Bucket, eigenen Zugangsgeheimnissen (Secrets) und eigenem Zertifikat. Es gibt keine gemeinsame Datenbank, in der ein Fehler in der Zugriffskontrolle Datensätze eines Kunden an einen anderen weitergeben könnte.

Ehemalige Mitwirkende. Wird eine Person aus einem Ordner entfernt, erhält der Ordner neue Schlüssel. Die Dateien sind danach unter Schlüsseln versiegelt, die die entfernte Person nie hatte. Der Server kann eine Freigabe nicht rückgängig machen, weil er die Schlüssel nie hatte. Die Arbeit erledigt das Gerät der Person, die den Zugriff entzieht. Zugriff entziehen heißt, die Schlösser auszutauschen erklärt den Aufwand und die eine Lücke, die unten aufgeführt ist.

Gestohlene Zugangsdaten. Ist ein zweiter Faktor oder ein Passkey eingerichtet, genügt ein Passwort allein nicht, um das Konto auf einem neuen Gerät zu öffnen. Ein gestohlener API-Schlüssel entschlüsselt nichts ohne die privaten Schlüssel des Service-Accounts, und die hält der Server nie.

Wer die Vergangenheit umschreiben will. Das Audit-Log ist per HMAC verkettet, mit einem Schlüssel, den die Datenbank nie sieht. Die Anwendungsrolle kann keine Einträge ändern, und eine Prüfroutine berechnet die gesamte Kette auf Anforderung neu. Wie das aufgebaut ist, beschreibt Ein Audit-Protokoll, das sich nicht unbemerkt ändern lässt.

Schädliche Dokumente. Dateien werden auf dem hochladenden Gerät vor der Verschlüsselung bereinigt oder abgewiesen, denn danach könnte der Server sie nicht mehr prüfen. Inhaltsbereinigung (CDR) beschreibt, welche Formate abgedeckt sind und welche nicht.

Ein künftiger Quantencomputer. Jede Schlüsselverpackung nutzt RSA-4096 und ML-KEM-768 gemeinsam. Chiffrat, das heute mitgeschnitten wird, lässt sich später also nicht öffnen, nur weil RSA gebrochen ist. Die hybride Schlüsselverpackung ist für Leser ohne Kryptografie-Hintergrund erklärt.

Angreifer, gegen die wir nicht schützen

Wer Ihr Gerät kontrolliert. Schadsoftware, ein Keylogger, eine Browser-Erweiterung mit Zugriff auf die Seite oder eine Person vor einem entsperrten Bildschirm handeln in Ihrem Namen. Klartext existiert auf Ihrem Gerät, und zwar mit Absicht. Nichts, was bei uns läuft, kann einen Dieb, der Ihre Sitzung übernommen hat, von Ihnen unterscheiden. Automatische Sperre bei Inaktivität, begrenzte Sitzungsdauer und die Möglichkeit, Sitzungen zu beenden, verkleinern das Zeitfenster. Schließen können sie es nicht.

Wer Ihre Freigabe erhält. Wer eine Datei heruntergeladen hat, besitzt sie. Ein Entzug verhindert künftigen Zugriff, eine Kopie holt er nicht zurück.

Ein schwaches oder mehrfach verwendetes Passwort. Argon2id macht das Raten teuer, und der Server sieht das Passwort nie. Ein Passwort, das bereits in einer Sammlung erbeuteter Zugangsdaten aus Datenlecks auftaucht, bleibt trotzdem das schwächste Glied der Kette.

Der Code, den wir ausliefern. Der Web-Client ist JavaScript, das vom Tenant ausgeliefert wird. Ein böswilliger Betreiber oder ein Angreifer, der den Tenant kontrolliert, könnte einen veränderten Client ausliefern, der Schlüssel abzieht. Eine strikte Content Security Policy ohne Skripte von Drittanbietern beschränkt diesen Angriff auf unseren eigenen Ursprung. Das Vertrauen, das Sie in das von uns ausgelieferte Paket setzen, nimmt sie Ihnen nicht ab. Signierte Builds und ein Transparenzlog für Client-Versionen stehen auf der Roadmap. Bis dahin ist dies die Stelle im Modell, an der Sie uns am meisten vertrauen müssen. Die Desktop-Clients werden einmal installiert und nur aktualisiert, wenn Sie es wollen. Bei ihnen liegt das Risiko daher beim Installieren, nicht bei jedem Aufruf.

Restrisiken, offen benannt

Dies sind die Lücken, die wir kennen. Sie sind auch im Abschnitt über die Grenzen des Whitepapers dokumentiert.

Metadaten. Dateigrößen, Zeitstempel, Ordnerstruktur, wer worauf Zugriff hat, wer wann worauf zugegriffen hat, und der verblindete Suchindex. Dieser verrät, dass dasselbe Token in mehreren Dateien vorkommt und welche Dateien zu einer Suchanfrage passten. Das ist Material für Verkehrsanalysen. Der Server sieht es mit Absicht, denn er muss Zugriffsrechte durchsetzen und Anfragen beantworten.
Erster Kontakt. Schlüssel-Pinning folgt dem Prinzip „Trust on First Use“. Die allererste Freigabe an eine neue Person akzeptiert den Schlüssel, den der Server vorlegt. Ein Austausch in genau diesem Moment fällt nur auf, wenn die beiden Personen ihre Fingerabdrücke vergleichen. Jede spätere Änderung wird blockiert und angezeigt.
Ältere Versionen. Wird jemandem der Zugriff auf eine Datei entzogen, behalten frühere Versionen, die diese Person bereits heruntergeladen hat, ihren bisherigen Schlüssel. Der Schlüsselwechsel schützt, was sie noch nicht hatte.
Transport ist klassisch. Der TLS-Schlüsselaustausch auf den Tenant-Hosts ist noch nicht Post-Quanten-sicher. Wird eine mitgeschnittene TLS-Sitzung künftig geknackt, liegen die Metadaten offen. Inhalte und Schlüssel bleiben geschützt, denn sie sind Ende-zu-Ende-verschlüsselt. Der hybride Austausch folgt, sobald die TLS-Bibliothek des Servers ihn unterstützt.
Die Bereinigung bestätigt der Client. Der Server kann nicht prüfen, ob eine hochgeladene Datei wirklich bereinigt wurde, denn er kann sie nicht lesen. Ein veränderter Client könnte eine unbereinigte Datei als bereinigt markieren. Endpunktschutz auf dem Gerät, das die Datei öffnet, bleibt deshalb nötig.
Regeln liegen im Klartext. Workflow-Definitionen, Auslöser, Empfänger und Webhook-Adressen werden im Klartext gespeichert, weil der Server sie auswertet.

Wie Sie diese Seite nutzen

Wenn Sie das Produkt bewerten, ordnen Sie Ihre eigenen Bedrohungen den beiden Listen zu. Alles aus der ersten Liste deckt die Architektur ab. Das lässt sich anhand des Whitepapers prüfen und, falls Sie einen haben, an Ihrem eigenen Tenant. Alles aus der zweiten Liste decken Sie selbst ab, mit Geräteverwaltung, Identitätsrichtlinien und Schulungen, so wie bei jedem anderen Produkt auch. Über alles aus der Liste der Restrisiken sprechen wir gern, und wo es einen Punkt auf der Roadmap dazu gibt, nennen wir ihn mit.

Fragen?

Wenn Ihr Prüfer die Mechanismen hinter einer Zeile dieser Seite sehen möchte oder eine Bedrohung vermisst, schreiben Sie an hello@sapherbox.com.