Host for Services Mainframe-Sicherheit als SOA-Fundament

Ordnungsmerkmale

erschienen in: <kes> 2007^#4, Seite 16

Zusammenfassung: Serviceorientierte Architekturen (SOA) können in erheblichem Maße von bewährten Mainframe-Eigenschaften profitieren. Das erfordert allerdings neue Sicherheitsbetrachtungen, die idealerweise systemübergreifend zu implementieren sind.

Autor: Von Georg Lauer, Darmstadt

Der oft schon totgesagte Mainframe erlebt gerade seine x-te Renaissance. Das kommt nicht von ungefähr, denn mit seiner beinahe sprichwörtlichen Zuverlässigkeit und der Fähigkeit, quasi gleichzeitig zigtausende von Anfragen zu bedienen, kann er das stabile und zuverlässige Fundament für eine serviceorientierte Architektur (SOA) bilden, deren Aufbau in vielen Unternehmen zumindest angedacht wird. Der Mainframe bietet dabei weitere Vorteile, weil darauf beispielsweise auch ganze Linux-Serverfarmen konsolidiert und deren Services ohne großen Middleware- und Netzwerk-Overhead verknüpft werden können.

Notwendig ist dafür allerdings ein völlig neuer Ansatz im Security-Management (vgl. Kasten "Vertrauensdienste"), um die sich öffnenden IT-Systeme effizient zu schützen. Dabei könnte ein spezielles SOA-Security-Managementsystem als unabhängige Instanz helfen, alle Sicherheitsregeln des Unternehmens in der gesamten SOA – inklusive des Mainframe – zu kontrollieren und gleichzeitig die drei Hauptaufgaben der Zugriffskontrolle zu übernehmen (Autorisierung, Authentifizierung und Auditing).

Eine solche unabhängige Instanz ist sinnvoll, da ansonsten in der SOA sämtliche Bausteine "vertrauenswürdig" gemacht und ihre Verbindungen untereinander nach außen völlig abgeschirmt werden müssten. Das ist nicht nur im Mainframe-Umfeld schwierig, wo die Anwendungen einerseits in der Regel ausschließlich auf die Nutzung durch autorisierte Mitarbeiter des Unternehmens ausgelegt sind, andererseits aber trotz der Einbindung in die neue SOA-Welt nicht verändert werden sollen.

Um diese Wiederverwertbarkeit zu gewährleisten, sind heute verschiedene Ansätze verbreitet. Beim so genannten "Wrapping", umhüllt eine Middleware-Schicht die Mainframe-Applikationen, um Programmfunktionen daraus zu extrahieren und dann in Services zu transformieren. Diese wiederum können dann über moderne Software-Tools für das Business-Process-Management (BPM), aber auch durch Workflow- oder Rule-Engines (evtl. ergänzt um fehlende Sicherheitsmechanismen) zu neuen Anwendungen kombiniert werden.

Hinter SOA verbirgt sich letzlich immer ein Gestaltungsprinzip, das Applikationen nach Maß aus einem Bündel lose gekoppelter Services erstellt, die über standardisierte Schnittstellen kommunizieren. Entsprechend ergänzt, können darin auch die berühmt-berüchtigten "Anwendungs-Silos" eingebunden werden, die dem Mainframe das kontraproduktive Image eingetragen haben, starr und inflexibel zu sein. Genau hier setzt SOA den Hebel an: Es eröffnet altbewährten Mainframe-Anwendungen neue Einsatzfelder und stellt umgekehrt für neue Anwendungen ausgereifte Mainframe-Funktionen mit hoher Leistungsfähigkeit und in einem zeitgemäßen Look bereit.

Neue Chancen, neue Risiken

Erkauft wird dieser Flexibilitätsgewinn mit neuen Risiken. Denn in einer SOA können neben unternehmenseigenen IT-Services gegebenenfalls auch Komponenten externer Anbieter oder "Funktionsbausteine" von Lieferanten oder Kunden zum Einsatz kommen, für deren Sicherheit der IT-Chef vielleicht nicht immer die Hand ins Feuer legen würde. Nutzer sind unter Umständen nicht nur Mitarbeiter des Unternehmens, sondern auch Geschäftspartner und womöglich sogar Interessenten, Bewerber und andere Webservices, im Zweifelsfall sogar unwillkommene Gäste wie Hacker oder Industriespione. Außerdem bleibt offen, wo genau ein Service betrieben wird: Auf dem "sicheren" Mainframe oder einem anderen Rechner des Unternehmens, bei einem Dienstleister oder Geschäftspartner oder gar auf einem Desktop-PC des Users.

Dazu gesellen sich neuartige Sicherheits- und Ablauf-Risiken, zum Beispiel ein unerwartetes Verhalten von Webservices im Zusammenspiel. Selbst scheinbar simple Fragen, beispielsweise ob einzelne Webservices tatsächlich vorhanden sind, mit welcher Performance sie laufen und wie sicher sie sind, lassen sich nur auf Basis eines integrativen Managements beantworten. Eine ganze Palette von Angriffen ist vorstellbar: von der einfachen Dienstunterbrechung und Verzögerung bis hin zur Datenverfälschung und -löschung oder dem Mitlesen sensitiver Informationen. Und ein kleiner Programmierfehler, der beispielsweise einen Webservice in eine Endlosschleife schickt, könnte eine Denial-of-Service-"Attacke" auslösen, wenn darin permanent andere Webservices aufgerufen werden.

Deshalb arbeiten führende Softwareanbieter für das Enterprise-IT- und -Security-Management intensiv an der Ausarbeitung, Formulierung und Durchsetzung entsprechender Standards mit, die den Betrieb einer SOA vereinfachen und vereinheitlichen – ja, letztlich sogar erst ermöglichen: Mit Standards wie dem Service-Discovery-Protokoll "Universal Description, Discovery and Integration" (UDDI, [1]) oder der Web Service Definition Language (WSDL, [2]) lassen sich Webservices nicht nur nutzen und kombinieren, sondern auch umfassend steuern, verwalten und sichern. Ergänzend treibt die Organization for the Advancement of Structured Information Standards (OASIS) aktiv den Standard "Web Services Distributed Management" (WSdM) voran [3].

Standardisierung

Für die nötige Sicherheit wollen ergänzend auch verschiedene Standardisierungs-Initiativen sorgen, die nicht zuletzt das Identitätsmanagement sowie die Zugriffskontrolle regeln. Vielversprechend ist hier vor allem die so genannte Identity Federation (vgl. [4,5]) für den sicheren Austausch digitaler Identitäten beziehungsweise entsprechender zweckgebundener Nutzungsrechte zwischen den verschiedenen teilnehmenden Stellen. Letztlich kann damit eine mehrmalige Anmeldung von Usern während einer Transaktion überflüssig werden, auch wenn unterschiedliche Systeme beteiligt sind. Mithilfe von Techniken wie Single Sign-on (SSO) kann das sogar gelingen, wenn diese Systeme nur sporadisch oder gar erstmalig zusammenarbeiten.

Im SOA-Rahmen kann so die traditionell sehr dezentrale "Siloverwaltung" der Identitäten durch teilauthentifizierte Services abgelöst werden. Das kann sogar auf Basis der Sicherheitsmechanismen erfolgen, wie sie auf dem Mainframe mit Tools wie RACF von IBM oder ACF2 und Top-Secret von CA in den letzten zwanzig Jahren ausgetüftelt worden sind. Der Host bietet sich damit als vertrauenswürdiger Träger des Benutzerverzeichnisses an, in dem die Identitäten der User ebenso verwaltet werden wie ihre Zugriffsrechte.

Daneben ist allerdings zu beachten, dass im SOA-Betrieb nicht nur die Sicherheitsprobleme der auch schon komplizierten vertikalen Integration zwischen den Schichten der lokalen Software-Architektur zu lösen sind. Darüber hinaus entstehen mit SOA neue, komplexe Service-Prozessketten, die nicht mehr unter einer einheitlichen Verwaltung und Kontrolle stehen. Dennoch muss über eine Kette von Intermediären und Webservices zwischen den beteiligten Parteien ein hinreichend guter Sicherheitskontext aufrechterhalten werden (vgl. [4]).

Gefragt ist daher ein Web-Sicherheitsmodell mit vermaschter Struktur – ein Netzwerk von "Objekten" wie Webservices und Anwendern, die auf mehreren Wegen miteinander verbunden sein können. Diese Struktur eines vermaschten Netzwerks (Mesh Network), die auch bei Funknetzen und Weitverkehrsnetzen (Wide Area Networks – WAN) anzutreffen ist, verspricht den Vorteil, dass bei Unterbrechungen zwischen einzelnen Knoten oder bei Performance-Engpässen alternative Wege für die Kommunikation benutzt werden können. Die Web-Objekte können sich in einer föderativen, vernetzten Umgebung finden, miteinander verhandeln, sich an- und abmelden; insbesondere ist dazu keine permanente Verbindung zwischen ihnen mehr erforderlich.

Sicherheit als Service

Der SOA-Idee folgend lassen sich auch Sicherheitsleistungen zum Teil durch zentrale Server-Plattformen (z. B. auf dem Mainframe) betreiben und ihrerseits als Dienst anfordern. Die notwendige Koordination kann über einen so genannten Enterprise Service Bus (ESB) erfolgen, der auch die Orchestrierung und das Routing der Services innerhalb einer SOA verantwortet.

Die Bereitstellung solcher Sicherheitsservices allein reicht jedoch nicht aus. Um die Sicherheitsbestimmungen zu überwachen und gegebenenfalls auch durchzusetzen, ist eine Kontrollinstanz wie das eingangs erwähnte (SOA-)Security-Managementsystem notwendig. Ein solches System könnte dabei zwischen den unterschiedlichen Sicherheitsanforderungen in drei Regionen unterscheiden:

• die Platform-Security innerhalb des Unternehmens, beispielsweise bei Verbindungen zwischen Webservices über den Enterprise Service Bus (ESB) oder beim so genannten "Credential Mapping" zwischen zwei sich gegenseitig vertrauenden Instanzen über eine sichere Verbindung,
• die Edge-Security an der Grenze der IT-Systeme eines Unternehmens – sie schützt zum Beispiel XML-Gateways und verhindert Denial-of-Service-Attacken,
• die Container-Security auf der "letzten Meile" von der Unternehmensgrenze bis hin zu dem Ort, wo der Webservice letztlich genutzt wird, beispielsweise beim Kunden oder beim Außendienstmitarbeiter – hier sind vor allem Sicherheitsmechanismen zum Schutz der HTTP- und XML-Kommunikation sowie der Java- und .NET-Applikationen, aber auch der Web- und ApplikationsServer gefragt.

Föderative Security-Policies

Im Endeffekt sollte das letztlich zu einem zentralisierten, aber dennoch föderativen Management von Security-Policies für ausnahmslos alle Webservices führen – inklusive eines entsprechenden Berichtswesens – und auch für Fälle, in denen die Anforderungen so unterschiedlich sind wie das Single Sign-on über ein Portal oder die Verkettung mehrerer Webservices zur Bedienung einer Anfrage.

So könnte beispielsweise ein Bankkunde am Portal nicht nur Überweisungen tätigen oder den Kontostand abfragen, sobald er sich einmal erfolgreich identifiziert hat. Er könnte dann auch eine Kreditkarte beantragen, wobei dieser Prozess durchaus bei einem partnerschaftlich mit der Bank verbundenen Kreditkartenunternehmen ablaufen könnte, das über Identity Federation mit den entsprechenden Informationen versorgt wird. Dabei könnten im Hintergrund beliebig verschachtelt weitere Webservices auch auf einem Mainframe angestoßen werden, etwa zur Prüfung der Kreditwürdigkeit.

Das Ergebnis ist (wie im genannten Beispiel) nicht nur eine bessere und längere Nutzung bewährter Mainframe-Anwendungen, sondern auch ein wesentlich geringeres Projektrisiko und eine deutliche Zeit- und Kostenersparnis bei der Erweiterung und Modernisierung der IT-Unterstützung – vorausgesetzt, die skizzierten Sicherheitsmaßnahmen werden effektiv in die Praxis umgesetzt.

Georg Lauer ist Regional Manager Technology Services bei CA.

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007^#4, Seite 16
tag:kes.info,2007:art:2007-4-016