BLOG | NGINX

Sichern Sie Ihr API-Gateway mit NGINX App Protect WAF

NGINX-Teil-von-F5-horiz-schwarz-Typ-RGB
Thelen Blum Miniaturbild
Thelen Blum
Veröffentlicht am 26. Mai 2022
Daphne Won Miniaturbild
Daphne Won
Veröffentlicht am 26. Mai 2022

Da Monolithen zu Microservices werden, werden Anwendungen schneller entwickelt als je zuvor. Um wettbewerbsfähig zu bleiben, ist Geschwindigkeit erforderlich und APIs stehen bei diesen schnellen Modernisierungsbemühungen im Mittelpunkt. Die Beliebtheit von APIs zur Anwendungsmodernisierung hat jedoch erhebliche Auswirkungen auf die App-Sicherheit. APIs sind anfällige Angriffsziele, da sie Anwendungslogik und vertrauliche Daten anderen Apps oder Dritten preisgeben. Mit der zunehmenden API-Nutzung steigt auch der Bedarf an API-Gateways.

Laut dem State of Application Strategy Report 2021 von F5 nutzen Unternehmen verschiedene Methoden zur Modernisierung, und APIs stehen bei diesen Modernisierungsbemühungen an der Spitze:

  • 58 % fügen eine API-Ebene hinzu, um moderne Benutzeroberflächen zu ermöglichen
  • 51 % fügen moderne Anwendungskomponenten hinzu (z. B. Kubernetes)
  • 47 % führen ein Refactoring durch (Änderung des Anwendungscodes selbst)
  • 40 % migrieren in die öffentliche Cloud (Lift and Shift), ohne zu modernisieren

Horizontales Balkendiagramm, das den Prozentsatz der Organisationen zeigt, die auf vier verschiedene Arten modernisieren

Wenn Unternehmen wachsen, können sie API-Risiken durch die Einführung eines API-Gateways mindern. Im aktualisierten State of Application Strategy Report 2022 von F5 stellen wir fest, dass API-Gateways am Rand oder in dessen Nähe die beste Leistung erbringen. Hier können API-Gateways Angriffe stoppen, bevor sie das gesamte Netzwerk beeinträchtigen, und bieten so einen einheitlichen und konsistenten Schutz für mehrere APIs. API-Gateways kapseln die interne Struktur einer App und optimieren so die Kommunikation zwischen Client und API. Anstatt bestimmte Dienste aufzurufen, stellen Clients einfach eine Verbindung zum API-Gateway her. Dies stellt dem Client eine spezifische API zur Verfügung, reduziert die Anzahl der Roundtrips zwischen Client und API und vereinfacht den Clientcode.

F5 NGINX-Kunden haben API-Gateways erfolgreich in verteilten Umgebungen bereitgestellt. Aber auch wenn Ihr API-Gateway nicht sicher ist, können böswillige Akteure trotzdem durchkommen. Bei NGINX verfügen wir über leistungsstarke Sicherheitstools, um sicherzustellen, dass Ihre Apps hinter API-Gateways in dieser sich ständig verändernden Landschaft sicher bleiben.

Mehr APIs bedeuten mehr Angriffsfläche

APIs sind nichts Neues. Webbasierte APIs gibt es schon seit den 1990er-Jahren. Und API-Versionen gab es bereits vor dem heutigen Internet, nämlich als Kommunikationsplattform zwischen kleinen, verteilten Netzwerken. Was wir jetzt sehen – und was die Spielregeln geändert hat – sind die modernen Architekturen, die APIs verwenden.

APIs spielen eine entscheidende Rolle bei der Beschleunigung der Modernisierung und lassen sich gleichzeitig immer einfacher nutzen. In Microservices-Architekturen kann eine einzelne API Hunderte von Endpunkten haben und eine einzelne Anwendung kann aus vielen Microservices bestehen, die APIs verwenden, um sich miteinander zu verbinden. Dies unterscheidet sich von monolithischen Apps der Vergangenheit, bei denen nur ein Einstiegspunkt gesichert werden musste. Da jeder Mikrodienst mehrere Sätze von API-Endpunkten offenlegt, hat sich die potenzielle Angriffsfläche verzehnfacht.

Der F5-Bericht von 2022 ergab außerdem, dass die meisten Organisationen zwischen 200 und 1.000 Apps haben 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 Ihre mögliche Angriffsfläche.

Die 10 größten Sicherheitslücken in der OWASP API-Sicherheit

APIs sind typischerweise offen und können vertrauliche Daten offenlegen. Das Open Web Application Security Project (OWASP) hebt die häufigsten Schwachstellen in seinem Projekt OWASP API Security Top 10 hervor:

API1. Autorisierung auf Ebene defekter Objekte
API2. Fehlerhafte Benutzerauthentifizierung
API3. Übermäßige Datenfreigabe
API4. Mangel an Ressourcen und Ratenbegrenzung
API5. Beschädigte Funktionsebenenautorisierung
API6. Massenzuordnung
API7. Sicherheitsfehlkonfiguration
API8. Injektion
API9. Unsachgemäße Vermögensverwaltung
API10. Unzureichende Protokollierung und Überwachung

 

Moderne Unternehmen sind aufgrund der immer kürzeren Entwicklungszyklen auf Agilität und Geschwindigkeit angewiesen. Sicherheitslösungen in dieser anfälligen, API-gesteuerten Landschaft müssen anpassungsfähig und leichtgewichtig sein und als Teil der 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 in der API des Mitfahrunternehmens Uber ein kritischer Fehler entdeckt – ein anfälliger API-Endpunkt ermöglichte es böswilligen Akteuren, wertvolle Daten zu stehlen, darunter auch die Authentifizierungstoken der Fahrgäste. Glücklicherweise wurde dieser Fehler entdeckt, bevor Schaden entstand. Im Jahr 2021 hatte LinkedIn nicht so viel Glück – aufgrund einer API-Schwachstelle erbeuteten Hacker Daten von über 700 Millionen LinkedIn-Benutzern , die dann im Dark Web zum Verkauf angeboten wurden.

Indem Sie F5 NGINX Plus als Ihr API-Gateway einsetzen , können Sie diese schnelle API-Landschaft mit hoher Leistung beim Umgang mit API-Routing und -Bereitstellung betreten. GigaOm, ein unabhängiges Technologieforschungs- und -analyseunternehmen, hat NGINX mit anderen API-Gateway-Lösungen verglichen . Die Benchmark-Ergebnisse zeigten, dass NGINX 30.000 Anfragen pro Sekunde mit einer Latenz von weniger als 30 ms liefern konnte, was einer 1000-mal geringeren Latenz entspricht als bei den API-Gateways der Hyperscaler.

NGINX Plus bietet sofort einsatzbereiten Schutz nicht nur vor OWASP-API-Schwachstellen – sein zusätzlicher Sicherheitsschutz umfasst auch Prüfungen auf fehlerhafte Cookies, JSON und XML und validiert zulässige Dateitypen und Antwortstatuscodes. Es gewährleistet die Einhaltung von HTTP-RFCs und erkennt Umgehungstechniken, die zum Maskieren von Angriffen verwendet werden.

NGINX Plus leitet API-Anfragen schnell weiter, authentifiziert und autorisiert API-Clients, um Ihre APIs zu sichern, und begrenzt den Datenverkehr, um Ihre API-basierten Dienste vor Überlastung zu schützen. Diese Tools schützen Ihre APIs auch vor den zehn häufigsten Sicherheitslücken in der OWASP API-Sicherheit:

  • Authentifizierungs- und Autorisierungsmechanismen – Stellen Sie sicher, dass nur Clients mit den richtigen Zugriffsrechten Ihre APIs nutzen können. Ein solcher Mechanismus sind Ansprüche in JSON Web Tokens (JWTs). Dadurch werden mehrere Schwachstellen in den OWASP API Security Top 10 behoben: Beschädigte Autorisierung auf Objektebene (API1), beschädigte Benutzerauthentifizierung (API2), beschädigte Autorisierung auf Funktionsebene (API5) und unzureichende Protokollierung und Überwachung (API10).
  • Richtlinien zur Ratenbegrenzung – Schützen Sie Ihre APIs vor Überlastung und mildern Sie DDoS-Angriffe, indem Sie eine Begrenzung für die Anzahl der Anfragen festlegen, die das API-Gateway innerhalb eines definierten Zeitraums von jedem API-Client akzeptiert. Mit NGINX Plus können Ratenbegrenzungen spezifisch für die Quelle sein (beispielsweise basierend auf dem Wert eines JWT-Anspruchs), sodass gültige Benutzer nicht beeinträchtigt werden. Dies trägt dazu bei, die Sicherheitslücke „Ressourcenmangel und Ratenbegrenzung“ (API4) zu schließen.

Stärken Sie Ihre APIs mit F5 NGINX App Protect WAF

Die Sicherung 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 API-Gateway- und Verwaltungsanbietern, die nur das absolute Minimum an OWASP-API-Schutz bieten, liefert NGINX App Protect WAF zusätzlichen Schutz vor Schwachstellen wie Remote Code Execution (RCE), Cross-Site Scripting (XSS) und anderen Angriffsmethoden. NGINX App Protect WAF bietet außerdem die erforderliche Angriffstransparenz für unzureichende Protokollierung und Überwachung (API10). Diese protokollierten Angriffsdetails können zur weiteren Analyse an SIEM-Systeme (Security Information and Event Management) oder andere Datenspeicher des Kunden gesendet werden.

Wenn Sie NGINX Plus als API-Gateway und Lastenausgleich verwenden (zum Routing von APIs, die dem Internet zugänglich gemacht werden müssen, sowie für externe Entwickler und Partner), ist dies der ideale Ort, um NGINX App Protect WAF zum Schutz bereitzustellen. Da ein Hop weniger für den API-Verkehr erforderlich ist, kann der Schutz mit geringster Komplexität und geringster Latenz hinzugefügt werden.

Gemäß den PCI-Konformitätsanforderungen für den Umgang mit sensiblen Daten (persönlich identifizierbare Informationen [PII]) in bestimmten Branchen muss die Nutzlast in offenen, öffentlichen Netzwerken durchgängig verschlüsselt werden. Wenn sich NGINX App Protect WAF am API-Gateway hinter einem Load Balancer oder CDN befindet, bedeutet dies, dass die Nutzlast vollständig verschlüsselt bleibt, bis sie am API-Gateway entschlüsselt wird. So bleiben Ihre APIs geschützt und erfüllen gleichzeitig die Anforderungen für den Umgang mit sensiblen Daten.

Mehrschichtiger Schutz mit F5 NGINX App Protect WAF

Topologiediagramm der drei Optionen zur Bereitstellung von NGINX App Protect WAF mit API-Gateways

Möglicherweise verfügen Sie über einen Load Balancer und auf diesem Load Balancer über eine WAF wie etwa F5 Advanced WAF . 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 Hauptvorteil der Umstellung von einer Load Balancer-WAF-Kombination am Edge auf eine API-Gateway-WAF-Kombination innerhalb Ihrer Umgebung ist eine strengere und detailliertere Kontrolle über die Sicherheit. Die Verantwortung für die Sicherheit kann an ein API-Team übergeben werden, um die Richtlinien API-spezifischer zu gestalten.

Mit diesem zweistufigen Ansatz können Sie sicherstellen, dass Ihre APIs auch in den schnellsten API-Entwicklungs- und Releasezyklen geschützt bleiben.

Positive Sicherheit durch OpenAPI-Schemavalidierung

Ein wichtiger Bereich, in dem der Schutz API-spezifisch sein muss, ist die Validierung der OpenAPI-Spezifikation von Swagger. OpenAPI-Schemas sind für jede API einzigartig und ändern sich mit jeder API-Version. Schutz, der auf dem OpenAPI-Schema einer API basiert, kann nicht warten, bis ein IT-Team die Sicherheitskontrollen auf der von ihm verwalteten zentralisierten WAF aktualisiert. Dies erfordert eine Genehmigung und sorgfältige Tests, um unerwartete Auswirkungen auf andere APIs und Apps zu vermeiden.

NGINX App Protect WAF kann OpenAPI-Schemata validieren und überprüfen, ob die Anforderungen mit dem kompatibel sind, was die API unterstützt (Methoden, Endpunkte, Parameter usw.). Aus diesem Grund ist es ideal, wenn NGINX App Protect WAF positive Sicherheit am API-Gateway hinter einem zentralisierten WAF beim Load Balancer bietet.

„Sicherheit als Code“, um mit API-Bereitstellungen Schritt zu halten

CI/CD-Pipelines sind auf Geschwindigkeit ausgelegt, nicht auf Sicherheit. Darüber hinaus werden APIs häufiger veröffentlicht als Apps der Vergangenheit. Aus diesem Grund erleben wir in der API-gesteuerten Landschaft eine Verschiebung nach links . Durch „Shift Left“ bzw. das frühere Anwenden von Sicherheitskontrollen im Lebenszyklus der App-Entwicklung bewegt sich DevOps in Richtung einer DevSecOps -Kultur, in der Sicherheit als Code behandelt wird.

Symbol mit Unendlichkeitssymbol, das den DevSecOps-Workflow zeigt

Unabhängig davon, ob Sie eine WAF am API-Gateway, am Load Balancer oder an beiden platzieren, müssen WAF-Konfigurationen automatisiert bereitgestellt werden, um mit den API-Versionsänderungen Schritt zu halten. Wenn Unternehmen eine Shift-Left-Kultur einführen und „Sicherheit als Code“ in die CI/CD-Pipeline integrieren, kann Sicherheit in jede Phase der Anwendungs- und API-Entwicklung eingebaut werden, statt erst nachträglich hinzugefügt zu werden.

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

  • Code kann einfach 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 codiert werden.
  • Die Sicherheit wird in der CI/CD-Pipeline automatisiert.

Wenn Sie das API-Schema automatisieren, müssen Sie bei jeder Aktualisierung einer API auch die Konfiguration und den Code in dieser Datei aktualisieren. Auch hier ist Automatisierung der Schlüssel. Sobald die Shift-Left- oder „Sicherheit zuerst“-Philosophie vollständig übernommen ist, können Entwickler den Code problemlos aus dem Repository abrufen – und so ihre Agilität bewahren, die Geschwindigkeit erhöhen und die Markteinführungszeit verkürzen.

Hochleistungsschutz für Ihre APIs

Unabhängig davon, wo Sie eine WAF zum Schutz Ihrer APIs platzieren, sind hohe Leistung und geringe Latenz Anforderungen, die es Ihren APIs ermöglichen, schnell auf Kundenanfragen zu reagieren und so ein besseres Benutzererlebnis zu bieten. Die leichtgewichtige Architektur von NGINX App Protect WAF bietet diese hohe Leistung und geringe Latenz bei extrem geringem Rechenleistungsbedarf in der Cloud.

In seinem High-Performance Application Security Testing Report berichtet GigaOm über die Ergebnisse der Leistungstests für NGINX App Protect WAF, AWS WAF, Azure WAF und ModSecurity Open Source WAF. GigaOm hat festgestellt, dass NGINX App Protect WAF eine 4,7-mal geringere Latenz als ModSecurity OSS WAF auf NGINX und eine 128-mal geringere Latenz als AWS WAF für Anwendungen mit hohen Leistungsanforderungen aufweist.

NGINX ist der einzige Anbieter, der eine WAF in ein NGINX-API-Gateway einbettet, was zu einem Hop weniger für den API-Verkehr führt. Weniger Hops zwischen den Schichten verringern Latenz, Komplexität und Fehlerquellen. Dies steht in krassem Gegensatz zu typischen API-Verwaltungslösungen, die nicht in eine WAF integriert sind (Sie müssen die WAF separat bereitstellen und nach der Einrichtung muss der API-Verkehr die WAF und das API-Gateway separat durchlaufen). Die enge Integration von NGINX bedeutet hohe Leistung ohne Kompromisse bei der Sicherheit.

Abschluss

Bei NGINX bieten wir starke API-Sicherheit mit NGINX Plus und NGINX App Protect WAF. Dank der leichten Skalierbarkeit von NGINX und der Robustheit der Advanced WAF-Engine von F5 können Sie in die API-gesteuerte Welt einsteigen und sich darauf verlassen, dass Ihre modernen Apps sicher sind.

Getreu den Grundwerten von NGINX ist NGINX App Protect WAF eine moderne Anwendungssoftware-Sicherheitslösung, die plattformunabhängig ist und sich nahtlos in gängige DevOps-Toolchains integrieren lässt, um Reibungsverluste zu beseitigen und sichere Bereitstellungen zu beschleunigen. Mit deklarativen Konfigurationsfunktionen kann die Sicherheit als Teil der CI/CD-Pipeline und des gesamten Softwareentwicklungslebenszyklus (SDLC) automatisiert werden. Dies trägt nicht nur zu einer schnelleren Veröffentlichungsgeschwindigkeit bei, sondern unterstützt Unternehmen auch beim Aufbau zuverlässiger und geschützter APIs, während es gleichzeitig Lücken zwischen DevOps- und SecOps-Teams überbrückt und einen kulturellen Wandel hin zu DevSecOps ermöglicht.

Sind Sie bereit, NGINX App Protect WAF selbst auszuprobieren? Starten Sie noch heute eine kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .


„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."