eBizTalk - Berichten, Unterhalten, Weiterbilden

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.

Dies ist der dritte Artikel über API Management in großen Unternehmen. Ziel der Reihe ist, Einblick in die vielen Aspekte und Themen zu gewähren, mit denen sich eine größere Firma mit besonderen Anforderungen auseinandersetzt. In diesem Artikel werde ich auf den Lebenszyklus von APIs eingehen.

Lebenszyklus von APIs

Häufig spricht man, wenn über den Lebenszyklus von APIs gesprochen wird, auch über den Prozess der API-Entwicklung. Beides ist sehr eng miteinander verknüpft. Generell spricht man meist von Aktivitäten, die in eine der vier Hauptphasen fallen: Entwickeln, Veröffentlichen, Verwalten und Entfernen. Jeder dieser Schritte kann beliebig tief detailliert werden.

Entwicklung beinhaltet Aspekte wie Technologie, Sicherheit, Provisionierung und Deployment-Automatisierung. Ebenfalls zu betrachten ist, und das wird häufig vernachlässigt, die Dokumentation der API oder auch das Testen im weiteren Sinne (eg: Mock, Load- und Penetration Test). Entwickler-, Design-, und Strategieleitfäden gehören hier ebenfalls dazu.

Veröffentlichen umfasst nicht allein die Aktion, eine API bereitzustellen. Hier könnte man auch in Betracht ziehen, eine API öffentlich oder intern zu monetarisieren, um eine neue Einkommensquelle für die Firma zu schaffen. In den meisten Fällen, wenn eine API wiederverwendbar zur Nutzung angeboten wird, ergibt sich das Problem wie die Kosten die Services gedeckt oder aufgeteilt werden sollen. Interne Monetarisierung, also die nutzungsbasierte Bezahlung, wäre hierfür eine saubere Lösung wenn die Dimensionen, wie Anzahl der APIs, Verursachte Last, Anzahl der Operationen, und viele mehr, dabei beachtet werden.

Analysieren der Verwendung von APIs ist ein wichtiger Teil des Lebenszyklus, der nicht zu unterschätzen ist. Mit Statistiken zu vielen verschiedenen Metriken, wie Latenzen, Peak-Zeiten, Requesthäufigkeit und ähnlichem können die Services optimiert, angepasst und Probleme schnell behoben werden.

Entfernen von APIs ist häufiger nötig als man denkt. Das liegt daran, dass sich die Services meist weiterentwickelt haben und die veraltete Version nicht mehr verwendet wird. Es ist daher angebracht, auch hierfür einen sauberen Prozess anzulegen, der möglichst automatisch angestoßen wird, um die API-Landschaft sauber zu halten (bspw. Einen Alarmsetzen, der Benachrichtigt, wenn APIs länger als drei Monate nicht verwendet werden).

Abbildung 1 - API Lebenszyklus

Weitere Aspekte der einzelnen Phasen

Entwicklung

1. Entwicklung: Sobald eine solide Strategie und einen solider Plan verfügbar ist, kann die API erstellt werden.

2. Testen: Vor der Veröffentlichung ist es wichtig, API-Tests abzuschließen, um sicherzustellen, dass sie die Leistungs-, Funktionalitäts- und Sicherheitserwartungen erfüllen.

3. Sicherung: Sicherheitsrisiken und -bedenken sind heute ein häufiges Problem. Auf technischer Ebene kann API Management Tooling behilflich sein. Jedoch auch auf Prozessebene muss die Sicherheit sichergestellt werden. Beispielsweise durch Verwendung von sauber implementierten Dev-Ops Prozessen.

Veröffentlichen

1. Veröffentlichen: Nach dem Testen ist es an der Zeit, die API zu veröffentlichen, um für Entwickler verfügbar zu werden. Das Developer Portal stellt diese dann zur Verfügung.

2. Vermarktung: Es gibt mehrere Möglichkeiten, Ihre API zu vermarkten, einschließlich der Auflistung in einem API-Marktplatz wie RapidAPI. Das Developer Portal kann als firmeneigenes Portal dienen.

3. Monetarisieren: Es besteht die Wahl APIs kostenlos intern oder extern anzubieten. Wenn es eine Gelegenheit dafür gibt, können APIs auch monetarisiert und so zusätzliche Einnahmen für das Unternehmen erzielt werden.

4. Onboarding: Wenn APIs für den öffentlichen oder privaten Verbrauch angeboten werden, ist Onboarding eine wichtige Komponente, damit Entwickler die wichtigsten Funktionen verstehen. Eine gute Dokumentation ist hierfür ausschlaggebend. Wie eine solche auszusehen hat sollte firmenweit definiert sein.

Verwalten

1. Verwalten: Nach der Veröffentlichung müssen Entwickler die APIs auch verwalten, um sicherzustellen, dass sie auf dem neuesten Stand sind und die Integrität Ihrer APIs nicht beeinträchtigt wird.

2. Analysieren: Ihre APIs sind live, aber wie funktionieren sie? API-Trafik Analyse hilft Ihnen, Ihr digitales Geschäft zu verstehen und Anomalien zu erfassen, bevor sie sich auf Ihr Unternehmen auswirken.

Ruhestand

1. Ruhestand: Der Ruhestand von APIs ist die letzte Phase eines API-Lebenszyklus und geschieht aus einer Vielzahl von Gründen, einschließlich Technologieänderungen und Sicherheitsbedenken.

Eine Strategie ist ausschlaggebend für ein erfolgreiches Lifecycle Management

Bereits im vorherigen Teil der Blog-Serie habe ich bekräftigt, dass APIs nicht nur als Mittel zum Zweck gesehen werden sollen, sondern auch in die Unternehmensstrategie einfließen können.

Wenn man den Lebenszyklus betrachtet sieht man, dass an vielen Stellen eine Unternehmensstrategie angeraten ist, um sicher und einheitlich APIs zu veröffentlichen und zu verwenden. Eine Strategie sollte demnach aus mehreren Blickwinkeln betrachtet werden. Entwicklungs-Vorschriften, Sicherheitsanforderungen, Kostenverteilungsplan, Minimum service lifetime Versprechen, und vieles mehr. Die Wiederverwendung von bestehenden APIs muss politisch motiviert werden, da sonst die Entstehung von Insellösungen nicht verhindert wird und „Digitale Schulden“ entstehen. Digitale Schulden sind Kosten, die an einem späteren Zeitpunkt anfallen, wenn Fehlentscheidungen und falsche Verwendung von Lösungen nachträglich korrigiert werden müssen.

Fazit

Der Lebenszyklus von APIs unterscheidet sich wenig vom Lebenszyklus anderer Lösungen. Es ist auf Grund ihrer Schnittstellenfunktion ungemein wichtig, diesen klar definiert zu haben. Eine API Strategie ist hier eine Voraussetzung dafür da viele Aspekte unternehmensweit relevant sind.

In diesem Artikel gehe ich auf eine häufig verwendete (ich möchte sagen „Vorurteil“) Rolle von APIs (Application Programming Interface bzw. Anwendungsschnittstelle) ein, in der sie als reine Middleware deklariert werden. Ich erkläre, dass APIs als Produkte behandelt werden sollten und was die daraus resultierenden Vorteile sind. Dieser Artikel gehört zu einer Reihe von Artikeln über API Management in Enterprise Organisationen. Ziel der Reihe, ist meine Sicht auf API Management zu geben, wie es im Enterprise-Kontext eingesetzt werden kann.

API-Lösungen und API-Produkte

Es gibt zwei Arten von APIs, API-Lösungen und API-Produkte.

Eine API-Lösung besteht aus einer oder mehreren APIs, die ein Integrationsproblem lösen. Genauer gesagt werden API-Lösungen eingesetzt, um direkte Kommunikation zwischen Computersystemen zu ermöglichen. Ein Beispiel hierfür könnte eine Situation sein, in der Kundendaten in mehreren Geschäftsbereichen, oder auch Silos, ausgetauscht werden müssen.

Ein API-Produkt besteht ebenfalls aus einer oder mehreren APIs, die jedoch eine Schnittstelle zu einem Wertversprechen bereitstellen. Mit anderen Worten, ein API-Produkt besteht aus Value Proposition-Schnittstellen. Um das obere Beispiel weiterzuführen, könnte ein API-Produkt unternehmensglobale Kundendaten zur Verfügung stellen, damit diese intern verwendet werden können.

API-Produkte sind mehr als Middleware

API-Lösungen sind also APIs die speziell für einen einzelnen Integrationsfall erstellt wurden. In diesem Fall erfüllen sie die Definition als Middleware, sie vermitteln zwischen Programmen um die Komplexität dieser zu verbergen. Viele Legacy-Architekturen auf diese Weise gewachsen. Aber APIs als reine Integrationstechnologie zu betrachten wäre ein Fehler, da der größte Teil des Mehrwertes, den APIs bieten können, ignoriert werden würde. Durch sie werden Werte im modernen Geschäft ausgetauscht. Dies macht APIs auch zur Sache der Geschäftsführung und Strategieentscheider. APIs sind allein Sache der IT-Abteilung.

Bei API-Lösungen, wie auch bei API-Produkten kann man den Konsumenten der API als intern oder extern klassifizieren. In der Welt der APIs ist ein Verbraucher einfach jeder, der einen Dienst nutzt, unabhängig davon ob er bezahlt wird oder nicht. Ein externer Verbraucher ist genau das, ein Dritter, der außerhalb der Unternehmenseinheit die API oder den Dienst, der durch eine API bereitgestellt wird, nutzt. Ein interner Verbraucher ist jedoch jemand, der innerhalb des Geschäftsbereichs existiert. Dies sind also Teams die unternehmensinternen Lösungen und Integrationen schaffen. Dies wird durch das untere Bild illustriert:

Abbildung 1: externe vs interne Verbraucher

Aus geschäftlicher Sicht steckt hinter jeder Transaktion ein Mehrwert, unabhängig von der Art der Datenverarbeitung oder ob sie den Umsatz direkt steigert. Es ist demnach nicht weithergeholt, wenn APIs als Produkt verwaltet werden, um so neue umsatzorientierte Einnahmequellen zu schaffen. Aus diesem Grund ist es wichtig, APIs als Geschäftsressource /Assets und nicht als amorphe Codebasis zu sehen. APIs sind also nicht nur Sache der IT-Abteilung.

50% of Salesforce transactions are done through their API. – source

Viele betrachten API-Produkte jedoch als Dinge, die große Internetunternehmen verwenden, um Ökosysteme rund um ihre Dienste zu erstellen. Konsistent gestaltete RESTful-APIs tragen jedoch auch intern dazu bei, direkte Kosten und auch Opportunitätskosten zu sparen, die eine mehrfach wiederholte Entwicklung von API-Lösungen mit sich bringt. In größeren Unternehmen ist es häufig der Fall, dass für Integrationsprojekte neue API-Lösungen erstellt werden. Wiederholt sich der Integrationsbedarf des gleichen Backendsystems, wird wieder eine neue Lösung geschaffen. In solchen Fällen treibt ein API-Produkt die Idee der Wiederverwendbarkeit von Schnittstellen voran, indem es zahlreiche API-Ressourcen in Pakete sammelt, die auf die Bedürfnisse verschiedener Entwicklergemeinschaften zugeschnitten sind.

Wie bereits erwähnt, sind die Benutzer eines API-Produkts interne oder externe Verbraucher, die Dienste oder Integrationen erstellen, sei es für Kunden, für Mitarbeiter oder um Automatisierung und Effizienz zu erhöhen. APIs sind also eine Möglichkeit für Unternehmen, die Entwicklung zu beschleunigen und die Effizienz in Wochen oder Monaten, nicht in Jahren zu verbessern.

Fazit

Das Label der Middleware bleibt in größeren Unternehmen jedoch meist bestehen. Es gibt viele Gründe dafür: Legacy-Architekturen, Monolithic Applications und traditionelle Integrations- und Entwicklungstechniken, die alle dazu neigen, APIs als reines Mittel zum Zweck zu sehen.

In vielen Unternehmen ist diese Verwendung tief verwurzelt und wird demnach weiterhin gelebt und umgesetzt. Was bei einer API-Produktstrategie zu bedenken ist, betrachten wir später in dieser Serie zu API Management.

Dieser Artikel ist der Erste in einer Reihe von Artikeln über API Management in Enterprise Organisationen. Ziel der Reihe ist es meine Sicht darauf zu geben, wie API Management im Enterprise-Kontext eingesetzt werden kann.

Die Rolle des API Managements (APIM)

Das API-Management ist der Prozess der Überwachung von Application Programming Interfaces (APIs) in einer sicheren, skalierbaren Umgebung. Das Ziel von des API Managements ist es den Lebenszyclus und die Verwendung einer API zu überwachen. Sie können so sicherstellen, dass Anforderungen von Entwicklern eingehalten werden.[1]

Um diesen Prozess zu unterstützen haben viele Unternehmen eine Softwarelösung geschaffen. Gartner hat diese am 09.Oktober 2019 in einem Magic Quadrant for Full Life Cycle API Management bewertet. Zu den „Leaders“ gehören unter anderem:

· AWS (Amazon Web Services)

· Google (mit Apigee)

· Microsoft (Azure API Management)

· Uvm.

Für technische Beispiele im Laufe der Blog-Serie zu API Management werde ich Azure API Management von Microsoft verwenden. Die meisten Konzepte sind jedoch meist problemlos übertragbar auf andere Anbieter.

Wenn das API-Management in einem Unternehmen richtig implementiert ist, führt es zu folgenden Ergebnissen:

· besser verwaltete Entwickler-Community

· gute Kontrolle über die API-Verwendung

· Entdecken von potenziellen Monetarisierungsmöglichkeiten

· robuster Sicherheits- und Governance-Prozess

· Geldeinsparung durch Vermeidung von Neuentwicklungen

Aufbau eines API Management Systems

Häufig sieht man, dass die Systeme von der logischen Architektur her aufgeteilt sind in einen API Developer und in einen API-Konsumenten fokussierten Teil; auch wenn diese Parteien nicht überall gleich benannt sind.

Figure 1: Architektur eines API Managements (Azure APIM). Quelle: azure.microsoft.com/en-us/services/api-management

Der Grund für diese Aufteilung liegt nicht nur in der zweiseitigen Natur von APIs. Ziel ist auch APIs, je nach Unternehmensstrategie verfügbar, auffindbar und insbesondere wiederverwendbar zu machen. In einem späteren Artikel werde ich näher auf die Best-Practices von API Management eingehen. So „stay tuned“!

API Gateway

Das API-Gateway ist der Endpunkt, der folgende Aufgaben übernimmt:

· Akzeptieren von API-Aufrufen und Weiterleiten dieser Aufrufe an Ihre Back-Ends

· Überprüfen von API-Schlüsseln, JWT-Token, Zertifikaten und anderen Anmeldeinformationen

· Erzwingen von Nutzungskontingenten und Übertragungsratenlimits

· Dynamisches Transformieren Ihrer API ohne Codeänderungen

· Zwischenspeichern von Back-End-Antworten, falls eingerichtet

· Protokollieren von Aufrufmetadaten zu Analysezwecken

Developer Portal

Das Developer Portal dient als wichtigste Webpräsenz für Veröffentlicher von APIs und als wichtigste Informationsquelle für Konsumenten/Entwickler. Es ermöglicht Folgendes:

· Lesen der API-Dokumentation

· Ausprobieren einer API mithilfe der interaktiven Konsole

· Erstellen eines Kontos und Anfordern von API-Zugriffsdaten

· Zugriff auf Nutzungsanalysen

Management Plane

Diese Oberfläche ist die Verwaltungsebene, über die das “API Management” durch die API-Administratoren verwaltet wird. Dazu gehört unter anderem:

· Definieren oder Importieren des API-Schemas

· Paketieren von APIs in Produkten

· Konfigurieren von Richtlinien wie z. B. Kontingenten oder Transformationen für die APIs

· Gewinnen von Erkenntnissen mithilfe von Analysen

· Verwalten von Benutzern

Sicherheit

Mit dem API Management lassen sich die backend-Services schützen. Eine typische Aufgabe ist die des „Edge“ Gateways, das zwischen Unternehmen und dem Internet typischerweise in einer demilitarisierten Zone (DMZ) angesiedelt ist. Ein API-Gateway kann Konsumenten authentifizieren und Anfragen autorisieren. Das Format und der Inhalt von Anfragen kann gegen Formatbeschreibungen (Schema) geprüft (validiert) werden. Die Transportverschlüsselung mit TLS bzw. SSL kann ebenfalls ein API Gateway übernehmen. Dadurch können sogar nicht explizit abgesicherte APIs sicher zur Nutzung angeboten werden.

Monitoring

Da das Gateway, wie der Name bereits vermuten lässt, die Anfragen entgegennimmt und validiert, werden dabei Metriken erfasst. Standartmäßig werden Last auf das Gateway, Anzahl der Verbindungen, Verfügbarkeit und Antwortzeiten erfasst. Diese werden in der Management Plane visualisiert. Es ist hier dann möglich „Alarme“ basierend auf den Metriken zu erstellen, um zum Beispiel schnell über kritische Probleme informiert zu werden.

Logging

Es ist möglich Logeinträge für alle Aufrufe des Gateways zu schreiben. Meist ist es jedoch üblich die Logs für einzelne APIs und Operationen zu gesonderten Log-Umgebungen zu senden, damit jeder API-Entwickler gesondert auf die für ihn relevanten Logs Zugriff hat.

Routing

Aufrufe können vom API Management Gateway an verschiedene Systeme weitergeleitet werden. Diese Regeln können den Inhalt des Aufrufes verwenden, um beispielsweise Aufrufe an verschiedene Versionen des Backendsystems zu senden.

Transformation

Häufig möchte man nicht, dass das Datenformat des Back-Ends auch in den Aufrufen verwendet wird. Hierfür bietet das API Management eine Funktion an, die es ermöglicht den Inhalt der Aufrufe zu transformieren, um Back-End-kompatibel zu sein.

Access Management

Durch die Aufteilung in API-Entwickler und API-Konsumenten ist das Zugriffsmanagement ähnlich aufgeteilt. So kann man beiden Gruppen in ihrem Bereich getrennt per RBAC (Role Based access controll) Zugriff auf die APIs geben.

Damit kann man genau definieren welcher Konsument welche APIs oder API-Produkte sehen darf und auf API-Entwickler Seite ebenso kontrollieren wer welche Eigenschaften einer API verändern darf.

Abrechnung/Monetarisierung

Für viele Firmen gehört es dazu die Nutzung von APIs an ein Bezahl-Model zu koppeln. Zur Limitierung der Anzahl an Aufrufen pro Konsumenten bieten API Management Systeme entsprechende Funktionalität an. Dadurch müssen solch aufwändig zu implementierende Limitierungen nicht in den Back-End APIs implementiert werden.

Fazit

Wenn du es bis hierhin geschafft hast, hast du ein gutes Grundverständnis erlangt um nun in jedes einzelne Thema gesondert einsteigen zu können.

Ein API Management als Tool ist vielseitig und gibt eine breite Palette an Funktionen vor, die von Unternehmen verwendet werden können, um nicht nur APIs zu sichern und zu verwalten, sondern auch um eine Strategie zu verfolgen, die über ein “einfaches Verwalten” von APIs hinausgeht.

Im Laufe der Serie plane ich unter anderem die folgenden Aspekte zu betrachten:

· APIs als Produkte

· API Live-Cycle

· Policy

· Monitoring & Logging

· Sicherheit

· Routing

· APIM mit Microservices oder Serverless

· …

[1] searchsoa.techtarget.com/definition/API-management

Grafiken oder Bilder mit einer guten Qualität und damit auch Größe austauschbar in einem PowerBI Report darzustellen ist durch die begrenzte Spaltengröße beim Laden der Daten gar nicht so einfach. Mit einem kleinen Trick lassen sich aber auch große Bilder dynamisch aus einer Datenbank laden.Wie ich dabei vorgegangen bin, möchte ich in diesem Artikel detailliert vorstellen.

Vorbereitung

Leider gibt es eine Größenbeschränkung für die als Datasource festgelegten Spalten. Die Spalten dürfen also eine bestimmte Größe nicht überschreiten, wodurch man auf dem im Artikel Dynamische Bilder in PowerBI beschriebenen Weg nur kleine Bilder verwenden kann.

Mein hier gezeigtes Beispiel setzt auf den in dem Artikel Dynamische Bilder in Power BI angelegten Daten auf.

Ich werde ein Projektlogo dynamisch hinzufügen. Das Logo hat aber eine Größe deutlich über 20 KB. Die Lösung ist es, das Image in viele kleine Teile zu zerlegen, sodass es pro Logo mehrere Imageteile gibt.

Für mein Beispiel habe ich folgende Tabellen hinzugefügt:

In der Project Tabelle wird die LogoID hinzugefügt.

Die Logos werden angelegt und den Projekten hinzugefügt.

Mit dem unten angegebenen Code wird das Logoimage zerlegt und in kleinen Teilen in der Tabelle LogoImage abgelegt. Der Index ist hier die Reihenfolge, in der das Bild hinterher wieder zusammengesetzt werden muss.

PowerBI Report

Im Report wird eine zweite Seite für die Projectdetails angelegt und dann muss die Datenquelle anpassen werden. Dafür gehen ich auf Edit Queries.

Die Tabellen Logo und LogoImage hinzufügen.

Für die Spalte mit den Bilddaten muss der Datentyp auf Text geändert werden.

Mit Close and Apply speichern.

In der Reportansicht muss der Logo-Tabelle ein neues Measure hinzugefügt werden

New Measure:

Nun kann der Detail-Report gebaut werden. Um das Logo hinzuzufügen, wird vom Marketplace ein Image Visual benötigt. Das simple Image hat hierfür leider nicht funktioniert. Ich habe Image by CloudScope verwendet.

Und als Ergebnis erscheint dann das vollständige Logo, obwohl es größer als 20 KB ist.

Auf diese Weise können Bilder beliebiger Größe aus einer Datenbank in den Report geladen werden und der eigentliche Report braucht zum Beispiel beim Hinzufügen eines neuen Projektes nicht mehr angefasst und neu gepublished werden.