Ihre Zugangsdaten liegen im Klartext, und niemand weiß, wo genau

Letzte Woche lag ein Stripe-Live-Key offen in einem HTTP-Modul

Wir haben uns das Make-Konto eines neuen Kunden angesehen, Routine vor einem größeren Umbau. Im dritten Szenario, einer simplen Zahlungsbenachrichtigung, stand der geheime Stripe-Schlüssel direkt im Header-Feld eines HTTP-Bausteins. Nicht in einer Verbindung, nicht in einer Variablen, sondern als sichtbarer Text, den jeder im Team beim Öffnen des Szenarios lesen konnte. Live-Modus, nicht die Sandbox. Mit diesem einen Schlüssel hätte jeder Rückerstattungen auslösen, Kundendaten abfragen und sämtliche Zahlungen einsehen können.

Niemand hatte das mit böser Absicht getan. Jemand wollte vor anderthalb Jahren schnell etwas zum Laufen bringen, das HTTP-Modul war der direkteste Weg, und danach hat nie wieder jemand hingeschaut. Genau so entstehen diese Dinge. Nicht durch grobe Fahrlässigkeit, sondern durch eine kleine Bequemlichkeit, die niemand je wieder anfasst.

Dieser Artikel handelt von dem Thema, das in der No-Code-Automatisierung am beharrlichsten ignoriert wird: wo Ihre Zugangsdaten tatsächlich liegen, wer sie sehen kann, und was passiert, wenn einer davon abhandenkommt. Es ist kein aufregendes Thema. Es ist das Thema, das Sie nachts wachhalten sollte, und in den meisten Unternehmen hat sich noch nie jemand systematisch damit beschäftigt.

Warum ausgerechnet No-Code seine Geheimnisse so gut versteckt

In klassischer Software ist die Frage nach Zugangsdaten ein gelöstes Problem, zumindest dem Anspruch nach. Es gibt Umgebungsvariablen, einen Secret-Manager, eine Trennung zwischen Code und Konfiguration. Entwickler wissen, dass ein API-Schlüssel im Quelltext ein Fehler ist, und Werkzeuge wie GitHub schlagen Alarm, wenn doch einer durchrutscht.

In No-Code-Plattformen verschwindet dieser ganze Apparat. Sie klicken auf "Verbindung hinzufügen", melden sich bei Google oder HubSpot an, und ab da funktioniert es einfach. Der Schlüssel ist da, irgendwo, aber Sie sehen ihn nie wieder. Das ist bequem und meistens sogar sicher, denn die Plattform speichert das Token verschlüsselt und gibt es nicht im Klartext zurück. Das Problem ist nicht die saubere Verbindung. Das Problem sind die vielen Stellen, an denen die Plattform Sie sanft dazu einlädt, am Verbindungsmanager vorbeizuarbeiten.

Ein Webhook, der eine API ansprechen soll, für die es keinen fertigen Baustein gibt. Ein interner Dienst mit einem statischen Token. Eine schnelle Integration, die nur einen Bearer-Header braucht. In all diesen Fällen tippen Sie den Schlüssel von Hand in ein Feld, und in diesem Moment wird aus einem verwalteten Geheimnis ein Stück Text in einer Workflow-Definition. Sichtbar für jeden mit Zugriff, kopiert in jedes Backup, mitexportiert, wenn Sie das Szenario teilen oder klonen.

No-Code macht das Anlegen von Automatisierungen so leicht, dass die unsichtbare Disziplin, die ein Entwicklungsteam mitbringt, schlicht fehlt. Niemand hat je entschieden, Schlüssel im Klartext abzulegen. Es ist einfach der Pfad des geringsten Widerstands, und ohne Gegenkraft setzt sich der Pfad des geringsten Widerstands immer durch.

Die vier Orte, an denen Ihre Schlüssel wirklich liegen

Wenn wir ein Konto auditieren, suchen wir an vier Stellen, und an mindestens dreien werden wir fast immer fündig.

Der erste Ort ist der Verbindungsmanager selbst. Das ist die gute Stelle. Hier liegt das Token verschlüsselt, an einen OAuth-Flow gebunden, von der Plattform verwaltet. Wenn alles dort wäre, müssten wir diesen Artikel nicht schreiben. Aber selbst hier lauert ein Problem, auf das wir gleich kommen: an wessen Konto hängt diese Verbindung?

Der zweite Ort sind HTTP-Module und generische API-Bausteine. Hier landen die statischen Schlüssel, die Bearer-Token, die Basic-Auth-Strings. Im Klartext, im Header- oder Query-Feld, sichtbar beim Öffnen. Das ist der Stripe-Key aus der Einleitung. Jeder, der das Szenario bearbeiten darf, sieht ihn, und in den meisten Make- oder n8n-Installationen darf das halbe Team Szenarien bearbeiten.

Der dritte Ort sind Datenspeicher, Variablen und Notizfelder. Wir haben Schlüssel in Make-Datastores gefunden, in n8n-Variablen, sogar in den Beschreibungsfeldern von Modulen, wo jemand sie "zur Sicherheit" hinterlegt hat, damit man sie wiederfindet. Das ist der digitale Klebezettel am Monitor, nur dass dieser Zettel in jedem Export und in jedem Log mitfährt.

Der vierte Ort ist der gefährlichste, weil er außerhalb der Plattform liegt: die Dokumentation. Das Confluence-Dokument, in dem jemand die Zugangsdaten gesammelt hat, damit das Team sie nicht ständig suchen muss. Die Google-Tabelle mit der Spalte "API-Keys". Der Slack-Thread, in dem ein Schlüssel einmal schnell geteilt wurde und seitdem in der durchsuchbaren Historie liegt. Diese Schlüssel sind genauso gültig wie die in der Plattform, und sie sind für deutlich mehr Menschen sichtbar.

Wer nicht weiß, an wie vielen dieser vier Orte seine Schlüssel liegen, hat keine Kontrolle über sie. Und Kontrolle ist genau das, worum es bei Zugangsdaten geht.

Persönliche Verbindungen sind eine tickende Uhr

Hier ist das Szenario, das wir am häufigsten sehen, und es hat nichts mit Klartext-Schlüsseln zu tun. Es geht um die saubere, verschlüsselte Verbindung im Verbindungsmanager, die alles richtig macht, bis auf eine Sache: Sie hängt am Google-Konto eines Praktikanten, der vor sechs Monaten gegangen ist.

So läuft es ab. Jemand baut eine Automatisierung, die E-Mails über sein Google-Konto verschickt, Termine in seinen Kalender schreibt oder Dateien in seinem Drive ablegt. Die Verbindung wird mit seinem persönlichen Login autorisiert, weil das im Moment des Bauens das Naheliegende ist. Die Automatisierung läuft, alle sind zufrieden, und niemand notiert, dass diese produktive Rechnungsstellung an einem persönlichen Konto hängt.

Dann verlässt die Person das Unternehmen. Die IT deaktiviert ihren Account, ordnungsgemäß, am letzten Arbeitstag. Eine Woche später laufen keine Rechnungen mehr raus, und niemand versteht warum, weil niemand wusste, dass dieser Prozess je an einem einzelnen Menschen hing. Oder, der schlimmere Fall: Die IT deaktiviert den Account nicht vollständig, weil "da hängt ja noch was dran", und jetzt existiert ein aktives Zugangsrecht für jemanden, der nicht mehr im Unternehmen ist.

Persönliche Verbindungen sind aus zwei Richtungen ein Problem. Geht die Person, bricht der Prozess oder das Recht bleibt offen. Und solange die Person da ist, läuft ein geschäftskritischer Vorgang über die individuellen Berechtigungen eines Einzelnen, mit allem, was diese Person in ihrem Konto sonst noch sehen und tun darf. Die Lösung sind dedizierte Dienstkonten, ein Automatisierungs-Login, das niemandem persönlich gehört, klar als solches benannt, mit genau den Rechten, die der Prozess braucht. Das ist mehr Aufwand beim Einrichten. Es ist der Unterschied zwischen einer Infrastruktur und einer Sammlung von Glücksfällen.

Niemand rotiert, weil niemand weiß, was bricht

Sicherheitsleute sagen, man solle Schlüssel regelmäßig rotieren. Alle 90 Tage, sagen manche Richtlinien. In der Praxis rotiert in No-Code-Umgebungen so gut wie niemand, und der Grund ist nicht Faulheit. Der Grund ist Angst.

Wenn Sie einen API-Schlüssel rotieren, müssen Sie jede Stelle aktualisieren, die ihn benutzt. In einer sauberen Architektur liegt der Schlüssel an genau einem Ort, Sie tauschen ihn, fertig. In einer gewachsenen No-Code-Landschaft wissen Sie nicht, an wie vielen Stellen derselbe Schlüssel klebt. Vielleicht in drei Szenarien, vielleicht in zwölf, vielleicht auch in dem Confluence-Dokument und in der Google-Tabelle. Rotieren Sie ihn an einer Stelle und vergessen eine andere, bricht ein Prozess, und Sie merken es womöglich erst Tage später, wenn jemand fragt, warum die Synchronisation steht.

Diese Angst ist berechtigt, und sie ist ein Symptom. Wenn Sie einen Schlüssel nicht rotieren können, ohne nervös zu werden, dann haben Sie keine Kontrolle über seinen Wirkungsradius. Sie wissen nicht, was er anrichtet, wenn er leakt, und Sie wissen nicht, was bricht, wenn Sie ihn ändern. Das sind dieselbe Frage aus zwei Richtungen.

Der Ausweg ist nicht, häufiger zu rotieren. Der Ausweg ist, zu wissen, wo jeder Schlüssel liegt, sodass Rotation eine Frage von Minuten wird und nicht von Mut. Ein einfaches Inventar, eine Liste jedes Schlüssels mit den Stellen, an denen er verwendet wird, verwandelt einen angstbesetzten Eingriff in eine Routine. Den meisten Unternehmen fehlt diese Liste vollständig.

Ein Schlüssel kann fast immer mehr, als er müsste

Es gibt eine Frage, die wir bei jedem Audit stellen, und auf die wir fast nie eine gute Antwort bekommen: Was genau darf dieser Schlüssel eigentlich?

Wenn eine Automatisierung nur neue Zeilen in ein Google Sheet schreiben soll, dann braucht ihr Schlüssel Schreibzugriff auf dieses eine Sheet. Was er in der Realität meistens hat, ist Vollzugriff auf das gesamte Google Drive der Person, die die Verbindung autorisiert hat. Lesen, Schreiben, Löschen, über alle Dateien hinweg. Das passiert, weil OAuth-Scopes beim Einrichten gerne großzügig vergeben werden und weil niemand sich die Mühe macht, sie einzuschränken, solange es funktioniert.

Das Prinzip dahinter heißt geringste Rechte, und es ist die wirksamste einzelne Maßnahme, die Sie ergreifen können. Ein Schlüssel mit minimalen Rechten richtet minimalen Schaden an, wenn er kompromittiert wird. Ein HubSpot-Token, das nur Kontakte lesen darf, ist im Fall eines Leaks ein überschaubares Problem. Ein HubSpot-Token mit vollem Admin-Zugriff ist eine Katastrophe, die Ihre gesamte Vertriebsdatenbank umfasst.

Die Disziplin ist unbequem, weil eingeschränkte Rechte bedeuten, dass eine Automatisierung später vielleicht doch noch eine Berechtigung braucht, die Sie ihr nicht gegeben haben, und dann steht sie. Genau deshalb vergeben die meisten Leute lieber zu viel. Aber dieser Tausch ist falsch herum gedacht. Ein Prozess, der wegen fehlender Rechte stoppt, ist ein sichtbarer, harmloser Fehler, den Sie in fünf Minuten beheben. Ein überprivilegierter Schlüssel, der leakt, ist ein unsichtbarer Schaden, von dem Sie womöglich erst erfahren, wenn er bereits angerichtet ist.

Der Datenschutz-Winkel, den die meisten übersehen

Bis hierhin klingt das nach einem reinen Sicherheitsthema. Für Unternehmen, die unter die DSGVO fallen, und das sind in Europa nahezu alle, ist es auch ein Compliance-Thema, und zwar ein konkretes.

Ein API-Schlüssel, der Zugriff auf personenbezogene Daten gewährt, ist im datenschutzrechtlichen Sinne ein Zugang zu diesen Daten. Wer ihn besitzt, kann die Daten verarbeiten. Die DSGVO verlangt in Artikel 32 technische und organisatorische Maßnahmen, die genau das regeln: Zugriffskontrolle, Vertraulichkeit, die Fähigkeit, nachzuvollziehen, wer auf welche Daten zugreifen kann. Ein Stripe-Live-Key im Klartext, sichtbar für das halbe Team, ist die Negation dieser Anforderung in einem einzigen Feld.

Es kommt eine zweite Dimension dazu. Wenn Ihre Automatisierung über einen Schlüssel Daten an einen Dienstleister schickt, etwa an einen amerikanischen API-Anbieter, dann ist dieser Dienstleister ein Auftragsverarbeiter, für den Sie einen Auftragsverarbeitungsvertrag und eine saubere Rechtsgrundlage brauchen. Der Schlüssel ist der technische Beweis, dass diese Datenübermittlung stattfindet. Wer seine Schlüssel nicht inventarisiert hat, kann nicht einmal sagen, welche Dienstleister überhaupt im Spiel sind, und kann damit seine eigene Auftragsverarbeitung nicht vollständig dokumentieren.

Im Ernstfall, bei einer Datenschutzpanne oder einer Anfrage der Aufsichtsbehörde, ist die erste Frage immer dieselbe: Wer hatte Zugriff, und wie war dieser Zugriff abgesichert? "Der Schlüssel lag im Klartext in einem Szenario, das zwölf Leute bearbeiten durften" ist keine Antwort, mit der Sie in dieser Situation auskommen wollen.

Woran Sie merken, dass ein Schlüssel abhandenkam (meistens: gar nicht)

Hier ist der unangenehmste Teil. Wenn ein Schlüssel kompromittiert wird, gibt es in den allermeisten No-Code-Setups kein Signal. Kein Alarm, keine Benachrichtigung, nichts. Der Angreifer benutzt einen gültigen Schlüssel, also sieht jede Anfrage legitim aus, weil sie es technisch ist.

Bei klassischer Software gibt es Logging, Anomalieerkennung, Warnungen bei ungewöhnlichen Zugriffsmustern. In einer typischen Automatisierungslandschaft fehlt all das. Ein geleakter Schlüssel kann monatelang im Stillen Daten abgreifen, und Sie erfahren davon, wenn überhaupt, durch einen Dritten. Durch eine Rechnung über API-Aufrufe, die Sie nicht getätigt haben. Durch einen Kunden, der fragt, warum seine Daten irgendwo aufgetaucht sind. Durch den Anbieter selbst, der ungewöhnliche Aktivität meldet.

Das verschiebt die ganze Logik. Wenn Sie ein Leck nicht zuverlässig erkennen können, dann ist Ihre einzige wirksame Verteidigung, das Leck von vornherein unwahrscheinlich zu machen und seinen Schaden klein zu halten. Genau dorthin führen die vorherigen Abschnitte: weniger Stellen, an denen ein Schlüssel liegt, weniger Rechte pro Schlüssel, dedizierte Konten statt persönlicher. Jede dieser Maßnahmen senkt entweder die Wahrscheinlichkeit eines Lecks oder den Schaden, den es anrichtet. Da Sie auf die Erkennung kaum bauen können, ist Prävention nicht eine von mehreren Optionen. Sie ist die einzige, die zuverlässig wirkt.

Wo es geht, lohnt es sich trotzdem, ein Minimum an Erkennung einzubauen. Manche Anbieter, Stripe etwa, zeigen das Datum der letzten Verwendung eines Schlüssels und erlauben getrennte, einzeln widerrufbare Schlüssel. Wer pro Automatisierung einen eigenen Schlüssel vergibt, kann im Verdachtsfall einen einzelnen widerrufen, ohne alles andere lahmzulegen, und sieht an der Nutzungsstatistik, ob ein Schlüssel Aktivität zeigt, die er nicht zeigen sollte.

Wie wir es lösen

Wenn wir ein Konto in Ordnung bringen, folgen wir immer derselben Reihenfolge, und sie beginnt nicht mit einem Werkzeugkauf, sondern mit einer Bestandsaufnahme.

Zuerst inventarisieren wir. Jeder Schlüssel, jede Verbindung, jeder Ort, an dem ein Geheimnis liegt, kommt auf eine Liste. Welcher Schlüssel, welcher Dienst, welche Rechte, an welchem Konto, in welchen Szenarien. Diese Liste existiert vorher fast nie, und allein ihre Erstellung deckt regelmäßig Schlüssel auf, von denen niemand mehr wusste, dass sie existieren und noch gültig sind.

Dann holen wir die Klartext-Schlüssel aus den Workflows heraus. In n8n bedeutet das, Anmeldedaten konsequent über das Credential-System zu führen statt über Felder in HTTP-Nodes. In Make heißt es, Verbindungen und, wo nötig, eigene Schlüsselverwaltung zu nutzen, statt Token in Header zu tippen. Wer es ernst meint und die Möglichkeit hat, legt einen echten Secret-Manager dazwischen, einen Dienst, dessen einzige Aufgabe es ist, Geheimnisse zu verwahren und kontrolliert herauszugeben. Die Workflows holen den Schlüssel dann zur Laufzeit von dort und speichern ihn nirgends ab.

Als Drittes ersetzen wir persönliche Verbindungen durch Dienstkonten. Jede produktive Automatisierung läuft über ein Konto, das dem Unternehmen gehört, nicht einem Mitarbeiter, klar benannt, mit dokumentiertem Zweck. Das überlebt jeden Personalwechsel.

Viertens schneiden wir Rechte zurück. Für jeden Schlüssel die Frage: Was braucht dieser Prozess wirklich? Alles darüber hinaus wird entzogen. Das ist die mühsamste Etappe, weil sie Prozess für Prozess geht, und die wirksamste, weil sie den Schaden jedes einzelnen Lecks begrenzt.

Erst danach reden wir über Rotation. Mit einem vollständigen Inventar wird Rotation zu dem, was sie sein sollte: ein planbarer Vorgang, der weder Angst noch einen ganzen Nachmittag kostet. Wer die ersten vier Schritte gegangen ist, für den ist der fünfte fast trivial.

Ein Audit, das eine halbe Stunde dauert

Sie müssen nicht auf ein Projekt warten, um eine erste Einschätzung zu bekommen. Setzen Sie sich dreißig Minuten mit jemandem zusammen, der Zugriff auf Ihre Automatisierungsplattform hat, und gehen Sie die folgenden Fragen durch.

Öffnen Sie Ihre fünf wichtigsten Szenarien und schauen Sie in jedes HTTP- oder API-Modul. Steht dort irgendwo ein Schlüssel oder Token im Klartext? Notieren Sie jeden, den Sie finden. Schauen Sie dann in den Verbindungsmanager und prüfen Sie bei jeder Verbindung, an wessen Konto sie hängt. Taucht dort der Name von jemandem auf, der das Unternehmen verlassen hat oder bald verlässt? Prüfen Sie, ob es irgendwo, in Confluence, in einer Tabelle, in einem Chat, eine Sammlung von Zugangsdaten gibt, und ob die Schlüssel darin noch gültig sind. Fragen Sie zuletzt für die drei kritischsten Verbindungen, welche Rechte sie eigentlich haben und ob der jeweilige Prozess auch nur einen Bruchteil davon braucht.

Wenn Sie diese vier Fragen ehrlich durchgehen, werden Sie mit hoher Wahrscheinlichkeit mindestens ein Problem finden, das Sie noch am selben Tag beheben sollten. Das ist kein Zeichen von Nachlässigkeit, sondern der Normalzustand gewachsener No-Code-Landschaften. Der Unterschied zwischen einem sicheren und einem unsicheren Konto ist nicht, dass beim sicheren nie etwas schiefgegangen wäre. Der Unterschied ist, dass beim sicheren jemand einmal systematisch hingeschaut hat.

Worauf es am Ende ankommt

Zugangsdaten sind das stille Fundament jeder Automatisierung. Solange sie funktionieren, denkt niemand an sie, und genau das macht sie gefährlich. Der Stripe-Key im Klartext, das Token am Konto des Praktikanten, der Schlüssel mit Vollzugriff, den eine Aufgabe nutzt, die nur lesen müsste: Keines dieser Probleme schreit. Sie warten leise, bis ein Mensch geht, ein Schlüssel leakt oder eine Behörde fragt.

Die gute Nachricht ist, dass dieses Thema mit Disziplin lösbar ist und nicht mit einem großen Budget. Ein Inventar, das Sie selbst führen können. Klartext-Schlüssel, die in das Credential-System der Plattform wandern. Dienstkonten statt persönlicher Logins. Rechte, die auf das Nötige zugeschnitten sind. Das ist keine Raketenwissenschaft, es ist Hygiene, und wie jede Hygiene wirkt sie nur, wenn sie zur Gewohnheit wird und nicht zur einmaligen Aufräumaktion.

Wenn Sie nicht sicher sind, wo Ihre Schlüssel liegen und wer sie sehen kann, ist das die wichtigste Frage, die Sie diese Woche in Ihrer Automatisierung stellen können. Und falls Sie bei dem Gedanken kurz zusammengezuckt sind, weil Ihnen ein bestimmtes Szenario eingefallen ist: Genau dort fangen Sie an.