XML Web Services brauchen eine Firewall

Netzwerk-Firewalls sind der wesentliche Bestandteil der vorherigen Generation von Sicherheitsinfrastruktur. Der Gedanke hinter dieser Art Infrastruktur war in etwa wie folgt:

Wir können nicht von der Sicherheit all unserer Systeme abhängig sein. Lasst uns deshalb einen Umkreis definieren, in dem mit Hilfe von Netzwerk-Firewalls diese Systeme versteckt werden. Außerdem lasst uns den folgenden Mechanismus einrichten:

  • Definieren, welche IP-Adressen sich in diesem Umkreis befinden
  • Allem außerhalb dieses Umkreises nicht trauen
  • Nur dem trauen, was sich innerhalb dieses Umkreises befindet
  • Annehmen, dass die Ports, die für bestimmte Protokolle offen bleiben, die Sicherheit des Systems nicht zu sehr beeinträchtigen

Mit anderen Worten lautet die typische Frage, die durch eine Netzwerk-Firewall gelöst wird: „Soll dieses Datenpaket, das von einem Sender-IP an einen bestimmten Port des Ziel-IP gerichtet ist, durchgelassen werden?“

Die Sicherheit auf Anwendungsebene wirft andere Fragen auf und erfordert eine andere Lösung. Die typische Frage, die durch eine XML Application Firewall gelöst wird, ist: „Soll diese SOAP-Nachricht, die im Namen eines Anfordernden eines Services mit einer bestimmten Identität (von der zuständigen Authentifizierungsbehörde bestätigt) und mit der nötigen Vertrauenswürdigkeit und dem Non-Repudiation-Schutz gesendet wurde, an den Zielvorgang des Ziel-Web-Service weitergeleitet werden?“

Der Gedanke hinter dem Einsatz von XML Application Firewalls ist in etwa wie folgt: „Wir können nicht davon abhängen, dass alle uns zu Grunde liegenden Systeme nachweisbar sicher sind. Lasst es uns deshalb erforderlich machen, dass alle Anforderungen von Services durch eine XML Application Firewall geleitet werden, die verschiedenen Kategorien von Anfordernden bestimmte Zugangsstufen zuweist und gleichzeitig über mehrere Geschäftssysteme hinweg für beständige und überprüfbare Sicherheits- und Überwachungspraktiken sorgt.“

Organisationen werden sich allmählich klar, dass die alte Sicht der Dinge nicht mehr ausreicht. Netzwerk-Firewalls werden zwar weiterhin zentraler Bestandteil der Gestaltung eines Netzwerks sein, doch sie tragen den folgenden aktuellen Erfordernissen und Realitäten nicht Rechnung:

  • Die meisten Verstöße gegen die Sicherheitsvorkehrungen gehen von einem Punkt innerhalb des Bereichs der Firewall aus.
  • Wirtschaftliche Erfordernisse verlangen Zugang und Integration über die Firewall hinaus.
  • Ports, die bestimmte Protokolle passieren sollen, werden für eine große Zahl verschiedener Zwecke verwendet.
  • XML-Web-Service-SOAP-Nachrichten sind gerade deshalb entwickelt worden, um bestehende Firewalls leicht passieren zu können, indem sie mithilfe von Transportprotokollen (HTTP, SMTP usw.) gesendet werden, die gewöhnlich durch offene Firewall-Ports geleitet werden.
  • Nur wenige Knoten in einem Datennetzwerk mit XML Web Services werden neuer, mit modernen Mitteln (.NET, aktuelle J2EE-Apps-Server usw.) geschriebener Code sein. Legacy- und gepackte Anwendungen werden die Mehrzahl der Knoten darstellen. Die Sicherheitsniveaus dieser Anwendungen unterscheiden sich sehr stark voneinander, und es ist häufig schwer, ihre Sicherheitsfunktionen zu überprüfen und zu verwalten.

Zweck der XML Application Firewalls ist es, diese Erfordernisse gemeinsam mit der bestehenden Netzwerk-Firewall-Infrastruktur (anstatt diese zu ersetzen) zu erfüllen.

Themenseiten: IT-Business, Technologien

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

ZDNet für mobile Geräte
ZDNet-App für Android herunterladen ZDNet-App für iOS

Artikel empfehlen:

Neueste Kommentare 

1 Kommentar zu XML Web Services brauchen eine Firewall

Kommentar hinzufügen
  • Am 17. November 2003 um 10:19 von Guido Burchartz

    Projekterfahrungen
    Der Ansatz Sicherheit für XML/SOAP basierte Web Services quasi auf Netzwerkebene zu implementieren bringt unserer Erfahrungen nach noch weitere wesentliche Vorteile mit sich:
    – Nutzung zentraler Ressourcen für XML Firewall Dienste zur Vermeidung von Performance Gaps auf den Applikationsservern
    – Zentraler Policy Enforcement Point zur Durchsetzung eines einheitlichen Regelwerks
    – Plattformunabhängige Sicherheit (.Net, J2EE, …)
    – Strikte Aufgabentrennung: Applikationserstellung auf der einen Seite und Sicherheitskonzept auf der anderen Seite
    – Qualitätssicherung für Applikationen und deren Schnittstellen durch Prüfung auf Konformität zum Standard

    Ein Bericht zu praktischen Erfahrungen findet sich unter: http://www.avantgar.de/content/httpview/263

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *