Bundesamt für Sicherheit in der Informationstechnik

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 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.

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.

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:

  • Für Webanwendungen, auf die nur aus einem "relativ vertrauenswürdigen Netz" zugegriffen wird, bietet auch der vereinfachte Aufbau meist ein ausreichendes Sicherheitsniveau.
  • Handelt es sich bei der Webanwendung um eine Anwendung, auf die über das Internet zugegriffen werden kann oder haben die verarbeiteten Daten einen hohen Schutzbedarf, so sollte mindestens ein Reverse-HTTP-Proxy zur Absicherung des Webservers vor Angriffen aus dem Internet eingesetzt werden.
  • Werden auf dem Datenbankserver, der zu der Webapplikation gehört, noch weitere Datenbanken betrieben, so muss auch der Schutzbedarf dieser Daten in die Überlegungen einbezogen werden. In diesem Fall kommt der sicheren und sorgfältigen Konfiguration des Datenbankservers eine besondere Bedeutung zu. In diesem Fall wird der Einsatz eines Sicherheitsproxies für die Datenbankzugriffe dringend empfohlen.

Prüffragen:

  • Betrifft Architektur mit zwei ALG s und Paketfiltern: Sind alle Server durch ein ALG voneinander getrennt, um unberechtigte Übergriffe von einem Server auf einen anderen zu unterbinden?

  • Betrifft Architektur mit zwei ALG s und Paketfiltern: Ist der Web-Server durch einen Paketfilter und durch ein ALG abgesichert, um einen zusätzlichen Schutz gegenüber externen Angreifern zu bieten?

  • Betrifft vereinfachte Architektur ohne ALG s: Sind der Webserver,wie auch der Applikations- und der Datenbank-Server in einer separaten DMZ des Paketfilters untergebracht?

  • Betrifft vereinfachte Architektur ohne ALG s: Wird für externe Zugriffe auf den Webserver ein Reverse- HTTP -Proxy eingesetzt?

  • Sind die Entscheidungen und Gründe zur gewählten Architektur der Integration der Web-Anwendung dokumentiert?

  • Wird sichergestellt, dass Änderungen der Web-Anwendung den Sicherheitsanforderungen der Organisation entsprechen?

  • Betrifft Datenbankserver der Web-Anwendung auf denen weitere Datenbanken betrieben werden: Wird für alle Datenbank-Instanzen ein Sicherheitsproxy für die Datenbankzugriffe eingesetzt?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK