Print-friendly Version

Identitäten in einer Service orientierten Welt – Identity as a Service

Achim Reckeweg, November 2008

Inhalt

• Software as a Service
• Sicherheitsbetrachtungen
• Organisatorische Aspekte
• Identity as a Service
• Ausblick

Software as a Service

Blättert man zur Zeit durch die einschlägigen Magazine, kommt man am Modewort Web 2.0 nicht vorbei. Neben vielen kleinen Firmen sind mittlerweile auch die großen Unternehmen der Branche wie Google, Yahoo oder Microsoft in diesem Bereich vertreten. Neben dem Mitmachkonzept in den Communities ist das eigentliche Erfolgsrezept die Bereitstellung von dokumentierten Schnittstellen, die es Webentwicklern ermöglichen, auf die dort angebotenen Dienste zu zugreifen und in eigene Entwicklungen zu integrieren – die sogenannten Mashups. Beispiele hierzu sind die Frameworks von Facebook oder die Services Schnittstelle zu Google Maps, die eine Einbindung in eigene Applikationen oder Webseiten erlaubt.

Abb. 1: Web 2.0 Anwendung

Im Web 2.0 werden derzeit immer mehr Dienste realisiert, die auch für die Umsetzung von dort bisher vielleicht nicht vermuteten Applikationen verwendet werden können. (Siehe Deutsches Bundesamt für Sicherheit in der Informationstechnik (BSI), Web 2.0 - Sicherheitsaspekte neuer Anwendungen und Nutzungsformen des Mediums World Wide Web und ihrer Implementierung (pdf), 2007, Kapitel 3.)

Aus einer ganz anderen Ecke kommt das Bestreben, Software wieder verwendbar zu implementieren, offene Standards zu benutzen und somit integrierbar zu machen. Bisher waren viele Standard-Softwareprodukte zu unflexibel, ließen sich kaum auf die Unternehmensbelange zuschneiden und nur schwer mit Produkten anderer Hersteller integrieren. (Vgl. Bundesamt für Sicherheit in der Informationstechnik (BSI), SOA-Security Kompendium - Sicherheit in Service-orientierten Architekturen (pdf), 2008, Kapitel 2.2.)

Nimmt man die kurzen Innovationszyklen aktueller Softwareprodukte, mit sich häufig ändernden oder zumindest erweiterten Schnittstellen hinzu, hat man die hauptsächlichen Faktoren erkannt, die für einen beträchtlichen Teil der Kosten heutiger Softwareprojekte verantwortlich sind. Diese Problematik will man mit der Verwendung offener, Hersteller unabhängiger Protokolle adressieren, die es ermöglichen, Geschäftslogik vollständig zu kapseln und mit standardisierten Schnittstellen umzusetzen. Dadurch können komplexe Applikationen unter Verwendung einfacherer Dienste zusammengesetzt werden. Diesen Vorgang bezeichnet man als Orchestrierung und die Applikationen als lose gekoppelt. Sie zeichnen sich dadurch aus, dass Teile der Anwendung sehr einfach und schnell durch vergleichbare Dienste ersetzt werden können.

Damit befinden sich die Hersteller aus dem SOA Umfeld in derselben Ausgangslage wie die Unternehmen im Web 2.0: Der implementierte Dienst muss nicht mehr lokal beim Anwender selbst laufen, sondern kann genauso gut über das Web bezogen und integriert werden.

Abb. 2: Das SOA Modell

Glaubt man einschlägigen Fachleuten wird Software in nicht allzu ferner Zukunft hauptsächlich online genutzt, die wenigsten werden Programme noch lokal installieren. Im Web 2.0 wird gerade daran gearbeitet, ein einheitliches Schnittstellenkonzept zu etablieren. In der Unternehmenswelt ist man weiter. Hier haben sich die Webservices Protokolle durchgesetzt. Diese XML basierenden Protokolle ermöglichen das Erstellen von Client-Server-Applikationen in heterogenen Umgebungen. Nichts Neues möchte man meinen, aber SOAP räumt mit den Versäumnissen auf, die in der Vergangenheit der Verbreitung von beispielsweise CORBA entgegenstanden.

Beliebig kombinierbare Dienste

Sowohl im Web 2.0 als auch in der Webservices Welt kann sich der Anwender die Applikationen nach seinen Anforderungen zusammenstellen. Benötigt man tatsächlich den gesamten Funktionsumfang der aktuellen Boliden der Büroanwendungen oder ist man mit deutlich weniger zufrieden? Zukünftig werden viele der bekannten Programme nur noch aus einem Rumpf- oder einem Applikations-Framework bestehen. Der Anwender bindet nur die Teile ein, die er wirklich benötigt. Mit diesem neuen Paradigma müssen die Teile nicht unbedingt vom Hersteller des Programmpaketes bezogen werden. Vielmehr hat man die Freiheit, diese Dienste von beliebigen Anbietern zu kombinieren.

Das bedeutet, dass die benutzte Laufzeitumgebung nicht vorher gesagt werden kann. Die Dienste können in beliebigen Programmiersprachen wie Java, C, C# oder auch C++ implementiert sein. Zu einer reibungslosen Zusammenarbeit ist es daher essentiell, auf offene Plattform und Sprachen übergreifende Standards zu setzen.

Auslagerung von Sicherheit

So finden wir verteilte Dienste vor, die in beliebigen Programmiersprachen implementiert sind, jedoch über eine standardisierte Schnittstelle verfügen. Diese Dienste können und werden von beliebig vielen anderen Diensten wieder verwendet und neu zusammengestellt. In der Vergangenheit hat sich jede Applikation selbst um die Themen Authentisierung und Autorisierung der Benutzer gekümmert und hat diese Daten in einer eigenen, isolierten Benutzerdatenbank abgelegt. Es ist offensichtlich, dass dieser Ansatz in einer verteilten, dynamischen Umgebung nicht mehr greifen kann. Die Sicherheitsanforderungen an die einzelnen Komponenten steigen dramatisch an. Jeder Dienst für sich muss den höchsten Ansprüchen genügen, da die Gesamtapplikation nur so sicher sein kann wie jede der Teilkomponenten, aus denen sie besteht. Um dies umzusetzen, ist ein ganzheitlicher Ansatz mit übergreifenden als Dienste implementierten Sicherheitskomponenten nur logisch. Die Sicherheitsaspekte müssen aus dem Kontext der Applikation gelöst und als Service ausgelagert werden. Dies sind insbesondere Bereiche wie die Authentisierung und Autorisierung von Diensten sowie die Protokollierung.

Ein weiterer sehr wichtiger Aspekt ist die Zuweisung und Verwaltung von Berechtigungen. Häufig werden diese in Form von Rollen organisiert. Hier muss zwischen eher systemspezifischen technischen Rollen und funktionalen bzw. organisatorischen Rollen unterschieden werden. Die technischen Rollen dienen der Zusammenfassung der Berechtigungen auf Systemebene. Die funktionalen und organisatorischen Rollen setzen auf diese auf und dienen der Modellierung der Berechtigungen nach den Anforderungen des Geschäftslebens. Auch für den Bereich des Rollenmanagements gilt, dass ein globales, übergreifendes Rollenmodell erarbeitet und gepflegt werden muss.

Die Analyse des bestehenden Modells sowie die Pflege und Weiterentwicklung kann dabei eine echte Herausforderung sein, die mit entsprechenden Rollenanalyse und Rollenverwaltungswerkzeugen deutlich erleichtert werden kann.

Da die Zuweisung der Rollen und Berechtigungen außerhalb der Applikation erfolgt, können diese zusammen mit den Anforderungen an die Authentifizierung und Autorisierung in Regelsätzen zusammengefasst werden. Das bedeutet, dass die Sicherheitsaspekte eines Dienstes konfigurierbar werden. Damit können mit denselben Diensten Applikationen mit unterschiedlichen Sicherheitsanforderungen umgesetzt werden. Da diese ohne programmatische Änderungen eingerichtet werden können, sind sie einfacher dokumentierbar und damit besser überprüfbar.

Mit einer Anwendungsinfrastruktur, die diese Dienste anbietet, ist es möglich, auch große Benutzerzahlen durch einfache Zuordnung von Rollen mit einem fein granularen Berechtigungskonzept zu versehen und damit den Zugriff nur noch personalisiert zu zulassen.

Aufbau kostenpflichtiger Dienste

Denkt man diesen Gedanken zu Ende, kann die Abrechenbarkeit von Diensten die Abrechenbarkeit der Informations Technologie zur Folge haben. Erfolgt die Umsetzung konsequent, wird diese damit planbar und die Kosten transparent.

Es können noch erheblich mehr Dienste definiert und genutzt werden, aber es werden wenigstens Authentifizierung, Autorisierung, Identity und Access Management sowie die Protokollierung benötigt.

Vertraulichkeit der Benutzerdaten

Jeder der Dienste muss Zugriff auf die Daten haben, die zu seiner Funktion notwendig sind, aber nicht auf weitere. Es muss sicher gestellt sein, dass dem Datenschutz Rechnung getragen wird. Daten werden dort gespeichert, wo sie anfallen, und Relationen zwischen den Datentöpfen werden nur gebildet, wo sie notwendig sind. Im deutschen Datenschutz wird dieser Ansatz Daten Minimalisierung genannt. Daraus kann abgeleitet werden, dass ein zentralistischer Ansatz zum Scheitern verurteilt ist. Vielmehr wird man einen verteilten Ansatz favorisieren müssen, der es gestattet, die unterschiedlichen Identitäten bei Bedarf miteinander in Relation zu setzen.

Der Anfang ist schon gemacht

Im Industriesegment gehen Standard Software Lieferanten wie SAP, Peoplesoft und Oracle diesen Weg schon geraume Zeit. Die neuen Versionen der Produkte werden auf die SOA Architektur umgestellt und setzen auf etablierte Standards wie Liberty oder WS-* auf.

Im Web 2.0 entstehen zur Zeit bei Google, mySpace, Facebook und Xing Plattformen, die neben ihren Community Aufgaben immer mehr Dienste implementieren, die bisherige Desktop Aufgaben übernehmen und lokal installierte Programme überflüssig machen wollen. Zur Zeit befinden sich diese Dienste in der Aufbau- und Experimentierphase. Vieles kann den verwöhnten Ansprüchen noch nicht gerecht werden, aber die Entwicklung schreitet sehr schnell voran. Momentan befinden sich eine Vielzahl von Schnittstellen Spezifikationen im Wettbewerb. Hier wird sich in der nächsten Zeit einiges tun. Welche sich dabei durchsetzt, lässt sich heute noch nicht sagen. Es ist jedoch sehr wahrscheinlich, dass es ein offener Standard sein wird.

Sicherheitsbetrachtungen

Betrachtet man die beiden aus verschiedenen Richtungen kommenden Ansätze, so setzen sie beide als Basis auf eine etablierte, verlässliche Plattform Sicherheit auf. Alles was man in den vergangenen Jahren zu diesem Thema gelernt hat, muss vorausgesetzt werden. Die für den Service verwendeten Server Systeme müssen so sicher wie möglich konfiguriert sein. Das zugrunde liegende Netzwerk muss auf etablierten als sicher bekannten Entwurfsmustern basieren. (Siehe auch BSI IT-Security Guidelines (pdf))

Es gibt einen gravierenden Unterschied zu den bisherigen Architekturen: Das Konzept der Firewall, die das interne Netz isoliert und schützt, kann in Zukunft nur eingeschränkt Verwendung finden. (Vgl.BSI, Sicherheit von Webanwendungen (pdf), 2006) Natürlich muss eine Firewall weiterhin eingesetzt werden, um die Gesamtarchitektur vor offensichtlichen Gefahren zu schützen. Es ist jedoch erklärtes Ziel, innerhalb der eigenen Infrastruktur Dienste für externe Benutzer anbieten zu wollen. Dies bedeutet, dass der Zugriff auf diese möglich sein muss und damit ein Durchgriff durch die Firewall notwendig wird. Für Web Services hat sich die Verwendung von SOAP über http bzw. https als Standard durchgesetzt. Hier werden dieselben Kommunikationskanäle genutzt, die bereits für die internen Benutzer geschaltet worden sind. Auf einmal werden über diese Kanäle neben relativ unkritischen Daten auch zahlreiche geschäftskritische Dienste und Daten exponiert. Die korrekte Verwendung muss demnach überprüft werden. Im Gegensatz zum bisherigen Firewall-Konzept muss die Semantik der Befehle geprüft werden. Es ist notwendig, in die einzelnen Felder eines Protokolls hinein zu sehen und zu entscheiden, ob es korrekt verwendet wird. Diese Aufgaben werden üblicherweise einer sogenannten XML Firewall übertragen. Vgl. BSI, SOA-Security Kompendium - Sicherheit in Service-orientierten Architekturen (pdf), 2008, Kap. 4.1.)

Letztlich ist für eine optimale Sicherheit ein durchgängiges Konzept erforderlich, das eine Ende-zu-Ende-Sicherheit bis auf die Ebene der Services sicher stellt: Also die Nutzung von Services im Kontext der digitalen Identität des Nutzers der Anwendung. Eine ausführliche Diskussion der Sicherheitsanforderungen findet man in BSI, SOA-Security Kompendium - Sicherheit in Service-orientierten Architekturen (pdf), 2008, Kap. 3.

Konsequente Personalisierung

Grundlage für die Personalisierung der Dienste muss ein umfassendes und durchgehendes Identity und Access Management sein. Es darf nicht sein, dass zum Zugriff auf einzelne Dienste ein spezielles Benutzerkonto angelegt wird, welches von allen Benutzern bei der Verwendung des Dienstes benutzt wird. Damit ist nachträglich selbst bei existierender Protokollierung nicht nachvollziehbar, wer oder für wen auf diese Ressource zugegriffen worden ist. Dies widerspricht der Nachvollziehbarkeit und erschwert die Zuordnung der Kosten. Jedoch ist das heute auf breiter Basis üblich.

Federated Identity Management

Akzeptiert man diese Forderung, hat das zur Folge, dass es keine Zugriffe ohne eindeutige Identitifizierung und Autorisierung mehr geben darf. Innerhalb einer Organisation ist dies meist mit vertretbarem Aufwand zum Beispiel durch die Implementierung eines zentralen Verzeichnisdienstes möglich. Ein Identity Management System kann an dieser Stelle noch weitergehende Ansprüche an Automatisierung und Protokollierung abdecken. In vernetzten Strukturen, in denen mit beliebigen Partnern oder Zulieferern gearbeitet werden soll, greift dieser Ansatz jedoch nicht. Hier muss eine Lösung wie das von der Liberty Alliance erarbeitete Konzept der Federated Identity zum Einsatz kommen. Die Liberty Alliance ist eine Industrie Organisation, in der sich zahlreiche Unternehmen zusammengefunden haben, um Protokolle für die föderale Zusammenarbeit zu entwickeln. Unter anderen sind die Firmen Sun Microsystems, Nokia und Oracle hier tätig.

Prinzipiell geht es darum, autonomen Organisationen ohne zentrale Instanz die Zusammenarbeit zu ermöglichen, indem ein Mechanismus gefunden wird, mit dem existierende Benutzerkonten mit Zustimmung des Benutzers in Relation gesetzt werden können.

Isolierte Organisationen

Das Ganze erfolgt auf eine Art und Weise, die sicher stellt, dass die Organisationen keine Kenntnis der Benutzerdaten der jeweils anderen Organisation erlangen. Sie wissen lediglich, dass sie von dem gleichen Benutzer sprechen, ohne zu wissen, wie dieser beim Gegenüber heißt. Damit ist sichergestellt, dass der Benutzer die Datenhoheit behält, und gleichzeitig dass die Unternehmen die Möglichkeit der Autorisierung und der Protokollierung erhalten.

Partnering

Jedes der beteiligten Unternehmen baut dazu ein eigenes Identity und Access Management auf, mit dem der Zugriff auf die eigenen Ressourcen geschützt wird. Dieses kümmert sich um alle notwendigen Aspekte für die Benutzerkonten der eigenen Organisation. Für organisationsfremde Benutzer wird die Authentifizierung ausgelagert. Dazu wird eine Anfrage an das Access Management der Heimatorganisation des betreffenden Benutzers gestellt. Voraussetzung dafür ist, dass sich beide Organisationen vertrauen und entsprechende Vereinbarungen getroffen haben.

Die Autorisierung erfolgt danach weiterhin durch die Organisation, die den jeweiligen Dienst betreibt. Diese will schließlich selbst entscheiden, ob die identifizierte Person tatsächlich Zugriff auf die gewünschte Ressource erhält.

Ganz wichtig ist, dass dieses Konzept eine durchgehende Protokollierung sowohl auf Seiten des Aufrufenden als auch auf der Seite des Diensterbringers ermöglicht.

Verschiedene Ansätze

Neben dem Konzept der Liberty Alliance gibt es einen zweiten Ansatz, der ähnliche Ziele verfolgt: Die WS-* Protokolle, die hauptsächlich von den Firmen Microsoft und IBM entwickelt werden.

Für den Programmierer von Web Services hatte dies bislang zur Folge, dass er sich bei der Erstellung seines Dienstes entscheiden musste, ob er dem einen oder dem anderen Konzept folgen wollte.

Das widerspricht schon im Ansatz der SOA Architektur, die es sich zum Ziel gesetzt hat, Dienste unabhängig benutz- und vernetzbar zu machen.

Die Ausgliederung der sicherheitsrelevanten Funktionen und Einbindung dieser als ein weiterer Service kristallisiert sich momentan als Lösung heraus.

Die Entwickler konzentrieren sich auf die Geschäftslogik und integrieren für die Authentifizierung, Autorisierung und das Rollenmanagement externe Funktionen die von der Laufzeitumgebung zur Verfügung gestellt werden.

Die Access Management Produkte dienen dabei als Mittler zwischen den Protokollfamilien. Man kann sich das als eine Sonderform der Föderation vorstellen. Neben der Authentifizierung erfolgt zum Zeitpunkt der Anfrage ebenfalls eine Protokollwandlung. Falls notwendig erhält der Anfragende ein weiteres zur Identifizierung notwendiges Token, welches in der jeweils anderen Protokollfamilie gültig ist. Es gibt zur Zeit schon erste Implementierungen, die dieses Konzept umsetzen. Ein Beispiel dafür ist OpenSSO.

Die Liberty Alliance hat sich zum Ziel gesetzt, auf bestehende, etablierte Protokolle aufzusetzen. So finden einige grundlegende Protokolle der OASIS Verwendung, die teilweise auch weiter entwickelt wurden. Mittlerweile sind schon Teile der WS-* Spezifikationen an die OASIS zur weiteren Pflege und Entwicklung übergeben worden. So wird zum Beispiel WS-Security bereits von aktuellen Liberty Protokollen genutzt. Es ist zu erwarten, dass die Protokoll Familien zu einem späteren Zeitpunkt konvergieren werden.

Transportsicherheit

Die SOA Protokolle bieten die Möglichkeit, neben http auch an weitere Transportprotokolle gebunden zu werden. Das dominierende Protokoll ist ganz klar SOAP über http. Da http ein Klartext Protokoll ist und sensitive Daten über dieses Medium übertragen werden, sollte der Einsatz der verschlüsselten Variante zwingend sein. Um es klar zu sagen: In der SOA Welt sollte es eine Selbstverständlichkeit sein, ausschließlich die verschlüsselten Varianten der eingesetzten Transportprotokolle zu verwenden.

Eine Verschlüsselung auf dieser Ebene kann jedoch nur die Vertraulichkeit zwischen den direkten Kommunikationsendpunkten sicher stellen. Sollten sich dazwischen noch Kommunikationspartner befinden, die die Daten nur weiterreichen, oder wenn der Datenintegrität oder der Nichtabstreitbarkeit Sorge getragen werden soll, reicht dies nicht aus. In diesem Fall müssen die einzelnen Teile der Nachricht kryptografisch bearbeitet werden.

Nachrichtensicherheit

Dazu werden die Einzelteile der Nachricht entweder signiert, verschlüsselt oder beides. Auf dem Weg zum Empfänger verpackt jede Station die Nachricht in einen Umschlag und schickt diese zum nächsten Kommunikationspartner. Dieser packt die Nachricht aus, packt sie in den nächsten Umschlag und schickt sie weiter. Auf diese Weise ist sichergestellt, dass die am Transport beteiligten Rechner nicht notwendigerweise in der Lage sind, die eigentliche Nachricht zu lesen oder sogar zu verändern, sondern nur die Informationen erhalten, die sie zum Transport benötigen. Das hauptsächlich eingesetzte Protokoll sowohl in der WS-* als auch in der Liberty Spezifikation heißt WS-Security. Dieses definiert wiederum, wie die grundlegenderen Protokolle XMLENC und XMLDSIG verwendet werden sollen.

Zertifikate

Grundvoraussetzung beim Einsatz dieser Protokolle ist das Vorhandensein einer PKI Infrastruktur. XMLENC und XMLDSIG definieren wie XML Nachrichten ganz oder teilweise verschlüsselt und/oder signiert werden können. Die dazu notwendigen Zertifikate werden durch ein drittes Protokoll – XKMS (XML Key Management Specification) – über eine Web Service basierende Schnittstelle bei einer PKI angefragt. Soll der Dienst nicht nur in der eigenen Organisation zum Einsatz kommen, sondern vielleicht sogar als öffentlicher Dienst im Internet vermarktet werden, empfiehlt es sich, die Dienstleistungen der großen CA Betreiber in Anspruch zu nehmen. Kommt ein Signaturgesetz konformes Zertifikat zum Einsatz kann der gesamte Vorgang sogar rechtsverbindlichen Charakter bekommen. Wird der Dienst eher in einer geschlossenen Benutzergruppe genutzt, kann eine eigene PKI zum Einsatz kommen.

Regel basierte Sicherheitsansätze

Es ist leicht vorstellbar, dass die Sicherheitsanforderungen eines Dienstes zum Zeitpunkt seiner Erstellung noch nicht komplett bekannt sind, oder sich diese über die Dauer der Nutzung ändern. Aus diesem Grund ist es sinnvoll, die Sicherheitsaspekte konfigurierbar zu halten und komplett aus der Applikation auszulagern. Wird das konsequent durchgehalten, wird die Applikationsentwicklung drastisch vereinfacht. Der Entwickler kann sich auf die Geschäftslogik konzentrieren. Welcher Teil der auszutauschenden Nachrichten danach in welcher Qualität signiert oder verschlüsselt wird, wird durch die Konfiguration des Dienstes festgelegt. Diese kann dann in Regelsätzen zusammengefasst werden und damit zur Laufzeit angepasst werden. Die Kommunikation kann sogar Attribut gesteuert gesichert werden. Bei der Nutzung im gesicherten Firmenumfeld können somit andere Maßstäbe angelegt werden als bei der Nutzung mit Partnern oder im Internet.

Organisatorische Aspekte

Identity Management

Das Thema Identity Management ist in erster Linie eine organisatorische Aufgabe, die heute schon von den Unternehmen umgesetzt werden muss. Es dreht sich dabei um die Verwaltung aller im Unternehmen tätigen Personen mit all ihren Zugangs- und Zugriffsrechten auf Liegenschaften, Systeme und Dokumente. Die zugrundeliegenden Geschäftsprozesse werden definiert und häufig wird dabei auf ein zentrales Rollenmodell aufgesetzt. Es handelt sich hier um eine Kernaufgabe jeder Organisation.

Im Gegensatz zu früheren Herangehensweisen versucht sich das heutige Identity Management an einer ganzheitlichen Behandlung dieser Aufgaben unter Zuhilfenahme von digitalen Identitäten. Das setzt vor allem die lückenlose Betrachtung der Nutzer von organisationseigenen Ressourcen voraus, schließt also Geschäftspartner, temporäre Gelegenheitsnutzer und Kunden mit ein.

Das Ganze muss im Einklang mit den gesetzlichen Regelungen und Bestimmungen erfolgen. Bei international tätigen Organisationen schließt das nicht nur nationales Recht ein, sondern es müssen ebenfalls die internationalen Regelungen betrachtet werden.

Outsourcing

Ein aktueller, heute am Markt zu beobachtender Trend, ist das Auslagern von Aufgaben oder ganzen Unternehmensteilen. Die Gründe dafür sind vielfältig und reichen von Einsparungen über Rationalisierungen bis hin zu Personalproblemen, die damit gelöst werden sollen.

Damit Aufgaben ausgelagert werden können, sind selbstverständlich entsprechende Aufgabenbeschreibungen, Service Level Agreements und Verträge zwischen den Dienstleistern und den Auftragnehmern notwendig.

Web Services oder Software as a Service

Die Inanspruchnahme eines Web Services oder einer bei Dritten betriebenen Software Plattform stellt nichts anderes als eine besondere Form des Outsourcings dar. Die Nutzung einer bei Dritten betriebenen Software Plattform ist heute schon üblich. Zum Beispiel gibt es seit geraumer Zeit das Angebot, bestimmte SAP Pakete anzumieten. Zu Zeiten des Internet Booms wurde dieses Geschäftsmodell Application Service Providing genannt und wird heute im Web 2.0 öfter zu beobachten sein.

Etwas anders stellt sich die Situation bei Nutzung von Web Services dar. Die Zahl der Diensterbringer kann sehr groß sein. Wenn sich das Konzept in allen Einzelheiten durchsetzt, also z. B. auch die dynamische Auswahl der notwendigen Services zur Laufzeit, kennt man den aktuell verwendeten Service Provider eventuell nicht einmal, sondern kann bestenfalls sagen, dass es einer aus der vorkonfigurierten Menge sein muss.

Verträge

Es muss geklärt werden, in wie weit die bisher bestehenden Regelungen in diesen Verträgen ausreichen.

Wer haftet z. B., wenn bei einem Geschäft föderierte Authentifizierung benutzt worden ist, der Geschäftspartner auf einmal behauptet, dieses Geschäft nie eingegangen zu sein, und dank fehlenden Protokollierungen nicht das Gegenteil bewiesen werden kann?

Wer trägt die Kosten, wenn bei einem Audit festgestellt wird, dass die geprüfte Firma im Prinzip eine Konformitätsbestätigung erhalten würde, aber einige von Dritten genutzte Dienste den Anforderungen nicht entsprechen?

Wie ist die Rechtslage, wenn ein Auftragnehmer die Datenschutzbestimmungen nicht so genau nimmt und dadurch sensitive, personenbezogene Daten öffentlich zugänglich werden?

Fraglich ist auch, ob sich die Betriebspraxis nach bestimmten Richtlinien festschreiben lässt oder ob die Diensterbringer Zertifizierungen nachweisen müssen (Siehe dazu Statement on Auditing Standards (SAS) No. 70). Was geschieht, wenn der Dienstleister diese Zertifizierung verliert? Es mag sein, dass der Vertrag in diesem Fall sofort erlischt, aber hat man dann die Flexibilität, in angemessener Zeit zu einen dritten Anbieter zu wechseln?

SLA's

Datenschutz

Bei diesen Betrachtungen gilt es die gesetzlichen Regelungen und hier im besonderen den Datenschutz zu beachten. Identity Management verwaltet personenbezogene Daten und somit sensitive Informationen. Es ist zu jedem Zeitpunkt sicher zu stellen, dass niemand Unbefugtes Zugriff oder Einsicht in diese Daten hat. Außerdem sind sämtliche administrativen Vorgänge zu protokollieren, um im Nachhinein nachweisen zu können, wer zu welchem Zeitpunkt den Zugriff auf eine Ressource gestattet hat. Dabei ist zu beachten, dass auch diese Daten dem Datenschutz unterliegen und sicher zu stellen, dass nur ausgewählte Personen Zugang zu diesen Informationen haben.

Prinzipiell unterscheiden sich die für den Datenschutz relevanten Regelungen nicht von denen, die auch für ein Outsourcing notwendig sind. Die große Herausforderung besteht in der Skalierung der notwendigen Verträge.

Eine Voraussetzung für den Betrieb von Applikationen für sensitive Datenverarbeitung ist die zugrundeliegende Basissicherheit der gesamten Infrastruktur und die strikte Einhaltung der vorhandenen Security Policies.

Compliance Zusagen

Organisationen, die zur Einhaltung gesetzlicher Regelungen wie Sarbanes-Oxley (SOX), Euro Sox (pdf) oder KontraG verpflichtet sind, müssen sicher stellen, dass die Einhaltung dieser Vorschriften für die gesamte Verarbeitungskette gilt. Werden einzelne Aspekte der Verarbeitung an Dritte ausgelagert, ist trotzdem die Organisation für die Einhaltung der Regelungen verantwortlich. Das bedeutet, dass auch die Anbieter von Dienstleistungen eine Konformitätszusage nach den gängigen Regelungen beibringen müssen. Es wird daher unerlässlich sein, dass die Anbieter von Web Services sich nach den hinlänglich bekannten IT-Security relevanten Standards zertifizieren lassen wie Information Technology Infrastructure Library (ITIL), Control Objectives for Information and related Technology (COBIT) (pdf), SAS 70, American Institute of Certified Public Accountants (AICPA) Service Organizations: Applying SAS No. 70, as Amended - AICPA Audit Guide

Resüme

Die Möglichkeiten der neuen Service orientierten Welt werden aus organisatorischen und rechtlichen Gründen wahrscheinlich gar nicht in dem Maße genutzt werden, wie es technisch machbar wäre. Für unternehmenskritische Dienste wird man sich auf einige wenige Anbieter beschränken (müssen). Für nicht so kritische Dienste kann man auch andere Anbieter, mit denen man noch keine Erfahrungen gesammelt hat, in die engere Wahl nehmen.

Identity as a Service

Nachdem nun die Entwicklung, die Security und die organisatorischen Belange diskutiert worden sind, soll beispielhaft skizziert werden, wie eine solche Architektur aussehen kann.

Daten Virtualisierung

Die Basis bildet weiterhin die Gesamtheit der Daten im Unternehmen. Nur erfolgt der Zugriff nicht mehr direkt, sondern über eine Virtualisierungsschicht. Damit können der Speicherort, das Zugriffsverfahren und die Attributnamen vor den Applikationen verborgen werden. Diese arbeiten auf einer virtuellen Datenschicht, die durch Konfiguration erstellt wird. Die für die jeweilige Applikation in diesem Umfeld notwendige Konfiguration, kann dann in einer Policy zusammen gefasst werden. Hierdurch ist es möglich, die für eine Applikation sichtbaren Daten einzuschränken oder je nach Ursprungsort des Zugriffs oder Identität des Zugreifenden festzulegen. Diese Vorgehensweise kann die Systemsicherheit erheblich verbessern, da die Daten im Zweifel nicht auf der Applikationsebene sichtbar sind.

Abb. 3: Identity as a Service - High-Level Architektur

Der applikative Zugriff erfolgt über Attributnamen der Virtualisierungsschicht, die innerhalb dieser Schicht auf die Namen der physikalischen Schicht abgebildet werden.

Durch diese Abstraktionsschicht ist es möglich, die zugrundeliegenden Datenbanken und Verzeichnisdienste auszutauschen oder zu erweitern, ohne dass die daraufzugreifenden Applikationen angepasst werden müssen.

Basisdienste

Neben vielen anderen Diensten, die in der Basisinfrastruktur zur Verfügung gestellt werden müssen, sind die Authentifizierung, Autorisierung und das Logging als wichtigste Dienste zu nennen. Auf dieser Ebene sind auch Maßnahmen zur Föderation oder die Einbindung weiterer Authentifizierungsverfahren wie OpenID oder CardSpace anzusiedeln.

Authentifizierung

Die Authentifizierung muss so implementiert sein, dass beliebige Verfahren zum Einsatz kommen können. Im einfachsten Fall ist das sicherlich UserID und Passwort, aber auch biometrische Verfahren sollten zur Verfügung stehen oder ohne grossen Aufwand implementiert werden können. Wichtig ist, dass damit allen Applikationen alle Authentifizierungsverfahren zur Verfügung stehen. Das gewünschte Verfahren wird nur noch konfiguriert und ist nicht mehr fest einprogrammiert. Somit ist die Auswahl eines Verfahren nach qualitativen Anforderungen, je nach Einsatz der Applikation, möglich.

Autorisierung

Die Autorisierung ist abhängig von den Applikationen und der eingesetzten Plattform. Diese kann an Gruppenzugehörigkeiten, Profile oder den Inhalt bestimmter Attribute gebunden sein. In dieser Schicht werden die applikationsspezifischen Anforderungen abstrahiert. Mit konfigurierbaren Berechtigungsverfahren auf Basis unterschiedlichster Attribute, wie Identität, Tageszeit, Ort des Zugriffs und vielen weiteren wird entschieden, ob der Zugriff erfolgen darf oder verwehrt wird.

Protokollierung

Die Protokollierung aller Aktionen im Gesamtsystem in einem einheitlichen Format ist die Grundvoraussetzung, um jegliche Vorgänge nachvollziehbar zu machen. Die Protokollierung muss dabei in einer Art und Weise erfolgen, dass spätere Änderungen oder Verfälschungen nicht möglich sind, ohne dass diese auffallen. Andernfalls ist die Revisionssicherheit nicht gegeben.

Security Services Infrastruktur

Auf dieser Ebene werden den Applikationen höherwertige Dienste zur Verfügung gestellt, die schon auf einem sehr viel höheren Abstraktionslevel angesiedelt sind als die Datendienste.

So stellen Role Services nach erfolgtem Role Mining Dienste zur Verfügung, um Rollen zu vergeben und die Zugehörigkeit abzufragen.

Im Rahmen der Policy Services wird konfigurativ festgelegt, was die Anforderungen einer Applikation an die Sicherheit sind, ob die Nachrichten verschlüsselt werden müssen, welches Authentifizierungsverfahren und Authorisierungsverfahren verwendet werden soll.

Da im Rahmen des Identity- und Access Managements der Zugriff auf Organisationsressourcen geregelt wird, ist es üblich, Genehmigungsprozesse einzubinden. Dabei kann es vorkommen, dass eine für den Prozess notwendige Person in Urlaub ist. Dann muss gewährleistet sein, dass es etablierte Eskalationsprozesse gibt, die es den Betroffenen gestatten, weiter zu agieren. Diese Mechanismen sind auch für alle weiteren genehmigungspflichtigen Vorgänge von Interesse.

Der Themenblock Reporting und Audit bietet die Möglichkeit, diese Dienste in eigene Applikationen einzubinden oder sogar so weit zu gehen, die für das Audit erzeugten Regelsätze schon in den Applikationen zu nutzen, um zu entscheiden, ob bestimmte Eingaben regelkonform sind oder nicht.

Applikationsinfrastruktur

Diese Schicht stellt die bereits bekannten Dienste wie Laufzeitumgebung und Hochverfügbarkeit bereit. Darüber hinaus liegen hier neue Aufgaben wie die Verwaltung von angemeldeten Web Services und der Betrieb eines zugehörigen Verzeichnisdienstes, damit Applikationen die Möglichkeit haben, den gewünschten Service zur Laufzeit zu ermitteln.

Außerdem sind auf dieser Ebene die Werkzeuge zur Orchestrierung – das heißt zur Zusammenstellung neuer Applikationen - angesiedelt. Hier werden aus einem Pool von Web Services mit grafischen Hilfsmitteln neue Applikationen erstellt.

Ausblick

Es steht außer Frage, dass SOA kommen wird und dass die Applikationserstellung auf eine neue Ebene gehoben wird. Damit das Ganze sicher und den Regularien entsprechend erfolgen kann, muss das Identity- und Access Management diesen Weg mitgehen. Die existierenden Produkte müssen weiter entwickelt werden und ihre Dienste sehr feingranular ebenfalls als Services angeboten werden. Dies wird auf dem Weg zum Geschäftsprozess orientierten Identity Management jedoch nicht ausreichen. Alle großen Hersteller denken zur Zeit darüber nach, diesen Weg zu gehen oder haben schon eine konkrete Roadmap. Kleinere Hersteller werden folgen müssen, wollen Sie nicht vom Markt verschwinden. Grundvoraussetzung ist eine verlässliche Identitätsbasis, die aber jederzeit mit marktüblichen Identity Management Produkten erarbeitet werden kann. Der nächste Schritt ist ein durchgehendes Rollenkonzept. Auch hierfür gibt es bereits Werkzeuge auf dem Markt. Diese müssen Unterstützung für die Rollen Analyse, sowie für die Rollen Modellierung bieten, damit eine belastbare Basis für die Audit bzw. Compliance Services aufgebaut werden kann. Mit der Zeit wird man damit eine Identity und Access Management Umgebung vorfinden, die als stabile Basis für die Entwicklung von geschäftsorientierten Applikationen dienen kann.

Literatur

• Identity Management section on Sun Developer Network
• BigAdmin Multilingual Hub
• BigAdmin Collection of Security Resources for System Administrators
• Documentation at http://docs.sun.com
• Sun training (http://www.sun.com/training/)
• Discussions such as Sun Developer Forums
• Support:
  • Sun resources:
    • Register your Sun gear
    • Services
    • SunSolve Online
  • Community system administration experts
• Events of interest to users of Sun products
  • Worldwide developer events and Sun Tech Days
  • Current events

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.