Was unsere Server sehen können und was nicht

Jeder verschlüsselte Dienst erklärt, was er nicht lesen kann. Kaum einer erklärt, was er lesen kann. Gerade diese zweite Liste braucht aber, wer die Sicherheit eines Dienstes prüft. Und genau sie fehlt meistens. Sie ist nämlich länger, als man erwartet, und weniger schmeichelhaft als „Zero Knowledge“.

Dieser Artikel liefert diese zweite Liste, vollständig und mit einer Begründung für jeden Eintrag. Wenn Sie nur einen Abschnitt lesen, dann „Kann sehen“. Der Rest erklärt, warum.

Warum ein Server überhaupt etwas sieht

Eine Dokumentenplattform muss auf dem Server arbeiten. Sie speichert Objekte und setzt durch, wer welches abrufen darf. Sie zeigt einen Ordnerbaum schnell an und erstellt Berichte, mit denen ein Administrator arbeiten kann. Sie verschickt Benachrichtigungen und führt ein Audit-Protokoll. Für jede dieser Aufgaben braucht der Server Informationen in einer Form, mit der er etwas anfangen kann. Die Frage beim Entwurf lautet also nicht, ob der Server Metadaten sieht. Sie lautet, welche Metadaten er sieht, ob jede einzelne Angabe nötig ist und ob das dokumentiert ist.

Bei Sapherbox gilt eine einfache Regel. Inhalte und Namen werden auf Ihrem Gerät verschlüsselt. Von Inhalten und Namen bekommt der Server nur Chiffrat und versiegelte Schlüssel. Was der Server für den Betrieb der Plattform braucht, liegt im Klartext vor, und nichts darüber hinaus. Die folgende Aufstellung nennt genau diese Dinge, und zwar alle.

Kann sehen

Zu Dateien und Ordnern

• Dateigrößen in Bytes und die Zahl der Blöcke, in denen eine Datei hochgeladen wurde.
• Zeitstempel für Anlegen, Ändern, Hochladen, Löschen und den letzten Zugriff.
• Die Zahl der Versionen und die Zeitpunkte der Versionshistorie.
• Die Ordnerstruktur. Der Server weiß, welcher Ordner in welchem liegt, wie viele Elemente jeder enthält und wie Ihr Baum aufgebaut ist. Ordnernamen sind verschlüsselt, die Hierarchie ist es nicht.
• Maskierte Namen im Audit-Log. Wird eine Datei oder ein Ordner angelegt oder umbenannt, speichert der Audit-Eintrag eine maskierte Form des Namens. Sie besteht aus dem ersten und dem letzten Zeichen plus Dateiendung, etwa „V****g.pdf“. Das reicht, damit ein Administrator einen Eintrag im Log wiedererkennt. Den Namen lesen kann er daraus nicht.
• Klassifizierungslabels, sofern die Klassifizierung aktiviert ist. Gemeint sind die Kategorien, mit denen eine Datei markiert wurde, etwa personenbezogene Daten oder Finanzdaten. Den Inhalt, in dem diese Kategorien erkannt wurden, sieht der Server nie.
• Den Vertrauensstatus aus der Inhaltsbereinigung, also ob eine Datei bereinigt wurde, noch aussteht oder ausgenommen ist.

Zu Personen und Zugriff

• Die Kontoidentität. Dazu gehören E-Mail-Adressen sowie Verzeichnisname und Organisation, die ein Administrator für jede Person pflegt. Dazu gehören außerdem Rolle, Kontotyp und Anmeldeverfahren, das Anlagedatum des Kontos und seine letzte Nutzung. Die E-Mail-Adresse dient als Anmeldekennung und als Zustelladresse für Einladungen und Warnungen. Rolle und Kontotyp braucht der Server, um Berechtigungen durchzusetzen. Verzeichnisname und Organisation sind lesbar, weil der Server sie selbst einsetzt, nämlich in Ordnerlisten, in Listen der Personen mit Zugriff, in Audit-Einträgen und in den E-Mails, die er verschickt. Anders die Profilfelder, die Nutzer selbst pflegen, also Firma, Telefonnummer und Postanschrift. Sie sind mit einem eigenen Schlüssel pro Nutzer verschlüsselt und gehören nicht in diese Liste.
• Öffentliche Schlüssel und Signaturen aller Nutzer, Gruppen und Ordner. Sie sind ihrem Wesen nach öffentlich.
• Den Zugriffsgraphen. Der Server weiß, welcher Nutzer und welche Gruppe eine Freigabe für welche Datei oder welchen Ordner hat. Er kennt die Berechtigungsstufe und weiß, wer die Freigabe wann erteilt hat. Die versiegelten Schlüssel in einer Freigabe kann er nicht öffnen. Dass es die Freigabe gibt, sieht er aber.
• Gruppenmitgliedschaften und wer welche Gruppe leitet.
• Sitzungen und Geräte, also aktive Sitzungen, ihren Startzeitpunkt, den Client-Typ und registrierte Passkeys.

Zur Aktivität

• Jedes Audit-Ereignis. Der Server weiß, wer sich wann angemeldet hat. Er weiß, wer wann etwas hochgeladen, heruntergeladen, in der Vorschau geöffnet, geteilt, umbenannt, verschoben oder gelöscht, eine Einstellung geändert oder einen Bericht erstellt hat. Das Audit-Protokoll ist der Nachweis der Plattform, und Nachweise müssen lesbar sein. Es zeigt Zugriffsmuster, also wer woran arbeitet, mit wem und wie oft.
• Client-IP-Adressen, aber nur, wenn der Administrator die IP-Protokollierung eingeschaltet und die Person zugestimmt hat. Bei anonymen Ereignissen wird nie eine IP-Adresse gespeichert.
• Suchaktivität in verblindeter Form. Der Server sieht, welche Tokens abgefragt wurden und welche Dateien dazu passten. Die Wörter hinter den Tokens kennt er nicht. Er weiß aber, dass gesucht wurde und was dabei herauskam.

Zur Suche

• Den verblindeten Suchindex. Er enthält für jede indexierte Datei die Tokens, die mit dem Suchschlüssel des Nutzers aus Name und Inhalt abgeleitet wurden. Der Server kann ein Token nicht in ein Wort zurückverwandeln. Er sieht aber, wie viele verschiedene Tokens eine Datei hat, welche Dateien ein Token gemeinsam haben und wie oft ein Token vorkommt. Was sich daraus schließen lässt, beschreibt der Artikel über Blind-Indizes.

Zur Automatisierung

• Workflow-Definitionen, also Auslöser, Bedingungen und Aktionen. Dazu gehören die E-Mail-Adressen und Webhook-URLs, die Sie eingetragen haben, und gegebenenfalls ein Klassifizierungsfilter.
• Einstellungen von Compute-Jobs. Der Server sieht, welchen Ordner ein Job liest, wohin er Ergebnisse schreibt, welcher Filter für Dateiformate gilt und wann der Job zuletzt lief. Der Name des Jobs, die Liste der Operationen und die Vorlage für den Namen der Ausgabedatei sind verschlüsselt, denn eine Operation kann eine Tabellenspalte beim Namen nennen. Ergebnisse werden beim Speichern verschlüsselt.
• Einstellungen öffentlicher Links, also Ablaufdatum, Download-Limits und ob ein Passwort gesetzt ist. Der Link-Schlüssel selbst steht nur im Fragment der URL und erreicht den Server nie.

Optional und standardmäßig ausgeschaltet

• Datei- und Ordnernamen im Klartext für Berichte der Administratoren. Ein Tenant-Administrator kann dafür eine Einstellung einschalten. Der Server speichert dann beim Anlegen, Umbenennen und Hochladen den vollständigen Namen jeder Datei und jedes Ordners. Zugriffsübersichten und Audit-Exporte zeigen so echte statt maskierter Namen. Die Einstellung sagt unmissverständlich, dass so gespeicherte Namen für den Server und für Administratoren lesbar sind. Wird sie ausgeschaltet, löscht der Server alle gespeicherten Namen. Inhalte bleiben in jedem Fall verschlüsselt.

Kann nicht sehen

• Den Inhalt von Dateien, einschließlich der Notizen, die Sie in Sapherbox schreiben.
• Die Namen von Dateien und Ordnern, außer im oben beschriebenen optionalen Berichtsmodus.
• Dateitypen. Der MIME-Typ liegt neben dem Namen und ist wie dieser unter dem Dateischlüssel versiegelt. Ob eine Datei ein PDF oder eine Tabelle ist, kann der Server deshalb nur anhand der Größe raten. Dateien von älteren Clients können den Typ noch im Klartext enthalten, bis sie erneut hochgeladen werden.
• Vorschauen, Miniaturansichten und extrahierten Text. All das entsteht auf Ihrem Gerät und wird nie gespeichert.
• Suchbegriffe und die Wörter hinter einem Token.
• Tag-Namen. Ein Tag wird als schlüsselabhängiger Hash und als verschlüsseltes Label gespeichert.
• Passwörter, Wiederherstellungscodes und Passphrasen für den Escrow-Schlüssel.
• Das Profil, das Nutzer selbst ausfüllen, also Firma, Telefonnummer und Anschrift. Lesbar sind nur Verzeichnisname und Organisation, die der Administrator pflegt, wie oben beschrieben.
• Den Account Master Key, private Identitätsschlüssel, private Ordner- und Gruppenschlüssel und Dateischlüssel. Jeder davon erreicht den Server nur versiegelt, und zwar mit einem Schlüssel, den der Server nicht hat.
• Namen und Operationslisten von Compute-Jobs sowie SQL-Abfragen, die im Katalog gespeichert sind. Beides ist mit einem Schlüssel versiegelt, den nur die Personen bekommen, mit denen der Job oder der Katalog geteilt ist.
• Den Inhalt öffentlicher Uploads und Downloads. Er wird auf dem Gerät des Absenders verschlüsselt und auf dem des Empfängers entschlüsselt.

Was der Server ableiten könnte

Ehrlich gesagt gehört auch der nächste Schritt dazu. Metadaten sind nicht bedeutungslos. Ein Server mit den oben genannten Daten kann daraus Schlüsse ziehen, und ebenso ein Angreifer, der sie erbeutet.

• Aus Größen und Zeitstempeln: ungefähr, wie aktiv ein Ordner ist und zu welchen Zeiten.
• Aus Zugriffsgraph und Audit-Protokoll: wer mit wem zusammenarbeitet, welche Ordner für welche Teams wichtig sind und wann die Aktivität einer Person aufhört.
• Aus maskierten Namen: die Endung und zwei Zeichen jedes Dateinamens. Bei kurzen Namen ist das der größte Teil des Namens.
• Aus dem Suchindex: dass ein Begriff in vielen Dateien vorkommt und welche Dateien eine bestimmte Suche geliefert hat, also wofür sich jemand interessiert hat.
• Aus Klassifizierungslabels: dass ein Ordner Gesundheits- oder Finanzdaten enthält, sofern diese Kategorien eingeschaltet sind.

Nichts davon legt Inhalte offen. Zusammen ist es aber mehr, als „Zero Knowledge“ nahelegt. Deshalb verwenden wir diesen Begriff nicht. Um genau diesen Unterschied ging es auch in „Zero Knowledge“ ist eine Frage der Architektur, nicht der Richtlinie. Der Sicherheitsüberblick enthält die Kurzfassung dieser Liste, dieser Artikel ist die Langfassung. Das Whitepaper für Sicherheitsteams führt dieselben Punkte unter einer nummerierten „bekannten Einschränkung“ auf.

Was Sie tun können, wo es für Sie zählt

• Schalten Sie keine Klassifizierungskategorien ein, die schon für sich genommen etwas verraten würden. Oder verwenden Sie eigene Muster mit neutralen Namen wie „öffentlich“, „nur intern“, „vertraulich“ und „geheim“. Dann sieht der Server eine Vertraulichkeitsstufe, aber nicht, um welche Art von Daten es geht.
• Lassen Sie die IP-Protokollierung ausgeschaltet, solange Sie sie nicht für eine bestimmte Sicherheitsmaßnahme brauchen.
• Lassen Sie Klartextnamen für Berichte ausgeschaltet, solange Ihre Administratoren in Übersichten keine echten Namen brauchen. Machen Sie sich klar, was Sie mit dem Einschalten aufgeben.
• Wählen Sie Datei- und Ordnernamen mit Blick auf die Maskierung, falls erstes und letztes Zeichen in einem Audit-Export zu viel verraten würden.
• Behandeln Sie das Audit-Protokoll als das, was es ist, nämlich eine sensible Aufzeichnung. Nichts auf dem Server ist aussagekräftiger, und wie lange das Protokoll aufbewahrt wird, legen Sie fest.
• Muss sogar vor dem Betreiber verborgen bleiben, wer in Ihrer Organisation arbeitet, lautet die ehrliche Antwort Self-Hosting. Betreiber sind dann Sie selbst. Kein noch so sorgfältiger Umgang mit Metadaten ändert etwas daran, dass ein Server seine Nutzer kennen muss.

Fragen?

Ihr Sicherheitsteam möchte diese Liste Feld für Feld dem Datenbankschema zugeordnet sehen? Oder Sie möchten besprechen, welche Punkte für Ihr Bedrohungsmodell zählen? Schreiben Sie uns an hello@sapherbox.com.