Fokussiert auf die Sicherung containerisierter Anwendungen

Die Einführung von Containern und Microservices kann zu erheblichen Lücken bei der Anwendungssicherheit führen, warnen die Sicherheitsexperten von Radware in ihrem Web Application Security Report. Zwar gebe es unterschiedliche Ansätze zur Absicherung containerisierter Anwendungen, doch nicht alle berücksichtigten alle Spezifika solcher Umgebungen.

Eine typische Anwendungsinfrastruktur muss skalierbar sein und umfasst normalerweise einen Orchestrator für den Einsatz und die Zuweisung von Ressourcen (wie Kubernetes, OpenShift oder Mesos) sowie einen Reverse-Proxy-Ingress-Controller wie NGiNX, HA-Proxy und Envoy. Jedoch verfügt laut Radware keines dieser Tools über eine integrierte Anwendungssicherheit.

Darüber hinaus werden diese Umgebungen normalerweise von DevOps entworfen, deren Ziel nicht primär die Sicherheit, sondern vielmehr die Automatisierung und Synchronisierung für erhöhte Agilität ist. Wenn also die Sicherheit beim Design nicht berücksichtigt wurde, muss sie vom Sicherheitspersonal im Nachhinein behandelt werden. Dabei gibt es laut Radware fünf wesentliche Aspekte:

• Externe Bedrohungen gehen grundsätzlich mit jeder Anwendung einher. Dieser typische Client-zu-Server-Verkehr wird auch als Nord-Süd-Verkehr bezeichnet.
• Laterale Bedrohungen – Bei Microservices verlagert sich der Schwerpunkt auf die Übertragung von Datenpaketen von Server zu Server oder von Microservice zu Microservice innerhalb eines Rechenzentrums oder VPC. Diese interne Kommunikation wird auch als Ost-West-Verkehr bezeichnet. Die Sicherung des Ost-West-Verkehrs ist entscheidend, um die für böswillige Aktivitäten verfügbare Angriffsfläche zu reduzieren.
• API-Sicherheit – APIs sind das Hauptvehikel für den Ost-West-Datenaustausch zwischen Microservices unter Verwendung verschiedener Protokolle – REST, gRPC, GraphQL oder anderer. Die Bedrohungen für APIs sind vielfältig und umfassen unbefugten Zugriff, Protokollmanipulationen, Denial-of-Service und ein breites Spektrum von Bot-Angriffen.
• Open Source – es gibt viele leistungsfähige Tools, Module und Funktionen von der Stange; es gibt jedoch keine Garantie dafür, dass sie auf Sicherheit getestet oder gepatcht sind.
• End-to-End-Verschlüsselung – Unternehmen sind heute weniger tolerant gegenüber jeder Form von Klartextkommunikation und benötigen SSL/TLS-Terminierung auf Host-Ebene. Auf diese Weise vermeiden sie die Verwaltung mehrerer Zertifikate, die über mehrere Standorte verteilt sind.

„Die Server-zu-Server- und API-Verkehr werden als sicher und daher vertrauenswürdig empfunden, obwohl sie den größten blinden Fleck in der Sicherheit von Microservices darstellen“ kommentiert Rob Hartley, Vice President & Managing Director für EMEA und Lateinamerika von Radware. „Unternehmen müssen daher Strategien entwickeln, um die komplette Sichtbarkeit und damit eine sicherere CI/CD-Pipeline zu gewährleisten.“ Dabei gibt es unterschiedliche Herangehensweisen und Technologien, die jedoch laut Radware neben Stärken auch meist immanente Schwächen bei der Absicherung von Anwendungen in Containern aufweisen.

Externe Web Application Firewall

Als virtuelle Maschine am Perimeter oder auf einem NGiNX Server kann eine externe WAF bekannte Angriffe auf der Basis von IP-Reputation oder Signaturen blockieren. Ein solcher Einsatz kann jedoch per Definition kein granulares Lernen und keine präzise Sicherheit bieten, wodurch die Anwendung anfällig für Zero-Day-Angriffe bleibt.

Der Versuch, positive Sicherheit und automatisches Lernen anzuwenden, führt zu einer hohen Rate von Fehlalarmen, da der gesamte Datenverkehr zu allen Microservices gelernt wird und nicht so feinkörnig wie nötig ist. Dasselbe gilt für Cloud-Sicherheitsdienste. Außerdem führt die Umleitung von Datenverkehr aus dem Ökosystem heraus und zurück zu einer unerwünschten Latenzzeit und widerspricht dem Grundprinzip der End-to-End-Integration der CI/CD-Pipeline.

Container-Sicherheitslösungen

Es gibt Sicherheitslösungen, die unterschiedliche Sicherheitsniveaus für die Container selbst bieten. Sie sind so konzipiert, dass sie den Container als Host oder Endpunkt schützen, indem sie die Container-Images und die darin enthaltenen bekannten Schwachstellen betrachten und nicht Datentransaktionen und HTTP-Verkehr.

Daher bieten sie minimale Anwendungssicherheit und schützen nicht vor Zugriffsverletzungen, Injektionen, Bruteforce, XSS und anderen Exploits. Darüber hinaus sind die meisten immer noch im Nur-Alarmmodus und setzen die Sicherheit bei Datentransaktionen nicht durch. Dennoch können sie mit der Anwendungssicherheit koexistieren, was eine recht robuste Haltung ermöglicht.

Runtime Application Self-Protection (RASP)

Wie der Name schon sagt, schützt sich die Anwendung während der Laufzeit selbst. Dies ist ein leichtes, wirtschaftliches Konzept und kann mit den Microservices automatisch skalieren. Aber auch RASP hat Schwächen. Zwar führt es keine Verzögerungen aufgrund von Sicherheitskontrollen im Datenpfad ein. Stattdessen gibt es aber eine Leistungseinbuße aufgrund der zusätzlichen Bibliothek bzw. Plug-ins mit WAF-ähnlichen Regeln.

Während RASP der Anforderung der Ende-zu-Ende-Verschlüsselung mit SSL/TLS-Terminierung bei der Anwendung entgegenkommt und auch aktiven Schutz in Echtzeit bietet, gibt es doch auch einige Angriffe, die man während der Laufzeit einfach nicht blockieren kann und die man vor der eigentlichen Anwendung entschärfen muss. Ein wichtiges Beispiel dafür ist eine Denial-of-Service-Attacke. Die Lernfähigkeit ist begrenzt, da sie einen Overhead erfordert, der nicht tragbar ist.

Schließlich behebt RASP nicht automatisch Code-Schwachstellen, was seinen Schutz für einige Anwendungen zu einem Schweizer Käse machen könnte. Da es den Code neu schreibt und eine Funktion während der Ausführung stoppen kann, besteht ein hohes Risiko für die Ausführung der Anwendung und schließlich für die SLA. RASP hat sich nicht auf breiter Front durchsetzen können und wird laut Radware von sich aus keine Ergebnisse liefern.

MicroWAF

Bei einer MicroWAF handelt es sich um ein dediziertes Tool zur Durchsetzung der Anwendungssicherheit, das sich in das System integriert, idealerweise von einem Orchestrierungswerkzeug wie Kubernetes verwaltet wird und vor jedem Container sitzt. Dieser Ansatz hat zwei große Vorteile. Einer besteht darin, dass die MicroWAF Kubernetes-kontrolliert ist und automatisch bereitgestellt, provisioniert und skaliert werden kann. Da sich vor jedem Container eine Instanz befindet, kann zweitens das automatische Lernen des Verkehrs zum Microservice als Basis für eine positive Sicherheit funktionieren.

Bei diesem Ansatz befinden sich das Management, die Analytik und die Regel-Engine getrennt vom Enforcer, der kontinuierlich die notwendigen Informationen zur Optimierung der Sicherheit austauscht. Ein weiterer Hauptvorteil dieses Ansatzes besteht darin, dass er DevOps-freundlich ist – es gibt keine Verzögerungen oder Unterbrechungen, er bietet vollständige Sichtbarkeit, und je mehr Bereitstellungs-, Analyse- und Automatisierungswerkzeuge in das von K8s kontrollierte Ökosystem integriert werden, desto effizienter wird dieses.

Lösungen wie Kubernetes WAF von Radware lassen sich leicht in gängige Software-Bereitstellungs-, Test- und Sichtbarkeitstools in der CI/CD-Pipeline integrieren und bieten sowohl IT-Sicherheits- als auch DevOps-Mitarbeitern detaillierte Einblicke bis hinunter zur Pod- und Container-Ebene. Die Lösung ermöglicht es Unternehmen, effektive Anwendungs- und Datensicherheit in On-Premise- und Cloud-basierten Umgebungen zu implementieren. (rhh)

Radware