Bundesamt für Sicherheit in der Informationstechnik

M 5.175 Einsatz eines XML-Gateways

Verantwortlich für Initiierung: Verantwortliche der einzelnen Anwendungen, Leiter IT

Verantwortlich für Umsetzung: Administrator, Leiter IT

Durch eine klassische Firewall kann sichergestellt werden, dass in geschlossenen Umgebungen nur Endgeräte mit berechtigten IP-Adressen auf einen Web-Service zugreifen können (Whitelisting) oder dass bei im Internet verfügbaren Web-Services IP-Adressen, von denen Angriffe, etwa durch Botnetze, ausgehen, gesperrt werden können (Blacklisting). Zu Details siehe M 4.454 Schutz vor unerlaubter Nutzung von Web-Services . Derartige Firewalls sind jedoch typischerweise nicht in der Lage, SOAP -Nachrichten zu analysieren und Angriffe auf der Anwendungsschicht ( SOAP / HTTP ) zu erkennen. Daher sollte, insbesondere bei erhöhtem Schutzbedarf, zum Schutz von Web-Services der Einsatz eines sogenannten XML -Gateways in Erwägung gezogen werden, das diese Filterung auf XML -Ebene leistet.

Ein XML -Gateway ist eine Infrastrukturkomponente, die zwischen Web-Service und Consumer geschaltet wird und dabei als eine Firewall für Nachrichten in einer Web-Service-Infrastruktur agiert. Sie leistet damit für Web-Services das, was eine Web Application Firewall (WAF) für Webanwendungen ausführt. Beide stellen Ausprägungen sogenannter Application Level Gateways (ALG) für unterschiedliche Anwendungsprotokolle dar. Das XML -Gateway fängt XML -Nachrichten ab, um sie nach definierten Vorgaben zu analysieren, bevor sie an den Web-Service weitergeleitet werden. Dafür kommt üblicherweise ein leistungsstarker, gehärteter Parser zum Einsatz, der eine definierte Sicherheitsrichtlinie anwendet und teilweise auch über Heuristiken verfügt, die das Erlernen typischer Kommunikationen erlaubt. So können etwa plötzlich sprunghaft anwachsende Nachrichtengrößen erkannt werden und definierte Aktionen und Alarme auslösen.

Ein XML -Gateway (auch als XML-Firewall, Web-Service-Firewall, Web-Service-Security-Gateway oder XML-SOAP-Proxy bezeichnet) ist eine Komponente, die dem Schutz von Diensten vor Angriffen über XML -basierte Schnittstellen dient, indem es XML -Daten prüft, die die Institution erreichen oder verlassen. XML -Gateways können als eigenständige Systeme oder auch als Komponente eines Enterprise Service Bus (ESB) realisiert werden.

Folgende Funktionen werden typischerweise bereitgestellt:

  • Auslagerung von Authentisierung und Autorisierung an das Gateway
  • Zugriffskontrolle durch Zertifikate, SAML, LDAP , RADIUS und ähnliche Methoden
  • Begrenzung von Datenraten als Maßnahme gegen Denial-of-Service-Angriffe
  • Ver- und Entschlüsselung auf Transport- oder Nachrichtenebene
  • Anbringung und Prüfung von XML -Signaturen
  • Kontrolle von Datenflüssen
  • Validierung von XML -Nachrichten anhand von Schemata und Policys
  • Schutz vor in XML eingebetteten Angriffen wie Cross-Site Scripting, SQL-Injection oder Command-Injection
  • Schutz vor bestimmten SOAP -/ XML -spezifischen Angriffen wie zu großen Nachrichten, zu stark verschlüsselten Elementen, rekursivem Parsen, bösartig manipulierten Schemata oder WSDL-Dateien sowie Angriffen auf das Routing
  • Scannen von SOAP -Body sowie SOAP -Attachments auf Schadsoftware
  • Unterstützung verschiedener Web-Service-Sicherheitsstandards wie WS-Security, WS-SecureConversation, WS-Trust oder WS-Federation
  • Auslösen von Alarmen, teilweise durch Anomalie-Erkennung in der Kommunikation
  • Teilweise auch Dienstvirtualisierung durch URL-Rewriting, XSL-Transformationen und SOAP -basiertes Routing

Modelle verschiedener Hersteller unterscheiden sich vor allem im Daten-Durchsatz und der Latenz der Verbindung, in Funktionen zur Sicherstellung der Verfügbarkeit durch redundante Systeme, den vorhandenen Zertifizierungen (etwa nach Common Criteria), Unterstützung für Identitäts- und Zugriffsmanagement (etwa durch SAML, OAuth oder für SSO-Lösungen), Konfigurationsmöglichkeiten und Erweiterbarkeit.

Für den Einsatz eines XML -Gateways sollte daher im ersten Schritt eine Anforderungsanalyse erfolgen, in der die erforderlichen und wünschenswerten Funktionen ermittelt werden. Werden XML -Gateways bei höherem Schutzbedarf eingesetzt, sollten zudem die zu erreichenden Sicherheitsziele definiert werden.

XML -Gateways sind in der Lage, den eingehenden Datenverkehr auf bösartige Inhalte zu untersuchen und diese herauszufiltern, damit eine Verarbeitung auf dem Endsystem gar nicht erst erfolgen kann. So können zum Beispiel vom Angreifer konstruierte fehlerhafte XML -Nachrichten bereits am Gateway herausgefiltert werden (siehe G 5.183 Angriffe auf XML ). Die Gateways bieten oft auch eine ausgehende Datenflusskontrolle an, die zu verhindern versucht, dass sensible Inhalte aus dem internen Netz exfiltriert werden.

Damit kann ein XML -Gateway die meisten Aufgaben übernehmen, die in den Maßnahmen M 4.454 Schutz vor unerlaubter Nutzung von Web-Services und M 4.393 Umfassende Ein- und Ausgabevalidierung bei Webanwendungen und Web-Services gefordert werden. Die Validierung eines Schemas etwa (siehe M 4.454 Schutz vor unerlaubter Nutzung von Web-Services ) kann entweder bereits am XML -Gateway oder direkt auf dem System erfolgen, welches den Web-Service bereitstellt. Die Entscheidung, an welcher Stelle die Validierung erfolgen soll, ist bereits in der Planung zu dokumentieren, da dies auch Auswirkungen auf die Gesamtarchitektur haben kann.

Folgende Vorteile ergeben sich beim Einsatz eines XML -Gateways:

  • XML -Gateways sind für ihren Einsatzzweck optimiert. Das bedeutet in der Regel, dass sie speziell gehärtet und dadurch robust sind.
  • Da in die Entwicklung viel Wissen über XML -basierte Angriffe und entsprechende Sicherheitsmaßnahmen geflossen ist, erlauben XML -Gateways die sichere Nutzung von Web-Services, wenn sie richtig konfiguriert werden.
  • Einer der größten Vorteile eines XML -Gateways ist die Verwaltung der verschiedenen Aspekte einer Web-Service-Sicherheitsrichtlinie an einer zentralen Stelle (häufig in einem Web-Interface), anstatt für jeden Dienst einzeln. Dies kann helfen, Konzeptions- und Konfigurationsfehler zu vermeiden. Das Managementinterface ist geeignet abzusichern.

Nachteile, die aus dem Einsatz eines XML -Gateways erwachsen können, sind die folgenden:

  • Wie bei anderen ALGs auch ist die Konfiguration eines XML -Gateways nicht trivial, sondern erfordert sorgfältige Planung und gründliches Testen. Dies gilt nicht nur für die Inbetriebnahme, sondern auch für alle Änderungen am Kommunikationsverhalten der betroffenen Web-Services.
  • Ein XML -Gateway ist zwar wartungsarm, aber nicht wartungsfrei. Auch hier sollten regelmäßig Software- und Signaturupdates eingespielt werden, falls der Hersteller solche anbietet. Auch auf das Bekanntwerden von Schwachstellen für das Gateway sollte geachtet und reagiert werden.
  • Durch den Einbau eines weiteren Systems in die Verarbeitungskette steigt das Risiko eines Verlusts der Verfügbarkeit durch Konfigurations-, Software- oder Hardwarefehler. Bei hohem Verfügbarkeitsbedarf sollte eine redundante Auslegung erfolgen.
  • Insbesondere wenn das Gateway auch die Prüfung auf Schadsoftware übernimmt, können Fehlalarme zu Beeinträchtigungen der Funktionalität und Verfügbarkeit führen. Daher ist neben ausführlichem Testen auch eine Abwägung der Risiken gegeneinander durchzuführen sowie gegebenenfalls ein Notfallkonzept zu erstellen.
  • Bestimmte Angriffstypen sind komplex und entwickeln sich laufend weiter, sodass nicht davon ausgegangen werden darf, dass das XML -Gateway jede Variante des Angriffs erkennen kann. Beispiele sind XML Signature Wrapping-Angriffe (XSW) oder neuere Angriffe auf TLS/SSL wie etwa CRIME.
  • Gerade bei ressourcenkritischen Services mit vielen kryptographischen Operationen kann der Einsatz eines Gateways notwendig sein, um die Rechenlast bewältigen zu können. Gleichzeitig kann das Gateway dadurch einen Flaschenhals darstellen, auf dessen innere Funktion und Leistung der Betreiber weniger Einfluss hat als auf den Web-Service selbst. Dies macht umsichtige Planung und Tests notwendig.

Ähnlich einer Web-Application Firewall (WAF) kann der Einsatz einer XML -Firewall ein falsches Gefühl von Sicherheit erzeugen und dazu führen, dass Sicherheitsmaßnahmen in der Softwareentwicklung und im Betrieb von Web-Services vernachlässigt werden. Dies ist häufig fatal, da für die meisten Gateways im Lauf der Zeit Methoden bekannt werden, wie deren Filterfunktionen umgangen werden können. Die Notwendigkeit von robustem Code und Sicherheitschecks im Dienst selbst wird dadurch also nicht obsolet.

Typischerweise wird ein XML-Gateway wie andere ALGs auch in einem neutralen Grenznetz ( DMZ ) positioniert. Zu empfehlen ist auch hier der P-A-P-Aufbau mit vor- und nachgeschaltetem Paketfilter und dem XML -Gateway in der Mitte, was erheblich bessere Kontroll- und Protokollierungsmöglichkeiten bietet (siehe M 2.73 Auswahl geeigneter Grundstrukturen für Sicherheitsgateways ). Zudem können die beiden Paketfilter das XML -Gateway selbst vor einfachen Attacken schützen und komplexitätsbedingte Fehlkonfigurationen dort teilweise kompensieren. Darüber hinaus können sie das Gateway bei der Filterung von unerwünschtem Datenverkehr (zum Beispiel durch Internet-Würmer) unterstützen und eine Überlastung zumindest hinauszögern.

Da ein XML -Gateway ein komplexes System darstellt, sind in allen Phasen des Lebenszyklus von Konzeption bis Notfallvorsorge detaillierte Anforderungen zu stellen. Daher ist das XML -Gateway selbst im Sicherheitskonzept anhand des Bausteins B 3.301 Sicherheitsgateway (Firewall) zu behandeln.

Prüffragen:

  • Wurde in einer Anforderungsanalyse bestimmt, welche Funktionen eines XML-Gateways benötigt werden?

  • Wurde die Entscheidung getroffen und dokumentiert, an welcher Stelle die Validierung von Nachrichten durchgeführt werden soll?

  • Ist sichergestellt, dass in der Anwendungsentwicklung weiter die Forderungen nach robustem Code und Überprüfung der Eingangsdaten berücksichtigt werden?

  • Ist die Platzierung des XML-Gateways geplant und begründet, etwa in der DMZ und zwischen zwei Paketfiltern (P-A-P)?

  • Wurde das XML-Gateway selbst im Sicherheitskonzept erfasst und mit dem Baustein B 3.301 Sicherheitsgateway (Firewall) abgebildet?

Stand: 14. EL Stand 2014