Spezielle Sicherheitsprobleme API-Kommunikation von Microservices absichern

Microservices-Architekturen unterliegen anderen Sicherheitsrisiken als monolithische Architekturen. Deshalb ist es wichtig, sich mit diesen Themen zu beschäftigen, bevor man Microservices in seine IT-Umgebung integriert.

Anbieter zum Thema

Vogel IT-Akademie

OutSystems

Fastly GmbH

Mit Microservices lässt sich die Anwendungsentwicklung und bereitstellung in einen zügigen und nahtlosen Vorgang verwandeln. Riesige, monolithische Anwendungen zerfallen dadurch in eine Gruppe individueller und unabhängiger Dienste.

Solche Architekturen passen sehr gut zu iterativen und agilen Entwicklungsstrategien und werden technologisch durch Werkzeuge wie Containerisierung ermöglicht. Sie passen sehr gut zu unternehmerischen, API-basierten Anwendungsfällen und strukturell in die DevOps-Bewegung.

Viele der heutigen wachstumsstärksten Organisationen wie Netflix, Uber und Lyft haben den Sprung bereits gewagt: Entweder durch den Übergang auf Microservices oder durch ihren unmittelbaren Einsatz bei Anwendungsprogrammen von Anfang an.

Größere Angriffsfläche als Monolithen

Auf Microservices basierende Anwendungsprogramme unterscheiden sich stark von Anwendungen, die als einzelne große Monolithen implementiert sind. Nach dem Zergliedern einer Anwendung in einzelne Dienste wird den betreffenden Organisationen meist sehr schnell klar, dass sie damit möglicherweise die Büchse der Pandora geöffnet haben.

Mikrodienste können nämlich vertrauenswürdigen Kunden über APIs und Internet-Endpunkte direkten Zugriff auf interne Daten und Dienste ermöglichen. Dieser direkte Zugriff vergrößert die potenzielle Angriffsfläche, die deshalb gut gesichert werden muss.

Besonderheiten des API-Schutzes

Microservice-Anwendungen stützen sich für die interne Kommunikation sehr stark auf APIs. Deshalb ist es sinnvoll, einige dieser APIs nach außen freizugeben, und durch leistungsfähige Javascript-Clients Webseiten und Ansichten auf das Client-Gerät erstellen zu lassen. Das heißt also, der Schutz von APIs stellt eine ganz andere Herausforderung dar als das Sichern von normalem Internet-Datenverkehr.

Im Vergleich zu komplexen HTML-Vorgängen, die über HTTP-Datenverkehr laufen, lassen sich APIs verhältnismäßig einfach absichern. APIs sind strukturierter und bieten klar definierte Authentisierungs- und Berechtigungsmaßnahmen sowie klar definierte und leicht verständliche Abfrage- und Antwortformate.

Möglicherweise stellen APIs jedoch mehr Funktionen zur Verfügung und geben sensible interne Informationen preis. Deshalb ist es enorm wichtig, alle von außen zugänglichen APIs sorgfältig zu prüfen, um so die eventuell freigegebenen Daten sowie die mit ihnen interagierenden Systeme zu bestimmen.

In vielen Fällen ist es für die betreffenden Organisationen eher schwierig, ein intern verwendetes API nachträglich abzusichern. Stattdessen empfiehlt es sich, für die externe Kommunikation ein eigenes „bereinigtes“ API zu entwickeln und mit Sicherheitsfunktionen wie begrenzter Durchsatzrate (rate-limiting), Detail-Protokollierung und Abtrennungsmechanismen auszustatten.

APIs für externen Zugriff per Gateway absichern

Durch ein geeignetes API-Gateway, das einen einzigen Zugangspunkt zum System erlaubt, vermeidet man, dass Clients über ihren öffentlichen Endpunkt Anfragen direkt an jeden Microservice stellen. Dabei muss es sich keineswegs um ein spezielles Gerät handeln.

In vielen Anwendungsfällen können Organisationen einen intelligenten Reverse Proxy einsetzen, mit dem sie API-Anfragen prüfen und authentisieren sowie deren Datenrate einschränken können. Er stellt dann eine Art Pförtner dar, erlaubt nur Anfragen, die bestimmte Kriterien erfüllen und protokolliert alle Vorgänge.

Die entsprechenden Organisationen sollten sicherstellen, dass der gesamte API-Verkehr TLS-verschlüsselt ist (TLS = Transport Layer Security), und dass jeder API-Client sowohl eine Anwendungs-ID (einen API-Schlüssel oder ein anderes „Shared Secret“) als auch eine Nutzer-ID (ein SSL-Zertifikat oder OAuth-Token) verwendet. Bei anonymen API-Anfragen sollte außerdem eine eindeutige User-ID verwendet, die Datenrate beschränkt und der Datenverkehr protokolliert werden.

Interne Sicherheit einer Microservices-Anwendung

Man sollte die anderen Bestandteile der Anwendung stets kritisch betrachten. Auch wenn sie heute vollkommen vertrauenswürdig sind, so gibt es keine Garantie dafür, wie stark die Zahl der Clients der Anwendung in Zukunft wachsen wird.

Deshalb sollten die betreffenden Organisationen als Standard für die gesamte interne Kommunikation TLS einsetzen und eine Zertifikatsprüfung sowohl für Nutzer (Clients) als auch Anbieter (Server) von Grund auf in die Architektur einbauen. Die durch die verschlüsselten Verbindungen entstehenden Leistungseinbußen können durch Proxy-Beschleunigung minimiert werden.

Zur Sicherung des internen Datenverkehrs sollte für den gesamten Netzwerk-Datenverkehr SSL-Verschlüsselung zum Einsatz kommen. Dies kann über PKI, eine Public-Key-Infrastruktur, geschehen, womit eine fein abgestimmte Authentisierung und Zugangssteuerung für den gesamten internen Datenverkehr erzielt wird.

Owen Garrett, Head of Products bei NGINX.

Vor dem Wechsel auf Microservices müssen sich Unternehmen also gründlich mit den Sicherheitsaspekten einer solchen Infrastruktur auseinandersetzen und diese auch verstehen. Wenn alle diese Herausforderungen von Anfang an berücksichtigt werden, sind die Organisationen gut vorbereitet und können die Flexibilität und Skalierbarkeit von Microservices in vollem Umfang nutzen.

* Owen Garrett verfügt über mehr als 15 Jahre Erfahrung in Software-Technologie und Produkt-Management bei Unternehmen wie Riverbed und OnApp, wo er Technologien zur Software-Lastverteilung und Anwendungsbereitstellung entwickelte. Er hat diverse Patente im Bereich Software-Technologie angemeldet, unter anderem zum Routing von Netzwerk-Datenverkehr und zum Management von Client-Datenanfragen. Heute leitet Owen Garrett die Produkt- und Markteinführungsstrategie für die Web-Beschleunigungs- und Bereitstellungstechnologien von NGINX.

(ID:44944255)