eBizTalk - Berichten, Unterhalten, Weiterbilden
Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

XML basierte Konfiguration in Azure API Management

Veröffentlicht am 04.06.2018 von Mahmoud Habiballah , Azure

In den letzten Jahren hat sich HTTP, dank REST, als eines der wichtigsten Protokolle zur Kommunikation zwischen Web-Services etabliert. Die Verwaltung und Betreuung solcher Services ist eine große Herausforderung. Mit Azure API Management will Microsoft das ändern.

Eine API (Application Programming Interface) beschreibt Operationen, die die Schnittstelle für Kommunikation zwischen Systemen zur Nutzung ihrer Funktionalitäten, vorschreiben.

Die Bereitstellung komplexer APIs stellt für Entwickler und Administratoren viele Herausforderungen dar, die sich stark voneinander unterscheiden und die umfangreiche Kenntnisse erfordern, um diese verwalten zu können. Die Verwaltung einer API befasst sich u.a. mit folgendem:

  • Zugriffsteuerung

  • Analytik

  • Dokumentation für Entwickler

  • Ratenbegrenzung

Azure API Management, ist ein Microsoft „Platform as a Service“ (PaaS) zur Lösung oben genannter Aufgaben. Er bietet u.a. einen Proxy zwischen der zu verwaltenden API und Anwendungen, die die Dienste der API nutzen. Durch Azure API Management verwaltete APIs müssen nicht in Azure gehostet werden, sondern können auch on premises oder in anderen Cloud Diensten gehostet werden.

Azure API Management teilt sich in drei Komponenten auf:

  • Publisher Portal: Eine Web-Applikation, womit Herausgeber der API unterschiedliche Konfigurationen des Proxys verwalten können.

  • Developer Portal: Bietet den Entwicklern eine Web-Applikation, um auf die Dokumentation der API sowie ihre eigenen Monitoring Dienste zuzugreifen.

  • API Proxy: Es besteht kein direkter Zugriff auf die API. Client Anwendungen kommunizieren mit dem Proxy zur Weiterleitung der Aufrufe an die API.

Da verschiedene APIs sich des gleichen Geschäftsmodels bedienen können, bietet Azure API Management das Produkt (Products) Konzept an. Ein Produkt stellt den Entwicklern eine Art von Abonnement zur Verfügung, womit verschiedene APIs zusammen verwaltet werden können.

Ein Produkt und seine APIs können durch Richtlinien (Policies) konfiguriert werden.

Die Macht der Richtlinien

Wie oben erwähnt, findet jede Kommunikation zwischen einer API und einer Anwendung, durch den Proxy statt. Dadurch ist es möglich alle Anfragen (Inbound) sowie Antworten (Outbound) vom Proxy abzufangen und je nach Anfrage oder Antwort, zusätzliche Dienste anzubieten.

Diese Richtlinien können innerhalb des Lebenszyklus einer Anfrage ausgeführt werden. Dieser Lebenszyklus  besteht aus 4 Phasen:

  1. Inbound: beim Eingang eines Aufrufs.

  1. Outbound: beim Ausgang eines Aufrufs (Antwort auf den eingehenden Aufruf).

  1. Backend: nach Inbound Richtlinien und bevor die Anfrage an die Backend API geschickt wird.

  1. Error: beim Auftritt von Fehlern.

Richtlinien sind XML basiert und können auf Produkte, APIs und Operation angewandt werden. Außerdem unterstützen sie C#-6, womit sich sämtliche Szenarien dynamischer und flexibler verwalten lassen.
Die Abbildung zeigt die Konfigurationsoberfläche für die Richtlinien.

1

Sollen z.B. die Anfragen aller APIs als XML beantwortet werden, müssen die folgenden Rechtlinie für alle Produkte, APIs und Operationen spezifiziert werden:

2

Solche Richtlinien sind zustandslos. Mit der vordefinierten Context-Variable ist es aber durchaus möglich auf Anfragen bezogene Informationen und Metadaten zuzugreifen. So kann man z.B. festlegen, dass von einer IP-Adresse maximal 5 Aufrufe pro Sekunde behandelt werden.

3

Wird ein Endpunkt mehr als 5 Mal innerhalb von 20 Sekunden aufgerufen, erhält man einen Rate Limit-Fehler:

4

Es ist zu beachten, dass das erste Beispiel eine Outbound-Richtlinie und das zweite eine Inbound-Richtlinie zeigt. D.h. dass, das erste Beispiel auf allen Antworten anzuwenden ist. Beim zweiten sind nur eingehende Aufrufe betroffen.

Innerhalb des „on-error“ Abschnitt, kann man Richtlinien, die beim Auftreten von Fehlern ausgewertet werden, festlegen.  Im folgenden Beispiel wird nach Fehlern, die durch die Auswertung der Ratenbegrenzungsrichtlinie ausgelöst werden, gesucht. Dafür ist von den Ablaufsteuerungselementen wie z.B. „choose“ und „when“ Gebrauch zu machen. Damit lassen sich Antworten modifizieren.

5

Richtlinien sind nicht nur für die Kommunikation einer Applikation, dem Proxy und der API gedacht. Aufrufe an externe Dienste können z.B. mittels der Richtlinie „send-request“ definiert werden.

6

In diesem Artikel wurde insbesondere auf das Thema Richtlinien in Azure API Management eingegangen. Eine XML basierte Konfiguration, zur Behandlung und Bearbeitung von Anfragen, welche nicht nur statische Konfigurationen sind. Auch dynamische und flexible Konfigurationen, die sich innerhalb des Lebenszyklus einer Anfrage, auswerten lassen sind möglich und einfach zu gestalten.

Fazit

Vielen lassen sich vom Azure API Management täuschen und stellen es sich als ein weiteres Werkzeug, um APIs in der Cloud zu hosten, vor. Das ist aber nicht der Fall.

Azure API Management stellt ein mächtiges Werkzeug in Azure für den Einsatz, Verwaltung und sogar bis zur Erweiterung dieser APIs. Ob für Administratoren oder Entwickler, lassen sich solche Aufgaben, flexibel mittels Richtlinien erledigen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

Geheimnisse sichern mit Azure Key Vault

Veröffentlicht am 01.06.2017 von Alexander Müller , Azure , Security

Da IT-Sicherheit in der heutigen Zeit immer mehr an Bedeutung gewinnt, gehört das Basiswissen über kryptografische Protokolle, Verschlüsselungsalgorithmen und Hash-Funktionen sowie deren kryptografische Stärke zum Basisrepertoire eines jeden Entwicklers. Mit dem aktuellen Trend zur Cloud stellt sich häufig die Frage wie dort Geheimnisse und Schlüssel geschützt werden können. Microsoft bietet dafür den Service „Azure Key Vault“ an.

Durch einen Vortrag auf der Technical Summit 2016 bin ich auf Azure Key Vault aufmerksam geworden. Da das Thema im Vortrag nur in einem Nebensatz erwähnt wurde, habe ich beschlossen mich näher damit auseinanderzusetzen und meine Erkenntnisse zu teilen.

Die Herausforderung

Als .NET-Entwickler hat man sich daran gewöhnt Connection Strings, API Keys etc. im Klartext in der Konfigurationsdatei der Anwendung (z. B. app.config) gleich neben den Anwendungseinstellungen abzulegen – meist einhergehend mit dem Gefühl, dass dies nicht der sicherste Ort dafür ist. Denn die Konfigurationsdatei wird in der Quellcodeverwaltung hinzugefügt und ist dadurch für das gesamte Entwicklungsteam, aber auch für alle anderen Personen mit Zugriff auf das Repository oder das Dateisystem, sichtbar. 

Azure Key Vault 

Mit Azure Key Vault bietet Microsoft einen Cloud Service an, mit dessen Hilfe geheime Schlüssel von der Anwendung separiert und an einem gesicherten Ort abgelegt werden können. So bleibt die Kontrolle über diese Daten beim Besitzer. Der Anwendung selbst wird bei Bedarf die Verwendung eines Schlüssels eingeräumt, jedoch nie direkter Zugriff darauf gewährt. Weiterhin wird jede Aktion in Azure Key Vault geloggt. Dieses Log kann zur Analyse von Monitoring-Systemen genutzt werden, um im Falle einer kompromittierten Anwendung, schnell gewarnt zu werden. Selbst im Fall der Fälle, können bei Verwendung eines Read-only Service Users keine Schlüssel durch die Anwendung geändert oder gelöscht werden.

Schlüssel und Geheimnisse

 image

In Azure Key Vault können Schlüssel und Geheimnisse gespeichert werden, doch worin liegt der Unterschied?

Mit Schüssel (keys) sind kryptografische Schlüssel zum Verschlüsseln und Entschlüsseln von sensiblen Daten in der Anwendung gemeint. Besonders zu schützende Schlüssel können direkt in Hardwaresicherheitsmodule (HSM) importiert oder dort generiert werden (Premium Service Tier notwendig, siehe auch Key Vault – Preise). Damit ist sichergestellt, dass diese nur innerhalb der Modulgrenzen bekannt sind.

In Azure Key Vault gibt es keine semantische Vorgabe, was als Geheimnis zählt und was nicht. Allerdings existiert eine Größenlimitierung von 25KB. Passwörter, API Keys, Connection Strings sind dort bspw. richtig aufgehoben. 

Schutz durch Azure Active Directory

Wie können Anwendungen nun auf die geheimen Daten zugreifen, ohne selbst wieder ein Geheimnis für den Zugriff auf Azure Key Vault preiszugeben? Die Antwort ist „Azure Active Directory“Authentifizierung. Die Anwendung wird im Active Directory registriert und authentifiziert sich dann mit Hilfe von ClientID und ClientSecret. Daraufhin ist der Zugriff auf den Key Vault, welcher sich im selben Active Directory befindet, möglich.

Aber wohin nun mit ClientID und ClientSecret? Beide können als Anwendungseinstellung in der Konfigurationsdatei der Anwendung gespeichert werden, sind dann jedoch wieder für jede Person mit Berechtigung auf Repository oder Dateisystem sichtbar. Zur Umgehung dieses Problems, gibt es zwei Lösungsansätze:

  1. Statt die Werte im Klartext in der Konfigurationsdatei zu speichern, werden „leere“ Einstellungen für ClientID und ClientSecret erstellt und die Werte selbst in den Anwendungseinstellungen im Azure Portal hinzugefügt. Dadurch werden vorhandene Werte zur Laufzeit durch die im Portal konfigurierten Werte überschrieben. Das Portal gilt als sicherer, da es in der Regel nur von einem eingeschränkten Personenkreis administriert wird und durch Zwei-Faktor-Authentifizierung zusätzlich geschützt werden kann. Dennoch, das Geheimnis ist im Klartext im Portal ersichtlich. 
  2. Mehr Sicherheit bietet die Authentifizierung mit ClientID und Zertifikat. Dies ist die sicherste Methode, da in Azure hinzugefügte Zertifikate nicht heruntergeladen werden können und der private Schlüssel nicht über die Oberfläche sichtbar ist. 

Fazit

Azure Key Vault ist ein Service, mit dem Schlüssel und Geheimnisse leicht zentral und separiert von der Anwendung administriert werden können. Laut Produktbeschreibung kann nicht einmal Microsoft selbst diese Daten einsehen. Der zusätzliche Programmieraufwand zur Verwendung des Service hält sich sehr in Grenzen, sodass der Aufwand auch für kleinere Applikationen gerechtfertigt werden kann. Besonders für Cloud-Anwendungen, in denen mit personenbezogenen Daten gearbeitet wird, sollte die Verwendung in Erwägung gezogen werden. Erste Schritte mit Azure Key Vault habe ich in diesem Sway dokumentiert. Eine Kostenübersicht für Azure Key Vault ist hier zu finden.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise