# Sicherheit

## Ueberblick

Neotask ist mit einer Security-First-Architektur konzipiert. Das Gateway bindet standardmaessig an localhost, alle sensiblen Daten werden im Ruhezustand verschluesselt, und die Agenten-Ausfuehrung kann in isolierten Containern sandboxed werden.

## Netzwerksicherheit

### Loopback als Standard

Das Gateway hoert nur auf `127.0.0.1` (localhost), es sei denn, Sie aendern den Bindungsmodus explizit. Keine externe Netzwerkexposition standardmaessig.

### Authentifizierung

Alle WebSocket-Verbindungen erfordern Authentifizierung:

- **Token-Auth** -- Bearer-Token (UUID oder benutzerdefinierte Zeichenkette)
- **Passwort-Auth** -- Bcrypt-gehashtes Passwort
- **Trusted Proxy** -- Vorab authentifizierte Header von Reverse-Proxys
- **Local Trust** -- Loopback-Verbindungen werden implizit vertraut

### Remote-Zugriffssicherheit

Fuer Remote-Zugriff ist der empfohlene Ansatz **Tailscale VPN** oder **SSH-Tunneling** -- setzen Sie das Gateway nie direkt dem Internet aus.

## Geraetekopplung

### Wie Kopplung funktioniert

Jeder Client, der sich mit dem Gateway verbindet, muss gekoppelt werden:

1. Geraet praesentiert seine Identitaet (Fingerprint + oeffentlicher Schluessel)
2. Gateway sendet eine Kopplungs-Challenge (Nonce)
3. Geraet signiert die Nonce mit seinem privaten Schluessel
4. Sie genehmigen das Geraet ueber die Benutzeroberflaeche
5. Gateway stellt ein Geraete-Token fuer zukuenftige Verbindungen aus

### Vertrauensmodell

- **Lokale Geraete** (Loopback) werden der Bequemlichkeit halber automatisch genehmigt
- **Nicht-lokale Geraete** erfordern explizite Genehmigung
- Geraete-Tokens werden lokal gespeichert und bei Wiederverbindung wiederverwendet
- Geraete koennen jederzeit widerrufen werden

## Verschluesselung

### Daten im Ruhezustand

- **AES-256-GCM** -- Alle Tokens, Secrets und API-Schluessel werden im Ruhezustand verschluesselt
- **Maschinenabgeleitete Schluessel** -- Verschluesselungsschluessel ueber scrypt von der Geraeteidentitaet abgeleitet
- **Keine Klartextspeicherung** -- Tokens werden nie im Klartext gespeichert

### Daten waehrend der Uebertragung

- **TLS** -- HTTPS fuer API-Kommunikation
- **WSS** -- WebSocket Secure fuer Gateway-Verbindungen (bei Verwendung von Tailscale Serve oder Reverse Proxy)
- **HMAC-Signierung** -- Anfrage-Integritaet mit Nonce und Zeitstempel

## Sandboxing

### Docker-basierte Isolation

Agenten-Befehlsausfuehrung kann in Docker-Containern sandboxed werden:

- **Pro-Agent-Profile** -- Jeder Agent kann seine eigene Sandbox-Konfiguration haben
- **Ressourcenlimits** -- Konfigurierbare CPU-, Speicher- und Timeout-Limits
- **Netzwerkisolation** -- Container koennen netzwerkisoliert werden
- **Dateisystembeschraenkung** -- Agenten greifen nur auf ihren Workspace zu
- **Benutzerdefinierte Images** -- Vorgefertigte Images mit bestimmten installierten Tools verwenden

### Sandbox-Scopes

| Scope | Beschreibung |
|-------|-------------|
| **Per-Session** | Frischer Container fuer jede Session |
| **Per-Agent** | Persistenter Container pro Agent |
| **Shared** | Geteilter Container ueber Agenten hinweg |

### Workspace-Zugriff

Sandboxed Agenten koennen auf ihr Workspace-Verzeichnis zugreifen (in den Container eingehaengt), aber nicht auf das Host-Dateisystem ausserhalb ihres Workspaces.

## Exec-Genehmigungen

Steuern Sie, welche Befehle Agenten auf Nodes und dem Gateway-Host ausfuehren koennen:

### Modi

| Modus | Beschreibung |
|------|-------------|
| **Allowlist** | Nur vorab genehmigte Befehle werden ausgefuehrt |
| **Ask** | Unbekannte Befehle erfordern Benutzergenehmigung |
| **Full** | Keine Einschraenkungen (mit Vorsicht verwenden) |

### Pro-Node-Konfiguration

Jeder Node (macOS, Headless-Host) hat seine eigene Exec-Genehmigungskonfiguration, lokal gespeichert. Sie koennen bestimmte Binaerdateien erlauben (z.B. `/usr/bin/docker`, `/usr/local/bin/terraform`) und alles andere blockieren.

## Elevated Mode

Einige Operationen erfordern die Ausfuehrung direkt auf dem Gateway-Host (nicht in einer Sandbox). Der Elevated Mode ist:

- Durch explizite Berechtigung in der Agent-Konfiguration eingeschraenkt
- Nur auf dem Gateway-Host verfuegbar
- Standardmaessig deaktiviert
- Durch Protokollierung ueberpruefbar

## Sicherheits-Audit

Die integrierte Sicherheitspruefung untersucht:

- Konfigurationsdatei-Berechtigungen (sollten 600 sein)
- Session-Datei-Berechtigungen
- Node.js-Version (Sicherheitspatches)
- Klartext-Secret-Erkennung
- Plugin-Allowlist-Validierung
- Offene Netzwerk-Interface-Pruefung
- Auth-Konfiguration-Vollstaendigkeit

Die Pruefung kann viele Probleme automatisch beheben, wenn die Berechtigung erteilt wird.

## Best Practices

1. **Gateway auf Loopback belassen** -- Tailscale oder SSH fuer Remote-Zugriff verwenden
2. **Sandboxing aktivieren** -- Agentenbefehle in Docker-Containern ausfuehren
3. **Exec-Allowlists verwenden** -- Einschraenken, welche Befehle Agenten auf Nodes ausfuehren koennen
4. **Auth-Tokens setzen** -- Immer Token-Auth konfigurieren, auch fuer Loopback
5. **Agent-Berechtigungen ueberpruefen** -- Wo moeglich minimale Tool-Profile verwenden
6. **Neotask aktuell halten** -- Updates enthalten Sicherheitspatches
7. **Regelmaessig pruefen** -- Sicherheits-Audits durchfuehren, um Fehlkonfigurationen zu erkennen
8. **Plugin-Laden einschraenken** -- Nur vertrauenswuerdige Plugins installieren