Der WSO2 API Manager kann verwirrend sein. In der Tat ist es ein großartiges Produkt, das Funktionen vieler anderer Produkte weiterverwendet – wie z.B. den Enterprise Service Bus, den Complex Event Processor, den Message Broker, den Enterprise Store und den Data Analytics Server (der an sich eine Reihe von Produkten ist). Es deckt sehr viel ab – wie z.B. Lifecycle Management, Policy Management, Engagement von Entwicklern und Durchsetzung von Richtlinien. Und alles in einem einzigen Produkt. Kein Wunder, dass es Architekten und Administratoren schwer fällt, sich damit zurechtzufinden. In diesem Beitrag werden wir versuchen, dem Ganzen einen Sinn zu geben.
Richtlinie 101
Lass uns mit deinem Endziel beginnen. Du willst deine Richtlinien durchsetzen. Egal, ob es um den Zugriff auf deine Daten geht, um die Raten, mit denen deine APIs aufgerufen werden dürfen, oder um die Authentifizierung, ohne ordnungsgemäße Durchsetzung sind deine Richtlinien grundlegend fehlerhaft. Willst du dir das Leben einfach machen, schaffst du einen einzigen Zugangspunkt, an dem du deine Richtlinien durchsetzen kannst. Das ist dein Policy Enforcement Point, auch bekannt als PEP. Es ist durchaus möglich, dass du mehr Zugänge hast, aber bedenke, dass du nicht in einer guten Position bist, wenn du deine Front Door sicherst, während du deine Back Door weit offen lässt. Du kannst dir deinen Policy Enforcement Point als die Schranke am Border Gate vorstellen.
Wenn du deine Richtlinien durchgesetzt hast, stellt sich die Frage, wie du die Einhaltung gewährleisten kannst. Auch hier brauchst du an der Grenze eine legale Erlaubnis. Vielleicht ist es gar nicht so schwierig, festzustellen, ob eine Person eine Genehmigung hat oder nicht. Aber ist das legal oder gefälscht? Ist sie immer noch gültig, oder vielleicht widerrufen? Ist diese Person wirklich der Inhaber der Genehmigung? Ist sie vielleicht eingetragen? Bei der Entscheidung, ob deine Richtlinie – der Besitz einer legalen Genehmigung – verletzt wird oder nicht, kann es alle möglichen Komplikationen geben. An dieser Stelle kommt ein Policy Decision Point (PDP) ins Spiel.
Natürlich müssen politische Entscheidungen fair und so objektiv wie möglich sein. Du willst nicht, dass jeder deiner Zöllner seine eigenen Regeln aufstellt. Um deine Richtlinien unmissverständlich festzulegen, solltest du einen Policy Administration Point (PAP) einrichten. Dies ist die Quelle, auf die sich dein PDP verlassen wird. Beachte, dass Policy-Administration und Policy-Durchsetzung unterschiedliche Aufgaben sind. Die Entwicklung und das Testen einer Richtlinie oder die Änderung einer Richtlinie kann Monate dauern. Normalerweise veröffentlichst du Updates der Richtlinien einmal pro Woche oder einmal im Monat. Die Durchsetzung von Richtlinien ist jedoch ein 24×7-Betrieb, bei dem Entscheidungen schnell getroffen werden müssen und Wartezeiten vermieden werden müssen.
Um eine Brücke zwischen den Welten der Policy-Operationen und der Policy-Entwicklung zu bauen, solltest du wahrscheinlich ein situatives Bewusstsein schaffen. Wie funktioniert deine Politik? Brauchst du eine gewisse Verfeinerung? Oder möchtest du vielleicht die Auswirkungen geplanter Änderungen der Richtlinien simulieren und bewerten? Dafür und für viele andere Dinge benötigst du Informationen über deinen Betrieb. Das sind deine Policy Information Point (PIP). Dort kannst du alle getroffenen Entscheidungen verfolgen und beurteilen, ob deine Richtlinien wie geplant funktionieren. Auf diese Weise schließt du deinen Richtlinien-Kreislauf.
API-Richtlinien
Also, wie funktioniert diese Verknüpfung zum WSO2 API Manager. Nun, du wirst nicht überrascht sein, wenn du erfährst, dass das API-Gateway in Wirklichkeit dein PEP ist. Es ist die Schnittstelle, die entweder den Zugang erlaubt oder nicht. Dieses Gateway kommt mit zwei Assistenten, die bei der Entscheidung über die Durchsetzung der Richtlinien helfen: der Key Manager – der die Aufgabe hat, über deine Zugangskontrollrichtlinien zu entscheiden – und der Traffic Manager – um deine Richtlinien zur Drosselung zu operationalisieren. Dies sind deine PDPs. Wie WSO2 die Schnittstellen zu diesen Komponenten implementiert hat, ist ein bisschen anders. Das Key Manager Interface ist ein Echtzeit-Interface, mit einem optionalen Cache, um die Gesamtleistung zu optimieren. Der Traffic-Manager hingegen hat ein nahezu echtzeitfähiges Interface. Es wird ständig mit Events gefüttert, und überwacht kontinuierlich den API-Verkehr und wertet aus, wenn Richtlinien verletzt werden – was komplexe Abfragen in großen Mengen von Events beinhalten kann. Wenn eine Verletzung auftritt, bedeutet das, dass das Gateway so schnell wie möglich seinen Betriebsregelsatz aktualisieren muss – den Satz einfacher Regeln, den es in Echtzeit auswertet – z.B. eine IP-Blacklist. Also sendet der Traffic-Manager eine Nachricht an das Gateway, um genau dies zu tun. Du kannst dir vorstellen, dass der Traffic-Manager mit diesem einfachen Regelwerk die Echtzeit-Entscheidungen an das Gateway delegiert, ähnlich wie die Polizei eine Liste der gestohlenen Passnummern mit dem Zoll teilt.
Warum Brauchen Sie Überhaupt Ein API-Management?
Jetzt herunterladenDas API Veröffentlichungs- und Verwaltungsportal ist offensichtlich ein PAP. Schließlich definierst du hier deine API-Richtlinien. Und in gewisser Weise ist das API Developer Portal auch ein PAP – das ist der Ort, an dem ein Entwickler gültige Apps definiert und seine Abonnements verwaltet. Abhängig von den Workflows, die du definierst, können verschiedene Rollen daran beteiligt sein, zu entscheiden, welche Entwickler-Registrierungen und welche API-Abonnements akzeptiert werden. Tatsächlich sind deine Workflows auch ein PDP.
Der API Manager Analytics dient als PIP im WSO2 API Manager. Hier findest du alle Berichte, die der API Manager out-of-the-box generiert. Wenn du mehr als das möchtest, gibt es immer die Möglichkeit, auf einen vollständigen WSO2 Data Analytics Server zu aktualisieren.
Take away
Zu wissen, welche Funktionen die verschiedenen Komponenten des WSO2-API-Managers tatsächlich spielen, kann dir bei der Entscheidung über deine Einsatzstrategie helfen. Vielleicht entscheidest du dich dafür, sie alle zusammen in deiner Entwicklungsumgebung zu verwenden, während du in deiner Produktionsumgebung die Design- und die Laufzeitkomponenten trennen kannst. Du kannst dich auch dafür entscheiden, dein Gateway in einem von deinem Key Manager und Traffic Manager getrennten Netzwerkbereich einzusetzen. In solch einem Setup kann das Gateway ohne eine Verbindung zu deinen gemeinsamen Datenbanken laufen. Anders gesagt, du kannst deine Daten sicher hinter deiner Firewall schützen. Natürlich musst du dafür sorgen, dass deine Proxies und Firewalls korrekt eingerichtet sind, damit die Verbindung zwischen den Komponenten jederzeit gewährleistet ist.
Zusammenfassend lässt sich sagen, dass es viele Optionen zu bedenken gibt, und es wird wahrscheinlich einige Überlegungen erfordern, wie du deine API-Manager-Komponenten am besten in deine Gesamtumgebung einbaust – in voller Übereinstimmung mit deinen Netzwerk- und Sicherheitsprinzipien. Und wir haben noch nicht einmal angefangen, ein Szenario mit mehreren Gateways zu diskutieren – verschiedene API-Gateways in verschiedenen Rechenzentren oder verschiedenen Netzwerkzonen zu betreiben – zum Beispiel, um internen und externen Datenverkehr zu trennen. Die Einsatzmöglichkeiten sind buchstäblich endlos. Zum Glück für dich ist Yenlo da, um deine Optionen zu präsentieren und dir bei der Auswahl deines besten Szenarios zu helfen – und am besten vielleicht auch, um seine Realisierbarkeit zu beweisen (was in der Praxis selten trivial ist). Immerhin haben wir das schon einmal gemacht. Und wir freuen uns immer darauf, einen API-Architektur-Workshop zu veranstalten, um deine Herausforderungen zu bewältigen oder anderweitig behilflich zu sein.
Möchtest du wissen, welches API-Produkt zu deinen geschäftlichen Bedürfnissen passt? Die Antwort findest du in unserem White Paper unten, in dem wir verschiedene API-Anbieter und ihre Produkteigenschaften vergleichen.
