API Gateway
Ein Eingang für alle Aufrufe von außen
Die Idee und ihr Nutzen
Die App einer Versicherung zeigt Kunden ihre Verträge und Schäden an. Die Daten dafür liefern mehrere Programme im internen Netz der Versicherung, etwa ein Vertragsdienst und ein Schadendienst. Statt die Adresse jedes dieser Dienste zu kennen, schickt die App alle Anfragen an eine einzige öffentliche Adresse. Unter dieser Adresse nimmt ein vorgeschaltetes Programm die Anfragen an, prüft die Anmeldung, weist zu viele Anfragen ab und leitet jede Anfrage an den zuständigen Dienst weiter. Dieses Programm heißt API Gateway. API steht für Programmierschnittstelle, also die Liste der Anfragen, die ein Programm annimmt, und Gateway heißt Eingangstor.
Wie funktioniert es?
Ein Kunde öffnet in der App seinen Schaden mit der Nummer 4711. Die App ruft api.versicherung.de/schaeden/4711 auf, die öffentliche Adresse des API Gateways, und schickt den Token des Kunden mit. Ein Token ist ein digitaler Nachweis, den der Kunde bei der Anmeldung erhalten hat. Das API Gateway prüft, ob der Token echt und noch gültig ist. Dann zählt das API Gateway die Anfragen des Kunden in der laufenden Minute. Der Kunde hat 12 Anfragen gestellt, erlaubt sind 100, die Anfrage liegt also unter der Grenze. Beim normalen Gebrauch stellt die App für einen Kunden höchstens etwa 30 Anfragen in der Minute; die Grenze von 100 lässt dafür genug Spielraum. Die Grenze verhindert, dass ein fehlerhaftes Programm oder ein Angreifer die Dienste mit Anfragen überschwemmt. Anschließend schlägt das API Gateway in seinen Weiterleitungsregeln nach, welcher interne Dienst zuständig ist. Die passende Regel lautet: Alles, was mit /schaeden/ beginnt, geht an den Schadendienst. Nur über diese Weiterleitung erreicht die Anfrage das interne Netz. Der Schadendienst prüft selbst, ob Schaden 4711 dem angemeldeten Kunden gehört, und gibt die Schadendaten an das API Gateway zurück. Das API Gateway gibt die Antwort an die App weiter, die den Schaden anzeigt. Zuletzt meldet das API Gateway Dauer und Ergebnis der Anfrage an die Betriebsüberwachung, ein Programm, in dem das Betriebsteam für alle Dienste gesammelt sieht, wie lange sie für eine Antwort brauchen und ob Fehler auftreten.
Die Versicherung betreibt ihre Anwendung nicht als ein einziges Programm, sondern als mehrere getrennte Dienste im internen Netz, die verschiedene Teams entwickeln und unabhängig voneinander ändern. Nur das API Gateway hat eine öffentliche Adresse; die internen Dienste sind von außen nicht erreichbar. Zwischen Internet und internem Netz liegt damit eine Sicherheitsgrenze, über die nur geprüfte Anfragen gelangen. Das API Gateway übernimmt nur die Aufgaben, die für alle Anfragen von außen gleich sind. So prüft das API Gateway nur, ob ein Kunde angemeldet ist. Nur der Schadendienst weiß, ob der angefragte Schaden diesem Kunden gehört und der Kunde ihn deshalb sehen darf. Schneller oder zuverlässiger macht das API Gateway die Dienste dahinter nicht; es entscheidet nur, welche Anfragen sie erreichen.
Eine Anfrage mit ungültigem Token weist das API Gateway ab, bevor sie einen internen Dienst erreicht. Ebenso weist das API Gateway weitere Anfragen eines Kunden ab, sobald er mehr als 100 Anfragen in der Minute stellt. Bei Bedarf passt das API Gateway die Antwort eines internen Dienstes an, zum Beispiel wenn sich Feldnamen im Dienst geändert haben, die App aber noch die alten erwartet.
API Gateway: Schaden 4711 über einen Eingang abrufen
Wann ist es sinnvoll und wann nicht?
Ein API Gateway lohnt sich
- Viele interne Dienste sollen nach außen wie eine einzige Anwendung mit einer Adresse auftreten. Ohne API Gateway müssten die App und die Webseite der Versicherung die Adresse jedes Dienstes im internen Netz kennen, und jeder Dienst müsste aus dem Internet erreichbar sein.
- Die internen Dienste ändern sich häufiger als die App. Ohne API Gateway müssten App und Webseite bei jedem Umbau der Dienste geändert und neu ausgeliefert werden. Bei der App dauert das, weil Kunden die neue Version erst installieren müssen. Mit API Gateway ändert die Versicherung nur die Weiterleitungsregeln. Teilt sie den Schadendienst zum Beispiel in einen Meldedienst für neue Schäden und einen Regulierungsdienst für die Bearbeitung auf, gehen Anfragen für bestehende Schäden danach an den Regulierungsdienst. Die App ruft weiterhin dieselbe Adresse auf und erhält dieselbe Antwort.
- Anmeldung, Begrenzung und Protokollierung sollen für alle Anfragen von außen einheitlich gelten. Ohne gemeinsamen Eingang muss jeder Dienst diese Regeln selbst umsetzen. Das führt zu doppelter Arbeit und zu Lücken, wenn in einem Dienst eine Regel fehlt.
Ein API Gateway ist nicht das Richtige
- Das API Gateway soll Berechnungen und Geschäftsregeln übernehmen. Diese baut jedes Team in seinen eigenen Dienst ein. Bei einer fachlichen Änderung ändert das Team dann nur seinen Dienst und muss nicht auf das Team warten, das das API Gateway betreut.
- App und Webseite brauchen sehr unterschiedliche Antworten. Die App zeigt zum Beispiel nur eine kurze Schadenliste, die Webseite alle Einzelheiten. Das API Gateway müsste dann jede Antwort einmal für die App und einmal für die Webseite umbauen, und das Team des API Gateways müsste jede Änderung an App oder Webseite mitmachen. Stattdessen baut das Team der App ein eigenes Backend for Frontend, ein Zwischenprogramm, das die Antworten der Dienste für die App zusammenstellt, und das Team der Webseite baut eines für die Webseite. Jedes Team ändert dann sein Backend for Frontend, ohne auf das Team des API Gateways zu warten. Beide lassen sich auch kombinieren. Dann geht eine Anfrage der App zuerst an das gemeinsame API Gateway, das die Anmeldung prüft und die Anfragen begrenzt, und von dort an das Backend for Frontend der App, das die Antwort aus den Diensten zusammenstellt.
- Die Versicherung betreibt nur eine einzige Anwendung statt mehrerer getrennter Dienste. Dann gibt es nichts, was ein API Gateway auf verschiedene Dienste verteilen könnte, und die Anwendung prüft die Anmeldung der Kunden selbst. Die App schickt ihre Anfragen dann direkt an die Anwendung oder an einen Reverse Proxy, ein Programm, das die Anfragen der Kunden annimmt und unverändert an die Anwendung weiterleitet. Weiterleitungsregeln für viele Dienste und Grenzwerte je Kunde braucht es dann nicht.
Nachteile und typische Fehler
Alle Anfragen von außen laufen durch das API Gateway. Damit ein Ausfall des API Gateways nicht die ganze App lahmlegt, laufen auf mehreren Servern gleichzeitig Exemplare desselben API Gateways. Weil alle Exemplare dieselben Weiterleitungsregeln und Grenzwerte haben, kann jedes Exemplar jede Anfrage annehmen. Das Betriebsteam muss diese Server, die Weiterleitungsregeln und die Grenzwerte pflegen. Jede Anfrage durchläuft einen zusätzlichen Schritt im Netz und dauert dadurch etwas länger. Tragen viele Teams ihre Weiterleitungsregeln in dasselbe API Gateway ein, warten sie aufeinander. Das Team des Schadendienstes will zum Beispiel eine neue Regel einspielen und muss warten, bis die Änderung des Teams des Vertragsdienstes geprüft und ausgeliefert ist. Legt eine fehlerhafte Regel des Teams des Vertragsdienstes das API Gateway lahm, scheitern auch alle Anfragen an den Schadendienst, obwohl am Schadendienst nichts geändert wurde. Deshalb legt das Betriebsteam fest, welches Team welche Weiterleitungsregel ändern darf.
Typische Fehler und woran man sie erkennt:
- Prüfung nur im API Gateway: Der Schadendienst verlässt sich allein auf das API Gateway und prüft nicht mehr, ob ein Schaden dem angemeldeten Kunden gehört. Ein angemeldeter Kunde ändert in der Adresse die Schadennummer, etwa von 4711 auf 4712. Das API Gateway prüft nur den Token des Kunden und leitet die Anfrage an den Schadendienst weiter. Der Schadendienst liefert dann die Daten des fremden Schadens 4712 aus. Erkennbar ist das an Abrufen von Schäden, deren Kundennummer nicht zum Token passt.
- API Gateway ohne Ersatz: Das API Gateway läuft nur auf einem Server. Fällt dieser Server aus, ist die ganze App nicht erreichbar, obwohl Schadendienst und Vertragsdienst laufen. Erkennbar ist das an Fehlermeldungen aller App-Funktionen zur selben Zeit, während die Dienste selbst keine Fehler melden.
- Umgangener Eingang: Ein interner Dienst ist versehentlich zusätzlich direkt aus dem Internet erreichbar. Ein Angreifer schickt seine Anfragen direkt an diesen Dienst statt an das API Gateway. Die Anfragen erreichen den Dienst dann ohne Prüfung des Tokens und ohne Begrenzung. Erkennbar ist das an Anfragen in den Protokollen des Dienstes, die nicht vom API Gateway stammen.
- Zu knappe Grenze: Die Grenze für Anfragen je Minute ist niedriger als der normale Bedarf der App. Kunden erhalten Abweisungen, obwohl sie die App ganz normal nutzen. Erkennbar ist das an vielen abgewiesenen Anfragen zu Zeiten ohne Angriff oder Fehlfunktion.
Weiterführend
Verwandte Ansätze
- Rate Limiting und Token Based Authentication: erklären die Begrenzung von Anfragen und die Anmeldung mit Token, die ein API Gateway häufig übernimmt.
- Service Mesh: regelt die Aufrufe zwischen den internen Diensten, während das API Gateway die Anfragen von außen annimmt.
Werkzeuge und Umsetzungen
- Apache APISIX: API Gateway mit Erweiterungen für Anmeldung, Begrenzung und Protokollierung. Regeln lassen sich im laufenden Betrieb ändern.
- Envoy Gateway: API Gateway für Kubernetes, eine verbreitete Plattform zum Betrieb von Anwendungen auf vielen Servern. Envoy Gateway baut auf Envoy auf, einem Programm, das Verbindungen stellvertretend annimmt und weiterleitet.
- KrakenD: API Gateway, das zusätzlich Antworten mehrerer Dienste zu einer Antwort zusammenführen kann. Die Community Edition ist Open Source; einige Funktionen gibt es nur in der kostenpflichtigen Ausgabe.
- Spring Cloud Gateway: API Gateway für Java-Anwendungen, das sich mit eigenem Java-Code erweitern lässt.
- Tyk: API Gateway, dessen Grundprogramm als Open Source angeboten wird. Verwaltungsoberfläche und weitere Bausteine sind kostenpflichtig.
Quellen
- Chris Richardson: Pattern: API Gateway / Backends for Frontends: beschreibt das API Gateway als einzigen Eingang für alle aufrufenden Programme und das Weiterleiten und Zusammenführen von Anfragen. Als Nachteile nennt der Beitrag, dass ein weiterer Baustein entwickelt, ausgeliefert und betrieben werden muss, und die längere Antwortzeit.
- Microsoft: Use API gateways in microservices: erläutert Weiterleitung, Zusammenführung und die Übernahme gemeinsamer Aufgaben wie Anmeldung, Begrenzung und Protokollierung durch das API Gateway.