

Es mag Sie überraschen, dass Sie durch Investitionen in die Verbesserung Ihrer Sicherheitslage mithilfe von Automatisierung und künstlicher Intelligenz (KI) letztlich weitaus mehr Geld sparen. In seinem Bericht „Cost of a Data Breach 2021“ zeigt das IBM Security-Team, dass eine Sicherheitsverletzung Unternehmen ohne Sicherheitsautomatisierung und KI im Durchschnitt ganze 80 % mehr kostet als Unternehmen, die Automatisierung und KI vollständig implementiert haben – 6,71 Millionen US-Dollar gegenüber 2,90 Millionen US-Dollar, also eine Differenz von 3,81 Millionen US-Dollar. Indem Unternehmen Sicherheitsautomatisierung und KI priorisieren, können sie Sicherheitsverletzungen schneller erkennen und eindämmen und so sowohl Geld als auch Zeit sparen.

(Quelle: Bericht zu den Kosten einer Datenschutzverletzung 2021)
Bei der Integration von Sicherheitsmaßnahmen in Ihre CI/CD-Pipeline ist es jedoch wichtig, Ihre Tools nicht zu überlasten. Je seltener Sie den Datenverkehr überprüfen, desto geringer ist die dadurch verursachte Latenz. Für das Unternehmen folgt daraus: Technische Komplexität ist der Feind der Agilität.
Bei F5 NGINX bieten wir eine Sicherheitsplattform, die sich durch ihre nahtlose Integration und ihre Fähigkeit auszeichnet, Teams dabei zu unterstützen, die Sicherheit im Softwareentwicklungszyklus „nach links zu verlagern“. Wenn Unternehmen „Security as Code“ in ihre CI/CD-Pipeline integrieren, ermöglichen sie die Automatisierung von Sicherheitsprozessen und den Einsatz von KI, was zu den von IBM beschriebenen enormen Einsparungen führt. Da Sicherheit in jede Phase der Anwendungs- und API-Entwicklung integriert ist, werden Konfigurations- und Sicherheitsrichtliniendateien als Code verarbeitet. So kann Ihr SecOps-Team eine deklarative Sicherheitsrichtlinie erstellen und pflegen, die DevOps bei der Entwicklung von Anwendungen verwendet. Dieselben Richtlinien lassen sich wiederholt auf neue Anwendungen anwenden, wodurch die Sicherheit in Ihrer CI/CD-Pipeline automatisiert wird.
Sehen wir uns das Ganze genauer an und betrachten wir drei Phasen der Datenverkehrsverarbeitung, in denen F5 NGINX App Protect und F5 NGINX Plus Sie bei der Automatisierung von Sicherheitsmaßnahmen unterstützen:
- Phase 1 – F5 NGINX App Protect DoS erkennt Denial-of-Service-Angriffe (DoS) und wehrt sie ab
- Phase 2 – F5 NGINX App Protect WAF schützt vor Angriffen gemäß OWASP Top 10 und bösartigen Bots
- Phase 3 – F5 NGINX Plus authentifiziert Anwendungs- und API-Clients und setzt Autorisierungsanforderungen mithilfe nativer Funktionen und Integrationen mit Single-Sign-on-Lösungen (SSO) von Drittanbietern durch

Diese dreiteilige Sicherheitslösung spart Ihnen auf zweierlei Weise Kosten, insbesondere in einer Public-Cloud-Umgebung:
- Nur legitimer Datenverkehr erreicht Ihre Anwendungen, da NGINX App Protect DoS den Datenverkehr von DoS-Angriffen herausfiltert und NGINX App Protect WAF anschließend mehrere Angriffsvektoren wie die OWASP Top 10 abwehrt.
- Dank seines hocheffizienten, ereignisgesteuerten Designs kann NGINX Plus bei geringer CPU-Auslastung eine enorme Anzahl von Anfragen pro Sekunde verarbeiten. Wenn auf einer hocheffizienten Plattform ausschließlich legitimer Anwendungsdatenverkehr verarbeitet wird, sind deutlich weniger Rechenressourcen erforderlich. Das spart Zeit und Geld und gewährleistet Schutz vor mehreren Angriffsvektoren, ohne Ihre Tools zu überlasten.
Wenn Sie derzeit F5 BIG-IP Advanced WAF verwenden, um Anwendungen in Ihrem Rechenzentrum zu schützen, können Sie NGINX Plus problemlos als Ingress-Controller für Kubernetes mit NGINX App Protect DoS und WAF ergänzen. So erhalten Sie eine umfassende Lösung, mit der Sie Ihre modernen Anwendungen skalieren und schützen sowie Kubernetes-Anwendungen in der Cloud orchestrieren können. Mit dem Security-as-Code-Ansatz von F5 können Sie Infrastruktur- und Sicherheitsrichtlinienkontrollen über eine deklarative API oder deklarative Definitionen im JSON-Format in einer Datei als Code definieren. Außerdem können Sie BIG-IP-XML-Dateien in JSON-Dateien konvertieren. Ihre Richtlinien – die unternehmensweiten Standardsicherheitskontrollen, die von SecOps verwaltet und gepflegt werden – können in einem Code-Repository gespeichert werden, aus dem sie abgerufen und wie jeder andere Codebestandteil in Ihre Entwicklungspipeline integriert werden. Dieser Ansatz hilft DevOps und SecOps, betriebliche Lücken zu schließen und Anwendungen schneller, kostengünstiger und mit höherer Sicherheit auf den Markt zu bringen.
F5 integriert die Erstellung und Baseline-Definition von WAF-Richtlinien in den Entwicklungsprozess. Dies ist ein wichtiger Bestandteil des „Shift Left“ der Sicherheit in der Anwendungsentwicklungspipeline und der Automatisierung der Anwendungsbereitstellung.
Die Sichtbarkeitstools in BIG‑IP und NGINX ergänzen sich gegenseitig und ermöglichen es SecOps, Automatisierungsprozesse frühzeitig in Ihren DevOps-Lebenszyklus zu integrieren. Mit BIG‑IP können Teams XML-Dateien in JSON-Dateien konvertieren, die von NGINX verwendet werden, um einheitliche Sicherheitsrichtlinien aufrechtzuerhalten. Mit NGINX können Teams bereits vorhandene Anwendungen optimieren und zugleich moderne Automatisierung für die Anwendungssicherheit einsetzen, um künftigen Sicherheitsverletzungen und den Kosten solcher potenziellen Angriffe entgegenzuwirken.
Phase 1: NGINX App Protect DoS schützt vor DoS-Angriffen
Die erste Station auf unserem Weg zu einem sicheren Datenverkehrsmanagement ist das Herausfiltern von Denial-of-Service-Angriffen (DoS). Diese missbräuchlichen Zugriffe von Anfang an zu unterbinden, ist eine unverzichtbare erste Verteidigungslinie.
Wir haben bereits darauf hingewiesen, dass Angreifer zunehmend von herkömmlichen volumetrischen Angriffen abrücken und stattdessen HTTP- und HTTPS-Anfragen oder API-Aufrufe für Angriffe auf Layer 7 nutzen. Warum? Sie wählen den Weg des geringsten Widerstands. Infrastrukturtechniker haben über Jahre hinweg wirksame Abwehrmaßnahmen gegen Angriffe auf Layer 3 und Layer 4 entwickelt. Dadurch lassen sich solche Angriffe leichter abwehren und sind weniger erfolgversprechend. Angriffe auf Layer 7 können diese herkömmlichen Abwehrmaßnahmen umgehen.
Nicht alle DoS-Angriffe sind volumetrisch. Angriffe, die darauf ausgelegt sind, Serverressourcen durch „Low-and-Slow“-Methoden wie Slow POST oder Slowloris zu verbrauchen, lassen sich leicht im legitimen Datenverkehr verbergen. Open-Source-Frameworks für Remoteprozeduraufrufe über HTTP/2 wie gRPC bieten zwar die für moderne Anwendungen erforderliche Geschwindigkeit und Flexibilität, könnten aufgrund ihres typischerweise offenen Charakters jedoch anfälliger für DoS-Angriffe sein als proprietäre Protokolle.
Im Gegensatz zu herkömmlichen DoS-Schutzlösungen erkennt NGINX App Protect DoS heutige Angriffe mithilfe automatisierter Analysen des Benutzer- und Websiteverhaltens, proaktiver Integritätsprüfungen und einer konfigurationsfreien Einrichtung. Es handelt sich um eine Lösung mit geringer Latenz zur Abwehr gängiger Angriffe wie HTTP-GET-Floods, HTTP-POST-Floods, Slowloris, Slow Read und Slow POST.
Um diese Angriffe abzuwehren, müssen SecOps- und DevOps-Teams die Automatisierung von „Security as Code“ in ihren CI/CD-Workflow integrieren – als Teil des Shift-Left-Ansatzes. NGINX App Protect DoS ermöglicht dies. Die Lösung schützt moderne, verteilte Anwendungen und APIs mit fortschrittlichen Abwehrmechanismen vor DoS-Bedrohungen und trägt dazu bei, die bisweilen gegensätzlichen Prioritäten von SecOps und DevOps miteinander in Einklang zu bringen. Dazu unterstützt sie dieses Modell mit einem schlanken Softwarepaket, einer kontinuierlichen Feedbackschleife zur Bedrohungsabwehr und der Integration vertrauter DevOps-Tools über RESTful APIs.
NGINX App Protect DoS integriert die Technologie für maschinelles Lernen (ML), die im IBM Security-Bericht als entscheidend für erhebliche Kosteneinsparungen hervorgehoben wird. Die Lösung analysiert das Clientverhalten und den Zustand der Anwendung, um normale Datenverkehrsmuster zu modellieren. Sie erstellt mithilfe einzigartiger Algorithmen ein dynamisches statistisches Modell, das äußerst präzisen Schutz bietet, und setzt dynamische Signaturen ein, um Angriffe automatisch abzuwehren. Darüber hinaus misst sie kontinuierlich die Wirksamkeit der Abwehrmaßnahmen und passt sich an veränderte Verhaltensweisen oder Zustände der Anwendung an. Dank dieser Funktionen kann NGINX App Protect DoS DoS-Angriffe blockieren, bei denen jede einzelne Angriffsanfrage völlig legitim erscheint und ein einzelner Angreifer möglicherweise sogar weniger Datenverkehr erzeugt als ein durchschnittlicher legitimer Benutzer.

NGINX App Protect DoS und WAF
Phase 2: NGINX App Protect WAF schützt vor den OWASP Top Ten
Während der DoS-Schutz schädlichen Datenverkehr zuverlässig daran hindert, in Ihre Infrastruktur einzudringen, können Angriffe dennoch durchkommen. Deshalb benötigen Sie für die nächste Phase einer erfolgreichen Abwehr eine Web Application Firewall (WAF), die sich auf als legitim getarnten Datenverkehr böswilliger Akteure konzentriert.
Schlank und leistungsstark bietet NGINX App Protect WAF umfassenden Sicherheitsschutz, der Antworten überprüft, die Einhaltung des HTTP-Protokolls durchsetzt, Umgehungstechniken erkennt, Kreditkartennummern und andere sensible personenbezogene Daten mit Data Guard maskiert und auf unzulässige Metazeichen und Dateitypen, fehlerhaftes JSON und XML sowie sensible Parameter prüft. Zudem schützt die Lösung vor den Bedrohungen der aktualisierten OWASP Top 10:
Fehlerhafte Zugriffskontrolle
Kryptografische Fehler
Injection
Unsicheres Design
Fehlkonfiguration der Sicherheit
Anfällige und veraltete Komponenten
Fehler bei der Identifizierung und Authentifizierung
Fehler bei der Software- und Datenintegrität
Fehler bei der Sicherheitsprotokollierung und -überwachung
Serverseitige Anfragenfälschung
Es überrascht nicht, dass Cyberangriffe auf Schwachstellen aus den OWASP Top 10 wie etwa A03:2021 Injection weiterhin weitverbreitet sind. Im Juli 2021 gab die Open-Source-E-Commerce-Plattform WooCommerce bekannt, dass viele ihrer Plug-ins anfällig waren für SQL-Injection, und zu diesem Zeitpunkt fanden mehrere Angriffe statt. Da Unternehmen und Kunden überwiegend online agieren, ist es nachvollziehbar, dass sich Angreifer auf webbasierte Anwendungen konzentrieren. Diese sind häufig komplex, bestehen aus Microservices und erstrecken sich über verteilte Umgebungen, in denen zahlreiche APIs miteinander kommunizieren, wodurch sich die Anzahl der für Angriffe anfälligen Endpunkte erhöht.
Moderne Angriffe verändern sich ebenfalls und passen sich schnell an. Hier kommt KI ins Spiel, weshalb IBM ihre Bedeutung hervorgehoben hat. Wie bei NGINX App Protect DoS erleichtert das leistungsstarke ML-System in NGINX App Protect WAF den Platform-Ops-, DevOps- und SecOps-Teams den Austausch von Angriffstrends und Daten. Eine neue Funktion – das Adaptive Violation Rating – wird ML noch stärker nutzen, indem sie erkennt, wenn sich das Verhalten einer Anwendung ändert. Dank dieser ML-Funktion bewertet NGINX App Protect WAF kontinuierlich das prognostizierte Verhalten jeder Anwendung. Auf Grundlage dieser Erkenntnisse kann es Clientanfragen zulassen, die andernfalls blockiert würden. Dadurch sinkt der Violation-Rating-Wert einer Anwendung, und Fehlalarme werden deutlich reduziert, was die Benutzererfahrung verbessert und zugleich die Verwaltungskosten senkt.
NGINX App Protect WAF bietet außerdem Schutz vor Bots. Heute stammen fast 50 % des Internetverkehrs von Bots. Durch das frühzeitige Herausfiltern von bekanntem schädlichem Datenverkehr kann NGINX App Protect WAF Bot-Datenverkehr mithilfe seiner Bot-Signaturdatenbank schnell blockieren.
Die frühzeitige Einführung einer WAF als Sicherheitsebene in Ihrer CI/CD-Pipeline trägt dazu bei, Sicherheitsrisiken zu minimieren. Da NGINX App Protect WAF CI/CD-freundlich ist, können Sie Sicherheit bereits frühzeitig als Code in Ihren Anwendungsentwicklungsprozess integrieren und automatisieren. Durch ein frühzeitiges Sicherheitsbewusstsein und die richtige Zusammenarbeit zwischen den Teams beseitigen Sie zudem Engpässe wie Bereitstellungsrisiken. Ein mehrstufiger DoS- und WAF-Schutz schafft zahlreiche Prüfpunkte, sodass Sicherheitsteams Einblick in die Nutzung der Anwendungen erhalten und Anwendungsteams nachvollziehen können, wie diese verwaltet werden.
Phase 3: NGINX Plus authentifiziert und autorisiert App- und API-Clients
Auch nachdem NGINX App Protect Dos und NGINX App Protect WAF schädlichen Datenverkehr herausgefiltert haben, müssen Sie weiterhin überprüfen, ob die Clients legitim und zum Zugriff auf die angeforderten Ressourcen berechtigt sind. Hier kommt NGINX Plus ins Spiel: Es übernimmt die Authentifizierung und Autorisierung und leitet die Anfragen anschließend an die entsprechenden Server weiter. Durch den Einsatz von NGINX Plus als API-Gateway können Sie einen einheitlichen Einstiegspunkt für mehrere APIs bereitstellen und so Ihren Stack weiter vereinfachen.
Authentifizierung und Autorisierung lassen sich auch mithilfe von Single Sign-on (SSO) automatisieren, sodass DevOps-Teams ihre gewünschte Agilität beibehalten können. NGINX Plus unterstützt OpenID Connect (OIDC), eine Identitätsschicht auf Basis des Protokolls OAuth 2.0. In der NGINX-Dokumentation erläutern wir, wie Sie mit OIDC SSO für Anwendungen aktivieren, die über NGINX Plus als Proxy bereitgestellt werden.

Aufgrund ihrer typischerweise offenen Struktur sind APIs anfällige Angriffsziele. In seinem Jahresbericht prognostizierte Gartner Research für 2022, dass APIs zum häufigsten Angriffsvektor werden und unzählige Datenschutzverletzungen bei Webanwendungen von Unternehmen verursachen würden. Diese Prognose bewahrheitet sich im Laufe des Jahres 2022, denn die API-Angriffsfläche in Unternehmen wächst weiterhin.
Der Bericht „API-Authentifizierungsvorfälle: Anwendungsschutzbericht 2020“ von F5 Labs nennt drei häufige Ursachen für API-Vorfälle:
- Keine Authentifizierung an API-Endpunkten
- Fehlerhafte API-Authentifizierung
- Fehlerhafte API-Autorisierung
Keine Authentifizierung an API-Endpunkten
Wenn Sie die Authentifizierung des API-Datenverkehrs implementieren, erhalten Clients, die ihre Identität erfolgreich nachweisen, ein Token von einem vertrauenswürdigen Identitätsanbieter. Der Client übermittelt anschließend bei jeder HTTP-Anfrage das Zugriffstoken. Bevor die Anfrage an die Anwendung weitergeleitet wird, stellt NGINX Plus die Authentifizierung und Autorisierung des Clients sicher, indem es das Token validiert und die darin codierten Identitäts- und sonstigen Daten (beispielsweise die Gruppenzugehörigkeit) extrahiert. Sofern das Token erfolgreich validiert wurde und der Client zum Zugriff auf die Ressource berechtigt ist, wird die Anfrage an den Anwendungsserver weitergeleitet. Für diese Validierung gibt es mehrere Methoden. OpenID Connect (basierend auf dem OAuth-2.0-Protokoll) ist jedoch eine gängige Möglichkeit, die Authentifizierung von API-Anfragen durch Drittanbieter zu ermöglichen.
Viele der auf dem Markt verfügbaren APIs sind jedoch auf der Authentifizierungsebene ungeschützt. Im Jahr 2021 wurde bekannt, dass die interaktive Fitnessplattform Peloton eine undichte API hatte. Ein Sicherheitsforscher entdeckte, dass nicht authentifizierte Anfragen an die API von Peloton möglich waren und sich so ohne Authentifizierung problemlos Benutzerdaten abrufen ließen. Peloton behob den Fehler zwar noch vor einer größeren Datenschutzverletzung, doch dieser Vorfall verdeutlicht, dass ein monolithischer Sicherheitsansatz der inhärenten Vielfalt von API-Strukturen und der daraus resultierenden Notwendigkeit, bei deren Schutz flexibel zu agieren, nicht gerecht wird.
Fehlerhafte API-Authentifizierung
APIs sind für die Kommunikation zwischen Computern konzipiert. Daher gehen viele DevOps-Teams davon aus, dass Menschen nicht mit dem API-Endpunkt kommunizieren. Ein Beispiel im Bericht von F5 Labs handelt von einem Forscher, der mehrere API-Anfragen miteinander verknüpfte, um sich Guthaben im Wert von Hunderttausenden Dollar in einer mobilen App zu „verdienen“. Die App generierte fortlaufend Token, die Missbrauch verhindern sollten, versah sie jedoch nicht mit einem Ablaufdatum, sodass sie immer wieder verwendet werden konnten.
Wenn Sie API-Authentifizierungstoken nicht ordnungsgemäß validieren, können Angreifer Schwachstellen in der API ausnutzen. Wird eine solche Schwachstelle nicht von einem Sicherheitsforscher, sondern von einem böswilligen Akteur entdeckt, kann dies ein ganzes Unternehmen gefährden.
Fehlerhafte API-Autorisierung
Eine fehlgeschlagene API-Authentifizierung führt zwangsläufig zu einer fehlerhaften API-Autorisierung. Der Bericht von F5 Labs beschreibt außerdem einen Vorfall, bei dem ein Fehler im Betriebssystem bösartige HTTP-Anfragen an die API ermöglichte und Angreifern so einfachen Zugriff auf Autorisierungstoken verschaffte. Sobald die Angreifer ein solches Autorisierungstoken erlangt hatten, verfügten sie über Administratorrechte.
NGINX bietet verschiedene Ansätze zum Schutz von APIs und zur Authentifizierung von API-Clients. Weitere Informationen finden Sie in der Dokumentation zu IP-adressbasierten Zugriffssteuerungslisten (ACLs), zur Authentifizierung mit digitalen Zertifikaten und zur HTTP-Basisauthentifizierung. Darüber hinaus unterstützt NGINX Plus nativ die Validierung von JSON Web Tokens (JWTs) für die API-Authentifizierung. Weitere Informationen finden Sie in unserem Blogbeitrag „Authentifizierung von API-Clients mit JWT und NGINX Plus“.
Starten Sie noch heute
Durch die Automatisierung von Sicherheitsprozessen wird Sicherheit zur gemeinsamen Verantwortung. Indem Ihr Unternehmen der Sicherheitsautomatisierung Priorität einräumt, kann es zuverlässigere Anwendungen entwickeln, Risiken minimieren, Betriebskosten senken und Releases schneller bereitstellen. So erhalten Ihre Microservices, Anwendungen und APIs eine agile Sicherheitslösung, die skalierbar und schnell genug ist, um mit dem heutigen Wettbewerb Schritt zu halten.
Diese dreistufige Sicherheitsstruktur sorgt zudem für einen optimalen Ablauf, da Ihre WAF nicht durch die Überprüfung des Datenverkehrs eines DoS-Angriffs ausgebremst werden soll und Sie keine wertvollen Ressourcen für die Authentifizierung und Autorisierung böswilliger Akteure verschwenden möchten. Indem Sie leicht erkennbare Angriffe frühzeitig abwehren, sparen Sie Zeit und Geld und können zugleich die Performance Ihrer Anwendungen steigern.
Möchten Sie NGINX Plus und NGINX App Protect selbst ausprobieren? Starten Sie noch heute eine kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.
Über die Autoren


Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.