Von Heinrich Vaske

Unternehmen sind auf den Einsatz von Application Programming Interfaces (APIs) angewiesen. Sie ermöglichen es, dass Anwendungen miteinander kommunizieren und sorgen für den Austausch von Daten und Funktionen. Konkret legen APIs fest, wie Anfragen zwischen Systemen formuliert werden, welche Datenformate verwendet werden (etwa JSON) und welche Regeln und Protokolle beachtet werden müssen.

Da APIs in Zeiten von Cloud Computing, Microservices und mobilen Anwendungen die IT-Shops in den Betrieben geradezu überschwemmen, entstehen an dieser Stelle erhebliche Risiken. Deshalb hat sich API-Sicherheit neben klassischen Disziplinen wie Applikations- und Netzsicherheit zu einer der wichtigsten Disziplinen der IT-Security entwickelt.

Problematisch ist, dass APIs oft nicht sauber inventarisiert und unter dem Radar der Sicherheits-Verantwortlichen betrieben werden (Stichwort: Shadow APIs). Erschwerend hinzu kommt, dass die zentralen Sicherheitsmechanismen im Zusammenhang mit APIs, nämlich Authentifizierung (wer ist der Nutzer?) und Autorisierung (was darf der Nutzer tun?), häufig Schwächen aufweisen.

Brute-Force-Angriffe, Token-Diebstahl, Session-Hijacking

Die APIs prüfen dann nicht ausreichend, ob ein Nutzer berechtigt ist, ein spezifisches Objekt, beispielsweise eine Datenzeile, anzusehen oder zu verändern. Dadurch fällt es Angreifern leicht, auf sensible Daten zuzugreifen oder diese zu manipulieren. Die Authentifizierungsmechanismen sind zudem nicht immer robust genug und ermöglichen Brute-Force-Angriffe, Token-Diebstahl oder Session-Hijacking. Angreifer können Identitäten übernehmen und sich unautorisierten Zugriff verschaffen.

Eine weitere bekannte Schwäche von APIs ist, dass sie zu viele Informationen zurückliefern (Datenüberbelichtung), was das Risiko für Datenlecks erhöht. Sie geben dann bei einer Anfrage mehr Felder oder sensible Eigenschaften zurück, als benötigt werden oder erlaubt sind. Werden die Zugriffsrechte nicht im Detail geprüft, können Angreifer an vertrauliche Informationen gelangen und Daten unbemerkt ändern.

Auch unverschlüsselte Verbindungen und Fehlkonfigurationen sind ein Risiko. In Unternehmen besteht oft kein Konsens darüber, welche Standards für APIs überhaupt gelten. Unterschiedliche Teams nutzen APIs, die nicht den gleichen Sicherheitsstandards folgen.

API-Monitoring: mangelhaft

Gerade die Verbreitung von Microservices und Cloud-Umgebungen hat die Angriffsfläche vergrößert. Die Service-Module kommunizieren via API, was die Risiken erhöht – und viele Unternehmen merken nichts davon, weil ihr API-Monitoring mangelhaft ist. Sie überwachen die genutzten APIs nicht in Echtzeit. Besonders groß ist die Herausforderung, wenn Partnerlösungen per Programmierschnittstelle eingebunden werden. Auch alte, längst vergessene APIs können ein Sicherheitsrisiko darstellen. Durch sie bleiben Endpunkte erreichbar, die nicht mehr gepatcht werden.

Die schöne neue KI-Welt löst das Problem nicht von selbst. KI-Modelle, die auf öffentlich verfügbaren Codebasen trainiert werden, übernehmen die vorgefundenen Fehler und Schwachstellen unbemerkt in neue Projekte. Veraltete und ungepatchte Bibliotheken werden dann in API-Projekte integriert, was die Angriffsfläche vergrößert. Zudem priorisieren KI-Tools in der Regel Funktionalität vor Sicherheit. Damit werden Schutzmechanismen wie eine strikte Zugriffskontrolle, Authentifizierung oder Eingabevalidierung oft gar nicht oder zu schwach implementiert.

KI-generierte APIs verwenden zudem häufig schwache Zugangsschlüssel, unzureichende Sitzungsverwaltungen, und sie verzichten auf Mehrfaktor-Authentifizierung. Auch fehlen grundlegende Schutzmechanismen gegen den Missbrauch von Endpunkten, und die Input-Validierung ist zuweilen mangelhaft, so dass solche APIs anfällig sind für SQL-Injection und Cross-Site Scripting.

Nicht alle Entwickler sind sich dieser Defizite bewusst. Viele glauben, KI-generierter Code sei per se sicher. Sie vertrauen den Vorschlägen des Programmierassistenten nahezu blind und verzichten auf Sicherheitsprüfungen wie Code-Reviews und Penetrationstests.

Was CIOs und CISOs tun sollten

Für IT-Verantwortliche geht es erst einmal darum, die Transparenz zu verbessern und die Inventarisierung ernst zu nehmen. Viele setzen dabei auf eine API-Governance und lassen die verwendeten APIs flächendeckend erfassen. Außerdem beschreiben sie den Zweck der verwendeten APIs, wer Ansprechpartner ist und welcher Schutzbedarf besteht.

Um Shadow-APIs zu finden, empfiehlt es sich, alle internen und externen Programmierschnittstellen zu katalogisieren. Hilfreich sind dafür Discovery-Tools, die den Netzwerk- und Cloud-Datenverkehr analysieren und herausfinden, welche APIs genutzt werden.

Als mögliche Lösung sei hier beispielhaft „Microsoft Defender for Cloud Apps“ genannt. Integriert in Firewalls, Proxys und Endgeräten sammelt sie Daten und wertet diese aus. Häufig eingesetzt werden auch Cloudflare API Discovery, Postman, Apigee von Google, MuleSoft von Salesforce oder Boomi von Dell – um nur einige zu nennen. Discovery-Tools sind idealerweise mit Endpoint-Sicherheitssoftware oder SIEM-Systemen verknüpft, so dass Schatten-APIs anhand von Protokolldaten, Nutzeraktivitäten und Traffic-Mustern entdeckt werden können.

Security by Design: Sicherheit von Anfang an

Ein weiterer Lösungsansatz ist Security by Design (SoD): Gelingt es, Sicherheit schon im API-Design zu berücksichtigen, indem auf zentrale SoD-Elemente wie Bedrohungsmodellierung (Threat Modeling), Input-Validierung oder das Prinzip der minimalen Rechte (Least-Privilege-Prinzip) gesetzt wird, lassen sich Risiken in einem frühen Stadium senken.

Natürlich helfen auch kontinuierliches Testing, automatisierte Security-Checks und Penetrationstests, Schwachstellen früh zu erkennen und automatisiert zu beseitigen. Diese Maßnahmen sollten integrale Bestandteile von CI/CD-Pipelines sein. Das Testing wird dabei durch Tools und Skripte in den Build- und Deploy-Prozess integriert, so dass Fehler und mögliche Sicherheitsprobleme sofort an den Entwickler zurückgemeldet werden.

Auf der sicheren Seite ist auch, wer standardisierte Authentifizierungsmethoden wie OAuth2, Multifaktor-Authentifizierung (MFA) und eine rollenbasierte Zugriffskontrolle (RBAC) nutzt. Sie erhöhen die API-Sicherheit durch das Absichern und Einschränken von Zugriffen. Während OAuth2 eine standardisierte Authentisierung und Autorisierung durch tokenbasierte Verfahren bereitstellt, erhöht die MFA die Sicherheit beim Nutzerzugang. RBAC begrenzt den Zugriff auf APIs auf notwendige Rechte, basierend auf vorher definierten Rollen und Verantwortlichkeiten.

Viele Unternehmen haben bereits End-to-End-Verschlüsselung eingeführt oder planen dies. Das ist auch für die API-Sicherheit wichtig, weil so der Schutz von Daten zwischen dem Client und dem finalen API-Endpunkt gewährleistet ist. Inhalte bleiben während der gesamten Übertragung geschützt vor unbefugtem Zugriff, Abhören oder Manipulation. Wenn Daten auf der Client-Seite verschlüsselt werden und bis zum Empfänger verschlüsselt bleiben, können keine zwischengeschaltete API-Gateways, Server oder sonstige Dritte darauf zugreifen. So werden nicht nur Compliance-Anforderungen (DSGVO, HIPAA u.a.) erfüllt, auch Man-in-the-Middle-Angriffe werden deutlich erschwert.

Datenüberbelichtung verhindern

Um die erwähnte Datenüberbelichtung (Overexposure) zu verhindern, haben sich nicht nur die Einführung des Least-Privilege-Prinzips, strikte Zugriffskontrollen und Authentifizierung bewährt. Auch der Einsatz von Filter- und Maskierungsmechanismen kann sich lohnen, da sich damit verhindern lässt, dass vertrauliche Felder wie Kreditkarten- oder Sozialversicherungsnummern zu den Clients gelangen.

Von der Komplexität der eigenen API-Landschaft, den eingesetzten Tools, dem Automatisierungsgrad und dem verfügbaren Budget hängt ab, wie tief Unternehmen in Logging, Laufzeit-Monitoring und Anomalie-Erkennung einsteigen wollen. So erfordern Endpunktkonfigurationen, Testdefinitionen und auch die Einbindung von Monitoring-Tools einiges an Zeit und Know-how. Hinzu kommt der Aufwand für Betrieb und Wartung: Datenanalyse, Anomalieprüfungen, Alarmmanagement und Systempflege sind nicht umsonst zu haben. Immerhin lassen sich viele Aufgaben automatisieren – zum Beispiel mit Tools von Datadog, Postman oder IBM.

CIOs und CISOs sollten ihre Entwickler- und Produktteams auch zu Security-Schulungen verpflichten. Es gilt, das Bewusstsein für API-Sicherheit zu schärfen und Best Practices zu vermitteln. Auch sollte gewährleistet sein, dass die Verantwortlichen für Architektur, Security, Entwicklung und Betrieb in crossfunktionalen Teams eng zusammenarbeiten.

Last, but not least kommen die IT-Sicherheitsverantwortlichen nicht drum herum, Governance und Compliance sicherzustellen, also regelmäßige Audits vorzunehmen und die Einhaltung und Aktualisierung ihrer Policies sicherzustellen. APIs müssen immer den unternehmenseigenen und auch den gesetzlich-regulatorischen Vorgaben genügen. Security ist eine Kernaufgabe der IT, nicht immer sind die Kulturen der Teams enstprechend ausgeprägt. Gelingt es, das Bewusstsein zu schärfen, können CIOs und CISOs ihre Unternehmen vor API-Sicherheitsvorfällen schützen.