Ein Leitfaden zur Verwaltung von API-Schlüsseln

Nicht-menschliche Identitäten (NHIs) übersteigen menschliche Benutzer in Unternehmensumgebungen im Verhältnis 144 zu 1, laut The NHI & Secrets Risk Report H1 2025, ein Anstieg von 56 % gegenüber 92:1 im Vorjahr. Das Management von API-Schlüsseln sollte diese Größenordnung berücksichtigen, da Dienstkonten, automatisierte Pipelines und Drittanbieter-Integrationen alle Anmeldeinformationen enthalten. Ein großer Teil dieser Anmeldeinformationen sind API-Schlüssel, statische Zeichenketten, die oft standardmäßig nicht ablaufen, in den Quellcode gelangen und Zugriffsprüfungen entgehen.

Menschliche Konten erhalten Joiner-Mover-Leaver-Workflows und regelmäßige Zertifizierungen. Entwickler erstellen normalerweise API-Schlüssel in Entwicklerkonsolen und fügen sie in Konfigurationsdateien ein. Die Schlüssel bleiben so lange aktiv, bis etwas schiefgeht oder eine unsachgemäße Offboarding-Lücke offenbart wird.

Effektive Credential Governance umfasst Maschinenanmeldeinformationen bei Erstellung, Speicherung, Rotation, Überwachung und Widerruf. Die Anwendung dieser Kontrollen auf jede nicht-menschliche Identität beseitigt das Risiko langlebiger Schlüssel und stärkt die Sicherheitslage, die operative Sichtbarkeit und die Cyber-Resilienz.

Was ist API-Schlüsselverwaltung?

API-Schlüsselverwaltung ist die Disziplin, die eine Maschinenanmeldeinformation von der Erstellung bis zum Widerruf steuert und Speicherung, Verteilung, Rotation und Überwachung umfasst. Ein API-Schlüssel ist eine statische, undurchsichtige Zeichenkette, die eine Anwendung mit einer API-Anfrage überträgt, typischerweise in einem Hypertext Transfer Protocol (HTTP)-Header, um die aufrufende Anwendung, den Dienst, das Skript oder die Pipeline zu identifizieren. Er fungiert als Berechtigungsnachweis im Bearer-Stil, da allein der Besitz zur Nutzung ausreicht.

Request for Comments (RFC) 6750 definiert dieselbe Eigenschaft für OAuth 2.0-Bearer-Tokens: Jeder, der das Token besitzt, kann es verwenden, ohne den Besitz des kryptografischen Schlüsselmaterals nachzuweisen. Diese Bearer-Eigenschaft ist genau der Grund, warum ein Standard-API-Schlüssel keinen Principal authentifiziert. Er beweist nur den Besitz eines Zeichenkettenwerts, nicht die Identität.

Warum API-Schlüssel eine wachsende Angriffsfläche darstellen

Entwickler haben 28.649.024 neue fest codierte Geheimnisse in öffentliche GitHub-Repositories im Jahr 2025 eingebracht, laut The State of Secrets Sprawl 2026 von GitGuardian. Diese Zahl stellt eine Steigerung von 34 % gegenüber dem Vorjahr dar und ist der größte Anstieg in einem Jahr, den der Bericht verzeichnet hat. Mehrere strukturelle Eigenschaften treiben diese Ausbreitung an. Viele API-Schlüssel laufen standardmäßig nicht ab, daher kann die langfristige Schlüssel-Exposition jahrelang bestehen bleiben, und derselbe Klartextwert, der in einem HTTP-Header funktioniert, funktioniert ebenso gut in einer Konfigurationsdatei, einer Continuous Integration und Continuous Delivery (CI/CD)-Variable oder einer Chat-Nachricht.

Überprivilegierte NHIs erhalten ebenfalls weiterreichende Berechtigungen, als ihre Aufgaben erfordern, und diese Berechtigungen bestehen oft länger als die Aufgabe selbst. Jeder neue Cloud-Dienst, jede Pipeline und jede Drittanbieterintegration erhöht den Bestand, den Sicherheitsteams verwalten müssen. Laut dem Netwrix 2026 Data and Identity Security Report, beginnen 75 % der vorfallbasierten Datenexpositionen mit einer kompromittierten Identität oder falsch konfigurierten Berechtigungen.

Ein historisches Beispiel zeigt die operative Auswirkung schwacher Lifecycle-Kontrollen. Im November 2023 griff ein Bedrohungsakteur über offengelegte gültige Anmeldedaten auf die selbstgehostete Atlassian-Umgebung von Cloudflare zu.

Der Akteur nutzte ein Zugriffstoken und drei Service-Konto-Anmeldeinformationen, die bei der Okta-Komprimittierung im Oktober 2023 offengelegt wurden und die Cloudflare danach nie rotierte. Cloudflare beschrieb sie als „irrtümlich für ungenutzt gehalten“. Die Behebung erforderte eine umfassende Rotation der Produktionsanmeldeinformationen und ein Neuaufsetzen der Maschinen im globalen Cloudflare-Netzwerk.

Dieser Angreifer authentifizierte sich während des gesamten Vorfalls mit gültigen Anmeldedaten, und der Netwrix 2025 Cybersecurity Trends Report stellte fest, dass 27 % der Organisationen Schadensschätzungen von 50.001 $ oder mehr angaben, was den finanziellen Nutzen von Lifecycle-Kontrollen unterstreicht, die vermeidbare Reaktions- und Behebungsarbeiten reduzieren. Kontinuierliche Inventarisierung, Eigentum und Rotation verringern diese Wiederherstellungsbelastung und verbessern die Cyber-Resilienz.

Der Lebenszyklus des API-Schlüssels

Die Open Worldwide Application Security Project (OWASP) Secrets-Anleitung organisiert ein effektives Schlüsselmanagement in fünf Phasen: Erstellung, Speicherung und Verteilung, Rotation, Überwachung und Prüfung sowie Widerruf.

Generierung

Jeder Schlüssel sollte aus einer kryptographisch sicheren Zufallsquelle stammen und von Anfang an Bereichsbeschränkungen tragen. Für einen Schlüssel, der als National Institute of Standards and Technology (NIST) SP 800-63B-4 Lookup-Geheimnis oder eine direkt analoge Berechtigung fungiert, verwenden Sie eine minimale Sicherheitsstärke von 112 Bit als Entropie-Benchmark; NIST verlangt, dass Lookup-Geheimnisse von einem zugelassenen Zufallsbitgenerator mit dieser Mindeststärke stammen, der speziell auf Lookup-Geheimnisse und direkt analoge Berechtigungen angewendet wird.

Wenden Sie Schlüsselbeschränkungen bei der Ausgabe an, indem Sie festlegen, welche APIs der Schlüssel aufrufen darf und welche Anwendungen ihn präsentieren dürfen. Weisen Sie jedem Schlüssel die minimalen Berechtigungen zu, die seine Aufgabe erfordert, und erstellen Sie gleichzeitig Eigentumsnachweise. Bezüglich der Schlüssel, die sich authentifizieren sollen, ist die OWASP API-Richtlinie eindeutig: API-Schlüssel sollten API-Clients authentifizieren, nicht Endbenutzer.

Zwei verwandte Anmeldetypen unterscheiden sich von API-Schlüsseln. Der OAuth 2.0-Standard, ein Autorisierungsrahmen, definiert Zugriffstoken, die von Autorisierungsabläufen ausgegeben werden. Anforderungen an die Client-Authentifizierung, Bereiche und Lebensdauern hängen vom Gewährungstyp und der Anbieter-Konfiguration ab; im Client-Credentials-Flow von Microsoft liegen typische Token-Lebensdauern oft bei etwa einer Stunde.

Ein zertifikatbasierter Nachweis, der mutual Transport Layer Security (mTLS) und X.509 verwendet, nutzt stattdessen einen Besitznachweis. Der Client weist die Kontrolle über einen privaten Schlüssel nach, der beim Client verbleibt, sodass gemäß RFC 8705 nur die Partei, die im Besitz des privaten Schlüssels zum Zertifikat ist, das zugehörige Token verwenden kann.

Speicherung und Verteilung

Halten Sie Schlüssel aus dem Quellcode heraus und rufen Sie sie zur Laufzeit aus einem dedizierten Geheimnisspeicher ab. Hardcodierte Zugangsdaten im Quellcode sind gefährlich; die Lösung ist ein Geheimnis-Manager, den CI/CD-Pipelines und Anwendungen sicher zum Abrufen von Geheimnissen verwenden können.

Umgebungsvariablen, die außerhalb des Quellbaums der Anwendung bleiben, sind die Grundlage; ein zentralisierter Geheimnis-Manager mit Zugriffskontrollen und Audit-Protokollierung ist der Standard. Verteilen Sie Schlüssel nur über Hypertext Transfer Protocol Secure (HTTPS) und platzieren Sie sie niemals in URLs, da Abfragezeichenfolgen in Webserver-Protokollen landen.

Rotation

Manuelle Rotationsprozesse führen zu Fehlern und lassen veraltete Zugangsdaten aktiv, weshalb Automatisierung wichtig ist. Für langlebige Google Cloud Service-Konto-Schlüssel Empfehlungen des Cloud-Anbieters empfehlen eine Rotation mindestens alle 90 Tage. Der Center for Internet Security (CIS) Amazon Web Services (AWS) Benchmark fordert ebenfalls, AWS Identity and Access Management (IAM) Zugangsschlüssel alle 90 Tage oder kürzer zu rotieren.

Für eine Rotation ohne Ausfallzeiten verwenden Sie dual-credential rotation. Halten Sie zwei gültige Anmeldedatensätze bereit, wechseln Sie die Anwendungen auf den neuen Satz und stellen Sie dann den alten zurück. Lösen Sie die event-driven rotation nach vermutetem Datenleck, Eigentümerwechsel oder Projektende aus. Die Kosten für das Überspringen dieser Phase summieren sich. GitGuardian fand heraus, dass 64% der vor vier Jahren entdeckten Geheimnisse bei erneuter Prüfung noch aktiv und ausnutzbar waren.

Überwachung und Prüfung

Erstellen Sie Schlüsselverwendungsprotokolle für jede Anmeldeinformation und prüfen Sie diese Protokolle auf inaktive Schlüssel. CIS Controls v8 verlangt mindestens 90 Tage Aufbewahrung von Audit-Logs, und CIS Cloud-Benchmarks fordern Teams auf, Anmeldeinformationen nach 45 Tagen Inaktivität zu deaktivieren. Inaktivität ist ein nützliches Signal.

Überprüfen Sie die Erstellung und Verwendung von Service Principal-Anmeldeinformationen und achten Sie auf ungewöhnliche Anwendungsnutzung, wie z. B. plötzlich wieder aktive ruhende Anwendungen. Maskieren Sie geheime Werte in Protokollen; Geheimnisse dürfen niemals im Klartext erscheinen.

Widerruf

Behandle jeden offengelegten Schlüssel ab dem Moment, in dem du davon erfährst, als kompromittiert und erstelle den Widerrufspfad, bevor du ihn benötigst. Folge einer sicheren Rotationssequenz. Erzeuge einen Ersatzschlüssel für dasselbe Servicekonto, verschiebe Arbeitslasten darauf, überprüfe die Funktionalität nach der Migration und lösche dann den alten Schlüssel.

Das Löschen des Secrets nur aus dem Code lässt die Anmeldeinformationen aktiv; folgen Sie der Anleitung zur Bereinigungen des Repositorys indem Sie zuerst widerrufen und dann Repositorys, Konfiguration und Protokolle bereinigen. Beenden Sie mit einer Überprüfung des Schadensausmaßes der Nutzungshistorie des Schlüssels. Was wurde während der Exposition abgerufen, und hat der Angreifer ihn verwendet, um neue Schlüssel, Rollen oder Richtlinien zu erstellen?

Worauf Sie bei einem API-Schlüssel-Management achten sollten

Ein funktionierendes Governance-Programm kombiniert die Bereitstellung von vault mit operativen Kontrollen, daher sollten Ansätze anhand operativer Kriterien bewertet werden.

• Zentralisiertes Inventar und Erkennung: Der Ansatz sollte Schlüssel über Cloud-Anbieter, CI/CD-Pipelines, Repositories, Konfigurationsdateien und Software as a Service (SaaS)-Plattformen finden und festhalten, wer jeweils Eigentümer ist. Ein praktisches Verzeichnis für nicht-menschliche Anmeldeinformationen sollte Identität, verantwortliches Team, Geschäftszweck, zugängliche Systeme, Berechtigungsumfang sowie Ablauf- oder Überprüfungsdatum erfassen.
• Least-Privilege-Abgrenzung und Just-in-Time-Ausstellung: Achten Sie auf eine Abgrenzung pro Schlüssel und pro Arbeitslast sowie die Möglichkeit, kurzlebige Anmeldeinformationen bei Bedarf auszustellen und nach der Nutzung automatisch zu widerrufen.
• Automatische Rotation ohne Ausfallzeiten: Sowohl geplante als auch ereignisgesteuerte Rotation mit Unterstützung für doppelte Anmeldedaten, damit Anwendungen während der Umstellung verfügbar bleiben.
• Auditfähige Protokollierung: Jede Abfrage, Rotation, Widerruf und administrative Aktion sollte auditfähige Aufzeichnungen mit einer zuordenbaren Identität und Zeitstempel erzeugen, die für Ihr Security Information and Event Management (SIEM)-System exportiert werden können. Diese Aufzeichnung liefert Auditnachweise und die forensische Spur, die Vorfallreaktionsteams benötigen.
• Integration mit Identity Governance: Identity Governance and Administration (IGA), Privileged Access Management (PAM) und Cloud Infrastructure Entitlement Management (CIEM) sollten zusammenarbeiten, um Identitäten und Berechtigungen in allen Umgebungen konsistent zu verwalten. Ein Tresor, der Inventar- und Eigentumsdaten mit Ihrem IGA program kann Schlüssel im Zertifizierungsprozess enthalten. Der IGA buyer's guide beschreibt weitere Governance-Funktionen zur Bewertung von Identity Management-Tools.

Wo das API-Schlüsselmanagement in die Governance nicht-menschlicher Identitäten passt

Viele Governance-Programme scheitern bei der Eigentümerschaft. Silverfort's Insecurity in the Shadows 2025 ergab, dass 40 % der nicht-menschlichen Identitäten einen unbekannten Eigentümer haben und nur 5,7 % der Sicherheitsverantwortlichen vollständige Sichtbarkeit über ihre NHIs melden.

Eine Gartner-Umfrage unter 335 IAM-Führungskräften, veröffentlicht in Gartner Identifies the Top Cybersecurity Trends for 2025, ergab, dass IAM-Teams nur für 44 % der Maschinenidentitäten einer Organisation verantwortlich sind; der Rest liegt bei Entwicklungs-, Plattform- und Geschäftsteams. Klare Identitätseigentümerschaft schafft Verantwortung für Überprüfungen, Rotation und Stilllegung.

Compliance-Rahmenwerke erwarten diese Disziplin bereits. Payment Card Industry Data Security Standard (PCI DSS) Anforderungen zum geringsten Privileg umfassen Anwendungs- und Systemkonten (Req. 7.2.5). Organisationen müssen den Zugriff auf diese Konten in einer in ihrer Risikoanalyse festgelegten Häufigkeit regelmäßig überprüfen. PCI DSS Req. 7.2.5.1 trat am 31. März 2025 in Kraft. PCI DSS legt außerdem fest codierte Passwortkontrollen für Skripte, Konfigurationsdateien und Quellcode fest (Req. 8.6.2).

Die Sicherheitsregel des Health Insurance Portability and Accountability Act (HIPAA) beschränkt Zugriffskontrollen auf Personen oder Softwareprogramme mit Zugriffsrechten, sodass Maschinenanmeldeinformationen, die geschützte Gesundheitsinformationen (PHI) berühren, eindeutig darunter fallen.

Für den Sarbanes-Oxley Act (SOX), unterstützen vollständige Zugriffspopulationen zuverlässige Kontrolltests. Die SOX-Zugriffsverwaltung sollte Dienstkonten und Integrationsschlüssel in Zugrifflisten einschließen. Über alle Frameworks hinweg umfassen konsistente Prüfungsnachweise Entdeckungsberichte, Eigentumsnachweise, Rotationsprotokolle, Stilllegungsaufzeichnungen und datierte Überprüfungen mit namentlichen Unterschriften.

Der Analystenkonsens hat sich auf denselben Punkt verlagert. Das Vaulting von Geheimnissen unterstützt die Governance, aber Governance geht über das Vaulting hinaus. Organisationen erwarten zunehmend, dass IGA-Plattformen sowohl menschliche als auch NHIs konsistent durch flexible Lebenszyklusrichtlinien, kontinuierliche Abstimmung und klare Eigentumsmodelle verwalten.

In der Praxis benötigt jeder API-Schlüssel die gleiche Lebenszyklusbehandlung wie ein menschliches Konto. Das bedeutet, ihn mit einem Eigentümer und dokumentiertem Zweck zu erstellen, regelmäßig zu zertifizieren und zu deaktivieren, wenn seine Aufgabe endet. Die Deaktivierung bleibt die größte Lücke; das Open Worldwide Application Security Project (OWASP) NHI Top 10 listet unsachgemäße Deaktivierung unter häufigen Fehlerursachen und berichtet, dass 51 % der Organisationen keinen formalen Prozess zum Deaktivieren oder Widerrufen von langlebigen API-Schlüsseln haben. Da Teams ständig Schlüssel erstellen und aufgeben, erfordert das Governance-Modell eine kontinuierliche Abstimmung, um Sichtbarkeit und Zustand bei Veränderungen der Population zu erhalten.

Best Practices für die Verwaltung großer API-Schlüsselbestände

Ein skalierbares Programm verwandelt Lifecycle-Policy in wiederholbare technische und Governance-Kontrollen:

• Vorlagen für Least-Privilege-Richtlinien: Definieren Sie genehmigte API-, Ressourcen- und Operationsbereiche für gängige Workloads, wenden Sie standardmäßige Verweigerung an und erkennen Sie Abweichungen von diesen Vorlagen.
• Migration von statischen Schlüsseln: Wenn Plattformen workload identity federation, managed identities oder temporäre Sitzungstoken unterstützen, verwenden Sie diese stattdessen. Die Richtlinien des National Cyber Security Centre (NCSC) raten davon ab, langfristige Zugriffsschlüssel zu verwenden, die bei Kompromittierung unbegrenzten Zugriff gewähren können.
• Rotation-Orchestrierung: Verbinden Sie die Ausstellung von Anmeldeinformationen, den Anwendungswechsel, die Validierung und den Ruhestand, damit Teams die Rotation von Anmeldeinformationen automatisieren können, wie es die NCSC-Richtlinien empfehlen.
• Vault-to-discovery-Abgleich: GitGuardian stellte fest dass 5,1 % der Repositories, die secrets managers verwenden, 2024 weiterhin Geheimnisse leaken; vergleichen Sie gespeicherte Anmeldedaten mit Repository-, Pipeline-, Cloud- und SaaS-Inventaren, um Lücken zu finden.
• Not-Aus-Schalter für die Vorfallreaktion: Behalten Sie die Fähigkeit, jeden Schlüssel innerhalb von Minuten zu widerrufen, mit einem vorgetesteten Ersatzweg. Das SANS Internet Storm Center (SANS ISC) beobachtete Bedrohungsakteure, die innerhalb von 24 Stunden vom Validieren gestohlener Geheimnisse zu aktiven Erkundungsoperationen in kompromittierten Cloud-Umgebungen übergehen.
• Überprüfungen mit benanntem Eigentümer: CIS Safeguard 5.5 erfordert ein Inventar der Servicekonten mit Abteilungsinhaber, Überprüfungsdatum und Zweck, mindestens vierteljährlich überprüft; API-Schlüssel in dieselbe Überprüfung einbeziehen.

Wie Netwrix Ihnen hilft, API-Schlüssel und Maschinenanmeldeinformationen zu verwalten

API-Schlüssel sind eine Art von Anmeldeinformationen innerhalb einer größeren Herausforderung der Governance nicht-menschlicher Identitäten, und die meisten Organisationen haben keine vollständige Übersicht über diese Gruppe. Netwrix unterstützt angrenzende PAM- und IGA-Kontrollen als Teil seines identitätszentrierten Sicherheitsansatzes für mittelständische Unternehmen mit Microsoft-lastigen hybriden Umgebungen.

Für privilegierte Zugriffs-Workflows wendet Netwrix Privilege Secure ein Modell ohne dauerhafte Berechtigungen an, das aufgabenbezogene ephemere Konten für eine einzelne Sitzung erstellt und diese nach Beendigung löscht. Eastern Carver County Schools hat dauerhaften privilegierten Zugriff auf Netzwerkswitches, VMware und Sicherheitskameras, die die Daten von 9.300 Schülern schützen, abgeschafft, durch Just-in-Time-Zugriff ersetzt und die Einführung in Tagen statt Monaten abgeschlossen. Netwrix Identity Manager unterstützt Zugriffszertifizierung und automatisiertes Offboarding für die Identitäten, denen diese Anmeldeinformationen gehören.

Über 14.000 Kunden, darunter etwa 25 % der Fortune-500-Unternehmen, vertrauen auf Netwrix, um Identitäts- und Datensicherheit gemeinsam zu verwalten.

Fordern Sie eine Demo an und sehen Sie, wie Netwrix Privilege Secure dauerhaften privilegierten Zugriff mit aufgabenbezogenen Zugangsdaten eliminiert, die automatisch ablaufen.