Claude Code Admin-Steuerung: Ein vollständiger Leitfaden für IT- und DevOps-Teams (2026)
Rama Adi Nugraha
Katelin Teen
Zuletzt bearbeitet June 9, 2026
Warum Claude Code überhaupt Admin-Steuerelemente benötigt
Wenn Sie einen Coding-Agenten in einer Engineering-Organisation einführen, ist das Risikoprofil anders als bei der Bereitstellung eines Chat-Tools. Claude Code kann Shell-Befehle ausführen, Dateien in einer gesamten Codebasis lesen, Pull Requests öffnen und – bei entsprechenden Berechtigungen – das Internet erreichen oder in Secrets-Dateien schreiben. Ohne Kontrollen treten zwei Fehlermodi auf: Entwickler verharren in vorsichtiger Nutzung und bestätigen jede Aktion manuell, oder sie gewähren pauschale Berechtigungen und enden mit einem Agenten, der technisch gesehen alles tun kann.
Beides ist nicht das, was Sie wollen. Was Sie tatsächlich wollen, ist etwas, das Group Policy für KI ähnelt: Sie definieren, was das Tool auf Organisationsebene tun darf, Entwickler erhalten eine produktive Umgebung innerhalb dieser Grenzen, und Sie haben Audit-Fähigkeiten, wenn etwas schiefgeht.
Genau dafür sind die Admin-Steuerelemente von Claude Code konzipiert. Lassen Sie uns jede Schicht des Systems durchgehen.
Die vierstufige Konfigurationshierarchie
Jede Claude Code-Einstellung wird durch einen Prioritätsstapel aufgelöst. Von höchster zu niedrigster Priorität:
- Managed – von der IT bereitgestellt, höchste Priorität, kann von nichts überschrieben werden
- CLI-Argumente – nur für die Sitzung gültige Überschreibungen (
--model sonnet,--permission-mode plan) - Lokales Projekt (
.claude/settings.local.json) – persönliche Überschreibungen für dieses Repository, in gitignore - Gemeinsames Projekt (
.claude/settings.json) – teamübergreifend, in Git eingecheckt - Benutzer (
~/.claude/settings.json) – persönliche globale Standards
Die verwaltete Schicht ist die Obergrenze und Benutzereinstellungen sind der Boden. Projekteinstellungen sind der Ort, an dem Teams das Tooling standardisieren. Array-wertige Einstellungen wie permissions.allow werden über Bereiche hinweg zusammengeführt, anstatt sich gegenseitig zu ersetzen – eine Allow-Regel in Benutzereinstellungen stapelt sich mit einer Allow-Regel in Projekteinstellungen. Skalare Werte folgen dem Winner-Takes-All-Prinzip vom höchsten Bereich, der sie definiert.
Eine Nuance, die es wert ist zu wissen: auto-Modus wird ignoriert, wenn er in Projekt- oder lokalen Einstellungen ab v2.1.142 festgelegt ist. Wenn Sie defaultMode: "auto" in einer Projektkonfiguration setzen und sich wundern, warum es keine Wirkung hat, das ist der Grund – es muss aus Benutzer- oder verwalteten Einstellungen kommen.
Verwaltete Einstellungen bereitstellen
Vier Bereitstellungsmechanismen, die alle dasselbe JSON-Format lesen:
Server-verwaltet (Teams/Enterprise): Einstellungen aus der Administratorkonsole in claude.ai pushen. Erfordert einen Claude for Teams oder Enterprise Plan. Verwenden Sie forceRemoteSettingsRefresh: true, um den Sitzungsstart zu blockieren, bis der Push bestätigt wird – nützlich, wenn Ihre Richtlinienaktualisierung wirksam werden muss, bevor ein Entwickler weiterarbeiten kann.
macOS MDM (Jamf, Kandji, Mosyle): Konfigurationsprofil bereitstellen, das auf die com.anthropic.claudecode plist-Domäne abzielt. Top-Level-Schlüssel spiegeln die JSON-Feldnamen wider; verschachtelte Einstellungen verwenden plist-Dictionaries, Arrays verwenden plist-Arrays. Standardansatz für Organisationen, die Macs bereits mit MDM verwalten.
Windows Group Policy / Intune: JSON in HKLM\SOFTWARE\Policies\ClaudeCode mit einem Settings-Wert vom Typ REG_SZ schreiben. Über Group Policy Object oder ein Intune-Konfigurationsprofil bereitstellen. Für nur-Benutzer-Richtlinien (wenn keine Admin-Level-Quelle vorhanden ist), verwenden Sie HKCU\SOFTWARE\Policies\ClaudeCode.
Dateibasiert: managed-settings.json ablegen unter:
- macOS:
/Library/Application Support/ClaudeCode/ - Linux / WSL:
/etc/claude-code/ - Windows:
C:\Program Files\ClaudeCode\
Dateibasiert unterstützt auch ein managed-settings.d/-Drop-in-Verzeichnis am selben Ort. Dateien werden alphabetisch sortiert und tief zusammengeführt – Skalare aus späteren Dateien gewinnen, Arrays werden verkettet und dedupliziert. Nützlich, wenn mehrere Sicherheitstools oder Teams separate Richtlinienfragmente beitragen müssen, ohne sich gegenseitig zu überschreiben.
Für dynamische Richtlinien, die aus dem Gerätestatus oder einem Remote-Compliance-Dienst abgeleitet werden, verweist der policyHelper-Schlüssel auf eine ausführbare Datei, die beim Start JSON-Einstellungen berechnet. Das Binary schreibt einen JSON-Envelope (mit Einstellungen unter einem managedSettings-Schlüssel) nach stdout, und Claude Code liest ihn vor dem Sitzungsstart ein. Verfügbar seit v2.1.136.
Um zu überprüfen, was aktiv ist, führen Sie /status in Claude Code aus. Der Status-Tab zeigt eine Setting sources-Zeile, die jede aktive Schicht mit dem Bereitstellungskanal in Klammern auflistet: Enterprise managed settings (remote), (plist), (HKLM), (file).
Berechtigungen: Allow-, Ask- und Deny-Regeln
Das Berechtigungssystem drückt aus, was Claude ohne Rückfragen tun darf und was es überhaupt nicht berühren kann. Drei Regeltypen:
- Allow – Claude führt das Tool automatisch aus, keine Eingabeaufforderung
- Ask – Claude fragt den Entwickler vor der Ausführung (Standard für die meisten Tools)
- Deny – Claude kann das Tool überhaupt nicht verwenden
Regeln folgen dem Format Tool oder Tool(specifier). Ein einfaches Deny wie "Bash" entfernt das gesamte Tool aus Claudes Kontext, sodass Claude es nie zu verwenden versucht. Ein bereichsspezifisches Deny wie "Bash(rm *)" hält das Tool verfügbar, blockiert aber übereinstimmende Aufrufe zur Laufzeit.
Die Auswertungsreihenfolge ist immer zuerst Deny, dann Ask, dann Allow – und die erste übereinstimmende Regel gewinnt, unabhängig davon, aus welchem Bereich sie stammt. Ein Deny in Benutzereinstellungen blockiert einen Allow auf Projektebene. Ein verwaltetes Deny kann durch keinen niedrigeren Bereich entsperrt werden.
Eine praktische Basis in .claude/settings.json für eine Teamumgebung:
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git status)",
"Bash(git stash *)"
],
"deny": [
"Bash(curl *)",
"Bash(wget *)",
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"WebFetch"
]
}
}
Dies genehmigt automatisch allgemeine Entwicklerbefehle und blockiert Netzwerktools und sensible Dateilesevorgänge.
Berechtigungsregeln-Muster, die Sie kennen sollten
Wildcards stimmen über Argumente hinweg überein. Bash(npm run *) stimmt mit npm run test --watch überein – das * erstreckt sich über mehrere Argumente einschließlich Leerzeichen. Bash(git *) stimmt mit git log --oneline --all überein. Ein Leerzeichen vor * erzwingt eine Wortgrenze: Bash(ls *) stimmt mit ls -la überein, aber nicht mit lsof.
URL-eingeschränktes curl ist fehleranfällig. Bash(curl http://github.com/ *) schlägt fehl bei curl -X GET http://github.com/... (Optionen vor URL), curl https://github.com/... (anderes Protokoll) oder Umgebungsvariablen, die die URL enthalten. Für zuverlässige Domain-Einschränkung verwenden Sie WebFetch(domain:github.com) für erlaubte Domains und verweigern Sie Bash-Netzwerktools vollständig. Die vollständige Erklärung finden Sie in der Berechtigungsreferenz.
Zusammengesetzte Befehle werden vor dem Abgleichen aufgeteilt. Eine Allow-Regel für npm test deckt nicht npm test && curl evil.com ab. Claude Code teilt bei &&, ||, ;, | auf und prüft jeden Unterbefehl unabhängig.
Read/Edit-Muster folgen der gitignore-Syntax. Read(./.env) und Read(**/.env) sind gleichwertig – beide blockieren jede .env-Datei im aktuellen Verzeichnis oder darunter. Verwenden Sie Read(//**/.env), um .env-Dateien überall im Dateisystem zu blockieren.
Berechtigungsmodi
Sechs Berechtigungsmodi ändern, wie nicht übereinstimmende Tool-Aufrufe behandelt werden:
| Modus | Was er tut |
|---|---|
default | Eingabeaufforderung bei der ersten Verwendung jedes Tools |
acceptEdits | Dateibearbeitungen und sichere Dateisystembefehle automatisch genehmigen |
plan | Nur-Lesen – keine Dateiänderungen |
auto | Hintergrund-Sicherheitsprüfungen genehmigen ausgerichtete Aufrufe automatisch (Forschungsvorschau) |
dontAsk | Automatisch ablehnen, sofern nicht über Allow-Regeln vorab genehmigt |
bypassPermissions | Alle Eingabeaufforderungen überspringen – nur für isolierte Container/VMs |
Setzen Sie defaultMode in den Einstellungen, um den Startmodus zu sperren. Um zu verhindern, dass der bypassPermissions-Modus jemals aktiviert wird, fügen Sie Folgendes zu Ihren verwalteten Einstellungen hinzu:
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}
Dies schließt das --dangerously-skip-permissions-Flag vollständig – Entwickler sehen einen Fehler, wenn sie versuchen, es zu verwenden. Gleiches Muster für den Auto-Modus: "disableAutoMode": "disable".
Nur verwaltete Einstellungen: die Admin-only-Sperr-Steuerelemente
Einige Einstellungen treten nur in Kraft, wenn sie über verwaltete Einstellungen bereitgestellt werden. Sie in Benutzer- oder Projektdateien zu platzieren, hat keine Wirkung – sie sind wirklich nur für Admins:
| Einstellung | Was sie durchsetzt |
|---|---|
allowManagedPermissionRulesOnly | Verhindert, dass Benutzer- und Projekteinstellungen Allow/Ask/Deny-Regeln definieren. Nur verwaltete Regeln gelten. |
allowManagedHooksOnly | Nur Hooks aus verwalteten Einstellungen oder zwangsweise aktivierten Plugins werden ausgeführt. Benutzer- und Projekt-Hooks werden blockiert. |
allowManagedMcpServersOnly | Nur MCP-Server in allowedMcpServers aus verwalteten Einstellungen werden verwendet. |
strictKnownMarketplaces | Kontrolliert, welche Plugin-Marktplätze Benutzer hinzufügen können. Ein leeres Array blockiert alle neuen Marktplatz-Hinzufügungen. |
strictPluginOnlyCustomization | Erzwingt, dass Skills, Agenten, Hooks und/oder MCP-Server nur aus Plugins stammen. |
forceLoginMethod | Anmeldung auf claudeai-Konten oder console-Konten beschränken. |
forceLoginOrgUUID | Anmeldung bei einer bestimmten Anthropic-Organisations-UUID erfordern. |
requiredMinimumVersion | Startup blockieren, wenn die Claude Code-Version darunter liegt. |
requiredMaximumVersion | Startup blockieren, wenn die Claude Code-Version darüber liegt. |
claudeMd | Organisationsweite Anweisungen einfügen, die in jeder Sitzung erscheinen. |
channelsEnabled | Kanäle (Integrationen) organisationsweit aktivieren oder deaktivieren. |
forceRemoteSettingsRefresh | Startup blockieren, bis verwaltete Einstellungen frisch vom Server abgerufen werden. |
Die Kombination aus allowManagedPermissionRulesOnly: true + allowManagedHooksOnly: true gibt Ihnen einen harten Perimeter: Kein Entwickler kann erweitern, was Claude über Ihre verwalteten Einstellungen hinaus autorisiert ist zu tun. Alles läuft durch IT-genehmigte Regeln und Hooks, nichts mehr.
Sandbox: OS-level-Dateisystem- und Netzwerkisolierung
Die Sandbox ist eine separate Sicherheitsschicht von den Berechtigungen. Berechtigungen regeln, was Claude zu tun versucht. Die Sandbox erzwingt, was Bash-Befehle tatsächlich erreichen können auf OS-Ebene – mit macOS' nativer Prozessisolierung (Seatbelt) und Linux seccomp/namespaces zur Durchsetzung von Dateisystem-Lese-/Schreibgrenzen und Netzwerkzugriffsregeln.
Eine Basis-Sandbox-Konfiguration für eine Entwicklermaschine:
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": [
"~/.aws/credentials",
"~/.ssh/id_rsa",
"~/.ssh/id_ed25519"
],
"allowWrite": ["/tmp/build", "~/.kube"]
},
"network": {
"allowedDomains": [
"github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com"
]
}
}
}
Mit autoAllowBashIfSandboxed: true (Standard) werden Bash-Befehle, die innerhalb der Sandbox-Grenzen bleiben, ohne Eingabeaufforderung ausgeführt – die Sandbox-Grenze ersetzt per-Befehl-Bestätigungsdialoge. Entwickler erhalten schnelleren Fluss; Sie erhalten Durchsetzung.
Drei nur-verwaltete Sandbox-Flags sind für strengere Umgebungen wissenswert:
sandbox.network.allowManagedDomainsOnly: true– nur Domains in verwaltetenallowedDomainssind erreichbar; Ergänzungen auf Projektebene werden ignoriertsandbox.filesystem.allowManagedReadPathsOnly: true– nur verwaltetefilesystem.allowRead-Pfade werden berücksichtigtsandbox.network.allowUnixSockets– erforderlich auf macOS, um Docker-Socket-Zugriff zu ermöglichen (/var/run/docker.sock)
Die Sandbox gilt nur für Bash-Befehle und ihre Kindprozesse. Sie schränkt Claudes eingebaute Read/Write-Tools nicht ein – diese werden durch die obigen Berechtigungsregeln geregelt. Verwenden Sie beide Schichten zusammen für Tiefenverteidigung: Berechtigungsregeln verhindern, dass Claude versucht, unbefugten Zugriff zu erlangen, und die Sandbox verhindert, dass alles, was durch den OS-Level durchschlüpft.
Für Container-, CI- und WSL-Umgebungen lesen Sie den Anthropic-Sandboxing-Leitfaden – die Konfiguration unterscheidet sich in diesen Umgebungen.
Hooks zur Richtliniendurchsetzung
Hooks sind Shell-Befehle, HTTP-Endpunkte oder LLM-ausgewertete Prompts, die an bestimmten Lifecycle-Punkten ausgelöst werden. Für Admin-Verwendung ist PreToolUse das Schlüssel-Ereignis: Es wird vor jedem Tool-Aufruf ausgelöst und kann den Aufruf blockieren, bevor er passiert – auch wenn eine Allow-Regel ihn sonst erlauben würde.
Ein Shell-basierter Sicherheits-Hook, der destruktive Befehle blockiert:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "/usr/local/bin/claude-security-check.sh",
"args": []
}
]
}
]
}
}
Der Hook empfängt den vollständigen Tool-Aufruf als JSON auf stdin. Um zu blockieren:
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "rm -rf durch Org-Sicherheitsrichtlinie blockiert"
}
}
Exit-Code 0 ohne Ausgabe bedeutet "keine Entscheidung" – normaler Berechtigungsfluss wird fortgesetzt. Der Hook kann ablehnen, aber Stille genehmigt nicht.
Für HTTP-basierte zentrale Richtlinien verwenden Sie type: "http", um Tool-Aufruf-Ereignisse an Ihren Sicherheitsdienst zu senden und die Entscheidung aus der Antwort zu lesen. Dadurch kann ein zentrales Team Richtlinienauswertungen durchführen, ohne Shell-Skripte auf jede Entwicklermaschine zu verteilen.
Zwei weitere Ereignisse, die für Governance nützlich sind:
ConfigChange– wird ausgelöst, wenn eine Einstellungsdatei während der Sitzung geändert wird. Verwenden Sie dies, um zu erkennen, wenn Entwickler ihre Berechtigungsregeln während einer Sitzung ändern, und senden Sie eine Benachrichtigung an Ihr SIEM oder Slack.SessionStart– wird beim Sitzungsöffnen ausgelöst. Gut zum Einfügen von Audit-Metadaten, Überprüfen von Versionsanforderungen oder Bestätigen, dass der Benutzer im Netzwerk ist, bevor sensible Vorgänge erlaubt werden.
Mit allowManagedHooksOnly: true in verwalteten Einstellungen werden nur über Ihren verwalteten Kanal bereitgestellte Hooks ausgeführt. Entwicklerseitige Hooks in Projekt-.claude/settings.json werden still ignoriert. Siehe die vollständige Hooks-Referenz für alle verfügbaren Ereignisse.
Netzwerk- und Proxy-Konfiguration
Für Umgebungen, die Datenverkehr über einen Unternehmens-Proxy leiten, liest Claude Code Standard-Proxy-Umgebungsvariablen:
HTTPS_PROXY=https://proxy.example.com:8080
HTTP_PROXY=http://proxy.example.com:8080
NO_PROXY="localhost,192.168.1.1,.internal.example.com"
Setzen Sie diese im env-Block der verwalteten Einstellungen, damit sie ohne Entwicklerkonfiguration auf jede Sitzung angewendet werden:
{
"env": {
"HTTPS_PROXY": "https://proxy.example.com:8080",
"NO_PROXY": "localhost,.internal.example.com"
}
}
Für Enterprise-TLS-Inspektion (CrowdStrike Falcon, Zscaler) vertraut Claude Code standardmäßig sowohl seinem gebündelten Mozilla CA-Satz als auch dem OS-Zertifikatspeicher. Wenn Ihr Proxy eine benutzerdefinierte CA verwendet, die nicht im OS-Speicher ist:
{
"env": {
"NODE_EXTRA_CA_CERTS": "/etc/ssl/certs/enterprise-ca.pem"
}
}
Für gegenseitige TLS-Authentifizierung:
{
"env": {
"CLAUDE_CODE_CLIENT_CERT": "/etc/ssl/certs/claude-client.pem",
"CLAUDE_CODE_CLIENT_KEY": "/etc/ssl/private/claude-client-key.pem"
}
}
Ihre Firewall-Zulassungsliste benötigt mindestens diese URLs:
| URL | Erforderlich für |
|---|---|
api.anthropic.com | Claude API-Aufrufe |
claude.ai | Claude.ai-Kontoauthentifizierung |
platform.claude.com | Konsolenkonto-Authentifizierung |
downloads.claude.ai | Plugin-Downloads und automatische Updates |
bridge.claudeusercontent.com | Claude in Chrome-Erweiterung |
raw.githubusercontent.com | Versionshinweise und Plugin-Marktplatz |
Beim Bereitstellen über Amazon Bedrock, Google Vertex AI oder Microsoft Foundry geht der Modelldatenverkehr an Ihren Cloud-Anbieter statt an api.anthropic.com. Setzen Sie CLAUDE_CODE_USE_BEDROCK=1 (oder das Äquivalent) im env-Block und konfigurieren Sie ANTHROPIC_BEDROCK_BASE_URL, wenn Sie über ein LLM-Gateway weiterleiten. Das vollständige Cloud-Provider-Setup finden Sie im Anthropic-Leitfaden für Drittanbieter-Integrationen.
MCP- und Plugin-Governance
MCP-Server erweitern Claude mit externen Tool-Integrationen – Jira, Notion, GitHub, interne Datenbanken. Aus Governance-Sicht besteht das Risiko darin, dass Entwickler eine Verbindung zu nicht vertrauenswürdigen Servern herstellen oder nicht geprüfte Marktplatz-Plugins installieren.
Steuerung des MCP-Zugriffs über verwaltete Einstellungen:
{
"allowedMcpServers": [
{ "serverName": "github" },
{ "serverName": "jira" }
],
"deniedMcpServers": [
{ "serverName": "filesystem" }
],
"allowManagedMcpServersOnly": true
}
Mit allowManagedMcpServersOnly: true werden Projekt-.mcp.json-Dateien ignoriert – nur Server in der verwalteten Zulassungsliste werden ausgeführt. Sperrlisten-Einträge werden weiterhin aus allen Bereichen zusammengeführt, sodass jeder Bereich einen Server blockieren kann, auch wenn die Zulassungsliste gilt.
Steuerung von Plugin-Marktplätzen:
{
"strictKnownMarketplaces": [
{ "source": "github", "repo": "acme-corp/approved-claude-plugins" }
],
"blockedMarketplaces": [
{ "source": "github", "repo": "untrusted-org/plugins" }
]
}
strictKnownMarketplaces mit einer bestimmten Liste bedeutet, dass Entwickler nur Marktplätze auf dieser Liste hinzufügen können. Ein leeres Array [] blockiert alle neuen Marktplatz-Hinzufügungen vollständig. blockedMarketplaces wird vor Netzwerk- oder Dateisystemoperationen durchgesetzt – blockierte Quellen berühren niemals die Festplatte.
strictPluginOnlyCustomization geht weiter und erfordert, dass alle Skills, Agenten, Hooks und MCP-Server aus Plugins kommen, anstatt aus Benutzer- oder Projektdateien:
{
"strictPluginOnlyCustomization": ["skills", "hooks"]
}
Übergeben Sie true, um alle vier Oberflächen (Skills, Agenten, Hooks, MCP) zu sperren, oder ein Array mit den Namen derer, die Sie sperren möchten. Dadurch wird sichergestellt, dass alle Claude Code-Anpassungen in Ihrer Organisation durch genehmigte, verteilte Plugins laufen, anstatt durch Ad-hoc-Entwicklerkonfiguration. Siehe die Claude Code Plugin-Übersicht für Kontext darüber, was das Plugin-System ermöglicht.
CLAUDE.md als organisationsweiter Kontext
CLAUDE.md-Dateien sind die Anweisungsschicht – sie teilen Claude mit, was priorisiert werden soll, während Einstellungsdateien definieren, was erlaubt ist. Die verwaltete Einstellung claudeMd fügt organisationsweite Anweisungen in jede Sitzung ein, unabhängig vom CLAUDE.md-Inhalt auf Projektebene:
{
"claudeMd": "Führe immer `make lint` vor dem Committen aus. Ändern Sie niemals Dateien in /vendor. Sicherheit: Verwenden Sie parametrisierte Abfragen, protokollieren Sie niemals Anmeldedaten. Interne Dokumente unter wiki.internal/engineering."
}
Anders als eine CLAUDE.md auf Projektebene, die Entwickler lokal überschreiben könnten, kann die verwaltete claudeMd nicht ausgeschlossen oder ignoriert werden. Es ist ein zuverlässiger Kanal für organisationsweite Coding-Standards, Sicherheitsanforderungen und Links zu internen Ressourcen, die in jeder Sitzung vorhanden sein sollten.
Für projektspezifischen Kontext committen Sie CLAUDE.md in das Repository-Stammverzeichnis – jeder Mitarbeiter erhält dieselben Anweisungen, und der Claude Code-Bereitstellungsleitfaden erläutert, wie diese für große Monorepos strukturiert werden. Die Einstellung claudeMdExcludes ermöglicht es Ihnen, CLAUDE.md-Dateien aus Vendor-Verzeichnissen oder Drittanbieter-Code zu überspringen, der Claudes Kontext nicht belasten soll.
Claude Code-Nutzung überwachen
Claude Code exportiert Telemetrie über OpenTelemetry, das mit jedem OTLP-kompatiblen Stack integriert wird – Datadog, Honeycomb, Grafana:
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_ENDPOINT": "https://your-collector:4318",
"OTEL_RESOURCE_ATTRIBUTES": "service.name=claude-code"
}
}
Verfügbare Metriken umfassen Sitzungsaktivität, Tool-Nutzungszähler nach Typ, Modellnutzung und Fehlerquoten. Für Cloud-Sitzungen werden alle Vorgänge automatisch für Compliance protokolliert.
Der ConfigChange-Hook (oben beschrieben) liefert Echtzeitsignale, wenn sich Einstellungsdateien während der Sitzung ändern. Die Kombination mit Ihrem SIEM erstellt einen Audit-Trail von Konfigurationsänderungen.
Für Nutzungsberichte auf Teamebene enthält der usage-analytics-claude-code-Blog eine vollständige Anleitung zur Claude Code-Nutzungsanalyse-Einrichtung, einschließlich der verfügbaren OTLP-Metriken und was jede davon bedeutet.
Teams vs. Enterprise: was jeder Plan für Admins hinzufügt
| Funktion | Teams | Enterprise |
|---|---|---|
| Projekteinstellungen (.claude/settings.json) | Ja | Ja |
| MDM/dateibasierte verwaltete Einstellungen | Ja | Ja |
| Vom Server verwaltete Einstellungen (Admin-Konsolen-Push) | Eingeschränkt | Vollständig |
| SSO und Domain Capture | Nein | Ja |
forceLoginOrgUUID-Durchsetzung | Nein | Ja |
| Verwaltete Richtlinieneinstellungen organisationsweit | Teilweise | Vollständig |
| Remote Control und Web-Sitzungs-Admin-Steuerungen | Ja | Ja |
| Compliance-API-Zugriff (SOC 2 / ISO 27001) | Nein | Ja |
| Zentralisiertes Nutzungs-Dashboard | Ja | Ja |
| Dedizierter Support / SLA | Nein | Ja |
Für das Bereitstellen von Claude Code an Teams mit ungefähr unter 50 Personen deckt Claude for Teams mit dateibasiert oder MDM-bereitgestellten verwalteten Einstellungen in der Regel das Wesentliche ab. Enterprise fügt SSO, forceLoginOrgUUID zur Durchsetzung der Organisationsmitgliedschaft und vom Server verwaltete Einstellungen, die von einer zentralen Konsole gepusht werden, hinzu – die richtige Wahl für Organisationen mit Active Directory, Okta oder ähnlichem Identitätsmanagement oder mit Compliance-Anforderungen, die Anthropic Trust Center-Dokumentation benötigen (SOC 2 Typ 2, ISO 27001 beide zertifiziert ab 2026).
Der vollständige Enterprise Claude Code-Leitfaden behandelt Beschaffung, Benutzerbereitstellung und SSO-Konfigurationsschritte.
Eine Schnellstart-Vorlage für verwaltete Einstellungen
Hier ist eine Basis-managed-settings.json, die das Wesentliche für die meisten sicherheitsbewussten Engineering-Organisationen abdeckt. Stellen Sie sie unter /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux) bereit oder pushen Sie sie über MDM/Group Policy:
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git status)",
"Bash(git stash *)",
"Bash(make *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(//home/**/.ssh/*)",
"Read(//root/.ssh/*)"
],
"disableBypassPermissionsMode": "disable"
},
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": [
"~/.aws/credentials",
"~/.ssh/id_rsa",
"~/.ssh/id_ed25519",
"~/.ssh/id_ecdsa"
]
},
"network": {
"allowedDomains": [
"github.com",
"*.github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com",
"*.anthropic.com"
]
}
},
"claudeMd": "Folgen Sie dem Projekt-CLAUDE.md für Coding-Standards. Protokollieren Sie niemals Anmeldedaten, Tokens oder Secrets. Verwenden Sie parametrisierte Abfragen. Interne Dokumente: wiki.internal/engineering",
"companyAnnouncements": [
"Die Claude Code Enterprise-Richtlinie gilt für alle Sitzungen. Fragen: security@yourcompany.com"
],
"requiredMinimumVersion": "2.1.100",
"availableModels": ["opus", "sonnet", "haiku"]
}
Diese Vorlage schließt --dangerously-skip-permissions, blockiert Lesevorgänge von SSH-Schlüsseln und AWS-Anmeldedaten, aktiviert die Sandbox mit automatisch genehmigtem sandbox-Bash, beschränkt ausgehende Netzwerkverbindungen auf genehmigte Domains, fügt eine minimale Sicherheitsrichtlinie ein und legt eine Mindestversion fest.
Nachdem Sie dies eine Woche lang ausgeführt und geprüft haben, was Ihre Entwickler tatsächlich in der Erlaubnisliste benötigen, sollten Sie in Erwägung ziehen, "allowManagedPermissionRulesOnly": true für die strengste mögliche Sperrung hinzuzufügen. Diese Einstellung ist hier absichtlich weggelassen – sie sollte nur hinzugefügt werden, wenn Sie sicher sind, dass die Erlaubnisliste den tatsächlichen Arbeitsablauf Ihres Teams abdeckt.
Die vollständige settings.json-Referenz deckt alle ~80 verfügbaren Schlüssel ab, wenn Sie weiter optimieren müssen, und der Claude Code Best Practices-Leitfaden behandelt das entwicklerseitige Setup, das diese Admin-Schicht ergänzt.
Probieren Sie eesel.ai aus
Wenn Sie sorgfältig über KI-Governance für Ihre Engineering-Organisation nachdenken, stellen Sie wahrscheinlich dieselben Fragen auch im Support, in der IT und in anderen Teams. eesel.ai stellt autonome KI-Agenten direkt in den Tools bereit, die diese Teams bereits verwenden – Zendesk, Freshdesk, Slack, Jira und 100+ weitere – mit demselben Ansatz wie das Berechtigungssystem von Claude Code: Agenten arbeiten innerhalb klarer Grenzen, die Sie konfigurieren, das Team behält die Kontrolle darüber, was sie können und was nicht, und die Einrichtung dauert Minuten aus vorhandener Wissenshistorie. Keine neue Oberfläche zu übernehmen, keine Prompt-Engineering-Kenntnisse erforderlich.
Häufig gestellte Fragen
Wie verhindere ich, dass Entwickler --dangerously-skip-permissions in Claude Code verwenden?
permissions.disableBypassPermissionsMode in Ihren verwalteten Claude Code-Einstellungen auf "disable". Da verwaltete Einstellungen an der Spitze des Prioritätsstapels stehen, kann dies durch keine Benutzer- oder Projektkonfiguration überschrieben werden – auch nicht durch Befehlszeilenargumente. Weitere Informationen finden Sie in der Berechtigungsreferenz von Anthropic.Was ist der Unterschied zwischen verwalteten Claude Code-Einstellungen und Projekteinstellungen?
.claude/settings.json, werden in Git eingecheckt und gelten für alle Mitarbeiter im Repository, können aber durch lokale oder Benutzereinstellungen überschrieben werden. Verwenden Sie verwaltete Einstellungen für Compliance-Richtlinien und Projekteinstellungen für Team-Konventionen.Kann ich einschränken, welche Claude-Modelle Entwickler in Claude Code verwenden können?
availableModels zu Ihren verwalteten Einstellungen hinzu, um einzuschränken, welche Modelle Benutzer über /model oder --model auswählen können – zum Beispiel ["sonnet", "haiku"], um Opus auszuschließen. Kombinieren Sie es mit dem Schlüssel model, um einen bestimmten organisationsweiten Standard festzulegen. Für Bedrock- oder Vertex-Deployments pin der Env-Var ANTHROPIC_DEFAULT_SONNET_MODEL genaue Modellversionen.Wie stelle ich Claude Code Admin-Steuerungen auf allen Entwicklermaschinen bereit?
com.anthropic.claudecode plist-Domäne abzielt), Windows Group Policy oder Intune (JSON in HKLM\SOFTWARE\Policies\ClaudeCode schreiben) oder eine Datei unter /Library/Application Support/ClaudeCode/managed-settings.json auf macOS oder /etc/claude-code/managed-settings.json auf Linux ablegen. Alle drei lesen dasselbe JSON-Format. Für vom Server verwaltete Einstellungen auf Team-/Enterprise-Plänen verwenden Sie die Administratorkonsole.Was macht allowManagedPermissionRulesOnly in den Claude Code Admin-Steuerelementen?
true gesetzt, verhindert dies, dass Benutzer- und Projekteinstellungen allow-, ask- oder deny-Berechtigungsregeln definieren. Nur die Regeln in Ihren verwalteten Einstellungen gelten. Dies ist die strengste verfügbare Berechtigungssperrung – nützlich, wenn die Sicherheitsrichtlinie erfordert, dass kein Entwickler ein Tool selbst autorisieren kann, das Claude Code nicht vorab genehmigt wurde.
