Sicherheits-Bewährte-Verfahren

Claude Codes Sicherheitsmechanismen vollständig beherrschen — Rechtekontrolle, Schutz sensibler Dateien, Befehlsabfangung, API-Key-Verwaltung

Sicherheits-Bewährte-Verfahren¶

Claude Code ist ein leistungsfähiger KI-Programmierassistent, doch „leistungsfähig“ bedeutet auch, dass er hohe Systemrechte erfordert — Dateien lesen und schreiben, Befehle ausführen, auf das Netzwerk zugreifen. Das ist vergleichbar mit einem Praktikanten, dem man Admin-Zugang gibt: kompetent, aber Sicherheitsgrenzen sind unabdingbar.

Dieses Dokument hilft Ihnen, eine umfassende Sicherheitsabwehr aufzubauen — von der persönlichen Nutzung bis zur Teamzusammenarbeit, von Entwicklungsumgebungen bis zur CI/CD-Automatisierung — damit Sie die Effizienz des KI-Programmierens genießen, ohne in Sicherheitsfallen zu tappen.

Das Sicherheitsmodell von Claude Code verstehen¶

Claude Code läuft in Ihrem Terminal¶

Das ist entscheidend und die Grundlage für das Verständnis aller Sicherheitsmaßnahmen: Claude Code läuft nicht in einer Cloud-Sandbox, sondern direkt in Ihrem lokalen Terminal.

Das bedeutet:

• Es kann jede Datei auf Ihrem Rechner lesen (sofern Ihr Benutzer die Berechtigung hat)
• Es kann jeden Shell-Befehl ausführen
• Es kann auf Ihre Umgebungsvariablen zugreifen (einschließlich etwa enthaltener Secrets)
• Es kann über das Netzwerk Daten senden und empfangen

Natürlich verfügt Claude Code über eingebaute Sicherheitsmechanismen, die diese Fähigkeiten einschränken. Dennoch sollten Sie sich diesen grundlegenden Fakt stets vor Augen halten: Die maximalen Berechtigungen sind Ihre Benutzerberechtigungen.

Berechtigungs-Genehmigungsmechanismus¶

Die zentrale Sicherheitsphilosophie von Claude Code ist Human in the Loop. Standardmäßig bittet es vor der Ausführung folgender Operationen um Ihre Bestätigung:

• Erste Verwendung eines Tools
• Ausführung von Shell-Befehlen (insbesondere solche, die Sie nicht vorab genehmigt haben)
• Anlegen neuer Dateien oder Änderung bestehender Dateien
• Zugriff auf Netzwerkressourcen

Die Berechtigungsanfragen sehen etwa so aus:

Claude wants to run: rm -rf node_modules && npm install

Allow?
  (y) Yes, allow once
  (a) Always allow "npm install" commands
  (n) No, deny

Grundprinzip: Wenn Sie sich nicht sicher sind, ob eine Operation sicher ist, wählen Sie „No“. Sie können sie später immer noch genehmigen, sobald Sie die Situation durchschaut haben.

Drei Verteidigungslinien¶

Das Sicherheitssystem von Claude Code besteht aus drei Verteidigungslinien:

First Line: Permission Mode (Global Policy)
  ↓
Second Line: Allow/Deny Rules (Fine-grained Control)
  ↓
Third Line: Hooks (Custom Interception Logic)

Wir behandeln jede einzelne im Folgenden.

Berechtigungskonfiguration¶

Vergleich der vier Berechtigungsmodi¶

Claude Code bietet vier Berechtigungsmodi, von höchster bis niedrigster Sicherheitsstufe:

Detaillierte Erläuterung der einzelnen Modi:

plan-Modus: Claude kann nur Code durchsuchen und lesen, keinerlei Änderungen vornehmen. Geeignet für Szenarien, in denen Sie Claude den Code analysieren lassen möchten, aber keine Veränderungen wünschen. Wechseln Sie mit Shift+Tab in diesen Modus.

default-Modus: Der empfohlene Alltagsmodus. Claude fragt beim ersten Verwenden eines Tool-Typs nach; nachdem Sie genehmigt haben, werden ähnliche Operationen nicht erneut abgefragt. Shell-Befehle erfordern immer eine Bestätigung.

acceptEdits-Modus: Vertraut Claudes Dateibearbeitungsfähigkeiten, bleibt aber bei der Befehlsausführung wachsam. Geeignet, wenn Sie umfangreiche Änderungen an Code-Dateien durch Claude benötigen, aber nicht möchten, dass es beliebige Befehle ausführt.

bypassPermissions-Modus: Überspringt alle Berechtigungsprüfungen. Verwenden Sie dies nur, wenn Sie der aktuellen Aufgabe vollständig vertrauen oder sich in einer isolierten CI/CD-Umgebung befinden.

Anzeigen und Ändern über /permissions¶

Sie können jederzeit /permissions in Claude Code eingeben, um den aktuellen Berechtigungsstatus anzuzeigen:

/permissions

Die Ausgabe zeigt den aktuellen Modus, genehmigte Tools, Allow/Deny-Regeln und mehr.

Berechtigungskonfiguration in settings.json¶

Die Berechtigungskonfiguration wird in settings.json gespeichert und ist in zwei Ebenen unterteilt:

Benutzerebene (betrifft alle Projekte): ~/.claude/settings.json Projektebene (betrifft nur das aktuelle Projekt): .claude/settings.json

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test:*)",
      "Bash(git status)",
      "Bash(git add:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(node:*)",
      "Bash(python:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)"
    ]
  }
}

Erklärung der Regelsyntax:

Wichtig: Deny-Regeln haben Vorrang vor Allow-Regeln. Selbst wenn Sie eine Operation in Allow genehmigt haben, wird sie trotzdem abgelehnt, wenn sie auch einer Deny-Regel entspricht.

Schutz sensibler Dateien¶

Sensible Verzeichnisse mit .claudeignore ausschließen¶

Die Syntax der Datei .claudeignore entspricht der von .gitignore. Aufgelistete Dateien und Verzeichnisse sind für Claude Code vollständig unsichtbar:

Erstellen Sie .claudeignore im Projektstammverzeichnis:

# Environment variables and keys
.env
.env.*
secrets/
*.pem
*.key
*credentials*

# Sensitive configuration
config/production.yml
config/secrets.yml

# Personal data
data/users/
*.sqlite
*.db

# Other sensitive directories
.aws/
.ssh/
.gnupg/

Hinweis: .claudeignore macht Claude diese Dateien vollständig unzugänglich – es weiß nicht einmal, dass diese Dateien existieren. Dies geht weiter als Deny-Regeln.

Sensible Dateien mit Hooks vor Änderungen schützen¶

Wenn Sie möchten, dass Claude bestimmte Dateien lesen, aber nicht ändern kann, können Sie Hooks für eine feingranulare Steuerung verwenden:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 -c \"\nimport sys, json, os\ntool_input = json.loads(os.environ.get('TOOL_INPUT', '{}'))\npath = tool_input.get('file_path', '') or tool_input.get('path', '')\nprotected = ['.env', 'credentials', 'secret', '.pem', '.key']\nfor p in protected:\n    if p in path.lower():\n        print(f'BLOCKED: Modification of files containing {p} is not allowed', file=sys.stderr)\n        sys.exit(2)\n\""
          }
        ]
      }
    ]
  }
}

Dieser Hook prüft den Dateipfad, bevor Claude versucht, eine Datei zu schreiben oder zu bearbeiten. Enthält der Pfad sensible Schlüsselwörter, wird die Operation blockiert (Exit-Code 2 bedeutet Blockierung).

Vorlage für Schutzkonfiguration¶

Für Teamprojekte empfiehlt es sich, eine Standard-Sicherheitskonfigurationsdatei anzulegen, die im Repository gespeichert wird:

// .claude/settings.json (committed to Git)
{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Write(.git/**)",
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(git reset --hard:*)",
      "Bash(chmod 777:*)",
      "Bash(curl|wget:*)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$TOOL_INPUT\" | python3 -c \"import sys,json; cmd=json.load(sys.stdin).get('command',''); blocked=['DROP TABLE','DELETE FROM','TRUNCATE','password','token','secret']; [sys.exit(2) for b in blocked if b.lower() in cmd.lower()]\""
          }
        ]
      }
    ]
  }
}

Sicherheit bei der Befehlsausführung¶

Verhalten des Bash-Tools verstehen¶

Claude Code führt Shell-Befehle über das Bash-Tool aus. Standardmäßig ist jede Ausführung – außer bei zuvor genehmigten Befehlen – bestätigungspflichtig.

Einige zu beachtende Verhaltensweisen:

• Befehle werden in Ihrer aktuellen Shell-Umgebung ausgeführt
• Umgebungsvariablen sind für Befehle sichtbar
• Befehle können das Dateisystem verändern
• Befehle können Software installieren
• Befehle können auf das Netzwerk zugreifen

Welche Befehle automatisch genehmigt werden¶

Wenn Sie ein Befehlsmuster zur allow-Liste in settings.json hinzufügen, werden passende Befehle automatisch ausgeführt, ohne eine Abfrage auszulösen.

Empfohlene vorab genehmigte sichere Befehle:

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(git branch:*)",
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(head:*)",
      "Bash(tail:*)",
      "Bash(wc:*)",
      "Bash(find:*)",
      "Bash(grep:*)",
      "Bash(npm run lint:*)",
      "Bash(npm run test:*)",
      "Bash(python -m pytest:*)"
    ]
  }
}

Blockierung gefährlicher Befehle¶

Die folgenden Befehle sollten stets auf der Deny-Liste stehen und niemals automatisch ausgeführt werden:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(rm -r /:*)",
      "Bash(git push --force:*)",
      "Bash(git push -f:*)",
      "Bash(git reset --hard:*)",
      "Bash(git checkout -- .:*)",
      "Bash(git clean -f:*)",
      "Bash(chmod 777:*)",
      "Bash(chown:*)",
      "Bash(dd:*)",
      "Bash(mkfs:*)",
      "Bash(shutdown:*)",
      "Bash(reboot:*)"
    ]
  }
}

Benutzerspezifische Befehlsblockierung über Hooks¶

Für komplexere Blockierungslogik verwenden Sie Hooks:

Beispiel 1: Alle Befehle mit Netzwerkzugriff blockieren

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$TOOL_INPUT\" | python3 -c \"\nimport sys, json\ncmd = json.load(sys.stdin).get('command', '')\nnet_cmds = ['curl', 'wget', 'nc ', 'netcat', 'ssh ', 'scp ', 'rsync']\nfor nc in net_cmds:\n    if nc in cmd:\n        print(f'BLOCKED: Network commands are not allowed ({nc})', file=sys.stderr)\n        sys.exit(2)\n\""
          }
        ]
      }
    ]
  }
}

Beispiel 2: Alle Befehle in ein Audit-Log schreiben

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$(date '+%Y-%m-%d %H:%M:%S') [Bash] $TOOL_INPUT\" >> ~/.claude/audit.log"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$(date '+%Y-%m-%d %H:%M:%S') [FileChange] $TOOL_INPUT\" >> ~/.claude/audit.log"
          }
        ]
      }
    ]
  }
}

Damit erhalten Sie ein vollständiges Operations-Audit-Log, auf das Sie jederzeit zurückgreifen können, um nachzuvollziehen, was Claude Code getan hat.

API Key-Sicherheit¶

API Keys nicht in CLAUDE.md hartkodieren¶

Dies ist der häufigste Sicherheitsfehler. Die Datei CLAUDE.md wird typischerweise in das Git-Repository committet, und Claude Code liest sie bei jedem Start. Enthält sie einen API-Key, dann:

1. Der Key wird in den Git-Verlauf committet (auch wenn er später gelöscht wird)
2. Der Key ist für Claude Code sichtbar und kann in Logs oder Analyseergebnissen auftauchen
3. Andere Teammitglieder können diesen Key alle einsehen

Falscher Ansatz:

<!-- CLAUDE.md -->
## API Configuration
Database connection: postgresql://admin:P@ssw0rd@localhost:5432/mydb
OpenAI Key: sk-xxxxxxxxxxxxxxxxxxxx

Richtiger Ansatz:

<!-- CLAUDE.md -->
## API Configuration

- Database connection and API Keys are managed via .env file
- .env file is not committed to Git (already in .gitignore)
- New developers need to copy .env.example and fill in their own credentials

Umgebungsvariablen zur Key-Verwaltung nutzen¶

Empfohlener Ansatz für die Key-Verwaltung:

# .env (not committed to Git)
DATABASE_URL=postgresql://admin:P@ssw0rd@localhost:5432/mydb
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx
REDIS_URL=redis://localhost:6379

# .env.example (committed to Git, without actual values)
DATABASE_URL=postgresql://user:password@localhost:5432/dbname
OPENAI_API_KEY=sk-your-key-here
REDIS_URL=redis://localhost:6379

Stellen Sie sicher, dass .env sowohl in .gitignore als auch in .claudeignore eingetragen ist:

# .gitignore
.env
.env.local
.env.production

# .claudeignore (if you don't want Claude to read .env)
.env
.env.*

Schritte nach Offenlegung eines API Keys¶

Wenn Sie vermuten, dass ein API-Key offengelegt wurde (z. B. versehentlich in Git committet), führen Sie umgehend die folgenden Schritte aus:

1. Rotate the key immediately

   - Go to the corresponding service's console to generate a new API Key
   - Update all environment variables using that Key

2. Remove from Git history
   git filter-branch --force --index-filter \
     "git rm --cached --ignore-unmatch .env" \
     --prune-empty --tag-name-filter cat -- --all

   Or use the safer BFG Repo-Cleaner:
   bfg --delete-files .env
   git reflog expire --expire=now --all
   git gc --prune=now --aggressive

3. Force push the cleaned history
   git push --force --all

4. Check for abnormal usage

   - Review API usage logs for any abnormal calls
   - Check billing records for any abnormal charges

5. Notify the team

   - Inform all developers to re-clone the repository
   - Update keys in all deployment environments

Sicherheitsrichtlinien für Teams¶

settings.json-Vorlage teilen¶

Erstellen Sie eine einheitliche Sicherheits-Baseline-Konfiguration für das Team, die in .claude/settings.json des Projekts committet wird:

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm run:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(python -m pytest:*)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/*credential*)",
      "Write(.git/**)",
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(git reset --hard:*)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(ssh:*)",
      "Bash(scp:*)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$(date -Iseconds) TOOL_USE: $TOOL_INPUT\" >> .claude/audit.log"
          }
        ]
      }
    ]
  }
}

Teammitglieder können persönliche Konfiguration in ~/.claude/settings.json (Benutzerebene) hinzufügen, aber projektseitige Deny-Regeln können nicht überschrieben werden.

Sicherheitskonfiguration in CI/CD¶

Wenn Sie Claude Code in CI/CD-Umgebungen (Headless-Modus) verwenden, ist die Sicherheitskonfiguration noch wichtiger:

# GitHub Actions example
name: AI Code Review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:

      - uses: actions/checkout@v4

      - name: Run Claude Code Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          claude --print --dangerously-skip-permissions \
            "Please review the code changes in this PR, providing feedback on security and code quality" \
            < /dev/null

CI/CD-Sicherheitsaspekte:

Sicherheitsaspekte des Headless-Modus¶

Der Headless-Modus (--print oder -p) wird für nicht-interaktive Szenarien ohne menschliche Bestätigung verwendet. Hier ist besondere Vorsicht geboten:

# Safe Headless usage — read-only operations
claude --print "Analyze the code structure in the src/ directory"

# For write operations, limit to specific files
claude --print "Fix the type error in src/utils.py"

# Be clearly aware of the risks when using --dangerously-skip-permissions
claude --print --dangerously-skip-permissions "Run npm test"

Der Grund, warum --dangerously-skip-permissions so einen langen Parameternamen hat, ist, dass es Sie daran erinnern soll: Das Überspringen von Berechtigungsprüfungen ist gefährlich. Verwenden Sie es nur, wenn Sie den Eingabe-Prompt vollständig kontrollieren und die möglichen Operationen genau kennen.

Enterprise-Sicherheit¶

Netzwerkzugriffskontrolle¶

Wenn Ihr Unternehmen strenge Netzwerksicherheitsrichtlinien hat, können Sie den Netzwerkzugriff von Claude Code auf folgende Weise steuern:

1. Proxy-Konfiguration

HTTP-Proxy über Umgebungsvariablen einstellen, sodass alle Netzwerkanfragen über den Proxy laufen und so leichter geprüft und gesteuert werden können:

# Set in .bashrc or .zshrc
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.com

2. Firewall-Regeln

Auf der Unternehmens-Firewall können Sie Claude Code den Zugriff auf nur die erforderlichen Domains erlauben:

# Domains that must be allowed
api.anthropic.com         # Anthropic API
*.claude.ai               # Claude services

# Optional allows (based on features used)
registry.npmjs.org         # npm package installation
pypi.org                   # Python package installation
github.com                 # Git operations

3. Netzwerk-Befehle in settings.json deaktivieren

Als zusätzliche Sicherheitsebene können Sie gängige Netzwerk-Tools über Deny-Regeln blockieren:

{
  "permissions": {
    "deny": [
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(nc:*)",
      "Bash(ssh:*)",
      "Bash(scp:*)",
      "Bash(rsync:*)",
      "Bash(ftp:*)",
      "Bash(telnet:*)"
    ]
  }
}

Protokollprüfung¶

Für Unternehmen mit höheren Compliance-Anforderungen empfiehlt es sich, ein vollständiges Audit-Protokollierungssystem einzurichten:

1. Operationsprotokolle

Alle Tool-Aufrufe über Hooks protokollieren:

{
  "hooks": {
    "PreToolUse": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 -c \"\nimport json, os, datetime\nlog_entry = {\n    'timestamp': datetime.datetime.now().isoformat(),\n    'user': os.environ.get('USER', 'unknown'),\n    'tool': os.environ.get('TOOL_NAME', 'unknown'),\n    'input': os.environ.get('TOOL_INPUT', '')[:500]\n}\nwith open(os.path.expanduser('~/.claude/audit.jsonl'), 'a') as f:\n    f.write(json.dumps(log_entry, ensure_ascii=False) + '\\n')\n\""
          }
        ]
      }
    ]
  }
}

2. Sitzungsprotokolle

Claude Code selbst speichert den Sitzungsverlauf im Verzeichnis ~/.claude/. Unternehmen können diese Protokolle regelmäßig sichern.

3. Änderungsverfolgung

In Kombination mit Git gibt es für alle Dateiänderungen vollständige Verfolgungsdatensätze. Es wird empfohlen, dass Änderungen durch Claude Code auf separaten Branches erfolgen und über den PR-Prozess zusammengeführt werden.

Compliance-Aspekte¶

Die Nutzung von KI-Programmierungstools kann folgende Compliance-Fragen betreffen:

Datensicherheit

Geistiges Eigentum

• Ausgaben von Claude Code (generierter Code) gehören dem Nutzer
• Beachten Sie, dass generierter Code urheberrechtlich geschützte Inhalte enthalten kann
• Für geschäftskritischen Code wird eine menschliche Überprüfung vor der Verwendung empfohlen

Branchen-Compliance

• Regulierten Branchen wie Finanzwesen und Gesundheitswesen können zusätzliche KI-Nutzungsbeschränkungen auferlegt sein
• Prüfen Sie, ob Ihre Organisation Richtlinien zur Nutzung von KI-Tools hat
• Bewahren Sie Audit-Protokolle auf, um Compliance-Prüfanforderungen zu erfüllen

Schnellreferenz für Sicherheitskonfiguration¶

Hier abschließend eine Schnellreferenz-Checkliste für die Sicherheitskonfiguration:

Minimale Sicherheitskonfiguration für Einzelpersonen¶

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)"
    ]
  }
}

Empfohlene Konfiguration für Teamprojekte¶

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm run:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Read(**/*.pem)",
      "Write(.git/**)",
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(git reset --hard:*)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}

Hochsicherheits-Enterprise-Konfiguration¶

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test)",
      "Bash(git status)",
      "Bash(git diff)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/*credential*)",
      "Read(**/*password*)",
      "Write(.git/**)",
      "Write(.github/**)",
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Bash(git reset:*)",
      "Bash(git checkout -- :*)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(ssh:*)",
      "Bash(scp:*)",
      "Bash(nc:*)",
      "Bash(python -c:*)",
      "Bash(node -e:*)",
      "Bash(eval:*)",
      "Bash(exec:*)",
      "Bash(sudo:*)",
      "Bash(chmod:*)",
      "Bash(chown:*)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 -c \"import json,os,datetime; f=open(os.path.expanduser('~/.claude/audit.jsonl'),'a'); f.write(json.dumps({'ts':datetime.datetime.now().isoformat(),'user':os.environ.get('USER','?'),'tool':os.environ.get('TOOL_NAME','?'),'input':os.environ.get('TOOL_INPUT','')[:500]},ensure_ascii=False)+'\\n'); f.close()\""
          }
        ]
      }
    ]
  }
}

Häufig gestellte Fragen¶

F: Sendet Claude Code meinen Code an die Server von Anthropic?

A: Claude Code kommuniziert über die API mit Anthropic, und der Kontext einer Konversation (einschließlich der von Ihnen referenzierten Code-Snippets) wird als Teil von API-Anfragen gesendet. Anthropic verwendet jedoch keine Daten, die über die API übermittelt werden, zum Trainieren von Modellen (gemäß den Nutzungsbedingungen von Anthropic). Wenn Sie Claude Code über einen Relay-Dienst wie QCode nutzen, beachten Sie bitte die Datenschutzerklärung dieses Dienstes.

F: Kann Claude Deny-Regeln in settings.json umgehen?

A: Bei normaler Nutzung: nein. Deny-Regeln werden auf Systemebene durchgesetzt, und Claude kann sie weder durch Prompt Engineering noch auf andere Weise umgehen. Wenn Sie jedoch manuell den bypassPermissions-Modus wählen oder den Parameter --dangerously-skip-permissions verwenden, finden diese Regeln keine Anwendung mehr.

F: Worin unterscheidet sich .claudeignore von Deny-Regeln?

A: .claudeignore sorgt dafür, dass Claude die Existenz von Dateien gar nicht erst wahrnimmt (vergleichbar mit der Funktionsweise von .gitignore für Git), während Deny-Regeln den Zugriff verweigern, wenn Claude versucht, auf Dateien zuzugreifen. Verwenden Sie .claudeignore, wenn Sie nicht möchten, dass Claude bestimmte Dateien kennt; verwenden Sie Deny-Regeln, wenn Sie lediglich nicht möchten, dass Claude sie verändert.

F: Was passiert bei Teamzusammenarbeit, wenn alle unterschiedliche settings.json haben?

A: Die projektweite .claude/settings.json wird in Git eingecheckt und stellt sicher, dass das Team eine einheitliche Sicherheitsgrundlage teilt. Einzelne Personen können in ihrer persönlichen ~/.claude/settings.json zusätzliche Konfiguration hinzufügen, aber die projektweiten Deny-Regeln nicht überschreiben.

F: Ist es sicherer, Claude Code in einem Docker-Container auszuführen?

A: Ja. Docker bietet eine zusätzliche Isolierungsschicht, sodass selbst bei unerwarteten Aktionen von Claude Code die Auswirkungen auf den Container beschränkt bleiben. Empfohlene Praktiken in Containern: Quellcode-Verzeichnisse nur schreibgeschützt mounten, Netzwerkzugriff einschränken, Ausführung als Nicht-Root-Benutzer.

MCP-Sicherheit & Sandboxing¶

MCP (Model Context Protocol) ermöglicht es Claude Code, sich mit externen Tools und Datenquellen zu verbinden – Datenbanken, APIs, Dateisysteme, Drittanbieterdienste und mehr. Das erweitert die Möglichkeiten erheblich, bringt aber auch eine neue Klasse von Sicherheitsrisiken mit sich: Jeder MCP-Server, den Sie hinzufügen, bringt ein Stück Drittanbietercode und die von ihm deklarierten Tool-Berechtigungen in Ihre Vertrauensgrenze ein. Informationen zur Konfiguration und Nutzung von MCP finden Sie unter MCP-Server-Konfiguration; dieser Abschnitt konzentriert sich auf Sicherheit.

Von MCP ausgehende Hauptrisiken¶

• Datenexfiltration: Ein bösartiger oder kompromittierter MCP-Server kann lesen, was Sie ihm übergeben (Code, Dateien, Konversationskontext), und dies unbemerkt an ein externes Ziel senden.
• Tool Poisoning: Ein Server verbirgt Anweisungen in der Beschreibung oder den Metadaten eines Tools, um das Modell zu unbeabsichtigten Aktionen zu verleiten – eine Form von Prompt Injection, die auf AI-Tool-Aufrufe abzielt.
• Zugangsdaten-Leak: Wenn ein Server auf Umgebungsvariablen oder geheime Dateien zugreifen kann, kann er API-Keys, Tokens und andere sensible Zugangsdaten ausspähen.
• Übermäßige Tool-Berechtigungen: Ein Server, der destruktive Tools wie „delete“, „write“ oder „execute commands“ deklariert, kann bei einem Fehlverhalten irreversible Schäden anrichten.

Gegenmaßnahmen¶

• Nur vertrauenswürdige Quellen installieren: Installieren Sie MCP-Server ausschließlich aus offiziellen oder geprüften Quellen, und bewerten Sie deren Vertrauenswürdigkeit wie bei jeder anderen Drittanbieterabhängigkeit.
• Tool-Scopes jedes Servers prüfen: Prüfen Sie vor dem Verbinden jedes vom Server deklarierte Tool und was es tun kann, und behandeln Sie „Lesen“, „Schreiben“ und „Ausführen“ mit unterschiedlicher Vorsicht.
• Menschliche Freigabe beibehalten: Claude Code bittet vor dem Aufruf eines Tools um Ihre Bestätigung. Bei destruktiven Operationen und Tools, die Zugangsdaten berühren, sollten Sie nicht pauschal freigeben, sondern die Freigabe für jede Nutzung einzeln beibehalten.
• Zugriff auf Geheimnisse per Sandbox blockieren: Nutzen Sie die Konfiguration sandbox.credentials, um zu verhindern, dass Befehle in der Sandbox Umgebungsvariablen und Geheimdateien lesen. So kann selbst ein manipuliertes Tool keine Zugangsdaten erlangen.
• Minimale Rechte: Geben Sie jedem MCP-Server nur die minimale Menge an Tools und den minimalen Zugriffsumfang, die er für seine Aufgabe braucht – öffnen Sie nicht aus Bequemlichkeit alles.
• Prüfen und protokollieren: Protokollieren Sie Tool-Aufrufe und prüfen Sie regelmäßig, welche Server aufgerufen werden und was sie getan haben, damit auffälliges Verhalten früh erkannt wird.

Behandeln Sie jeden MCP-Server wie einen externen Auftragnehmer, der mit seinem eigenen Werkzeugkasten hereinkommt: Prüfen Sie zuerst seine Identität, begrenzen Sie dann, was er anfassen darf, und behalten Sie sich das Recht vor, jede Aktion zu bestätigen. So nutzen Sie die erweiterten Möglichkeiten von MCP und wahren zugleich Ihre Sicherheitsgrenze.