So entwerfen Sie LLM-Dienstkonten für Produktions-Workloads

Produktions-LLM-Arbeitslasten sollten sich nicht als Personen authentifizieren. Ein CI-Job, ein Backend-Dienst, ein Agent-Runner, ein Batch-Prozessor oder ein Partner-Gateway benötigt eine eigene nicht-menschliche Identität mit einem klaren Besitzer, einem engen Umfang, einem Budget, einem Prüfpfad und einem Abschaltpfad. Ohne dieses Modell kann ein durchgesickerter Schlüssel zu viele Systeme repräsentieren, durch Offboarding wird der Zugriff nicht entfernt und Nutzungsberichte können nicht erklären, welche Arbeitslast Kosten oder Risiken verursacht hat.

Dieser Leitfaden bietet Technik- und Plattformteams einen praktischen Entwurf für die LLM-Dienstkonto-Governance über Anbieter-APIs und interne Gateways hinweg. Es trennt verifizierte Anbieterfakten von Implementierungsempfehlungen und macht Vorhersagen darüber, wo sich das Betriebsmodell voraussichtlich weiterentwickeln wird.

Was ist ein LLM-Dienstkonto?

Fakt: Dienstkonten sind nichtmenschliche Identitäten, die von Anwendungen und Arbeitslasten und nicht von einzelnen Benutzern verwendet werden. OpenAI API Projekte unterstützen projektbezogene Dienstkonten und API Schlüssel. Anthropic beschreibt Dienstkonten als benannte nichtmenschliche Identitäten innerhalb einer Organisation. Google Cloud IAM beschreibt Dienstkonten als nichtmenschliche Benutzer für Anwendungen und Arbeitslasten.

Für LLM-Systeme sollte ein Dienstkonto eine Arbeitslastgrenze darstellen: einen Backend-Dienst, eine CI-Workflow-Familie, eine Agent-Laufzeit, eine Batch-Pipeline oder eine Partner-Integrationsebene API. Es sollte nicht eine Person, ein ganzes Unternehmen oder jede Anwendung in einer Umgebung darstellen.

Ein nützlicher Dienstkontodatensatz beantwortet fünf Fragen:

• Welche Anwendung oder welcher Workflow besitzt diese Identität?
• In welcher Umgebung kann es ausgeführt werden?
• Welches Team ist für Kosten, Zugriff und Vorfälle verantwortlich?
• Welche Modelle, Endpunkte, Tools, Datenrichtlinien und Regionen sind zulässig?
• Wie werden die Anmeldeinformationen rotiert, widerrufen oder durch eine Föderation ersetzt?

Wann ein Dienstkonto erstellt werden sollte

Erstellen Sie ein Dienstkonto, wenn der Aufrufer eine operative Software und kein Mensch ist. Häufige Beispiele sind CI/CD-Jobs, die Evaluierungen ausführen, API Produktionsdienste, Dokumentverarbeitungsarbeiter, Copiloten für den Kundensupport, autonome Agentenwarteschlangen, geplante Anreicherungsjobs und interne Entwicklerplattformen, die den LLM-Zugriff für viele Teams vermitteln.

Erstellen Sie nicht für jeden Entwickler, jedes lokale Experiment oder jede Eingabeaufforderung ein neues Dienstkonto. Die menschliche Erforschung gehört zur Benutzeridentität und zu kurzlebigen Entwicklungsnachweisen. Die Zuordnung auf Eingabeaufforderungs- und Funktionsebene kann als Anforderungsmetadaten unter der Workload-Identität erfasst werden.

Eine einfache Entscheidungsregel funktioniert gut:

• Wenn der Anrufer unbeaufsichtigt ausgeführt werden kann, verwenden Sie ein Dienstkonto.
• Wenn der Aufrufer Produktionsdatenverkehr bedient, verwenden Sie ein Dienstkonto pro Arbeitslast und Umgebung.
• Wenn der Anrufer für einen Kunden oder Partner handelt, trennen Sie die Workload-Identität von der delegierten Mandantenidentität.
• Wenn der Anrufer ein Mensch ist, der eine Konsole oder ein Notebook verwendet, verstecken Sie dies nicht hinter einem Produktionsdienstkonto.

Beginnen Sie mit einer Identitätsinventur

Die Migration sollte mit einer Bestandsaufnahme beginnen, nicht mit einer Schlüsselrotation. Teams stellen häufig fest, dass ein Anbieterschlüssel von Produktionsdiensten, Staging-Jobs, lokalen Skripten, Evaluierungspipelines und abgebrochenen Integrationen verwendet wird. Wenn dieser Schlüssel zuerst rotiert wird, entsteht ein Risiko, ohne dass die Eigentumsverhältnisse verbessert werden.

Erstellen Sie ein Inventar mit diesen Kategorien:

• Im Besitz von Menschen befindliche Anbieter-API-Schlüssel.
• Workload-Dienstkonten.
• CI/CD-Identitäten.
• Vom Gateway ausgegebene interne Schlüssel.
• Vom Partner oder Kunden delegierte Schlüssel.
• Zugangsdaten zum Glasbruch im Notfall.
• Unbekannte Schlüssel, die weiterhin genutzt werden.

Für jede Anmeldeinformation, Datensatzanbieter, Projekt oder Arbeitsbereich, Schlüsseleigentümer, verbrauchende Anwendung, Bereitstellungsumgebung, geheimen Speicherort, zulässige Modelle, Ausgabeeigentümer, zuletzt gesehener Zeitstempel und Widerrufsrisiko. Dieses Inventar wird zur Quelle der Wahrheit für LLM API Schlüsselverwaltung, aber Dienstkonten sollten als erstklassige Arbeitslastidentitäten modelliert werden und nicht nur als eine weitere Schlüsselbezeichnung.

Ein Dienstkonto pro Arbeitslastgrenze verwenden

Die wichtigste Designauswahl ist die Granularität. Zu wenige Dienstkonten erzeugen einen gemeinsamen Explosionsradius. Zu viele verursachen Betriebsgeräusche. Die richtige Einheit ist die kleinste Workload-Grenze, die unterschiedliche Eigentümer-, Berechtigungen-, Kostenprofil- oder Vorfallreaktionsanforderungen hat.

Getrennte Dienstkonten verwenden für:

• Produktions- und Nicht-Produktionsumgebungen.
• Verschiedene Anwendungen, die verschiedenen Teams gehören.
• Kundenorientierte Dienstleistungen versus interne Jobs.
• Interaktive Anforderungspfade im Vergleich zu asynchronen Batch-Prozessoren.
• Agent-Laufzeiten, die Tools aufrufen oder Schleifen ausführen können.
• Partner API-Oberflächen, die delegierten Zugriff offenlegen.

Ein praktisches Benennungsmuster ist:

llm-sa-{app}-{env}-{team}-{purpose}

Beispiele:

llm-sa-supportbot-prod-cx-chat
llm-sa-contracts-stg-legal-extract
llm-sa-evals-ci-platform-regression
llm-sa-agentrunner-prod-eng-tools

Verschlüsseln Sie keine Geheimnisse, Kundennamen, Personennamen oder temporäre Ticketnummern im Kontonamen. Fügen Sie stattdessen veränderliche Details in Tags oder Metadaten ein.

Anbieterkonten einem Gateway-Identitätsmodell zuordnen

Fakt: Die Möglichkeiten der Anbieter sind unterschiedlich. OpenAI unterstützt Dienstkonten innerhalb von API Projekten, und Projektdienstkonten gelten nur für das Projekt, in dem sie erstellt werden. Anthropic Arbeitsbereiche können Mitglieder, Dienstkonten, API Schlüssel und Ressourcenlimits enthalten. Anthropic Workload Identity Federation ermöglicht es Arbeitslasten, signierte Identitätstoken anstelle von statischen Anthropic Anmeldeinformationen zu verwenden, wobei Zuordnungs- und Ratenbeschränkungen bei Konfiguration an den Arbeitsbereich gebunden sind.

Empfehlung: Behalten Sie ein Dienstkontomodell auf Gateway-Ebene bei, auch wenn anbieternative Dienstkonten vorhanden sind. Die Gateway-Identität sollte das stabile interne Objekt sein, mit dem Richtlinien, Berichte, Budgets und Prüfnachweise verknüpft sind. Den Anbieteranmeldeinformationen werden dann Implementierungsdetails zugeordnet, die darunter abgebildet sind.

Zum Beispiel:

internal_service_account:
  id: sa_01h_supportbot_prod
  name: llm-sa-supportbot-prod-cx-chat
  owner_team: customer_experience
  environment: production
  app: supportbot
  allowed_models:
    - provider: openai
      model_family: gpt-4.1
    - provider: anthropic
      model_family: claude-sonnet
  data_policy: no_training_required
  monthly_budget_usd: 2500
  provider_bindings:
    openai_project: proj_supportbot_prod
    anthropic_workspace: ws_supportbot_prod

Diese Zuordnung ist in einem Multi-Modell-KI APIGateway wichtig, da Upstream-Anbieter unterschiedliche Kontostrukturen, Abrechnungsfelder, Modellberechtigungen und Verbundoptionen offenlegen. Eine einzige interne Identitätsschicht ermöglicht es Teams, einen Richtlinienvertrag durchzusetzen und gleichzeitig den anbieterspezifischen Kontext für die Fehlerbehebung beizubehalten.

Berechtigungen eng eingrenzen

Der Umfang eines Dienstkontos sollte sich nach den Anforderungen der Arbeitslast richten und nicht danach, was der Anbieterschlüssel zufällig zulässt. Definieren Sie den Umfang mindestens über diese Dimensionen:

• Anbietergrenze: welche Anbieter und Anbieterprojekte oder Arbeitsbereiche verwendet werden dürfen.
• Modellgrenze: erlaubte Modellfamilien, Versionen, Vorschaumodelle und Fallbackmodelle.
• Endpunktgrenze: Chat, Antworten, Einbettungen, Batch, Dateien, Feinabstimmung, Assistenten, Tools oder Admin-APIs.
• Umgebungsgrenze: Entwicklung, Staging, Produktion, Sandbox oder Partner.
• Datengrenze: Aufbewahrungsrichtlinie, Region, Klasse für sensible Daten und zulässige zustandsbehaftete Funktionen.
• Budgetgrenze: Soft Alerts, Hard Caps, Minutenlimits und Monatslimits.
• Netzwerkgrenze: akzeptierte Quellnetzwerke, Workload-Identitäten oder Bereitstellungsplattformen.

Administratorberechtigungen API sollten für Laufzeitdienstkonten fast nie verfügbar sein. Trennen Sie die Bereitstellungsautomatisierung von Inferenz-Workloads. Ein Backend-Dienst, der Eingabeaufforderungen sendet, sollte nicht auch in der Lage sein, neue Anbieterschlüssel zu erstellen, Budgets zu ändern oder Modellzugriff zu gewähren.

Föderation gegenüber statischen Schlüsseln bevorzugen, wenn es praktisch ist

Fakt: Anthropic dokumentiert die Workload-Identitätsföderation als eine Möglichkeit für Arbeitslasten, signierte Identitätstokens anstelle statischer Anthropic Anmeldeinformationen zu verwenden. Google Cloud warnt davor, dass benutzerverwaltete Dienstkontoschlüssel Sicherheitsrisiken darstellen, wenn sie nicht sorgfältig verwaltet werden, und empfiehlt nach Möglichkeit sicherere Alternativen. OWASP empfiehlt die zentrale Speicherung von Geheimnissen sowie die Überwachung von Geheimanfragen und -nutzung, Rotation, Widerruf und Ablauf, sofern möglich.

Empfehlung: Bevorzugen Sie Workload Identity Federation oder kurzlebigen Token-Austausch für Cloud-gehostete Dienste und CI/CD-Systeme, bei denen Anbieterunterstützung vorhanden ist. Verwenden Sie statische API-Schlüssel nur, wenn die Föderation nicht verfügbar ist, vom benötigten Anbieterpfad nicht unterstützt wird oder betrieblich für eine Arbeitslast mit geringem Risiko nicht gerechtfertigt ist.

Ein Föderationsablauf sieht normalerweise so aus:

1. Die Arbeitslast wird unter einem Cloud-, CI- oder Identitätsanbieter-Prinzipal ausgeführt.
2. Die Arbeitslast erhält ein signiertes Identitätstoken von diesem Upstream-Identitätsanbieter.
3. Der LLM-Anbieter oder das interne Gateway validiert Aussteller, Zielgruppe, Betreff und Ansprüche.
4. Das Gateway ordnet das Token einem internen Dienstkonto zu.
5. Das Gateway gibt eine kurzlebige Sitzung aus oder autorisiert die LLM-Anfrage direkt.

Mehr als den Aussteller validieren. Überprüfen Sie Zielgruppe, Betreff, Repository- oder Workload-Pfad, Umgebung, Branch oder Bereitstellungsansprüche (sofern verfügbar) sowie die Token-Lebensdauer. Die Föderation verlagert das Risiko vom statischen Geheimleck auf die Konfiguration des Identitätsanbieters. Schwache Ansprüche, umfassende Vertrauensrichtlinien oder freizügige CI-Umgebungen können dennoch unbeabsichtigten Zugriff gewähren.

Attributionsmetadaten bei jeder Anfrage erforderlich

Dienstkonten identifizieren die Arbeitslast, sollten aber nicht das einzige Attributionsfeld sein. Produktions-LLM-Anfragen benötigen genügend Metadaten, um betriebliche Fragen schnell beantworten zu können.

Diese Felder sind am Gateway erforderlich:

• service_account_id
• app
• environment
• owner_team
• deployment_id oder Release-Version
• request_purpose, z. B. Chat, Extraktion, Klassifizierung, Bewertung oder agent_tool_use
• tenant_id oder ggf. Kundenkennung
• workflow_id oder Job-ID für asynchrone Arbeit

Diese Felder unterstützen LLM API Kostenzuordnung, Reaktion auf Vorfälle, Ratenbegrenzungsentscheidungen und den Rechnungsabgleich von Anbietern. Sie verhindern auch den allgemeinen Fehlermodus, bei dem jede Anfrage von einem gemeinsam genutzten Schlüssel nur als „Backend“ gekennzeichnet wird.

Budgets und Benachrichtigungen an Workload-Identitäten anhängen

Dienstkonten werden oft unbeaufsichtigt ausgeführt. Dadurch wird die Kostenkontrolle wichtiger und nicht weniger wichtig. Ein Benutzer bemerkt möglicherweise eine außer Kontrolle geratene Chatsitzung. Ein geplanter Agent oder ein sich wiederholender Batch-Job kann über Nacht das Budget sprengen.

Budgets auf mehreren Ebenen festlegen:

• Anbieterprojekt- oder Arbeitsbereichsbudget, sofern unterstützt.
• Monatsbudget auf Gateway-Ebene pro Dienstkonto.
• Anomalieerkennung in kurzen Zeitfenstern für plötzliche Spitzen.
• Maximale geschätzte Kosten pro Anfrage oder pro Job.
• Getrennte Grenzwerte für Produktions-, Staging-, CI- und Evaluierungs-Workloads.

Verwenden Sie unterschiedliche Aktionen für unterschiedliche Schwellenwerte. Bei 50 Prozent benachrichtigen Sie das Eigentümerteam. Bei 80 Prozent ist eine Bestätigung erforderlich. Bei 100 Prozent werden entweder unkritische Anfragen blockiert, auf billigere genehmigte Modelle heruntergestuft oder eine explizite Überschreibung erforderlich. Das richtige Verhalten hängt davon ab, ob die Arbeitslast kundenorientiert, intern, stapelweise oder sicherheitskritisch ist.

Entwerfen Sie den Lebenszyklus-Workflow

Ein Dienstkonto ohne Lebenszykluskontrollen wird zu einem weiteren nicht verwalteten Geheimnis. Definieren Sie den Workflow vor der breiten Einführung.

Anfrage

Der Anforderer muss Anwendungsnamen, Umgebung, Eigentümerteam, Geschäftszweck, erwartete monatliche Ausgaben, Datenklassifizierung, Modellanforderungen, Endpunktanforderungen angeben und angeben, ob eine Föderation möglich ist.

Genehmigung

Die Genehmigung sollte vom Eigentümerteam und der Plattform oder Sicherheitsrichtlinie erfolgen. Arbeitslasten mit hohem Budget, sensiblen Daten, Partnern oder Werkzeugen sollten eine strengere Prüfung erfordern als interne Zusammenfassungsjobs mit geringem Risiko.

Bereitstellung

Erstellen Sie das interne Dienstkonto, die Anbieterbindung, das Budget, die Modellrichtlinie, die Prüfsenke und die Geheim- oder Verbundvertrauensstellung. Bereitstellung durch Automatisierung statt manueller Konsolenarbeit, sofern möglich.

Geheime Lieferung

Wenn ein statischer Schlüssel erforderlich ist, übermitteln Sie ihn nur an einen zentralen Secret-Manager oder eine Bereitstellungsplattform. Senden Sie keine Schlüssel über Chat, Tickets, lokale Dateien oder Dokumentationsseiten.

Bewertung

Überprüfen Sie Dienstkonten in einem festen Rhythmus. Bestätigen Sie das Eigentümerteam, die letzte Nutzung, Berechtigungen, Budget, Modellzugriff, Datenrichtlinie und ob statische Schlüssel durch Föderation ersetzt werden können.

Deaktivieren und löschen

Deaktivieren Sie nicht verwendete Dienstkonten vor dem Löschen. Dadurch wird ein Wiederherstellungsfenster erstellt, wenn eine Workload-Abhängigkeit übersehen wurde. Löschen Sie nach Ablauf der Quarantänezeit das Konto und widerrufen Sie alle Anbieterbindungen und Geheimnisse.

Protokollieren Sie die Ereignisse, die Auditoren und Responder benötigen

Überwachungsprotokolle sollten sowohl Aktivitäten auf der Steuerungsebene als auch auf der Datenebene abdecken. Mindestens log:

• Erstellung, Aktualisierung, Deaktivierung und Löschung von Dienstkonten.
• Erstellung, Lesen, Rotation und Widerruf von Anmeldeinformationen.
• Föderationsvertrauenserstellung und Änderungen der Anspruchsrichtlinien.
• Änderungen von Berechtigungen, Modellzugriff, Endpunktzugriff und Datenrichtlinien.
• Jede LLM-Anfrage mit Dienstkonto, Mandant, Modell, Anbieter, Token-Nutzung, geschätzten Kosten, Status und Anfragezweck.
• Budgetschwellenwert-Ereignisse, Hard-Limit-Blockierungen und manuelle Überschreibungen.
• Admin API Aufrufe, die sich auf Anbieterprojekte, Arbeitsbereiche, Dienstkonten oder Schlüssel auswirken.

Senden Sie diese Ereignisse an einen unveränderlichen oder manipulationssicheren Audit-Stream. Halten Sie Anforderungstelemetriedaten mit hoher Kardinalität von Prüfnachweisen mit langer Aufbewahrungszeit getrennt, wenn dies zur Kontrolle der Speicherkosten beiträgt, behalten Sie jedoch die für Untersuchungen erforderlichen Verknüpfungsschlüssel bei.

Migrationsplan von gemeinsam genutzten Schlüsseln

Das Ersetzen gemeinsam genutzter Schlüssel kann schrittweise erfolgen. Vermeiden Sie eine Big-Bang-Migration, es sei denn, der Schlüssel ist bereits kompromittiert.

1. Identifizieren Sie die am häufigsten genutzten gemeinsamen Schlüssel. Ordnen Sie nach Ausgaben, Datenverkehr, Modellzugriff und unbekanntem Eigentümer.
2. Gruppieren Sie Anrufer in Arbeitslastgrenzen. Verwenden Sie Protokolle, Quellrepositorys, Bereitstellungsvariablen, Benutzeragenten und Netzwerkquelldaten.
3. Erstellen Sie bereichsbezogene Dienstkonten. Beginnen Sie mit Produktionsarbeitslasten, die eindeutige Eigentümer und hohe Ausgaben oder ein hohes Risiko haben.
4. Route durch das Gateway. Behalten Sie den alten Anbieterschlüssel vorübergehend hinter dem Gateway bei, falls die direkte Anbietermigration länger dauern würde.
5. Dual-Run-Attribution. Vergleichen Sie Traffic, Kosten, Fehler, Latenz und Anbieterabrechnung, bevor Sie die vollständige Umstellung vornehmen.
6. Aufrufer rotieren. Bereitstellungsgeheimnisse, CI-Variablen und Anwendungskonfiguration jeweils für eine Arbeitslast aktualisieren.
7. Gemeinsamen Schlüssel widerrufen. Zuerst unter Quarantäne stellen, wenn der Explosionsradius unklar ist, dann nach dem Beobachtungsfenster widerrufen.

Das Ziel besteht nicht nur darin, einen Schlüssel zu drehen. Das Ziel besteht darin, mehrdeutigen Zugriff durch Workload-eigene Identität, Richtlinien, Budget und Beweise zu ersetzen.

Kompromisse, um sie explizit zu machen

Mehr Dienstkonten verbessern die Kontrolle, erhöhen aber auch die Verwaltung. Namenskonventionen, Eigentumsmetadaten, Bereinigungsjobs und Überprüfungsworkflows sorgen dafür, dass das Modell nutzbar bleibt.

Föderation reduziert das Risiko von statischen Geheimnissen, fügt aber Abhängigkeit vom Identitätsanbieter hinzu. Der Token-Austausch kann aufgrund von Ausstelleränderungen, Anspruchsdrift, Zeitversatz oder CI-Konfigurationsänderungen fehlschlagen. Entwerfen Sie klare Fehlermodi und Warnungen.

Anbieternative Kontrollen sind wertvoll, aber inkonsistent. Einige Anbieter stellen Projekte, Arbeitsbereiche, Dienstkonten, Budgets oder Föderationen unterschiedlich zur Verfügung. Eine Identitätsschicht auf Gateway-Ebene bietet konsistente Richtlinien und Berichte, muss jedoch den Upstream-Kontext für Kontingent-, Abrechnungs- und Supportuntersuchungen beibehalten.

Kurzlebige Anmeldeinformationen verbessern die Sicherheit, erhöhen jedoch die Komplexität der Laufzeit. Cachen Sie Token sorgfältig, respektieren Sie den Ablauf und vermeiden Sie, dass jede LLM-Anfrage von einem langsamen Aufruf der Steuerungsebene abhängt.

Zentralisierte Durchsetzung verbessert die Governance, erhöht jedoch die Plattformverantwortung. Wenn das Gateway über Richtlinien, Budgets und Zuordnung verfügt, muss es gut beobachtbar und operativ ausgereift sein.

Implementierungs-Checkliste

• Erstellen Sie ein Inventar menschlicher Schlüssel, Workload-Identitäten, CI-Identitäten, Partnerschlüssel und Break-Glass-Anmeldeinformationen.
• Definieren Sie eine Namenskonvention mit App, Umgebung, Eigentümerteam und Zweck.
• Verwenden Sie ein Dienstkonto pro Produktionsarbeitslastgrenze.
• Binden Sie jede Identität an enge Anbieterprojekte oder Arbeitsbereiche.
• Modellfamilien, Endpunkte, Regionen, Datenrichtlinien und Budgets einschränken.
• Bevorzugen Sie einen Verbund oder einen kurzlebigen Token-Austausch, sofern dies unterstützt wird.
• Speichern Sie statische Schlüssel nur in der zentralen Secret-Verwaltung.
• Attributionsmetadaten bei jeder Anfrage erforderlich.
• Dienstkontobudgets und Anomaliewarnungen festlegen.
• Anmeldedaten-, Berechtigungs-, Anforderungs-, Budget- und Sperrereignisse protokollieren.
• Deaktivieren Sie nicht verwendete Konten, bevor Sie sie löschen.
• Gemeinsame Schlüssel nach Arbeitslast migrieren und dann die alten Anmeldeinformationen widerrufen.

Schlussfolgerung

LLM-Dienstkonto-Governance ist das Betriebsmodell für den Produktions-KI-Zugriff. Behandeln Sie jeden unbeaufsichtigten Anrufer als Workload-Identität mit Eigentümer, Zweck, Berechtigungsgrenze, Budget und Lebenszyklus. Verwenden Sie anbieternative Dienstkonten, wo sie hilfreich sind, bevorzugen Sie die Föderation, wo es praktisch ist, und normalisieren Sie die Identität am Gateway, damit OpenAI, Anthropic, Gemini und interne Systeme konsistent verwaltet werden können.

Vorhersage: LLM-Plattformen werden sich weiterhin von breiten statischen Schlüsseln hin zu Dienstkonto- und Workload-Identitätsmodellen bewegen. Teams, die jetzt eine saubere Arbeitslastverantwortung einrichten, haben später einen einfacheren Weg zur Anbieterföderation, Prüfungsbereitschaft, Partner-Governance API und zuverlässigen Kostenkontrollen.

Verwandte Lektüre

• API Schlüssel-Governance für Teams