Die vier größten Missverständnisse über API-Sicherheit

Illustration: Absmeier

APIs bilden die Grundlage für digitale Services und modernisierte Anwendungen. Wir alle benutzen sie, ob wir eine Mitfahrgelegenheit buchen, unser Bankkonto verwalten oder online bestellen. Um den damit verbundenen Datenaustausch zu erleichtern, brauchen wir APIs. Während der Covid-Pandemie wuchs der Bedarf an Online-Diensten deutlich – und die Nutzung von APIs stieg deutlich an. In einer Umfrage aus dem Jahr 2022 gaben mehr als 25 Prozent der Unternehmen aus allen Branchen an, dass sie jetzt doppelt so viele APIs nutzen wie im Vorjahr.

 

Angespornt durch dieses Wachstum haben sich APIs auch zu einem Top-Angriffsziel für Cyberkriminelle und Hacker entwickelt. Die oben erwähnte Studie ergab auch, dass der API-Angriffsverkehr im Jahr 2021 um 681 Prozent zunahm, der gesamte API-Verkehr wuchs um 321 Prozent.

APIs wurden speziell für Dienste entwickelt, die wichtige Daten mit Ihren Kunden, Partnern und Mitarbeitern austauschen. Mobile Anwendungen laufen auf APIs. Untersuchungen zeigen, dass mehr als 80 Prozent des Internetverkehrs über APIs abgewickelt werden. Unternehmen verfügen heute über Tausende von APIs, und diese ändern sich regelmäßig. In seinem 2021 State of the API Report fand das Unternehmen Postman heraus, dass mehr als die Hälfte aller Entwickler neue APIs einmal pro Tag, einmal pro Woche oder einmal pro Monat in der Produktion einsetzen.

Darüber hinaus werden APIs sowohl über externe Partner- als auch über Kundenkanäle genutzt und ermöglichen neue mobile und Online-Dienste. Dabei erleichtern sie aber auch die Konnektivität für die Nutzung hochsensibler Daten wie personenbezogene Daten, Finanzdaten und medizinische Daten. APIs enthalten den Schlüssel zu diesen wertvollen Daten – und sind deshalb zum attraktiven Ziel für Angreifer geworden. Dies zeigt die wachsende Zahl von Cyber-Bedrohungen, die auf Unternehmens-APIs abzielen.

Viele Unternehmen, darunter Parler, Experian, Facebook und Peloton, haben API-Verletzungen erlebt. API-Angriffe können das Vertrauen der Kunden mindern, Umsatzeinbußen verursachen und den Ruf eines Unternehmens unwiderruflich schädigen. Im schlimmsten Fall kann eine API-Schwachstelle das Unternehmen in den Ruin treiben.

Trotz all dieser Risiken sind APIs häufig nur unzureichend geschützt. Nach den neuesten Untersuchungen von Salt Labs haben  . Wenn Unternehmen verstehen, welche Missverständnisse ihre API-Sicherheitsrisiken erhöhen, können sie die Wahrscheinlichkeit eines Sicherheitsvorfalls verringern. Zu den häufigsten Irrtümern gehören:

 

  • API-Gateways und WAFs sichern APIs
  • Entwickler bauen Sicherheit in APIs ein
  • Zero-Trust-Architektur schützt APIs
  • Anbieter von Cloud-Diensten bieten API-Sicherheit

 

Irrtum Nr. 1: API-Gateways und WAFs sichern APIs

Web Application Firewalls (WAFs) und API-Gateways spielen eine wichtige Rolle im Sicherheitssystem eines Unternehmens. WAFs helfen bei der umfassenden Erkennung von Exploits für den Webanwendungsverkehr, und API-Gateways ermöglichen die Beobachtung der API-Nutzung und die Durchsetzung von Zugriffskontrollen. Beide bieten jedoch nicht die Transparenz und die Sicherheitskontrollen, die zum Schutz von APIs erforderlich sind.

Da API-Gateways und WAFs für das Erkennen von Angriffen auf Signaturen und Regeln angewiesen sind, können sie API-spezifische Probleme wie den Missbrauch von Geschäftslogik und Autorisierungs-Exploits nicht erkennen. Dazu gehört die »Broken Object Level Authorization« (BOLA), die von der OWASP API Security Top 10 als das am weitesten verbreitete API-Sicherheitsrisiko bezeichnet wird.

API-Gateways und WAFs basieren zudem auf Proxys. Da ein Proxy-Modell jedoch die API-Kommunikation verlangsamt, setzen Unternehmen in der Regel nicht jede API, die innerhalb eines Gateways oder einer WAF verwendet wird, um. In Folge dessen verlieren Unternehmen den Überblick darüber, wie diese APIs genutzt werden.

 

Irrtum Nr. 2: Entwickler bauen Sicherheit in APIs ein

Das Shift-Left-Konzept sieht vor, mehr Sicherheitsprozesse in die frühe Entwurfs- und Entwicklungsphase zu verlagern. Dies soll helfen, Sicherheitsprobleme früher zu erkennen und zu beheben, bevor sie in die Produktion gelangen, wo deren Behebung mehr Zeit und Ressourcen in Anspruch nimmt.

Auch wenn einige bekannte Schwachstellen oder Schwachpunkte durch Sicherheitsanalyse- und Testtools identifiziert werden können, lassen sich viele Arten von Sicherheitsproblemen nicht im Rahmen von automatisierten Design-, Entwicklungs- und Build-Scans erkennen. Unternehmen sollten nicht davon ausgehen, dass die Einführung von Shift-Left-Ansätzen bedeutet, dass die Sicherheit von den jeweiligen Entwicklungs-, API-Produkt- oder DevOps-Teams in jede API integriert wird.

Eine wirksame API-Sicherheitsstrategie setzt voraus, dass einige Kontrollen außerhalb des Codes vorhanden sind. Das Erkennen der meisten Fehler in der Business-Logik und des API-Missbrauchs erfordert eine Verhaltensanalyse während der Laufzeit. API-Entwicklerteams können dann die gewonnenen Erkenntnisse nutzen, um APIs gegen das breite Spektrum von API-Angriffsmustern zu schützen.

 

Irrtum Nr. 3: Eine Zero-Trust-Architektur schützt APIs

Zero Trust befürwortet den Aufbau von »vertrauenswürdigen« Umgebungen (in der Regel Netzwerkzonen), in denen Anwendungen, Systeme und Daten gehostet werden, die mit den geringsten Zugriffsrechten arbeiten. Die Idee dahinter ist, dass Zero Trust die Ressourcen innerhalb dieser »vertrauenswürdigen« Umgebungen angemessen schützen kann.

Mit Zero-Trust und APIs gibt es eine ganze Reihe von Problemen. Sinn und Zweck von Zero-Trust ist es, den Zugang zu beschränken, doch für das Funktionieren von APIs in der Zugang unerlässlich. Die Methoden der Zugangskontrolle versagen bei der API-Sicherheit. Viele Zero-Trust-Network-Access-Angebote (ZTNA) verwenden beispielsweise die Two-Factor-Authenication zur Authentifizierung, bevor sie den Zugriff erlauben. Diese Technik eignet sich jedoch nicht für die Kontrolle der direkten API-Kommunikation.

Unternehmen, die sich auf Zero-Trust-Sicherheitsprinzipien konzentrieren, müssen verstehen, wann diese Prinzipien nicht vollständig schützen. Sie sollten ihre Investitionen in die Zero-Trust-Technologie durch Lösungen ergänzen, die Sicherheit bieten, während sie den Zugriff ermöglichen. Im Falle von APIs bedeutet dies, dass sie wissen müssen, welcher API-Verkehr zugelassen oder blockiert werden soll, damit Unternehmen ihre APIs und die von ihnen betriebenen Anwendungen schützen können.

 

Irrtum Nr. 4: Cloud Service Provider bieten API-Sicherheit

Auch wenn einige Cloud-Anbieter Tools wie API-Verwaltung und API-Gateways anbieten, bieten diese punktuellen Produkte nicht das Maß an Schutz, das Unternehmen für ihre APIs benötigen. Mit begrenzten API-Sicherheitsfunktionen auf der Anwendungs- und API-Ebene sind APIs nicht ausreichend geschützt, wenn man sich ausschließlich auf die Tools des Cloud-Anbieters verlässt. Da es sich bei APIs um Anwendungslogik handelt, tragen Cloud-Kunden im Rahmen des Modells der geteilten Verantwortung für die Sicherheit die letzte Verantwortung für deren Schutz.

 

Die Realität: Heutige Unternehmen benötigen dedizierte API-Sicherheitstools

Interne Digitalisierungsinitiativen, mobile Anwendungen und webbasierte Dienste tragen alle zur verstärkten Nutzung von APIs bei. Die Angriffsfläche ist bereits beträchtlich und wird jeden Tag größer. Doch die Art und Weise, wie Unternehmen in der Vergangenheit eine Handvoll APIs schützen konnten, funktioniert nicht mehr, wenn schnell Dutzende oder Hunderte von APIs hinzukommen.

95 Prozent der Unternehmen waren im Jahr 2021 von einem API-Sicherheitsvorfall betroffen. Deshalb ist es jetzt an der Zeit, spezielle API-Sicherheitstools einzuführen, um die zunehmenden API-Sicherheitsbedrohungen zu entschärfen. Um API-Angriffe erfolgreich zu identifizieren und zu blockieren, müssen diese API-Tools in der Lage sein, umfassenden Kontext zum API-Verhalten zu liefern und gleichzeitig kontinuierlich API-Attribute über Millionen von Nutzern und API-Aufrufen hinweg zu analysieren. Hierfür sind Big Data im Cloud-Maßstab mit KI, ML und Automatisierung erforderlich.

Daniel Wolf, Regional Director DACH, Salt Security