Bundesamt für Sicherheit in der Informationstechnik

M 4.458 Planung des Einsatzes von Web-Services

Verantwortlich für Initiierung: Leiter IT

Verantwortlich für Umsetzung: Administrator, Fachverantwortliche

Vor dem Einsatz eines Web-Service ist der genaue Zweck zu bestimmen, den der Web-Service erfüllen soll. Denn Web-Services stellen nur eine Art der Kommunikation zwischen Maschinen dar und bringen spezifische Vor- und Nachteile gegenüber anderen Formen der Integration von Anwendungen und Diensten mit sich. Nicht jede Anwendung eignet sich für eine Ausführung als Web-Service. Auch Kosten-Nutzen-Überlegungen spielen hier eine Rolle. So wird der Datendurchsatz, gerade beim durchgängigen Einsatz von Web-Service-Sicherheitsstandards, regelmäßig deutlich schlechter sein als bei klassischen Massendaten-Übertragungsverfahren. Dem gegenüber stehen Vorteile in der Wiederverwendbarkeit von Diensten und Funktionen und in der Skalierbarkeit von Anwendungen durch Verteilung der Aufgaben auf unterschiedliche Dienste.

Am Anfang steht eine gründliche Analyse der Anforderungen, die auch dokumentiert werden sollten. Hierbei empfiehlt es sich, mit einer Abbildung der betroffenen Prozesse auf einer hohen Abstraktionsebene zu beginnen, daraufhin die Arbeitsabläufe im Ist und Soll zu skizzieren und darauf aufbauend einen Entwurf mit Eingaben, Ausgaben, Schnittstellen und Daten zu detaillieren. Ebenso zu identifizieren sind Anbieter, Konsumenten, Kommunikationsverbindungen und erforderliche Service-Verzeichnisse. Zu letzteren ist zu entscheiden, ob und welche Web-Services darin veröffentlicht werden sollen.

Eine grundlegende Entscheidung ist die für einen REST - oder einen SOAP -basierten Web-Service. Während SOAP bei internen betrieblichen Anwendungen wesentlich weiter verbreitet ist und auf eine Vielzahl von Werkzeugen und Standards aufbaut, ist REST hauptsächlich im agilen Web-Umfeld anzutreffen. Letztlich wird die Entscheidung im Wesentlichen von den anderen Diensten und Anwendungen abhängen, die bereits vorhanden sind, noch entstehen oder angebunden werden sollen. In jedem Fall sind die Folgen der grundlegenden Architekturentscheidung am Anfang zu berücksichtigen und durchzuspielen.

Dies ist insbesondere dann relevant, wenn eine serviceorientierte Architektur ( SOA ) entstehen oder ein Dienst in eine bestehende SOA integriert werden soll. Hierbei sind Fragen des SOA -Betriebsmodells zu klären: Wer ist innerhalb der Institution für die fachliche Funktionalität und für die verarbeiteten Informationen verantwortlich? Rollen und Verantwortlichkeiten sind spätestens jetzt festzulegen und zu dokumentieren.

Ob eine Architektur in Richtung Serviceorientierung umgeformt werden soll, ist eine strategische Entscheidung, die mit der Strategie zur Nutzung von Web-Services und der Plattformstrategie Hand in Hand gehen sollte. Sollen viele Web-Services auf unterschiedliche, möglicherweise wechselnde Art und Weise miteinander interagieren können - man spricht von Orchestrierung -, so können Modellierungs- und Beschreibungssprachen wie BPMN oder BPEL eingesetzt werden, um die Interaktion der Geschäftsprozesse zu steuern. Dies ergibt jedoch frühestens dann Sinn, wenn eine ausreichend große Zahl von Web-Services vorhanden ist, welche auf verschiedene Art verknüpft werden sollen, um neue Dienste zu kreieren.

Besonders gut geeignet für die Ausführung als Web-Service sind Dienste, die von mehreren Anwendungen oder anderen Diensten benötigt werden. Hier sollte auch berücksichtigt werden, dass die Dienste nicht nur intern genutzt werden könnten. Werden diese weiteren Institutionen zur Verfügung gestellt werden, ist unbedingt zu klären, wer über die Bereitstellung von Diensten und Daten an Dritte entscheidet. Außerdem sind die Absicherung der Netzübergänge und Kommunikationsschnittstellen zu betrachten, damit die Web-Services im erforderlichen Maß von außen angesprochen werden können, ohne die Sicherheit interner Netze unnötig zu gefährden. Dabei werden häufig Unternehmensdaten über Netzsegmente hinweg und auf freigeschalteten Ports wie 80 ( HTTP ) oder 443 ( HTTPS ) durch Firewalls hindurch transportiert. Auch Schadsoftware kann auf diesem Weg in die Institution hinein gelangen, etwa als eingebettete Datei. Hier sind Schutzkonzepte und technische Sicherheitsmaßnahmen wie Application Level Gateways ( ALG ) zu überprüfen und gegebenenfalls anzupassen.

Um den Web-Service gegen Angriffe abzusichern, müssen auch bei der Implementierung geeignete Sicherheitsmaßnahmen vorgesehen werden, zum Beispiel eine durchgängige Validierung von Ein- und Ausgabedaten und Konformitätsprüfungen der verarbeiteten XML-Daten. Auch hierzu sollten entsprechende Vorgaben in der Planungsphase erarbeitet und dokumentiert werden.

Um über die Einführung von Web-Services, die damit verbundenen Risiken und die notwendige Absicherung informiert entscheiden zu können, ist es wichtig, die komplette Funktionalität des Web-Service zu dokumentieren und diese Dokumentation aktuell zu halten. Dies geschieht am besten für alle Web-Services an einer zentralen Stelle. Bei Nutzung des Web-Service durch mehrere Parteien sollten alle Seiten Zugriff auf diese Informationen haben.

Auch auf den Lebenszyklus eines Web-Service hat die Mehrfachnutzung Einfluss: Es muss geklärt und beschrieben werden, wie Änderungen eines Web-Service, der von mehreren Anwendungen oder Organisationen genutzt wird, durchgeführt werden können. Entsprechendes gilt für die Abschaltung am Ende des Lebenszyklus.

Für die Realisierung der Web-Service-Funktionalität empfiehlt es sich, bewährte und gut getestete Komponenten heranzuziehen, da die Materie komplex ist und Programmierfehler bei Eigenentwicklungen häufig vorkommen. Sowohl beim Applikationsserver wie bei Web-Service-Bibliotheken oder -Frameworks sollten Produkte ausgewählt werden, die aktiv weiter gepflegt werden, und bei denen Informationen über Schwachstellen und Patches zeitnah bereitstehen.

Kommen komplexere Standards wie etwa WS-Security, WS-Trust oder WS-Federation zum Einsatz, ist die gegenseitige Abhängigkeit und Beeinflussung der verschiedenen Sicherheitsfunktionen genau zu planen und zu testen. Für die Aufrechterhaltung der Sicherheit in einer kompletten SOA ist schließlich ein Zusammenspiel von Standards, Konzepten und Mechanismen notwendig, das über die Absicherung einer reinen Client-Server-Beziehung hinausgeht. Hier ist besonderes Fachwissen gefragt.

Neben anderen Sicherheitszielen, die je nach Einsatzzweck eine Rolle spielen können, ist fast immer die Absicherung der Kommunikation zwischen Dienstnutzer und Dienstanbieter entscheidend. Dies kann entweder auf Transportebene erfolgen, wenn der Transportweg der Nachrichten dies erlaubt (etwa durch SSL-/TLS bei HTTP ), oder aber auf Nachrichtenebene. Letzteres erlaubt neben der Ende-zu-Ende-Absicherung auch, die Sicherheitsparameter in einer feineren Granularität auszuwählen und auszuwerten, zum Beispiel die Signatur oder Verschlüsselung lediglich für bestimmte Teile einer Nachricht. Dabei ist tiefliegendes Wissen über die verwendeten Mechanismen notwendig, um nicht durch Schwachstellen in Protokollen oder in der Implementierung angreifbar zu werden, beispielsweise durch XML Signature Wrapping (siehe G 5.183 Angriffe auf XML ). Außerdem erschwert eine Ende-zu-Ende-Verschlüsselung die Filterung bösartiger Nachrichten. Hier kann es helfen, die Verschlüsselung am Application-Level-Gateway zu terminieren.

Um die Vorteile von Web-Services, insbesondere ihre Wiederverwendbarkeit und Skalierbarkeit, voll ausnutzen zu können, ist es entscheidend, das Identitäts- und Zugriffsmanagement nicht in jedem Dienst einzeln neu zu realisieren. Die Planung der Web-Service-Landschaft umfasst deshalb auch die Planung der übergreifenden Verwaltung der Benutzer und Rechte. Näheres hierzu findet sich in den Maßnahmen M 4.456 Authentisierung bei Web-Services und M 4.455 Autorisierung bei Web-Services .

Die vorgenannten, für die Planung eines Web-Service erforderlichen Aspekte gelten in ähnlicher Form auch für klassische IT-Anwendungen. Durch die mögliche Mehrfach-Nutzung und Orchestrierung zu übergreifenden Aufgaben und durch die technische Komplexität der Standards und Protokolle ist der Einfluss von Planungsmängeln auf den Projekterfolg jedoch gegenüber anderen Technologien erhöht.

Prüffragen:

  • Ist der Einsatzzweck des Web-Service beschrieben und sind die Anforderungen der Consumer analysiert und dokumentiert?

  • Ist dokumentiert, wer für die fachliche Funktionalität und die verarbeiteten Informationen verantwortlich ist?

  • Wurden Konzepte und Maßnahmen zur Absicherung der Netzübergänge im Hinblick auf den Einsatz von Web-Services angepasst?

  • Besteht ein Schutz vor Schadsoftware in Web-Service-Nachrichten, und sind Sicherheitsmaßnahmen wie eine Eingabe- und Ausgabevalidierung für die Software-Implementierung vorgegeben?

  • Wurden bewährte, gut getestete Komponenten, Bibliotheken und Frameworks für die Realisierung des Web-Service ausgewählt?

  • Ist die Kommunikation zwischen Consumer und Dienstanbieter entweder auf Transport- oder auf Nachrichtenebene auf eine dem Schutzbedarf angemessene Weise abgesichert?

Stand: 14. EL Stand 2014