OpenAI-API-Schlüssel verwalten: Erstellungsregeln, Eigentümer, Ablauf und Rotation ohne Ausfall
OpenAI führte im September 2026 Organisations- und Projektregeln für die Erstellung neuer API-Schlüssel sowie Ablaufdaten und maximale Laufzeiten ein. Dieser Leitfaden erklärt den Vorrang der Richtlinien, die Wahl des Eigentümers, die Migration alter Schlüssel und eine überlappende Rotation ohne Anwendungsunterbrechung.
Inhalt
Sie möchten OpenAI-API-Schlüssel mit Ablaufregeln versehen, ohne dass eine neue Richtlinie eine Anwendung stoppt oder bei der nächsten Rotation plötzlich der passende Ersatzschlüssel nicht mehr erstellt werden kann. Gleichzeitig müssen Sie entscheiden, ob Produktion Dienstkontoschlüssel und persönliche Entwicklung benutzereigene Schlüssel verwenden soll.
Dieser Leitfaden gibt Ihnen eine praktische Reihenfolge: Eigentum nach Arbeitslast wählen, eine tatsächlich betreibbare Lebensdauer festlegen und alte Schlüssel mit einer kontrollierten Überlappung ersetzen. Behalten Sie zwei Fakten im Blick: Neue Erstellungsregeln ändern bestehende Schlüssel nicht, und Organisationsbeschränkungen haben Vorrang vor Projekteinstellungen.
Zuerst die Antwort: Die neuen Kontrollen regeln künftige Schlüssel, nicht alte
Die September-Änderungen lassen sich in zwei Kontrollen aufteilen: welche neuen Schlüsseltypen ausgegeben werden dürfen und wie lange neue Projektschlüssel gültig bleiben.
| Datum | OpenAI-Änderung | Operative Bedeutung |
|---|---|---|
| 10. September 2026 | Projektschlüssel können mit Ablaufdatum erstellt werden. Administratoren können auf Organisations- oder Projektebene eine maximale Lebensdauer festlegen. | Neue Schlüssel müssen nicht mehr unbegrenzt gelten; vor kurzen Fristen braucht das Team aber einen wiederholbaren Rotationsprozess. |
| 15. September 2026 | Organisationen und Projekte können nur service-account keys, nur user-owned project keys oder überhaupt keine neuen API-Schlüssel zulassen. | Produktionsdienste, persönliche Entwicklung und eingefrorene Projekte können unterschiedliche Ausgaberegeln erhalten. |
| 15. September 2026 | Organisationsbeschränkungen haben Vorrang vor Projekteinstellungen. | Ein Projekt kann strenger sein, aber die Organisationsregel nicht lockern. |
| 15. September 2026 | Bestehende API-Schlüssel bleiben von den neuen Erstellungsregeln unberührt. | Das Aktivieren einer Regel widerruft keine alten Schlüssel und erledigt keine Altbestandsmigration. |
Zwei Grenzen sind wichtig. „Keine neuen Schlüssel erstellen“ bedeutet nicht „alle vorhandenen Schlüssel widerrufen“. Außerdem beschreibt das Update vom 10. September die maximale Lebensdauer für neu erstellte Schlüssel. Gehen Sie nicht davon aus, dass ein alter Schlüssel rückwirkend ein Ablaufdatum erhält, ohne dies im konkreten Projekt zu prüfen.
Trennen Sie drei Entscheidungen: Wer erstellt, wie lange gilt der Schlüssel und wie wird er abgelöst?
Entwerfen Sie diese drei Entscheidungen getrennt; ein einzelner Platform-Schalter verwaltet nicht den gesamten Lebenszyklus.
Die Ausgaberichtlinie bestimmt, ob Dienstkontoschlüssel, benutzereigene Projektschlüssel oder keine neuen Schlüssel erstellt werden dürfen.
Die Ablaufrichtlinie bestimmt, ob ein neuer Schlüssel ablaufen muss und welche maximale Lebensdauer Organisation und Projekt erlauben.
Die Lebenszyklusausführung bestimmt, wer einen Ersatz erstellt, wo das Geheimnis gespeichert wird, wie Anwendungen es erhalten, welche Nachweise den Wechsel bestätigen, wann der alte Schlüssel widerrufen wird und wie ein fehlgeschlagener Rollout zurückgesetzt wird.
Die ersten beiden Ebenen können in der OpenAI Platform erzwungen werden. Die dritte hängt weiterhin vom Secret Manager, dem Deployment-Prozess, der Observability, den Verantwortlichkeiten und den Incident-Abläufen ab. Eine maximale Lebensdauer ohne Rotationsverantwortlichen und ausreichenden Vorlauf verwandelt eine Sicherheitskontrolle in einen geplanten Ausfall.
Nach Einsatz wählen: Dienstkonto für Produktion, Benutzerschlüssel für persönliche Entwicklung
Bevorzugen Sie einen service-account key für Produktion und geteilte Arbeitslasten, einen user-owned project key für lokale oder kurzfristige Arbeit und deaktivieren Sie die Ausgabe nur für tatsächlich eingefrorene oder auslaufende Projekte.
| Einsatz | Meist geeigneter Typ | Begründung | Wichtigstes Risiko |
|---|---|---|---|
| Produktionsdienst, gemeinsames Backend, geplanter Job, teamverwalteter Agent | service-account key | Die Anmeldedaten gehören zur Arbeitslast und nicht zu einer einzelnen Person; Personalwechsel gefährden die Kontinuität weniger. | Ein Dienstkonto für viele unabhängige Anwendungen vergrößert den Wirkungsbereich. Nach Projekt oder Arbeitslast trennen. |
| Lokale Entwicklung, kurzfristiges Debugging, exploratives Skript | user-owned project key | Eigentümer und individuelle Verantwortlichkeit sind klar; Offboarding kann die Schlüssel des Nutzers einschließen. | Ein persönlicher Schlüssel darf nicht unbemerkt zur gemeinsamen Produktionsabhängigkeit werden. |
| Archiviertes, auslaufendes oder vorübergehend eingefrorenes Projekt | Neue Schlüssel deaktivieren | Verhindert, dass der Bestand während Stilllegung oder Untersuchung weiter wächst. | Ein zu früher Freeze kann den Ersatzschlüssel für Rotation oder Wiederherstellung blockieren. |
Eine hilfreiche Frage lautet: Soll die Anwendung weiterlaufen, wenn eine bestimmte Person das Team verlässt? Falls ja, sollten Produktionszugänge in der Regel nicht von deren Benutzerkonto abhängen. Umgekehrt schwächt ein gemeinsamer Dienstkontoschlüssel auf allen Entwicklergeräten die Zuordnung und vervielfacht die Kopien des Geheimnisses.
Kein Typ ist automatisch sicher. Der tatsächliche Schutz hängt von Umfang, Speicherung, Zugriff, Lebensdauer, Rotation und Widerruf ab. Ein langlebiger Dienstkontoschlüssel, der in Dutzenden Anwendungen steckt, bleibt ein großer einzelner Risikopunkt.
Die Organisation setzt die Obergrenze: Projekte dürfen strenger, nicht lockerer sein
Eine Organisationsbeschränkung ist die Obergrenze für jedes Projekt; testen Sie deshalb die nächste Rotation, bevor Sie sie breit anwenden.
Erlaubt eine Organisation nur Dienstkontoschlüssel, kann ein Entwicklungsprojekt nicht über seine eigene Einstellung benutzereigene Projektschlüssel freigeben. Ein Projekt darf innerhalb der Organisationsgrenze weiter einschränken, aber nicht lockern.
Vor einer organisationsweiten Änderung sollten Sie:
- alle Projekte erfassen und als Produktion, Staging, Entwicklung, Test, temporär, archiviert oder in Stilllegung klassifizieren;
- für jedes Projekt den Schlüsseltyp festhalten, der bei der nächsten Rotation benötigt wird – nicht nur den aktuellen Bestand;
- den Ersatz für jede aktive Arbeitslast identifizieren und prüfen, ob die geplante Organisationsregel seine Erstellung erlaubt;
- Erstellung, Verteilung, Validierung und Widerruf in einem risikoarmen Projekt proben;
- die Organisationsregel erst anwenden, wenn eine normale Rotation nachweislich möglich bleibt.
Da bestehende Schlüssel weiter funktionieren, kann eine zu strenge Regel am Tag der Aktivierung harmlos wirken. Das Problem zeigt sich später, wenn ein Schlüssel abläuft und kein passender Ersatz erstellt werden darf. Prüfen Sie die nächste Rotation, nicht nur den aktuellen erfolgreichen Traffic.
Nicht überall dieselbe Laufzeit: Beginnen Sie mit der Dauer einer echten Rotation
Die maximale Lebensdauer muss länger sein als die gesamte Zeit für Freigabe, Ausgabe, Verteilung, Deployment, Beobachtung und Rollback.
Definieren Sie für jede Projektklasse mindestens:
| Feld | Zu beantwortende Frage |
|---|---|
Maximale Lebensdauer N | Wie lange darf ein neuer Schlüssel zwischen Erstellung und Ablauf bestehen? |
Rotationsvorlauf R | Wie lange vor Ablauf muss der Ersatz beginnen? |
| Haupt- und Ersatzverantwortlicher | Wer handelt, und wer übernimmt bei Abwesenheit? |
| Verteilung | Kann die Anwendung eine neue Secret-Version laden oder braucht sie Neustart/Deployment? |
| Validierungsnachweis | Welche Requests, Logs, Fehler- und Nutzungsdaten belegen die Traffic-Übernahme? |
| Rollback-Fenster | Wie lange bleibt der alte Schlüssel nach dem Wechsel gültig? |
| Ausnahmeprozess | Wer darf wie lange verlängern und mit welchen kompensierenden Maßnahmen? |
R muss den gesamten Ablauf abdecken. Eine extrem kurze Lebensdauer mit manuellen Kopiervorgängen, Freigaben über Zeitzonen hinweg und ohne Vertretung ist unzuverlässiger als eine etwas längere Frist mit automatischen Warnungen und geübtem Runbook.
Verwenden Sie den Organisationswert als gemeinsamen Höchstwert. Risikoreiche Projekte können einen kürzeren Projektwert setzen, nie einen längeren. Produktion, persönliche Entwicklung, temporäre Tests und auslaufende Projekte haben unterschiedliche Auswirkungen und Wiederherstellungsgeschwindigkeiten und müssen daher nicht dieselbe interne Zahl verwenden.
Mit diesen sieben Schritten ohne Ausfall rotieren
Am sichersten laufen alter und neuer Schlüssel kurz parallel; der alte wird erst widerrufen, wenn echter Traffic den Wechsel bestätigt.
1. Bestand aufnehmen
Erfassen Sie Projekt, Eigentumstyp, Arbeitslast, Anwendung, Umgebung, verantwortliche Person, Speicherort, Deployment-Art, Erstellungsdatum, bekanntes Ablaufdatum und zuletzt beobachtete Nutzung. Ein Schlüssel mit unbekanntem Zweck oder Eigentümer gehört in eine priorisierte Untersuchung statt in einen blinden Massenwiderruf.
Im Changelog vom 4. August 2026 steht, dass Usage- und Costs-Dashboards sowie Usage API und Costs API nach API-Schlüssel filtern und gruppieren können. Diese Dimension hilft zu erkennen, ob ein Schlüssel noch Requests erzeugt. Sie ist aber nur ein Signal: seltene Batch-Jobs, Disaster-Recovery-Pfade oder monatliche Prozesse können lange still sein.
2. Konformen Ersatz erstellen
Erstellen Sie im vorgesehenen Projekt einen neuen Schlüssel mit dem durch Organisation und Projekt erlaubten Eigentumstyp. Das Ablaufdatum darf die geltende Höchstgrenze nicht überschreiten. Prüfen Sie die Ausgabe vor dem Wartungsfenster.
3. Als neue Secret-Version speichern
Überschreiben Sie nicht sofort den einzigen alten Wert. Halten Sie während des kontrollierten Übergangs beide Versionen mit klaren Zuständen wie „aktuelle Produktion“, „Rotationskandidat“ und „Widerruf ausstehend“. Schlüssel gehören nicht in Quellcode, Images, Tickets, Logs oder Chats.
4. Traffic schrittweise verlagern
Beginnen Sie mit einer Instanz, einem risikoarmen Job oder einem kleinen Traffic-Anteil. Prüfen Sie Authentifizierung, Projektzuordnung, Berechtigungen und Request-Verhalten, bevor Sie erweitern. Liest die Anwendung das Geheimnis nur beim Start, müssen Neustarts und Kapazität eingeplant werden.
5. Anwendung und Nutzung pro Schlüssel beobachten
Kontrollieren Sie erfolgreiche Requests, Authentifizierungsfehler, Limits, Latenz und fachliche Ergebnisse. Bestätigen Sie gleichzeitig, dass der neue Schlüssel erwartete Nutzung erzeugt und die alte zurückgeht. Ein erfolgreich markiertes Deployment beweist noch keinen Traffic-Wechsel.
6. Rollback-Fenster zeitlich begrenzen
Bewahren Sie den alten Schlüssel nach Stabilisierung für einen vorher definierten Zeitraum auf und widerrufen Sie ihn anschließend. Das Fenster muss verzögerte Worker, Regionen und seltene Aufgaben abdecken, darf aber nicht unbegrenzt offenbleiben. Dauerhafter Doppelbetrieb verdoppelt nur die Zahl gültiger Geheimnisse.
7. Widerrufen, prüfen und nächste Rotation planen
Bestätigen Sie nach dem Widerruf, dass der alte Schlüssel fehlschlägt und der neue weiter funktioniert. Aktualisieren Sie Inventar, Bereitschaftshinweise, Eigentümer, Ablauf und nächsten Rotationstermin.
Alte Schlüssel werden nicht automatisch konform: Migrieren Sie nach Risiko
Nach Aktivierung der neuen Regeln brauchen alte Schlüssel weiterhin eine eigene Migrationswarteschlange, weil Eigentümer und Laufzeit unverändert bleiben.
Führen Sie eine eigene Migrationswarteschlange und priorisieren Sie:
- Schlüssel, die in Code, Tickets, Logs oder Chats aufgetaucht sind;
- Schlüssel mit unbekanntem Eigentümer oder Zweck;
- benutzereigene Schlüssel ausgeschiedener oder versetzter Personen;
- Schlüssel, die mehrere Produktionsanwendungen gemeinsam nutzen;
- Schlüssel mit weitem Umfang oder hohem Schadenpotenzial;
- Schlüssel mit klarem Eigentümer, einer Arbeitslast und getestetem Ersatzpfad.
Erfolg bedeutet nicht, alle alten Schlüssel an einem Tag zu widerrufen. Sicherer ist: Jeder Schlüssel besitzt eine Abhängigkeitskarte, einen genehmigten Ersatz, Belege für die Umschaltung und einen Widerrufstermin. Für vorübergehende Ausnahmen dokumentieren Sie konkreten Blocker, Eigentümer, kompensierende Kontrolle und Enddatum. „Legacy-System“ ist keine dauerhafte Ausnahme.
Ihre interne Richtlinie braucht mindestens diese 11 Felder
Eine ausführbare Richtlinie nennt Regel, Verantwortlichen, Validierungsnachweise, Rollback-Fenster und Widerrufsbedingung – nicht nur eine Laufzeit.
| Richtlinienpunkt | Zu dokumentieren |
|---|---|
| Geltungsbereich | Organisation, Projekte, Umgebungen und Arbeitslastklassen |
| Zulässiger neuer Typ | Nur Dienstkonto, nur Benutzer oder keine neuen Schlüssel |
| Begründung | Kontinuität, individuelle Zuordnung, Freeze oder anderer dokumentierter Grund |
| Maximale Lebensdauer | Organisationsgrenze und strengere Projektgrenzen |
| Vorlauf | Zeitpunkt für Warnung oder Ticket vor Ablauf |
| Speicherung | Genehmigter Secret Manager und Zugriffsrollen |
| Deployment | Canary/Phasen, Neustart und Rollback |
| Nachweise | Erfolgreiche Requests, Fehlermetriken, Nutzung pro Schlüssel und alter Traffic bei null |
| Widerrufsbedingung | Neuer Schlüssel stabil, seltene Jobs abgedeckt, Rollback-Fenster beendet |
| Ausnahme | Genehmiger, Grund, Kompensation und Ausnahmeablauf |
| Audit | Erstellung, Richtlinienänderung, Deployment, Widerruf und Eigentümerwechsel |
Langfristige Verantwortung sollte einer Arbeitslast oder Teamrolle zugeordnet werden, zugleich braucht jede Rotation eine konkrete ausführende Person. „Das Plattformteam kümmert sich“ ist ohne Bereitschaftsweg, Frist und Eskalation nicht operativ.
Vor der Durchsetzung die nächste Rotation proben
Setzen Sie Organisations- oder Projektbeschränkungen erst durch, wenn alle folgenden Punkte geklärt sind und eine risikoarme Probe abgeschlossen ist.
- jede aktive Anwendung einem konkreten Projekt und Schlüssel zugeordnet ist;
- der bei der nächsten Rotation benötigte Typ pro Projekt bekannt ist;
- die Organisationsregel keinen kritischen Ersatz blockiert;
- Produktion nicht vom persönlichen Schlüssel einer einzelnen Person abhängt;
- der Secret Store Versionierung oder einen anderen verlässlichen Rollback unterstützt;
- das Laden eines neuen Geheimnisses einschließlich möglichem Neustart getestet wurde;
- Nutzung oder Kosten pro Schlüssel beobachtbar sind und seltene Jobs berücksichtigt werden;
- Haupt- und Ersatzverantwortliche benannt sind;
- Ablaufwarnungen früh genug eintreffen;
- Widerrufskriterien dauerhafte Überlappung verhindern;
- jeder offene Altschlüssel einen konkreten Blocker, Eigentümer und Termin hat.
Häufige Fragen
Bricht eine neue Erstellungsregel bestehende Anwendungen sofort?
Laut OpenAI-Eintrag vom 15. September 2026 bleiben bestehende API-Schlüssel unberührt. Die Änderung zulässiger neuer Schlüssel widerruft aktive Schlüssel nicht automatisch. Sie kann jedoch die nächste Rotation blockieren, daher sollte die Ersatzschlüsselerstellung vorher geprobt werden.
Läuft die maximale Lebensdauer rückwirkend für alte Schlüssel?
Das Update vom 10. September beschreibt die Anforderung für neue Schlüssel. Unterstellen Sie keine rückwirkende Frist, sondern prüfen Sie die Details und migrieren Sie alte Schlüssel separat.
Kann ein Projektadministrator die Organisationsregel lockern?
Nein. Die Organisationsbeschränkung hat Vorrang vor den Projekteinstellungen.
Sollte die gesamte Organisation nur Dienstkontoschlüssel verwenden?
Bevorzugen Sie Dienstkontoschlüssel für Produktionsdienste, gemeinsame Backends, geplante Jobs und teamverwaltete Agenten. Bevorzugen Sie benutzereigene Projektschlüssel für lokale Entwicklung und kurzfristige Erkundung. Eine organisationsweite Beschränkung auf Dienstkontoschlüssel ist nur sinnvoll, wenn fast alle Projekte zur ersten Gruppe gehören und die Entwicklung bereits eine praktikable Alternative hat.
Wann sollten neue Schlüssel vollständig deaktiviert werden?
Bei archivierten oder auslaufenden Projekten oder vorübergehend während einer Sicherheitsuntersuchung. Vergewissern Sie sich vorher, dass kein Ersatz für Rotation oder Wiederherstellung benötigt wird.
Was beweist, dass ein alter Schlüssel widerrufen werden kann?
Kombinieren Sie Rollout-Status, erfolgreiche Requests mit dem neuen Schlüssel, Fehlermonitoring, Nutzung pro Schlüssel, Ausführung seltener Jobs und den Abschluss des Rollback-Fensters. Ein kurzer Zeitraum ohne Traffic genügt normalerweise nicht.
Womit Sie beginnen sollten
Beginnen Sie mit drei Schritten: Erfassen Sie den Schlüsseltyp, den jedes Projekt bei der nächsten Rotation benötigt, führen Sie eine Überlappungsrotation in einem risikoarmen Projekt durch und setzen Sie erst danach Organisations- und Projektbeschränkungen durch.
Die Reihenfolge ist entscheidend. Wenn Sie zuerst die Obergrenze setzen, können aktuelle Anwendungen weiterlaufen, während die Richtlinie den später benötigten Ersatz still blockiert. Beweisen Sie zuerst, dass die nächste Rotation funktioniert, und verschärfen Sie dann die Regeln.
Offizielle Quelle:
