Der Anspruch an die IT in Unternehmen wächst: Aus einer stabilen, aber auch mitunter starren Infrastruktur soll ein flexibler Service für die Geschäftsprozesse werden. Damit einher geht ein grundlegender technologischer Wandel hin zum Einsatz von Webservices. Dieser Wandel verspricht als Hauptvorteil eine evolutionäre Weiterentwicklung der IT, wobei intern vorhandene IT-Systeme ebenso eingebunden werden können wie externe Lösungen von Geschäftspartnern.
Möglich wird dieser Wandel durch Fortschritte nicht nur in der Technologie, sondern vor allem auch bei der Standardisierung. Letztlich wird das Konzept einer serviceorientierten Architektur, kurz SOA, möglich durch Standards wie XML oder SOAP, die für die nötige Interoperabilität unter den lose gekoppelten Services sorgen und gleichzeitig die unverzichtbare Unabhängigkeit von den verwendeten Plattformen, Datenbanken und Programmiersprachen schaffen.
Zugriff auf Webservices reglementieren
Webservices können durchaus unterschiedliche Eigentümer und Betreiber haben. Auch die Nutzer sind nicht mehr automatisch nur autorisierte Mitarbeiter des Unternehmens. Es können Kunden, Händler, Interessenten, andere Webservices, im Zweifelsfall aber auch unwillkommene Gäste wie Hacker oder Industriespione sein.
Dazu gesellen sich neuartige Fehlerquellen, z. B. ein unerwartetes Verhalten von Webservices im Zusammenspiel, die ein Sicherheitsrisiko bilden. Auch simple Fragen, ob beispielsweise die einzelnen Webservices tatsächlich vorhanden sind, mit welcher Performance sie laufen und wie sicher sie sind, lassen sich nur auf Basis eines integrativen und sicheren Managements beantworten.
Deshalb arbeiten führende Software-Anbieter für das Enterprise IT- und Security-Management intensiv an der Ausarbeitung, Formulierung und Durchsetzung entsprechender Standards mit, die den SOA-Einsatz vereinheitlichen und vereinfachen. Mit Standards wie UDDI oder WSDL lassen sich die Webservices nicht nur besser wiederverwenden und kombinieren, sondern auch umfassend steuern, verwalten und sichern.
Ergänzend treibt das Gremium Organization for the Advancement of Structured Information Standards (OASIS) aktiv den Standard “Web Services Distributed Management” (WSdM) voran.
Identity Federation
Für die nötige Sicherheit sollen ergänzend verschiedene Standardisierungs-Initiativen sorgen, die insbesondere das Identitätsmanagement sowie die Zugriffskontrolle regeln. Viel versprechend ist hier vor allem die Technologie der so genannten Identity Federations für den sicheren Austausch digitaler Identitäten bzw. von entsprechenden zweckgebundenen Nutzungsrechten zwischen den verschiedenen teilnehmenden Stellen.
Überflüssig wird somit eine mehrmalige Anmeldung von Usern während einer Transaktion, an der unterschiedliche Systeme beteiligt sind. Mit Hilfe von Techniken wie dem Single Sign-On (SSO) kann das sogar gelingen, wenn diese Systeme nur sporadisch oder gar erstmalig zusammenarbeiten.
Im SOA-Rahmen kann damit die traditionell sehr dezentrale „Siloverwaltung“ der Identitäten durch teilauthentifizierte Services abgelöst werden, auf Basis etablierter Sicherheitsmechanismen. Es entsteht ein Web-Sicherheitsmodell mit vermaschter Struktur. Dabei handelt es sich um ein Netzwerk von „Objekten“ wie Webservices oder Usern, die auf mehreren Wegen miteinander verbunden sein können.
Ähnlichkeit zu Weitverkehrsnetzen
Die Struktur eines vermaschten Netzwerkes (Mesh Network), die beispielsweise auch bei Weitverkehrsnetzen (Wide Area Networks) 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 Webobjekte können sich in der föderativen, vernetzen Umgebung finden, miteinander verhandeln, sich an- und abmelden. Insbesondere ist dazu keine permanente Verbindung zwischen ihnen mehr erforderlich.
Für den Aufbau von solchen Identity Federations stehen verschiedene Technologien bereit. Man spricht von Browser-basierter Föderation, wenn ein beim Unternehmen A registrierter Benutzer über einen Link ohne erneute Authentifizierung direkt auf den geschützten Bereich des Partnerunternehmens B gelangt. Benutzer können hier dank Cross Domain SSO nach einmal erfolgter Authentifizierung auf mehrere Sites zugreifen. Die Authentifizierung kann dabei auf Basis von Accounts, Attributen oder von Rollen erfolgen.
In einer dokumenten-basierten Föderation dagegen schickt der User eine XML-Anfrage an den gewünschten Webservice. Das Unternehmen authentifiziert anhand dessen die Anfrage des Kunden A und leitet diese entsprechend seiner Berechtigungen an andere Webservices innerhalb der Föderation weiter. Die Ergebnisse der Applikation werden dann letztendlich an den Kunden A gesendet. Die Standardisierung läuft auf Hochtouren, vor allem im Eclipse-Projekt Higgins und bei OASIS im Rahmen von SAML (Security Assertion Markup Language) zum Austausch von Identitätsinformationen.
Föderation als Schutz für Webservices
Föderationen bilden einen wirksamen und gleichzeitig für den User unmerklichen Schutz von Webservices. Sie sind vor allem dann entscheidend für den Aufbau von SOA-Infrastrukturen, wenn diese diverse Zwischenstationen (Intermediaries) einbeziehen. Auch die mehrstufige Webservice-Bearbeitung wirft die sicherheitsrelevanten Fragen der Autorisierung, Authentifizierung, Integrität und Vertraulichkeit auf, die durch solche Förderationen beantwortet werden.
Der SOA-Idee folgend lassen sich die Sicherheitsservices dabei zum Teil durch zentrale Server-Plattformen betreiben und können ihrerseits als Dienst angefordert werden. Die notwendige Koordination lässt sich über den Enterprise Service Bus (ESB) vornehmen, der ohnehin die Orchestrierung und das Routing der Services innerhalb einer SOA verantwortet.
Die notwendigen Industriestandards zu dem dafür nötigen Austausch von Identitätsinformationen zwischen den Domänen einer Föderation definiert der bereits erwähnte SAML-Standard in der aktuellen Version 2.0. Ebenso wichtig in dem Zusammenhang sind die Protokolle, die den Austausch von Security-Informationen betreffen. Einen derartigen Austausch gibt es in Bezug auf die Ressourcen („Assets“) und Personen, aber auch die Organisationsstrukturen und die Sicherheitsbestimmungen („Policies“) der beteiligten Unternehmen.
Ergänzend lassen sich in Identity Federations auch Zuordnungen und Abbildungen treffen, etwa von Ressourcen auf Abteilungen oder Personen („Eigentümer“), von Policies auf Organisationseinheiten („Gültigkeitsbereiche“) oder von Usern auf Organisationseinheiten („Rollen“). So können beispielsweise allen Mitarbeitern in der Rolle „Einkäufer“ bestimmte Rechte eingeräumt werden, was den Aufbau von Identity Federations wesentlich erleichtert.
Der SOA-Sheriff
Die Definition von Sicherheitsmechanismen allein reicht jedoch nicht aus. Um ihre Einhaltung zu überwachen und gegebenenfalls auch durchzusetzen, ist als Kontrollinstanz ein SOA Security Manager notwendig. Ähnlich wie einst im Wilden Westen der Sheriff für Recht und Ordnung sorgte, kontrolliert der SOA Security Manager alle einmal verabschiedeten Sicherheitsregeln in der gesamten SOA-Umgebung und nimmt gleichzeitig die drei Hauptaufgaben der Zugriffskontrolle wahr – Autorisierung, Authentifizierung und Auditing. Dabei unterscheidet der SOA Security Manager zwischen den unterschiedlichen Sicherheitsanforderungen in drei Regionen:
-
Die SOA-Plattform-Security innerhalb des Unternehmens, z. B. bei Verbindungen zwischen Webservices über den Enterprise Service Bus (ESB) oder beim sogenannten „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 beispielsweise die 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.
Ergebnis ist ein zentralisiertes Management von Security-Policies für alle Webservices mit einem entsprechenden Berichtswesen, auch wenn die Anforderungen so unterschiedlich sind wie das Single Sign-On über ein Portal oder die Verkettung mehrer Webservices zur Bedienung einer Anfrage. So kann beispielsweise ein Bankkunde am Portal nicht nur Überweisungen tätigen oder den Kontostand abfragen, sobald er sich einmal erfolgreich identifiziert hat. Er kann dann auch eine Kreditkarte beantragen, wobei dieser Prozess sogar bei einem partnerschaftlich mit der Bank verbundenen Kreditkartenunternehmen ablaufen könnte, dass über die Identity Federation mit den entsprechenden Identitäts-Informationen versorgt wird. Dabei könnten im Hintergrund beliebig verschachtelt weitere Webservices angestoßen werden, etwa zur Prüfung der Kreditwürdigkeit. (mha)