M 5.119 Integration einer Web-Anwendung mit Web-, Applikations- und Datenbank-Server in ein Sicherheitsgateway

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, IT-Sicherheitsbeauftragter

Zur Bereitstellung einer komplexen Web-Applikation ALG (beispielsweise einer E-Government-Anwendung oder eines Online-Shop) sind aufgrund des erhöhten Schutzbedarfs weitergehende Schutzmaßnahmen notwendig. Im Folgenden wird zu diesem Spezialfall ein Standardaufbau zur Bereitstellung einer Web-Applikation, bestehend aus Webserver, Applikationsserver und Datenbankserver, vorgeschlagen.

Architektur mit zwei ALGs und Paketfiltern

Das Sicherheitsgateway ist so angelegt, dass alle Server durch ein ALG voneinander getrennt sind, um unberechtigte Übergriffe von einem Server auf einen anderen zu unterbinden und eine Kontrolle über die eingesetzten Protokolle zu erhalten. Der Webserver ist sowohl durch einen Paketfilter als auch durch ein ALG abgesichert, um einen höchstmöglichen Schutz vor Angreifern aus dem nicht-vertrauenswürdigem Netz zu bieten.

Der Aufbau wurde so gewählt, dass jeder Server im Anwendungszusammenhang maximal zwei Kommunikationsverbindungen eingehen kann, die jeweils durch entsprechende ALGs abgesichert sind. Die folgende Tabelle stellt die Kommunikationsverbindungen zusammen:

Server Kommunikation mit Protokoll Bemerkung
Webserver Client aus dem externen Netz HTTPS Gegebenenfalls kann die verschlüsselte Verbindung bereits am ALG terminiert werden.
Siehe auch M 5.115 Integration eines Webservers in ein Sicherheitsgateway
Webserver Applikations-Server Anwendungs-spezifische Protokolle, beispielsweise SOAP, RPC, Corba o.ä. Für die Protokolle existieren ebenfalls Sicherheitsproxies
Applikations-Server Datenbank-Server
Datenbank Protokoll Siehe auch M 5.117 Integration eines Datenbank-Servers in ein Sicherheitsgateway

Tabelle: Kommunikationsverbindungen

Zusätzlich sind jeweils eventuell noch Zugriffe zur Administration aus dem internen Netz notwendig. Diese müssen auf entsprechende Administrationsrechner beschränkt werden und dürfen nur über entsprechend abgesicherte Protokolle (beispielsweise SSH) abgewickelt werden. Es sollte geprüft werden, ob auf eine physikalische Verbindung zu dem vertrauenswürdigen Netz ganz verzichtet werden kann, um einem Angriff durch Innentäter vorzubauen.

Die folgende Abbildung zeigt noch einmal die oben beschriebene Architektur. Die jeweils zugelassenen Kommunikationsverbindungen sind eingetragen.

Aufbau einer typischen Web-Applikation bestehend aus Webserver, Applikationserver und Datenbank

Vereinfachte Architektur ohne ALGs

Falls die Anwendung keine besonderen Sicherheitsanforderungen stellt können eventuell die ALGs wegfallen und der Webserver kann in einer DMZ des äußeren Paketfilters aufgestellt werden, der Applikations- und der Datenbankserver in separaten DMZs des inneren Paketfilters. Die Kommunikationsbeziehungen werden in diesem Fall nur durch entsprechende Paketfilterregeln eingeschränkt.

In diesem Fall besteht allerdings nicht mehr die Möglichkeit zur Kontrolle des Inhalts der Kommunikation. Wird auf ALG zwischen dem Client und dem Webserver verzichtet (Reverse-HTTP-Proxy) können beispielsweise keine HTTP-Anfragen aus dem nicht-vertrauenswürdigen Netz mehr auf Konformität mit der HTTP-Spezifikation überprüft und auf (im jeweiligen Zusammenhang) ungewöhnliche Inhalte getestet werden.

Es wird dringend empfohlen, zumindest für den Zugriff der Clients auf den Webserver ein entsprechendes ALG (Reverse-HTTP-Proxy) einzusetzen.

Die folgende Abbildung zeigt die vereinfachte Architektur mit zwei Paketfiltern. Die Kommunikationsbeziehungen sind wie in der obigen Tabelle beschrieben, nur dass keine protokollspezifischen Sicherheitsproxies eingesetzt werden.

Aufbau einer typischen Web-Applikation bestehend aus Webserver, Applikationserver und Datenbank ohne die Verwendung von ALGs

Ob für die jeweils eingesetzte Webapplikation der vereinfachte Aufbau ausreichend ist muss im Einzelfall geklärt werden. Die Entscheidung muss anhand des Schutzbedarfs der verarbeiteten Daten getroffen werden, keinesfalls dürfen ausschließlich Kostenargumente den Ausschlag geben. Die Entscheidung und die Gründe dafür müssen dokumentiert werden und es muss regelmäßig geprüft werden, ob sich die Voraussetzungen nicht geändert haben. Insbesondere bei Änderungen und Erweiterungen der Webanwendung muss sichergestellt sein, dass die Architektur noch den Sicherheitsanforderungen entspricht.

Die folgenden Punkte können bei den Erwägungen als Hinweise dienen:

Prüffragen: