API-Management

Im Kontext der API-Economy deckt das API-Management den Bereich der Verwaltung ab. In Ergänzung zu den strategischen Entscheidungen der API-Governance beschäftigt sich API-Management primär mit operativen Aspekten der API-Economy.
In diesen Bereich fallen neben dem API-Lifecycle-Management auch betriebliche Themen wie Monitoring, welches die Grundlage für die Analysen der API-Governance bildet.

Fein-granulares Routing sowie Traffic Control basieren auf Policies und dienen einer stabilen, abgesicherten Bereitstellung der eigenen APIs. Sie bilden das Fundament für die Monetarisierung der Nutzung durch Dritte.
Auch die Absicherung und Zugriffskontrolle fällt in den Bereich des API-Managements bzw. ist integraler Bestandteil der meisten Software-Lösungen.

Aufbau einer API-Management-Lösung

Typische Werkzeuge im Bereich API-Management sind:

  • das API-Admin-UI zur Registrierung und Provisionierung von APIs sowie der Performance-Analyse
  • das API-Developer-Portal für Consumer-Developer-Registrierung, Collaboration und Sandbox-Testing
  • der bzw. die API-Gateway(s) zur Vermittlung und Steuerung des Zugriffs auf die API-Provider durch Consumer

Management-Portal

Das Management-Portal (auch Publisher oder Admin Portal genannt) ist der administrative Baustein einer API-Management-Lösung. Im Management-Portal werden die verfügbaren APIs initial definiert, üblicherweise durch Abruf oder Upload der Spezifikation im Swagger/OpenAPI oder WSDL-Format. In der Regel können weitere Informationen, die durch keinen der Standards abgedeckt werden, hinzugefügt werden (z. B. Business Owner, technischer Kontakt, etc.).

Die so gewonnene bzw. generierte Spezifikation wird – neben weiteren Informationen – den anderen Komponenten der API-Management-Lösung zur Konfiguration zur Verfügung gestellt:

  • Technische und fachliche Dokumentation sowie die verfügbaren Abonnement-Möglichkeiten (Subscriptions) werden an das Developer Portal (den Store) weitergereicht und erlauben dort der Erforschung und Buchung der Services
  • Einstellungen zu Routing, Traffic Control und Umgebungen werden an die konfigurierten API-Gateways weitergeleitet und dort zur Einrichtung des Zugangs bzw. der Request-Behandlung verwendet. Das API-Gateway wird außerdem im Rahmen seiner Möglichkeiten die erwarteten KPIs berichten.

Developer-Portal

Das Developer-Portal ist der erste Anlaufpunkt für die Entwickler von Portalen und mobilen Anwendungen, die auf einen oder mehrere Services zugreifen möchten. Im Developer-Portal finden sich die Schnittstellenbeschreibungen der verfügbaren Services mit fachlichen und technischen Details.

Da diese API-Spezifikationen immer häufiger aus Swagger- oder OpenAPI-Dokumenten erstellt werden, bieten Developer-Portale oftmals auch direkte Test-Möglichkeiten, d.h. der Zugriff auf einen Service in Produktion oder einer Testumgebung kann über das Portal durchgeführt werden.

Darüber hinaus kann hier die Nutzung von Services angemeldet bzw. (kostenpflichtig) gebucht werden. Dazu stehen die im Rahmen der API-Governance erarbeiteten Preis- und Abrechnungsmodelle als Pakete oder Abonnements zur Verfügung. Registrierte Anwendungen erhalten eine sog. Consumer ID, die in allen eingehenden Anfragen eines Consumer enthalten sein muss. Bei der Consumer ID handelt es sich üblicherweise um einen einfachen, statischen Text in den Metadaten (Header) einer Anfrage oder um ein Sicherheits-Token nach OAuth2 bzw. OpenID Connect. Da die Consumer ID im einfachsten Falle in Klarschrift übertragen wird, ist der Einsatz von Transportverschlüsselung (TLS) zwingend erforderlich.

API-Gateway

Der API Gateway ist die Routing-Komponente einer API-Management Lösung. Nach Art eines Proxys oder eines Adapters stellt das API-Gateway Verbindungen zwischen den nutzenden Anwendungen (Consumer) und den Services dar. Im einfachsten Falle handelt es sich dabei tatsächlich um einen Proxy, welcher eingehende Verbindungen auf eine oder mehrere Service-Instanzen verteilt (Routing und Load-Balancing). Oftmals bieten die Produkte allerdings noch weitere Funktionen:

  • Access Control:
    Consumer-Anwendungen wie Portale oder Mobile Apps können sich für die Nutzung der (kostenpflichtigen) Services registrieren (s. a. Developer-Portal). Dabei erhalten sie ein Identifizierungsmerkmal, üblicherweise einene API-Key oder die sog. Consumer ID und ein Consumer Secret. Ein API-Gateway prüft bei Aufruf entsprechender Services die Präsenz und Gültigkeit dieser Kennung und weist fehlerhafte Anfragen ab.
  • Traffic Shaping:
    Basierend auf konfigurierbaren Regeln findet eine erweiterte Kontrolle eingehender Verbindungen statt. Dabei kann es sich um eine Begrenzung der Zugriffe auf Services handeln, um einer Überlastung des Backends entgegenzuwirken. Auch ist eine Begrenzung je Consumer denkbar, wobei diese auf der Buchung entsprechender Pakete (Pre-Paid oder On-Demand) basieren kann.

Produkte und Anbieter

In seinen “Magic Quadrant for Full Life Cycle API-Management” führt Gartner regelmäßig über 20 Anbieter für API-Management-Lösungen auf. Dabei lassen sich die Anbieter von API-Management-Produkten grob in drei Kategorien unterteilen:

  • Cloud bzw. “as-a-Service”-Anbieter, deren das Geschäftsmodell das Bevorraten einer API-Management-Lösung notwendig macht;
  • Hersteller von Enterprise-Produkten, die Lösungen zum API-Management als Ergänzung ihres Portfolios anbieten, um ihre bestehenden Produkte (in der Regel Application-Server, Datenbanken oder Enterprise-Service-Bus) in neue Märkte einzubringen;
  • Hersteller dedizierter Lösungen, die API-Management als Kernprodukt anbieten und rund um dieses Produkt weitere Lösungen oder Services anbieten.

In die Kategorie “Cloud-Anbieter” fallen ohne Zweifel Amazon und Google mit ihren Offerten AWS und GCE. Beide bieten eine “hausgemachte” Lösung an, die auf Eigenentwicklungen oder bewährten (Open-Source-) Komponenten aufbaut. In der Regel handelt es sich dabei um die API-Gateway-Komponente nebst notwendigem Management-Portal. Ein Developer-Portal hingegen ist üblicherweise nicht anzufinden.

Die Anzahl der Anbieter dedizierter Lösungen hingegen ist überschaubar. Stellvertretend sei hier die Firma Kong Inc. zu nennen, die sich zunächst als Mashape Inc. firmierte und sich dann entsprechend ihres einzigen Produktes (Kong API Gateway) umbenannt hat. Kong Inc. bietet die API-Gateway-Komponente Kong als Open-Source (Community Edition) kostenlos an . Weiterführende Module wie Management- und Developer-Portal hingegen sind nur als Teil der kostenpflichtigen Enterprise Edition erhältlich, wobei die Nutzung eines Service-Angebots oder die Installation im eigenen Rechenzentrum möglich ist.

Produktauswahl

Die Auswahl eines geeigneten Produktes ist eng mit den Anforderungen und den vorhandenen Möglichkeiten im Unternehmen verbunden:

  • Nutzer bereits bestehender Software-Suiten im Bereich Enterprise Middleware haben eventuell die Möglichkeit, API-Management über entsprechende Add-Ons zu realisieren.
  • Alternativ kann dedizierte (“standalone”) Software eingesetzt werden, wenn diese dokumentierte Schnittstellen für die Integration in die bestehende Software-Landschaft bietet
  • Cloud-Angebote beinhalten oftmals eigene Lösungen für API-Management, wobei nur wenige davon auf etablierten Produkten, sondern in der Regel auf Eigenentwicklungen basieren.

Doch diese Infrastrukturfragen bzw. -einschränkungen sollten nicht im Vordergrund stehen. Vielmehr müssen das ausgewählte Produkt bzw. die betrachtete “as-a-Service”-Lösung den ermittelten Anforderungen genügen. Aspekte wie Dimensionierung, Verfügbarkeit und Wartbarkeit und auch mögliche Migrationspfade sind hier zu evaluieren und im Kontext der eigenen Anforderungen zu betrachten.

Ein guter Einstieg in die Erfassung und Bewertung von Anforderungen und deren Erfüllung liefert wieder Gartner Inc. in seinem Bericht “A Guidance Framework for Evaluating API-Management Solutions” (Gartner Inc., 2017).

Magic Quadrant for Full Life Cycle API-Management (Gartner Inc., 2018)

Magic Quadrant for Full Life Cycle API-Management (Gartner Inc., 2018)

API-Lifecycle-Management

Wie alle Artefakte in der IT sind auch Services und deren APIs häufigen Änderungen unterworfen. Gleichzeitig sind die Entwicklungszyklen der Services und der nutzenden Anwendungen (Consumer) nicht synchron, insbesondere wenn Services und Consumer nicht intern bzw. vom gleichen Anbieter stammen. Ein schlüssiges Versionierungsschema und die Etablierung eines API-Lifecycle Managements sind daher unabdingbar.

Die einzelnen Schritte des Lifecycle-Managements unterscheiden sich je nach Anbieter, insbesondere wen API-Management als “Add-On” zu einer bestehenden Lifecycle-Management-Lösung angeboten wird. Über diverse Beschreibungen und Produkte hinweg, lässt allerdings folgender Minimalkonsens ableiten:

Created
Die ist der initiale Stand einer API, d.h. die Schnittstelle ist formell beschrieben und ausreichend dokumentiert. Service Provider und Consumer Developer können basierend auf dieser Beschreibung mit der Entwicklung ihrer Implementierung beginnen. Eine geeignete API-Management-Lösung kann unter Umständen einen statischen Prototyp zur Verfügung stellen, um das Testen zu erleichtern.

Um diese Phase des Lebenszyklus abzuschließen, sollten spezifische Quality Gates erfüllt werden, die sich meist aus Entwicklungsrichtlinien zusammensetzen. Optimalerweise erfolgt die Überprüfung automatisiert.

Published
Die Service-Implementierung steht bereit und kann über das API-Gateway unter Verwendung der API angesprochen werden. Dabei garantiert ein Versionierungsschema den Parallelbetrieb mehrerer Versionen, um existierenden Consumern eine sanfte Migration zu ermöglichen.

Deprecated
Die API betritt die letzte Phase ihres Lebenszyklus und ist zur Ablösung vorgesehen. Der Betrieb der betroffenen API bzw. der betroffenen Version wird aufrechterhalten, aber neuen Registrierungen für die Nutzung (“Subscription”) werden nicht mehr angenommen. Consumer erhalten bei Aufruf der API einen Hinweis (z. B. als HTTP Header) auf das bevorstehende Betriebsende.

Retired
Die API bzw. API-Version wird nicht mehr durch eine entsprechende Service-Implementierung bedient, ein Abruf von Daten ist nicht mehr möglich. Optional ist die Schnittstelle weiterhin aufrufbar und antwortet mit einem Hinweis auf einen evtl. Nachfolger.

Datenschutz

Die Einhaltung des Datenschutzes ist kein Thema, mit welchem sich die API-Economy primär beschäftigt. Allerdings kommt es in vielen Bereichen zu einer Beeinflussung durch gesetzliche Vorgaben, firmeneigene Compliance-Regeln und allgemeine Erwartungen. Die meisten dieser Bereiche haben eine Beziehung zu operativen Tätigkeiten und sind daher im Bereich API-Management zu finden.

Besonders der Verarbeitung personenbezogener Daten ist hier besonderes Augenmerk zu schenken. Diese fallen z. B. im Bereich Consumer- und Provider-Verwaltung an, wenn (fachliche bzw. technische) Ansprechpartner im Management- oder Developer Portal veröffentlicht werden. Die Verwendung von Gruppenpostfächern statt dedizierter Personen kann hier Konflikten vorbeugen (und ist tatsächlich auch aus Gründen der geteilten Verantwortung empfehlenswert).

Deutlich umfangreicher sind die Vorbereitungen im Bereich API-Gateway(s): Als Proxy-Komponente gehen jede Anfrage und jede Antwort durch das Gateway. Eine eventuell vorhandene Transport-Verschlüsselung wird vor dem Gateway terminiert, um Authentifizierungsdaten zu prüfen und den API-Key zu verifizieren. Somit besteht an dieser Stelle vollständiger Zugriff auf die Meta-Informationen und - sofern keine dedizierte Verschlüsselung des Inhalts zum Einsatz kommt - auch auf die Nutzdaten.

Selbst wenn an dieser Stelle keine Bösartigkeit unterstellt werden soll: das (oder die) API-Gateways sind ideale Stellen für Man-in-the-middle-Attacken. Ihre Installationen müssen besonders abgesichert und regelmäßig einem Audit unterzogen werden.

Abseits bewusster Datenschutzverletzungen durch Angriffe kann es zu unwillentlicher Veröffentlichung durch Protokollierung und Monitoring kommen: Bereits ein einfaches Zugriffsprotokoll (access.log) nach Common Log Format (CNF) enthält relevante Informationen wie IP-Adresse und Benutzername und kann problemlos um weitere Meta- und Nutzdaten erweitert werden. Die Konfiguration des Gateways ist daher im Vorfeld zu prüfen und ggfs. anzupassen. Dies gilt besonders (aber nicht ausschließlich) bei der Nutzung eines Cloud-Angebots. Hier ist ggfs. die Datenverarbeitung auf Regionen zu beschränken, die sich im eigenen Rechtsraum befinden. Bei as-a-Service Angeboten sind die AGB und SLAs entsprechend zu prüfen.

Security

Mittels Bedrohungsmodellierung (Threat Modelling) lassen sich mögliche Bedrohungen identifizieren und bewerten. Dazu müssen zunächst alle zu schützenden Ressourcen der IT-Landschaft und alle damit verbundenen Data Flows identifiziert werden. Im Anschluss werden alle möglichen Bedrohungen und entsprechende Angriffe gelistet.

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Escalation of Privileges) ist eine beliebte Technik, um Bedrohungen für ein System methodisch zu identifizieren. Das Ergebnis des Threat Modelling ist eine Liste möglicher Attacken, die sich zum spezifischen Monitoring eines Systems eignet, aber auch zum Erstellen einer Test-Matrix z. B. für Penetrationstests.

Verfügbarkeit

Eine Anforderung an das IT-System, insbesondere bei öffentlichen APIs, sollte eine hohe Verfügbarkeit sein. In dem Zusammenhang ist die Ermittlung oder Verhinderung von DDoS-Angriffen (Distributed Denial of Service) eine schwierige Herausforderung, die ein sorgfältiges Monitoring und das Definieren von Schwellwerten erfordert. Ein Ratenlimit für jeden API-Aufruf in einem definierten Zeitfenster liefert dabei eine gängige Lösung, jedoch wird dadurch die Skalierbarkeit des Systems beeinträchtigt. Die Schwellenwerte der Ratenlimitierung sollten einerseits von der CPU- und Memory-Last durch die Services abhängen und anderseits den Erfahrungen aus bisherigen Monitoring-Ergebnissen entsprechen.

Sie haben Fragen zum Thema API?

Ob API-Economy, API-Governance, API-Management oder API-Design.
Unser Technology Lead API & Services steht Ihnen gerne Rede und Antwort.

Christoph Dahlen, Aleri Solutions

Christoph Dahlen

Technology Lead: API & Serviceschristoph.dahlen@aleri.de

Nutzen Sie auch gerne unser Kontaktformular

Wir freuen uns über Ihre Nachricht und melden uns schnellstmöglich bei Ihnen.

Dieses Feld ist Pflicht.
*Pflichtangaben