Headerbild

eBizTalk - Berichten, Unterhalten, Weiterbilden

Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

API Management - Teil 4 - API-Sicherheit

Veröffentlicht am 21.08.2020 von Hieronymus Deutsch , APIM

Dieser Artikel ist Teil einer Serie zu API Management. Ziel der Serie ist es, meine Sicht darauf zu geben wie API Management im Enterprise-Kontext eingesetzt werden kann. Es werden also mit jedem Artikel Themen angesprochen, die eine Komplexität aufdeckt, mit der sich Unternehmen auseinandersetzen sollten. In diesem Teil, der vierte, gehe ich auf Sicherheitsaspekte ein.


Was ist „API-Sicherheit“

APIs sind, wie auch schon im Teil 2 der Serie erwähnt, wichtiger Teil einer Geschäftsstrategie in allen Branchen, und dieser Trend scheint nicht so schnell nachzulassen, insbesondere mit dem Aufstieg von IoT.

Die Zahl der öffentlichen APIs, die auf „ProgrammableWeb“ gelistet sind, liegt bei etwa 25.000, während die Zahl der privaten APIs um vieles höher ist als die Zahl der öffentlichen APIs. Diese Zahl wird auch weiter wachsen wie eine Studie von RapidAPI ergibt (Quelle: https://rapidapi.com/blog/rapidapi-developer-survey-insights/). Die gleiche Studie zeigt auch, dass die Zahl der APIs die in einer Firma verwendet werden mit der Größe des Unternehmens ansteigt.

Das sind eine Menge Daten, die über das Internet oder Netzwerk weitergeleitet werden, einige davon sind vertraulich.

Wie kann man also sicherstellen, dass die eigene Firma nicht auf die Liste der Unternehmen kommt, die von erfolgreichen Angriffen betroffen waren?


Viele Blickwinkel auf „Sicherheit“

Wenn man den Zugriff auf APIs sichern möchte, dann muss man sich nicht nur mit der Zugriffssteuerung beschäftigen, sondern auch mit der Sicherung der Umgebung, in der sich die API aufhält. Themen, die also betrachtet werden sollten, sind:

  • Verbindungen direkt oder über das Internet
  • IP white/black-listing
  • Isolierung und Sichtbarkeit der Endpunkte
  • Isolierung des Backends
  • Verschlüsselung der Verbindung
  • Zugriffssteuerung der Aufrufe
  • Zugriffssteuerung auf das Developer-Portal
  • Autorisierung der Aufrufer
  • Authentifizierung der Aufrufer
  • Ausfallsicherung und Load-Balancing
  • Absicherung nach OWASP regeln
  • DDoS Absicherung
  • Etc.


Rolle des API Managements 

Sicherheit ist ein wesentliches Element jeder Anwendung, insbesondere im Hinblick auf APIs, die täglich von Hunderten oder Tausenden von Anwendungen aufgerufen werden. Möglicherweise beseitigt ein API-Management System zwar nicht alle Bedrohungen, aber es kann Sie gegen einige der häufigsten Bedrohungen schützen. Wenn es als Proxy verwendet wird, kann es bösartige Angriffe auf Systeme verhindern. Viele der Sicherheitsmaßnahmen müssen jedoch konfiguriert und auch schon beim Aufsetzen des API Management Systems implementiert werden.

Der erste und fundamentalste Weg durch den das API Management die API schützen kann, ist die Vergabe von Autorisierungs-Schlüsseln, auch „Subscription keys“ genannt. Dieser Schlüssel muss bei jedem Aufruf der API im Header vorhanden sein. Aufrufe, die diesen Schlüssel nicht besitzen, werden bereits vom API Management abgefangen. Es entsteht also keine unnötige Last auf Seiten des Backends.So wie Requests abgefangen werden, die nicht den richtigen Subscription-Key haben, können auch andere Merkmale über „Policies“ konfiguriert werden, die nicht akzeptiert sind. Diese könnten zum Beispiel sein: IP-Bereiche, Größe des Requests, bestimmte Inhalte, Häufigkeit der Requests innerhalb eines Zeitrahmens und viele mehr.

Auch die am häufigsten und auch die nicht so häufig verwendeten Autorisierungsmethoden können bereits im API Management System angewandt werden. OAUTH und Client Certificates sind die am häufigsten verwendeten. Im Folgenden ein Beispiel wie eine solche Konfiguration aussehen könnte. Dieser Policy-Ausschnitt überprüft das Client Certificate, ob es im System hinterlegt ist:


<choose>

<when condition="@(context.Request.Certificate == null || !context.Deployment.Certificates.Any(c => c.Value.Thumbprint == context.Request.Certificate.Thumbprint))" >

<return-response>

<set-status code="403" reason="Invalid client certificate" />

</return-response>

</when>

</choose>

Policies geben dem/r API-Manager/in oder den Entwicklern die Möglichkeit, viele Aspekte der API zu konfigurieren, ohne dass ein Request erst zum Backend weitergeleitet werden muss. Das macht die API nicht nur performanter, sondern limitiert auch den Bereich, in dem neue Sicherheits-mechanismen angewandt werden müssen. So muss zum Beispiel nur im API Management das Zertifikat erneuert werden im Gegensatz zu jedem einzelnem Backend-Service.


Rolle der Systemumgebung & Architektur

Auch wenn die Zugriffssteuerung auf die API selbst essenziell ist, gibt es doch auch andere Risiken, die sich auf die Sicherheit und Verfügbarkeit einer API und das gesamte System auswirken. So könnte durch mögliche Infrastruktur-Probleme, Kriege, Naturkatastrophen und Vielem mehr das Rechenzentrum, in dem der Service oder das API Management laufen, ausfallen. Dies würde nicht direkt unbefugten Zugriff auf Daten erlauben, die unterbrochene Verfügbarkeit der Services könnte jedoch Auswirkungen auf die konsumierenden Systeme haben und somit auf den gesamten Wertschöpfungsprozess. Es ist demnach auch wichtig, die Systemverfügbarkeit sicherzustellen.

Dies kann ermöglicht werden indem kritische Systeme über mehrere Regionen hinweg verfügbar gemacht werden. Meist ist bei solchen Szenarien ein Loadbalancer gefragt um die Requests and den richtigen backend-service weiterzuleiten. API Management kann hier als einfacher Load-balancer fungieren. Eine weitere Möglichkeit, die den Service beinträchtigen kann, ist, wenn es mehr API-Aufrufe gibt als der Service bearbeiten kann. Das kann passieren, wenn der Service zu bestimmten Zeiten besonders häufig aufgerufen wird, oder wenn absichtlich jemand versucht, das System auf diese Weise lahm zu legen (Stichwort DDoS).

Um dieses Risiko zu minimieren, kann man vor einem API Management einen Service platzieren der Requests nach OWASP und Firewall Regeln prüft und auch automatisch DDoS Attacken erkennen und verhindern kann. Diese Services werden meist als Gateways bezeichnet. Im Azure gibt es für diese Funktion „Azure Front Door“ und auch das „Application Gateway“.


Logging, Analyse und Audit

Sicher zu sein ist gut, sicher zu bleiben ist jedoch auch eine Herausforderung. Anfragen sollten zurück verfolgbar sein, um nicht nur den staatlichen Regularien genüge zu leisten, sondern auch um eventuell mistrauen erweckende Verhalten von Konsumenten früh zu erkennen. Wenn ein Konsument zum Beispiel untypisch viele Daten über die API herunterlädt, dann könnte das ein Anzeichen dafür sein, dass dieser Schaden verursachen möchte.

API Management Systeme bieten meist eine umfassende Prüfungsmöglichkeit aller eingehenden Anfragen, jedoch nur für eine Teilmenge. Wenn ein vollständiges Audit oder verschiedene Rückverfolgungsdetails erforderlich sind, kann APIM so konfiguriert werden, dass diese Details an einen Logger weitergeleitet werden. Aus Performance-Gründen publiziert der Logger normalerweise an einen Event Hub. Es können Abonnenten des Event Hubs eingerichtet werden z.B: Azure Table Storage, Stream Analytics, PowerBI und Azure Machine Learning.


Fazit

Die Sicherheit von APIs ist nicht nur darauf beschränkt, ob ein Konsument der API ein Passwort braucht oder nicht. Es sollten alle Schichten des OSI Models in Betracht gezogen werden, wenn eine sicher API erstellt werden soll. Natürlich ist die Anforderung an die Sicherheit der API von Fall zu Fall unterschiedlich und meist wird der einfachste Weg gesucht, die API so gut wie möglich zu sichern. Hierbei sollte man sich ein API Management genau anschauen, da es mit Policies und Zugriffsbeschränkungen ein umfangreiches Tooling bereitstellt, um APIs zu sichern.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz