Make.com und Zapier: Automatisierungen, die Ihre Dateien nie sehen
Integrationsplattformen sind Klebstoff, und Klebstoff darf meist alles lesen. Bei Sapherbox bekommt er Ereignisse, Kennungen und maskierte Namen, nie Inhalte.
Make.com, Zapier und ihre Verwandten sind der Weg, auf dem die meisten Organisationen Werkzeuge verbinden, ohne Code zu schreiben. Eine Datei landet hier, dort öffnet sich ein Ticket, in einer Tabelle erscheint eine Zeile. Bei einem gewöhnlichen Cloud-Laufwerk bekommt der Connector, was das Laufwerk hat, also alles: Er lädt die Datei herunter, liest den Namen und reicht den Inhalt an das weiter, was als Nächstes in der Kette kommt. Das ist bequem. Es bedeutet aber auch, dass die Integrationsplattform, und jeder Schritt danach, jetzt ein Ort ist, an dem Ihre Dokumente im Klartext liegen.
Sapherbox kann so nicht arbeiten, denn der Server selbst hat Ihre Dateien nie im Klartext. Die Frage, die dann kommt, ist berechtigt: Was bleibt für eine Automatisierung noch zu tun? Mehr, als man erwarten würde. Dieser Artikel geht die zwei Richtungen durch, die eine Integration nehmen kann, was jede davon transportiert, und drei Automatisierungen, die wir auf diese Weise gebaut haben.
Zwei Richtungen
Eine Integration reagiert entweder auf etwas, das in Ihrem Tenant passiert ist, oder sie tut etwas mit ihm.
Reagieren ist die Aufgabe von Workflow-Webhooks. Eine Regel in Ihrem Tenant löst bei einem Ereignis aus und sendet eine signierte JSON-Nachricht an eine URL Ihrer Wahl. Make und Zapier starten Szenarien beide über einen eingehenden Webhook, also ist das der natürliche Einstieg.
Etwas tun ist die Aufgabe eines Service-Accounts mit API-Schlüssel. Das Konto ist ein eigenständiger Akteur mit eigenen Schlüsseln, und der API-Schlüssel kann genau die Verben, die Sie aufgelistet haben. Das Modell haben wir in Service-Accounts mit eng begrenzten Rechten beschrieben.
Die Grenze zwischen beiden verläuft dort, wo der Inhalt liegt. Webhooks transportieren, was der Server weiß, und das ist nie der Inhalt. Die API lässt einen Aufrufer lesen und ändern, was der Server hält, also Chiffrat und Metadaten. Nur ein Aufrufer, der die privaten Schlüssel des Kontos hält, kann aus Chiffrat ein Dokument machen. Ein Schritt in Make oder Zapier hält diese Schlüssel nie.
Was ein Webhook transportiert
Ein Workflow ist ein Auslöser, ein Filter und eine Liste von Aktionen. Die Mechanik steht in Workflows für verschlüsselte Daten. Ist eine der Aktionen ein Webhook, sendet der Server einen JSON-Body mit den Feldern, die er für das Ereignis hat:
- das Ereignis, etwa eine hochgeladene Datei oder ein Klassifizierungsergebnis
- die Kennungen von Datei und Ordner
- den Dateinamen in maskierter Form, erster und letzter Buchstabe, die Mitte mit Sternen
- wer gehandelt hat, als Adresse und Anzeigename
- die gefundenen Klassifizierungs-Labels, falls der Auslöser eine Klassifizierung war
- das Datum, einen Link zum Ordner in der Web-App und den Namen des ausgelösten Workflows
Zwei Dinge fehlen absichtlich. Der Inhalt fehlt, weil der Server ihn nie hatte. Der vollständige Dateiname fehlt, weil Namen auf dem Gerät versiegelt werden, das sie hochgeladen hat. Das ist der Grund, warum wir auch Datei- und Ordnernamen verschlüsseln. Die maskierte Form reicht, um eine Datei wiederzuerkennen, die man kennt, und reicht nicht, um eine zu erfahren, die man nicht kennt.
Jede Anfrage ist signiert. Sie hinterlegen ein Geheimnis an der Webhook-Aktion, und der Server sendet einen HMAC-SHA-256 über den exakten Body im Header X-Sapherbox-Signature, als sha256= gefolgt vom Hex-Digest. Ihr empfangender Schritt berechnet ihn mit demselben Geheimnis nach und verwirft alles, was nicht übereinstimmt. Eine Nachricht lässt sich so unterwegs weder fälschen noch verändern. Make berechnet den Digest mit der eingebauten Funktion sha256, wenn man ihr den Schlüssel gibt; in Zapier sind es ein paar Zeilen in einem Code-Schritt. Der Server wartet zehn Sekunden auf eine Antwort und wiederholt den Versand nicht. Richten Sie den Webhook also auf die Sofort-Empfangs-URL der Plattform und nicht auf einen langsamen eigenen Endpunkt.
Beispiel 1: Ein neuer Vertrag öffnet ein Ticket
Eine Kanzlei bewahrt unterschriebene Verträge in einem Ordner pro Mandant auf. Das Backoffice soll jedes neue Dokument sehen, ohne den Vault zu öffnen.
- Workflow-Auslöser: Datei hochgeladen, gefiltert auf den Teilbaum „Verträge“.
- Aktion: Webhook an ein Make-Szenario.
- Make: Signatur prüfen, dann ein Ticket im Helpdesk anlegen, mit Ordner-Link, maskiertem Namen, Namen des Hochladenden und Datum in der Beschreibung.
Das Ticket sagt „R****f.pdf hochgeladen in Mandanten / Nordwind GmbH von a.lindqvist“, und die Sachbearbeiterin, die die Datei sehen muss, klickt auf den Ordner-Link und öffnet sie in der Web-App mit ihren eigenen Schlüsseln. Der Helpdesk hat den Vertrag nie gespeichert, Make auch nicht. Genau dieser Satz gehört für beide Werkzeuge ins Verzeichnis der Verarbeitungstätigkeiten: Sie verarbeiten Kennungen und maskierte Namen.
Beispiel 2: Ein Upload-Link speist das Fallsystem
Ein Versicherungsmakler sammelt Schadensunterlagen von Kunden, die kein Konto haben. Jeder offene Schadensfall hat einen eigenen Eingangsordner und einen Upload-Link für diesen Ordner, der dem Kunden einmal geschickt wird. Der Makler möchte, dass der Schadensdatensatz im CRM in dem Moment aktualisiert wird, in dem etwas eintrifft, ohne dass jemand den Vault beobachtet.
- Workflow-Auslöser: Datei hochgeladen, gefiltert auf den Teilbaum „Schadenseingang“.
- Aktion: Webhook an ein Make-Szenario.
- Make: Signatur prüfen, den Schadensfall anhand der Ordnerkennung nachschlagen, eine Notiz „Dokument eingegangen, R****t.pdf, 14:02“ mit Ordner-Link anhängen und den Fall auf „Unterlagen eingegangen“ setzen, falls er darauf gewartet hat.
Die Nutzlast trägt die Ordnerkennung, also den Schadensfall, und nennt den Akteur als anonym. Das sagt dem Szenario, dass die Datei über den Link kam und nicht von einem Kollegen. Sie trägt nicht den Namen des Kunden, nicht den vollständigen Dateinamen und kein Byte des Inhalts. Das CRM erfährt also, dass für Schadensfall 4471 ein Dokument eingegangen ist, und nichts darüber, was darin steht. Der Sachbearbeiter öffnet den Ordner in der Web-App, wenn er es lesen will. Wird der Link einmal missbraucht, sorgt der Ordnerfilter dafür, dass der Lärm in einem einzigen Fall landet, und das Widerrufen dieses Links beendet ihn.
Beispiel 3: Monatszahlen in eine Tabelle
Compute-Jobs aggregieren Zahlen aus verschlüsselten Tabellen und Formularen im Browser. Die Aggregate existieren also auf dem Gerät der Person, die den Job ausgeführt hat. Ein Job kann einen Ausgabe-Webhook bekommen. Ist der Lauf beendet, sendet der Browser die Ergebnisse, die Operation und die aggregierten Werte mit den Kennungen der Dateien, aus denen sie stammen, an diese URL. Ein Make-Szenario hängt sie an ein Google Sheet oder ein anderes Zielsystem an.
Das ist die eine Stelle, an der aus Inhalten abgeleitete Daten das System verlassen. Sie tun es vom Gerät des Nutzers aus, wenn der Nutzer den Job ausführt, und zwar mit genau den Zahlen, die die Abfrage ergeben hat. Der Server sieht die Zahlen nicht und könnte sie nicht senden. Gäbe die Abfrage jede Zeile der Tabelle zurück, würde jede Zeile reisen. Die Kontrolle ist die Abfrage, und das Audit-Protokoll hält fest, dass der Job gelaufen ist.
Von außen etwas tun
Die eingehende Richtung ist enger, und die Grenzen folgen direkt aus der Verschlüsselung.
Was ein API-Schlüssel ganz ohne Schlüsselmaterial kann: die Ordner und Dateien auflisten, die mit seinem Konto geteilt wurden, als Kennungen, Größen und versiegelte Namen, die er nicht lesen kann; Nutzer und deren öffentliche Schlüssel nachschlagen; Einladungen anlegen, erneut senden und löschen; und Dateien oder Ordner löschen, für die ihm dieses Recht erteilt wurde. Ein Zapier-Zap, der einen neuen Mitarbeitenden einlädt, sobald die Personalabteilung ihn im Verzeichnis anlegt, kommt also allein mit dem Recht zum Einladen aus, und ein Offboarding-Zap kann die offenen Einladungen eines Kontos auflisten und entfernen.
Was die privaten Schlüssel des Kontos braucht: eine Datei lesen, eine hochladen, eine umbenennen, einen Ordner anlegen, einen teilen. Jede dieser Aktionen verschlüsselt, entschlüsselt oder versiegelt einen Schlüssel auf dem Client, und der Client muss etwas sein, das den PKCS#8-Schlüssel und den Post-Quanten-Seed hält, die beim Anlegen des Kontos einmal angezeigt wurden. Ein Schritt in Make oder Zapier kann dieser Client nicht sein, und wir haben keinen Connector gebaut, der ihn dazu machen würde. Denn das hieße, einer fremden Plattform eine Kopie der Schlüssel zu geben. Für Automatisierungen, die Inhalte bewegen müssen, ist das Muster ein kleiner eigener Dienst oder der Desktop-Sync-Client auf einer Maschine unter Ihrer Kontrolle, der Dateien in einen synchronisierten Ordner legt, den die Plattform nur anstößt.
Jedes Recht ist ausdrücklich, und ein neuer Schlüssel hat keines. Eine Integration, die nur Nutzer einlädt, kann keine einzige Datei auflisten. Jeder Aufruf wird im Audit-Protokoll dem Service-Account zugerechnet. Das macht die Aktivität einer Maschine neben der eines Menschen prüfbar.
Was die Plattformen sehen, und was ins Verzeichnis gehört
Für den Auftragsverarbeitungsvertrag gilt: Die beiden Plattformen verarbeiten Folgendes und nicht mehr: Ereignisnamen, Datei- und Ordnerkennungen, maskierte Dateinamen, Adressen und Anzeigenamen von Nutzern, Klassifizierungs-Labels, Zeitstempel und Workflow-Namen, dazu die aggregierten Zahlen, die ein Nutzer aus einem Compute-Job zu senden beschlossen hat. Dateiinhalte oder vollständige Namen erhalten sie nie, denn der Server, der mit ihnen spricht, hat beides nicht.
Zwei Geheimnisse sind zu schützen: das Signaturgeheimnis des Webhooks und, falls Sie die eingehende Richtung nutzen, der API-Schlüssel. Bewahren Sie beide im Zugangsdatenspeicher der Plattform auf, nicht in den sichtbaren Feldern eines Szenarios. Rotieren Sie den API-Schlüssel auf der Seite des Service-Accounts, wenn jemand mit Zugriff ausscheidet, und widerrufen Sie ihn dort im Zweifel. Keines der beiden Geheimnisse kann für sich allein etwas entschlüsseln.
Fragen?
Wenn Sie ein bestimmtes System an einen Tenant anbinden möchten und nicht sicher sind, welche Richtung es braucht, oder wenn Sie Webhook-Nutzlast und Signaturverfahren als Referenzdokument für Ihr Integrationsteam haben möchten, schreiben Sie uns an hello@sapherbox.com.