Nichts Passendes dabei? Stellen Sie ein, welche Inhalte Sie auf aleri.de sehen möchten:
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.
Typische Werkzeuge im Bereich API-Management sind:
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:
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.
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:
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:
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.
Die Auswahl eines geeigneten Produktes ist eng mit den Anforderungen und den vorhandenen Möglichkeiten im Unternehmen verbunden:
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).
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.
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.
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.
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.
Ob API-Economy, API-Governance, API-Management oder API-Design.
Unser Technology Lead API & Services steht Ihnen gerne Rede und Antwort.
Wir freuen uns über Ihre Nachricht und melden uns schnellstmöglich bei Ihnen.