Application-Programming-Interfaces (APIs): Sichere : Sichere Schnittstellen zu Services und Software : Angriffsszenarien und Abwehrmöglichkeiten

Viele Unternehmen setzen im Zuge der digitalen Transformation auf Application-Programming-Interfaces (APIs) – also mehr oder minder offene Schnittstellen zur Anwendungsprogrammierung. Das liegt nahe: Denn auf dem Markt verfügbare Applikationen verfügen über umfangreiche Funktionen, sind robust, leistungsfähig und skalierbar. Gleichzeitig sind APIs jedoch zu einem gleichermaßen „standardisierten“ und willkommenen Ziel der Cyberkriminalität avanciert.

Vor etwas mehr als zehn Jahren war SOAP – anfangs als Akronym für „Simple Object Access Protocol“, heute als Eigenname angesehen – der Quasi-Standard für Web-Services und hat das Arbeiten mit solchen APIs (anders als das „simple“ im Namen vermuten ließe) nicht gerade angenehm gestaltet: SOAP-Calls waren kompliziert aufzurufen, eine entsprechende Infrastruktur musste erst mal aufgebaut werden und ein „Debuggen“ für Antworten war – bedingt durch noch fehlende Statuscodes – schwer machbar.

Inzwischen hat sich die Situation deutlich verbessert und SOAP dazugelernt (wobei „simple“ noch immer nicht stimmt) – und mit dem „Representational State Transfer“ (REST) kam ein neues Paradigma zur Erstellung von Webservices hinzu. Roy Fielding hatte es sich zur Jahrtausendwende in seiner Dissertation [1] zum Ziel gesetzt, APIs klar und einfach zu definieren. Durch seine eindeutig umrissenen und einfach umzusetzenden, universellen Regeln wurde die Art und Weise, wie APIs aussehen müssen, stark vereinfacht. Das erleichterte nicht nur ihre Erstellung und Wartung, sie fanden durch die wachsende Bedeutung des Internets auch schnell einen großen Anwenderkreis.

Im E-Commerce haben Branchengrößen wie Ebay oder Amazon durch den Einsatz von APIs ihre eigene Verbreitung deutlich beschleunigt – auch Dienste wie das Fotoportal Flickr konnten durch APIs ihre Dienstleistungen einfach auf viele verschiedene Plattformen verteilen und dadurch die eigene Präsenz ausweiten. Doch mit der zunehmenden Bedeutung der APIs wuchs auch ihre Attraktivität aus der Sicht von Angreifern.

Typische Angriffsszenarien

APIs sind in ihrer Kernfunktion als Bindeglied zwischen unterschiedlichen Systemen und Daten durch ihre einfache Struktur ein willkommenes Ziel von Attacken. Letztlich liefern sie Zugänge zu Ressourcen: Um beispielsweise ein Kundenportal für die eigenen Lieferanten und Kunden anzubieten, bedarf es einer API zur ERP-Software

– so kann etwa ein Lieferant seine Lieferungen überwachen und ein Kunde seine Bestellungen verwalten. Bei ungenügender Authentifizierung könnte jedoch auch ein Wettbewerber hierüber an solche Informationen gelangen

– und diese dann gegen das konkurrierende Unternehmen einsetzen. Die Sicherheit der Schnittstellen nachhaltig zu gewährleisten, ist für Unternehmen und Behörden folglich besonders wichtig.

Wenn ein API Zugriff auf schützenswerte Daten hat, sind Authentifizierung und Autorisierung offensichtlich das A und O. Obwohl das einleuchtend und selbstverständlich klingt, stehen Nachlässigkeiten in diesem Bereich auf Platz zwei der OWASP Top-10 [2], sind also die zweithäufigsten Fehler im Bereich der Webdienste. Aber auch andere fehlende technische Feinheiten rollen Attacken den roten Teppich aus – dazu gehören beispielsweise SQL-Injections, mit denen ein Angreifer bei ungesicherten Schnittstellen mit „hinzugeschummelten“ SQL-Befehlen in der Anfrage mehr Daten abgreift, als beim Design der API vorgesehen war. Einige typische Angriffsvektoren bei der Absicherung von APIs führt Tabelle 1 auf.

Grundregeln für APIs

Um Sicherheitsmaßnahmen für APIs im eigenen Unternehmen nachhaltig zu etablieren, sind einige Vorkehrungen zu treffen: Das beginnt – wieder einmal – mit dem Dokumentieren von Zugriffswegen, um überhaupt an Daten heranzukommen. Hierzu zählen neben extern erreichbaren Kommunikationskanälen auch solche, die über interne Wege führen – denn Schutzmaßnahmen zur Abgrenzung nach außen sind nicht unfehlbar und können überwunden werden. Eine Kategorisierung der Relevanz der eigenen Ressourcen hilft dabei, schnell das Gefahrenpotenzial einschätzen zu können – auch unter dem Gesichtspunkt branchen- oder bereichsspezifischer Regulierung.

Im nächsten Schritt steht die Priorisierung der eigenen APIs auf der Agenda: Nicht immer hat ein API eine hohe Unternehmensrelevanz, wenn es um Verfügbarkeit und Latenz bei Antworten geht. Sollte es jedoch Zugang zu hochsensiblen Systemen besitzen, ist der Zugriff – zumindest von außen – entsprechend einzuschränken. Stuft man das API als unternehmenskritisch ein (etwa, weil wichtige Geschäftsprozesse über die bereitgestellten Daten ablaufen), gelten höchste Anforderungen an die Sicherheit. APIs für eigene Kunden müssen sichere und unverfälschte Daten zuverlässig liefern, sollten aber auch besonders strikt überwacht werden – mit einem Fokus auf Schutzmaßnahmen, welche die Verfügbarkeit sicherstellen.

Um die Sicherheit von APIs festzulegen, lohnt es sich, klare Richtlinien zu definieren:

• keine Datenübertragung ohne Transportverschlüsselung (TLS)
• anonymer Zugriff nur bei allgemeinen APIs, die keinen besonderen Schutzbedarf haben
• Datensparsamkeit: Keine Daten übertragen, die nicht übertragen werden müssen – das Filtern von Kundendaten sollte nicht die Webapplikation übernehmen, sondern schon das Backend
• Nutzung etablierter API-Management-Produkte zur Absicherung gegen Standardangriffswege
• klare Code-Guidelines und eine gelebte Teststruktur (mit Sicherheitsabnahme, bevor APIs veröffentlicht werden)

Eine wichtige Basis dieser Maßnahmen bildet naturgemäß auch die Awareness bei den Mitarbeitern, die über regelmäßige Schulungen hochgehalten werden muss. Wichtig sind auch neue und einfach zu nutzende Kommunikationswege, um auftretende Sicherheitsprobleme melden zu können. Sogenannte Bug-BountyProgramme haben sich in diesem Kontext bewährt – dabei erwarten den Entdecker von Schwachstellen und Sicherheitslücken attraktive Belohnungen (statt Strafen). Dieses Verfahren zieht nicht nur White-Hat-Hacker an, sondern motiviert auch die eigenen Mitarbeiter, auftretende Probleme zu melden und bei der Lösung mitzuhelfen.

Um letztlich über den Zugriff auf eine API zu entscheiden, bedarf es an sich nur dreier einfacher und wohlbekannter Schritte (vgl. [3]):

• Identifizierung: Wer möchte auf das API zugreifen?
• Authentifizierung: Lässt sich die behauptete Identität des Zugreifenden nachweisen?
• Autorisierung: Darf diese Identität diesen Zugriff überhaupt ausführen?

Da diese drei Schritte meist jedoch nicht wirklich für alle APIs benötigt werden, ist es umso wichtiger, klar zu definieren, an welchen Stellen Schutzmaßnahmen erforderlich sind und an welchen nicht.

Best-Practice-Ansätze

• API-Keys für die Identifizierung: Ein API-Key ist eine relativ lange alphanumerische Zeichenkette, die einen bestimmten Dienst oder einen bestimmten Benutzer eindeutig identifiziert – er ist sehr leicht zu verwalten und in Anwendungen einzubauen. Praktischerweise lässt sich über den API-Key auch der Zugriff auf eine API sehr leicht wieder entziehen, falls der Schlüssel beispielsweise durch einen Angreifer missbraucht oder durch eine falsch konfigurierte Anwendung fehlerhaft genutzt wird. Zudem wird hierdurch ein „sanfter Zwang“ zum Update auf eine neue App-Version möglich, indem man (bestimmte) Zugriffe nur mittels eines API-Keys gestattet, der exklusiv in der neuen Version vorliegt.
• Authentifizierung: Hierzu kommen im einfachsten Fall sogenannte HTTP-Basic-Credentials zum Einsatz – sprich Benutzername und Passwort. Für eine einfache Zugriffssteuerung reicht das oft aus, aus Perspektive der Sicherheit ist das aber nur ein Basisschutz. Benötigt man bessere Schutzmaßnahmen, bieten sich föderierte Protokolle an: Dazu gehört das inzwischen etwas betagte, aber nichtsdestotrotz sichere und weitverbreitete XMLFramework der „Security Assertion Markup Language“ (SAML). Alternativ dazu hat sich im Mobile-App-Zeitalter das Protokoll OAuth2 in Verbindung mit „OpenID Connect“ durchgesetzt – bei Neuentwicklungen sollte man, wenn möglich, Letzteres einsetzen.
• Verpflichtende Verschlüsselung: Unverschlüsselte WLANs und Telekommunikationsnetze sind heute mit geringem Aufwand angreifbar – unverschlüsselte Verbindungen lassen sich dann womöglich abhören oder sogar manipulieren. In den letzten Jahren hat sich glücklicherweise die Einstellung vieler Entscheider geändert: Aus dem „Warum brauchen wir Verschlüsselung? Ich habe doch nichts zu verstecken!“ ist mittlerweile oft ein „Warum sollten wir das nicht nutzen?“ geworden. Es ist ratsam, diesem Trend zu folgen und auf eine möglichst umfassende Verschlüsselung mittels TLS und Zertifikaten für alle Verbindungen zu setzen.
• API-Management-Lösungen: Diese professionellen Werkzeuge unterstützen Verantwortliche und Entwickler mit teils nahezu automatischen Sicherheitsmaßnahmen und einer Vielzahl von Hilfestellungen bei der Konfiguration sicherer APIs. Vor allem gegen SQL-Injection sowie XML-/JSON-Attacken kann man damit heute einen nahezu vollständigen Schutz erzielen – er wird lediglich durch die Entdeckung neuer Schwachstellen begrenzt, für die noch keine vordefinierten Maßnahmen vorhanden sind. Gleichzeitig sind solche Systeme – eine richtige Konfiguration vorausgesetzt – ein guter „Enforcement-Point“ für eine obligatorische Verschlüsselung.
• Quotas: Diese können basierend auf API-Keys definiert werden, um Angriffe abzuwehren oder fehlerhaften Anwendungen schnell und einfach den Zugriff zu verwehren. Gleichzeitig besteht damit auch eine weitere Möglichkeit mit Blick auf die Wirtschaftlichkeit: Wer mehr Zugriffe benötigt, kann (bzw. muss) zusätzliche Gebühren bezahlen.

API-Überwachung und -Pflege

Man kann es nicht oft genug sagen: Ein umfassendes Monitoring und ein einfaches Management sind sicherheitsrelevant! Effizientes und intelligentes APIManagement ist dabei von essenzieller Bedeutung, denn es unterstützt die Administratoren dabei, die laufenden Prozesse von der Entwicklung über die Umsetzung bis hin zum Betrieb dauerhaft und ohne großen Zeitaufwand abzusichern.

Um erfolgreich den sich ständig verändernden Marktgegebenheiten zu folgen, ist eine stetige Weiterentwicklung der eigenen Dienste notwendig. Auf der anderen Seite dürfen bereits vorhandene Dienste von dieser Weiterentwicklung auf keinen Fall in Mitleidenschaft gezogen werden. Ein bewährter Ansatz ist es daher, verschiedene Bereitstellungsumgebungen (sog. Stages) einzusetzen. Damit lassen sich etwa in einer speziell für Entwickler vorgesehenen Umgebung neue Funktionen ausprobieren, während eine Testumgebung entsteht, um neue Funktionalität vor der Produktivstellung zu prüfen und mit möglichst realitätsnahen Daten zu testen. Und die möglichst stabil laufende Produktivumgebung arbeitet wiederum unabhängig davon, um den Kunden eine gleichbleibende Qualität der Services anbieten zu können.

Es ist zwar auch möglich, neue Funktionen in jede Umgebung manuell einzupflegen und dabei ebenso manuell umfangreiche Tests durchzuführen. Diese Vorgehensweise hat sich in der Praxis aufgrund ihrer Fehleranfälligkeit jedoch nicht bewährt – ganz zu schweigen vom hohen Ressourcenbedarf. Hier helfen API-ManagementLösungen, statt fehleranfälliger manueller Re-Konfiguration eine automatisierte Anpassung vorzunehmen und die (optional automatische) Migration zwischen den Umgebungen zu optimieren. Im besten Fall können auch Tests selbstständig durch das System erfolgen, was eine erhebliche Zeitersparnis bedeutet.

Wie so oft liegt bei der Verwaltung von APIs der Teufel im Detail. Es ist daher ratsam, bei der Auswahl geeigneter API-Management-Lösungen genau abzuwägen, welche Funktionen sofort Mehrwerte bieten können – etwa bei der Entwicklung (Dev) – und welche Funktionen gegebenenfalls erst im Dauerbetrieb (Ops) ihren vollen Nutzen entfalten. Praxisbewährte Anwendungen überwachen beispielsweise die APIs in Echtzeit und melden auftretende Probleme sofort. Von Vorteil ist hier eine sogenannte „Auto-healing“-Funktion: Hiermit reagiert das System auf erkannte Probleme oder Ausfälle automatisch mit Gegenmaßnahmen – zum Beispiel dem automatischen Erstellen eines Backups und der ebenso automatischen Wiederherstellung früherer API-Versionen, falls Probleme mit aktuellen Varianten auftreten.

Im Sinne einer agilen Entwicklung sollte eine API-Management-Lösung vor allem aber die schnelle Umsetzung von Änderungen im Sinne von „DevOps“ (s. a. [4]) und „Continous-Delivery“-Ansätzen über alle Entwicklungsumgebungen (beispielsweise Entwicklungs-, Test- und Produktivumgebung) hinweg unterstützen.

Fazit

Die digitale Transformation zwingt alle Branchen, neue Wege zu gehen. APIs haben sich dabei als offene Anwendungsprogrammierschnittstellen aufgrund ihrer Robustheit, Skalierbarkeit und Leistungsfähigkeit bewährt. Ihr Anwendungszweck, nämlich anderen Programmen Zugriff auf mitunter sensible Daten zu geben, ruft jedoch leider auch Angreifer auf den Plan. Folglich sind Unternehmen gut beraten, wenn sie ihre APIs bestmöglich absichern.

Hier können die Verantwortlichen auf BestPractice-Modelle aufsetzen, die nachhaltigen Schutz versprechen. Gleichzeitig sollten sie wachsam bleiben und neue Angriffsszenarien im Blick behalten, um rechtzeitig notwendige Strategien ableiten zu können. Daneben hilft ein intelligentes API-Management, den vollen Mehrwert des digitalen Bausteins „API“ zu entfalten. So sollte beispielsweise eine einfache Migration neuer API-Versionen unkompliziert möglich sein und unter keinen Umständen zum Ausfall nachgelagerter oder korrelierender Systeme führen können.

Waldemar Rosenfeld ist Senior Services Consultant bei der APIIDA AG.

Literatur

[1] Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, Doktorarbeit, UC Irvine, 2000, www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm

[2] Open Web Application Security Project (OQASP), OWASP Top 10 – 2017, The Ten Most Critical Web Application Security Risks, November 2017, www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

[3] Dan Woods, Daniel Jacobson, Greg Brail, APIs: A Strategy Guide, Creating Channels with Application Programming Interfaces, O’Reilly, 2011, ISBN 978-1-4493-0892-6

[4] Stefan Beißel, DevOps aus Sicherheitsperspektive, 2014# 6, S. 6