OpenClaw-Sicherheitskonfiguration: Fünf Verteidigungsebenen von Docker-Sandbox bis Berechtigungskontrolle

Kurzfassung (zuerst die Antwort)

Wenn Sie nur drei Dinge tun, drücken Sie die meisten Hochrisiko-Szenarien bei OpenClaw zunächst runter:

1. Erzwingen Sie Authentifizierung (Token/Passwort) und begrenzen Sie den Zugang;
2. Container-Sandbox + Nicht-Root + Least Privilege;
3. Hochrisiko-Tools per Whitelist, sensible Befehle standardmäßig ablehnen.

Wenn diese drei Schritte stehen, ergänzen Sie Audit und Netzwerkisolation schrittweise – dort ist der Sicherheitsgewinn am höchsten.

Um drei Uhr nachts bat ein Entwickler auf Reddit um Hilfe. Er hatte OpenClaw auf seinem MacBook installiert, zwei Wochen lang mit Standardeinstellungen betrieben und war zufrieden. Bis er OpenClaw bat: „Hilf mir, die Projektdateien der letzten Zeit zu sortieren“ – und die KI las nebenbei ~/.ssh/ und ~/.aws/, zeigte in der Antwort freundlich den Inhalt seines privaten Schlüssels.

Schlimmer noch: Das Gespräch wurde in seine Arbeitsgruppe synchronisiert.

Ehrlich gesagt lief mir beim ersten Lesen dieses Falls kalt den Rücken runter. OpenClaw ist ein mächtiger KI-Assistent – Shell-Befehle, Dateizugriff, Browsersteuerung. Falsch konfiguriert ist das wie ein Fremder mit dem Hausschlüssel.

Vielleicht denken Sie: Ich nutze es nur privat, das passt schon.

Genau hier liegt das Problem. OpenClaw-Risiken kommen nicht nur von externen Angriffen, sondern auch von Prompt Injection (bösartige Anweisungen im Chat), Konfigurationsfehlern (versehentlich exponierter API-Port) oder der „Übereifer“ der KI (Aufräumen wird zu Löschen wichtiger Daten).

Das lässt sich vermeiden – mit der richtigen Konfiguration.

Dieser Artikel zeigt Schritt für Schritt, wie Sie OpenClaw in einen „Sicherheitskäfig“ setzen – von Docker-Sandbox bis feingranularer Berechtigungskontrolle. Die Konfiguration wirkt aufwendig; verglichen mit Datenleck oder versehentlichem Löschen der Datenbank ist der Aufwand gering.

Günstig „Garnelen züchten“: ArkClaw macht KI-Agenten alltagstauglich

OpenClaw (der „Hummer“) ist stark, die Einrichtung aber mühsam? ByteDance Volcano Engine bietet ArkClaw mit minimalem Setup: ohne Server- und Token-Fummelei, ein Klick – 24/7 online, Browser, Skripte, Kalender.

Preis: 9,9 ¥/Monat; mit Einladungscode ZLKUK54M (Registrierung) 8,9 ¥. Entwickler: Coding Plan Pro kann kostenlos nutzbar sein.

Warum Sicherheitskonfiguration nötig ist

Wie weitreichend sind OpenClaw-Berechtigungen?

Zuerst eine nüchterne Tatsache: OpenClaw ist kein reiner Chatbot – es kann im Wesentlichen alles, was Sie im Terminal können:

• Beliebige Shell-Befehle: rm -rf /? Technisch möglich.
• Ganzes Dateisystem lesen/schreiben: SSH-Schlüssel, AWS-Credentials, DB-Passwörter – alles auf der Platte ist erreichbar.
• Netzwerkressourcen: APIs, Downloads, sogar interne Port-Scans.
• Browsersteuerung: per Playwright, inklusive eingeloggter Sites.
• Umgebungsvariablen: alles in process.env liegt offen.

Standardrechte für OpenClaw sind wie ein Universal-Schlüssel für einen sehr klugen Assistenten, den Sie noch nicht gut kennen.

Wie gefährlich ist die Standardkonfiguration?

Viele installieren mit npm install -g openclaw und starten direkt openclaw gateway (oder nur den Daemon). Wissen Sie, was standardmäßig passiert?

Vor v2026.1.29:

• Zugriffskontrolle konnte auth: none sein – jeder mit Ihrer URL kontrollierte OpenClaw.
• Keine Sandbox – voller Dateisystemzugriff.
• Alle Tools standardmäßig an, inkl. exec und browser.
• Betrieb mit hohen Rechten, teils als root.

"Ab v2026.1.29 wurde auth: none entfernt – Token- oder Passwort-Authentifizierung ist Pflicht"

Ab v2026.1.29 etwas besser: auth: none entfällt, Token oder Passwort sind Pflicht. Sandbox, Tool-Rechte und Dateisystemzugriff müssen Sie aber weiter manuell härten.

Ehrlich: Standardkonfiguration ist wie offene Haustür und ein Schild „Willkommen“.

Drei Ziele der Sicherheitskonfiguration

Wofür der ganze Aufwand? Drei Kernpunkte:

1. Least Privilege: Nur Rechte, die OpenClaw wirklich braucht. Code schreiben? Lese-/Schreibzugriff auf den Workspace – kein Browser, dann browser aus.

2. Defense in Depth: Nicht alles auf eine Linie setzen. Docker-Isolation, Nicht-Privileg-Benutzer, Zugriffskontrolle, Tool-Whitelist, Netzwerkisolation – fällt eine Ebene, halten andere.

3. Kontrollierbarer Schaden: Worst Case – Prompt Injection, Token-Leak, KI-Bug – wie groß ist der Schaden? Nur isolierter Workspace statt ganzes /home.

Sicherheitskonfiguration verhindert Angriffe nicht vollständig, macht sie aber teuer und begrenzt den Schaden.

Fünf Ebenen der Sicherheitskonfiguration

Praxis von unten nach oben – jeweils mit Begründung und Verifikation.

Erste Ebene: Docker-Sandbox (Pflicht)

Warum Docker?

Docker dient nicht nur dem Deployment. Bei hochprivilegierten Apps wie OpenClaw ist Isolation der Hauptgewinn:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

• Dateisystem: KI sieht nur Container-Dateien – ~/.ssh auf dem Host bleibt außen vor.
• Netzwerk: kein Internet oder nur erlaubte Domains.
• Ressourcen: keine Endlosschleife, die die CPU verbrennt.
• Recovery: Problem? docker rm, in Sekunden sauberer Neustart.

Frage: Brauche ich das lokal?

Ja. Lokal ist es riskanter – GitHub-Token, DB-Passwörter, API-Keys sind Ziele für Prompt Injection.

Konfiguration

1. Sicheres Dockerfile

FROM openclaw/gateway:latest

# Nicht-privilegierter Benutzer
RUN adduser --disabled-password --gecos '' clawuser

# Wechsel zu Nicht-Root
USER clawuser

# Arbeitsverzeichnis
WORKDIR /home/clawuser/openclaw

Entscheidend: USER clawuser. Standard-Container laufen als root – OpenClaw hätte root im Container. Ein dedizierter User begrenzt Schaden nach Container-Breakout auf clawuser.

2. Docker Compose mit Sicherheitsparametern

version: '3.8'
services:
  openclaw-gateway:
    build: .
    container_name: openclaw-safe

    # Sicherheit
    security_opt:
      - no-new-privileges:true  # Keine Rechteerhöhung im Container
    cap_drop:
      - ALL  # Alle Linux-Capabilities entfernen
    cap_add:
      - NET_BIND_SERVICE  # Nur Port-Bindung

    # Schreibgeschütztes Root-FS
    read_only: true

    # Temporäre schreibbare Verzeichnisse
    tmpfs:
      - /tmp
      - /home/clawuser/openclaw/temp

    # Ressourcenlimits
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
        reservations:
          cpus: '1.0'
          memory: 2G

    # Netzwerkisolation
    networks:
      - openclaw-isolated

    # Volumes (minimal)
    volumes:
      # Workspace (RW)
      - ./workspace:/home/clawuser/workspace
      # Config (RO)
      - ./config:/home/clawuser/openclaw/config:ro
      # Logs (nur Schreiben)
      - ./logs:/home/clawuser/openclaw/logs

networks:
  openclaw-isolated:
    driver: bridge
    internal: true  # Kein externer Netzwerkzugriff

Warum so?

• no-new-privileges:true: kein sudo/setuid-Escalation im Container.
• cap_drop: ALL: minimale Capabilities, nur Nötiges zurück (z. B. Port binden).
• read_only: true: kein Backdoor-Install, kein System-File-Write; Schreibbedarf über tmpfs.
• internal: true: kein Internet – sinnvoll bei rein lokaler Verarbeitung, verhindert Exfiltration.

3. OpenClaw-Sandbox-Modus

Hauptkonfiguration meist in ~/.openclaw/openclaw.json (JSON). YAML unten nur Struktur-Analogie – Feldnamen siehe offizielle Gateway-Doku. Eigenes GitOps-Repo mit config/config.yaml ist Repo-Naming, nicht Upstream-Default.

sandbox:
  mode: "non-main"  # Alle Gruppenchats in isolierten Containern
  docker:
    enabled: true
    network: "none"  # Kein Netz in Sandbox-Containern

mode: "non-main": außer Ihrem Hauptchat laufen Dialoge in eigenen Docker-Containern – Prompt Injection bleibt im Mini-Sandbox.

Verifikation

# Nicht-Root im Container?
docker exec openclaw-safe whoami
# Erwartet: clawuser

# Schreibgeschütztes Root-FS?
docker exec openclaw-safe touch /test.txt
# Erwartet: Read-only file system

# Netzwerkisolation?
docker exec openclaw-safe ping 8.8.8.8
# Erwartet: Network is unreachable

Bestehen alle drei Tests, steht Ebene eins.

Zweite Ebene: Nicht-privilegierter Betrieb (Pflicht)

Nicht-Root im Container reicht nicht, wenn auf dem Host root docker-compose up startet – nach Escape bleibt root auf dem Host.

Lösung: dedizierter Low-Privilege-User auf dem Host

# Gruppe und User
sudo groupadd -r openclaw
sudo useradd -r -g openclaw -d /opt/openclaw -s /bin/bash clawuser

# Verzeichnisstruktur
sudo mkdir -p /opt/openclaw/{workspace,config,logs,temp}

# Rechte
sudo chown -R clawuser:openclaw /opt/openclaw
sudo chmod 700 /opt/openclaw/config  # Config nur Owner RW
sudo chmod 755 /opt/openclaw/workspace
sudo chmod 750 /opt/openclaw/logs

# Passwort-Login sperren
sudo usermod -L clawuser

Warum chmod 700?

Nur Owner darf lesen/schreiben/ausführen. Config enthält Token und Passwörter – streng absichern.

Credential-Dateien (sehr wichtig!)

Bei WhatsApp o. Ä.:

# Nur Owner RW (600)
chmod 600 ~/.openclaw/credentials/whatsapp/*/creds.json
chmod 700 ~/.openclaw

644 (weltlesbar) – Credentials wurden schon von anderen Usern auf demselben Server gelesen. Vermeiden Sie das.

Verifikation

# Prozess-User
ps aux | grep openclaw
# clawuser, nicht root

# Dateirechte
ls -la /opt/openclaw/config
# drwx------ clawuser openclaw

Warum wichtig?

Worst Case: Container-Breakout, Sandbox umgangen, beliebiger Code – Angreifer hat nur clawuser:

• Keine fremden User-Dateien
• Kein Systemsoftware-Install ohne sudo
• Kein /etc-Write
• Kein /root-Read

Defense in Depth: eine Ebene fällt, die nächste schützt.

Dritte Ebene: Zugriffskontrolle und Authentifizierung (Pflicht)

Ebene 1–2: was OpenClaw darf. Ebene 3: wer es nutzen darf.

Änderung ab v2026.1.29

Früher erlaubte auth: none – Katastrophe. Ab v2026.1.29 ist Token oder Passwort Pflicht.

Gateway-Token-Authentifizierung

Token vs. Passwort: verschiedene Token für Personen/Apps, unterschiedliche Rechte; Leak eines Tokens → nur dieses widerrufen.

In ~/.openclaw/openclaw.json (Gateway-Abschnitt; YAML nur Illustration):

gateway:
  # Token-Pflicht
  auth: token

  tokens:
    - name: "admin-token"
      value: "${OPENCLAW_ADMIN_TOKEN}"  # Aus Env, nicht hardcoden!
      permissions:
        - "admin"

    - name: "readonly-token"
      value: "${OPENCLAW_READONLY_TOKEN}"
      permissions:
        - "chat"
        - "read"
      # Kein exec, browser usw.

Sicheres Token erzeugen

Kein 123456 oder mytoken:

openssl rand -base64 32

export OPENCLAW_ADMIN_TOKEN="generiertes-token"
export OPENCLAW_READONLY_TOKEN="anderes-token"

Nicht hardcoden: Config landet in Git, Logs, Backups. Umgebungsvariablen sind relativ sicherer.

Zugriffs-Whitelist

# DM
dmPolicy: allowlist
allowFrom:
  - "user_id_1"
  - "user_id_2"

# Gruppen
groupPolicy: allowlist
allowFrom:
  - "group_id_1"

# Nur bei @ in Gruppen
mentionGating: true

publicAccess: false

mentionGating: true: in 100-Personen-Gruppe sonst jede Nachricht → Kosten und Prompt-Angriffe. Mit Gating nur bei @.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Verifikation

# Ohne Auth (soll scheitern)
curl -X POST http://localhost:3000/api/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# 401 Unauthorized

# Mit Token
curl -X POST http://localhost:3000/api/chat \
  -H "Authorization: Bearer ${OPENCLAW_ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# 200 OK

Warum kritisch?

Ohne Zugriffskontrolle nützen Isolation und Rechte nichts – direkter API-Zugriff ohne Docker-Escape.

Diese Ebene ist der Türsteher.

Vierte Ebene: Tool-Berechtigungen (empfohlen)

OpenClaw ist im Käfig, hat aber noch viele Werkzeuge – gefährliche einschränken.

Problem: alle Tools standardmäßig an

Dutzende Tools: exec, browser, write_file, web_fetch … alles an.

Brauchen Sie alles? Nur Code und Recherche? browser und exec können aus.

Tool-Whitelist

tools:
  allowlist:
    - "read_file"
    - "write_file"
    - "web_search"
    - "git"
    # Kein exec, browser

  exec:
    enabled: false

  browser:
    enabled: false

  web_fetch:
    enabled: true
    allowedDomains:
      - "github.com"
      - "api.anthropic.com"
      - "*.npmjs.com"

exec nötig? Befehls-Whitelist

tools:
  exec:
    enabled: true
    sandbox: true

    allowCommands:
      - "git"
      - "npm"
      - "yarn"
      - "pytest"
      - "curl"

    denyCommands:
      - "rm -rf"
      - "sudo"
      - "chmod 777"
      - "dd if="
      - "mkfs"
      - "> /dev/sda"

Whitelist schlägt Blacklist: Angriffe sind unendlich variabel, sichere Befehle sind begrenzt und listbar.

Dateisystem-Limits

filesystem:
  allowedPaths:
    - "/home/clawuser/workspace"
    - "/home/clawuser/projects"

  deniedPaths:
    - "/home/clawuser/.ssh"
    - "/home/clawuser/.aws"
    - "/home/clawuser/.config"
    - "/etc"
    - "/root"

  defaultPermission: "readonly"

  writablePaths:
    - "/home/clawuser/workspace/temp"

Prompt „lies ~/.ssh/id_rsa“ → abgelehnt.

Verifikation

Im Chat testen:

• Sie: „Führe sudo apt update aus“ → blockiert durch Sicherheitsrichtlinie
• Sie: „Lies ~/.ssh/id_rsa“ → Access denied

Fünfte Ebene: Netzwerkisolation und Monitoring (fortgeschritten)

Für Enterprise, sensible Daten oder maximale Härtung.

Netzwerk: unnötige Verbindungen trennen

internal: true blockiert Internet – OpenClaw braucht aber Claude API.

Proxy mit Domain-Whitelist

# docker-compose.yml
services:
  openclaw-gateway:
    environment:
      - HTTP_PROXY=http://allowlist-proxy:8080
      - HTTPS_PROXY=http://allowlist-proxy:8080
    networks:
      - openclaw-isolated

  allowlist-proxy:
    image: squid:latest
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro
    networks:
      - openclaw-isolated
      - external  # Nur Proxy ins Internet

squid.conf:

acl allowed_domains dstdomain .anthropic.com
acl allowed_domains dstdomain .github.com
acl allowed_domains dstdomain .npmjs.com

acl SSL_ports port 443
acl CONNECT method CONNECT

http_access allow allowed_domains
http_access deny all

access_log /var/log/squid/access.log

Nur diese Domains – Prompt-Injection „lade Skript“ scheitert am Proxy.

Audit-Logs

logging:
  level: "info"

  auditLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/audit.log"
    format: "json"

    logToolCalls: true
    logFileAccess: true
    logNetworkRequests: true
    logPrompts: true

  sessionLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/sessions/"

logPrompts: true erkennt Injection wie „ignoriere vorherige Limits …“.

Live-Monitoring

tail -f /opt/openclaw/logs/audit.log | grep -E "(exec|sudo|rm|chmod)"

docker exec openclaw-safe netstat -tuln

docker stats openclaw-safe

Alerts

alerts:
  - type: "command_execution"
    pattern: "sudo|rm -rf|chmod 777"
    action: "block_and_notify"

  - type: "file_access"
    pattern: "/.ssh/|/.aws/|/etc/passwd"
    action: "block_and_notify"

  - type: "network_request"
    pattern: ".*\\.onion|torproject\\.org"
    action: "block_and_notify"

E-Mail, Slack oder Dienst pausieren.

Strategie: mit Leserechten starten

Nach fünf Ebenen: nicht alles sofort voll öffnen.

Sicherheit und Komfort balancieren. Zu streng → OpenClaw nutzlos. Zu locker → kein Schutz.

Besser: streng starten, schrittweise lockern.

Woche 1: reiner Lesemodus

tools:
  allowlist:
    - "read_file"
    - "web_search"
    - "git_log"

filesystem:
  defaultPermission: "readonly"
  writablePaths: []

Beobachten: welche Dateien, Logs, Tools, Prompt-Injection-Tests in sicherer Umgebung.

Ruhige Woche → Basis ok. Versuche auf .ssh → Config oder Angriff prüfen.

Woche 2: eingeschränktes Schreiben

filesystem:
  writablePaths:
    - "/home/clawuser/workspace/temp"

tools:
  allowlist:
    - "write_file"
    - "git_commit"

Nur Temp-Verzeichnis schreibbar – Quellcode bleibt geschützt. „Projekt aufräumen“ als Alles-löschen trifft nur Temp.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Woche 3+: Tools nach Bedarf

tools:
  exec:
    enabled: true
    sandbox: true
    allowCommands:
      - "git"
      - "npm test"

Prinzipien:

• Pro Schritt eine Freigabe
• 24 Stunden Logs prüfen
• Bei Verdacht sofort zurückrollen

Praxis: meine Evolution

Erst „volle Sicherheit“ aus der Doku – OpenClaw konnte nicht mal Code ergänzen, write_file war aus.

Dann schrittweise:

• Woche 1: Lesemodus, Docs und Code-Erklärung – ok.
• Woche 2: Schreiben in workspace/drafts – ok.
• Woche 3: git – Git-User fehlte, Commits scheiterten, danach ok.
• Woche 4: npm test – reichte für mich.

browser und unbegrenztes exec – nie gebraucht, nie an.

Lektion: keine Rechte „für gutes Gefühl“, die Sie nicht nutzen. Nach Bedarf öffnen.

Sicherheits-Checkliste

Vor dem Deployment (alles abhaken)

Container:

• ☐ Nicht-privilegierter User im Container
• ☐ no-new-privileges:true
• ☐ cap_drop: ALL
• ☐ read_only: true
• ☐ CPU-/RAM-Limits
• ☐ OpenClaw-Sandbox aktiv

Authentifizierung:

• ☐ Starkes Token (kein auth: none)
• ☐ ≥32 Zeichen, zufällig
• ☐ Token in Env, nicht im Code
• ☐ DM/Group-Whitelist
• ☐ Auf VPS: IP-Whitelist

Berechtigungen:

• ☐ Tool-Whitelist
• ☐ exec/browser aus oder Befehls-Whitelist
• ☐ Dateisystem-Limits
• ☐ .ssh, .aws verboten
• ☐ Credentials 600

Audit:

• ☐ Audit-Log an
• ☐ Session-Log an
• ☐ Log-Speicher ok
• ☐ Log-Analyse bekannt

Laufend (regelmäßig)

Wöchentlich:

• ☐ Audit-Log auf Anomalien
• ☐ Ressourcen CPU/RAM/Disk
• ☐ Unbefugte Zugriffsversuche
• ☐ Config-Backup

Monatlich:

• ☐ OpenClaw-Update
• ☐ Token-Rotation
• ☐ docker scan
• ☐ Rechte-Review, Unnötiges entfernen

Notfall

Stop-Skript:

#!/bin/bash
# emergency-stop.sh

echo "OpenClaw Notfall-Stopp..."

docker stop openclaw-safe

# Token widerrufen (dynamisches Auth-System)
# curl -X DELETE https://your-auth-server/tokens/revoke-all

curl -X POST https://your-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"text":"OpenClaw wurde notgestoppt"}'

echo "Gestoppt. Logs: /opt/openclaw/logs/audit.log"

Token-Leak:

1. Token sofort widerrufen
2. Audit: was wurde gemacht?
3. Neues Token, legitime Nutzer informieren
4. Bei Datenleck: Incident-Plan

Verdächtige Aktivität:

1. Nicht sofort abschalten (Spuren verwischen)
2. Logs und Container-Snapshot sichern
3. Pfad und Impact analysieren
4. Dann isolieren, neu starten oder rebuild

Fazit

Kernbotschaft: OpenClaw ist mächtig – in einem sicheren Käfig wird aus dem „Raubtier“ ein nützlicher Assistent.

Fünf Ebenen:

1. Docker-Sandbox: Container, begrenzte Dateien und Netz
2. Nicht-privilegierter User: niedrige Rechte bei Angriff
3. Zugriffskontrolle: Token + Whitelist
4. Tool-Kontrolle: gefährliche Tools aus
5. Netzwerk und Monitoring: Verbindungen begrenzen, alles protokollieren

Erste drei Pflicht, letzte zwei stark empfohlen bei sensiblen Daten.

Konfiguration ist mühsam – aber nötig. Nicht weil OpenClaw unsicher ist, sondern weil KI-Fähigkeiten enorm sind. „Projekt sortieren“ kann „Temp-Dateien löschen“ inkl. wichtiger Drafts bedeuten. „Letzte Commits“ kann .git/config-Credentials lesen.

Keine Bosheit – „Übereifer“ mit gleichem Schaden.

Sicherheit begrenzt den Unfallradius.

Drei Schritte:

1. Jetzt Config prüfen – bei Defaults mindestens die ersten drei Ebenen.
2. Streng starten, lockern nach Bedarf – eine Woche Lesemodus.
3. Audit wöchentlich – fünf Minuten reichen.

OpenClaw ist ein gutes Werkzeug – wie Kernenergie: richtig genutzt nützlich, falsch katastrophal.

Der Aufwand ist geringer als Datenleck, DB-Verlust oder ein Reddit-Hilferuf.

Stimmt’s?

Weiterlesen

• 5 Sicherheitsschalter in der OpenClaw-Erstkonfiguration
• OpenClaw-Konfiguration im Detail: Vollständiger openclaw.json-Leitfaden
• OpenClaw 2026 Installationsleitfaden: Deployment von null