Sichern Sie Ihr API-Gateway mit NGINX App Protect WAF

NGINX | 26. Mai 2022

Thelen BlumSenior Product Marketing Manager, NGINX App Protect | F5

Mit der Umstellung von monolithischen Architekturen auf Microservices werden Anwendungen schneller entwickelt als je zuvor. Geschwindigkeit ist entscheidend, um wettbewerbsfähig zu bleiben, und APIs stehen im Mittelpunkt dieser rasanten Modernisierungsbemühungen. Doch die Beliebtheit von APIs bei der Anwendungsmodernisierung hat erhebliche Auswirkungen auf die Anwendungssicherheit. APIs sind anfällige Angriffsziele, da sie Anwendungslogik und sensible Daten für andere Anwendungen oder Dritte zugänglich machen. Mit der zunehmenden API-Nutzung wächst auch der Bedarf an API-Gateways.

Laut dem F5-Bericht „State of Application Strategy 2021“ nutzen Unternehmen verschiedene Methoden zur Modernisierung, wobei APIs bei diesen Modernisierungsmaßnahmen an erster Stelle stehen:

58 % fügen eine API-Schicht hinzu, um moderne Benutzeroberflächen zu ermöglichen
51 % fügen moderne Anwendungskomponenten hinzu (zum Beispiel Kubernetes)
47 % führen ein Refactoring durch (sie ändern den Anwendungscode selbst)
40 % migrieren in die Public Cloud (Lift-and-Shift), ohne zu modernisieren

Horizontales Balkendiagramm, das den prozentualen Anteil der Unternehmen zeigt, die auf vier verschiedene Arten modernisieren

Mit zunehmendem Wachstum können Unternehmen API-Risiken durch den Einsatz eines API-Gateways mindern. Im aktualisierten 2022 State of Application Strategy Report von F5 zeigt sich, dass API-Gateways am besten am Netzwerkrand oder in dessen Nähe funktionieren. Dort können sie Angriffe abwehren, bevor diese das gesamte Netzwerk beeinträchtigen, und so mehrere APIs einheitlich und durchgängig schützen. API-Gateways kapseln die interne Struktur einer Anwendung und optimieren dadurch die Kommunikation zwischen Client und API. Anstatt bestimmte Dienste aufzurufen, stellen Clients einfach eine Verbindung zum API-Gateway her. Dadurch erhält der Client eine spezifische API, die Anzahl der Anfragen und Antworten zwischen Client und API wird reduziert und der Clientcode vereinfacht.

F5 NGINX-Kunden haben API-Gateways erfolgreich in verteilten Umgebungen bereitgestellt. Wenn Ihr API-Gateway jedoch nicht sicher ist, können sich Angreifer weiterhin Zugang verschaffen. NGINX bietet leistungsstarke Sicherheitstools, die dafür sorgen, dass Ihre Anwendungen hinter API-Gateways auch in dieser sich ständig verändernden Bedrohungslandschaft geschützt bleiben.

Mehr APIs bedeuten eine größere Angriffsfläche

APIs sind nichts Neues. Webbasierte APIs gibt es bereits seit den 1990er-Jahren, und Varianten von APIs existierten sogar schon vor dem Internet, wie wir es heute kennen, als Kommunikationsmittel zwischen kleinen, verteilten Netzwerken. Was wir heute erleben – und was die Spielregeln verändert hat –, sind moderne Architekturen, die APIs nutzen.

APIs spielen zwar eine entscheidende Rolle bei der Beschleunigung der Modernisierung, lassen sich zugleich jedoch immer leichter ausnutzen. In Microservices-Architekturen kann eine einzelne API über Hunderte von Endpunkten verfügen, und eine einzelne Anwendung kann aus zahlreichen Microservices bestehen, die über APIs miteinander verbunden sind. Dies unterscheidet sich von den monolithischen Anwendungen der Vergangenheit, bei denen nur ein einziger Zugangspunkt abgesichert werden musste. Da jeder Microservice mehrere Gruppen von API-Endpunkten bereitstellt, hat sich die potenzielle Angriffsfläche verzehnfacht.

Balkendiagramm zum Vergleich der durchschnittlichen Größe von Anwendungsportfolios in Unternehmen zwischen 2017 und 2022. Die durchschnittliche Größe liegt zwischen 200 und 1.000 Anwendungen, bei einer Spannweite von 1 bis über 3.000.

Der Bericht von F5 aus dem Jahr 2022 ergab außerdem, dass die meisten Unternehmen zwischen 200 und 1.000 Apps betreiben und 77 % Anwendungen in mehreren Clouds ausführen. Je mehr Apps und APIs einem Portfolio in verteilten Umgebungen hinzugefügt werden, desto größer ist die potenzielle Angriffsfläche.

Die 10 größten API-Sicherheitslücken laut OWASP

APIs sind typischerweise offen und können sensible Daten preisgeben. Das Open Web Application Security Project (OWASP) stellt in seinem Projekt „OWASP API Security Top 10“ die häufigsten Schwachstellen vor:

API1. Fehlerhafte Autorisierung auf Objektebene
API2. Fehlerhafte Benutzerauthentifizierung
API3. Übermäßige Offenlegung von Daten
API4. Fehlende Ressourcen- und Ratenbegrenzung
API5. Fehlerhafte Autorisierung auf Funktionsebene
API6. Massenzuweisung
API7. Sicherheitsfehlkonfiguration
API8. Einschleusung
API9. Unsachgemäße Verwaltung von Ressourcen
API10. Unzureichende Protokollierung und Überwachung

Unternehmen müssen heute agil und schnell sein, da sich die Entwicklungszyklen immer weiter verkürzen. Sicherheitslösungen müssen in dieser anfälligen, API-gesteuerten Umgebung anpassungsfähig und schlank sein und in die automatisierten Bereitstellungsprozesse einer API integriert werden.

Starten Sie Ihre API-Sicherheit mit F5 NGINX Plus

Aufsehenerregende API-Angriffe sorgen regelmäßig für Schlagzeilen. Im Jahr 2019 wurde beim Fahrdienstanbieter Uber eine kritische Schwachstelle in seiner API entdeckt – ein anfälliger API-Endpunkt ermöglichte es Angreifern, wertvolle Daten zu stehlen, darunter die Authentifizierungstoken von Fahrgästen. Glücklicherweise wurde diese Schwachstelle entdeckt, bevor Schaden entstehen konnte. Im Jahr 2021 hatte LinkedIn weniger Glück – aufgrund einer API-Schwachstelle verschafften sich Hacker Zugriff auf die Daten von über 700 Millionen LinkedIn-Nutzern, die anschließend im Darknet zum Verkauf angeboten wurden.

Durch die Bereitstellung von F5 NGINX Plus als API-Gateway können Sie sich in dieser schnelllebigen API-Landschaft eine hohe Performance bei API-Routing und -Bereitstellung sichern. GigaOm, ein unabhängiges Technologie-, Forschungs- und Analyseunternehmen, verglich NGINX in einem Benchmark mit anderen API-Gateway-Lösungen. Die Benchmark-Ergebnisse zeigten, dass NGINX 30.000 Anfragen pro Sekunde bei einer Latenz von weniger als 30 ms verarbeiten konnte. Damit ist die Latenz 1000-mal niedriger als bei den API-Gateways von Hyperscalern.

NGINX Plus bietet standardmäßig nicht nur Schutz vor OWASP-API-Schwachstellen, sondern umfasst darüber hinaus Sicherheitsprüfungen auf fehlerhafte Cookies sowie fehlerhaftes JSON und XML und validiert zulässige Dateitypen und Antwortstatuscodes. Es gewährleistet die Einhaltung der HTTP-RFCs und erkennt Verschleierungstechniken, mit denen Angriffe getarnt werden.

NGINX Plus leitet API-Anfragen schnell weiter, authentifiziert und autorisiert dabei API-Clients zum Schutz Ihrer APIs und begrenzt die Anfragerate, um Ihre API-basierten Dienste vor Überlastung zu schützen. Diese Tools schützen Ihre APIs außerdem vor den zehn größten OWASP-API-Sicherheitsrisiken:

Authentifizierungs- und Autorisierungsmechanismen – Stellen Sie sicher, dass nur Clients mit den entsprechenden Zugriffsrechten Ihre APIs nutzen können. Ein solcher Mechanismus sind Claims in JSON Web Tokens (JWTs). Damit werden mehrere Schwachstellen aus den OWASP API Security Top 10 adressiert: Fehlerhafte Autorisierung auf Objektebene (API1), Fehlerhafte Benutzerauthentifizierung (API2), Fehlerhafte Autorisierung auf Funktionsebene (API5) und Unzureichende Protokollierung und Überwachung (API10).
Richtlinien zur Ratenbegrenzung – Schützen Sie Ihre APIs vor Überlastung und mindern Sie DDoS-Angriffe, indem Sie die Anzahl der Anfragen begrenzen, die das API-Gateway innerhalb eines festgelegten Zeitraums von jedem API-Client akzeptiert. Mit NGINX Plus können Ratenbegrenzungen quellenspezifisch festgelegt werden (beispielsweise anhand des Werts eines JWT-Claims), sodass legitime Benutzer nicht beeinträchtigt werden. Dies trägt dazu bei, die Schwachstelle Fehlende Ressourcen und Ratenbegrenzung (API4) zu beheben.

Schützen Sie Ihre APIs mit F5 NGINX App Protect WAF

Die Absicherung Ihres API-Gateways mit F5 NGINX App Protect WAF bietet zusätzliche API-Sicherheit und schützt vor OWASP-Angriffen wie Injection (API8). Im Gegensatz zu anderen Anbietern von API-Gateways und API-Management, die nur ein Mindestmaß an Schutz vor OWASP-API-Risiken bieten, stellt NGINX App Protect WAF zusätzlichen Schutz vor Schwachstellen wie Remote Code Execution (RCE), Cross-Site Scripting (XSS) und anderen Angriffsvektoren bereit. NGINX App Protect WAF sorgt außerdem für die erforderliche Transparenz bei Angriffen im Zusammenhang mit unzureichender Protokollierung und Überwachung (API10). Diese protokollierten Angriffsdaten können zur weiteren Analyse an SIEM-Systeme (Security Information and Event Management) oder andere Data Lakes des Kunden gesendet werden.

Wenn Sie NGINX Plus als API-Gateway und Load Balancer verwenden (um APIs weiterzuleiten, die im Internet sowie für externe Entwickler und Partner zugänglich sein müssen), ist dies der ideale Ort für den Einsatz von NGINX App Protect WAF. Da der API-Datenverkehr eine Station weniger durchläuft, lässt sich der Schutz mit minimaler Komplexität und geringstmöglicher Latenz hinzufügen.

Gemäß den PCI-Compliance-Anforderungen für den Umgang mit sensiblen Daten (personenbezogenen Daten [PII]) in bestimmten Branchen müssen die Nutzdaten über offene, öffentliche Netzwerke hinweg durchgängig verschlüsselt sein. Wenn sich NGINX App Protect WAF am API-Gateway hinter einem Load Balancer oder CDN befindet, bleiben die Nutzdaten vollständig verschlüsselt, bis sie am API-Gateway entschlüsselt werden. So können Ihre APIs geschützt bleiben und gleichzeitig die Anforderungen für den Umgang mit sensiblen Daten erfüllen.

Mehrschichtiger Schutz mit F5 NGINX App Protect WAF

Topologiediagramm mit drei Optionen für die Bereitstellung von NGINX App Protect WAF mit API-Gateways

Möglicherweise verwenden Sie einen Load Balancer, auf dem eine WAF – beispielsweise F5 Advanced WAF – ausgeführt wird. Dahinter haben Sie ein API-Gateway bereitgestellt. Warum benötigen Sie also eine WAF auf Ihrem API-Gateway, wenn Sie bereits eine auf Ihrem Load Balancer haben?

Ein wesentlicher Vorteil des Wechsels von einer Load-Balancer-WAF-Kombination am Netzwerkrand zu einer API-Gateway-WAF-Kombination innerhalb Ihrer Umgebung besteht in einer strengeren und granulareren Kontrolle der Sicherheit. Die Verantwortung für die Sicherheit kann an ein API-Team übertragen werden, damit die Richtlinien gezielter auf APIs zugeschnitten werden können.

Mit diesem zweistufigen Ansatz können Sie sicherstellen, dass Ihre APIs selbst bei schnellsten API-Entwicklungs- und Release-Zyklen geschützt bleiben.

Positive Sicherheit durch OpenAPI-Schemavalidierung hinzufügen

Ein zentraler Bereich, in dem der Schutz API-spezifisch sein muss, ist die Validierung von Swaggers OpenAPI-Spezifikation. OpenAPI-Schemata sind für jede API einzigartig und ändern sich mit jeder API-Version. Bei einem Schutz, der auf dem OpenAPI-Schema einer API basiert, kann nicht darauf gewartet werden, dass ein IT-Team die Sicherheitskontrollen der von ihm verwalteten zentralen WAF aktualisiert, da dies eine Genehmigung und sorgfältige Tests erfordert, um unerwartete Auswirkungen auf andere APIs und Anwendungen zu vermeiden.

NGINX App Protect WAF kann OpenAPI-Schemata validieren und überprüfen, ob Anfragen den von der API unterstützten Vorgaben entsprechen (Methoden, Endpunkte, Parameter usw.). Daher ist es ideal, NGINX App Protect WAF am API-Gateway hinter einer zentralisierten WAF am Load Balancer für Positiv-Sicherheit einzusetzen.

„Security as Code“, um mit API-Bereitstellungen Schritt zu halten

CI/CD-Pipelines sind auf Geschwindigkeit ausgelegt, nicht auf Sicherheit. APIs werden zudem häufiger veröffentlicht als frühere Anwendungen. Deshalb beobachten wir in der API-getriebenen Landschaft eine Shift-Left-Bewegung. Durch die Verlagerung nach links, also die frühere Anwendung von Sicherheitskontrollen im Lebenszyklus der Anwendungsentwicklung, entwickelt sich DevOps hin zu einer DevSecOps-Kultur, in der Sicherheit wie Code behandelt wird.

Symbol mit Unendlichkeitszeichen, das den DevSecOps-Workflow darstellt

Unabhängig davon, ob Sie eine WAF am API-Gateway, am Load Balancer oder an beiden Stellen einsetzen, müssen WAF-Konfigurationen automatisiert bereitgestellt werden, um mit Änderungen an API-Versionen Schritt zu halten. Wenn Unternehmen eine Shift-Left-Kultur etablieren und „Security as Code“ in die CI/CD-Pipeline integrieren, kann Sicherheit in jede Phase der Anwendungs- und API-Entwicklung eingebettet werden, anstatt sie erst nachträglich hinzuzufügen.

Die Nutzung von Sicherheitsrichtlinien und -konfigurationen als Code bietet viele Vorteile:

Code kann problemlos aus einem Quellcode-Repository abgerufen werden.
Ihr SecOps-Team kann deklarative Sicherheitsrichtlinien erstellen und pflegen, um sicherzustellen, dass die zum Schutz des Unternehmens erforderlichen Kontrollen vorhanden sind.
Deklarative Richtlinien können wiederholt in neue Apps und APIs einprogrammiert werden.
Sicherheit wird in der CI/CD-Pipeline automatisiert.

Bei der Automatisierung des API-Schemas müssen bei jeder Aktualisierung einer API auch die Konfiguration und der Code in der entsprechenden Datei aktualisiert werden. Auch hier ist Automatisierung der Schlüssel. Sobald eine Shift-Left- oder „Security First“-Philosophie vollständig etabliert ist, können Entwickler diesen Code einfach aus dem Repository abrufen – und so agil bleiben, die Entwicklungsgeschwindigkeit erhöhen und die Markteinführungszeit verkürzen.

Leistungsstarker Schutz für Ihre APIs

Unabhängig davon, wo Sie eine WAF zum Schutz Ihrer APIs einsetzen, sind hohe Leistung und geringe Latenz unverzichtbar, damit Ihre APIs schnell auf Kundenanfragen reagieren und so ein besseres Benutzererlebnis bieten können. Die schlanke Architektur der WAF von NGINX App Protect ermöglicht diese hohe Leistung und geringe Latenz bei einem äußerst geringen Rechenressourcenbedarf in der Cloud.

In seinem „Bericht über Hochleistungs-Anwendungssicherheitstests“ stellt GigaOm die Ergebnisse der Leistungstests von NGINX App Protect WAF, AWS WAF, Azure WAF und der Open-Source-WAF ModSecurity vor. GigaOm stellte fest, dass NGINX App Protect WAF eine 4,7-mal niedrigere Latenz als die ModSecurity OSS WAF auf NGINX und eine 128-mal niedrigere Latenz als AWS WAF bei Anwendungen mit hohen Leistungsanforderungen aufweist.

NGINX ist der einzige Anbieter, der eine WAF in ein NGINX-API-Gateway integriert, sodass der API-Datenverkehr einen Hop weniger durchlaufen muss. Weniger Hops zwischen den Schichten reduzieren Latenz, Komplexität und potenzielle Fehlerquellen. Dies steht in deutlichem Gegensatz zu typischen API-Management-Lösungen, die keine WAF integrieren. Bei diesen müssen Sie die WAF separat bereitstellen, und nach der Einrichtung muss der API-Datenverkehr die WAF und das API-Gateway getrennt durchlaufen. Die enge Integration von NGINX ermöglicht hohe Leistung ohne Abstriche bei der Sicherheit.

Fazit

Bei NGINX bieten wir mit NGINX Plus und NGINX App Protect WAF zuverlässige API-Sicherheit. Dank der schlanken Skalierbarkeit von NGINX und der Robustheit der Advanced-WAF-Engine von F5 können Sie sich zuversichtlich in die API-gesteuerte Welt begeben – in dem Wissen, dass Ihre modernen Anwendungen sicher sind.

Getreu den Grundwerten von NGINX ist NGINX App Protect WAF eine moderne Software-Sicherheitslösung für Anwendungen, die plattformunabhängig ist und sich nahtlos in gängige DevOps-Toolchains integrieren lässt, um Reibungsverluste zu beseitigen und sichere Bereitstellungen zu beschleunigen. Dank deklarativer Konfigurationsmöglichkeiten kann die Sicherheit als Teil der CI/CD-Pipeline und des gesamten Softwareentwicklungslebenszyklus (SDLC) automatisiert werden. Dies trägt nicht nur dazu bei, die Veröffentlichungsgeschwindigkeit zu erhöhen, sondern unterstützt Unternehmen auch dabei, zuverlässige und geschützte APIs zu entwickeln, Lücken zwischen DevOps- und SecOps-Teams zu schließen und einen kulturellen Wandel hin zu DevSecOps zu ermöglichen.

Möchten Sie NGINX App Protect WAF selbst ausprobieren? Starten Sie noch heute eine kostenlose 30-tägige Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.