Kontrollposten im Vorfeld von Randy Franklin Smith und Susanne Franke
Die meisten XML-Firewalls bieten auf irgendeine Art auch Audit-Funktionalität und Logging, sodass der Anwender nachvollziehen kann, was mit seinem Webservice geschieht. Verschlüsselung und XML-Parsing nehmen viel CPU-Ressourcen in Anspruch. Deswegen ist diese komplexe Proxy-Architektur vor allem für die Implementierung von SOAP-Firewalls in hochsicheren und auf große Datenmengen ausgerichtetete Webservices-Szenarien wichtig. Weil SOAP/XML Sicherheitsfunktionen auf Transportebene bieten, kann eine Firewall Secure Sockets Layer (SSL) und Transport Layer Security (TLS) verwenden, um den gesamten HTTP-basierten Nachrichtenstrom zu verschlüsseln.
In manchen Fällen ist es notwendig, Teile eines XML-Dokuments zu verschlüsseln oder digital zu signieren, beispielsweise um Transaktionen mit mehreren Beteiligten zu vereinfachen. Diese Anforderungen erfüllen die Standards XML-Encryption und -Signature. Aufgrund der Tatsache, dass eine XML-Firewall als Proxy-Webdienst fungiert, wird die Authentifizierung, Ver- und Entschlüsselung hier vorgenommen. Der Vorteil besteht darin, dass der Anwender zentral und konsistent die Authentifizierung, Verschlüsselung und Policy kontrollieren kann, auch wenn die Webservices auf verschiedene Server im Netzwerk verteilt sind. Nur entschlüsselte Verkehrsdaten lassen sich untersuchen, deshalb passiert dies in der Firewall, wobei die Inhalte mit der Policy verglichen werden – ein weiterer Pluspunkt für die XML-„Brandmauer“. SOAP-Firewalls gibt es entweder als Gerät oder als serverseitige Software auf dem Webserver. Beide Ansätze haben Vor- und Nachteile.