Leitfaden für die Administratoreinführung

Verwenden Sie diesen Leitfaden, um die Einführung von ChatGPT Enterprise über diese Administrationsgrenzen hinweg zu planen:

Workspace-Zugriff.
Lokale Laufzeitrichtlinie für abgedeckte Funktionen in der ChatGPT-Desktop-App, Codex CLI und der IDE-Erweiterung.
Codex cloud.
Platform API-Zugriff.
Zugriff auf Plugins und Konnektoren.
Berechtigungen in verbundenen Systemen.

Führen Sie die Schritte bei einer neuen Einführung der Reihe nach aus oder verwenden Sie die verlinkten Seiten, um eine einzelne Grenze zu ändern.

Wenn Sie ein Modell-Gateway für lokale Codex-Clients verwalten, verwenden Sie Codex über ein Gateway bereitstellen für die Eignungsprüfung des Gateways, die Verteilung von Zugangsdaten und die Übergabe an die Clients. Konfigurieren Sie den Arbeitsbereichszugriff separat, wenn Ihre Bereitstellung Arbeitsbereichsfunktionen nutzt.

In den Workspace-Einstellungen fasst Codex and Work Local den Zugriff auf lokales Codex und Work unter Allow members to use Codex and Work Locally zusammen. Einige Workspaces bieten stattdessen separate Bereiche für Codex Local und Work Local. In dieser Anordnung steuert Allow members to use Codex locally den Zugriff auf Codex und Use Work locally den Zugriff auf Work. Wenn Sie eine der beiden Optionen aktivieren, wird die andere nicht automatisch aktiviert. Diese Bezeichnungen kennzeichnen Workspace-Berechtigungen und keine separaten Produkte oder Clients. Berechtigungen für Tokens und Begrenzungen der Gültigkeitsdauer von Anmeldedaten werden je nach Workspace entweder im Bereich Access tokens oder im Bereich für lokalen Zugriff angezeigt. Die verwaltete Konfiguration bildet eine separate Richtlinienebene, die das unterstützte Laufzeitverhalten für die von ihr abgedeckten Funktionen in diesen Clients einschränken kann. Dieser Leitfaden nennt die jeweilige Oberfläche ausdrücklich, wenn sich Verhalten oder Verfügbarkeit unterscheiden.

Einen Überblick über die Zugriffskontrollen finden Sie unter Rollen und Arbeitsbereichsberechtigungen. Nutzen Sie die Anleitungen im Hilfecenter für aktuelle Verfahren in ChatGPT-Arbeitsbereichen und die verlinkte Entwicklerdokumentation für das Verhalten lokaler und gehosteter Laufzeitumgebungen.

Informationen zu Sicherheit, Datenschutz und Laufzeitschutz für Unternehmen finden Sie unter Agentengenehmigungen und Sicherheit und im Codex-Sicherheits-Whitepaper.

Schritt 1: Verantwortliche zuweisen und eine Einführungsstrategie auswählen

Weisen Sie jedem Teil der Einführung eine verantwortliche Person zu:

Workspace-Zugriff: Mitgliedschaft, Lizenzplätze, Rollen und unterstützte Workspace-Funktionen.
Lokale Laufzeitrichtlinie: Genehmigungen, Berechtigungsprofile, Dateisystem- und Netzwerkzugriff sowie weitere Anforderungen für unterstützte lokale Clients.
Codex cloud: Gehostete Umgebungen, Repository-Verbindungen und Cloud-Laufzeitrichtlinien.
Verbundene Systeme: Anwendungsinstallation auf Anbieterseite, Konten und Berechtigungen.
Berichterstattung und Compliance: Analysezugriff, Audit-Exporte und nachgelagerte Datenverarbeitung.

Entscheiden Sie, ob die jeweilige Zielgruppe abgedeckte lokale Funktionen in der ChatGPT-Desktop-App, Codex CLI, der IDE-Erweiterung, Codex cloud oder einer Kombination daraus benötigt. Behandeln Sie den Platform API-Zugriff als separate Organisations- und Projektgrenze, wenn ein Workflow die Authentifizierung per API key verwendet.

Schritt 2: Workspace-Zugriff und Identität konfigurieren

Verwenden Sie ChatGPT-Workspace-Mitgliedschaften, Lizenzplätze, Gruppen und unterstützte RBAC-Berechtigungen, um den vorgesehenen Zielgruppen unterstützte Workspace-Funktionen bereitzustellen. Überprüfen Sie den Zugriff auf lokale Clients und Codex cloud anhand der aktuellen Workspace-Anleitungen, statt davon auszugehen, dass dieselbe Rolle jede Oberfläche steuert. Beschränken Sie integrierte Administrationsrollen auf die Personen, die den Workspace verwalten.

Workspace-Steuerelemente und -Bezeichnungen ändern sich im Laufe der Zeit. Verwenden Sie für aktuelle Verfahren diese Quellen:

Testen Sie die Anmeldung und den Funktionszugriff mit einem Mitglied, das über die vorgesehenen Berechtigungen verfügt. Der Arbeitsbereichszugriff gewährt keinen Zugriff auf Repositorys, Dateien oder Aktionen in einem verbundenen Dienst.

Lokalen Computerzugriff mit Work Cloud einrichten

Wenn Ihr Rollout den lokalen Computerzugriff für Work oder dots umfasst, prüfen Sie vor dem Rollout die Richtlinien in Agent Security. Richtlinienmigration und Funktionszugriff sind separate Änderungen; im Bestätigungsablauf müssen keine Richtlinien erstellt werden, um den Zugriff zu aktivieren. Die unterstützte Richtlinie für Global steuert die Cloud-Orchestrierung, wenn die verwaltete Richtlinie aktiviert ist. Anforderungen an die lokale Ausführung und Gerätekontrollen gelten für den verbundenen Computer. Work-Cloud-Container und dots-Cloud-Computer verwenden ihre jeweils eigene Ausführungskonfiguration und eigene Anforderungen. Befolgen Sie die Anleitung Lokaler Computerzugriff für Work Cloud und dots für die separaten Einrichtungsanforderungen und Nutzungsvoraussetzungen.

Verwenden Sie die Richtlinien-API, um die Einstellungen für Global zu verwalten. Verwenden Sie für die Einstellungen für Local oder Codex Cloud die Benutzeroberfläche von Agent Security. Bestehende API-Workflows für Global bleiben nach der Migration verfügbar. Testen Sie Ihre Skripte und Terraform-Integrationen und bestätigen Sie, dass Richtlinienzuweisungen und Reihenfolge unverändert sind.

Prüfen Sie die Kompatibilität, bevor Sie die Synchronisierung aktivieren:

Netzwerkrichtlinie. Wenn umgebungsspezifische Überschreibungen verfügbar sind, testen Sie die unter Verwaltete Konfiguration dokumentierten Ausnahmen für experimental_network. Eine globale Einschränkung kann trotz einer Freigabe auf Umgebungsebene weiterhin gelten.

Enterprise-Hooks. Sofern für Ihren Workspace aktiviert, unterstützt der lokale Computerzugriff mit Work Cloud administrativ definierte MCP-Hooks, die bei unterstützten Lebenszyklus- und Tool-Ereignissen auf dem Cloud-Koordinator (Orchestrator) ausgeführt werden. Befehls-Hooks und Hooks aus der lokalen Konfiguration oder aus Plugins werden bei der Cloud-Orchestrierung nicht unterstützt, auch wenn Tools lokal ausgeführt werden.
Nicht unterstützte Hooks. Befehls-Hooks und Hooks aus der lokalen Konfiguration oder aus Plugins werden bei der Cloud-Orchestrierung nicht unterstützt, auch wenn Tools lokal ausgeführt werden. Wenn sowohl die Orchestrierung als auch die Ausführung lokal erfolgen, funktionieren bestehende unterstützte Hooks weiterhin in ausschließlich lokalen Work- und Codex-Threads. Administratoren können für diese Workflows weiterhin unterstützte verwaltete Hooks in Agent Security konfigurieren.
Auditierung. Bevor Sie sich auf diese Hooks verlassen, testen Sie die Callback-Verbindung, bestätigen Sie die empfangenen Ereignisse und prüfen Sie, wie sich Fehler auf die Aufgabe auswirken. MCP-Hooks liefern kein vollständiges Auditprotokoll über die Compliance API.
Datenanforderungen. Der lokale Computerzugriff mit Work Cloud bietet keine strikte Null-Datenaufbewahrung. Datenresidenz und Inferenzresidenz gelten nur für berechtigte Inhalte sowie unterstützte Workloads, Regionen und Konfigurationen. Enterprise Key Management (EKM) gilt für unterstützte gespeicherte Inhalte in berechtigten Workspaces. Work wird bei Inferenzresidenz in den VAE nicht unterstützt. Wenn enforce_residency in einer beliebigen Cloud-Richtlinie aktiviert ist, wird Allow local computer access sowohl für Work als auch für dots deaktiviert. Diese Schutzmaßnahme konfiguriert weder die Workspace-Residenz noch deaktiviert sie für sich genommen Work Cloud oder dots. Wenn Ihre Organisation ZDR erfordert, aktivieren Sie diese Funktion nicht.

Prüfen Sie als Workspace-Inhaber die Work-Berechtigungen für die vorgesehenen Benutzer oder Gruppen. Aktivieren Sie Work Cloud und anschließend Allow local computer access. Gewähren Sie den Zugriff über unterstützte Rollenzuweisungen. Siehe Rollen und Workspace-Berechtigungen.

Schritt 3: Lokale Laufzeitanforderungen konfigurieren

Lokale Anforderungen beschränken das Laufzeitverhalten, wenn ein Benutzer einen unterstützten lokalen Lauf in der ChatGPT-Desktop-App, Codex CLI oder der IDE-Erweiterung startet. Stellen Sie requirements.toml über einen unterstützten Cloud-, Geräte- oder Systemkanal bereit. Halten Sie diese Richtlinie von ChatGPT-Workspace-Rollen und -Gruppen getrennt.

Verwenden Sie Berechtigungsprofile für unterstützte lokale Clients, statt neue Bereitstellungen auf veralteten Einschränkungen des Sandbox-Modus aufzubauen. Zum Beispiel:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

Um Computer Use auf allen unterstützten Browser- und Desktop-Funktionsoberflächen zu deaktivieren, schränken Sie jeden öffentlichen Funktionsschlüssel ein, der an dieser Funktion beteiligt ist:

[features]
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
computer_use = false

Die maßgebliche Schlüsselliste, das Bereitstellungsverhalten, die Rangfolge und weitere Beispiele finden Sie unter Verwaltete Konfiguration und in der Referenz zu requirements.toml.

Schritt 4: Repository-Konfiguration standardisieren

Verwenden Sie Repository-bezogene Konfigurationen, um Projektstandardwerte, Regeln und Skills gemeinsam zu nutzen, ohne die Einrichtung für jeden Benutzer zu duplizieren. Checken Sie die Konfiguration gemäß dem dokumentierten Speicherort der Funktion in .codex oder .agents ein:

Typ	Quelle	Verwendungszweck
Konfiguration	Grundlagen der Konfiguration	Repository-Standardwerte für unterstützte lokale Clients festlegen
Regeln	Regeln	Befehle steuern, die außerhalb der Sandbox eine Genehmigung erfordern
Skills	Skills erstellen	Repository-Workflows für unterstützte Clients verfügbar machen

Die Repository-Konfiguration kann Standardwerte und wiederverwendbare Workflows bereitstellen. Sie kann keinen Zugriff auf den Workspace, Modelle, die Platform API oder verbundene Systeme gewähren.

Schritt 5: Codex cloud konfigurieren

Codex cloud verwendet gehostete Umgebungen und verbundene Quellcode-Repositories.

Codex Cloud ist für Enterprise-Workspaces standardmäßig deaktiviert. Bestehende Einstellungen für Use Codex in the cloud werden aus Codex Cloud (Legacy) übernommen: Workspaces, die Cloud bereits aktiviert haben, behalten ihren Zugriff. Bei Workspaces mit deaktivierter Cloud bleibt diese deaktiviert, bis ein Administrator sie aktiviert. Der Zugriff unterliegt weiterhin den Einschränkungen des Rollouts und des Workspaces.

Planen Sie jede Berechtigungsgrenze:

Gewähren Sie der vorgesehenen Benutzergruppe Use Codex in the cloud. Gewähren Sie separat Manage workspace environments den Personen, die im Workspace gemeinsam genutzte Umgebungen erstellen und bearbeiten. Siehe Hinweise zu Workspace-Rollen.
Installieren und konfigurieren Sie die unterstützte Integration des Quellsystems.
Beschränken Sie den Repository-Zugriff im Quellsystem auf die Repositories, die die jeweilige Benutzergruppe benötigt.
Konfigurieren Sie Cloud-Umgebungen, Geheimnisse, Internetzugriff und unterstützte, in der Cloud verwaltete Anforderungen für diese Repositories.
Konfigurieren Sie optionale gehostete Workflows wie Code-Reviews.
Testen Sie den Aufgabenzugriff mit einem repräsentativen Mitglied und die Umgebungsverwaltung mit dem zuständigen Administrator. Überprüfen Sie für jede Person die Workspace-, Umgebungs- und Repository-Berechtigungen.

Cloud-Umgebungen übernehmen weder lokale Geräterichtlinien noch MDM-Einstellungen oder lokalen Netzwerkzugriff. Prüfen Sie unterstützte, in der Cloud verwaltete Anforderungen getrennt von den Anforderungen, die auf dem Computer eines Benutzers installiert sind. Siehe Verbindung zu Diensten herstellen für den Zugriff auf Ziele und Agent Security für Informationen dazu, wie Workspace-Anforderungen Cloud-Umgebungen einschränken.

Codex cloud berücksichtigt die Repository-Berechtigungen und Schutzmaßnahmen, die das verbundene Quellsystem bereitstellt. Der Workspace-Zugriff umgeht diese Kontrollen nicht. Siehe Cloud-Umgebungen für Hinweise zur Einrichtung und Laufzeit.

Schritt 6: Plugins und verbundene Funktionen konfigurieren

Betrachten Sie die Plugin-Installation, gebündelte Skills, konnektorgestützte Funktionen, Konnektoraktionen und die Autorisierung im Quellsystem als separate Entscheidungen. Das Deaktivieren einer konnektorgestützten Funktion deinstalliert nicht zwangsläufig das Plugin oder dessen gebündelte Skills.

Bevor Sie ein Plugin oder einen Skill in die Einführung aufnehmen:

Bestätigen Sie Quelle, verantwortliche Person, vorgesehene Zielgruppe und Überprüfungsdatum.
Prüfen Sie gebündelte Skills, Konnektoren, MCP server, Hooks sowie die Daten und Aktionen, die jede Funktion benötigt.
Testen Sie die Funktion mit nicht sensiblen Daten und den geringstmöglichen erforderlichen Zugriffsrechten.
Dokumentieren Sie, wer für die erneute Überprüfung und Außerbetriebnahme verantwortlich ist.

Plugins funktionieren in Chat und Work in ChatGPT im Web, auf Desktopgeräten und Mobilgeräten, in Codex in der ChatGPT-Desktop-App sowie über den Plugin-Browser der Codex CLI. In der IDE-Erweiterung sind sie nicht verfügbar. ChatGPT und Codex nutzen ein gemeinsames universelles öffentliches Plugin-Verzeichnis; die Kontrollmechanismen des Arbeitsbereichs bestimmen, auf welche dieser Plugins Mitglieder zugreifen können.

Das vollständige Modell finden Sie unter Plugin-Steuerelemente und Skill-Steuerelemente.

Schritt 7: Governance und Beobachtbarkeit einrichten

Wählen Sie die Berichtsoberfläche passend zur jeweiligen Fragestellung aus:

Verwenden Sie Workspace-Analysen für interaktive ChatGPT-Workspace-Analysen und Codex-Analysen.
Verwenden Sie die Analytics API für programmatische, aggregierte Berichte über die Codex Analytics API.
Verwenden Sie die Compliance API für Audit- und Untersuchungsdatensätze.
Verwenden Sie ChatGPT-Nutzungslimits und Ausgabensteuerung, wenn tarifabhängige Codex-Aktivitäten berechtigte ChatGPT-Workspace-Guthaben verbrauchen.

Nutzen Sie beim Erstellen einer Integration die nach Authentifizierung zugänglichen API-Referenzen für aktuelle Zugriffsanforderungen, Schemas, Felder, Aufbewahrungsfristen und das Anfrageverhalten.

Schützen Sie die Integrationsgrenze:

Speichern Sie API keys und andere Integrationsanmeldedaten im Geheimnisverwaltungssystem der Organisation.
Beschränken Sie den Zugriff auf nachgelagerte Systeme und gespeicherte Daten auf die genehmigte Zielgruppe.
Schützen Sie exportierte Datensätze der Compliance API gemäß ihrer Sensibilität und der Aufbewahrungsrichtlinie der Organisation und testen Sie Erfassungs- und Löschworkflows anhand des aktuellen Vertrags.

Schritt 8: Einführung überprüfen und pflegen

Erstellen Sie nach dem Aktivieren des lokalen Computerzugriffs mit Work Cloud eine neue Aufgabe und setzen Sie die Unterhaltung auf einem anderen unterstützten Gerät fort. Bestehende Aufgaben werden nicht migriert und behalten ihr ursprüngliches, ausschließlich lokales oder ausschließlich cloudbasiertes Verhalten bei. Lassen Sie den Computer für Schritte, die seine Dateien oder Tools benötigen, online. Testen Sie eine Aktion, die die Richtlinie erlauben sollte, und eine Aktion, die sie blockieren sollte. Prüfen Sie dabei die geltenden Genehmigungen sowie Dateisystem- und Netzwerkeinschränkungen getrennt für die lokale Ausführung und die Cloud-Ausführung. Testen Sie außerdem den Start eines neuen Durchlaufs, während der lokale Computer nicht verfügbar ist. Eine geeignete Aufgabe kann in einem Cloud-Container ohne Zugriff auf die lokalen Dateien oder Tools dieses Computers fortgesetzt werden. Während eines Durchlaufs kann eine Aufgabe nicht von der lokalen Ausführung in die Cloud wechseln.

Dokumentieren Sie die wirksamen Einstellungen und das Ergebnis jedes Tests. Wenn eine Einschränkung nicht wie erwartet funktioniert, beheben Sie das Problem, bevor sich Benutzer darauf verlassen. Befolgen Sie das dokumentierte Vorgehen zum Deaktivieren der Synchronisierung. Behandeln Sie den Zugriffsentzug, die Aufgabenunterbrechung und die Datenaufbewahrung als separate Maßnahmen.

Überprüfen Sie jede relevante Grenze mit repräsentativen Identitäten:

ChatGPT-Workspace-Mitgliedschaft, Lizenzplatz und unterstützte Rollenberechtigungen.
Abgedeckte lokale Funktionen in der ChatGPT-Desktop-App, Codex CLI und der IDE-Erweiterung, einschließlich Anmeldung und tatsächlich geltender Laufzeitanforderungen.
Zugriff auf Codex cloud, Umgebungskonfiguration und Repository-Berechtigungen.
Organisations- und Projektzugriff auf die Platform API für API key-Workflows.
Plugin-Installation, gebündelte Skills, Konnektorzugriff und unterstützte Aktionen.
Autorisierung und Datenzugriff in verbundenen Systemen.
Analyse- und Compliance-Zugriff für die verantwortlichen Administratoren.

Dokumentieren Sie für jedes Steuerelement die verantwortliche Person und die aktuelle Verfahrensquelle. Diese Dokumentation ermöglicht Administratoren, Verfahren bei Änderungen der Benutzeroberfläche oder Richtlinien zu aktualisieren, ohne das Administrationsmodell zu ändern.

Überprüfen Sie nach der anfänglichen Einführung den Zugriff, verbundene Funktionen, die Guthabennutzung, Support-Rückmeldungen und die Workflows, die Teams tatsächlich verwenden. Passen Sie den Einführungsumfang und die Anleitungen für Administratoren an, wenn sich diese Signale ändern.

Wenn Sie den lokalen Computerzugriff mit Work Cloud deaktivieren müssen

Wenn Sie den lokalen Computerzugriff mit Work Cloud deaktivieren, werden laufende Durchläufe unterbrochen. Benutzer können in einer bestehenden Cloud-Unterhaltung einen neuen Durchlauf starten. Dieser verwendet automatisch Work Cloud ohne Zugriff auf lokale Dateien. Weisen Sie Benutzer an, nach der Unterbrechung einen neuen Durchlauf zu starten, und erklären Sie, dass lokale Dateien dem Cloud-Thread nicht mehr zur Verfügung stehen.

Letzte Suchanfragen

Suchvorschläge

Dokumentationsnavigation