Ein Marketingteam verbindet im Frühjahr ein neues Analyse-Tool mit dem CRM. Der Dienstleister, der die Anbindung einrichtet, bekommt dafür einen Zugang – vorübergehend, so ist es gedacht. Ein halbes Jahr später ist das Projekt abgeschlossen, das Tool gekündigt, das Team teilweise neu besetzt. Die Schnittstelle läuft weiter. Wer sie eingerichtet hat, weiß niemand mehr genau, und in keinem Verzeichnis taucht sie auf. Genau an dieser Stelle beginnt API-Sicherheit: nicht bei Firewalls oder Verschlüsselung, sondern bei der Frage, welche Verbindungen ein Unternehmen überhaupt betreibt, wer sie verantwortet und welche Daten über sie fließen.
Gewachsen, verbunden, nirgends verzeichnet
Solche Verbindungen entstehen selten durch eine zentrale Entscheidung. Das Controlling automatisiert Berichte über einen Cloud-Dienst, der Vertrieb koppelt sein Angebotstool an die Warenwirtschaft, ein externer Partner erhält Zugriff auf ein internes System. Jede dieser Integrationen löst ein konkretes Problem. In der Summe entsteht daraus eine technische Realität, die kaum noch jemand vollständig überblickt: Die zentrale IT sieht einen Teil, während Fachbereiche, Dienstleister und Projektteams längst eigene Verbindungen eingerichtet haben.
So entstehen Schatten-APIs – Schnittstellen außerhalb des Blickfelds der zentralen IT. Dazu kommen Testendpunkte, die nach Projektende aktiv bleiben, und alte Integrationen, die einen Tool-Wechsel überleben, weil niemand prüft, ob sie noch gebraucht werden. Wer API-Sicherheit nicht als reines Gateway- oder Firewall-Thema versteht, landet früher oder später bei einer unbequem einfachen Frage: Welche Schnittstellen gibt es bei uns überhaupt?
Der Schaden beginnt vor dem Angriff
Eine vergessene Schnittstelle ist kein abstraktes Risiko. Sie kann Kundendaten, Preislisten oder interne Dokumente erreichbar machen, ohne dass ein Angreifer eine einzige Firewall überwinden muss. Fließen personenbezogene Daten ab, kann das datenschutzrechtliche Prüf- und Meldepflichten auslösen; der Europäische Datenschutzausschuss beschreibt in seinen EDPB-Leitlinien, wie solche Vorfälle einzuordnen sind. Der eigentliche Schaden entsteht aber oft früher: Schon die Frage, warum eine alte Verbindung noch Zugriff hatte, beschädigt das Vertrauen von Kunden, Partnern und den eigenen Fachbereichen.
Auch der umgekehrte Fall trifft hart. Fällt eine Verbindung aus, an der ein zentraler Geschäftsprozess hängt, stehen Bestellungen, Rechnungen oder Datenabgleiche still – und weil die Integration nirgends dokumentiert war, sucht die IT die Ursache dort, wo sie zuletzt hingeschaut hat, nicht dort, wo das Problem liegt. Technisch ist das ein Ausfall. Aus Sicht des Geschäfts ist es ein Prozessbruch.
Das US-amerikanische NIST hat für cloud-native Systeme eine NIST-Leitlinie veröffentlicht, die Risiken und Schutzmaßnahmen über Entwicklung und Laufzeit hinweg behandelt. Sie macht ein Grundproblem deutlich: Klassische Perimeter-Kontrollen greifen bei Maschinenverkehr nur begrenzt. Anfragen kommen mit gültigen Schlüsseln und Token, sie sehen aus wie normaler Betrieb – Missbrauch fällt erst auf, wenn jemand gezielt auf Muster, Volumen und ungewöhnliche Datenzugriffe achtet.
Ein Vertrag endet, ein Schlüssel bleibt gültig
Schnittstellen haben einen Lebenszyklus: entwerfen, anbinden, nutzen, stilllegen. In der Praxis fehlt oft der letzte Schritt. Der SaaS-Vertrag endet, aber der API-Schlüssel des Anbieters funktioniert weiter. Das Projekt ist abgeschlossen, die Testintegration läuft. Das Entwicklerteam wechselt, und mit ihm verschwindet das Wissen, wofür eine Verbindung überhaupt eingerichtet wurde.
So entstehen Zombie-APIs: Schnittstellen, die technisch funktionieren, aber keinen Eigentümer, keinen Zweck und keine Überwachung mehr haben. Die Fragen dahinter klingen weniger nach Technik als nach Governance. Werden Schlüssel und Token regelmäßig erneuert? Arbeiten alle Teams nach denselben Regeln? Und sitzt die Sicherheitsabteilung mit am Tisch, bevor eine Integration live geht – oder erst, wenn etwas passiert ist?
Fünf Fragen, die jede Schnittstelle beantworten muss
Der Weg aus dem Blindflug beginnt mit einer Inventur, und die ist unbequemer, als sie klingt: Ein Verzeichnis aller aktiven Schnittstellen fördert regelmäßig Verbindungen zutage, die niemand mehr erklären kann. Erst danach lohnt sich die zweite Frage: Welche Verbindungen sind geschäftskritisch, welche berühren sensible Daten? Eine Anbindung an das Newsletter-Tool verdient andere Aufmerksamkeit als eine, über die Kundendaten oder Zahlungsinformationen laufen. Wie schnell aus einer technischen Abhängigkeit ein operatives Risiko wird, zeigt auch der Blick auf Cloud-Ausfälle in Unternehmen: Wenn zentrale Anwendungen nicht erreichbar sind, stehen nicht nur Systeme still, sondern oft ganze Geschäftsprozesse.
Jede Schnittstelle braucht zudem einen Eigentümer – nicht als Formalie, sondern als Adresse für die Fragen, an denen es im Alltag hakt: Wozu existiert die Verbindung? Wird sie noch gebraucht? Wer darf entscheiden, dass sie abgeschaltet wird? Ohne verantwortliche Person bleibt jede Dokumentation ein Schnappschuss, der schneller veraltet, als er entsteht.
Auf dieser Grundlage greifen die technischen Maßnahmen: Zugriffsrechte nach dem Prinzip der minimalen Berechtigung, regelmäßige Rotation von Schlüsseln und Token, geordnete Stilllegung alter Verbindungen. API-Gateways und Ratenbegrenzung bündeln den Zugriff und machen Ausreißer sichtbar, Monitoring und Logging müssen den Maschinenverkehr ausdrücklich einschließen, und die Incident-Response-Planung sollte durchspielen, was passiert, wenn eine Schnittstelle ausfällt oder missbraucht wird. Gute API-Sicherheit zeigt sich am Ende nicht an der Zahl der Werkzeuge, sondern daran, ob ein Unternehmen für jede Verbindung fünf Fragen beantworten kann: Wer kennt sie? Wem gehört sie? Welche Daten berührt sie? Wer darf sie nutzen? Und was passiert, wenn sie ausfällt?
Was ein Gateway nicht schützen kann
Unsichtbare Schnittstellen sind kein Werkzeugproblem, sondern ein Organisationsproblem – und deshalb hilft es wenig, die Lösung im Produktkatalog zu suchen. Ein Gateway schützt nur die Verbindungen, die es kennt. Ein Monitoring meldet nur, was es beobachten darf. Wer die Inventur auslässt, kauft Sicherheit für einen Ausschnitt der eigenen Landschaft und erklärt den Rest stillschweigend zum Restrisiko. Die unbequeme Reihenfolge lautet deshalb: erst zählen, dann zuordnen, dann absichern. Das klingt nach Verwaltungsarbeit, und genau das ist es auch. Aber es ist die Verwaltungsarbeit, die darüber entscheidet, ob die vergessene Verbindung aus dem Frühjahr ein Eintrag in einem Verzeichnis bleibt – oder der Anfang eines Vorfalls wird.
![Samsung Galaxy A17 5G AI Smartphone, KI-Handy mit Android, Dünner 7,5-mm-Rahmen, 50-MP-Kamera, 128 GB Speicher, 4 GB RAM, 5.000-mAh-Akku, Black, 2,5 Jahre Herstellergarantie [Exklusiv auf Amazon]](https://m.media-amazon.com/images/I/41AjombgQqL._SS520_.jpg)
![Samsung Galaxy A16 4GB+128GB [Internationale Version] (Gray)](https://m.media-amazon.com/images/I/41YKywbBFfL._SS520_.jpg)
![Samsung Galaxy A17 5G AI Smartphone, KI-Handy mit Android, Dünner 7,5-mm-Rahmen, 50-MP-Kamera, 128 GB Speicher, 4 GB RAM, 5.000-mAh-Akku, Blue, 2,5 Jahre Herstellergarantie [Exklusiv auf Amazon]](https://m.media-amazon.com/images/I/41udwsmCASL._SS520_.jpg)
