AWS erklärt kontrollierte ChatGPT-Desktop-Inferenz über Bedrock GovCloud mit getrennter Identitäts- und Geräteprüfung
AWS veröffentlichte am 30. Oktober eine Anleitung, um Modell-Inferenz der ChatGPT-Desktop-App über Amazon Bedrock in AWS GovCloud (US) zu leiten. Diese technische Ausgabe vom 1. November lässt das Originaldatum unverändert. Der Leitfaden richtet sich an Organisationen, die GovCloud-Identitäten, Endpunkte und regionale Kontrollen benötigen, und beschreibt eine kontrollierte lokale Prüfung über Bedrock Mantle in `us-gov-west-1`.
AWS veröffentlichte am 30. Oktober eine Anleitung, um Modell-Inferenz der ChatGPT-Desktop-App über Amazon Bedrock in AWS GovCloud (US) zu leiten. Diese technische Ausgabe vom 1. November lässt das Originaldatum unverändert. Der Leitfaden richtet sich an Organisationen, die GovCloud-Identitäten, Endpunkte und regionale Kontrollen benötigen, und beschreibt eine kontrollierte lokale Prüfung über Bedrock Mantle in `us-gov-west-1`. AWS stellt ausdrücklich klar, dass weder die Anleitung noch GovCloud allein eine Arbeitslast genehmigen. Jede Organisation muss Modell, Dienste, Gerät, Repositories, Zugangsdaten und Datenflüsse nach ihrem eigenen Sicherheitsverfahren prüfen.
Die Desktop-Anwendung hat zwei Anwendungsbereiche. Work ist für größere Aufgaben mit Planung, Recherche und Dateien vorgesehen; Codex für Codeänderungen, Tests und Pull-Request-Reviews. App oder CLI laufen auf einem von der Organisation verwalteten Computer und verwenden die konfigurierte AWS-Identität für Bedrock-Anfragen. In diesem direkten AWS-Modus bestimmen laut AWS Gerätepolitik sowie IAM-Identität und Berechtigungen die Steuerung, nicht die üblichen Rollen eines ChatGPT-Arbeitsbereichs. Der Beitrag beschreibt Verarbeitung in der gewählten Region, Token-Abrechnung ohne Sitzplatzbindung und unterstützte Zero Data Retention. Diese Eigenschaften müssen für die tatsächlich genehmigte Konfiguration überprüft werden.
Vorbedingungen gehen über die Installation hinaus. Die genaue App-Version muss GovCloud unterstützen; ein genehmigtes Konto und eine IAM-Identität sowie Rechte für Modell, Region und Endpunkt sind erforderlich. Der Ablauf umfasst Authentifizierung, die Dateien `requirements.toml` und `config.toml`, anschließend Start und Prüfung. Das Beispielprofil `codex-il5` ist lediglich ein Konfigurationsname und kein übertragbarer Zugang. Kennwörter, Bearer- und Sitzungstokens gehören nicht in TOML-Dateien. Profilkonfiguration, SSO-Cache und Hilfsprogramme zur Anmeldung müssen gegen Schreibzugriffe der Aufgaben geschützt werden.
Bei der Authentifizierung gilt eine Vorrangregel. Zuerst prüft die App `AWS_BEARER_TOKEN_BEDROCK` in ihrer Umgebung. Ist ein Bearer-Token vorhanden, hat er Vorrang vor einem Profil. Fehlt er, nutzt die Anwendung die normale AWS-SDK-Zugangskette mit benanntem Profil und gegebenenfalls einer IAM-Identity-Center-SSO-Sitzung. Ein richtig angezeigter Profilname beweist deshalb nicht, welcher AWS-Prinzipal die Anfrage tatsächlich ausführt. Bei einer falschen Identität müssen die wirksame Quelle und ein möglicher Token-Vorrang geprüft werden. Die Anmeldung im API-Modus allein setzt weder die Richtlinie für Gerätefunktionen noch die Netzwerkbeschränkungen durch.
Die beiden Konfigurationsdateien sollen vor dem ersten App-Start vorhanden sein. Wurde die App bereits geöffnet, verlangt AWS das vollständige Beenden und erneute Starten, damit Richtlinie und Provider neu geladen werden. Das sind Schritte eines möglichen späteren Einsatzes, keine von dieser Redaktion vorgenommenen Eingriffe in einen laufenden Dienst. Anschließend sollen `/status` in Codex CLI und die Desktop-Einstellungen `amazon-bedrock` als Provider zeigen. Zusätzlich sind genehmigte Identität, `us-gov-west-1`, Endpunkt und Netzsperren zu prüfen. Eine Provider-Anzeige allein bestätigt nicht alle Sicherheitsbedingungen.
AWS unterscheidet zwischen unerwarteter OpenAI-Kontoanmeldung, nicht unterstütztem GovCloud-Endpunkt, falscher AWS-Identität und fehlenden Funktionsbeschränkungen. Eine geänderte URL macht eine nicht unterstützte Version nicht kompatibel; API-only ist nicht die vollständige Gerätepolitik. Scheitert eine Prüfung, empfiehlt AWS, die Ausweitung zu stoppen, zu zuvor genehmigten Einstellungen zurückzukehren, temporäre Zugangsdaten zu widerrufen und sicherzustellen, dass betroffene Geräte Bedrock nicht mehr erreichen.
Dieser Artikel hat keinen GovCloud-Arbeitsplatz eingerichtet oder eine behördliche Umgebung geprüft. Belegt ist die von AWS veröffentlichte kontrollierte Konfiguration samt Authentifizierungs- und Geräteregeln. Eine Organisation muss zuerst ihre eigene Genehmigung einholen und dann genaue Unterstützung und Datenverarbeitung anhand des vollständigen Leitfadens und aktueller Dokumentation verifizieren. Verfügbarkeit und optionale Datenhaltung sind keine pauschale Compliance-Zusage für jede Installation.
Sources
FAQ
Was muss vor der GovCloud-Desktop-Einrichtung genehmigt sein?
Prüfen Sie die genaue App-Version sowie das freigegebene Konto, die IAM-Identität, das Modell, den Endpunkt in us-gov-west-1, Geräterichtlinien, Repositories und Datenflüsse. AWS betont, dass weder die Nutzung von GovCloud noch das Befolgen der Anleitung allein eine Arbeitslast autorisiert.
Was hat Vorrang, wenn Bearer-Token und AWS-Profil vorhanden sind?
Die App prüft zuerst AWS_BEARER_TOKEN_BEDROCK; ein vorhandener Token hat Vorrang vor dem benannten Profil. Ohne Token kann die normale AWS-SDK-Zugangskette ein Profil oder eine SSO-Sitzung nutzen. Bei einer falschen Identität ist die tatsächlich wirksame Quelle zu prüfen, nicht nur der sichtbare Profilname.
Wie wird geprüft und nach einem Fehler verfahren?
Die beiden TOML-Dateien gehören vor den ersten Start. Danach müssen /status in der CLI und die Desktop-Einstellungen amazon-bedrock zeigen; Identität, Region und Netzregeln sind zusätzlich zu prüfen. Scheitert ein Test, empfiehlt AWS den Stopp, die Rückkehr zu genehmigten Einstellungen, den Widerruf temporärer Zugänge und die Kontrolle, dass betroffene Geräte nicht mehr verbinden.