> ## Documentation Index
> Fetch the complete documentation index at: https://docs.localmind.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Sicherheit

> Security-Best-Practices für Automate-Workflows

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.

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

**Abgrenzung: Org-Zugangsdaten.** Der Automate Credential Store ist unabhängig von den [Zugangsdaten](/settings/organization/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

<Warning>
  Webhooks ohne Authentifizierung sind ein Sicherheitsrisiko. Implementieren Sie immer mindestens eine Authentifizierungsmethode.
</Warning>

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.

<Steps>
  <Step title="Authentifizierung aktivieren">
    Öffnen Sie den Webhook-Node und wählen Sie unter **Authentication** die Option **Header Auth**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

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

<CodeGroup>
  ```bash Custom Header theme={null}
  curl -X POST https://your-webhook-url \
    -H "X-API-Key: your-secret-api-key" \
    -H "Content-Type: application/json" \
    -d '{"data": "value"}'
  ```

  ```bash Authorization-Header (Bearer) theme={null}
  curl -X POST https://your-webhook-url \
    -H "Authorization: Bearer your-secret-token" \
    -H "Content-Type: application/json" \
    -d '{"data": "value"}'
  ```
</CodeGroup>

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.

<CodeGroup>
  ```javascript HMAC-Validierung (Code-Node) theme={null}
  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 } }];
  ```

  ```bash cURL mit Signatur theme={null}
  # 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"}'
  ```
</CodeGroup>

<Note>
  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.
</Note>

### 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.

```bash cURL Beispiel theme={null}
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.

```javascript Timestamp-Check (Code-Node) theme={null}
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.

```javascript Nonce-Check (Code-Node) theme={null}
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:

```javascript Input-Validierung (Code-Node) theme={null}
// 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.

<CodeGroup>
  ```javascript Sicher (Parameterized) theme={null}
  const query = 'SELECT * FROM users WHERE id = ?';
  const result = await db.query(query, [userId]);
  ```

  ```javascript Unsicher (SQL-Injection Risiko) theme={null}
  const query = `SELECT * FROM users WHERE id = ${userId}`;
  // NIEMALS SO!
  ```
</CodeGroup>

## 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](/automate/debugging).
* **Localmind-Audit-Logs:** Sicherheitsrelevante Ereignisse Ihrer Organisation (Logins, Berechtigungsänderungen, Ressourcen-Zugriffe) erfassen die Audit-Logs der Plattform — siehe [Observability](/administration/observability) und [Audit-Logs](/settings/instance/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](/compliance/Sub-Processors) und [Compliance-Dokumente](/compliance/documents).