Netzwerk-Schnittstellen für mobile Endgeräte Sichere Entwicklung von API-Anwendungen

Autor / Redakteur: Sascha Preibisch, Layer 7 / Stephan Augsten

Benutzer mobiler Computer und Smartphones sind es gewohnt, via Internet jederzeit auf persönliche Daten zugreifen zu können. Wirklich sicher funktioniert das aber nur über entsprechende Schnittstellen im Unternehmen. Dieser Beitrag befasst sich mit der API-Sicherheit.

Fallbeispiel für den Zugriffsschutz mithilfe eines API Proxy.
Fallbeispiel für den Zugriffsschutz mithilfe eines API Proxy.

Wenn Smartphone- und PC-Nutzer sich mit dem Internet verbinden, so werden hierfür in der Regel Internet-Browser oder Apps auf den Endgeräten genutzt. Entsprechende Anwendungen verbinden sich bei jedem Aufruf mit einem Server, der eine API (Application Programming Interface) zur Verfügung stellt, um die angeforderten Daten zu liefern.

Anbieter dieser APIs müssen sicherstellen, dass diese zuverlässig und sicher funktionieren. Darüber hinaus muss man der Lage sein, einzelne APIs hinsichtlich ihrer Antwortzeiten, Aufruffrequenzen oder der aufrufenden Anwendung zu überwachen. Anbieter sollten weiterhin einzelne APIs deaktivieren oder die mögliche Zugriffshäufigkeit ändern können, bzw. einzelne APIs vor Zugriffen bestimmter Anwendungen schützen.

Für einen Anbieter kann es eine Herausforderung sein, diese APIs entsprechend anzubieten. Ein guter Weg diese Aufgabe zu erfüllen sind zwei bestimmte Schritte. Zum einen sollten APIs über einen API Proxy im Internet zur Verfügung gestellt werden, zum anderen empfiehlt sich der Einsatz sogenannter API-Keys.

Wie funktioniert ein API Key

Ein API Key ist ein Authentifizierungsmerkmal für einzelne Anwendungen. Sollen API-Schlüssel eingeführt werden, müssen Anwendungsentwickler ihre Anwendung über den API Proxy registrieren. Der API Proxy generiert einen API Key, welcher mit jedem Aufruf der Schnittstelle verwendet werden muss.

Der API Proxy identifiziert den Schlüssel und kann so Kennzahlen erstellen und Regeln zur Verwendung dieses API-Keys anwenden. In Kombination mit OAuth kann der API-Schlüssel auch dazu verwendet werden, einen konkreten Benutzer mit einer Anwendung in Verbindung zu bringen. In OAuth wird der API Key als oauth_consumer_key (OAuth 1.0) oder client_id (OAuth 2.0) bezeichnet.

Da die Anwendung die Login-Daten des Benutzers nicht kennt und auch nicht kennen soll, muss der Benutzer die Anwendung in einer anderen Art und Weise authorisieren. Eine OAuth-fähige Anwendung verwendet dabei den API Key und ein Passwort (API Key Secret, shared secret, oauth_consumer_key_secret), um sich zu authentifizieren.

Der Anwender muss dann aktiv den Zugriff der entsprechenden Anwendung authorisieren. Diese erhält anschließend einen sogenannten access_token. Versucht die Anwendung später auf die Daten den Benutzers zuzugreifen, muss diese den API Key und den access_token (je nach OAuth-Version) mitgeben.

Auf der einen Seite kanm der API-Anbieter nun festzustellen, welche Anwendung auf welche API zugreift und welcher Benutzer diese Anwendung authorisiert hat. Auf der anderen Seite ist für den Benutzer nachvollziehbar, welchen Anwendungen er Zugriff gewährt hat. Die Zugriffrechte kann er selbst verwalten und auch zurückziehen.

Neben mobilen Endgeräten rückt aktuell auch das Thema BYOD (Bring Your Own Device) in den Vordergrund, wenn es um Datensicherheit geht. Mitarbeiter bringen ihre eigenen Endgeräte mit zu ihrem Arbeitsplatz, in der Erwartung, diese über das Firmennetzwerk verwenden zu können. Eine Verbindung zum Internet lässt sich noch relativ einfach und sicher anbieten.

Soll das Endgerät jedoch auf firmeninterne Daten zugreifen, wird die Verwaltung schwieriger. Ein Ausweg kann auch hier die Verwendung von API-Keys sein. Firmen könnten Anwendungen für die geläufigsten Endgeräte entwickeln und dabei auch API-Keys und OAuth verwenden.

Die Verwaltung wäre durch den API Proxy handhabbar. Zudem kann die Möglichkeit genutzt werden, den API Proxy für interne und externe Anwendungen unterschiedlich zu konfigurieren. So lassen sich in Abhängigkeit des benutzten API-Keys beispielsweise OAuth-Token mit unterschiedlich langer Lebensdauer generieren.

Während der Entwicklung einer Anwendung kann in unterschiedlichen Umgebungen mit unterschiedlichen API-Keys und OAuth-Token gearbeitet werden. Ein API Proxy sollte in der Lage sein, allein durch Konfigurationsanpassungen, verschiedene Umgebungen zu unterstützen. So können, in Abhängigkeit vom Entwicklungsstadium der jeweiligen Anwendung, sowohl der Umfang der gelieferten Daten als auch die verwendeten Zugriffsrechte eingeschränkt werden.

Anforderungen an den API Proxy

Da ein API Proxy in der DMZ platziert wird, ist es eine Frage der Sicherheit, dass API-Keys und OAuth-Token nicht dort, sondern im internen Netzwerk verwaltet werden. Der API Proxy sollte zu keiner Zeit direkten Zugriff (z.B. durch eine direkte Datenbankverbindung) auf ein API Key Secret haben. Eine umfassende API-Proxy-Lösung besteht deshalb aus mindestens zwei Komponenten: einer im internen Netzwerk und einer in der DMZ.

Die Komponente im internen Netzwerk (SecureZone) erlaubt den Zugriff über eine eigene API. Sie umfasst einen Tokenstore (Verwaltung der OAuth-Token), einen Clientstore (Verwaltung der API-Keys) und einen OAuth Validation Point (OVP). Die Komponente in der DMZ stellt Endpunkte nach außen zur Verfügung, um z.B. OAuth-Token zu generieren und ruft die in der SecureZone angebotenen APIs selbständig auf, um z.B. Validierungen durchführen zu lassen.

Firmen mit externen Mitarbeitern, welche eingeschränkten Zugriff auf interne Daten haben sollen, sind im Besonderen Kandidaten für eine derartige Integration. Externe Mitarbeiter besitzen in der Regel bereits mobile Endgeräte, welche mit der Installation einer geeigneten Software leicht integriert wenden können. So lässt sich der sonst hohe Aufwand zusätzliche Hardware vorzuhalten vermeiden.

Die fiktive Firma ACME Warehouse beschäftigt Mitarbeiter, die zeitweise ausserhalb der Firmengebäude bei Kunden oder zu Hause arbeiten. ACME Warehouse beschliesst Applikationen (Apps) zu entwickeln, welche API-Keys verwenden und diese den Mitarbeitern zur Verfügung zu stellen.

ACME Warehouse beschafft einen API Proxy und positioniert diesen in der DMZ. Es wird zunächst eine App entwickelt, die Zugriff auf Produkt-Dokumentationen erlaubt (DokuApp). Mithilfe des API Proxy kann OAuth für die Authorisierung der Apllikationen genutzt werden. Der verwendete API Key wird genutzt, um Zugriffsrechte zu regeln.

Das Artikelbild zeigt die Struktur der beteiligten Komponenten. Im ersten Schritt verbindet sich DokuApp mit den OAuth-Endpunkten. An diesen Endpunkten werden OAuth-Token erstellt, ausgegeben und validiert.

Ausserdem wird der Benutzer von DokuApp dazu aufgefordert, sich zu authentisieren, bevor er DokuApp authorisiert. Der API Proxy verbindet sich dazu mit dem internen Identity-Management-System, mit dem Clientstore (Datenbank der gültigen API-Keys) und dem Tokenstore (Datenbank aller OAuth-Token).

Sobald DokuApp einen access_token erhalten hat, verbindet sich die Anwendung über den DokuServerProxy Endpunkt mit dem DokuServer. Der API Proxy stellt dabei sicher, dass der access_token gültig und der Zugriff authorisiert ist. ACME Warehouse braucht nun keine Endgeräte mehr zu verwalten, sondern nur noch Applikationen. Der Verwaltungs- und Kontrollaufwand wird um ein Vielfaches reduziert.

Zusammenfassung

Der Schlüssel zur erfolgreichen und sicheren Einführung sowie Verwaltung von APIs ist die Wahl des richtigen API Proxies. Ist die Infrastruktur einmal erstellt und wurde der API Proxy für die eigenen Bedürfnisse konfiguriert, lassen sich APIs anbieten, API-Keys verwalten und benutzerfreundliche Möglichkeiten in Bezug auf Datenzugriff und Freigabenverwaltung realisieren.

Neben der so möglichen Unterstützung des Einsatzes mobiler Endgeräte eignen sich APIs auch für die sichere Einbindung von BYOD-Geräten in ein Firmennetzwerk und tragen damit zur Verbreitung dieses Ansatzes bei. OAuth ist darüber hinaus direkt verwendbar. API-Keys und OAuth kommen heutzutage bereits bei praktisch allen bekannten Plattformen wie Google, Facebook oder auch Twitter zum Einsatz.

Sascha Preibisch arbeitet als Senior Software Developer bei Layer 7 Technologies.

(ID:33247980)