Claude Code Sicherheits-Best-Practices: API-Schlüssel, Berechtigungen & Produktionsschutz

Claude Code verfügt über leistungsstarke Dateimanipulations- und Befehlsausführungsfähigkeiten — aber falsche Konfiguration kann zu irreversiblen Unfällen führen. Eine .env-Datei committen, versehentlich eine Produktionsdatenbank löschen, einen API-Schlüssel in Logs ausgeben — das sind reale Vorfälle, die durch den ungeschützten Einsatz von Claude Code entstanden sind.

Dieser Artikel bietet eine implementierungsnahe Erklärung der Sicherheits-Best-Practices für Claude Code. Der Fokus liegt nicht auf Theorie, sondern auf kopierfertige Konfigurationen und präventivem Code.

Warum Claude Code Sicherheitsmaßnahmen benötigt

Anders als ein normaler Texteditor hat Claude Code folgende Fähigkeiten:

• Beliebige Dateien lesen, schreiben und löschen (Read / Write / Edit / Bash(rm))
• Shell-Befehle ausführen (Bash)
• Netzwerkzugriff (WebFetch / API-Aufrufe)
• An externe Dienste posten (GitHub, Slack, etc.)

All das kann mit Benutzerbestätigung ausgeführt werden. Das Problem: Wer mechanisch jeden Prompt bestätigt, lässt unbeabsichtigte Operationen durch. Sicherheitsmaßnahmen bedeuten, strukturell keinen Raum für Fehler zu lassen.

Maßnahme 1: API-Schlüsselverwaltung — .env + .gitignore als Grundlage

Was man NICHT tun sollte

// ❌ Direkt im Quellcode
const client = new Anthropic({ apiKey: "PASTE_REAL_API_KEY_HERE" });

// ❌ In CLAUDE.md oder Konfigurationsdateien geschrieben
// ANTHROPIC_API_KEY=PASTE_REAL_API_KEY_HERE

// ❌ Im Prompt von claude -p angegeben
// Verwende QIITA_TOKEN=PASTE_REAL_TOKEN_HERE zum Posten

Der richtige Ansatz

# .env (aus git ausgeschlossen, nur lokal auf dem Rechner)
ANTHROPIC_API_KEY=<anthropic-api-key>
QIITA_TOKEN=<qiita-token>
SLACK_BOT_TOKEN=<slack-bot-token>
DATABASE_URL=postgresql://...

# Unbedingt zu .gitignore hinzufügen
.env
.env.*
.env.local
!.env.example   # ← Beispieldatei darf committet werden
*.pem
*.key
credentials.json
*-service-account.json

# .env.example (sicher zu committen, Werte leer lassen)
ANTHROPIC_API_KEY=
QIITA_TOKEN=
SLACK_BOT_TOKEN=
DATABASE_URL=

Variablen im Code lesen

// ✅ Aus Umgebungsvariablen lesen
import { config } from "dotenv";
config();

const token = process.env.QIITA_TOKEN;
if (!token) throw new Error("QIITA_TOKEN ist nicht gesetzt. Bitte .env-Datei prüfen.");

Verbote in CLAUDE.md dokumentieren

## Sicherheitsverbote
- API-Schlüssel oder Tokens niemals in Prompts einbeziehen
- Den Inhalt von .env-Dateien niemals lesen und ausgeben
- Werte von Umgebungsvariablen niemals in Logs oder Kommentare schreiben
- Den Inhalt von process.env niemals per console.log ausgeben

Maßnahme 2: Pre-Commit-Scan auf Geheimnisse

Auch mit .env in .gitignore können versehentliche Einträge in anderen Dateien oder Copy-Paste-Fehler auftreten. Fügen Sie einen automatischen Pre-Commit-Scan hinzu.

Pre-Commit-Prüfung mit Hooks

.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit*)",
        "hooks": [
          {
            "type": "command",
            "command": "node scripts/secret-scan.mjs"
          }
        ]
      }
    ]
  }
}

scripts/secret-scan.mjs:

import { execSync } from "child_process";

// Gestagete Änderungen abrufen
const diff = execSync("git diff --cached").toString();

const PATTERNS = [
  { name: "Anthropic API-Schlüssel-Zuweisung", re: /\b(?:ANTHROPIC_API_KEY|CLAUDE_API_KEY)\s*[:=]\s*["']?[^"'\s]{20,}/i },
  { name: "OpenAI API-Schlüssel-Zuweisung", re: /\bOPENAI_API_KEY\s*[:=]\s*["']?[^"'\s]{20,}/i },
  { name: "AWS Access Key", re: /\bAKIA[0-9A-Z]{16}\b/ },
  { name: "Slack Token", re: /\bxox[baprs]-[0-9A-Za-z-]{10,}\b/ },
  { name: "Generisches Geheimnis", re: /\b(?:secret|token|api[_-]?key|password)\s*[:=]\s*["'][^"']{10,}["']/i },
];

const found = PATTERNS.filter(({ re }) => re.test(diff));

if (found.length > 0) {
  console.error("🚨 Geheimnis erkannt! Commit wird abgebrochen:");
  found.forEach(({ name }) => console.error(`  - ${name}`));
  console.error("\nLösung: `git reset HEAD <file>` ausführen, um die Datei zu unstagen");
  process.exit(1);  // Exit-Code 1 → Hook blockiert den Befehl
}

console.log("✓ Geheimnis-Scan: Keine Probleme gefunden");
process.exit(0);

Das bedeutet: Sobald Claude Code versucht, git commit auszuführen, läuft automatisch ein Scan und erkannte Lecks werden blockiert.

Maßnahme 3: Konfiguration der Berechtigungsmodi

Die Erlaubnis-/Ablehnungseinstellungen von Claude Code können auf Dateiebene detailliert gesteuert werden.

Berechtigungseinstellungen in .claude/settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(DROP TABLE*)",
      "Bash(truncate*)",
      "Bash(curl * | bash)",
      "Bash(wget * | sh)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(npm publish*)",
      "Bash(wrangler pages deploy*)"
    ]
  },
  "disableAutoMode": "disable"
}

Einstellung	Bedeutung
allow	Ohne Bestätigung ausführen
deny	Niemals ausführen (vollständig blockiert)
ask	Erfordert jedes Mal eine Genehmigung

Grundprinzip: Destruktive Befehle in deny, Schreiboperationen in ask, Leseoperationen in allow.

Produktion und Organisationsrichtlinien mit local oder managed settings trennen

Das offizielle Konfigurationsmodell wendet Scopes in dieser Reihenfolge an: managed, Kommandozeilenargumente, local, project, dann user. Statt sich auf ein inoffizielles Umschalten über eigene Dateien zu verlassen, nutzen Sie .claude/settings.local.json für ein strengeres persönliches Produktions-Terminal und managed settings für Organisationsregeln.

Verwenden Sie .claude/settings.local.json für lokale Overrides und committen Sie die Datei nicht.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan",
    "disableBypassPermissionsMode": "disable",
    "allow": ["Read(**)", "Glob(**)", "Grep(**)", "Bash(git log*)", "Bash(git diff*)"],
    "deny": ["Write(**)", "Edit(**)", "Bash(git push*)", "Bash(rm*)", "Bash(*deploy*)"],
    "ask": []
  },
  "disableAutoMode": "disable"
}

Für Team- oder Unternehmensrichtlinien gehört dieselbe Grenze in managed settings. Mit allowManagedPermissionRulesOnly können Benutzer und Projekt-Repositories keine eigenen allow-, ask- oder deny-Regeln definieren, um die Organisationsrichtlinie zu umgehen.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "disableAutoMode": "disable",
  "allowManagedPermissionRulesOnly": true
}

Maßnahme 4: Schutz der Produktionsumgebung

Verbindungsziele explizit trennen

## CLAUDE.md — Regeln für die Produktionsumgebung

## Umgebungserkennung
- Enthält DATABASE_URL 'prod' oder 'production', handelt es sich um eine **Produktionsumgebung**
- In der Produktion niemals ausführen:
  - DROP / TRUNCATE / DELETE (ohne WHERE-Klausel)
  - Migrationen (vorherige Bestätigung erforderlich)
  - Massenhafte Dateilöschungen

## Bestätigungsablauf
Alle Produktionsänderungen müssen:
1. Zuerst in einer Staging-Umgebung getestet werden
2. Benutzerbestätigung erhalten
3. Ergebnisse nach der Ausführung berichten

Verbindungen mit Umgebungsvariablen steuern

// scripts/db-query.mjs
const env = process.env.NODE_ENV ?? "development";
const dbUrl = process.env.DATABASE_URL;

if (env === "production" && process.argv.includes("--write")) {
  console.error("❌ Schreiben in Produktion erfordert das Flag --force-production");
  process.exit(1);
}

Maßnahme 5: Sicherheitsmechanismen für Dateioperationen

Backups vor dem Löschen automatisieren

// Hooks in .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(rm *)",
        "hooks": [
          {
            "type": "command",
            "command": "echo '⚠️  Ein Löschbefehl wird gleich ausgeführt. Drücken Sie Ctrl+C zum Abbrechen.' && sleep 3"
          }
        ]
      }
    ]
  }
}

Kritische Dateien vor versehentlichen Bearbeitungen schützen

## CLAUDE.md — Dateien, die nicht geändert werden dürfen

Folgende Dateien dürfen **niemals bearbeitet** werden:
- .env (enthält Umgebungsvariablen und geheime Schlüssel)
- wrangler.toml (Cloudflare-Produktionskonfiguration)
- scripts/deploy.sh (Deployment-Skript)
- .github/workflows/*.yml (CI/CD-Konfiguration)

Falls Änderungen notwendig sind, zuerst den Benutzer fragen.

5 häufige Fallstricke

1. .gitignore nachträglich hinzufügen ist zu spät Eine bereits committete .env-Datei bleibt in der Git-Historie, auch wenn man sie später zur .gitignore hinzufügt.

# Vollständige Entfernung aus der Historie (Achtung: Force-Push erforderlich)
git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch .env" \
  --prune-empty --tag-name-filter cat -- --all

# Alternativ BFG Repo Cleaner verwenden

Wenn die Datei bereits auf GitHub gepusht wurde, immer zuerst die API-Schlüssel rotieren, bevor die Historie bereinigt wird.

2. Service-Account-JSON-Dateien im Repository ablegen Service-Account-Schlüssel für Google Cloud oder AWS werden oft als .json-Dateien verteilt, aber sie im Repository zu speichern ist gefährlich. Konvertieren Sie sie in Umgebungsvariablen oder migrieren Sie zu einem Secret Manager (AWS Secrets Manager / GCP Secret Manager).

3. Interaktive Befehle mit dem Bash-Tool ausführen Bei der headlosen Ausführung mit claude -p führen Befehle, die interaktive Eingabe erfordern (wie sudo oder vim), zum Hängen des Prozesses. Verwenden Sie nur nicht-interaktive Befehle.

4. Anmeldeinformationen in Fehlermeldungen einbeziehen

// ❌ Gefährlich: API-Schlüssel erscheint in Logs
throw new Error(`Authentifizierung fehlgeschlagen: token=${process.env.TOKEN}`);

// ✅ Sicher: Wert nicht preisgeben
throw new Error(`Authentifizierung fehlgeschlagen: bitte TOKEN-Umgebungsvariable prüfen`);

5. Dieselben Berechtigungseinstellungen für alle Projekte wiederverwenden Werden dieselben settings.json für persönliche und geschäftliche Projekte verwendet, können die lockeren Einstellungen des persönlichen Projekts die strengeren Anforderungen des Geschäftsprojekts überschreiben. Verwalten Sie .claude/settings.json für jedes Projekt separat.

Praktische Betriebsregeln

Keine Secrets im normalen Arbeitsfluss preisgeben

Wenn Sie Claude Code bitten, “diesen Fehler zu beheben”, kopieren Sie nicht den vollständigen Log oder den Inhalt von .env. Legen Sie vorher fest, dass API-Schlüssel, OAuth-Tokens, Cookies, Datenbank-URLs, Kunden-E-Mails, Rechnungs-IDs und private Schlüssel nie in Prompts, Issues oder Chats eingefügt werden.

Wenn Claude Code Kontext braucht, maskieren Sie Werte und lassen nur die Struktur stehen. DATABASE_URL=***REDACTED*** reicht aus, damit Claude Code erkennt, dass eine Datenbank-URL existiert. Der echte Wert ist für die meisten Code-Debugging-Aufgaben nicht nötig.

Zulässige Informationen	Nicht übergeben
Fehlertyp, Dateinamen im Stack Trace, Reproduktionsschritte	API-Schlüssel, private Schlüssel, Session-Cookies, echte .env-Werte
.env.example, Setting-Namen, Berechtigungsregeln, fehlgeschlagener Befehl	Produktionsdatenbank-URLs, Kundendaten, interne Zugangsdaten
Maskierte Logs, Testdaten, lokale Beispielwerte	Echte Tokens, Service-Account-JSON, Screenshots mit Secrets

Nehmen Sie diese Tabelle in CLAUDE.md auf, damit jede Sitzung mit derselben Grenze beginnt. In Teams muss “keine Secrets preisgeben” eine Betriebsregel sein, kein implizites Wissen.

Secret-Scanning vor dem Commit doppelt absichern

Der obige PreToolUse Hook blockiert einen Commit, wenn Claude Code git commit ausführt. Er deckt aber nicht ab, dass ein Mensch aus einem anderen Terminal committet oder CI Dateien mit Secrets erzeugt. In Produktivteams sollten drei Schichten zusammenarbeiten: Claude Code Hook, lokaler pre-commit Scan und ein CI Secret Scan, der den Merge blockiert.

Das minimale sinnvolle Setup lautet: lokal blockieren, in CI erneut prüfen und den Pull Request fehlschlagen lassen, wenn ein Secret-Pattern auftaucht. Tools wie gitleaks oder trufflehog eignen sich besser für CI-Erkennung; das Script aus diesem Artikel bleibt als schneller lokaler Schutz nützlich.

Konkrete Fehlerbeispiele

Fehler 1: .env während der Untersuchung lesen lassen Ein Entwickler bat Claude Code, “die Umgebungsvariablen zu prüfen”, und echte Werte landeten in Konversation oder Arbeitslogs. Die Lösung ist, das Lesen von .env zu verbieten und nur .env.example bereitzustellen.

Fehler 2: Qiita-Publishing-Token in den Prompt kopieren Eine Automatisierungsaufgabe enthielt QIITA_TOKEN direkt im Prompt, wodurch ein Subagent oder Log ihn speichern konnte. Sicherer ist, das Token in .env zu halten und Befehle nur den Namen der Umgebungsvariablen referenzieren zu lassen.

Fehler 3: Produktions- und Staging-DB-URLs sehen ähnlich aus Die Anweisung lautete nur “Datenbank aufräumen” und übersprang die Verbindungsprüfung. War die Produktions-URL aktiv, konnte ein Delete oder eine Migration zum Incident werden. Vor Schreiboperationen sollten NODE_ENV, Host und Datenbankname ausgegeben und eine explizite Bestätigung verlangt werden.

Erste Schritte nach einem Incident

Wenn ein Secret möglicherweise geleakt wurde, ist der erste Schritt nicht die History-Bereinigung. Der erste Schritt ist das Deaktivieren des Credentials.

1. Betroffenen API-Schlüssel, Token oder Passwort sofort rotieren oder widerrufen
2. GitHub Actions, Cloudflare, AWS, GCP und verbundene SaaS-Audit-Logs prüfen
3. Festhalten, wer was, wann, in welchem Repository und über welchen Kanal offengelegt hat
4. Secret aus Git-Historie und Logs entfernen und Auswirkungen eines Force Push kommunizieren
5. deny-Regeln, Hooks, CI-Scans und CLAUDE.md-Verbote verschärfen

In der Praxis reduziert es Fehler, zuerst das Credential zu stoppen und danach die Historie zu säubern. Während eines Incidents werden oft weitere Logs gepostet; bereiten Sie daher vorab eine Vorlage für maskierte Logs vor.

Weg zu Training und Beratung

Claude Code Sicherheit ist nicht mit einer einzelnen Settings-Datei erledigt. Repository-Struktur, CI, Deployment-Berechtigungen und Team-Freigabeprozess müssen ebenfalls betrachtet werden.

Bei ClaudeCodeLab beginnt der Lernpfad für Einzelentwickler mit .env-Hygiene und permission rules. In Teamberatungen klären wir zuerst, wo managed settings erzwungen werden und wo der CI Secret Scan Merges blockieren muss. Wenn Claude Code bereits im Unternehmen genutzt wird, starten Sie mit einer Übersicht, wer auf welche Secrets zugreifen kann, bevor Sie Detailberechtigungen feinjustieren.

Sicherheits-Checkliste

Eine Checkliste für die Einrichtung eines Claude Code-Projekts:

### Grundkonfiguration
- [ ] .env erstellt und zu .gitignore hinzugefügt
- [ ] .env.example erstellt und mit dem Team geteilt
- [ ] Per git log überprüft, ob in bestehenden Commits keine Geheimnisse enthalten sind

### Berechtigungseinstellungen
- [ ] Deny-Liste in .claude/settings.json konfiguriert
- [ ] Destruktive Befehle (rm -rf, DROP TABLE usw.) zu deny hinzugefügt
- [ ] Produktions-Deployment-Befehle auf ask gesetzt

### Automatisierung
- [ ] Pre-Commit-Geheimnis-Scan-Hook konfiguriert
- [ ] Sicherheitsverbote in CLAUDE.md dokumentiert

### Betrieb
- [ ] API-Schlüssel-Rotationsplan festgelegt (Empfehlung: alle 90 Tage)
- [ ] Produktionsarbeit mit .claude/settings.local.json oder managed settings eingeschränkt
- [ ] Incident-Response-Prozess dokumentiert

Zusammenfassung

Sicherheit bei Claude Code bedeutet nicht „Einschränkungen auferlegen” — sondern eine Struktur zu schaffen, in der Unfälle strukturell nicht passieren können.

Bedrohung	Gegenmaßnahme
API-Schlüssel-Leck	.env + .gitignore + Geheimnis-Scan-Hook
Unbeabsichtigtes Löschen	Deny-Liste + Pre-Lösch-Hook
Produktionsfehler	local/managed settings + CLAUDE.md-Verbote
Commit-Kontamination	PreToolUse-Hook für Pre-Commit-Scan

Einmal konfiguriert sind diese Einstellungen praktisch wartungsfrei. 30 Minuten Aufwand heute können einen großen Vorfall in der Zukunft verhindern.

Verwandte Artikel

• Claude Code Berechtigungsleitfaden
• Claude Code Sicherheitsfehler-Fallstudien
• Claude Code + SaaS-Integration Komplettleitfaden
• CLAUDE.md Best Practices

Referenzen

• Claude Code settings offizielle Dokumentation
• Claude Code permissions offizielle Dokumentation
• Claude Code server managed settings offizielle Dokumentation
• Geheimnisse aus der Historie entfernen mit git-filter-branch
• BFG Repo Cleaner