Umzug in die Cloud – aber sicher! WAF Anforderungen und Einsatzmöglichkeiten

Der Umzug in die Cloud ist selbst bei Unternehmen, die sich bisher gegen diesen Schritt gesträubt haben, mittlerweile äußerst populär. Egal, wo in Ihrer Migrationsplanung Sie stehen: So ein Umzug kann dauern – manchmal sogar Jahre. Und oft fängt er mit dem Umzug von Peripherieaufgaben in die Cloud an, wohingegen die Komponenten des Kerngeschäfts (wie z. B. Datenbanken) im physischen Rechenzentrum verbleiben.

Während die Cloud Agilität, niedrigere Kosten und andere Vorteile verspricht, gilt der Sicherheit die größte Sorge – insbesondere geht es um die Frage, ob die Cloud ein ebenso hohes Maß an Sicherheit gewährleisten kann wie das physische Rechenzentrum. Die gute Nachricht: Es ist möglich, den Web-Verkehr in der Cloud zu sichern. Führende WAF- Lösungen (Web Application Firewall), die Daten und Anwendungen im physischen Rechenzentrum schützen, sind auch in der Cloud verfügbar. Die Wahl einer agilen, leistungsstarken WAF ist unverzichtbar dafür, die Cloud-Umgebung ebenso sicher zu machen, wie das physische Rechenzentrum. In diesem Beitrag beleuchten wir die Anforderungen und Bereitstellungsoptionen für die Bewertung einer WAF für die Cloud.

Unterschiedliche Web-App-Attacken

Schauen wir uns zunächst einmal herkömmliche Angriffe auf Web-Anwendungen an, vor denen WAF-Lösungen schützen sollen. Die heutigen primären Bedrohungen für Web-Anwendungen lassen sich in vier Hauptkategorien unterteilen:

Angriffe auf die Anwendungsschicht: SQL-Injection und Cross-Site Scripting (XSS) sind zwei herkömmliche Arten von Angriffen auf die Anwendungsschicht. Waren solche Versuche in der Vergangenheit erfolgreich, dann zieht das weitere Account-Takeover-Angriffe nach sich, wobei versucht wird, weitere Anmelde- und Benutzerdaten abzugreifen. Mobile APIs haben nach wie vor viele Sicherheitslücken, und wir erleben einen stetigen Zustrom von Schwachstellen aus Drittanbieter-Komponenten.

Distributed Denial of Service (DDoS): Diese Angriffe nutzen größere Botnetze und machen sich dazu Sicherheitslücken in IoT-Produkten (Internet of Things – Internet der Dinge) zunutze. Billigere und leistungsstärkere DDoS-Services können gemietet werden (DDoS-as-a-Service).

Randsomware: Endpoint-Ransomware hat einen Höchststand erreicht; Erpressung ist im Vormarsch, da die Angreifer versuchen, ihre Angriffe zu Geld zu machen.

Insider-Angriffe: Böswillige Insider (also unzufriedene Mitarbeiter) sind eine große Bedrohung; IoT-Geräte verstärken das Nachlässigkeits-/Gefährdungsrisiko. Sicherheitsabteilungen müssen gegen diese Bedrohungen im physischen Rechenzentrum vorgehen, und das Bedrohungsszenario bleibt auch bei einem Umzug in die Cloud bestehen.
Aber das Sicherheitsmodell ändert sich. Für die Zwecke dieses Beitrags konzentrieren wir uns auf Angriffe auf die Anwendungsschicht.

Das Sicherheitsmodell für die Public Cloud

Die führenden Cloud-Anbieter haben das so genannte Shared-Responsibility-Modell für die Cloud-Sicherheit eingeführt. Amazon stellt fest, dass AWS „verantwortlich für die Sicherheit der Cloud selbst ist“, während die Kunden „verantwortlich für die Sicherheit in der Cloud sind“. Auch Microsoft Azure, Google Cloud und andere Cloud-Anbieter haben dieses Modell übernommen. Einfach gesagt bedeutet Shared Responsibility (gemeinsame Verantwortung), dass die Cloud-Anbieter Tools und Services zur Sicherung der Infrastruktur (z. B. Netzwerk- und Rechensysteme) bereitstellen, während die Kunden z. B. verantwortlich sind für den Schutz des Netzwerkverkehrs und die Datensicherheit. So unterstützen Cloud-Anbieter beispielsweise bei der Beschränkung des Zugangs zu den Recheninstanzen (AWS EC2/Azure VM/Google CE), auf denen der Webserver eingesetzt wird (durch Nutzung von Sicherheitsgruppen/Firewalls und anderen Methoden). Darüber hinaus verhindern sie den Zugriff des Web-Verkehrs auf eingeschränkte Ports, indem sie nur die wirklich benötigten HTTP- oder HTTPS-Listener in den öffentlichen Endpunkten setzen (normalerweise den Load Balancer).

Aber Public-Cloud-Anbieter bieten nicht die notwendigen Tools für einen umfassenden Schutz gegen Anwendungsschwachstellen und Bedrohungen wie OWASP Top-10 oder automatisierte Angriffe. Es liegt in der Verantwortung des Kunden, Sicherheitsmaßnahmen zu treffen, die nur autorisierten Web-Verkehr in ihr cloudbasiertes Rechenzentrum zulassen – ganz genau so wie im physischen Rechenzentrum. Der Web-Verkehr in physischen Rechenzentren wird in der Regel durch eine WAF gesichert. Das ist auch in der Public Cloud möglich.

Minderung von Angriffen auf die Anwendungsschicht in der Cloud

Bei der Auswahl von Lösungen zur Minderung unterschiedlicher Bedrohungen von Web-Anwendungen ist es wichtig, die richtigen Tools einzusetzen. Die erste Maßnahme ist in der Regel für alle Angreifer dieselbe, z. B. Zugang blockieren für zweifelhafte Quellen („bösartige IPs“) und Blockieren von Anfragen mittels vordefinierten Signaturen. Diese Schicht könnte gegen generische Attacken wie einen Botnetz-Angriff eingesetzt werden, der bekannte Schwachstellen ausnutzt. Je gezielter der Angriff ist, desto feinkörniger müssen die Tools zur Abwehr sein – genauso wie der Grad der Kontrolle durch das Sicherheitsteam. Im Falle einer gezielten Attacke auf einen speziellen Web-Service, ist zur Abwehr ein konfigurierbares Tool erforderlich.
Eine moderne, konfigurierbare WAF kann innerhalb des privaten Netzwerks eingesetzt werden und bietet dem Sicherheitsadministrator umfassende Kontrolle einschließlich Bereitstellungstopologie und Sicherheitskonfiguration. Eine WAF, die in der Public Cloud eingesetzt wird, muss verschiedene Schlüsselattribute unterstützen:

• Skalierbarkeit: Da Skalierbarkeit für Cloud-Umgebungen sehr wichtig ist, muss auch eine WAF-Lösung skalierbar sein, damit sie bei wachsender Last auch mehr Web-Verkehr verarbeiten kann. Die WAF-Tier sollte unabhängig von der Web Application Tier skaliert werden können, da geringer Verkehr, der nur schwer auf der WAF feststellbar ist, manchmal erhebliche Backend-Rechenkapazitäten beansprucht. In solchen Fällen ist eine Skalierung der WAF nicht notwendig, während die Web-Server möglicherweise zusätzliche Ressourcen benötigen. Der Einsatz unterschiedlicher Load Balancer für die einzelnen Tiers kann eine unabhängige Skalierung unterstützen.

• Hohe Verfügbarkeit: Um die geschäftliche Kontinuität jederzeit zu gewährleisten, muss die WAF hochverfügbar sein. Das bedeutet in der Regel, dass der WAF-Stack die nativen Cloud-Tools für Hochverfügbarkeit nutzen muss (z. B. Nutzung mehrerer Verfügbarkeitszonen in AWS oder als Teil des Availability Set in Azure).

• Automatisierung: Da Cloud-Umgebungen häufig hoch dynamisch sind, muss die gesamte Umgebung automatisiert werden. Automatisierung kann genutzt werden, um Umgebungen zu starten, zu skalieren, Richtlinien aufeinander abzustimmen und Wartungsmaßnahmen durchzuführen. Eine WAF in einer Cloud-Umgebung muss Tools bereitstellen, die eine Automatisierung ermöglichen. Die Automatisierung kann mittels nativer Ochestrierungsservices (wie CloudFormation in AWS und ARM in Azure) oder durch Third-Party-Tools (z. B. Puppet oder Chef) orchestriert werden.

• Zentrales Management für den Hybrideinsatz: Die Migration in die Public Cloud findet meistens über einen längeren Zeitraum statt. Dabei ist ein hybrider Einsatzmodus – bei dem ein Teil der Arbeitslast im physischen Rechenzentrum verbleibt und ein anderer in der Cloud liegt –absolut üblich. In Bezug auf den Betrieb wirft dies die Frage auf, wie sich die gleichen organisatorischen Sicherheitsrichtlinien sowohl im physischen Rechenzentrum als auch in der Cloud anwenden lassen. Hierzu bedarf es einer zentralen Managementlösung, die WAFs in beiden Szenarien bedienen kann.

Schlussfolgerung

Der Umzug aus dem vertrauten und gut geschützten Rechenzentrum in die Cloud ist ein großer Schritt. Aber dieser Schritt kann sicher gestaltet werden. Es braucht dazu nur eine sorgfältige Planung, um die richtigen Werkzeuge und die richtige Architektur zu finden. Die Auswahl einer agilen und leistungsstarken WAF ist ein solider erster Schritt.

Ihre Ansprechpartner bei ADN:
imperva@adn.de
02327 9912-206
www.adn.de/imperva

 

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>