n8n-Zugangsdaten und Rechte sicher übergeben

Definition. Ein Credential verbindet einen Workflow mit einer Anwendung, etwa über OAuth oder einen API-Schlüssel. Die offizielle Anleitung zur Erstellung von Credentials beschreibt die Bedienung und dienstabhängige Einrichtung. Die konkrete Berechtigung wird jedoch auch durch das verbundene System bestimmt.

Effektive Handlungsmöglichkeit. Behandeln Sie deshalb nicht nur den sichtbaren Schlüssel als sensibel. Wer einen Workflow mit einer privilegierten Verbindung ausführen oder verändern kann, kann unter Umständen weitreichende Aktionen auslösen, ohne den ursprünglichen Geheimwert zu sehen. Prüfen Sie die effektive Handlungsmöglichkeit, nicht lediglich, ob ein Passwortfeld verdeckt dargestellt wird.

Getrennte Aufgaben. Ein lesender Statusbericht benötigt andere Rechte als eine Kontaktsynchronisation mit Schreibzugriff. Ein Workflow, der Entwürfe vorbereitet, benötigt nicht automatisch das Recht, Nachrichten zu versenden. Trennen Sie diese Aufgaben soweit das Zielsystem und die Betriebsform es ermöglichen.

Die Tabelle trennt die beiden Berechtigungsebenen, n8n und Zielsystem, von der Zuständigkeit für das Erneuern oder Ersetzen eines Zugangs:

Rollen. n8n unterscheidet Instanz- und Projektrollen. Konkrete Rollen und Verwaltungsfunktionen hängen von Edition und Tarif ab. Prüfen Sie die aktuelle Rollenübersicht und die Befugnisse einzelner Rollen für Ihre Installation. Die Produktdokumentation wurde am 26. September 2026 geprüft; eine allgemein benannte „Viewer“-Rolle darf nicht ohne Prüfung als passende Datenabschirmung angenommen werden.

Projektgrenze. Ein Projekt ist außerdem keine universelle Mandantengrenze für jedes angeschlossene System. Prüfen Sie beispielsweise, ob das verbundene API-Konto trotz Projekttrennung sämtliche Kunden lesen kann. Das Ergebnis dieser Prüfung gehört in die Zugriffsmatrix.

Felder des Inventars. Ein Credential-Inventar ist eine Tabelle ohne Geheimwerte. Sie enthält:

• verständlichen Namen
• Zielsystem
• Zweck
• Umgebung
• Kontoeigentümer
• erlaubte Aktionen
• Ablauf oder Erneuerungsverfahren
• abhängige Workflows

Ein Name wie „CRM-Produktion-Kontakte-Lesen“ ist aussagekräftiger als „Account 2“.

Zuständigkeiten. Für jede n8n-Verbindung beantworten Sie vier Fragen zur Zuständigkeit:

• Wer darf sie einrichten?
• Wer genehmigt die Rechte?
• Wer kann sie bei einem Vorfall sperren?
• Wer prüft nach einer Änderung die abhängigen Prozesse?

Bei kleinen Teams kann dieselbe Person mehrere Rollen übernehmen, doch die Zuständigkeit sollte trotzdem ausdrücklich feststehen.

Personengebundene Konten. Halten Sie auch fest, ob die Verbindung an eine einzelne Person gebunden ist. Ein Workflow darf nicht unerwartet ausfallen, weil das private Projektkonto eines früheren Mitarbeiters gelöscht wird. Verwenden Sie organisationsgeeignete Konten oder App-Registrierungen entsprechend den Regeln des Zielanbieters.

Eigentum zurückgewinnen. Halten Sie auch fest, auf welchem Weg das Eigentum an einer Verbindung zurückgewonnen wird. Eine während eines Projekts eingerichtete Verbindung lässt sich nur schwer pflegen, wenn allein der ausscheidende Dienstleister weiß, auf welcher App-Registrierung oder welchem Konto sie beruht.

Ausgangslage. Das folgende Beispiel ist ein konstruierter Entwurf. Ein Unternehmen beauftragt eine Agentur mit der Pflege einer CRM-Übertragung. Intern soll ein Vertriebsadministrator Ergebnisse prüfen; die IT verwaltet die Anwendungseinwilligung. Die Agentur benötigt Änderungsmöglichkeiten am Workflow, aber keinen pauschalen Zugriff auf alle Unternehmensanwendungen.

Geplanter Aufbau. Der geplante Aufbau verwendet ein kundeneigenes Vertrags- und Kontomodell, eine dokumentierte CRM-Verbindung und getrennte Testdaten. Vor Übergabe prüft die IT den tatsächlichen API-Umfang. Der Vertriebsadministrator erhält den für seine Aufgabe nötigen Zugang zu Ergebnissen, nicht automatisch Bearbeitungsrechte an Produktionsabläufen.

Negativer Test. Zur Abnahme gehört ein negativer Test: Die Agentur darf außerhalb des vereinbarten Projekts keine Ressourcen bearbeiten. Zusätzlich wird geprüft, ob der Workflow eine nicht vorgesehene Zieloperation ausführen könnte. Wenn die API Rechte nur sehr grob vergibt, wird diese verbleibende Einschränkung dokumentiert und durch passende betriebliche Grenzen behandelt.

Warum das zählt. Diese Übung ist aussagekräftiger als eine Checkliste mit dem Vermerk „Credentials verschlüsselt“. Verschlüsselung schützt gespeichertes Material; sie entscheidet nicht darüber, ob eine Person eine privilegierte Aktion auslösen darf.

Wo Schlüssel nicht hingehören. Speichern Sie Schlüssel nicht in Beschreibungsfeldern, normalen Tabellen, Screenshots oder Beispiel-Payloads. Achten Sie besonders auf HTTP-Header, URLs und Fehlermeldungen. Ein Token in einem Query-Parameter kann leichter in Protokollen oder geteilten Links auftauchen.

Credential-Felder und Geheimnisspeicher. Verwenden Sie Credential-Felder und gegebenenfalls einen zur Edition passenden externen Geheimnisspeicher. Verwechseln Sie gewöhnliche Konfigurationsvariablen nicht mit einem vorgesehenen Secret-Verfahren. Exporte und gespeicherte Ausführungen müssen ebenfalls auf sensible Inhalte geprüft werden.

Erlaubte Zieldomains. Bei HTTP-Requests unterstützt n8n für viele Credentials eine Begrenzung erlaubter Zieldomains. Die Credential-Dokumentation erklärt auch deren Grenze: Die Einstellung bezieht sich auf die Verwendung im HTTP-Request-Node. Sie ersetzt keine allgemeine Prüfung aller Nodes und Netzwerkwege.

Kopien für die Prüfung. Wenn Sie einen Workflow zur Prüfung weitergeben, liefern Sie erfundene Beispielwerte und eine Feldbeschreibung statt echter Zugangsdaten. Ein Prüfer muss in der Regel Art und Umfang der Verbindung verstehen, nicht den produktiven Geheimwert besitzen.

Vorbereitung. Eine geplante Erneuerung beginnt mit der Liste abhängiger Workflows. Erstellen oder erneuern Sie die Verbindung entsprechend dem Verfahren des Anbieters. Prüfen Sie zunächst einen erlaubten, möglichst wenig folgenreichen Zugriff. Danach kontrollieren Sie den realen Prozess mit einem bekannten Testfall.

Übergang. Falls der Anbieter parallele alte und neue Schlüssel erlaubt, kann ein zeitlich begrenzter Übergang sinnvoll sein. Wenn er das nicht erlaubt, braucht die Umstellung ein geplantes Fenster. Erfinden Sie keine generelle Rotationsfrist; berücksichtigen Sie Anbieterregeln, Sensibilität und interne Vorgaben.

Widerruf. Nach erfolgreicher Umstellung wird der alte Zugang widerrufen und der Nachweis aktualisiert. Lassen Sie ungenutzte Schlüssel nicht dauerhaft bestehen, nur weil sie vielleicht noch einmal gebraucht werden könnten. Ein dokumentierter Rückfallweg sollte nicht von unbegrenzt aktiven Altzugängen abhängen.

Beim Ausscheiden einer Person oder eines Dienstleisters prüfen Sie n8n-Konto, Projekte, Zielsystemkonten, App-Einwilligungen, API-Schlüssel und Zugang zu Backups. Das Entfernen eines n8n-Benutzers widerruft nicht automatisch sämtliche Berechtigungen in anderen Systemen.

Testen Sie anschließend den weiter benötigten Workflow unter der vorgesehenen Betriebsverantwortung. Kontrollieren Sie außerdem, dass der entfernte Nutzer keine neuen Aktionen mehr auslösen kann. Die Abnahme ist vollständig, wenn Zuständigkeit, tatsächliche Befugnis und Entzug zusammen nachgewiesen sind. Eine Liste versteckter Passwortfelder reicht dafür nicht aus.

Diese Seiten behandeln die Leistungsübersicht und die angrenzenden Entscheidungen zu n8n-Zugangsdaten und Rechten:

• n8n-Agentur: Umsetzung und Betrieb von Unternehmensworkflows
• n8n und Datenschutz: Datenflüsse statt pauschaler Zusagen prüfen
• n8n mit Outlook und Microsoft 365: Postfachprozesse planen
• n8n-Projekt übergeben: Dokumentation, Tests und Eigentum

Für eine konkrete Ablaufprüfung reichen zunächst eine Prozessbeschreibung, die beteiligten Systeme und typische Ausnahmen. Mit modernagents besprechen.