Security, Datenschutz und Compliance

Security, Datenschutz und Compliance

0:00 Ich möchte dieses Modul mit einer einzigen Tatsache eröffnen, weil sie stellvertretend für das ganze Thema steht: Der SSRF-Schutz in n8n ist ab Werk ausgeschaltet. Nicht versteckt, nicht unvollständig — schlicht aus. Wer ihn für eine Selbstverständlichkeit hält, hat ihn nicht. Und so verhält es sich mit mehreren Schutzmaßnahmen: Sie sind vorhanden, gut dokumentiert und warten darauf, eingeschaltet zu werden.

0:24 Sicherheit ist bei einer Automatisierungsplattform kein Zustand, den man erbt, sondern eine Reihe bewusster Entscheidungen. Dieses Modul geht sie durch.

Security, Datenschutz und Compliance

0:34 Das letzte Modul des fünften Tages. Wir beginnen mit dem Bedrohungsmodell — was macht einen Automatisierungs-Workflow eigentlich angreifbar? — und mit dem Umgang mit Zugangsdaten. Dann die Angriffsflächen und die Stellschrauben, die man selbst gehostet setzen muss. Danach der Datenschutz: Wo bleiben überall Inhalte liegen, und wie wird man sie wieder los?

0:55 Und zum Schluss Nachweisführung und Regulierung — einschließlich einer Prüfung, die n8n selbst mitbringt.

Bedrohungsmodell und Secrets

1:02 Fangen wir mit der Bestandsaufnahme an. Ein Workflow ist ein Dienst mit Zugriff auf alles, was er kennt — und er läuft, ohne dass jemand zusieht. Vier Eigenschaften, und zusammengenommen ergeben sie ein Risikoprofil, das man ernst nehmen sollte. Er nimmt Daten von außen an und verarbeitet sie ohne Aufsicht. Er hält Zugangsdaten zu Systemen, in denen er schreiben darf — oft zu mehreren gleichzeitig. Er läuft unbeobachtet, oft nachts, oft ohne Empfänger für Meldungen.

1:30 Und der vierte ist der, an den beim Einrichten der Rechte niemand denkt: Wer ihn ändern darf, ändert damit die Wirkung auf alle angebundenen Systeme. Ein Automatisierungswerkzeug ist damit ein sehr attraktives Ziel — es sitzt an einer Stelle, an der viele Fäden zusammenlaufen. n8n erzeugt beim ersten Start einen zufälligen Verschlüsselungsschlüssel im Ordner Punkt n8n und verschlüsselt damit die Credentials, bevor sie in die Datenbank geschrieben werden.

1:57 Merken Sie sich diesen Schlüssel — er ist der wichtigste Wert Ihrer Installation. Ohne ihn ist ein Datenbank-Backup wertlos: Sie haben dann verschlüsselte Zugangsdaten und keinen Schlüssel dazu. Und im Queue Mode, über den wir morgen sprechen, muss derselbe Schlüssel allen Workern bekannt sein. Wenn ein Worker einen anderen hat, scheitern Credentials sporadisch — und sporadisch ist die unangenehmste aller Fehlerarten.

2:21 Vier Regeln. In ein Credential, nie in einen Baustein-Parameter und nie in eine Expression — das ist die Grundregel aus Modul fünf. Bei bezahlten Plänen in einen externen Secret Store, projektbezogen einsetzbar; damit liegt das Geheimnis dort, wo es hingehört, und n8n holt es sich. Mit den kleinstmöglichen Scopes, getrennt nach lesend und schreibend — die Trennung, die uns bei den Agenten gerettet hat.

2:46 Und mit einem festgelegten Rotationszeitpunkt statt auf unbestimmte Zeit. Der letzte Punkt klingt bürokratisch und ist der einzige, der verhindert, dass ein Zugang zehn Jahre lang gültig bleibt. Der erste Punkt ist der teuerste Verlust, den Sie erleiden können: Der Verschlüsselungsschlüssel wird nicht gesichert — mit ihm sind alle Credentials verloren, und Sie richten jede Anbindung neu ein.

3:09 Der zweite ist der Queue-Mode-Fall von eben, und er ist deshalb so gemein, weil er nur manchmal auftritt. Der dritte ist eine Bequemlichkeit mit Folgen: Ein Credential dient allen Umgebungen, weil das Anlegen mühsam ist — dann testet Ihre Entwicklung gegen Produktion. Und der vierte kommt aus Modul fünf zurück: Zugangsdaten stehen im cURL-Import, der aus der Dokumentation übernommen wurde.

Angriffsflächen absichern

3:32 Jetzt zu den Stellschrauben. Drei davon müssen selbst gehostet gesetzt werden — und die erste ist die, mit der ich dieses Modul eröffnet habe. Server Side Request Forgery bringt einen Server dazu, Aufrufe an vom Angreifer gewählte Adressen zu richten — etwa localhost, private Netze oder den Metadaten-Endpunkt eines Cloud-Anbieters.

3:53 Das ist bei einem Automatisierungswerkzeug besonders relevant, denn Workflows bilden Adressen naturgemäß aus Daten. Denken Sie an einen Boten, dem man sagt, wohin er laufen soll: Solange Sie das sagen, ist alles gut. Sobald der Absender des Briefes es sagt, wird es interessant — denn Ihr Bote kommt in Gebäude, in die der Absender nicht hineinkommt. n8n kann solche Aufrufe absichern.

4:16 Der Schutz ist standardmäßig ausgeschaltet. Vier Variablen, und die erste ist die einzige, ohne die nichts passiert: Sie schaltet den Schutz überhaupt erst ein. Die anderen drei stimmen ihn ab. Gesperrt werden Bereiche, die n8n als Voreinstellung mitbringt und die Sie um eigene ergänzen können. Erlaubt werden Ausnahmen, und die gehen der Sperrliste vor — damit erreichen Sie einen bekannten internen Dienst, ohne den Schutz ganz abzuschalten.

4:42 Und Hostnamen lassen sich mit einem führenden Platzhalter freigeben. Nehmen Sie sich zehn Minuten für diese vier Zeilen; es ist die wirksamste Einzelmaßnahme dieses Moduls. Vier weitere Hebel. Eine Umgebungsvariable sperrt einzelne Bausteine instanzweit für alle Benutzer. Execute Command ist ab Werk gesperrt — und sollte es bleiben; mit n8n 2 gilt das ebenso für den Local File Trigger.

5:06 Community Nodes lassen sich abschalten oder auf eine eigene Registry begrenzen, das Thema aus Modul elf. Und die öffentliche REST-API gehört abgeschaltet, wenn sie nicht gebraucht wird. Das ist eine Zeile Konfiguration und nimmt eine ganze Angriffsfläche weg. Die Faustregel dahinter ist alt und gilt weiter: Was Sie nicht brauchen, schalten Sie ab.

5:28 Der erste Punkt ist die Zusammenfassung dieses Kapitels: Der SSRF-Schutz wird vorausgesetzt, statt ihn zu setzen. Der zweite ist eine offene Tür ohne Bedarf: Read/Write Files from Disk bleibt verfügbar, obwohl kein Workflow es braucht. Der dritte ist ein Lieferkettenrisiko, das man unterschätzt: Ein Community Node wird installiert, weil er ein Problem löst — geprüft hat ihn niemand, und er bringt seine eigenen Abhängigkeiten mit.

5:53 Und der vierte ist die vergessene Zeile: Die API bleibt offen, weil sie einmal für einen Test gebraucht wurde.

Daten schützen und löschen

6:00 Kommen wir zum Datenschutz. Und da ist die zentrale Einsicht unbequem: Ausführungsdaten sind eine vollständige Kopie aller Inhalte, die Ihr Workflow je verarbeitet hat. Vier Orte, und sie sind nicht alle offensichtlich. In den gespeicherten Ausführungsdaten je Baustein, Ein- und Ausgabe — das ist die große Menge. In Binärdaten, je nach Betriebsart im Dateisystem oder in der Datenbank. In Data Tables, solange niemand sie räumt.

6:27 Und in den Protokollen, wenn dorthin ganze Datensätze geschrieben werden. Wenn Sie also ein Auskunftsersuchen nach DSGVO bekommen und ehrlich beantworten wollen, müssen Sie an vier Stellen nachsehen. Die meisten Häuser denken nur an die erste — und die Data Table erwischt sie dann. Fünf Schritte. Entscheiden Sie je Workflow, welche Läufe überhaupt gespeichert werden. Setzen Sie für sensible Prozesse die Schwärzung der Ausführungsdaten.

6:54 Erzwingen Sie sie bei Bedarf instanzweit — dann ist sie im einzelnen Workflow nicht mehr abschaltbar, und genau das ist der Sinn. Legen Sie für Binärdaten Ablageort und Löschzeitpunkt fest. Und setzen Sie das Löschen als Workflow um, nicht als Absicht. Die Fußzeile beschreibt eine praktische Folge: Wo die Schwärzung instanzweit erzwungen ist, sind die betroffenen Einstellungen im Workflow gesperrt. Das ist Governance, die trägt.

7:20 Der erste Punkt ist eine halbe Maßnahme: Geschwärzt werden manuelle Läufe, produktive nicht — oder umgekehrt; es sind zwei getrennte Einstellungen, und man übersieht leicht eine. Der zweite ist eine Lücke im System: Die Schwärzung wird gesetzt, aber die Protokolle enthalten die Daten weiterhin. Der dritte ist der KI-Fall aus Modul zwölf: Personenbezogene Daten gehen ans Modell, weil das Filtern Arbeit macht.

7:44 Und der vierte ist die klassische Papiermaßnahme: Es gibt eine Aufbewahrungsfrist, aber keinen Vorgang, der sie durchsetzt.

Nachweisführung und Regulierung

7:52 Zum Abschluss zwei Arten von Audit: eine, die man laufen lassen kann — und eine, die man führen muss. Die erste ist erfreulich konkret, die zweite braucht Entscheidungen. n8n bringt eine Sicherheitsprüfung mit, die verbreitete Probleme findet. Sie läuft auf drei Wegen: über die Kommandozeile, über einen Aufruf des Audit-Endpunkts oder über den n8n-Baustein mitten in einem Workflow.

8:15 Dieser dritte Weg ist bemerkenswert, denn er bedeutet: Sie können die Sicherheitsprüfung automatisieren. Ein Workflow, der monatlich prüft und das Ergebnis ins Team schickt, ist in zwanzig Minuten gebaut — und er löst genau das Problem, das jede einmalige Prüfung hat: dass sie einmalig bleibt. Fünf Berichte, und sie lesen sich wie eine Zusammenfassung dieses Seminars. Credentials meldet ungenutzte Zugangsdaten — Kandidaten zum Entziehen.

8:42 Database meldet Expressions in SQL-Feldern; das ist exakt der Einschleusungs-Stolperstein aus Modul sieben, und es freut mich, dass das Werkzeug selbst darauf zeigt. File system listet Bausteine mit Dateizugriff. Nodes meldet riskante, Community- und eigene Bausteine. Und Instance meldet ungeschützte Webhooks, fehlende Sicherheitseinstellungen und eine veraltete Version.

9:05 Lassen Sie diese Prüfung einmal auf einer gewachsenen Instanz laufen — das Ergebnis ist meistens lehrreich. Vier Punkte zur Einordnung, und sie sind bewusst nüchtern gehalten. Der AI Act greift, wenn KI in geschäftliche Entscheidungen und Aktionen eingebunden ist. Nicht das Transportieren von Inhalten ist der Auslöser, sondern das Entscheiden — ein Workflow, der eine Zusammenfassung an einen Menschen schickt, ist etwas anderes als einer, der selbst eine Bestellung auslöst.

9:34 Die Einordnung erfolgt risikobasiert und ist eine fachliche Festlegung, keine technische. Und Freigaben und ihre Nachweise sind Teil dieser Einordnung. Damit ist das Human-in-the-Loop-Modul von gestern nicht nur gute Praxis, sondern auch ein Baustein der Nachweisführung. Der erste Punkt ist der, gegen den der automatisierte Prüf-Workflow hilft: Die Sicherheitsprüfung läuft einmal zur Einführung und nie wieder.

9:58 Der zweite ist eine Form der Gewöhnung: Ungeschützte Webhooks werden gemeldet und als bekannt abgehakt — Befunde, die man nicht behebt, sollte man wenigstens datiert begründen. Der dritte ist eine Lücke in der Nachweisführung: KI-Freigaben werden erteilt, aber nicht nachweisbar festgehalten. Und der vierte ist eine Verschiebung ins Nichts: Die Einordnung nach AI Act wird auf die Rechtsabteilung verschoben und nie geholt.

Übung

10:22 Jetzt nehmen Sie Ihren eigenen Workflow auseinander — den, den Sie in den letzten Tagen aufgebaut haben. Er ist inzwischen ein vollständiger Gegenstand für ein Review. Der Störungs-Workflow von Kesselwerk nimmt Daten von außen an, ruft ein fremdes Portal auf, schreibt in die Fachdatenbank, ruft ein Modell auf und legt Einsätze an.

10:41 Lesen Sie diese Aufzählung als Risikoliste: Jeder einzelne dieser Punkte war in diesem Seminar Gegenstand eines Sicherheitshinweises. Genau deshalb ist er ein vollständiger Gegenstand für ein Security- und Datenschutzreview — Sie können alles anwenden, was wir besprochen haben, und zwar an etwas, das Sie selbst gebaut haben und kennen.

11:00 Das Lernziel: Risiken eines Workflows systematisch erheben und je Befund Maßnahme und Zuständigkeit benennen. Auf systematisch und Zuständigkeit liegt die Betonung — ein Befund ohne Namen wird nicht behoben. Erfolgreich sind Sie, wenn jeder Befund Risiko, Maßnahme und verantwortliche Person trägt, der KI-Anteil risikobasiert eingeordnet ist und die Sicherheitsprüfung gelaufen ist.

11:22 Wer früh fertig ist, prüft, welche Befunde durch eine Einstellung und welche nur durch eine Änderung am Workflow zu beheben sind. Diese Unterscheidung ist praktisch wertvoll: Die einen sind heute erledigt, die anderen brauchen einen Termin. Eine Stunde, fünf Schritte. Lassen Sie zuerst die Sicherheitsprüfung laufen und gehen Sie die fünf Berichte durch — das ist die schnellste Ausbeute.

11:45 Prüfen Sie dann Credentials und Scopes des Workflows einzeln. Sehen Sie sich Webhook-Absicherung, SSRF-Schutz und gesperrte Bausteine an. Legen Sie Ausführungsdaten, Schwärzung und Aufbewahrung fest. Und ordnen Sie zum Schluss den KI-Anteil ein und benennen Sie die Freigabewege. Wenn Sie das einmal durchgespielt haben, haben Sie eine Vorlage, die für jeden weiteren Workflow trägt.

12:09 Vier Fallen. Erstens: Die Checkliste wird abgehakt, ohne die Einstellungen tatsächlich anzusehen — Häkchen sind keine Prüfung. Zweitens: Befunde bekommen eine Maßnahme, aber keine zuständige Person; dann bleibt die Liste liegen. Drittens, und das ist der Fehler, mit dem dieses Modul begann: Der SSRF-Schutz gilt als aktiv, weil er in der Dokumentation steht — sehen Sie nach, ob die Variable gesetzt ist.

12:34 Und viertens: Das Review endet mit einer Liste statt mit Terminen. Eine Liste ohne Termin ist eine Sammlung guter Vorsätze.