Sicherheit

Vier Grundregeln sichern Ihre Automate-Workflows ab: Credentials gehören in den Credential Store und niemals in den Workflow selbst, jeder Webhook braucht mindestens eine Authentifizierungsmethode, alle Verbindungen — API-Calls, Webhooks, Datenübertragung — laufen über HTTPS, und die Nachvollziehbarkeit sichern Execution-Historie und die Localmind-Audit-Logs.

Credential-Management

Secrets gehören in den Credential Store von Automate: Dort werden sie verschlüsselt gespeichert und nur zur Laufzeit entschlüsselt — sie landen weder im Workflow-JSON noch in Workflow-Exporten. Legen Sie API-Keys, Passwörter und Tokens immer als Credential an und referenzieren Sie diese in den Node-Einstellungen. Die $env-Expression liest Server-Umgebungsvariablen. Diese werden vom Betreiber Ihrer Automate-Instanz serverseitig gesetzt — ein eigenes UI zum Anlegen von Environment Variables gibt es in Automate nicht. Als Workflow-Builder können Sie $env nur nutzen, wenn der Betreiber die entsprechende Variable hinterlegt hat.

Hardcoden Sie Credentials niemals direkt in Nodes oder Code — hardcodierte Werte erscheinen im Workflow-JSON und damit in jedem Export.

Abgrenzung: Org-Zugangsdaten. Der Automate Credential Store ist unabhängig von den Zugangsdaten Ihrer Localmind-Organisation. Letztere verwalten Org-Admins unter Org-Settings → Sicherheit → Zugangsdaten für Dienste, die Localmind-Agents und Apps nutzen (z.B. DeepL). Credentials, die Ihre Automate-Workflows verwenden, legen Sie direkt in Automate an.

Webhook-Sicherheit

Webhooks ohne Authentifizierung sind ein Sicherheitsrisiko. Implementieren Sie immer mindestens eine Authentifizierungsmethode.

Behandeln Sie auch die Webhook-URL selbst als Geheimnis: Wer sie kennt, kann Ihren Workflow auslösen. Teilen Sie Produktions-URLs nur mit den Systemen, die sie benötigen. Die Webhook-URL eines Workflows sehen Sie direkt im Webhook-Node im Workflow-Editor. Der kanonische Weg zur Absicherung ist Header Auth im Webhook-Node. Für Datenintegrität und Absender-Verifikation ergänzen Sie eine HMAC-Signatur.

Header Auth (empfohlen)

Der Webhook-Node prüft eingehende Requests auf einen erwarteten Header und beantwortet Requests ohne gültigen Header mit einem Fehler — ohne dass Ihr Workflow startet.

Authentifizierung aktivieren

Öffnen Sie den Webhook-Node und wählen Sie unter Authentication die Option Header Auth.

Credential anlegen

Erstellen Sie eine neue Header-Auth-Credential mit Name (der erwartete Header, z.B. X-API-Key) und Value (das Secret). Die Credential wird verschlüsselt im Credential Store gespeichert.

Testen

Senden Sie einen Test-Request mit und ohne gültigen Header und prüfen Sie, dass nur der authentifizierte Request den Workflow auslöst.

Auch Bearer-Tokens prüfen Sie über Header Auth: Verwenden Sie als Header-Name Authorization und als Value Bearer <ihr-token>.

curl -X POST https://your-webhook-url \
  -H "X-API-Key: your-secret-api-key" \
  -H "Content-Type: application/json" \
  -d '{"data": "value"}'

curl -X POST https://your-webhook-url \
  -H "Authorization: Bearer your-secret-token" \
  -H "Content-Type: application/json" \
  -d '{"data": "value"}'

Verwenden Sie starke, zufällige Werte und rotieren Sie sie regelmäßig — bei Header Auth genügt dafür ein Update der Credential, der Workflow bleibt unverändert. Je nach Automate-Version bietet der Webhook-Node zusätzlich JWT Auth an; ob die Option verfügbar ist, sehen Sie direkt im Authentication-Dropdown des Nodes.

HMAC-Signatur

Eine HMAC-SHA256-Signatur stellt sicher, dass der Request-Body unterwegs nicht manipuliert wurde und tatsächlich vom erwarteten Absender stammt. Der Absender signiert den Body mit einem Shared Secret; Ihr Workflow berechnet die Signatur nach und vergleicht.

const crypto = require('crypto');

const signature = $json.headers['x-signature'];
const body = JSON.stringify($json.body);

const expectedSignature = crypto
  .createHmac('sha256', $env.WEBHOOK_SECRET)
  .update(body)
  .digest('hex');

if (signature !== expectedSignature) {
  throw new Error('Invalid signature');
}

return [{ json: { valid: true, data: $json.body } }];

# Signatur berechnen
SIGNATURE=$(echo -n '{"data":"value"}' | \
  openssl dgst -sha256 -hmac "secret" | \
  cut -d' ' -f2)

curl -X POST https://your-webhook-url \
  -H "X-Signature: $SIGNATURE" \
  -H "Content-Type: application/json" \
  -d '{"data":"value"}'

Das Beispiel setzt voraus, dass der Betreiber das Shared Secret als Server-Umgebungsvariable (WEBHOOK_SECRET) hinterlegt hat und require für das Node.js-Built-in-Modul crypto serverseitig freigeschaltet ist. Falls der Aufruf fehlschlägt, wenden Sie sich an Ihren Administrator.

Basic Auth

Für interne Systeme genügt oft Basic Auth: Wählen Sie im Webhook-Node Authentication → Basic Auth und hinterlegen Sie Benutzername und Passwort als Credential.

cURL Beispiel

curl -X POST https://your-webhook-url \
  -u webhook_user:secure_password \
  -H "Content-Type: application/json" \
  -d '{"data": "value"}'

Basic Auth ist einfach und von allen HTTP-Clients unterstützt, aber weniger flexibel als Header Auth — bevorzugen Sie für neue Integrationen Header Auth.

Replay-Schutz

Header Auth und HMAC verhindern nicht, dass ein abgefangener, gültiger Request erneut gesendet wird. Dagegen schützen Timestamp- und Nonce-Prüfung — am besten kombiniert. Timestamp-Validierung: Lehnen Sie Requests ab, deren Zeitstempel zu alt ist. Der Absender sendet dafür einen Header wie X-Timestamp mit.

Timestamp-Check (Code-Node)

const requestTime = parseInt($json.headers['x-timestamp'] || '0');
const maxAge = 5 * 60 * 1000; // 5 Minuten

if (Math.abs(Date.now() - requestTime) > maxAge) {
  throw new Error('Request timestamp too old or invalid');
}

return [{ json: { valid: true } }];

Verwenden Sie ein maximales Alter von 5-15 Minuten, abhängig von Ihrer Anwendungslogik. Bei HMAC-Absicherung sollte der Timestamp Teil der signierten Daten sein, damit er nicht manipuliert werden kann. Nonce-Validierung: Eine Nonce (Number Used Once) stellt sicher, dass jeder Request nur einmal verarbeitet wird, auch wenn er mehrfach gesendet wird.

Nonce-Check (Code-Node)

const staticData = $getWorkflowStaticData('global');
const nonce = $json.headers['x-nonce'];
const seenNonces = staticData.seenNonces || [];

if (seenNonces.includes(nonce)) {
  throw new Error('Duplicate request');
}

staticData.seenNonces = [...seenNonces, nonce].slice(-1000);

return [{ json: { valid: true } }];

Beachten Sie: $getWorkflowStaticData persistiert nur bei Produktions-Ausführungen aktiver Workflows, nicht bei manuellen Test-Runs.

Webhook-Sicherheits-Checkliste

Mindestens eine Authentifizierungsmethode ist implementiert
Secrets liegen im Credential Store, nicht im Workflow-JSON
Die Webhook-URL wird wie ein Geheimnis behandelt
HTTPS wird verwendet (nicht HTTP)
HMAC-Signaturen werden bei kritischen Webhooks validiert
Replay-Schutz (Timestamp + Nonce) ist bei kritischen Webhooks implementiert
Fehlgeschlagene Authentifizierungsversuche werden überwacht

Input-Validierung

Validieren Sie alle eingehenden Daten, bevor Ihr Workflow sie weiterverarbeitet:

Input-Validierung (Code-Node)

// Validieren Sie das E-Mail-Format
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
if (!emailRegex.test(input.email)) {
  throw new Error('Invalid email format');
}

// Validieren Sie Datentypen
if (typeof input.userId !== 'string') {
  throw new Error('userId must be string');
}

// Validieren Sie den Wertebereich
if (input.amount < 0 || input.amount > 10000) {
  throw new Error('Amount out of range');
}

SQL-Injection verhindern

Bei Datenbankabfragen gilt: Verwenden Sie Parameterized Queries, fügen Sie User-Input niemals direkt in SQL ein und validieren Sie alle Inputs.

const query = 'SELECT * FROM users WHERE id = ?';
const result = await db.query(query, [userId]);

const query = `SELECT * FROM users WHERE id = ${userId}`;
// NIEMALS SO!

Audit und Nachvollziehbarkeit

Automate führt kein eigenes Audit-Log. Zwei reale Quellen decken die Nachvollziehbarkeit ab:

Execution-Historie: Jede Workflow-Ausführung mit Status, Input/Output und Fehlern finden Sie im Executions-Tab — siehe Debugging.
Localmind-Audit-Logs: Sicherheitsrelevante Ereignisse Ihrer Organisation (Logins, Berechtigungsänderungen, Ressourcen-Zugriffe) erfassen die Audit-Logs der Plattform — siehe Observability und Audit-Logs.

Best Practices

Principle of Least Privilege: nur die minimal notwendigen Berechtigungen gewähren.
Regelmäßige Audits: Workflows regelmäßig auf Sicherheitslücken prüfen.
Credential Rotation: Credentials regelmäßig rotieren.
Monitoring: auf verdächtige Aktivitäten überwachen.

Häufige Sicherheitsfehler

Fehler	Lösung
Hardcodierte Credentials in Code oder Node-Parametern	Credential Store verwenden, Workflow-Exporte auf versehentlich enthaltene Secrets prüfen, Secrets niemals in Git committen
Unverschlüsselte Verbindungen (HTTP statt HTTPS)	Immer HTTPS verwenden, SSL-Zertifikate validieren, TLS 1.2+ nutzen
Fehlende Input-Validierung	Alle Inputs validieren, Whitelisting nutzen, User-Input sanitizen

Weiterführend: Sub-Processors und Compliance-Dokumente.

Grundlagen

Localmind anbinden

Workflows

Erweitert

Betrieb

Credential-Management

Webhook-Sicherheit

Header Auth (empfohlen)

HMAC-Signatur

Basic Auth

Replay-Schutz

Webhook-Sicherheits-Checkliste

Input-Validierung

SQL-Injection verhindern

Audit und Nachvollziehbarkeit

Best Practices

Häufige Sicherheitsfehler

​Credential-Management

​Webhook-Sicherheit

​Header Auth (empfohlen)

​HMAC-Signatur

​Basic Auth

​Replay-Schutz

​Webhook-Sicherheits-Checkliste

​Input-Validierung

​SQL-Injection verhindern

​Audit und Nachvollziehbarkeit

​Best Practices

​Häufige Sicherheitsfehler

Credential-Management

Webhook-Sicherheit

Header Auth (empfohlen)

HMAC-Signatur

Basic Auth

Replay-Schutz

Webhook-Sicherheits-Checkliste

Input-Validierung

SQL-Injection verhindern

Audit und Nachvollziehbarkeit

Best Practices

Häufige Sicherheitsfehler