Web Application Firewall: Sicherheit auf die Client-Seite ausgeweitet

Einführung einer neuen Generation von WAF

(25.02.10) - Deny All, Anbieterin für Sicherheit und Beschleunigung von Web-, XML- und FTP-Anwendungen, kündigt ihre neueste Version der Sicherheitslösung für Web/XML-Anwendungen "rWeb 4.0" mit einer Vielzahl an Neuheiten im Bereich Sicherheit, Performance und Management an.

Die meisten Web Application Firewalls (WAFs) schützen nur die "klassischen" Schichten (HTTP, SMTP,...) und so ist der Schutz der Web Services vernachlässigt. "rWeb" bietet ein integriertes Modul an, das vollständig auf Web Services ausgerichtet ist. Vereinfacht in der Benutzung, steigert es die funktionelle Absicherung im Vergleich zu der bisherigen rWeb-Version 3.8.

Die Sicherheit der Web Anwendungen auf den Client ausgeweitet

Deny All erweiterte den Funktionsumfang, indem die Sicherheit auf die Client-Seite ausgeweitet wird. Dies geschieht durch eine neue Funktion in rWeb, der "Client Sanitization". Diese bietet eine Art "Schutzblase" auf der Ebene des Navigators, die zum Beispiel die Keylogger (Software-programmspione) oder andere Trojaner daran hindert, die Daten des Internetbenutzers zu speichern oder finanzielle Transaktionen zu gefährden.

Eine aktiv-aktiv Hochverfügbarkeit

Künftig können zwei rWeb-Systeme parallel arbeiten, um den Traffic aufzuteilen und zu verwalten (aktiv/aktiv). Zurzeit bietet nach eigenen Angaben kein anderer Hersteller diesen Mechanismus standardmäßig an, sondern nur als Option. Ab jetzt - wenn die Auslastung eines Systems zu groß wird - wird diese automatisch auf das zweite System verteilt. Diese Architektur kann vervielfältigt werden, sodass 3, 4 oder mehr rWeb-Systeme zusammenarbeiten. Dieser Active-Active-Mechanismus erlaubt Modularität und Flexibilität für Funktionen. Der Kunde ist somit frei in der Gestaltung seiner Architektur.

Verteilung von verschiedenen rWeb Funktionen auf mehrere Komponenten

Es ist ebenfalls möglich, rWebs mit verteilten Funktionen auf verschiedenen Systemen zu konfigurieren. Das heißt zum Beispiel, dass während ein rWeb für Caching und Compression verantwortlich ist, ein zweites rWeb-System nur mit der Black-List arbeiten und ein Drittes die Sicherheit nur mit der Scoring-List bieten kann. Die Anzahl der Server muss nicht im gleichen Verhältnis zu den Funktionen stehen, es können z.B. drei Front-End-Server für die Verwaltung des Caches zuständig sein, einer für die Security und zwei für das Load Balancing.

Eine vereinfachte Benutzeroberfläche (GUI) und eine Programmierschnittstelle "a la carte"

Die GUI wurde vollständig neu entwickelt, um wesentlich benutzerfreundlicher zu sein und eine vereinfachte Konfiguration anzubieten. Ein API wurde ebenfalls zur Verfügung gestellt, um die Administration so weit wie möglich zu vereinfachen.

Somit ist es für den jeweiligen verantwortlichen Adminstrator nicht unbedingt notwendig, alle Funktionen von rWeb zu bedienen. Er kann die anzeigen lassen, die er wünscht und im Gegensatz dazu jene ausblenden, die ihn nicht betreffen. (Deny All: ma)