Sapherbox logoSapherboxBlog
Alle Artikel

Workflows für verschlüsselte Daten: Was Automatisierung kann, wenn der Server blind ist

Alarme, Aufbewahrung, Webhooks und geplante Berechnungen für Dateien, die der Server nicht lesen kann: was ein Workflow sieht, was wo läuft und welche zwei Aktionen Ihr Gerät brauchen.

Auch verfügbar auf English

Automatisierung und Ende-zu-Ende-Verschlüsselung wirken wie ein Widerspruch. Automatisierung ist auf dem Server zu Hause. Dort läuft sie auch um drei Uhr nachts, wenn längst kein Laptop mehr aufgeklappt ist. Ende-zu-Ende-Verschlüsselung gibt es, damit der Server nichts lesen kann. Ein Produkt, das beides verspricht, muss genau sagen, worauf seine Automatisierung zugreifen kann. Die ehrliche Antwort lautet: auf alles, was der Server weiß, und auf nichts darüber hinaus.

Damit lässt sich erstaunlich viel anfangen. Der Server weiß, wann eine Datei angekommen ist, wer sie hochgeladen hat, in welchem Ordner sie liegt, welche Labels der Browser ihr zugewiesen hat und wann sie geteilt, heruntergeladen oder gelöscht wurde. Er kennt weder ihren Namen noch ihren Inhalt. Workflows in Sapherbox arbeiten ausschließlich mit diesen Angaben. Dieser Artikel zeigt, worauf sie reagieren, was sie tun können, was nicht, und wie wir die einzige Art von Aktion umsetzen, die Ihre Schlüssel braucht, ohne dem Server einen Schlüssel zu überlassen.

Eine Regel in drei Teilen

Ein Workflow besteht aus einem Auslöser, einem optionalen Filter und einer oder mehreren Aktionen. Sie bauen ihn auf der Seite „Workflows“ oder starten mit einer der zwölf Vorlagen und passen sie an.

Der Auslöser ist eines von sieben Ereignissen: Eine Datei wurde hochgeladen, heruntergeladen, geteilt, gelöscht oder klassifiziert, oder ein Ordner wurde angelegt oder geteilt. Der Filter grenzt den Auslöser auf einen bestimmten Ordner ein, beim Ereignis „klassifiziert“ zusätzlich auf bestimmte Labels: personenbezogene Daten, Gesundheitsdaten, Finanzdaten, Zugangsdaten. Ein Workflow gehört der Person, die ihn angelegt hat, und reagiert auf Ereignisse in ihren eigenen Dateien und Ordnern. Niemand außer Ihnen kann eine Regel an Ihre Uploads hängen.

In den Aktionen steckt die eigentliche Arbeit der Regel. Sie lassen sich in drei Gruppen einteilen: Aktionen, die jemanden informieren, Aktionen, die den Status der Datei ändern, und Aktionen, die eine Berechnung anstoßen. Jede Gruppe geht anders mit der Blindheit des Servers um.

Die Seite Workflows mit drei gespeicherten Regeln (Webhook on Upload, Upload Digest und GDPR 90-Day Retention), jeweils mit Auslöser, Filter und Aktionen als Badges und einem Ein-Aus-Schalter

Jemanden informieren

Eine E-Mail-Benachrichtigung geht an eine feste Liste von Adressen, an den Owner des Ordners, an seine Co-owner oder an eine beliebige Kombination daraus. Betreff und Text sind Vorlagen mit Platzhaltern: der maskierte Dateiname, das Ereignis, Name und Adresse der handelnden Person, die gefundenen Labels, ein Link zum Ordner, das Datum. Der Server füllt sie aus dem, was er hat. Eine Meldung kann also sagen: „Eine als Zugangsdaten klassifizierte Datei wurde von j.berger@… in den Ordner Finanzen hochgeladen.“ Welche Datei das ist, kann sie nicht beim Namen nennen, denn der Name ist versiegelt. Die maskierte Form, erstes und letztes Zeichen mit Sternen dazwischen, ist dieselbe, die auch das Audit-Log zeigt.

Benachrichtigungen lassen sich bündeln. Im Digest-Modus sammelt ein Zeitfenster Ereignisse und verschickt eine einzige Nachricht mit allen. Statt vierzehn einzelner E-Mails steht dann eine Nachricht im Postfach: „Heute Nachmittag sind vierzehn Dateien im geteilten Ordner angekommen.“

Ein Webhook schickt dieselben Felder als JSON an eine URL Ihrer Wahl, signiert per HMAC über den Request-Body, berechnet mit einem Geheimnis, das Sie festlegen. Das empfangende System kann so prüfen, dass der Aufruf aus Ihrem Tenant kam und unterwegs nicht verändert wurde. Das ist die Schnittstelle für Ticketsysteme, Chat-Kanäle und alles andere, das auf Ereignisse reagiert. Der Empfänger erhält Kennungen, Labels und maskierte Namen, nie Dateiinhalte.

Ein Audit-Eintrag mit eigener Nachricht schreibt eine Zeile in das manipulationssichere Audit-Log, unter dem Akteur „workflow: Name“ und mit einem Text, den Sie als Vorlage vorgeben. So wird eine Richtlinienentscheidung automatisch protokolliert: „vom Lockdown-Workflow als Zugangsdaten markiert“, direkt neben dem Upload, auf den sie sich bezieht. Wer das Log später prüft, etwa bei einem Audit, sieht nicht nur, was passiert ist, sondern auch, welche Regel reagiert hat.

Den Status der Datei ändern

Die geplante Löschung versieht die Datei mit einem Löschdatum, das eine wählbare Anzahl von Tagen in der Zukunft liegt. An diesem Tag wandert sie in den Papierkorb und wird nach Ablauf der Papierkorbfrist endgültig entfernt. So arbeiten die Aufbewahrungsvorlagen: Alles, was in einem bestimmten Ordner als personenbezogene Daten klassifiziert wurde, wird neunzig Tage nach Eingang zur Löschung vorgemerkt, mit einem Audit-Vermerk dazu. Den Ablauf einer Löschung haben wir separat beschrieben. Der Workflow setzt nur das Datum. Alles Weitere läuft wie bei jeder anderen gelöschten Datei.

„Alle Freigaben entziehen“ entfernt jede Freigabe der Datei außer der des Owners. Das ist der Eindämmungsschritt in der Vorlage für Zugangsdaten: Eine Datei, die sich als Passwort oder API-Schlüssel entpuppt, wird in dem Moment, in dem sie erkannt wird, mit niemandem mehr geteilt. Eine Einschränkung müssen wir hier offen nennen. Freigaben entfernen kann der Server allein. Hat ein Empfänger den Dateischlüssel aber bereits zwischengespeichert, hilft nur ein Schlüsselwechsel. Den kann nur Ihr Gerät durchführen, denn der Server besitzt keine Schlüssel, mit denen er das tun könnte. Der Workflow kappt den Zugriff am Server also sofort, und beim nächsten Öffnen der Mitgliederliste der Datei schließen Sie den Entzug mit einem Schlüsselwechsel ab. Warum sich die beiden Schritte unterscheiden, haben wir an anderer Stelle erklärt.

Der Workflow-Builder mit der Vorlage Credentials Lockdown: Auslöser File classified, Klassifizierungsfilter Credentials / Secrets und drei Aktionen (Revoke All Shares, Create Audit Entry mit einer Nachrichtenvorlage und Email Notification an die Sicherheitsadresse und den Ordner-Owner)

„Automatisch verschieben“ und „In Ordner kopieren“ legen die Datei an anderer Stelle ab. Hier zeigt sich die Blindheit des Servers am deutlichsten. Bei einer Datei in einem geteilten Ordner ist der Dateischlüssel für das Schlüsselpaar dieses Ordners versiegelt. Wer sie woanders ablegt, muss den Schlüssel für den Zielordner neu versiegeln, und das kann nur Ihr Browser. Diese beiden Aktionen funktionieren deshalb nur bei Dateien, deren Schlüssel der Server für Sie versiegelt vorhält. In der Praxis sind das Uploads auf die oberste Ebene Ihres eigenen Bereichs, das Eingangskorb-Muster: Dateien kommen oben an, eine Regel verschiebt sie in die Ordner „Finanzen“ oder „Verträge“ oder legt eine Kopie im Archivordner ab. Die verschobene oder kopierte Datei bleibt dabei allein für Sie versiegelt. Sie können sie öffnen, die Mitglieder des Zielordners noch nicht. Erst wenn Sie die Datei einmal im Browser verschieben oder teilen, wird sie auch für die Mitglieder versiegelt. Liegt die Datei bereits in einem geteilten Ordner, tut die Aktion nichts. Das ist besser, als eine Datei zu hinterlassen, die niemand öffnen kann. Das Serverprotokoll hält die Ablehnung fest.

Eine Berechnung anstoßen

Bei der dritten Gruppe wird es konzeptionell interessant. Ein Workflow kann einen Compute-Job oder eine Katalogabfrage in die Warteschlange stellen. Beide brauchen Dateiinhalte, und die hat der Server nicht.

Die Lösung: Der Server reiht die Ausführung ein, Ihr Browser führt sie aus. Wenn die Regel auslöst, legt der Server eine ausstehende Ausführung an und schickt eine Nachricht an Ihre Sitzung. Auf der Seite „Workflows“ erscheint ein Zähler. Dort sehen Sie die ausstehende Ausführung mit dem zugehörigen Job und bestätigen sie. Von da an passiert die Arbeit auf Ihrem Gerät: Die Dateien werden als Chiffrat heruntergeladen, mit Ihren Schlüsseln entschlüsselt, verarbeitet, und das Ergebnis wird verschlüsselt als neue Datei in den Ausgabeordner hochgeladen, den Sie festgelegt haben. Der Server sieht einen Job starten, einen Job enden und ein neues verschlüsseltes Objekt. Für jedes davon schreibt er einen Audit-Eintrag. Keine einzige Zeile der Daten bekommt er zu sehen.

Geplante Berechnungen laufen in Sapherbox also nicht unbeaufsichtigt wie ein Cron-Job. Sie braucht einen Browser mit Ihrer offenen Sitzung, und sie fragt, bevor sie läuft. Wir haben das der Alternative vorgezogen, die eine Kopie Ihrer Schlüssel auf dem Server bedeuten würde, damit ein Job laufen kann, während Sie schlafen. Diese Bestätigung ist zugleich eine Sicherheitseigenschaft: Ein Workflow kann nicht stillschweigend abgeleitete Dokumente aus Ihren Daten erzeugen. Jede Ausführung ist eine Entscheidung, die Sie sehen.

Was der Server von einem Workflow sieht

Die Regel selbst wird im Klartext gespeichert. Auslöser, Filter, Aktionen, E-Mail-Adressen, Webhook-URL und die Nachrichtenvorlagen sind für den Server und für Ihre Administratoren lesbar, denn der Server muss sie auswerten. Darauf weisen wir auch in der Liste dessen, was unsere Server sehen können, hin, und es lohnt sich, es hier zu wiederholen: Schreiben Sie nichts in einen Workflow-Namen oder eine E-Mail-Vorlage, was Sie nicht auch in ein Support-Ticket schreiben würden. Die Compute-Jobs, auf die ein Workflow verweist, sind anders. Deren Namen und Operationslisten sind verschlüsselt. Der Server speichert nur die Kennung und die beteiligten Ordner.

Eines kann ein Workflow nie: dem Server etwas verraten, das er nicht ohnehin schon weiß. Eine Regel reagiert auf Metadaten, die der Server bereits hat. Was sie erzeugt, sind E-Mails und Webhooks aus diesen Metadaten, Markierungen an Datensätzen, die er ohnehin hat, und eingereihte Ausführungen, die Ihr Gerät übernimmt. Es gibt keine Aktion, die auf dem Server irgendetwas entschlüsselt, weil es auf dem Server keinen Schlüssel gibt, mit dem das ginge.

Zwölf Ausgangspunkte

Die Vorlagengalerie deckt die Regeln ab, die die meisten Tenants am ersten Tag haben wollen. Vier davon sind Sicherheitsregeln: Alarm bei sensiblen Dateien, Alarm bei Zugangsdaten, Lockdown bei Zugangsdaten mit Entzug aller Freigaben und Audit-Vermerk sowie ein DSGVO-Alarm. Drei sind Compliance-Regeln: ein Alarm bei Gesundheitsdaten, neunzig Tage Aufbewahrung für personenbezogene Daten und eine Upload-Zusammenfassung. Drei benachrichtigen bei Löschung, Ordnerfreigabe und Uploads. Zwei automatisieren die Ablage: Finanzdateien in einen Ordner sortieren und von jedem Upload eine Archivkopie anlegen. Nach der Auswahl ist jede Vorlage ein normaler Workflow. Adressen, Ordner und Zeitfenster passen Sie nach Bedarf an.

Die Galerie Workflow Templates: die Sicherheitsvorlagen Sensitive File Alert, Credentials Detected und Credentials Lockdown, die Compliance-Vorlagen GDPR Data Alert, Health Data Alert und GDPR 90-Day Retention sowie die Benachrichtigungsvorlagen Upload Digest und File Deletion Alert, jeweils mit einer Schaltfläche Use

Fragen?

Wenn Sie einen Aufbewahrungsplan oder eine Alarmrichtlinie auf diese Regeln abbilden möchten, die Webhook-Nutzlast und das Signaturverfahren schriftlich für eine Integration brauchen oder wissen wollen, was eine bestimmte Aktion in Ihrer Ordnerstruktur kann und was nicht, schreiben Sie uns an hello@sapherbox.com.