Einheit 2 — Credentials richtig verwalten
Was du nach dieser Einheit weißt: Du verstehst den Unterschied zwischen zentraler Credentials-Verwaltung und Inline-Credentials, kennst die Risiken von Inline-Credentials und weißt wann du welchen Ansatz nutzen solltest.
Was sind Credentials im Kontext von Workflows?
Credentials sind Zugangsdaten — alles was ein System braucht um sich bei einem anderen System zu authentifizieren. Das können sein:
- Benutzername und Passwort
- API-Keys
- Client-ID, Client-Secret, Tenant-ID (z. B. für Microsoft Graph)
- Server-Adressen und Ports
- Datenbankverbindungen
In 42°OS gibt es zwei Wege, diese Daten einem Agent mitzugeben.
Weg 1: Zentrale Credentials-Verwaltung
Die Credentials werden an einer zentralen Stelle in 42°OS eingetragen — in der Credentials-Verwaltung. Der Agent referenziert die Credentials nur über ihren Namen, nicht über die eigentlichen Werte.
📸 Screenshot: [Platzhalter — Credentials-Verwaltung in 42°OS: Liste der hinterlegten Credentials mit Namen und Typ]
📹 Video: [Platzhalter — Screencast: Credential anlegen und in einem Agent referenzieren]
{
"credential_name": "erp-prod-api"
}
Der Agent weiß nur: „Ich nutze die Credentials mit dem Namen erp-prod-api." Was dahinter steht — Server, Benutzername, Passwort — sieht der Agent in seiner Konfiguration nicht.
Welche Agents erzwingen das? Einige Agents erlauben nur die zentrale Credentials-Verwaltung:
- SMB File Manager Agent — Server, Share, Benutzername und Passwort müssen als Credential hinterlegt sein
- SMB Monitor Agent — ebenso
- Weitere Agents je nach Typ
Weg 2: Inline-Credentials (direkt in der Agent-Konfiguration)
Bei vielen Agents kannst du Zugangsdaten direkt in die Konfigurationsfelder eintragen — z. B. die Server-URL im Post Agent, oder Client-ID, Tenant-ID und Client-Secret im Microsoft Graph Email Agent.
📸 Screenshot: [Platzhalter — Post Agent Konfiguration: URL-Feld mit direkt eingetragener IP-Adresse und API-Key im Header-Feld]
{
"url": "https://192.168.1.50:8080/api/v1/orders",
"headers": {
"Authorization": "Bearer sk-a8f3...x9z2",
"Content-Type": "application/json"
}
}
Das funktioniert — aber es hat gravierende Nachteile.
Warum Inline-Credentials ein Problem sind
Problem 1: Export enthält Klartext-Zugangsdaten
Wenn du einen Workflow exportierst (z. B. um ihn in eine andere Umgebung zu übertragen oder als Backup zu sichern), werden die Inline-Credentials im Klartext mitexportiert. Jeder der die Export-Datei öffnet, sieht Benutzername, Passwort, API-Keys und Server-Adressen.
Bei zentralen Credentials wird nur der Name exportiert (z. B. erp-prod-api) — die eigentlichen Zugangsdaten bleiben in der Credentials-Verwaltung der Quellumgebung und tauchen im Export nicht auf.
📸 Screenshot: [Platzhalter — Gegenüberstellung: Export-JSON mit Inline-Credentials (Passwort sichtbar) vs. Export-JSON mit Credential-Referenz (nur Name sichtbar)]
Problem 2: Analyse durch externe KI-Tools
In der Praxis kommt es vor, dass du einen Workflow oder dessen Konfiguration durch ein externes KI-Tool analysieren lässt — z. B. durch ChatGPT, Claude oder Mistral — um Fehler zu finden oder Verbesserungen vorzuschlagen.
Wenn der Workflow Inline-Credentials enthält, schickst du die Zugangsdaten an einen externen Dienst. Das ist:
- Ein Datenschutzverstoß — insbesondere wenn es sich um Produktiv-Credentials handelt
- Ein Sicherheitsrisiko — die Zugangsdaten könnten in Trainingsdaten oder Logs des KI-Anbieters landen
- In vielen Unternehmen ein Compliance-Verstoß — Zugangsdaten dürfen das Unternehmensnetz nicht verlassen
Bei zentralen Credentials ist dieses Risiko eliminiert: Im Export steht nur der Name, keine sensiblen Daten.
Ein Entwickler exportiert einen Workflow und fügt das JSON in ChatGPT ein mit der Frage „Warum funktioniert dieser Workflow nicht?" — im JSON stehen Client-ID, Client-Secret und Tenant-ID des Microsoft-365-Mandanten im Klartext. Diese Daten sind jetzt bei einem externen Anbieter.
Mit zentralen Credentials wäre im Export nur "credential_name": "m365-prod" gestanden — keine sensiblen Daten.
Problem 3: Änderungen an mehreren Stellen
Wenn sich ein Passwort ändert oder ein Server umzieht, musst du bei Inline-Credentials jeden Agent einzeln anfassen der diese Daten verwendet. Bei zentralen Credentials änderst du den Wert einmal in der Verwaltung — alle Agents die darauf referenzieren, nutzen automatisch die neuen Daten.
Problem 4: Keine Zugriffskontrolle
Wer den Workflow bearbeiten darf, sieht bei Inline-Credentials automatisch alle Zugangsdaten. Die zentrale Credentials-Verwaltung erlaubt eine Trennung: Workflow-Entwickler können Credentials nutzen ohne sie sehen zu müssen.
Die Regel
Trage niemals Zugangsdaten direkt in Agent-Konfigurationen ein. Nutze immer die zentrale Credentials-Verwaltung — auch wenn der Agent Inline-Credentials erlaubt.
Das gilt für:
- Server-URLs und IP-Adressen (ja, auch diese können sensibel sein — sie verraten die interne Netzwerkstruktur)
- API-Keys und Bearer Tokens
- Client-IDs, Client-Secrets, Tenant-IDs
- Benutzernamen und Passwörter
- Datenbankverbindungsstrings
Credentials sauber benennen
Wenn du viele Credentials anlegst, wird eine klare Benennung wichtig. Bewährt hat sich folgendes Schema:
[system]-[umgebung]-[zweck]
Beispiele:
| Credential-Name | Beschreibung |
|---|---|
erp-prod-api | ERP-System, Produktivumgebung, API-Zugang |
erp-test-api | ERP-System, Testumgebung, API-Zugang |
m365-prod-graph | Microsoft 365, Produktiv, Graph API |
smb-prod-eingangsrechnungen | SMB Share, Produktiv, Ordner Eingangsrechnungen |
dms-prod-api | DMS, Produktiv, API-Zugang |
So erkennst du auf einen Blick welches System, welche Umgebung und welchen Zweck ein Credential abdeckt.
📸 Screenshot: [Platzhalter — Credentials-Verwaltung mit sauber benannten Credentials nach dem Schema system-umgebung-zweck]
Zusammengefasst
| Zentrale Credentials | Inline-Credentials | |
|---|---|---|
| Im Export sichtbar? | Nur der Name | Klartext-Zugangsdaten |
| KI-Analyse sicher? | Ja | Nein — Datenschutzrisiko |
| Passwort-Änderung | Einmal zentral | Jeden Agent einzeln |
| Zugriffskontrolle | Möglich | Nicht möglich |
| Empfehlung | Immer nutzen | Vermeiden |