Das Problem mit der API-Sicherheit

Nach einer Datenschutzverletzung, bei der 37 Millionen T-Mobile-Konten betroffen waren, liegt der Schwerpunkt derzeit auf der Sicherheit von Anwendungsprogrammierschnittstellen (APIs). APIs sind die Grundlage für die gemeinsame Nutzung von Daten, insbesondere im Zeitalter der digitalen Wirtschaft, sodass inzwischen Millionen von APIs verwendet werden. Leider wurde die Sicherheit dieser APIs bisher nur stiefmütterlich behandelt, wobei sich das Ganze jetzt zuspitzt.

T-Mobile berichtet, dass die kompromittierte API zwar Zugriff auf Kundendaten ermöglichte, aber keine Zahlungsdaten, Sozialversicherungsnummern/Steuernummern, Führerschein- oder andere staatliche Identifikationsnummern, Passwörter/Persönliche PIN-Nummern oder andere Finanzdaten offengelegt wurden. Mit anderen Worten: Es hätte viel schlimmer kommen können.

Das Problem, mit dem viele Unternehmen bei der API-Sicherheit konfrontiert sind, ist, dass nicht immer klar ist, wer dafür verantwortlich ist. Entwickler erstellen routinemäßig APIs zum Austausch von Daten. Die meisten dieser APIs basieren auf der REST-Architektur, aber auch andere Arten von APIs, die z. B. auf GraphQL basieren, gewinnen zunehmend an Bedeutung. Das Kernproblem besteht darin, dass Entwickler, die diese APIs erstellen, kaum Fachwissen über Cybersecurity haben. Das bringt viele Fehlermöglichkeiten mit sich, die Cyberkriminelle zur Extraktion von Daten nutzen.

Leider haben Cybersecurity-Teams in der Regel nur wenig Einblick in die Erstellung und Bereitstellung dieser APIs. Infolgedessen sind all diese APIs tatsächlich ungesicherte Endpunkte. Glücklicherweise sind die meisten dieser APIs intern ausgerichtet, sodass das eigentliche Problem die Sicherheit der APIs ist, die von außen zugänglich sind. Obwohl es weniger dieser APIs gibt, sollten Cybersecurity-Teams die Sicherheit von intern ausgerichteten APIs nicht ignorieren. Es braucht nicht viel, damit Entwicklungsteams interne APIs für externe Benutzer zugänglich machen. Was also heute noch sicher genug erscheint, kann morgen zu einem großen Problem werden, wenn eine Geschäftseinheit beschließt, eine bestehende API, aus welchen Gründen auch immer, für eine Einheit außerhalb des Unternehmens zugänglich zu machen.

Zumindest theoretisch übernehmen Entwickler mehr Verantwortung für die API-Sicherheit, da die Anwendungssicherheit im Allgemeinen durch die Übernahme bewährter DevSecOps-Praktiken weiter nach links verschoben wird. Die Zahl der bereits erstellten APIs geht jedoch in die Millionen. Außerdem gibt es eine unbeschreibliche Anzahl von „Zombie-APIs“, die von Entwicklungsteams aufgegeben wurden, aber immer noch Zugang zu Daten bieten. Im Allgemeinen liegt es immer noch in der Verantwortung der Cybersecurity-Teams, alle erstellten API-Endpunkte zu finden und zu sichern.

Unabhängig davon, wer in einem Unternehmen letztendlich für die API-Sicherheit verantwortlich ist, liegt es auf der Hand, dass ihr nicht genug Aufmerksamkeit geschenkt wird. Dieselben Cybersicherheitsprobleme, die Webanwendungen seit Jahren plagen, betreffen auch APIs. Das Problem ist, dass es wesentlich mehr unsichere APIs als Webanwendungen gibt. Die Wahrscheinlichkeit, dass die meisten Unternehmen im Jahr 2023 mit einem API-Sicherheitsproblem konfrontiert werden, ist leider viel größer, als man sich eingestehen möchte.