In den letzten Jahren haben sich APIs zum De-facto-Standard für den Aufbau der modernen App-Ökonomie entwickelt. Diese Softwareschnittstellen sind heute das vorherrschende Mittel, um Systemen, Anwendungen und Geräten die Kommunikation und den Austausch einer enormen Bandbreite an Daten und Funktionen zu ermöglichen. Im Wesentlichen sind APIs zur modernen Seidenstraße für Informationen geworden und geben Kunden die Möglichkeit, Lösungen zu erschließen, die die besten Tools verschiedener Anbieter miteinander kombinieren.
Von den im Rahmen des jährlichen Connectivity Benchmark Report von MuleSoft befragten Unternehmen nutzen 80 % öffentliche und/oder private APIs. Zu den genannten Vorteilen zählen unter anderem eine höhere Produktivität (54 %), mehr Innovation (47 %) und Kosteneinsparungen (34 %). Laut der Umfrage generieren APIs zudem erhebliche Umsätze für die Unternehmen, die sie veröffentlichen – im Durchschnitt 31 % des Gesamtumsatzes.
Allerdings ist nicht alles rosig. Untersuchungen von F5 Labs ergaben, dass die Zahl der API-Sicherheitsvorfälle im ersten Halbjahr 2020 voraussichtlich die Gesamtzahl der Vorfälle aus den beiden Vorjahren übersteigen würde. Eine große Herausforderung für DevOps-Teams besteht darin, dass es bei der API-Sicherheit viele Schwachstellen gibt – vom vollständigen Fehlen einer Authentifizierung vor API-Endpunkten über fehlerhafte Authentifizierung und Autorisierung bis hin zu grundlegenden Fehlkonfigurationen.
Nun stellt sich die Frage: Wie sichern Sie Ihre gesamte API-Aktivität ab? In diesem Blog erläutern wir, warum ein auf „Security as Code“ basierender Ansatz mit NGINX App Protect entscheidend für den Schutz Ihrer APIs ist und sich nahtlos in Ihre CI/CD-Pipeline einfügt – zusammen mit Lösungen anderer Sicherheitsanbieter, auf die Sie sich bereits verlassen.
APIs dienen sowohl Mitarbeitern als auch Partnern
Laut ProgrammableWeb sind mehr als 20.000 private, Partner- und öffentliche APIs im Einsatz, die die Anwendungen ermöglichen, auf die wir uns täglich verlassen. Der Reiz von APIs – und damit auch von containerbasierten Microservices, in denen APIs ausgeführt werden oder mit denen sie verbunden sind – liegt darin, dass sie Ihre Softwarefunktionen und Daten einem breiten Nutzerkreis zugänglich machen können, darunter Ihren Mitarbeitern sowie all Ihren strategischen Partnern und Geschäftspartnern. (Dieser Ansatz ist natürlich auch für DevOps-Teams attraktiv, da sie gezielt die besten Anbieter für ihre jeweiligen Anforderungen auswählen können.)
Viele Unternehmen nutzen beispielsweise private APIs und Partner-APIs, um Self-Service-IT zu ermöglichen. Indem IT-Ressourcen auffindbar und wiederverwendbar gemacht werden, können mehr Mitarbeitende im Unternehmen mehr Aufgaben erledigen, ohne bei jedem Schritt auf DevOps angewiesen zu sein. Richtig umgesetzt führt Self-Service-IT zu mehr Agilität, einer schnelleren Markteinführung, kundenorientierten Lösungen unter Einbeziehung verschiedener Anbieter, höherer Effizienz und Innovationskraft sowie zu Umsätzen mit höheren Margen.
Diese Dynamik zeigt sich auch auf der Entwicklungs- und Produktionsseite: Containerisierte Software und APIs ermöglichen es dem DevOps-Team, mit einer Vielzahl von Partnern zusammenzuarbeiten. Dazu gehören Partner für Identitäts- und Zugriffsmanagement (IAM) wie Okta, AuthO und Microsoft sowie Partner für das Lebenszyklusmanagement wie MuleSoft, Akana und Kong.
Sicherheit als Code, Richtlinien als Schutz
In den heutigen schnelllebigen, dynamischen CI/CD-Umgebungen benötigen Entwickler und DevOps-Teams einen ganzheitlichen Ansatz zum Schutz von Webanwendungen und APIs, unterstützt durch Anwendungssicherheitstools, mit denen sie Lösungen implementieren und Software schnell und sicher bereitstellen können. Teams müssen ihren Code absichern und gleichzeitig eng mit den von ihnen gewählten Partnern für Zugriffs- und Lebenszyklusmanagement integriert bleiben.
Da sich DevOps in den letzten Jahren zu DevSecOps weiterentwickelt hat, gibt es verstärkte Bestrebungen, Sicherheit selbst als Code umzusetzen. Anders ausgedrückt: Unternehmen erkennen zunehmend, dass Sicherheit in jeden Aspekt neuer Software integriert werden muss, anstatt sie erst nach Abschluss der Programmierung nachträglich hinzuzufügen. Dazu gehören Praktiken wie:
- Sicherheitsmaßnahmen nach Möglichkeit automatisieren, indem sie direkt in die CI/CD-Pipeline integriert werden
- Sicherheit als Leitplanke statt als Zugangsschranke gestalten (also Orientierungshilfen und Tools bereitstellen, anstatt den Zugriff lediglich zu gewähren oder zu verweigern)
- Zusammenarbeit mit verschiedenen Partnern, um sicherzustellen, dass Sicherheitslösungen einheitlich, zentralisiert und per Self-Service verfügbar sind – für jede Umgebung, einschließlich verteilter, containerisierter Umgebungen
„Security as Code“ bedeutet, dass Sicherheit in jeden Aspekt neuer Software integriert wird, anstatt sie erst am Ende nachträglich hinzuzufügen.
Fortschrittliche API-Sicherheit für moderne Anwendungsinfrastrukturen
F5 ist ein starker Befürworter des Security-as-Code-Ansatzes, der Anwendungssicherheit anpassungsfähig, skalierbar und zuverlässig macht. NGINX App Protect spielt bei dessen Umsetzung eine wichtige Rolle. NGINX App Protect kombiniert API-Sicherheit mit grundlegenden Funktionen unserer marktführenden Advanced Web Application Firewall (Advanced WAF) und unseres Bot-Schutzes und unterstützt DevOps-Teams so bei Folgendem:
- Unterbrechungsfreie Sicherheitskontrollen (wie vom Sicherheitsteam autorisiert) in die Automatisierungs- und CI/CD-Prozesse integrieren
- Sicherheitskontrollen für Anwendungen in verteilten Umgebungen wie Containern und Microservices bereitstellen und verwalten
- Implementieren Sie kosteneffiziente Sicherheitskontrollen, ohne die Veröffentlichungsgeschwindigkeit oder die Anwendungsleistung zu beeinträchtigen
Mit NGINX App Protect stellen Sie Anwendungssicherheit als schlankes Softwarepaket bereit, das zudem unabhängig von der zugrunde liegenden Infrastruktur ist. So können Softwareentwickler deklarative Richtlinien („Security as Code“) nutzen, um den gesamten ein- und ausgehenden Datenverkehr eines API-Gateways oder eines anderen Ingress-Controllers abzusichern. Bei diesem Modell kann die Sicherheit mit NGINX App Protect an mehreren Punkten umgesetzt werden – am Ingress, innerhalb eines Kubernetes-Pods oder über mehrere Services hinweg –, selbst wenn eine API standardmäßig nicht sicher ist.
Durch die Zusammenarbeit mit anderen Branchenführern, die für unsere Kunden eine hohe Priorität haben, und die Einbindung der Anbieter und Produkte, die bereits von DevOps-Teams weltweit eingesetzt werden, setzen sich F5 und NGINX dafür ein, innovative Lösungen für das gesamte Anwendungsökosystem bereitzustellen.
Fazit
Da APIs zur neuen Seidenstraße für den Informationsaustausch werden und es ermöglichen, wie nie zuvor mit Ihren Benutzern in Kontakt zu treten, schützt NGINX App Protect Ihre Anwendungen und Daten vor dem gesamten Spektrum potenzieller Bedrohungen. NGINX App Protect ist auf die Art und Weise zugeschnitten, wie Sie Anwendungen bereitstellen, und ermöglicht unter anderem eine enge Integration in Ihr Partner-Ökosystem. Diese branchenführende Lösung funktioniert nahtlos in DevOps-Umgebungen und integriert unterbrechungsfreie Sicherheitskontrollen in die gesamte DevOps-Automatisierung und die CI/CD-Prozesse. So wird Anwendungssicherheit nicht erst nachträglich ergänzt oder als Übergangslösung aufgesetzt, sondern ist von Anfang an fest verankert.
Möchten Sie 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 den Autor
Ä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.