Die Anwendungsinfrastruktur absichern

Die Webanwendung selbst kann perfekt abgesichert sein, aber wenn die Infrastruktur dahinter Schwachstellen hat, nützt das wenig. Angreifer suchen immer das schwächste Glied im gesamten Stack.

Das 3-Tier-Modell

Eine klassische Webanwendungsarchitektur besteht aus drei Schichten (Tiers), die in separaten Netzwerksegmenten betrieben werden. Du kennst das Konzept der Netzwerksegmentierung und der DMZ (Demilitarized Zone) bereits aus Modul B5. Bei Webanwendungen wird dies in einer angepassten Form angewendet:

1. Presentation Tier (Webserver): Die Webserver nehmen HTTP-Anfragen entgegen, liefert statische Inhalte (HTML, CSS, Bilder) und leitet dynamische Anfragen an den Application Server weiter. Er steht in der DMZ und ist als einzige Schicht direkt aus dem Internet erreichbar.
2. Application Tier (Anwendungsserver): Diese Server enthalten die Geschäftslogik, also die eigentliche Anwendung. Sie verarbeiten Anfragen und kommunizieren mit der Datenbank. Sie stehen in einem geschützten Netzwerksegment hinter der DMZ.
3. Data Tier (Datenbankserver): Hier werden die Daten gespeichert. Dazu gehören Kundendaten, Bestellungen und Konfigurationen. Die Datenbankserver stehen im am stärksten geschützten Segment und sind nur von den Application Servern erreichbar.

Jede Schicht ist durch eine Firewall von der nächsten getrennt. Der Datenbankserver ist aus dem Internet niemals direkt erreichbar. Wenn ein Angreifer den Webserver in der DMZ kompromittiert, steht er vor der nächsten Firewall und hat keinen direkten Zugang zur Datenbank.

Schauen wir uns das am Beispiel des NovaHealth-Kundenportals an: Ein Patient ruft https://portal.novahealth-solutions.de auf. Der Webserver in der DMZ nimmt die Anfrage entgegen und leitet sie an den Anwendungsserver weiter. Dieser prüft die Authentifizierung, fragt die Patientendaten beim Datenbankserver ab und erzeugt die Antwort, die über den Webserver zurück an den Browser des Patienten geht. Die Patientendaten verlassen zu keinem Zeitpunkt das innerste Netzwerksegment ungeschützt.

Ein problematisches Beispiel aus der Praxis

Das 3-Tier-Modell ist heute bei Webanwendungen weit verbreitet. Aber nicht alle Anwendungen in Unternehmen sind Webanwendungen. In der Praxis findet man insbesondere bei älteren oder spezialisierten Anwendungen noch sogenannte 2-Tier-Architekturen: Eine Client-Anwendung auf dem Rechner des Benutzers kommuniziert direkt mit dem Datenbankserver, ohne separate Anwendungsschicht dazwischen.

Die Anwendungslogik befindet sich dabei typischerweise im Client und teilweise in der Datenbank. Der Client benötigt daher direkten Zugriff auf die Datenbank und entsprechende Zugangsdaten.

Bei 2-Tier-Anwendungen besteht ein besonderes Risiko, wenn Datenbank-Credentials direkt auf dem Client gespeichert werden. Sie können dann beispielsweise durch Reverse Engineering, aus Konfigurationsdateien oder aus dem Arbeitsspeicher ausgelesen werden. Mit diesen Zugangsdaten könnte sich ein Angreifer direkt am Datenbankserver anmelden und damit Sicherheitsmechanismen umgehen, die ausschließlich in der Client-Anwendung implementiert sind.

Wie weit der Zugriff reicht, hängt allerdings von den Berechtigungen des verwendeten Datenbankkontos ab. Deshalb ist gerade bei solchen Architekturen ein konsequentes Least-Privilege-Konzept auf Datenbankebene besonders wichtig.

Bei einer 3-Tier-Architektur wird dieses Risiko deutlich reduziert: Der Client kommuniziert mit der Präsentationsschicht der Webanwendung, nicht direkt mit der Datenbank. Datenbankzugriffe erfolgen über die serverseitige Anwendungsschicht, die auch die dafür erforderlichen Credentials verwaltet. Idealerweise ist die Datenbank zusätzlich so abgeschottet, dass nur die vorgesehenen Anwendungsserver darauf zugreifen können. Ein kompromittierter Client kann daher nicht ohne Weiteres direkt auf die Datenbank zugreifen.

⚠️ Die Lösung klingt zunächst einfach: eine Anwendungsschicht dazwischenbauen. In der Praxis ist die Umstellung einer bestehenden 2-Tier-Anwendung auf eine 3-Tier-Architektur jedoch mit erheblichem Aufwand verbunden und erfordert häufig tiefgreifende Änderungen an der Anwendung. Deshalb werden insbesondere ältere Warenwirtschaftssysteme und Branchensoftware bis heute als 2-Tier-Anwendungen betrieben.

Solche Anwendungen werden in Unternehmen häufig über Citrix bereitgestellt. Dabei läuft die Client-Anwendung nicht direkt auf dem Arbeitsplatzrechner des Benutzers, sondern auf einem zentralen Server. Der Benutzer erhält über Citrix lediglich Zugriff auf die dort ausgeführte Anwendung. Dadurch lässt sich eine ältere 2-Tier-Anwendung zentral bereitstellen, ohne sie grundlegend umbauen zu müssen.

Das löst jedoch das eigentliche Architekturproblem nicht. Die Anwendung bleibt eine 2-Tier-Anwendung: Sie kommuniziert weiterhin direkt mit der Datenbank und benötigt die entsprechenden Zugriffsrechte. Citrix kann dabei eine zusätzliche Sicherheitsschicht bilden, muss aber selbst konsequent gehärtet werden. Insbesondere muss verhindert werden, dass Benutzer aus der bereitgestellten Anwendung auf das zugrunde liegende Betriebssystem oder andere nicht vorgesehene Ressourcen zugreifen können.

Netzwerksegmentierung

Über das 3-Tier-Modell hinaus sollte das Netzwerk so segmentiert sein, dass verschiedene Anwendungen und Dienste voneinander isoliert sind. Das solltest du bereits wissen aus Modul B5, aber hier ein kleiner Reminder in Bezug auf Anwendungen:

• Verschiedene Anwendungen trennen: Das Kundenportal und die interne Verwaltung von NovaHealth laufen in unterschiedlichen VLANs oder Netzwerksegmenten. Wird eine Anwendung kompromittiert, ist die andere nicht automatisch betroffen.
• Umgebungen trennen: Produktions-, Staging- und Entwicklungsumgebungen müssen strikt getrennt betrieben werden. Testdaten in der Entwicklung dürfen nie echte Patientendaten enthalten.
• Management-Netzwerk isolieren: SSH-Zugang, Monitoring und Administration über ein separates Management-Netzwerk, das nicht über das Internet erreichbar ist.
• Container-Netzwerke einschränken: In Kubernetes-Umgebungen legen Network Policies fest, welche Container miteinander kommunizieren dürfen.

Das Ziel ist immer dasselbe: Wird ein System kompromittiert, begrenzt die Segmentierung den möglichen Schaden und erschwert einem Angreifer die weitere Ausbreitung im Netzwerk (Lateral Movement).

Datenbank absichern

Die Datenbank ist der wertvollste Teil der Infrastruktur, denn sie enthält die Daten, auf die es Angreifer abgesehen haben. Die sogenannten „Kronjuwelen“. Die Härtung der Datenbank ist daher besonders kritisch.

Härtungsmaßnahmen für Datenbanken:

• Netzwerkzugriff einschränken: Die Datenbank darf nur vom Application Server angesprochen werden. In der Konfiguration wird der Zugriff auf die IP-Adresse des Anwendungsservers beschränkt.
• Least Privilege für Datenbankbenutzer: Der Benutzer, den die Webanwendung verwendet, erhält nur die minimal notwendigen Rechte – SELECT, INSERT, UPDATE, DELETE auf die benötigten Tabellen. Das Prinzip Least Privilege kennst du aus Modul B1, hier muss es penibel angewendet werden.
• Verschlüsselung: Daten in der Datenbank verschlüsseln (Encryption at Rest) und Verbindungen zur Datenbank über TLS absichern (Encryption in Transit). Besonders bei sensiblen Daten wie Gesundheitsdaten ist das Pflicht.
• Standardkonfiguration ändern: Default-Passwörter (z.B. root ohne Passwort bei MySQL), Default-Ports (MySQL 3306, PostgreSQL 5432) und Beispiel-Datenbanken entfernen. Diese Standardeinstellungen sind öffentlich bekannt und werden von Angreifern als Erstes getestet.
• Regelmäßige Backups: Verschlüsselt, an einem getrennten Ort gespeichert und regelmäßig getestet. Ein Backup, das nie getestet wurde, ist kein Backup, wenn du nicht weißt, ob die Wiederherstellung funktioniert.

⚠️ Für Unternehmen im Gesundheitswesen wie NovaHealth gilt: Gesundheitsdaten gehören nach der DSGVO zu den besonders geschützten personenbezogenen Daten. Unternehmen müssen deshalb angemessene technische und organisatorische Maßnahmen treffen, um diese Daten zu schützen. Dazu gehören je nach Risiko insbesondere Verschlüsselung und konsequente Zugriffsbeschränkungen. Für bestimmte Anwendungen im Gesundheitswesen gelten darüber hinaus spezielle gesetzliche Anforderungen.

Bevor wir zum nächsten Thema übergehen, prüfe doch gleich mal, ob du die Infrastruktur-Konzepte verinnerlicht hast.