Radware über Bedrohungen in der Anwendungsvirtualisierung Container und Microservices absichern

Redakteur: Stephan Augsten

Im Web Application Security Report warnt Radware vor Anfälligkeiten, die mit der Einführung von Containern und Microservices einhergehen. Der Hersteller klärt darüber auf, welche Bedrohungen existieren und welche Gegenmaßnahmen Unternehmen treffen können.

Firmen zum Thema

Die Überwachung der Container-Infrastruktur sollte bei DevOps-Ansätzen immer mit dazu gehören.
Die Überwachung der Container-Infrastruktur sollte bei DevOps-Ansätzen immer mit dazu gehören.
(© sutthinon602 - stock.adobe.com)

Ob Orchestrierungsplattformen wie Kubernetes, OpenShift oder Mesos oder Reverse-Proxy-Ingress-Controller wie NGiNX, HA-Proxy und Envoy: Kaum ein Tool zur Containerisierung verfügt über integrierte Mechanismen zur Anwendungssicherheit, kommentiert Radware.

Das Ziel von DevOps ist außerdem nicht primär die Sicherheit, sondern vielmehr die Automatisierung und Synchronisierung für erhöhte Agilität. Da Sicherheit nicht „by Design“ berücksichtigt wird, muss sie zwangsläufig vom Sicherheitspersonal im Nachhinein behandelt werden. Dabei gibt es laut Radware fünf wesentliche Aspekte:

  • Externe Bedrohungen: Diese 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.
  • Ende-zu-Ende-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.

Ost-West- und API-Verkehr stellen dabei den größten blinden Fleck in der Sicherheit dar, konstatiert 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 verschiedene Herangehensweisen und Technologien mit unterschiedlichen Stärken und Schwächen bei der Absicherung von Anwendungen in Containern.

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.

(ID:47004281)