Webapplikationen mit Unterstützung von XML

Navigation:

Inhalt -> 2 Grundlagen und Voraussetzungen -> 2.6 Sicherheitsaspekte und Verfügbarkeit

Neues und Änderungen << Vorheriges Kapitel | Nächstes Kapitel >>

Neben dem Umstand, dass Server für Webapplikationen gegen unerlaubtes Eindringen von Crackern durch Firewalls und regelmäßiges Einspielen der aktuellen Sicherheitspatches geschützt werden müssen, gibt es noch weitere Punkte, die einen sicheren und permanenten Betrieb einer Webapplikation ermöglichen. SSL erlaubt es, Daten, die zwischen Webserver und Webbrowser geschickt werden, zu verschlüsseln. Über eine VPN-Verbindung kann man über das Internet sicher in ein Intranet integriert werden und auf dessen Intranetanwendungen zugreifen. Der oder die Server und die Netzverbindung spielen bei Webapplikationen die entscheidende Rolle. Fällt der Server oder die Netzverbindung aus oder werden sie überlastet, kann mit der Anwendung nicht mehr vernünftig gearbeitet werden. Es müssen daher eine möglichst hohe Verfügbarkeitsrate und eine akzeptable Geschwindigkeit beim Server und der Netzverbindung gewährleistet werden. Schließlich müssen von den Daten der Anwendung laufend Sicherheitskopien (Backups) erstellt werden.

Normalerweise werden Daten im Internet unverschlüsselt als Klartext übertragen. Das heißt, jeder, der einen Rechner in einem Netzwerk hat, über das bestimmte Daten geschickt werden, kann mit geeigneten Werkzeugen die Daten mitlesen. Neben Webseiten und Formulardaten, die in HTML-Formularen eingegeben wurden, sind das auch zum Beispiel E-Mails und FTP. Bei diesen Diensten werden sogar die Passwörter im Klartext übertragen.

Bei Webapplikationen gibt es üblicherweise auch sensible Daten, die nicht in falsche Hände gelangen dürfen. Beispielsweise Kreditkartennummern beim Online-Shopping. Es wird daher ein Mechanismus benötigt, der es erlaubt, Daten, die zwischen Webclient und Webserver transferiert werden, sicher zu verschlüsseln.

Bereits 1994 wurde das SSL-Protokoll (Secure Socket Layer) von Netscape entwickelt. Seit 1996 gibt es die noch immer aktuelle SSL 3.0 Spezifikation [Heinzmann 2002]. SSL baut auf die Transportschicht, also im Internet auf TCP, auf und stellt seinen Dienst der Anwendungsschicht, also beispielsweise HTTP, zur Verfügung [Netscape 1998]. Mittlerweile unterstützen längst alle gängigen Webserver und Webbrowser die SSL-Spezifikation.

Um SSL verwenden zu können, benötigt man ein SSL Zertifikat. Bei verschiedenen Firmen, so genannten "Certification Authorities" (CA), können diese Zertifikate angefordert und erworben werden. Die bekannteste dieser Firmen ist Verisign (www.verisign.com). Anhand des SSL Zertifikats erkennt ein Client, ob er mit dem richtigen Server verbunden ist (Autorisierung). Gäbe es das Zertifikat nicht, könnte sich ein fremder Server unter Umständen als der eigentlich gewünschte Server ausgeben und mit dem Client eine sichere SSL-Verbindung aufbauen. Der fremde Server könnte dem Client vortäuschen, er wäre der echte Server und der Client würde dann sensible Daten an den fremden Server senden.

Mit dem SSL Zertifikat werden einige wichtige Daten, wie der Inhaber des Zertifikats, das Gültigkeitsdatum, die Server-Domain und auch ein öffentlicher Schlüssel (public key) des Servers versendet. Der Server verwendet einen privaten Schlüssel (private key), den nur er kennt, und der zum öffentlichen Schlüssel passt, der an den Client gesendet wird. Diese beiden Schlüssel passen insofern zusammen, als Daten, die mit dem privaten Schlüssel verschlüsselt wurden, mit dem öffentlichen Schlüssel entschlüsselt werden können und umgekehrt. Somit können Client und Server sicher miteinander kommunizieren: Der Server verschlüsselt mit seinem privaten Schlüssel. Der Client erhält diese Daten und entschlüsselt sie mit dem öffentlichen Schlüssel. Er verschlüsselt dann seine Daten mit dem öffentlichen Schlüssel, die dann der Server mit seinem privaten Schlüssel entschlüsseln kann.

Mit dieser Methode (Public-Key-Verschlüsselung) könnten Client und Server verschlüsselt Daten austauschen. Da die Public-Key Verschlüsselung aber aufwändig ist, wird sie nur für die Autorisierung und für den Austausch von so genannten symmetrischen Schlüsseln verwendet. Mit den symmetrischen Schlüsseln werden dann die Daten verschlüsselt. Das ist schneller als mit dem Public-Key Verfahren. [Netscape 1999] Die SSL 3.0 Spezifikation kann man unter [Freier 1996] finden.

Aktuell werden bei SSL üblicherweise 128-Bit-Schlüssel verwendet. Früher waren auch 40-Bit-Schlüssel im Einsatz. Immer schnellere Hardware würde es aber immer leichter erlauben, solche kurzen Schlüssel mit Brute-Force-Verfahren28 zu knacken.

Im Webbrowser erkennt man SSL anhand dem Kürzel "https://" anstelle von "http://" am Beginn der URL. Zusätzlich blenden die meisten Browser in der Statuszeile ein entsprechendes Symbol (beispielsweise ein geschlossenes Vorhängeschloss oder einen Schlüssel) ein. Dies soll verdeutlichen, dass die Daten verschlüsselt und damit sicher übertragen werden. HTTP-Verbindungen über SSL verwenden üblicherweise den Port 443, anstelle von Port 80, wie das normalerweise bei HTTP der Fall ist.

Zu beachten ist, dass die Verschlüsselung äußerst rechenintensiv ist. SSL sollte daher nur dort eingesetzt werden, wo es unbedingt nötig ist.

Mittlerweile hat die Internet Engineering Task Force (IETF) den ursprünglich proprietären Standard SSL von Netscape übernommen und in TLS (Transport Layer Security) umbenannt. 1999 wurde die Version 1.0 herausgebracht. Diese und auch der aktuelle Entwurf 1.1 unterscheiden sich allerdings nur leicht vom SSL 3.0 Standard. [IETF-TLS 2003] [Curphey 2002]

Eine Webapplikation, die in einem LAN einer Firma oder Organisation läuft, kann durch eine Firewall vor Zugriffen von außen geschützt werden. Es kann aber vorkommen, dass nicht nur innerhalb dieses LANs auf die Webapplikation zugegriffen werden soll. So könnte es notwendig sein, dass beispielsweise auch eine entfernte Zweigstelle, ein Kunde oder Lieferant, ein Teleworker oder ein Außendienstmitarbeiter mit seinem mobilen Rechner auf die Webapplikation zugreifen soll. Eine Möglichkeit wäre, die Webapplikation vom Internet aus zugänglich zu machen, den Zugang mittels Passwörtern nur für bestimmte Benutzer zu erlauben und die Daten mittels SSL zu verschlüsseln.

Eine alternative Vorgehensweise ist der Einsatz eines Virtual Private Network (VPN). Eine Möglichkeit ist dabei eine Leitung zwischen den Standorten (Firma, Zweigstellen, Kunden, Lieferanten, etc.) zu mieten. Hierbei spricht man von einem "Trusted" VPN. Man muss dem Anbieter der Leitung vertrauen, dass die Daten auf der gemieteten Leitung sicher sind [VPNC 2003].

Wenn die Distanzen zwischen den Standorten groß sind, oder wenn nur selten oder wenige Daten übertragen werden, dann sind gemietete Leitungen allerdings viel zu teuer. Bei Außendienstmitarbeitern, die von verschiedenen Standorten auf das Firmennetz und auf die dort laufende Webapplikation zugreifen wollen, ist dieser Ansatz nicht möglich. Es bietet sich daher folgendes an: Die Daten werden verschlüsselt und über das Internet zum entfernten Rechner oder Netzwerk geschickt und dort wieder entschlüsselt. Man spricht hier von einem "Secure" VPN, da die Daten durch Verschlüsselung sicher gegen Abhören und Verändern sind.

Abbildung 6: Schema eines Virtual Private Network.

Der Vorteil bei dieser Art von VPN ist, dass hier die meist bereits vorhandene Internetverbindung verwendet werden kann. Es muss daher auch nur diese Verbindung bezahlt werden. Durch die Verschlüsselung kommt es allerdings zu Performanzeinbußen.

VPN-Lösungen gibt es sowohl in Software als auch in Hardware. Bei geringem Datenaufkommen bieten sich Softwarelösungen an. Bei hohem Aufkommen sind eigene VPN-Geräte zu bevorzugen, weil diese für die Verschlüsselung der Daten optimiert sind.

Bei weniger kritischen Anwendungen kann es genügen, regelmäßige Backups zu erstellen und dafür zu sorgen, dass Ersatzteile rasch besorgt werden können. Für etwas kritischere Einsatzgebiete eignen sich professionelle Server mit redundanten Festplattenspeichern und Netzteilen. Zusätzlich sollte zumindest eine zweite Netzanbindung und eine USV (Unterbrechungsfreie Stromversorgung) vorhanden sein. Das sind die Teile, die am häufigsten ausfallen.

SCSI RAID

Als redundanter Festplattenspeicher wird meist SCSI (Small Computer System Interface) RAID (Redundant Array of Inexpensive Disks) eingesetzt. Bei RAID unterscheidet man verschiedene "Levels". Die am meisten verbreiteten Levels sind 0, 1 und 5.

Bei Level 1 ("Mirroring") werden die gleichen Daten auf zwei Platten parallel geschrieben. Das Schreiben ist daher gleich schnell oder langsamer als bei einer Platte. Beim Lesen können unterschiedliche Daten von den Platten gelesen werden. Es ist daher schneller als mit nur einer Platte. Fällt eine Platte wegen eines Defekts aus, kann mit der noch funktionierenden weitergearbeitet werden. Der Nachteil bei Level 1 ist, dass nur die Speicherkapazität einer Platte zur Verfügung steht. [RAID.edu 2003]

Bei RAID Level 5 werden die Daten in Blöcke geteilt und diese auf die verschiedenen Platten aufgeteilt. Angenommen es sind fünf Platten vorhanden, dann werden die Datenblöcke auf vier Platten geschrieben und die fünfte Platte enthält die zu den vier Blöcken gehörende Paritätsinformation. Dabei sind nicht alle Paritäts-Blöcke auf der gleichen Platte, sondern auf alle Platten gleichmäßig verteilt. Fällt eine Platte aus, können die Daten von den anderen Platten gelesen werden. Ist der zerstörte Teil die Paritätsinformation, kann sie aus den Datenblöcken der restlichen Platten wieder neu berechnet werden. Ist ein Datenblock zerstört, kann er mithilfe der restlichen Datenblöcke und der Paritätsinformation wieder ermittelt werden.

Für RAID Level 5 sind mindestens drei Platten notwendig. Bei n Platten kann die Kapazität von n-1 Platten genützt werden. Lesen und Schreiben ist ebenfalls bis zu n-1 mal schneller als mit nur einer Platte.

Bei Servern wird meist SCSI-RAID Hardware eingesetzt, die "hot plug"-fähig ist. Das bedeutet, dass eine defekte Platte während des Betriebs ausgetauscht werden kann. Es wird automatisch dafür gesorgt, dass die Daten auf der neuen Platte wieder restauriert werden.

Der Vollständigkeit halber sei noch RAID Level 0 (Stripping) erwähnt. Es genügt dem Akronym "RAID" eigentlich nicht, weil hier keine Datenredundanz vorhanden ist. Die Datenblöcke werden nacheinander gleichmäßig auf zwei oder mehr Platten verteilt. Lesen und Schreiben ist daher schneller, allerdings steigt sogar die Fehlerrate, da beim Defekt einer Platte die Daten zerstört sind. Die Wahrscheinlichkeit, dass von zwei Platten eine defekt wird, ist natürlich höher, als dies bei nur einer Platte der Fall ist.

Höhere Anforderungen an die Ausfallsicherheit

Werden noch höhere Anforderungen bezüglich der Ausfallsicherheit verlangt, müssen alle Geräte redundant ausgeführt werden. Meist werden hier Cluster-Systeme eingesetzt. Fällt ein Rechner im Cluster-System aus, übernimmt ein anderer Rechner dessen Aufgabe. Wichtig ist hierbei, einen so genannten "Single Point of Failure" (SPOF) zu vermeiden. Es nutzt wenig, wenn die Server vollständig redundant ausgelegt sind, aber alle Server über denselben Router an das Netz angebunden sind.

Eine Webseite soll nicht nur eine möglichst hohe Verfügbarkeit aufweisen, sondern auch eine akzeptable Geschwindigkeit. Die Server müssen daher auch bei Belastungsspitzen genügend Reserven aufweisen. Bei Intranet (LAN) Anwendungen sind die Netzwerke üblicherweise sehr schnell und die Wege kurz. Bei Internet-Anwendungen können deutliche Verzögerungen durch das Netzwerk auftreten. Die Anbindung an das Internet und die sinnvollerweise vorhandene Backup-Anbindung müssen daher ebenfalls genügend Reserven für die Belastungsspitzen aufweisen. Zusätzlich sollten die Webseiten inklusive der Grafiken möglichst klein sein (Richtwert: 50 KB).

Interessant ist in diesem Zusammenhang die Möglichkeit, den HTML-Quelltext komprimiert zu übertragen. Das bringt vor allem bei langsamen Internetanbindungen (Modems) einen deutlichen Geschwindigkeitsvorteil. Der Quelltext kann dabei typischerweise auf 10 bis 20 Prozent seiner ursprünglichen Größe reduziert werden, wodurch die Seiten (ohne Grafiken) fünf bis zehn mal schneller vom Webserver ausgeliefert werden können. (Links für mehr Information zur gzip-Kompression von Webseiten unter Apache: sourceforge.net/projects/mod-gzip/, unter IIS: www.15seconds.com/issue/020314.htm, in PHP: www.php.net/manual/en/function.ob-gzhandler.php; Test auf Komprimierung: leknor.com/code/gziped.php.)

Wenn eine Webseite abgerufen wird, muss der Webbrowser zuerst den Webserver kontaktieren und ihm mitteilen, welche Seite er benötigt. Der Webserver wiederum muss die Seite an den Webbrowser senden. Je nach Entfernung zwischen Webbrowser und Webserver entstehen dadurch Verzögerungen. Um die Verzögerungszeit möglichst gering zu halten, empfiehlt es sich, den Serverstandort bzw. die Netzanbindung dort zu wählen, wo auch die meisten Benutzer zu erwarten sind. Typische Verzögerungszeiten innerhalb des deutschsprachigen Raums sind unter 50 ms. Bei Transatlantikverbindungen typischerweise zwischen 100 und 200 ms.

Bei den Backupstrategien unterscheidet man zwischen vollständigen und inkrementellen Backups. Bei vollständigen Backups wird der gesamte Datenbestand gesichert. Bei inkrementellen Backups werden nur die Änderungen seit dem letzten (oder dem letzten vollständigen) Backup gesichert. Das spart Zeit und Speicherplatz. Die Wiederherstellung ist allerdings komplizierter. Eine sinnvolle Vorgehensweise wären etwa wöchentliche und monatliche vollständige Backups und tägliche inkrementelle Backups. [Krosch 2001]

28Dabei wird nur mit hoher Rechenleistung versucht, durch Durchprobieren aller Möglichkeiten den korrekten Schlüssel ausfindig zu machen. Oft werden hier viele Rechner zusammengeschaltet, um gemeinsam eine Lösung zu finden.