API-Schlüssel: der Zugang, den niemand widerruft

Inhalt in Kürze

• Ein API-Schlüssel ist ein Zugang ohne Person: kein Name, kein Austritt, kein zweiter Faktor. Wer ihn hat, ist drin.
• GitGuardian zählte für 2025 rund 29 Millionen neu veröffentlichte Zugangsdaten im Quelltext auf öffentlichem GitHub — 34 Prozent mehr als im Jahr davor.
• Das Problem ist selten der einzelne Schlüssel. Es ist die Kombination aus zu weiten Rechten, fehlendem Ablaufdatum und fehlendem Protokoll.
• Drei Schritte reichen für den Anfang: inventarisieren, Rechte kürzen, Ablaufdatum setzen.

Wer im Unternehmen fragt, wer Zugriff auf die Daten hat, bekommt eine Liste von Personen. Die Liste stimmt — sie ist nur unvollständig.

Neben den Menschen greifen Programme zu: die Buchhaltungssoftware, die Umsätze abholt; das Auswertungswerkzeug, das nachts eine Datei zieht; das Skript, das jemand vor zwei Jahren für einen Sonderfall geschrieben hat. Sie alle melden sich mit einem API-Schlüssel an, und dieser Schlüssel steht in keiner Nutzerliste.

Warum ein Schlüssel etwas anderes ist als ein Passwort

Auf den ersten Blick sieht beides gleich aus: eine geheime Zeichenfolge, die Zugang verschafft. Der Unterschied liegt im Drumherum.

Ein Passwort gehört einer Person. Diese Person hat einen Arbeitsvertrag, ein Onboarding und irgendwann einen letzten Arbeitstag. An diesem Tag greift ein Prozess, den es in jedem Unternehmen gibt — auch wenn er nur aus einer Checkliste besteht.

Ein API-Schlüssel gehört keiner Person. Er wurde für einen Zweck erzeugt, in eine Konfigurationsdatei kopiert und danach vergessen. Es gibt keinen Austritt, der ihn beendet, keine Anmeldung, die auffiele, und in vielen Systemen keine Anzeige, wann er zuletzt benutzt wurde.

Dazu kommt ein dritter Unterschied: Ein Passwort wird in der Regel nicht weitergegeben, ein Schlüssel schon. Er wandert in ein Repository, in eine Automatisierung, in eine Nachricht an einen Dienstleister. Jede dieser Kopien ist gleich gültig.

Die Größenordnung

Dass Zugangsdaten öffentlich werden, ist keine Ausnahme. GitGuardian untersucht dafür jährlich die öffentlich zugänglichen Commits auf GitHub und zählte für das Jahr 2025 rund 29 Millionen neu offengelegte, fest hinterlegte Zugangsdaten — ein Zuwachs von 34 Prozent gegenüber dem Vorjahr und der stärkste Anstieg, den der Bericht bisher gemessen hat. Allein auf Dienste rund um künstliche Intelligenz entfielen davon über 1,2 Millionen Schlüssel, ein Plus von 81 Prozent.

Der Grund ist unspektakulär: Ein Schlüssel im Quelltext funktioniert sofort, und die saubere Lösung kostet eine halbe Stunde mehr. Wer unter Zeitdruck etwas zum Laufen bringt, wählt die erste Variante und nimmt sich vor, es später zu ändern.

Für mittelständische Unternehmen ist die Zahl weniger als Warnung relevant denn als Maßstab: Wenn das in dieser Größenordnung passiert, ist die Annahme „bei uns liegt sowas nicht herum” keine Feststellung, sondern eine Vermutung.

Was die DSGVO dazu verlangt

Wörtlich steht nichts über API-Schlüssel im Gesetz. Der Sache nach steht einiges dort.

Art. 32 DSGVO verlangt technische und organisatorische Maßnahmen, die dem Risiko angemessen sind, und nennt dabei ausdrücklich zwei Punkte, die hier einschlägig sind: die Fähigkeit, die Vertraulichkeit der Systeme auf Dauer sicherzustellen, und ein Verfahren zur regelmäßigen Überprüfung der Wirksamkeit. Ein Schlüssel, den niemand kennt, kann weder dauerhaft vertraulich noch regelmäßig überprüft sein.

Dazu kommt die vertragliche Seite. Ein API-Schlüssel ist oft der Weg, auf dem personenbezogene Daten zu einem Dienstleister fließen. Damit ist die Verarbeitung nach Art. 28 DSGVO zu regeln. In der Praxis fehlen Auftragsverarbeitungsverträge besonders häufig bei genau diesen Anbindungen — weil sie niemand als Dienstleistungsbeziehung wahrnimmt, sondern als technisches Detail.

Wer einen Auftragsverarbeiter kündigen will, merkt das spätestens dann: Der Vertrag endet, der Schlüssel bleibt gültig.

Drei Eigenschaften, die zusammen gefährlich werden

Einzeln ist keine davon dramatisch. Zusammen ergeben sie den Regelfall.

Zu weite Rechte. Viele Anbieter geben beim Anlegen einen Schlüssel mit vollem Zugriff aus, weil das keine Rückfragen erzeugt. Gebraucht wird meist Lesen auf einen Teilbereich. Der Unterschied entscheidet, ob ein Leck eine Auskunft oder eine Löschung ermöglicht.

Kein Ablaufdatum. Ein unbefristeter Schlüssel wird nie überprüft, weil es keinen Anlass gibt. Ein Ablaufdatum erzwingt genau diese Überprüfung — beim Erneuern fragt zum ersten Mal jemand, wofür der Zugang eigentlich da ist.

Kein Protokoll. Nach einem Verdacht lautet die erste Frage: Was ist mit diesem Schlüssel passiert? Sie ist nur beantwortbar, wenn die Zugriffe je Schlüssel festgehalten werden — nicht nur je IP-Adresse, die bei Cloud-Diensten ohnehin wechselt.

Der Weg zum Inventar

Der Einstieg ist unspektakulär und dauert bei einem mittelständischen Betrieb ein bis zwei Stunden.

1. Bei den Rechnungen anfangen, nicht bei der Technik. Jeder angebundene Dienst kostet Geld oder hat einmal Geld gekostet. Die Kontoauszüge und Kreditkartenabrechnungen der letzten zwölf Monate ergeben die Liste der Kandidaten — vollständiger als jede Umfrage im Team.
2. Je Dienst in die Verwaltung sehen. Fast alle Anbieter führen die vorhandenen Schlüssel mit einem Datum der letzten Nutzung. Was seit Monaten nicht benutzt wurde, ist der erste Kandidat für den Widerruf.
3. Je Schlüssel drei Dinge festhalten: wofür er da ist, wer ihn verantwortet, wann er abläuft. Mehr braucht das Inventar nicht. Eine Tabelle genügt, solange sie existiert.
4. Rechte kürzen, bevor etwas passiert. Für die meisten Anbindungen reicht Lesen. Schreibende Zugänge sollten begründet sein — und die Begründung gehört in dieselbe Zeile.

Danach steht die Frage nach dem Turnus. Einmal im Quartal reicht, wenn die Ablaufdaten gepflegt sind; ohne sie hilft auch ein monatlicher Termin wenig, weil niemand weiß, was zu prüfen wäre.

Woran man einen gut gebauten Zugang erkennt

Nicht jeder Anbieter macht es einem schwer. Es lohnt sich, bei der Auswahl einer Software auf vier Dinge zu achten — sie kosten nichts extra und sparen im Ernstfall den entscheidenden Tag.

• Ein Schlüssel je Anbindung, nicht einer für alles. Dann lässt sich einer widerrufen, ohne dass drei andere Dinge ausfallen.
• Einzeln wählbare Rechte je Schlüssel, statt „Vollzugriff oder nichts”.
• Ein Ablaufdatum, das beim Anlegen gesetzt wird und vor Ablauf erinnert.
• Ein Zugriffsprotokoll je Schlüssel — mit Weg, Zeitpunkt und Status, aber ohne den Schlüssel selbst im Klartext.

Der letzte Punkt wird oft übersehen und ist der wichtigste: Ein Schlüssel, der in einem Protokoll auftaucht, ist ein Schlüssel, der über das Protokoll ein zweites Mal leckt.

Ein Beispiel für eine so gebaute Schnittstelle liefert die Finanzsoftware Yupana, die wir als frag.hugo Informationssicherheit GmbH betreiben: je Anbindung ein eigener Schlüssel, einzeln wählbare Rechte, eigenes Ablaufdatum, sofortiger Widerruf — und ein Zugriffsprotokoll, das den Schlüssel maskiert.

Was wir in Prüfungen regelmäßig finden

Drei Befunde kommen so oft vor, dass sie kaum noch überraschen.

Der Schlüssel des Ausgeschiedenen. Jemand hat vor Jahren eine Anbindung eingerichtet und das Unternehmen verlassen. Der Zugang läuft weiter, weil er an keinem Konto hängt. Beim Offboarding wurde alles richtig gemacht — nur nicht das, was in keiner Liste stand.

Der Schlüssel im Repository. Er steht in einer alten Konfigurationsdatei, die längst nicht mehr benutzt wird. Gelöscht ist er dort trotzdem nicht: Die Versionsgeschichte trägt ihn weiter, auch wenn die aktuelle Fassung ihn nicht mehr enthält.

Der geteilte Schlüssel. Ein Zugang, den drei Systeme benutzen, weil das Anlegen eines zweiten umständlich war. Er lässt sich nicht widerrufen, ohne dass jemand nachsehen muss, was dann alles stehen bleibt — und genau deshalb wird er nie widerrufen.

Der erste Schritt

Wenn Sie eine Stunde investieren wollen: Nehmen Sie die Kontoauszüge der letzten zwölf Monate und schreiben Sie jeden Softwaredienst auf, der darin auftaucht. Danach in jedem dieser Dienste nachsehen, welche Zugänge existieren und wann sie zuletzt benutzt wurden.

Erfahrungsgemäß findet man dabei zwei bis fünf Zugänge, die niemand mehr braucht. Sie zu widerrufen, ist die günstigste Sicherheitsmaßnahme überhaupt — sie kostet nichts und nimmt Angriffsfläche weg, ohne dass jemand etwas anders machen muss.