10.09.2018

Azure API Management: Diese 5 Policies solltet ihr kennen

Technical Value

API Management Policies

In den vergangenen Monaten habe ich schon mehrere Blog-Beiträge zum Azure API Management veröffentlicht, einem meiner Lieblingsthemen. Dabei bin ich auf den Aufbau und Nutzen des Web-Portals eingegangen. Zuletzt habt ihr erfahren können, wie die Veröffentlichung einer API läuft.

Im letzten Teil meiner kleinen Serie möchte ich euch nun zeigen, wie ihr Richtlinien und besondere Verhaltensweisen für eure APIs anlegt. Auf insgesamt fünf dieser Policies will ich näher eingehen:

  • CORS: Welche Webseiten dürfen eure API einbinden?
  • Cross-Domain: CORS für Adobe Flash und Microsoft Silverlight
  • Call-Limit: Wie viele Aufrufe sind erlaubt?
  • Quota: Was ist die maximale Nutzung?
  • Header: Wie kann ich mein Backend schützen?

Die Policies lassen sich auf Produkte, APIs und einzelne API-Endpunkte in zwei wesentlichen Bereichen anwenden: Inbound und Outbound. Inbound-Policies steuern den Aufruf, bevor er an das Backend weitergeleitet wird. Outbound-Policies hingegen verarbeiten die Antwort? des Backends weiter, bevor diese an den Aufrufer zurückgegeben wird.

Zunächst erkläre ich euch die CORS- und Cross-domain-Policies, damit eure API auch von anderen Webseiten aus genutzt werden kann. Danach zeige ich euch, wie ihr die Nutzung eurer API einschränkt, um zum Beispiel verschiedene Produkte wie „Free“ oder „Premium“ anbieten zu können. Zu guter Letzt gebe ich euch mit der Header-Policy noch eine super Möglichkeit an die Hand, mit der ihr euer Backend schützen könnt.

CORS: Welche Webseiten dürfen eure API einbinden?

CORS ist eine Inbound-Policy und steht für „Cross-Origin Resource Sharing“. Ihr könnt also über die CORS-Policy festlegen, welche Webseiten eure API einbinden dürfen und welche verschiedenen http-Methoden (GET, POST, …) verwendet werden können. Wenn also eure API auch von anderen Webseiten genutzt werden soll, dann müsst ihr entsprechende CORS-Policies definieren.

Dabei möchte ich euch empfehlen, die CORS immer gleich für die gesamte API zu setzen. So bleibt die Menge der Policies übersichtlich. Ihr habt später keine Probleme mit der Wartbarkeit und müsst euch auch nicht fragen, warum ein neuer Endpunkt nicht funktioniert.
Um die CORS zu definieren, wählt ihr zunächst im Azure Portal euer Azure API Management aus und öffnet das API-Blade. Danach geht ihr folgendermaßen vor:

  1. Wählt eure API aus
  2. Wählt „All operations“ aus
  3. Öffnet das Drop-Down bei „Inbound processing“
  4. Klickt „Code editor“ an

CORS beim Azure API Management definieren

Nun seht ihr ein XML-Dokument, in dem die Policies geschrieben werden. Dort könnt ihr innerhalb des Inbound-Tags folgendes Snippet einfügen, um einen Zugriff von allen Domains sowie für alle Methoden und Header zu erlauben:

  1. <cors>
  2. <allowed-origins><origin>*</origin></allowed-origins>
  3. <allowed-methods><method>*</method></allowed-methods>
  4. <allowed-headers><header>*</header></allowed-headers>
  5. </cors>

Wenn ihr spezifischere Einstellungen benötigt, dann könnt ihr den Stern auch durch eine URL, eine Methode bzw. einen Header ersetzen. Wollt ihr beispielsweise CORS nur für zwei bestimmte URLs aktivieren, so könnte das Snippet wie folgt aussehen:

  1. <cors>
  2. <allowed-origins><origin>http://localhost:8080</origin><origin>http://example.org</origin></allowed-origins>
  3. <allowed-methods><method>*</method></allowed-methods>
  4. <allowed-headers><header>*</header></allowed-headers>
  5. </cors>

Cross-domain: CORS für Adobe Flash und Microsoft Silverlights

Cross-domain ist ebenfalls eine Inbound-Policy. Sie wird insbesondere bei Adobe-Flash- oder Microsoft-Silverlight-Clients verwendet und funktioniert äquivalent zur CORS-Policy. Um die Cross-domain-Policy einzustellen, navigiert ihr – wie eben gezeigt – in das XML-Dokument. Dort könnt ihr dann beim Inbound-Tag folgendes Snippet einfügen:

  1. <cross-domain>
  2. <cross-domain-policy>
  3. <allow-http-request-headers-from domain="*" headers="*" />
  4. </cross-domain-policy>
  5. </cross-domain>

Nun kann eure API aus anderen Webseiten, Flash- oder Silverlight-Clients heraus verwendet werden.

Call-Limit: Wie viele Aufrufe sind erlaubt?

Damit eure API nun nicht von zu vielen Anfragen überrannt wird, empfiehlt es sich ein Call-Limit einzurichten. Wenn ihr eure API monetarisieren wollt, könnt ihr auch eine kostenlose Version anbieten, die beispielsweise nur 10 Aufrufe pro Minute erlaubt. Ergänzend macht eine bezahlte Version ohne Limitierung Sinn.

Die Aufruf-Limitierung wird ebenfalls über eine Inbound-Policy eingestellt. Entsprechend müsst ihr wieder in das XML-Dokument navigieren um dort im Inbound-Tag folgendes Snippet einzufügen:

  1. <rate-limit-by-key calls="10" renewal-period="60" counter-key="@(context.Subscription.Id)" />

Dadurch limitiert das Azure API Management die Aufrufe auf maximal 10 pro Minute für jede Subscription. Ist das Limit erreicht, bekommt der Aufrufer eine Antwort mit dem HTTP-Status 429 sowie der Nachricht, ab wann die API wieder verwendet werden kann.

Wenn ihr die Call-Limit-Policy zur Monetarisierung eurer API nutzen möchtet, dann müsst ihr sie auf der Produkt-Ebene statt auf der API-Ebene anlegen. Dazu öffnet ihr das produktspezifische XML-Dokument und tragt die Policy dort ein. In dieses Dokument gelangt ihr mit folgenden Schritten:

  1. Products-Blade auswählen
  2. Produkt auswählen
  3. Reiter „Policies“ auswählen

 

Call Limit beim Azure API Management einrichten

Quota: Was ist die maximal mögliche Nutzung?

Über das Call-Limit könnt ihr also die Frequenz bestimmen, mit der sich eure API verwenden lässt. Die Quota-Policy ermöglicht es euch nun, auch die maximale Nutzung auf einen bestimmten Zeitraum zu begrenzen. Das ist vor allem dann sinnvoll, wenn ihr mit eurer API Geld verdienen wollt. Auf diese Weise könnt ihr verschiedene Produkt-Ausbaustufen anbieten. Ein klassisches Limit wäre z.B. 1.000 Aufrufe am Tag und 1 GB an übertragenen Daten.
Die Inbound-Policy hierzu sieht so aus:

  1. <quota-by-key calls="1000" bandwidth="1048576" renewal-period="86400" counter-key="@(context.Subscription.Id)" />

Header: Wie kann ich mein Backend schützen?

Wie versprochen, möchte ich euch zuletzt noch zeigen, wie ihr euer Backend schützen könnt. Denn: Zur Freude potenzieller Angreifer, lassen sich viele WebServer über den Antwort-Header identifizieren. Beispielsweise ist der Header „X-Powered-By“ ein Kandidat, der häufig die verwendete PHP-Version verrät. Somit braucht sich ein Angreifer nur noch über bekannte Schwachstellen der entsprechenden PHP-Version zu informieren, und schon kann er sich unerlaubt Zugriff auf eure API verschaffen.

Um solchen Szenarien einen Riegel vorzuschieben ist es ratsam, diese Header aus der Antwort zu entfernen. Das lässt sich über die Header-Policy bewerkstelligen. Es empfiehlt sich, für alle APIs die zugehörigen Policies in dem Outbound-Tag zu pflegen. Dazu müsst ihr wieder in das XML-Dokument navigieren und dann:

  1. „All APIs“ auswählen
  2. Dropdown-Menü unter „Outbound Processing“ öffnen
  3. „Code editor“ öffnen

Backend beim Azure API Management schützen

Das entsprechende Policy-Snippet im Outbound-Tag sieht dann so aus:

  1. <set-header name="X-Powered-By" exists-action="delete" />

So weit, so gut. Ihr habt nun die wichtigsten Funktionsweisen des Azure API Managements kennengelernt. Meine kleine Blogserie ist damit beendet. Ich wünsche euch viel Spaß und Erfolg beim Einsatz des Azure API Managements für eure eigenen Projekte. Falls ihr noch irgendwelche Fragen habt, könnt ihr mich gerne kontaktieren.

Neuen Kommentar schreiben

Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.

Klartext

  • Keine HTML-Tags erlaubt.
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.
  • Web page addresses and email addresses turn into links automatically.
Teilen auf

Newsletter Anmeldung

Abonnieren Sie unseren Newsletter!
Lassen Sie sich regelmäßig über alle Neuigkeiten rundum ORAYLIS und die BI- & Big-Data-Branche informieren.

Jetzt anmelden