![[Illustration]](07-2-036-1.jpg)
Abbildung 1: Versionssprung auf 3.0 durch Zusatzkomponenten im .NET Framework
Serviceorientierung ist auch für Microsoft spätestens seit der Veröffentlichung des .NET Frameworks 3.0 Ende 2006 zu einer integralen Funktion der hauseigenen und seit Windows Vista nun auch vollständig mit dem Client-Betriebssystem ausgelieferten Anwendungsplattform geworden. Mit .NET 3.0 umfasst diese Plattform jedoch noch einiges mehr: Sie besteht aus den neuen Komponenten Windows Workflow Foundation (WF), Windows Presentation Foundation (WPF, Entwicklungsname Avalon), Windows CardSpace (WCS) und Windows Communication Foundation (WCF, Entwicklungsname Indigo) sowie dem klassischen .NET Framework in der Version 2.0 (vgl. Abb. 1).
Abbildung 1: Versionssprung auf 3.0 durch Zusatzkomponenten im .NET Framework
Während die Workflow Foundation ein neues Modell zur grafischen Abbildung und Entwicklung von Arbeitsabläufen darstellt und die WPF für lokale und Internet-basierte Anwendungen eine neue Darstellungstechnik bietet, soll die WCF zum Herzstück kommender Kommunikationsinfrastrukturen werden. Windows CardSpace knüpft hier mit einer neuartigen Lösung für ein einheitliches und interoperables Identitätsmanagement an.
Bei der Sicherheit von .NET 3.0 kommt der WCF aufgrund ihrer zentralen Stellung in allen Kommunikationsszenarien eine Schlüsselrolle zu. Die Sicherheit der übrigen Komponenten, insbesondere auch von Windows CardSpace, hängt wesentlich von der Absicherung der WCF ab. Hierfür bietet die WCF Entwicklern zahlreiche vorgefertigte Sicherheitsfunktionen an. Allerdings stößt sie bei der konsequenten, vollständigen Umsetzung einer sicheren, serviceorientierten Architektur auch an ihre Grenzen: Über den mitgelieferten Funktionsumfang hinaus ist Eigeninitiative erforderlich, um mit WCF-basierten Diensten sicher arbeiten zu können.
Die Kommunikation zwischen Anwendungen wurde unter Windows bisher durch verschiedene Techniken wie dem Component Object Model (COM) oder .NET Remoting realisiert. Die WCF vereint nun unterschiedliche Kommunikationsanforderungen und Protokolle erstmals unter einem einzigen Architekturansatz. Sowohl interoperable als auch proprietäre Szenarien werden dabei durch umfangreiche Konfigurationsmöglichkeiten umsetzbar. Entwickler und Administratoren können diese Einstellungen sowohl im Quellcode als auch in Konfigurationsdateien bis ins feinste Detail vornehmen (vgl. Tab. 1).
| Kommunikationsszenario | Kommunikation zwischen .NET-Anwendungen | Web Services und Interoperabilität | Unterstützung ergänzender Web-Service-Spezifikationen (WS*) | Transaktionen zwischen verteilten Systemen | Einsatz von Nachrichtenschlangen |
|---|---|---|---|---|---|
| Klassische Lösung von Microsoft | .NET Remoting | Web Services unter ASP.NET (ASMX) | Web Services Enhancements (WSE) | Enterprise Services | Microsoft Message Queuing (MSMQ) |
| Lösung unter .NET 3.0 | WCF | WCF | WCF | WCF | WCF |
Tabelle 1: Vereinheitlichung unterschiedlicher Kommunikationsmodelle mithilfe der WCF
Komplexität und Sicherheit sind nur selten miteinander vereinbar. So stellt eine Vereinheitlichung und damit Vereinfachung des Kommunikationsmodells zunächst eine wichtige Voraussetzung für das Erreichen einer höheren IT-Sicherheit dar. Andererseits verführen einfach zu handhabende Programmierschnittstellen dazu, notwendige Sicherheitsüberlegungen hintanzustellen und unkritisch auf die schlüsselfertig gelieferte Sicherheit des Produkts, in diesem Fall der WCF, zu vertrauen.
Damit steht der Hersteller der WCF in einer besonderen Verantwortung, die vom BSI mithilfe einer Bedrohungsmodellierung gegen die Architektur einer realitätsnahen Beispielanwendung und einer sich daran anschließenden tatsächlichen Implementierung auf die Probe gestellt wurde. Im Ergebnis zeigte sich dabei, dass Sicherheit kein inhärentes Merkmal der WCF ist. Auch hier ist Sicherheit ein Prozess, für den die WCF zwar die meisten Voraussetzungen mitbringt. An welchen Stellen es jedoch unbedingt auch eigene, weitergehende Überlegungen anzustellen gilt, folgt aus einer genauen Betrachtung der von der WCF selbst beanspruchten Serviceorientierung.
Softwareanwendungen führen heute kein isoliertes Dasein mehr. Vielmehr fußen sie in der Regel darauf, dass sie mit verschiedenen anderen Anwendungen effizient und sicher kommunizieren können. Es handelt sich damit um über ein einzelnes System oder mehrere, auch physische Systeme verteilte Anwendungen. Deren Kommunikation kann technisch und architektonisch elegant über die Bereitstellung und die Verwendung so genannter Dienste realisiert werden. Anwendungen mit entsprechenden Fähigkeiten werden als dienstbasiert oder serviceorientiert bezeichnet.
Erst mithilfe der Serviceorientierung können Aufgaben innerhalb verteilter Anwendungen wirklich effizient aufgeteilt werden. Gleichzeitig ist so eine saubere Trennung zwischen der Geschäftslogik und etwa Komponenten zur Interaktion mit dem Benutzer möglich. Eine solche Interaktion kann aufgrund dieser flexiblen Architektur schließlich auf unterschiedlichsten Geräten über verschiedene, jeweils geeignete Benutzerschnittstellen wie Internetbrowser oder auch allein lauffähige Applikationen stattfinden.
Zur Umsetzung dieser begrüßenswerten Ziele müssen allerdings vier Grundsätze der Serviceorientierung eingehalten werden:
Die Kompatibilität der miteinander in Kontakt tretenden Anwendungen muss durch eine eindeutige Klärung der Rahmenbedingungen der Kommunikation sichergestellt werden. Insbesondere gilt es hier, die Erwartungen an die Sicherheit der Kommunikation zwischen den beteiligten Partnern in so genannten Richtlinien verbindlich zu klären.
Die Grenzen zwischen den verschiedenen Anwendungen sind immer explizit sichtbar. Diese Grenzziehung manifestiert sich insbesondere auch im Quellcode, sodass dem Entwickler zu jedem Zeitpunkt bewusst wird, wenn er mit einem Dienst Daten austauscht und damit den eigenen Herrschaftsbereich verlässt. Die Kommunikation mit anderen Diensten darf sich damit ausdrücklich nicht hinter kurzen (wenn auch eleganten) Befehlsstrukturen im Quellcode verstecken.
Serviceorientierte Konzepte dürfen daneben nicht durch eine wie auch immer geartete Kopplung zwischen den einzelnen Anwendungen ausgehebelt werden. Eine gemeinsame Datenhaltung (z. B. in gemeinsam genutzten Datenbanksystemen), mehrfach in verschiedenen Anwendungen verwendeter Quelltext oder gemeinsam genutzte, statische Speicherbereiche sind in jedem Fall zu vermeiden.
Schließlich müssen sich die beteiligten Entwickler der unterschiedlichen Dienste untereinander auf einen "Vertrag" über die angestrebte serviceorientierte Verbindung zwischen ihren Anwendungen verständigen. Hier geht es tatsächlich um einen Vertrag zwischen den handelnden Menschen. Auf Maschinenebene manifestiert sich dieser Vertrag dann in formalisierten Beschreibungen, etwa per XML Schema Definition (XSD) oder Web Services Description Language (WSDL).
Insgesamt gesehen dient damit der serviceorientierte Ansatz vor allem dazu, über formale Regeln die Komplexität großer, verteilter Systeme drastisch zu reduzieren. Softwareentwickler sollen an kleinen, überschaubaren Einheiten arbeiten, die unabhängig voneinander erstellt, gewartet und erweitert werden können. Die WCF stellt die von Microsoft zur Erfüllung dieser Anforderungen vorgesehene zentrale Technik dar.
Trotz der grundsätzlichen Vereinfachung und Systematisierung des Programmiermodells erkennt man bei der konkreten Entwicklung eines Dienstes, dass auch eine solch isolierte, zunächst klein und überschaubar erscheinende Komponente sehr schnell eine hohe Komplexität in sich bergen kann (s. Abb. 2). Ihr sicherer Betrieb auf einem Zielsystem ist in der Folge nicht ohne weitergehende Überlegungen beherrschbar.
Abbildung 2: Die kleinste sinnvolle Einheit eines WCF-basierten Dienstes
In seiner kleinsten technisch sinnvollen Einheit besteht ein WCF-basierter Dienst aus
Um den Grundsätzen der Serviceorientierung mit einer solchen Diensteinheit vollständig gerecht werden zu können, muss nun für jeden Service ein individuelles Dienstkonto auf dem Zielsystem eingerichtet werden. Ansonsten ist mit den vom Betriebssystem zur Verfügung gestellten Mitteln keine saubere Trennung des Zugriffs auf die verschiedenen Ressourcen eines verteilten Systems möglich. Und nur so können die einzelnen Dienste wirkungsvoll auch gegeneinander abgesichert werden. Die Notwendigkeit dieser Trennung zwischen den einzelnen Diensten setzt sich dann bis zur Einrichtung individueller Ereignisprotokolle und Nachrichtenschlangen fort.
Auf der so geschaffenen Grundlage müssen weiterhin allen einzelnen Bestandteilen einer Diensteinheit auf dem Zielsystem individuelle Berechtigungen (Access Control Lists, ACLs) zugewiesen werden. Hier offenbart sich die eigentliche Herausforderung bei Umgang mit WCF-basierten Diensten: Wirklich effizient lässt sich dies durch einen Administrator von Hand nicht durchführen, da sämtliche Einstellungen in einem sehr hohen Detaillierungsgrad und immer wieder in einer definierten Reihenfolge vorgenommen werden müssen. Erschwerend kommt hinzu, dass vom Hersteller nicht alle notwendigen Einstellungen ausreichend dokumentiert werden. Daher müssen zwingend selbstständig geeignete Hilfswerkzeuge zur sicheren Verteilung von Diensten entwickelt werden, um eine reproduzierbar sichere Einrichtung unter anderem der benötigten Dienstkonten, der Ereignisprotokolle, der Nachrichtenschlangen sowie der zugehörigen ACLs gewährleisten zu können.
Von Hause aus bringt das .NET Framework keine geeignete Unterstützung zur sicheren Installation von WCF-basierten Diensten mit. Administratoren müssen für diese Aufgabe eine geeignete Automatisierungsmethode suchen. Zur Auswahl stehen grundsätzlich:
Angesichts des Ziels, eine sichere Installation einer zwar kleinen, aber dennoch komplexen Softwareeinheit durchführen zu wollen, scheiden die ersten beiden Varianten von vornherein aus, da sie keine Transaktionssicherheit bieten. Ein definiertes Verhalten für den Fall, wenn einzelne Installationsschritte fehlschlagen, ist mit diesen Methoden nicht zu erreichen. Ebenso kann die vollständige Rückabwicklung eines fehlgeschlagenen Installationsversuchs oder eine zu einem späteren Zeitpunkt notwendige Deinstallation mit diesen Methoden nicht erfolgreich durchgeführt werden. Die (in anderen Fällen durchaus legitime) Umfunktionierung von MSBuild zu einem Installationswerkzeug würde den Grundprinzipien der Serviceorientierung wegen der mangelnden Autonomie einer solch zentralen Erstellungskomponente widersprechen und muss daher ebenfalls fallengelassen werden.
Übrig bleibt für die sichere Verteilung von WCF-basierten Diensten daher letztlich nur die Verwendung der (vergleichsweise aufwändigen) Ausführungsumgebung Windows Installer. Mit ihr können alle serviceorientierten Anforderungen auch im Installationsprozess umgesetzt werden; die Technik bietet auch Transaktionssicherheit und die Möglichkeit einer sauberen Rückabwicklung.
Die Komplexität typischer Diensteinheiten spiegelt sich nun jedoch auch in den – für jede einzelne Einheit! – zu erstellenden Installationsroutinen wider: Es sind jeweils individuelle Routinen für das Dienstkonto, das Ereignisprotokoll, die Nachrichtenschlange und je nach Anforderung für weitere Komponenten (wie virtuelle Verzeichnisse der Internet Information Services – IIS, Betriebssystemdienste und ein Datenbanksystem) zu entwickeln. Diese Einzelroutinen können dann am Ende allerdings in eine zusammenfassende, übergreifende Installationsroutine überführt werden.
Zur Beurteilung der Leistungsfähigkeit der WCF im Bereich der Sicherheit wurde vom BSI ein Bedrohungsmodell erstellt, um besonders kritische Aspekte bereits vor der Entwicklung einer Beispielanwendung identifizieren zu können. Dabei stellte sich schnell heraus, dass die Absicherung der einzelnen Dienste nicht nur gegen externe Angreifer, sondern gegen andere Dienste wirksam betrieben werden muss. Dies kann nur über ein ausgefeiltes, geprüftes und dann reproduzierbar identisch auf allen Zielsystemen verteiltes Berechtigungskonzept geschehen.
Diese Erkenntnis manifestierte sich dann bei der Implementierung der realitätsnahen Beispielanwendung im Rahmen der WCF-Sicherheitsanalyse des BSI. Während Microsoft für die Absicherung der zu übertragenden Nachrichten zahlreiche wirkungsvolle Schutzmechanismen sowohl für transportbasierte als auch für nachrichtenbasierte Sicherheit bietet, stößt man bei dem Versuch, Dienste sicher auf den Zielsystemen zu verteilen, an die Grenzen der Unterstützung durch Werkzeuge des Herstellers.
Eine einfache und auch in ihrem Kommunikationsverhalten hinreichend sichere WCF-Beispielanwendung auf "Hallo-Welt-Niveau" kann bereits durch wenige Mausklicks erstellt werden. Für eine unter Sicherheitsgesichtspunkten verantwortbare Installation WCF-basierter Dienste müssen jedoch zahlreiche, bisher nicht zusammenhängend und transparent dokumentierte Zusatzmaßnahmen zwingend automatisiert durchgeführt werden. Microsoft steht in der Pflicht, für diese Aufgaben in kommenden Versionen des .NET Frameworks eigene Lösungen anzubieten. Bis dahin kann auf die publizierten Ergebnisse der Sicherheitsanalyse des BSI zurückgegriffen werden.
Während der Sicherheitsanalyse wurde zu Testzwecken eine umfangreiche Beispielanwendung unter der Bezeichnung "Blue Books" entwickelt, in der die vollständige grundlegende Geschäftslogik eines Internetbuchhändlers implementiert ist. Diese Anwendung dient nun nach Abschluss der Analyse der Illustration der gewonnenen Erkenntnisse. Aufgrund ihrer Komplexität und Realitätsnähe ist sie daneben durchaus auch als vom BSI empfohlenes Entwurfsmuster für Anwendungen, die auf .NET und WCF aufsetzen sollen, zu verstehen. Überdies werden zusammen mit dem Quellcode aber auch gebrauchsfertige Routinen für die besonders kritische und allein mit .NET-Bordmitteln nicht hinreichend sicher durchführbare Installation WCF-basierter Dienste bereitgestellt.
Vom BSI werden in diesem Rahmen auch grundsätzliche Empfehlungen zu serviceorientierten Architekturen unter Verwendung von .NET und der WCF gegeben. Diese Handlungsempfehlungen umfassen die Bereiche:
Der komplette Quellcode der WCF-Beispielanwendung kann vom BSI zusammen mit Handlungsempfehlungen zur Erstellung WCF-basierter Architekturen bezogen werden. Der Versand der Quelltexte ebenso wie der Handlungsempfehlungen (Gesamtgröße 6,7 MB) erfolgt per E-Mail auf formlose Anfrage an os-security@bsi.bund.de. Die Dokumentation wurde aufgrund der internationalen Zusammenarbeit bei der Erarbeitung der Ergebnisse in englischer Sprache erstellt.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007#2, Seite 36
tag:kes.info,2007:art:2007-2-036
| 