OpenAI-API-Vorfälle diagnostizieren, ohne Zugangsdaten offenzulegen

Ein Vorfall mit der OpenAI API lässt sich leichter diagnostizieren, wenn Logs betriebliche Hinweise enthalten, ohne Zugangsdaten oder unnötige Kundendaten zu erfassen. Beginnen Sie mit dem Fehlersignal – etwa einem nicht erfolgreichen Status, einem Timeout oder einer Anwendungsausnahme – und gleichen Sie es anschließend mit einer Anfragekennung und der betroffenen Bereitstellung ab. Halten Sie den API-Schlüssel aus Umgebungen heraus, in denen nicht vertrauenswürdiger oder von einem Agent generierter Code darauf zugreifen kann.

Einen sicheren Diagnoseeintrag erstellen

Halten Sie für jeden API-Aufruf nur die Informationen fest, die nötig sind, um vier Fragen zu beantworten: Wann ist es passiert? Welcher Workload hat die Anfrage gestellt? Welche Art von Fehler ist aufgetreten? Lässt sich das Ereignis mit Informationen des Anbieters abgleichen?

Ein nützlicher Eintrag kann einen Zeitstempel, eine eigene undurchsichtige Vorgangs-ID, die Endpoint-Kategorie, den HTTP-Status, die verstrichene Zeit, die Anzahl der Wiederholungsversuche und – sofern zurückgegeben – eine Anbieter-Anfragekennung enthalten. Protokollieren Sie die Ausnahmeklasse oder eine bereinigte Fehlerkategorie, statt ein Ausnahmeobjekt vollständig auszugeben: Manche Bibliotheken fügen dem Ausnahmetext Anfragedetails hinzu. Lassen Sie Prompts, Antworten, Authorization-Header sowie unbearbeitete Anfrage- und Antwortinhalte aus den üblichen Logs heraus, sofern kein geprüftes Verfahren einen konkreten Bedarf und angemessene Schutzmaßnahmen vorsieht.

Der folgende Python-Code ist ein veranschaulichendes Muster, keine getestete Integration. Die Funktion zum Abrufen von Geheimnissen und die Verarbeitung der Antwort hängen von Ihrer Anwendung und Ihrem SDK ab. Der Code vermeidet bewusst, den Anfrageinhalt oder das Zugangstoken zu protokollieren.

import logging
import time
import uuid

logger = logging.getLogger(__name__)


def send_request(client, payload):
    operation_id = str(uuid.uuid4())
    started = time.monotonic()

    try:
        result = client.responses.create(**payload)
        logger.info(
            "openai_request_succeeded",
            extra={
                "operation_id": operation_id,
                "elapsed_ms": round((time.monotonic() - started) * 1000),
                "provider_request_id": getattr(result, "_request_id", None),
            },
        )
        return result
    except Exception as exc:
        # Do not log str(exc), request headers, or payload here.
        logger.error(
            "openai_request_failed",
            extra={
                "operation_id": operation_id,
                "elapsed_ms": round((time.monotonic() - started) * 1000),
                "exception_type": type(exc).__name__,
            },
        )
        raise

Prüfen Sie vor der Übernahme dieses Musters, wie Ihr Client Anfragekennungen bereitstellt und ob seine Ausnahmemeldungen sensible Daten enthalten können. Wenden Sie dieselben Regeln zur Schwärzung in Traces, Fehlermeldungen, Proxy-Logs und Support-Paketen an. Nur die Anwendungslogs zu bereinigen, reicht nicht aus.

Fehlersignale nutzen, um die Ursache einzugrenzen

Ein Statuscode oder eine Ausnahme ist ein Hinweis, aber noch keine vollständige Diagnose. Häufen sich Authentifizierungsfehler nach einer Bereitstellung, kann das auf fehlende, ungültige oder falsch übermittelte Zugangsdaten hindeuten. Steigt die Zahl der Rate-Limit-Antworten, haben sich möglicherweise Anfragevolumen oder Parallelität verändert. Bei Timeouts kommen Netzwerkzugriff, Verzögerungen beim Upstream oder ein zu kurz eingestellter Client-Timeout infrage. Eine erfolgreiche Antwort des Anbieters, auf die eine fehlgeschlagene Benutzeranfrage folgt, kann dagegen auf ein Problem beim Parsen in der Anwendung oder bei einem nachgelagerten Dienst hindeuten.

Vergleichen Sie Fehlerrate und Latenz vor und nach einer Bereitstellung und schlüsseln Sie die Ergebnisse nach Workload oder Umgebung auf. Gruppieren Sie nicht nach geheimen Werten und protokollieren Sie diese auch nicht, um zu „prüfen“, ob zwei Systeme denselben Schlüssel verwenden. Wenn Sie feststellen müssen, welche Zugangsdaten ein Dienst verwendet, prüfen Sie den Verweis im Secret Manager und die Bereitstellungskonfiguration über einen autorisierten Weg.

Zugangsdaten trennen und einschränken

Die Sandbox-Sicherheitshinweise von OpenAI empfehlen isolierte Rechenumgebungen, getrennte Umgebungen für Workloads, die keine Daten gemeinsam nutzen dürfen, sowie ein eigenes OpenAI-Projekt für eine Anwendung oder einen Workload. Außerdem unterscheiden sie zwischen einem API-Schlüssel für Anwendungen und einem Schlüssel für die Executor-Umgebung: Letzterer dient der Verbindung von Umgebungen und berechtigt nicht zu anderen API-Aktionen. Die Hinweise führen bestimmte Berechtigungen für Agents-API-Sitzungen, Inferenz und die Vault-Verwaltung auf. Erteilen Sie nur die Berechtigungen, die der jeweilige Workload benötigt. Weitere Informationen finden Sie in den Sandbox-Sicherheitshinweisen von OpenAI.

Bewahren Sie den Anwendungsschlüssel außerhalb einer Umgebung auf, in der von einem Agent generierter Code darauf zugreifen kann. Betten Sie Schlüssel weder in Quellcode noch in Container-Images oder Logs ein. Für Zugangsdaten von Drittanbietern empfehlen die Hinweise, Geheimnisse außerhalb der Umgebung aufzubewahren und sie über einen vertrauenswürdigen Mechanismus bereitzustellen, beispielsweise – sofern geeignet – über einen Proxy oder einen Vault. Ein in eine Umgebung eingebundenes Geheimnis bleibt für den dort ausgeführten Code verfügbar; allein durch das Einbinden ist es also nicht vor diesem Code geschützt.

Ein Verfahren zum Austausch von Zugangsdaten festlegen

Halten Sie die folgenden Schritte schriftlich fest und üben Sie sie vor einem Vorfall:

1. Vorbereiten: Ermitteln Sie die verantwortliche Stelle, Berechtigungen, nutzenden Dienste und den Speicherort im Secret Manager. Klären Sie, wer Zugangsdaten erstellen, bereitstellen und widerrufen darf.
2. Ersetzen: Erstellen Sie neue Zugangsdaten mit ausschließlich den erforderlichen Berechtigungen. Speichern Sie sie im genehmigten Secret Manager – nicht in einem Ticket, Chat oder Quellcode-Repository.
3. Bereitstellen: Aktualisieren Sie den betreffenden Workload über den üblichen Release-Prozess. Ist eine Überschneidung zulässig, behalten Sie die alten Zugangsdaten nur für das kürzestmögliche Überprüfungsfenster bei.
4. Überprüfen: Führen Sie eine Anfrage mit geringem Risiko aus und prüfen Sie Erfolg, Fehlerrate und Logs. Vergewissern Sie sich, dass kein Dienst mehr von den alten Zugangsdaten abhängt.
5. Widerrufen und prüfen: Widerrufen Sie die alten Zugangsdaten. Wird eine Offenlegung vermutet, haben Widerruf und Untersuchung der betroffenen Workloads und Logs Vorrang; warten Sie nicht auf den nächsten regulären Rotationstermin.

Schlagen Anfragen direkt nach dem Austausch fehl, prüfen Sie, ob der Dienst die neuen Geheimnisse tatsächlich erhalten hat, ob er neu gestartet wurde oder den Zugriff auf Geheimnisse aktualisiert hat und ob die neuen Zugangsdaten die passenden Berechtigungen besitzen. Beheben Sie einen Berechtigungsfehler nicht durch weitreichende Zugriffsrechte, ohne zuvor die erforderliche Aktion zu bestätigen.

Kompakte Checkliste für Vorfälle

• Beschränkt sich der Fehler auf einen bestimmten Workload, eine Umgebung oder ein Release?
• Zeigen Status, Latenz, Anzahl der Wiederholungsversuche und sichere Anfragenkennungen ein Muster?
• Sind die Logs frei von Authorization-Headern, Schlüsseln und unnötigen Prompt- oder Antwortinhalten?
• Werden die Zugangsdaten über einen genehmigten Weg zur Geheimnisverwaltung gespeichert und bereitgestellt?
• Können Sie die Zugangsdaten austauschen und widerrufen, ohne nicht betroffene Dienste zu ändern?

Es geht nicht darum, alles zu protokollieren. Ziel ist es, genügend sichere Hinweise zu behalten, um Fehler bei Zugangsdaten, Datenverkehr, Netzwerk und Anwendung voneinander zu unterscheiden – und Zugangsdaten schnell auszutauschen, falls eine Offenlegung vermutet wird.