Sicherheit für Legacy-Anwendungen in der Cloud

Beim Weg die IT-Infrastruktur eines Unternehmens vom lokalen Rechenzentrum in die Cloud zu verschieben, gibt es viele Herausforderungen. Abgesehen davon, dass sich nicht jede Anwendung von Haus aus für den Betrieb in der Cloud eignet, gibt es gerade bei vielen Legacy-Anwendungen neben diesen eher technischen Problemen häufig bekannte Schwachstellen, wie z.B. Cross-Site-Scripting (XSS) oder dem fehlenden Schutz vor Cross-Site-Request-Forgery (CSRF). Doch gerade hier bietet der Weg in die Cloud auch Chancen diese Sicherheitsprobleme zu adressieren.

Oftmals gibt es in Unternehmen Legacy-Anwendungen, die für das Tagesgeschäft benötigt, aber nicht mehr aktiv weiter entwickelt werden bzw. der Hersteller die Wartung der Software ganz oder zum Teil eingestellt hat. Eine Ablösung dieser Anwendungen ist vielleicht für die nächsten Jahre geplant, das Projekt aber noch nicht einmal gestartet. Werden in diesen Anwendungen Sicherheitslücken gefunden, ist es oftmals schwierig oder zumindest sehr langwierig diese zu
schließen. Ein gutes Beispiel für so eine, plötzlich entdeckte Sicherheitslücke ist die im Jahr 2021 unter dem Namen "log4shell" bekannt gewordene Remote-Code-Execution-Lücke im weit verbreiteten Logging-Framework Log4j (CVE-2021-44228). Diese mit einem CVSS 3.0 Wert von 10.0 als kritisch eingestufte Lücke stellte ein hohes Risiko für die IT-Infrastruktur von Unternehmen dar. Viele Softwarehersteller benötigten mehrere Wochen, um eine aktualisierte Version ihrer Anwendung zur Verfügung zu stellen. In der Zwischenzeit, bis der Patch eingespielt war, war man der Lücke ohne weitere Schutzmaßnahmen ausgeliefert. Das BSI empfahl sogar in einem Rundschreiben nicht zwingend benötigte Anwendungen abzuschalten. Für Anwendungen, die wegen der Kritikalität für die Geschäftsprozesse im Unternehmen nicht abgeschaltet werden konnten, empfahl das BSI den Einsatz einer Web Application Firewall und die Verwendung von Netzwerksegmentierung zur Isolierung der betroffenen Systeme. Gerade hier haben in der Cloud betriebene Anwendungen einen großen Vorteil. Die Isolation der betroffenen Anwendung in einem eigenen Netzwerksegment ist in der Cloud mit den entsprechenden Policies schnell zu realisieren. Darüber hinaus bieten alle großen Cloud-Provider eine Web Application Firewall (WAF) als Feature, welches häufig recht simpel aktiviert und, wie im folgenden Bild dargestellt, einer Anwendung vorgeschaltet werden kann.

(Bildquelle: https://learn.microsoft.com/de-de/azure/web-application-firewall/ag/application-gateway-web-application-firewall-portal )

Im Falle der bereits angesprochenen Log4J-Lücke wurden innerhalb weniger Tage reguläre Ausdrücke bekannt, mit denen man HTTP-Requests auf potenzielle Angriffe auf diese Lücke untersuchen konnte. Diese wurden zeitnah in die, von den Cloud-Providern zur Verfügung gestellten Regelwerke aufgenommen (siehe https://aws.amazon.com/de/security/security-bulletins/AWS-2021-005/) um dahinterliegende, für log4shell anfällige Anwendungen zu schützen.

Doch mit dem einfachen Aktivieren einer Web Application Firewall ist es nicht getan. Eine WAF beinhaltet ein komplexes Set an Regeln, welches auf die entsprechenden Bedürfnisse der Anwendung angepasst werden sollte. Zum einen ist dies aus Kostengründen ratsam, da sich die laufenden Kosten einer Web Application Firewall in der Cloud häufig unter anderem aus der Anzahl der aktivierten Regeln und Regelwerke zusammensetzten. Regeln, die zum Schutz einer auf WordPress basierenden Webseite dienen, müssen bei einer selbst implementierten Spring- Boot-Anwendung nicht aktiviert werden, da sie hier keinen Mehrwert bringen und lediglich zusätzliche Kosten verursachen oder im schlimmsten Falle gewünschte Funktion negativ beeinträchtigen. Zum anderen birgt auch jede aktivierte WAF-Regel die Gefahr HTTP-Requests fälschlicherweise als gefährlich anzusehen und zu blocken. Sogenannte False Positives sind, gerade bei Regeln für SQL-Injection (SQLi) oder Cross-Site-Scripting (XSS) keine Seltenheit und führen oftmals dazu, legitime Benutzer abzuschrecken. Daher gilt es, so viele Regeln wie notwendig und so wenige wie möglich zu aktivieren. False Positives, die trotzdem auftreten, können mit Hilfe von Ausschlusslisten, bei Azure "exclusion list" oder bei AWS "safe list" genannt, unterdrückt werden.

Neben dem Schutz vor bekannten Sicherheitslücken bieten die WAFs der Cloud-Provider häufig noch weitere Features. Hier findet man Bot-Protection, IP-Sperrlisten, Rate Limiting, Geoblocking und weitere Dinge. Je nach Provider heißen diese Features unterschiedlich, ähneln sich aber in der Praxis sehr stark. Um zum Beispiel das Rate Limiting in der WAF von AWS zu konfigurieren muss einfach eine neue Regel vom Typ "Rate-based rule" angelegt werden. Das Rate Limiting basiert hierbei auf der IP-Adresse des Requests. Der Schwellwert, der pro 5 Minuten erlaubten Requests pro IP-Adresse kann, je nach Wunsch konfiguriert werden. Bei Microsoft Azure ist dies ganz ähnlich, hier muss eine Regel vom Typ "Rate Limit" angelegt werden. Neben dem Schwellwert lässt sich bei Azure auch das Zeitintervall für den Schwellwert, 1 oder 5 Minuten, konfigurieren. Auch in der Google Cloud kann ein Rate Limiting in Cloud Armor konfiguriert werden. Cloud Armor bietet die meisten Möglichkeiten das Rate Limiting auf die eigenen Bedürfnisse anzupassen.

Auch das Thema zentrales Logging und Monitoring ist in der Cloud mit wenigen Handgriffen eingerichtet. So können die existierenden Anwendungslogs einer virtualisierten oder auch containerisierten Anwendung an ein zentrales Log-Management System geschickt werden. Je nach Anbieter gibt es unterschiedliche Lösungen wie Amazon CloudWatch, Azure Monitor oder Google Cloud Logging. Metriken wie CPU-Auslastung und Speicherverbrauch oder die Logs von Cloud-Komponenten wie der WAF stehen dort üblicherweise ebenfalls automatisch zur Verfügung. Aufbauend auf diese zentral gesammelten Daten lassen sich bei den großen Anbietern wie Google, Amazon oder Microsoft automatische Benachrichtigungen konfigurieren, so dass man z.B. bei einer Häufung von fehlerhaften Login-Versuchen alarmiert wird. Der Zugriff auf die Log-Daten kann im Übrigen ebenfalls sehr einfach gesteuert werden. So kann Mitarbeitern der Zugriff auf die Logs von bestimmten Anwendungen erlaubt von anderen Anwendungen untersagt werden, frei nach dem Need-to-know-Prinzip.

Eine weitere Chance für Legacy-Anwendungen bieten die Identity and Access Management (IAM) Lösungen der Cloud Provider. Mit ihrer Hilfe lässt sich eine Single Sign-on (SSO) Authentifizierung für den Zugriff auf die Anwendung erzwingen. Dafür gibt es zum Beispiel bei Azure sogenannte Application Proxys, die der Anwendung vorgeschaltet werden und sich, für die Anwendung transparent um die Authentifizierung kümmern. Die Berechtigung zum Zugriff auf die Anwendung kann dann ebenfalls an zentraler Stelle verwaltet werden.

Fazit

Oftmals schrecken Unternehmen vor dem Weg in die Cloud zurück. Sicherlich bringt dieser Weg auch Nachteile mit sich, auf die hier nicht näher eingegangen wurde. Außerdem ließen sich viele der hier angesprochenen Themen mit entsprechendem Aufwand auch im eigenen Rechenzentrum umsetzten. Trotzdem bietet die Cloud in der Regel die größere Flexibilität und viele vorgefertigte, aufeinander abgestimmte Lösungen. Daher lohnt es sich, zumindest einmal die Vor- und Nachteile einer Migration seiner Altanwendung(en) in die Cloud genau abzuwägen und den Schritt doch zu wagen.