Service-Accounts mit eng begrenzten Rechten

Früher oder später greift nicht nur ein Mensch auf Ihre Dokumentenplattform zu, sondern auch ein Programm. Eine CI-Pipeline legt Build-Berichte in einem Ordner ab. Ein CRM archiviert unterschriebene Verträge. Ein Skript exportiert die Rechnungen des Vormonats für die Buchhaltung. Am schnellsten geht das, wenn man dem Skript das Passwort einer echten Person gibt. So fangen die meisten Integrationen an, und viel zu viele bleiben dabei.

Die Probleme sind bekannt. Das Skript darf nun alles, was diese Person darf, in jedem Ordner, den sie öffnen kann. Verlässt die Person das Unternehmen, funktioniert die Integration nicht mehr. Oder, schlimmer noch, sie läuft weiter unter einem Konto, für das niemand mehr zuständig ist. Jede Aktion des Skripts landet unter dem Namen der Person im Protokoll. Die Mehrfaktor-Authentifizierung ist entweder im Weg, oder sie wird für dieses Konto abgeschaltet. Und das Passwort, das eigentlich nur im Kopf einer Person existieren sollte, steht jetzt in einer Konfigurationsdatei.

Dafür gibt es in Sapherbox Service-Accounts. Das Konzept an sich ist nicht neu. Erklärenswert ist, wie ein Konto für eine Maschine in ein System passt, in dem der Server keine Schlüssel besitzt.

Ein Konto, kein Token

Ein Service-Account ist ein vollwertiger Teilnehmer im Tenant. Er hat eine Identität, ein Schlüsselpaar und einen Eintrag im Benutzerverzeichnis, gekennzeichnet mit einem API-Badge. Angelegt wird er von einem Administrator. Dieser vergibt einen Namen und eine Adresse, die als Kennung dient. Ein Service-Account hat kein Passwort und kann sich nicht über die Oberfläche anmelden. Er authentifiziert sich stattdessen mit einem API-Schlüssel.

Weil er ein vollwertiger Teilnehmer ist, behandelt ihn die gesamte Plattform auch so. Sie können einen Ordner mit ihm teilen und dabei jede Rolle vergeben, genau wie bei einer Person. Seine Aktionen erscheinen im Audit-Log unter seinem eigenen Namen. Seine Zugriffe stehen in den Zugriffsberichten neben denen aller anderen. Entfernen Sie ihn aus einem Ordner, werden die Schlüssel des Ordners rotiert, wie bei jedem anderen Entzug auch. Einen Sonderweg für Maschinen gibt es nicht. Es gibt ein einziges Zugriffsmodell, und Maschinen gehören dazu.

Schlüssel, die dem Konto gehören

Hier kommt die Ende-zu-Ende-Verschlüsselung ins Spiel. Teilen Sie einen Ordner mit einem Service-Account, wird das Schlüsselbündel des Ordners für die öffentlichen Schlüssel des Kontos versiegelt. Es ist dasselbe hybride Schlüsselpaar, das jeder Teilnehmer hat: RSA-4096 und ML-KEM-768. Der Server speichert das versiegelte Bündel, öffnen kann er es nicht. Die Integration öffnet es mit den privaten Schlüsseln des Kontos, und diese hat nur die Integration.

Die privaten Schlüssel entstehen beim Anlegen des Kontos. Sie werden genau einmal angezeigt, zusammen mit dem ersten API-Schlüssel: dem privaten Schlüssel im Format PKCS#8, dem Post-Quanten-Seed und der Zeichenkette des API-Schlüssels. Der Administrator kopiert sie in den Secret-Store der Integration oder lädt die Datei mit den Zugangsdaten herunter. Dann schließt er den Dialog. Der Server behält die öffentlichen Schlüssel und einen Hash des API-Schlüssels. Die privaten Schlüssel behält er nicht, und er kann sie auch nicht noch einmal anzeigen. Verliert eine Integration ihre Zugangsdaten, bekommt sie ein neues Konto. Eine Wiederherstellung gibt es nicht.

Was manche überrascht: Der Server kann einer Integration keinen Zugriff auf einen Ordner verschaffen. Ein Administrator kann es ebenso wenig, es sei denn, er teilt den Ordner aus einem Browser heraus mit dem Konto. Dieser Browser muss die Schlüssel des Ordners haben und versiegelt dann eine Kopie für das Konto. Die Übergabe läuft also genauso wie die Schlüsselübergabe zwischen Personen, die wir bereits beschrieben haben. Nur sitzt auf der Empfängerseite eine Maschine.

Ein API-Schlüssel mit genau den Rechten, die Sie festlegen

Authentifizierung und Autorisierung sind getrennt. Der API-Schlüssel sagt, wer anfragt. Eine Liste von Scopes am Schlüssel legt fest, was die Anfrage darf. Die Scopes sind bewusst wenige und bewusst einfach gehalten:

• file.read, file.write, file.delete, file.share
• folder.read, folder.write, folder.delete, folder.share
• user.read, user.invite

Ein neuer API-Schlüssel hat gar keine Scopes. Jedes Recht muss ausdrücklich vergeben werden. Eine Integration, die nur Dateien in einem Ordner ablegen soll, bekommt also file.write und sonst nichts. Sie kann weder auflisten, was im Ordner liegt, noch herunterladen, löschen oder teilen. Eine Integration für den Rechnungsexport bekommt file.read und folder.read und kann nichts schreiben. Der Server prüft den Scope bei jeder Anfrage. Fehlt er, lehnt der Server die Anfrage mit einer klaren Meldung ab, die das fehlende Recht nennt.

Die Scopes begrenzen, was der Schlüssel tun darf. Die Freigaben begrenzen, wo er es tun darf. Auch ein Schlüssel mit file.read liest daher nur Dateien in Ordnern, die mit seinem Konto geteilt wurden. Erst beides zusammen ergibt das Prinzip der minimalen Rechte in der Praxis: so wenige Aktionen wie möglich auf so wenigen Ordnern wie möglich.

Ein Konto kann mehrere API-Schlüssel haben, jeden mit eigenen Scopes und eigenem Namen. Rotieren Sie den Schlüssel einer Integration, bleibt eine andere davon unberührt. Einen Schlüssel zu widerrufen kostet einen Klick, und schon der nächste Aufruf mit diesem Schlüssel wird mit Status 401 abgelehnt. Jedes Anlegen eines Schlüssels, jede Änderung der Scopes und jeder Widerruf erzeugt einen Audit-Eintrag.

Was der Server sieht

Für den Server sieht der Datenverkehr eines Service-Accounts aus wie der einer Person. Er sieht also Chiffrat und Metadaten. Er weiß, welches Konto angefragt hat, an welchem Endpunkt, für welchen Ordner oder welche Datei, wann, und ob der Scope das erlaubt hat. Er sieht, dass eine Integration eine Datei in einen Ordner hochgeladen hat, und er kennt die Dateigröße. Lesen kann er die Datei nicht. Die Integration hat sie vor dem Hochladen verschlüsselt, mit einem Schlüssel, den der Server nie hatte. Ein Browser macht es genauso.

Das beantwortet eine Frage, die Integratoren häufig stellen: Kann der Betreiber der Plattform die Integration als Hintertür nutzen? Nein. Der API-Schlüssel dient der Anmeldung am Server, entschlüsseln kann er nichts. Wer den API-Schlüssel stiehlt, aber nicht die privaten Schlüssel, kann im Namen des Kontos die Aktionen ausführen, die seine Scopes erlauben. Das ist Grund genug, den Schlüssel sofort zu rotieren. Inhalte aus Ordnern, die mit dem Konto geteilt sind, kann er aber nicht lesen. Wer beides stiehlt, übernimmt das Konto. Bewahren Sie deshalb beides im selben Secret-Store mit derselben Sorgfalt auf, und legen Sie diesen Store nicht im Repository ab.

Wann Sie einen Service-Account einsetzen

Immer dann, wenn kein Mensch die Anfragen stellt. Das sind Pipelines, Scheduler und Konnektoren, aber auch Automatisierungsplattformen, die aus einem neuen Upload ein Ticket machen oder aus einem unterschriebenen Dokument einen CRM-Eintrag. Geben Sie jeder Integration ein eigenes Konto. Dann gehören ihre Zugriffe und ihr Audit-Protokoll nur ihr. Und geben Sie den Schlüsseln jedes Kontos nur die Scopes, die die Integration zum Arbeiten braucht.

Nutzen Sie einen Service-Account nicht, um die Rechte einer Person zu umgehen. Und nutzen Sie ihn nicht abteilungsübergreifend. Der Sinn eines Service-Accounts liegt darin, dass er genau eine Aufgabe, eine verantwortliche Person und eine Liste von Ordnern hat. Alle drei kann der Administrator, der dafür geradestehen muss, direkt auf dem Bildschirm ablesen.

Fragen?

Wenn Sie eine Integration bauen und den Umgang mit den Schlüsseln genau beschrieben haben möchten, oder wenn Sie wissen wollen, welche Scopes ein bestimmter Konnektor braucht, schreiben Sie uns an hello@sapherbox.com.