Mehr Sicherheit mit F5 NGINX App Protect auf Amazon EKS

Laut dem Bericht „The State of Application Strategy in 2022“ von F5 beschleunigt sich die digitale Transformation in Unternehmen weltweit weiter. Die meisten Unternehmen setzen zwischen 200 und 1.000 Apps ein, die sich über mehrere Cloud-Zonen erstrecken. Dabei wandeln sich die Apps von monolithischen zu modernen verteilten Architekturen.

Kubernetes hielt auf der Tech-Szene erstmals im Jahr 2016 Einzug im Mainstream, also vor gerade einmal sechs Jahren. Dennoch betreiben heute mehr als 75 % der Unternehmen weltweit containerisierte Anwendungen in der Produktion, 30 % mehr als 2019. Ein kritisches Problem in Kubernetes-Umgebungen, einschließlich Amazon Elastic Kubernetes Service (EKS), ist die Sicherheit. Allzu oft wird die Sicherheit erst am Ende des App-Entwicklungsprozesses „angehängt“ und manchmal sogar erst, wenn eine containerisierte Anwendung bereits einsatzbereit ist.

Die aktuelle Welle der digitalen Transformation, die durch die COVID-19-Pandemie noch beschleunigt wurde, hat viele Unternehmen dazu gezwungen, einen ganzheitlicheren Sicherheitsansatz zu verfolgen und eine „Shift-Left“-Strategie in Betracht zu ziehen. Das Verschieben der Sicherheit nach links bedeutet, Sicherheitsmaßnahmen frühzeitig in den Softwareentwicklungslebenszyklus (SDLC) einzuführen und in jeder Phase der CI/CD-Pipeline für Anwendungen, Container, Microservices und APIs Sicherheitstools und -kontrollen zu verwenden. Es stellt einen Übergang zu einem neuen Paradigma namens DevSecOps dar, bei dem Sicherheit zu DevOps-Prozessen hinzugefügt und in die schnellen Release-Zyklen integriert wird, die für die Entwicklung und Bereitstellung moderner Software-Apps typisch sind.

DevSecOps stellt einen bedeutenden kulturellen Wandel dar. Sicherheits- und DevOps-Teams arbeiten mit einem gemeinsamen Ziel: qualitativ hochwertige Produkte schnell und sicher auf den Markt zu bringen. Entwickler haben nicht mehr das Gefühl, ständig durch Sicherheitsverfahren behindert zu werden, die ihren Arbeitsablauf unterbrechen. Sicherheitsteams müssen nicht mehr immer wieder dieselben Probleme beheben. Dadurch kann das Unternehmen eine starke Sicherheitsposition aufrechterhalten und Schwachstellen, Fehlkonfigurationen und Verstöße gegen die Einhaltung von Vorschriften oder Richtlinien erkennen und verhindern, sobald diese auftreten.

Durch die Verlagerung der Sicherheit nach links und die Automatisierung der Sicherheit als Code wird Ihre Amazon EKS-Umgebung von Anfang an geschützt. Ein wichtiger Teil des Aufbaus einer Kubernetes-Grundlage besteht darin, zu lernen, wie man die Produktion im großen Maßstab vorbereitet. Eine ordnungsgemäße Governance von Amazon EKS trägt dazu bei, die Effizienz, Transparenz und Verantwortlichkeit im gesamten Unternehmen zu steigern und gleichzeitig die Kosten unter Kontrolle zu halten. Starke Governance- und Sicherheitsvorkehrungen schaffen einen Rahmen für eine bessere Sichtbarkeit und Kontrolle Ihrer Cluster. Ohne sie ist Ihr Unternehmen einem höheren Risiko von Sicherheitsverletzungen und den damit verbundenen langfristigen Kosten in Verbindung mit Umsatz- und Reputationsschäden ausgesetzt.

Weitere Informationen dazu, was bei der Umstellung auf eine „Sicherheit an erster Stelle“-Strategie zu beachten ist, finden Sie im aktuellen Bericht von O'Reilly: Shifting Left for Application Security .

Automatisierung der Sicherheit für Amazon EKS mit GitOps

Automatisierung ist ein wichtiger Faktor für DevSecOps und trägt dazu bei, die Konsistenz auch bei schnellem Entwicklungs- und Bereitstellungstempo aufrechtzuerhalten. Wie bei Infrastruktur als Code erfordert die Automatisierung mit einem Security-as-Code -Ansatz die Verwendung deklarativer Richtlinien, um den gewünschten Sicherheitszustand aufrechtzuerhalten.

GitOps ist ein Betriebsframework, das die Automatisierung erleichtert, um die Anwendungsbereitstellung und Clusterverwaltung zu unterstützen und zu vereinfachen. Die Hauptidee von GitOps besteht darin, ein Git-Repository zu haben, das deklarative Richtlinien von Kubernetes-Objekten und den auf Kubernetes ausgeführten Anwendungen speichert, die als Code definiert sind. Ein automatisierter Prozess vervollständigt das GitOps-Paradigma, um sicherzustellen, dass die Produktionsumgebung allen gespeicherten Zustandsbeschreibungen entspricht.

Das Repository fungiert als Quelle der Wahrheit in Form von Sicherheitsrichtlinien, auf die dann im Rahmen des CI/CD-Pipeline-Prozesses durch deklarative Konfigurations-als-Code -Beschreibungen verwiesen wird. Beispielsweise verwaltet NGINX ein GitHub-Repository mit einer Ansible-Rolle für F5 NGINX App Protect , von dem wir hoffen, dass es Teams hilft, die die Sicherheit nach links verschieben möchten.

Mit einem solchen Repo müssen Sie zum Bereitstellen einer neuen Anwendung oder zum Aktualisieren einer vorhandenen lediglich das Repo aktualisieren. Der automatisierte Prozess verwaltet alles Weitere, einschließlich der Anwendung von Konfigurationen und der Sicherstellung erfolgreicher Updates. Dadurch wird sichergestellt, dass alles im Versionskontrollsystem für Entwickler geschieht und synchronisiert wird, um die Sicherheit geschäftskritischer Anwendungen zu gewährleisten.

Bei der Ausführung auf Amazon EKS sorgt GitOps für nahtlose und robuste Sicherheit, während menschliche Fehler praktisch eliminiert werden und alle im Laufe der Zeit vorgenommenen Versionsänderungen nachverfolgt werden.

NGINX App Protect und NGINX Ingress Controller Schützen Sie Ihre Apps und APIs in Amazon EKS

Ein robustes Design für die Kubernetes-Sicherheitsrichtlinie muss den Anforderungen sowohl von SecOps als auch von DevOps gerecht werden und Vorkehrungen für die Anpassung an die Skalierung der Umgebung enthalten. Kubernetes-Cluster können auf viele Arten gemeinsam genutzt werden. Beispielsweise können in einem Cluster mehrere Anwendungen ausgeführt werden, die die Ressourcen gemeinsam nutzen, während in einem anderen Fall mehrere Instanzen einer Anwendung vorhanden sind, jeweils für einen anderen Endbenutzer oder eine andere Gruppe. Dies bedeutet, dass die Sicherheitsgrenzen nicht immer klar definiert sind und flexible und fein abgestimmte Sicherheitsrichtlinien erforderlich sind.

Das allgemeine Sicherheitsdesign muss flexibel genug sein, um Ausnahmen zu berücksichtigen, muss sich problemlos in die CI/CD-Pipeline integrieren lassen und muss Mandantenfähigkeit unterstützen. Im Kontext von Kubernetes ist ein Tenant eine logische Gruppierung von Kubernetes-Objekten und -Anwendungen, die einer bestimmten Geschäftseinheit, einem Team, einem Anwendungsfall oder einer Umgebung zugeordnet sind. Mandantenfähigkeit bedeutet, dass mehrere Mandanten denselben Cluster sicher gemeinsam nutzen und die Grenzen zwischen den Mandanten auf Grundlage technischer Sicherheitsanforderungen erzwungen werden, die eng mit den Geschäftsanforderungen verknüpft sind.

Eine einfache Möglichkeit, Sicherheit mit geringer Latenz und hoher Leistung auf Amazon EKS zu implementieren, ist die Einbettung der NGINX App Protect WAF- und DoS- Module mit NGINX Ingress Controller . Keiner unserer anderen Wettbewerber bietet diese Art von Inline-Lösung an. Die Verwendung eines Produkts mit synchronisierter Technologie bietet mehrere Vorteile, darunter eine kürzere Rechenzeit, geringere Kosten und eine geringere Anzahl an Tools. Hier sind einige zusätzliche Vorteile.

• Sicherung des Anwendungsperimeter – In einer gut konzipierten Kubernetes-Bereitstellung ist der NGINX Ingress Controller der einzige Einstiegspunkt für Datenverkehr auf Datenebene, der zu Diensten fließt, die in Kubernetes ausgeführt werden, und ist somit ein idealer Ort für einen WAF- und DoS-Schutz.
• Konsolidierung der Datenebene – Durch die Einbettung der WAF in den NGINX Ingress Controller wird kein separates WAF-Gerät mehr benötigt. Dadurch werden Komplexität, Kosten und die Anzahl der Fehlerquellen reduziert.
• Konsolidierung der Kontrollebene – WAF- und DoS-Konfigurationen können mit der Kubernetes-API verwaltet werden, was die Automatisierung von CI/CD-Prozessen erheblich vereinfacht. Die Konfiguration des NGINX Ingress Controllers entspricht den Praktiken der rollenbasierten Zugriffskontrolle (RBAC) von Kubernetes, sodass Sie die WAF- und DoS-Konfigurationen sicher an ein dediziertes DevSecOps-Team delegieren können.

Die Konfigurationsobjekte für NGINX App Protect WAF und DoS sind sowohl im NGINX Ingress Controller als auch im NGINX Plus konsistent. Eine Masterkonfiguration kann problemlos übersetzt und auf beiden Geräten bereitgestellt werden. Dadurch wird es noch einfacher, die WAF-Konfiguration als Code zu verwalten und in jeder Anwendungsumgebung bereitzustellen.

Um NGINX App Protect WAF und DoS in NGINX Ingress Controller zu integrieren, müssen Sie Abonnements sowohl für NGINX Plus als auch für NGINX App Protect WAF oder DoS haben. Mit wenigen einfachen Schritten können Sie das integrierte NGINX Ingress Controller-Image (Docker-Container) erstellen. Nach der Bereitstellung des Images (z. B. manuell oder mit Helm-Diagrammen ) können Sie Sicherheitsrichtlinien und -konfigurationen mit der vertrauten Kubernetes-API verwalten.

Der auf NGINX Plus basierende NGINX Ingress Controller bietet eine detaillierte Kontrolle und Verwaltung der Authentifizierung, der RBAC-basierten Autorisierung und der externen Interaktionen mit Pods. Wenn der Client HTTPS verwendet, kann der NGINX Ingress Controller TLS beenden und den Datenverkehr entschlüsseln, um Layer-7-Routing anzuwenden und Sicherheit zu erzwingen.

NGINX App Protect WAF und NGINX App Protect DoS können dann als leichte Software-Sicherheitslösung eingesetzt werden, um Sicherheitsrichtlinien durchzusetzen und vor Punktangriffen auf Ebene 7 zu schützen. NGINX App Protect WAF sichert Kubernetes-Apps vor OWASP-Top-10-Angriffen und bietet erweiterte Signaturen und Bedrohungsschutz, Bot-Abwehr sowie Dataguard-Schutz vor der Nutzung personenbezogener Daten (PII). NGINX App Protect DoS bietet eine zusätzliche Verteidigungslinie auf den Ebenen 4 und 7, um ausgeklügelte DoS-Angriffe auf Anwendungsebene durch Benutzerverhaltensanalysen und App-Integritätsprüfungen abzuschwächen und so vor Angriffen wie Slow POST , Slowloris, Flood-Angriffen und Challenger Collapsar zu schützen.

Solche Sicherheitsmaßnahmen schützen sowohl REST-APIs als auch Anwendungen, auf die über Webbrowser zugegriffen wird. Die API-Sicherheit wird auch auf Ingress-Ebene gemäß dem Nord-Süd-Verkehrsfluss erzwungen.

NGINX Ingress Controller mit NGINX App Protect WAF und DoS kann Amazon EKS-Verkehr pro Anfrage statt pro Dienst sichern: Dies ist eine nützlichere Ansicht des Layer-7-Verkehrs und eine weitaus bessere Möglichkeit, SLAs und Nord-Süd-WAF-Sicherheit durchzusetzen.

Der neueste Testbericht zur Hochleistungs-Webanwendungs-Firewall von GigaOm zeigt, wie NGINX App Protect WAF durchgehend starke App- und API-Sicherheit bietet und gleichzeitig eine hohe Leistung und geringe Latenz aufrechterhält und die anderen drei getesteten WAFs – AWS WAF, Azure WAF und Cloudflare WAF – bei allen getesteten Angriffsraten übertrifft.

Abbildung 4 zeigt beispielsweise die Ergebnisse eines Tests, bei dem die WAF 500 Anfragen pro Sekunde (RPS) verarbeiten musste, wobei 95 % (475 RPS) der Anfragen gültig und 5 % (25 RPS) der Anfragen „schlecht“ waren (was eine Skript-Injektion simulierte). Beim 99. Perzentil war die Latenz für NGINX App Protect WAF 10-mal geringer als bei AWS WAF, 60-mal geringer als bei Cloudflare WAF und 120-mal geringer als bei Azure WAF.

Abbildung 5 zeigt den höchsten Durchsatz, den jede WAF bei 100 % Erfolg erreichte (keine 5xx oder429 Fehler) mit weniger als 30 Millisekunden Latenz für jede Anfrage. NGINX App Protect WAF bewältigte 19.000 RPS im Vergleich zu 14.000 RPS bei Cloudflare WAF, 6.000 RPS bei AWS WAF und nur 2.000 RPS bei Azure WAF.

So stellen Sie NGINX App Protect und NGINX Ingress Controller auf Amazon EKS bereit

NGINX App Protect WAF und DoS nutzen einen app-zentrierten Sicherheitsansatz mit vollständig deklarativen Konfigurationen und Sicherheitsrichtlinien, wodurch die Sicherheit für den Anwendungslebenszyklus auf Amazon EKS problemlos in Ihre CI/CD-Pipeline integriert werden kann.

NGINX Ingress Controller bietet mehrere benutzerdefinierte Ressourcendefinitionen (CRDs), um jeden Aspekt der Web-Anwendungssicherheit zu verwalten und ein Modell mit geteilter Verantwortung und mehreren Mandanten zu unterstützen. CRD-Manifeste können gemäß der von der Organisation verwendeten Namespace-Gruppierung angewendet werden, um den Besitz durch mehr als eine Betriebsgruppe zu unterstützen.

Wenn Sie eine Anwendung auf Amazon EKS veröffentlichen, können Sie Sicherheit integrieren, indem Sie die bereits verwendete Automatisierungspipeline nutzen und die WAF-Sicherheitsrichtlinie darüber legen.

Darüber hinaus können Sie mit NGINX App Protect auf dem NGINX Ingress Controller Schwellenwerte für die Ressourcennutzung sowohl für die CPU- als auch für die Speicherauslastung konfigurieren, um zu verhindern, dass NGINX App Protect andere Prozesse aushungert. Dies ist insbesondere in Umgebungen mit mehreren Mandanten wie Kubernetes wichtig, die auf die gemeinsame Nutzung von Ressourcen angewiesen sind und möglicherweise unter dem „Noisy Neighbor“-Problem leiden.

Konfigurieren der Protokollierung mit NGINX CRDs

Die Protokolle für NGINX App Protect und NGINX Ingress Controller sind grundsätzlich getrennt, um widerzuspiegeln, wie Sicherheitsteams normalerweise unabhängig von DevOps und Anwendungseigentümern arbeiten. Sie können NGINX App Protect-Protokolle an jedes Syslog-Ziel senden, das von den Kubernetes-Pods aus erreichbar ist, indem Sie den Parameter für die Annotation „ app-protect-security-log-destination“ auf die Cluster-IP-Adresse des Syslog-Pods setzen. Darüber hinaus können Sie mit der Ressource APLogConf angeben, welche NGINX App Protect-Protokolle für Sie wichtig sind und welche Protokolle somit in den Syslog-Pod übertragen werden. NGINX Ingress Controller-Protokolle werden wie für alle Kubernetes-Container an die lokale Standardausgabe weitergeleitet.

Diese Beispielressource für APLogConf gibt an, dass alle Anfragen protokolliert werden (nicht nur böswillige), und legt die maximale Nachrichten- und Anfragegröße fest, die protokolliert werden kann.

API-Version: appprotect.f5.com/v1beta1 Art: APLogConf 
Metadaten: 
Name: logconf 
Namespace: dvwa 
Spezifikation: 
Inhalt: 
Format: Standard 
Max. Nachrichtengröße: 64k 
max_request_size: beliebig 
filter: 
request_type: alle

Definieren einer WAF-Richtlinie mit NGINX CRDs

Das APPolicy Policy-Objekt ist ein CRD, das eine WAF-Sicherheitsrichtlinie mit Signatursätzen und Sicherheitsregeln basierend auf einem deklarativen Ansatz definiert. Dieser Ansatz gilt sowohl für NGINX App Protect WAF als auch für DoS, während sich das folgende Beispiel auf WAF konzentriert. Richtliniendefinitionen werden normalerweise als Teil des SecOps-Katalogs in der Wahrheitsquelle der Organisation gespeichert.

API-Version: appprotect.f5.com/v1beta1 Art: APPolicy 
Metadaten: 
Name: Beispielrichtlinie
Spezifikation: 
Richtlinie: 
Name: Beispielrichtlinie 
Vorlage: 
Name: POLICY_TEMPLATE_NGINX_BASE 
Anwendungssprache: utf-8 
Durchsetzungsmodus: Blockierung 
Signatursätze: 
- Name: Befehlsausführungssignaturen 
Alarm: true 
Block: true
[...]

Nachdem das Sicherheitsrichtlinienmanifest auf dem Amazon EKS-Cluster angewendet wurde, erstellen Sie ein APLogConf-Objekt namens „log-violations“ , um den Typ und das Format der Einträge zu definieren, die in das Protokoll geschrieben werden, wenn eine Anforderung gegen eine WAF-Richtlinie verstößt:

API-Version: appprotect.f5.com/v1beta1 Art: APLogConf 
Metadaten: 
Name: Log-Verstöße
Spezifikation: 
Inhalt: 
Format: Standard 
Max_Message_Size: 64k 
max_request_size: beliebig 
filter: 
request_type: unzulässig

Das Richtlinienobjekt „Waf-Policy“ verweist dann auf die Beispielrichtlinie für NGINX App Protect WAF, um die Durchsetzung für eingehenden Datenverkehr zu erzwingen, wenn die Anwendung vom NGINX Ingress Controller verfügbar gemacht wird. Es verweist auf Protokollverletzungen , um das Format der Protokolleinträge zu definieren, die an den im Feld „logDest“ angegebenen Syslog-Server gesendet werden.

API-Version: k8s.nginx.org/v1 Art: Richtlinie 
metadata: 
Name: waf-policy 
spec: 
waf: 
enable: true 
apPolicy: „default/sample-policy“ 
securityLog: 
enable: true 
apLogConf: „default/log-violations“ 
logDest: „syslog:server=10.105.238.128:5144“

Die Bereitstellung ist abgeschlossen, wenn DevOps ein VirtualServer -Objekt veröffentlicht, das den NGINX Ingress Controller so konfiguriert, dass die Anwendung auf Amazon EKS verfügbar gemacht wird:

API-Version: k8s.nginx.org/v1kind: VirtualServer
Metadaten:
Name: eshop-vs
Spezifikation:
Host: eshop.lab.local
Richtlinien:
- Name: Standard/Waf-Richtlinie
Upstreams:
- Name: eshop-upstream
Dienst: eshop-service
Port: 80
Routen:
- Pfad: /
Aktion:
Pass: eshop-upstream

Das VirtualServer-Objekt vereinfacht die Veröffentlichung und Sicherung von containerisierten Apps, die auf Amazon EKS ausgeführt werden, und wahrt gleichzeitig das Modell der geteilten Verantwortung, bei dem SecOps einen umfassenden Katalog von Sicherheitsrichtlinien bereitstellt und DevOps sich darauf verlässt, um die Sicherheit vom ersten Tag an zu verbessern. Dies ermöglicht Organisationen den Übergang zu einer DevSecOps-Strategie.

Abschluss

Für Unternehmen mit Legacy-Apps und über Jahre aufgebauten Sicherheitslösungen ist die Verlagerung der Sicherheit auf Amazon EKS wahrscheinlich ein schrittweiser Prozess. Aber die Neudefinition von Sicherheit als Code, der vom Sicherheitsteam verwaltet und gewartet und von DevOps verwendet wird, trägt dazu bei, Dienste schneller bereitzustellen und sie produktionsreif zu machen.

Um den Nord-Süd-Verkehr in Amazon EKS zu sichern, können Sie den mit NGINX App Protect WAF eingebetteten NGINX Ingress Controller zum Schutz vor Punktangriffen auf Ebene 7 und NGINX App Protect DoS zur DoS-Minderung auf den Ebenen 4 und 7 nutzen.

Um NGINX Ingress Controller mit NGINX App Protect WAF auszuprobieren, starten Sie eine kostenlose 30-Tage -Testversion im AWS Marketplace oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .

Um zu erfahren, wie Sie Sicherheitsverletzungen verhindern und Ihre Kubernetes-Apps im großen Maßstab mit NGINX Ingress Controller und NGINX App Protect WAF und DoS auf Amazon EKS schützen können, laden Sie unser eBook „ Erhöhen Sie die Sicherheit Ihres Amazon EKS mit F5 NGINX“ herunter .

Um mehr darüber zu erfahren, wie NGINX App Protect WAF die nativen WAFs für AWS, Azure und Cloudflare übertrifft, laden Sie den Testbericht „High-Performance Web Application Firewall“ von GigaOm herunter und registrieren Sie sich für das Webinar am 6. Dezember, bei dem GigaOm-Analyst Jake Dolezal die Ergebnisse bespricht.