Sicherheit nach links verlagern mit F5 NGINX App Protect auf Amazon EKS

Fabrizio FiorucciNGINX-Lösungsarchitekt | F5 (EMEA)

Thelen BlumSenior Product Marketing Manager, NGINX App Protect | F5

Laut dem F5-Bericht „The State of Application Strategy in 2022“ schreitet die digitale Transformation in Unternehmen weltweit immer schneller voran. Die meisten Unternehmen stellen zwischen 200 und 1.000 Anwendungen bereit, die sich über mehrere Cloud-Zonen erstrecken. Dabei entwickeln sich heutige Anwendungen von monolithischen hin zu modernen verteilten Architekturen.

Kubernetes hielt 2016, also vor gerade einmal sechs Jahren, Einzug in den Mainstream der Technologiewelt. Heute führen jedoch bereits mehr als 75 % der Unternehmen weltweit containerisierte Anwendungen in Produktionsumgebungen aus – 30 % mehr als 2019. Ein entscheidendes Thema in Kubernetes-Umgebungen, einschließlich Amazon Elastic Kubernetes Service (EKS), ist die Sicherheit. Allzu oft wird Sicherheit erst am Ende des Anwendungsentwicklungsprozesses „nachträglich hinzugefügt“, manchmal sogar erst, nachdem eine containerisierte Anwendung bereits in Betrieb genommen wurde.

Die aktuelle Welle der digitalen Transformation, die durch die COVID‑19-Pandemie beschleunigt wurde, hat viele Unternehmen dazu veranlasst, einen ganzheitlicheren Sicherheitsansatz zu verfolgen und eine „Shift-left“-Strategie in Betracht zu ziehen. Shift Left in der IT-Sicherheit bedeutet, Sicherheitsmaßnahmen bereits frühzeitig in den Softwareentwicklungszyklus (SDLC) einzubinden und in jeder Phase der CI/CD-Pipeline für Anwendungen, Container, Microservices und APIs Sicherheitstools und Kontrollmechanismen einzusetzen. Dies stellt den Übergang zu einem neuen Paradigma namens DevSecOps dar, bei dem Sicherheit in DevOps-Prozesse eingebunden und in die schnellen Release-Zyklen integriert wird, die für die moderne Entwicklung und Bereitstellung von Softwareanwendungen typisch sind.

DevSecOps stellt einen bedeutenden kulturellen Wandel dar. Sicherheits- und DevOps-Teams verfolgen ein gemeinsames Ziel: hochwertige Produkte schnell und sicher auf den Markt zu bringen. Entwickler fühlen sich nicht mehr ständig durch Sicherheitsverfahren ausgebremst, die ihren Arbeitsablauf unterbrechen. Sicherheitsteams müssen nicht mehr immer wieder dieselben Probleme beheben. So kann das Unternehmen ein hohes Sicherheitsniveau aufrechterhalten und Schwachstellen, Fehlkonfigurationen sowie Verstöße gegen Compliance-Vorgaben oder Richtlinien unmittelbar erkennen und verhindern.

Durch die frühzeitige Einbindung von Sicherheitsmaßnahmen und die Automatisierung von Sicherheit als Code wird Ihre Amazon-EKS-Umgebung von Anfang an geschützt. Zu lernen, wie sich Produktionsreife in großem Maßstab erreichen lässt, ist ein wesentlicher Bestandteil beim Aufbau einer Kubernetes-Grundlage. Eine angemessene Governance von Amazon EKS trägt dazu bei, Effizienz, Transparenz und Verantwortlichkeit im gesamten Unternehmen zu fördern und gleichzeitig die Kosten zu kontrollieren. Eine starke Governance und klare Sicherheitsleitplanken schaffen einen Rahmen für eine bessere Übersicht und Kontrolle über Ihre Cluster. Ohne diese ist Ihr Unternehmen einem höheren Risiko von Sicherheitsverletzungen und den damit verbundenen langfristigen Kosten durch Umsatz- und Reputationsschäden ausgesetzt.

Weitere Informationen dazu, was bei der Umstellung auf eine Security-First-Strategie zu beachten ist, finden Sie in diesem aktuellen Bericht von O’Reilly: „Shift Left für Anwendungssicherheit“.

Automatisierung der Sicherheit für Amazon EKS mit GitOps

Automatisierung ist ein wichtiger Wegbereiter für DevSecOps und trägt dazu bei, selbst bei einer hohen Entwicklungs- und Bereitstellungsgeschwindigkeit Konsistenz zu gewährleisten. Ähnlich wie bei Infrastructure as Code werden bei der Automatisierung nach dem Security-as-Code-Ansatz deklarative Richtlinien eingesetzt, um den gewünschten Sicherheitszustand aufrechtzuerhalten.

GitOps ist ein Betriebsframework, das die Automatisierung erleichtert, um die Anwendungsbereitstellung und das Cluster-Management zu unterstützen und zu vereinfachen. Der Kerngedanke von GitOps besteht darin, ein Git-Repository zu verwenden, in dem deklarative Richtlinien für Kubernetes-Objekte und die auf Kubernetes ausgeführten Anwendungen als Code gespeichert werden. Ein automatisierter Prozess vervollständigt das GitOps-Paradigma, indem er sicherstellt, dass die Produktionsumgebung mit allen gespeicherten Zustandsbeschreibungen übereinstimmt.

Das Repository dient als zentrale Informationsquelle in Form von Sicherheitsrichtlinien, auf die dann im Rahmen des CI/CD-Pipeline-Prozesses durch deklarative Configuration-as-Code-Beschreibungen verwiesen wird. Beispielsweise unterhält NGINX ein GitHub-Repository mit einer Ansible-Rolle für F5 NGINX App Protect, das Teams hoffentlich dabei unterstützt, Sicherheitsmaßnahmen in frühere Phasen des Entwicklungsprozesses zu verlagern.

Mit einem solchen Repository genügt es, das Repository zu aktualisieren, um eine neue Anwendung bereitzustellen oder eine bestehende zu aktualisieren. Der automatisierte Prozess übernimmt alles Weitere, einschließlich der Anwendung von Konfigurationen und der Sicherstellung erfolgreicher Aktualisierungen. Dadurch wird gewährleistet, dass alle Vorgänge im Versionskontrollsystem für Entwickler stattfinden und synchronisiert werden, um die Sicherheit geschäftskritischer Anwendungen durchzusetzen.

Beim Betrieb auf Amazon EKS sorgt GitOps für nahtlose und robuste Sicherheit, eliminiert menschliche Fehler nahezu vollständig und protokolliert alle im Laufe der Zeit vorgenommenen Versionsänderungen.

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

Ein robustes Konzept für Kubernetes-Sicherheitsrichtlinien muss sowohl die Anforderungen von SecOps als auch von DevOps berücksichtigen und Vorkehrungen für die Anpassung an eine skalierende Umgebung umfassen. Kubernetes-Cluster können auf vielfältige Weise gemeinsam genutzt werden. Beispielsweise können in einem Cluster mehrere Anwendungen ausgeführt werden, die sich dessen Ressourcen teilen. In einem anderen Fall gibt es mehrere Instanzen einer Anwendung, jeweils für einen anderen Endbenutzer oder eine andere Gruppe. Dies bedeutet, dass Sicherheitsgrenzen nicht immer klar definiert sind und flexible, fein abgestufte Sicherheitsrichtlinien erforderlich sind.

Das gesamte Sicherheitskonzept muss flexibel genug sein, um Ausnahmen zu berücksichtigen, sich problemlos in die CI/CD-Pipeline integrieren lassen und Mandantenfähigkeit unterstützen. Im Kontext von Kubernetes ist ein Mandant 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 demnach, dass sich mehrere Mandanten denselben Cluster sicher teilen, wobei die Grenzen zwischen den Mandanten anhand technischer Sicherheitsanforderungen durchgesetzt werden, die eng mit den geschäftlichen Anforderungen verknüpft sind.

Eine einfache Möglichkeit, Sicherheit mit niedriger Latenz und hoher Leistung auf Amazon EKS zu implementieren, besteht darin, die Module NGINX App Protect WAF and DoS in den NGINX Ingress Controller zu integrieren. Keiner unserer anderen Wettbewerber bietet eine solche Inline-Lösung an. Der Einsatz eines einzigen Produkts mit aufeinander abgestimmten Technologien bietet mehrere Vorteile, darunter einen geringeren Rechenaufwand, niedrigere Kosten und weniger Tool-Wildwuchs. Hier sind einige weitere Vorteile.

• Absicherung des Anwendungsperimeters – In einer gut konzipierten Kubernetes-Bereitstellung ist der NGINX Ingress Controller der einzige Einstiegspunkt für Datenverkehr auf der Datenebene, der zu den in Kubernetes ausgeführten Diensten fließt. Damit ist er der ideale Ort für WAF- und DoS-Schutz.
• Konsolidierung der Datenebene – Durch die Integration der WAF in den NGINX Ingress Controller ist keine separate WAF-Appliance mehr erforderlich. Dadurch werden Komplexität, Kosten und die Anzahl potenzieller Fehlerquellen reduziert.
• Konsolidierung der Steuerungsebene – Die WAF- und DoS-Konfiguration kann über die Kubernetes-API verwaltet werden, wodurch sich CI/CD-Prozesse wesentlich einfacher automatisieren lassen. 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 in NGINX Plus identisch. Eine Masterkonfiguration kann problemlos übertragen und auf beiden Systemen bereitgestellt werden. Dadurch wird es noch einfacher, die WAF-Konfiguration als Code zu verwalten und in jeder beliebigen Anwendungsumgebung bereitzustellen.

Um NGINX App Protect WAF und DoS in NGINX Ingress Controller zu integrieren, benötigen Sie Abonnements sowohl für NGINX Plus als auch für NGINX App Protect WAF oder DoS. Mit nur wenigen einfachen Schritten können Sie das integrierte NGINX-Ingress-Controller-Image (Docker-Container) erstellen. Nachdem Sie das Image bereitgestellt haben (zum Beispiel manuell oder mithilfe von Helm-Charts), können Sie Sicherheitsrichtlinien und Konfigurationen über die vertraute Kubernetes-API verwalten.

Der auf NGINX Plus basierende NGINX Ingress Controller ermöglicht eine granulare Steuerung 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 terminieren und den Datenverkehr entschlüsseln, um Layer-7-Routing anzuwenden und Sicherheitsrichtlinien durchzusetzen.

NGINX App Protect WAF und NGINX App Protect DoS können anschließend als schlanke softwarebasierte Sicherheitslösung bereitgestellt werden, um Sicherheitsrichtlinien durchzusetzen und vor gezielten Angriffen auf Layer 7 zu schützen. NGINX App Protect WAF schützt Kubernetes-Anwendungen vor Angriffen gemäß den OWASP Top 10 und bietet erweiterte Signaturen und Bedrohungsschutz, Bot-Abwehr sowie Dataguard-Schutz vor der Ausnutzung personenbezogener Daten (PII). NGINX App Protect DoS bietet eine zusätzliche Verteidigungslinie auf den Layern 4 und 7, um ausgefeilte DoS-Angriffe auf Anwendungsebene mithilfe von Analysen des Benutzerverhaltens und Zustandsprüfungen der Anwendung abzuwehren 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 zudem auf der Ingress-Ebene entlang des Nord-Süd-Datenverkehrs durchgesetzt.

NGINX Ingress Controller mit NGINX App Protect WAF und DoS kann den Amazon-EKS-Datenverkehr auf Anfragebasis statt auf Dienstbasis absichern. Dies ermöglicht eine aussagekräftigere Betrachtung des Layer-7-Datenverkehrs und bietet eine weitaus bessere Möglichkeit, SLAs und die WAF-Sicherheit für den Nord-Süd-Datenverkehr durchzusetzen.

Der neueste Testbericht zu Hochleistungs-Web-Application-Firewalls von GigaOm zeigt, wie NGINX App Protect WAF durchgängig zuverlässige Sicherheit für Anwendungen und APIs bei gleichzeitig hoher Leistung und niedriger Latenz bietet und die drei anderen getesteten WAFs – AWS WAF, Azure WAF und Cloudflare WAF – bei allen getesteten Angriffsraten übertrifft.

Abbildung 4 zeigt beispielhaft die Ergebnisse eines Tests, bei dem die WAF 500 Anfragen pro Sekunde (RPS) verarbeiten musste. Dabei waren 95 % (475 RPS) der Anfragen gültig und 5 % der Anfragen (25 RPS) „schädlich“ (Simulation einer Skriptinjektion). Beim 99. Perzentil war die Latenz von NGINX App Protect WAF 10-mal niedriger als die von AWS WAF, 60-mal niedriger als die von Cloudflare WAF und 120-mal niedriger als die von Azure WAF.

Abbildung 5 zeigt den höchsten Durchsatz, den die einzelnen WAFs bei einer Erfolgsquote von 100 % (keine 5xx- oder 429-Fehler) und einer Latenz von weniger als 30 Millisekunden pro Anfrage erreichten. NGINX App Protect WAF bewältigte 19.000 RPS, verglichen mit 14.000 RPS bei Cloudflare WAF, 6.000 RPS bei AWS WAF und lediglich 2.000 RPS bei Azure WAF.

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

NGINX App Protect WAF und DoS verfolgen einen anwendungszentrierten Sicherheitsansatz mit vollständig deklarativen Konfigurationen und Sicherheitsrichtlinien. Dadurch lässt sich Sicherheit für den gesamten Anwendungslebenszyklus auf Amazon EKS einfach in Ihre CI/CD-Pipeline integrieren.

NGINX Ingress Controller stellt mehrere benutzerdefinierte Ressourcendefinitionen (CRDs) bereit, um alle Aspekte der Sicherheit von Webanwendungen zu verwalten und ein Modell mit geteilter Verantwortung und mehreren Mandanten zu unterstützen. CRD-Manifeste können entsprechend der von der Organisation verwendeten Namespace-Gruppierung angewendet werden, sodass mehrere Betriebsteams die Verantwortung übernehmen können.

Bei der Veröffentlichung einer Anwendung auf Amazon EKS können Sie die Sicherheit von Anfang an integrieren, indem Sie die bereits verwendete Automatisierungspipeline nutzen und zusätzlich die WAF-Sicherheitsrichtlinie anwenden.

Darüber hinaus können Sie mit NGINX App Protect auf dem NGINX Ingress Controller Schwellenwerte für die CPU- und Arbeitsspeicherauslastung konfigurieren, um zu verhindern, dass NGINX App Protect anderen Prozessen Ressourcen entzieht. Dies ist besonders wichtig in mandantenfähigen Umgebungen wie Kubernetes, die auf der gemeinsamen Nutzung von Ressourcen basieren und potenziell unter dem „Noisy-Neighbor“-Problem leiden können.

Protokollierung mit NGINX-CRDs konfigurieren

Die Protokolle für NGINX App Protect und NGINX Ingress Controller sind bewusst voneinander getrennt, da Sicherheitsteams in der Regel unabhängig von DevOps-Teams und Anwendungsverantwortlichen arbeiten. Sie können NGINX App Protect-Protokolle an jedes Syslog-Ziel senden, das von den Kubernetes-Pods aus erreichbar ist. Setzen Sie dazu den Parameter der Annotation app-protect-security-log-destination auf die Cluster-IP-Adresse des Syslog-Pods. Darüber hinaus können Sie mithilfe der Ressource APLogConf festlegen, welche NGINX App Protect-Protokolle für Sie relevant sind und somit an den Syslog-Pod übertragen werden. Die Protokolle des NGINX Ingress Controller werden wie bei allen Kubernetes-Containern an die lokale Standardausgabe weitergeleitet.

Diese APLogConf-Beispielressource legt fest, dass alle Anfragen protokolliert werden (nicht nur schädliche), und definiert die maximale Größe der Nachrichten und Anfragen, die protokolliert werden können.

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
 name: logconf 
 namespace: dvwa 
spec: 
 content: 
   format: default 
   max_message_size: 64k 
   max_request_size: any 
 filter: 
   request_type: all

Definieren einer WAF-Richtlinie mit NGINX-CRDs

Das APPolicy-Policy-Objekt ist eine CRD, die mithilfe eines deklarativen Ansatzes eine WAF-Sicherheitsrichtlinie mit Signatursätzen und Sicherheitsregeln definiert. Dieser Ansatz gilt sowohl für NGINX App Protect WAF als auch für DoS, wobei sich das folgende Beispiel auf WAF konzentriert. Richtliniendefinitionen werden üblicherweise als Teil des SecOps-Katalogs in der maßgeblichen Datenquelle der Organisation gespeichert.

apiVersion: appprotect.f5.com/v1beta1 kind: APPolicy 
metadata: 
  name: sample-policy
spec: 
  policy: 
    name: sample-policy 
    template: 
      name: POLICY_TEMPLATE_NGINX_BASE 
    applicationLanguage: utf-8 
    enforcementMode: blocking 
    signature-sets: 
    - name: Command Execution Signatures 
      alarm: true 
      block: true
[...]

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

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
  name: log-violations
spec: 
  content: 
    format: default 
    max_message_size: 64k 
    max_request_size: any 
  filter: 
    request_type: illegal

Das waf-policy-Richtlinienobjekt verweist dann auf sample-policy, damit NGINX App Protect WAF diese Richtlinie auf eingehenden Datenverkehr anwendet, wenn die Anwendung über den NGINX Ingress Controller bereitgestellt wird. Es verweist auf log-violations, um das Format der Protokolleinträge festzulegen, die an den im Feld logDest angegebenen Syslog-Server gesendet werden.

apiVersion: k8s.nginx.org/v1 kind: Policy 
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, sobald DevOps ein VirtualServer-Objekt veröffentlicht, das den NGINX Ingress Controller so konfiguriert, dass die Anwendung auf Amazon EKS verfügbar gemacht wird:

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: eshop-vs
spec:
  host: eshop.lab.local
  policies:
  - name: default/waf-policy
  upstreams:
  - name: eshop-upstream
    service: eshop-service
    port: 80
  routes:
  - path: /
    action:
      pass: eshop-upstream

Das VirtualServer-Objekt erleichtert die Veröffentlichung und Absicherung containerisierter Anwendungen, die auf Amazon EKS ausgeführt werden, und wahrt dabei das Modell der geteilten Verantwortung: SecOps stellt einen umfassenden Katalog von Sicherheitsrichtlinien bereit, auf den DevOps zurückgreift, um Sicherheit vom ersten Tag an frühzeitig in den Entwicklungsprozess zu integrieren. So können Unternehmen zu einer DevSecOps-Strategie übergehen.

Fazit

Für Unternehmen mit Legacy-Anwendungen und über Jahre gewachsenen Sicherheitslösungen dürfte die Verlagerung der Sicherheit in frühere Phasen auf Amazon EKS ein schrittweiser Prozess sein. Wenn Sicherheit jedoch als Code verstanden wird, der vom Sicherheitsteam verwaltet und gepflegt und von DevOps genutzt wird, können Services schneller bereitgestellt und produktionsreif gemacht werden.

Um den Nord-Süd-Datenverkehr in Amazon EKS abzusichern, können Sie den NGINX Ingress Controller mit integriertem NGINX App Protect WAF zum Schutz vor gezielten Angriffen auf Layer 7 sowie NGINX App Protect DoS zur Abwehr von DoS-Angriffen auf den Layern 4 und 7 einsetzen.

Wenn Sie NGINX Ingress Controller mit NGINX App Protect WAF testen möchten, starten Sie eine kostenlose 30-tägige Testversion im AWS Marketplace oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Erfahren Sie, wie Sie mit NGINX Ingress Controller sowie NGINX App Protect WAF und DoS Sicherheitsverletzungen verhindern und Ihre Kubernetes-Anwendungen auf Amazon EKS in großem Umfang schützen können. Laden Sie dazu unser E-Book „Mehr Sicherheit für Ihr Amazon EKS mit F5 NGINX“ herunter.

Wenn Sie mehr darüber erfahren möchten, wie NGINX App Protect WAF die nativen WAFs von AWS, Azure und Cloudflare übertrifft, laden Sie den Testbericht zu leistungsstarken Web Application Firewalls von GigaOm herunter und melden Sie sich für das Webinar am 6. Dezember an, in dem der GigaOm-Analyst Jake Dolezal die Ergebnisse erläutert.

Über die Autoren

Fabrizio FiorucciNGINX-Lösungsarchitekt | F5 (EMEA)

Weitere Blogbeiträge von Fabrizio Fiorucci

Thelen BlumSenior Product Marketing Manager, NGINX App Protect | F5

Weitere Blogbeiträge von Thelen Blum