Zugriffsschutz für Web Services - eine Krankenhausfallstudie

Transkript

1 Zugriffsschutz für Web Services - eine Krankenhausfallstudie Manuel Koch 2 Roman Kober 2 Cristian Oancea 2 Johannes Bernarding 1 1 Abteilung Medizinische Informatik, Universitätsklinikum Benjamin Franklin, FU Berlin 2 Institut für Informatik, FU Berlin Enleitung Neue Entwicklungen von Hard- und Softwarekomponenten im Bereich interner und externer Internetanwendungen ermöglichen zunehmend den Einsatz neuer Dienste und den Zugriff auf verteilte Ressourcen. Eine für den Arzt wichtige Funktionalität ist hierbei der Zugriff auf Wissensdatenbanken, der es während der Visite oder anderer ärztlicher Tätigkeiten erlaubt, Zusatzinformationen einzuholen. Beim Einsatz von Web Service-Funktionalitäten muss ein Zugriffsschutz für das Gesamtsystem realisiert werden. Sowohl die Anfrage als auch die Antwort des Web Services werden mit dem auf XML-basierenden Simple Object Transfer Protocol (SOAP) beschrieben. Sicherheitsaspekte und Standards für Web Services sind aktueller Forschungsgegenstand, so dass es noch wenige Werkzeuge zur Spezifikation und vor allem zum Durchsetzen von Zugriffsschutzpolitiken gibt. In zwei Beispielanwendungen soll die konkrete Spezifikation des Zugriffsschutzes innerhalb des ärztlichen Arbeitsflusses untersucht und realisiert werden: Web Service Medikamente: Dieser Dienst bietet Informationen zu Medikamenten an, wie sie in der Roten Liste zu finden sind. Darüber hinaus können Wirkstoffkonflikte, Allergiekonflikte, Wirkstoff- bzw. Medikamentalternativen etc. abgefragt werden. Der Dienst ist ein Prototyp für den Zugriff auf verteilte Wissensdatenbanken mit medizinischen Grundund Spezialwissen. Web Service Patientenakte: Dieser Dienst bietet Teilmengen der Informationen zu Patienten an, die in einer elektronischen Patientenakte gespeichert sind. Ziel ist die Realisierung eines gesicherten Austausches der Patienteninformationen zwischen verschiedenen Krankenhäusern, so dass vorher erfolgte Untersuchungen schnell für weitere Behandlungen zur Verfügung stehen. In datenschutzrelevanten Web Services wie beispielsweise bei der Patientenakte dürfen berechtigte Ärzte auf sensible Patienteninformationen anderer Krankenhäuser zugreifen. Hierbei sind verschiedene Zugriffslevel zu definieren, die geeignet spezifiziert und vom System umgesetzt werden müssen. In der Arbeitsgruppe wurde mit der Infrastruktur RACCOON eine Beschreibungssprache entwickelt, mit der sich Zugriffsschutzpolitiken in verteilten System spezifizieren lässt. Insbesondere wird eine dynamische Zugriffsverwaltung ermöglicht, die, bedingt durch die hohe Fluktuation bei den ärztlichen Kräften, eine wichtige Forderung an jedes System ist. Wir zeigen in diesem Artikel, wie die fehlenden Sicherheitskonzepte und werkzeuge zur Gewährleistung der Sicherheit für Web Services mittels RACCOON zur Verfügung gestellt werden können und wie so ein unbefugtes Ausführen der medizinischen Web Services der Fallstudie verhindert wird. Die Benutzung von RACCOON zur Gewährleistung des Zugriffsschutzes sowohl für Web Services als auch andere verteile Krankenhausapplikationen ermöglicht ein einheitliches

2 Zugriffsschutzmodell und einheitliche Managementwerkzeuge. Sie erleichtert somit die Sicherheitsadministration. Hiermit wurde eine einheitliche IT-Infrastruktur zum Durchsetzen von spezifizierten Politiken geschaffen. Der Artikel ist wie folgt gegliedert: Zunächst stellen wir die beiden von uns benutzten Web Services vor und der anschließende Abschnitt präsentiert die Architektur der Fallstudie. Die nächsten beiden Abschnitte befassen sich mit dem Zugriffsschutz für Web Services. Zunächst zeigen wir, wie sich eine Zugriffsschutzpolitik spezifizieren lässt, danach zeigen wir, wie sich diese in einem verteilten System durchsetzen lässt. Eine Zusammenfassung des Artikels und dessen Ergebnisse schließt den Artikel ab. Web Services im Krankenhaus Web Services erlauben ein standardisiertes Zusammenarbeiten von Anwendungen verschiedener Organisationen über das Internet, wobei die Kommunikation über ein standardisiertes und auf XML basierendem Protokoll, dem Simple Object Access Protocol (SOAP), erfolgt. Dieses Protokoll erlaubt, Web Services unabhängig von Plattform und Programmiersprache zu beschreiben. Web Services können einfache Operationen realisieren, wie das Ermitteln des aktuellen Wertes eines Wechselkurses, aber auch komplexe Geschäftssysteme, welche Informationen aus verschiedenen Quellen erfragen und kombinieren. Wir betrachten in diesem Artikel einen Medikamenten- und einen Patientenakten-Web Service. Die Schnittstellen mit den Web Service Operationen zeigt Abbildung 1. Die Operationen des Medikamentenservices haben folgende Bedeutung: registrieren(): Mit dieser Operation meldet sich ein Krankenhaus für den Web Service an. Erst nach einer erfolgreichen Anmeldung können die anderen Operationen genutzt werden. zeigeinfo(): Zeigt die gesamten Informationen zu einem Medikament an. Die Informationen zu Medikamenten sind mit denen in der Roten Liste vergleichbar. suchemedikamente(): Gibt alle Medikamente an, die einen bestimmten Wirkstoff enthalten. ermittlekonflikte(): Gibt alle Medikamente an, die zu einem bestimmten Medikament in Konflikt stehen. ermittlewirkstoffkonflikte(): Gibt alle Wirkstoffe an, die zu einem bestimmten Wirkstoff in Konflikt stehen. suchealternative(): Gibt eine Liste von Medikamenten aus, die alternativ zu einem Medikament eingesetzt werden können. empfehlemedikament(): Schlägt eine Liste von Medikamenten vor, die zur Behandlung von bestimmten Symptomen geeignet sind. Der Medikamentenservice geht über eine einfache Abfrageschnittstelle zu einer Wissensdatenbank wie der Roten Liste hinaus, da auch Operationen existieren, die Anwendungslogik beinhalten. Zum Beispiel die Ermittlung von Konflikten zwischen Medikamenten bzw. Wirkstoffen oder die Ermittlung von Medikamentalternativen.

3 Abbildung 1 Mit dem Patientenaktenservice bietet ein Krankenhaus anderen Krankenhäusern an, die Patientenakten ihrer Patienten einzusehen. Die Operationen des Patientenaktenservices haben folgende Bedeutung: registrieren(): Mit dieser Operation meldet sich ein Krankenhaus für den Web Service an. Erst nach einer erfolgreichen Anmeldung können die anderen Operationen genutzt werden. deregistrieren(): Mit dieser Operation meldet sich ein Krankenhaus vom Service ab. registrieredoktor(): Ärzte dürfen nur auf die Akte eines Patienten eines anderen Krankenhauses zugreifen, wenn sie den Patienten in ihrem Krankenhaus behandeln. Mit der Operation registrieredoktor() wird ein Doktor für einen Patienten registriert. deregistrieredoktor(): Der Arzt wird für einen Patienten abgemeldet. listepatientenakten(): Gibt eine Liste aller Patientenakten aus. suchepatientenakte(): Sucht die Patientenakte zu einem bestimmten Patienten. liesakte(): Zeigt den Inhalt einer Patientenakte an. Es darf nur ein Arzt eine Akte eines Patienten lesen, für den er vorher registriert wurde. Architektur Die Architektur unserer Web Service Fallstudie setzt auf einer CORBA-basierten Krankenhausanwendung auf, die in [B KK02, BKL03] ausführlich beschrieben ist. Zentraler Bestandteil der Architektur ist ein durch einen CORBA-Server realisiertes Krankenhausinformationssystem, welches die elektronischen Patientenakten hält und verwaltet. Ärzte und Pflegepersonal des Krankenhauses, falls geeignete Zugriffsrechte vorhanden sind, können sich die Akten mittels einer Klientensoftware ansehen und ergänzen. Die Klientensoftware kann dabei ebenfalls auf mobilen Geräten, wie einem PDA, laufen. Die im vorigen Abschnitt beschriebenen Web Services sind in diese CORBA-basierte Infrastruktur integriert (siehe Abbildung 2): Der Medikamenten Web Service wird von einem externen Anbieter zur Verfügung gestellt, welcher sich um die Wartung der Medikamenteninformationen und deren Bereitstellung kümmert. Krankenhaus A registriert sich für den Medikamentenservice beim externen Anbieter, woraufhin die

4 Ärzte und das Pflegepersonal von Krankenhaus A diesen Service benutzen können. Den Ärzten und dem Pflegepersonal muss ein geeigneter SOAP-Klient zur Verfügung gestellt werden, mit dem sie auf den Service zugreifen können. Der Patientenaktenservice wird von einem Krankenhaus B angeboten und erlaubt anderen Krankenhäusern auf die Akten von Patienten des Krankenhauses B zuzugreifen. Dadurch kann beispielsweise Krankenhaus A die Krankengeschichte eines Patienten einsehen, der vorher schon im Krankenhaus B behandelt wurde und somit eine bessere Behandlung gewährleisten. Krankenhaus A kann den Patientenservice allerdings nur nutzen, wenn es sich vorher bei Krankenhaus B für den Service registriert hat, z.b. im Falle von miteinander kooperierenden Krankenhäusern. Auch hier muss den Ärzten im Krankenhaus A ein SOAP-Klient bereitgestellt werden, der den Zugriff auf den Patientenservice übers Internet erlaubt. Krankenhaus B Web Service Patientenakte Arzt/Pflege Klient Web Service Medikament C O R B A Externer Anbieter S O A P Abbildung 2 Die Verwaltung, Wartung und Modifikation der Patientenakten liegt allein bei Krankenhaus B. Die Informationen für den Web Service Patientenakte stammen vom internen Krankenhausinformationssystem. Da das Krankenhausinformationssystem durch einen CORBA- Server realisiert wird, muss der Web Service Patientenakte über CORBA mit dem CORBA-Server kommunizieren, um die Informationen zu einer Akte zu ermitteln. Daher muss die Implementierung des Web Services Patientenakte einen CORBA-Klient enthalten, der die Informationen der Patientenakten vom Krankeninformationssystem holt (siehe Abbildung 3). Krankenhaus B C O R B A Web Service Patientenakte Corba-Klient Abbildung 3

5 Zugriffsschutzspezifikation für die Krankenhaus - Web Services Der Zugriff auf den Medikamenten- und Patientenakten-Web Service ist nur berechtigten Personen zu erlauben. Der Anbieter des Medikamenten-Web Services wird beispielsweise nur seinen Kunden einen Zugriff erlauben. Auf den Patientenakten-Web Service dürfen nur bestimmte Krankenhäuser zugreifen und hier auch nur bestimmtes Personal. Die Zugriffsschutzanforderungen können in der View Policy Language (VPL) beschrieben werden, welcher das View-based Access Control (VBAC) Modell zugrunde liegt [Brose02, Brose01]. Zentrale Konzepte des VBAC Modells sind Views und Rollen. Eine View beschreibt eine Menge von Zugriffsrechten für den Aufruf von Web Service-Operationen. Eine View könnte beispielsweise die Rechte zum Aufrufen der Operationen registrieren() und deregistrieren() des Patientenakten-Web Service enthalten. Die Rollen dienen als Verbindung zwischen den Views und den Benutzern. Ein Benutzer kann eine Web Service-Operation ausführen, wenn er bzw. sie eine Rolle besitzt, der eine View mit dem benötigten Zugriffsrecht zugeordnet ist. Die Rollen in unserer Fallstudie sind Krankenhausverwaltung, Arzt und Pflegepersonal. Die Krankenhausverwaltung bestimmt, ob die Web Services genutzt werden sollen. Sie registriert das Krankenhaus für den Medikamenten- bzw. Patientenakten-Web Service. Nachdem die Krankenhausverwaltung sich für die Web Services registriert hat, können die Ärzte und das Pflegepersonal diese Services nutzen. In welcher Weise diese Nutzung besteht, wird im folgenden mit der VPL beschrieben. Eine View wird in VPL mit dem Schlüsselwort View eingeleitet, gefolgt vom Viewnamen. Danach wird mittels des Schlüsselwortes controls der Web Service spezifiziert, zu dem die Operationen der View gehören. Eine View darf nur Operationen zu einem Web Service enthalten, d.h. Operationen zu mehreren Web Services dürfen nicht in einer View vermischt werden. Die View MedRegistrierung beinhaltet das Recht zum Aufrufen der Operation registrieren() des Web Services Medikamentenservice. Eine Rolle, welcher die View MedRegistrierung zugeordnet wird, kann somit die Operation registrieren() aufrufen, nicht jedoch die anderen Operationen des Medikamentenservice, falls nicht weitere Views für diese Rolle existieren. View MedRegistrierung controls Medikamentenservice { registrieren } Die View MedNutzung gibt die Rechte zum Aufrufen der restlichen Operationen des Medikamentenservice. View MedNutzung controls Medikamentenservice { } zeigeinfo suchemedikamente ermittlekonflikte ermittlewirkstoffkonflikte suchealternative empfehledokument

6 Die View PAktenRegistrierung betrifft den Patientenaktenservice. Sie gibt das Recht zum Aufrufen der Operationen registrieren(), deregistrieren(), registrieredoktor() und deregistrieredoktor(). Im Gegensatz zu den bisherigen Views, modifizieren die Operationen dieser View den Sicherheitszustand. Der von uns betrachtete Sicherheitszustand besteht aus einer Menge von Paaren (DoktorID, AktenID). Zur Modifizierung des Sicherheitszustandes existieren die Aktionen add, remove und exists. Die Operation add fügt dem Sicherheitszustand ein Paar (doktorid, aktenid) zu, die Operation remove entfernt ein oder möglicherweise mehrere Paare aus der Menge und die Operation exists prüft, ob ein Paar in der Menge enthalten ist. Wir haben uns bemüht, dass die Operationen zur Modifikation des Sicherheitszustandes möglichst einfach sind und nicht zur Implementierung der Anwendungslogik genutzt werden können. Dadurch haben wir eine saubere Trennung zwischen Sicherheits- und Anwendungslogik. Das Aufrufen der Operation registrieredoktor() erzeugt eine Aktion zur Modifikation des Sicherheitszustandes. Dies wird mittels des Schlüsselwortes action gefolgt von der Modifikationsoperation spezifiziert. Im Falle der Operation registrieredoktor() wird ein neues Paar, definiert durch die Parameter der Operation, zugefügt. Bei der Operation deregistrieredoktor() werden alle Paare entfernt, die die DoctorID betreffen, welche der Operation als Parameter übergeben wurde. Dabei ist der zweite Wert des Paares (DoctorID, AktenID) nicht relevant, gekennzeichnet durch das Zeichen _. View PAktenRegistrierung controls Patientenaktenservice { } registrieren deregistrieren registrieredoktor(paktenid,doktorid) action add(doktorid,aktenid) deregistrieredoktor(doktorid) action remove(doktorid,_) Die View PAktenNutzung gibt die Rechte zum Zugriff auf die Patientenakten. Sie erlaubt das Aufrufen der Operationen listepatientenakten(), suchepatientenakte() und liesakte(). Im Gegensatz zu allen bisherigen Operationen, darf die Operation liesakte() nicht mit allen möglichen Parametern aufgerufen werden. Wir fordern, dass nur derjenige Arzt die Akte eines Patienten einsehen darf, der von ihm aktuell behandelt wird. Eine Einschränkung eines Rechtes zum Aufrufen einer Operation wird mit dem Schlüsselwort if spezifiziert. Die Bedingung für die Operation liesakte() fordert, dass der Parameter DoctorID mit der ID des Aufrufers der Operation (spezifiert durch caller) übereinstimmt und der Sicherheitszustand ein Paar für den Arzt und die angeforderte Patientenakte enthält. Diese Bedingung gewährleistet, das Ärzte nur Patientenakten von Patienten lesen, für die sie registriert wurden. View PAktenNutzung controls Patientenaktenservice { } listepatientenakten suchepatientenakte liesakte( AktenID, DoktorID ) if caller = DoktorID and exists (DoktorID, AktenID)

7 Die Operationen listepatientenakten() und suchepatientenakte() können hingegen unabhängig vom aktuellen Sicherheitszustand aufgerufen werden. Somit können Ärzte beispielsweise auch nach Patientenakten von Patienten suchen, für die sie nicht registriert sind. Sie dürfen die Akten dann allerdings nicht einsehen. Views werden Rollen zugeordnet. Hierbei wird zum einen die initiale Zuordnung spezifiziert als auch die Möglichkeiten der dynamischen Änderung von Viewzuordnungen. Die initiale Zuordnung der Views wird für unser Beispiel wie folgt spezifiziert: role Krankenhausverwaltung holds MedRegistrierung, PAktenRegistrierung Arzt, Pflegepersonal Die Rolle Krankenhausverwaltung besitzt die Views MedRegistrierung und PAktenRegistrierung (spezifiziert mittels des Schlüsselwortes holds). Die Krankenhausverwaltung bestimmt, ob und wann die Services registriert werden. Die Rollen Arzt und Pflegepersonal besitzen anfänglich keine Views. Ihnen werden erst nach der Registrierung der Web Services entsprechende Views zugeordnet. Die dynamische Zuordnung von Views wird mit Schemas beschrieben. Ein Schema wird mittels des Schlüsselwortes schema spezifiziert, gefolgt vom Schemanamen und dem Schlüsselwort observes, welches den Web Service spezifiziert, für den das Schema gilt. Für jede Operation des Web Services können (müssen aber nicht) assigns und removes Ausdrücke spezifiziert werden. Ein assigns- Ausdruck spezifiziert die Zuordnung einer View zu Rollen, ein removes-ausdruck das Entfernen einer View von Rollen. Im Schema MedServiceAnmeldung wird beim Aufruf der Operation registrieren() (d.h. nachdem sich das Krankenhaus beim Medikamentenservice angemeldet hat) die View MedNutzung den Rollen Arzt und Pflegepersonal zugeordnet. Im Besitz dieser View, können Ärzte und das Pflegepersonal nun den Medikamentenservice benutzen. schema MedServiceAnmeldung observes Medikamentenservice { registrieren assigns MedNutzung to Arzt, Pflegepersonal } Im Schema PaAktenAnmeldung wird bei der Operation registrieren() die View PAktenNutzung der Rolle Arzt zugefügt. Danach können Ärzte eine Liste der Patientenakten abfragen und nach Patientenakten suchen. Das Lesen einzelner Patientenakten ist nun ebenfalls möglich, allerdings nur wenn der Arzt für die entsprechende Akte registriert ist. Meldet sich ein Krankenhaus mittels der Operation deregristieren() vom Patientenaktenservice ab, wird die View PAktenNutzung den Ärzten wieder entzogen (spezifiziert durch den removes-ausdruck). schema PaAktenAnmeldung observes Patientenaktenservice { registrieren assigns PAktenNutzung to Arzt deregistrieren removes PAktenNutzung from Arzt }

8 Durchsetzen der Zugiffsschutzpolitik mit RACCOON Nachdem die Zugriffsschutzpolitik mit der VPL spezifiziert wurde, muss sie im laufenden Systembetrieb auch durchgesetzt werden. Hierzu wurde die Infrastruktur RACCOON entwickelt, die mit einer in VPL spezifizierten Zugriffsschutzpolitik konfiguriert wird [B rose01b]. Graphische Managementwerkzeuge dienen dem Administrator zur Verwaltung der Zugriffsschutzpolitik [Noffke01]. Die RACCOON-Infrastruktur wurde für den Einsatz in CORBA-Umgebungen konzipiert. Wir zeigen im folgenden, wie RACCOON ebenfalls zum Durchsetzen der Zugriffsschutzpolitik für Web Services eingesetzt werden kann. Die RACCOON-Infrastruktur verwaltet die in einer VPL-Zugriffsschutzpolitik spezifizierten Rollen auf einem Rollen-Server, die Views und Schemas auf einem Politik-Server (siehe Abbildung 4). Die Zugriffsschutzentscheidungen werden von RACCOON auf der Basis dieser beiden CORBA-Server gefällt. Wenn sich ein Benutzer im System authentifiziert, bekommt er/sie alle seine/ihre Rollenzertifikate vom Rollen-Server. Beim Aufruf einer Operation eines Zielobjektes, welches sich auf einem CORBA-Server befindet, werden die Rollenzertifikate mit dem Aufruf übertragen. Dieser Aufruf wird durch einen CORBA-Interceptor abgefangen und zum Zugriffsschutzentscheidungsobjekt weitergeleitet. Dieses Objekt entscheidet auf der Basis der gesendeten Rollenzertifikate und der aktuellen Politik, die sich auf dem Politik-Server befindet, ob der Aufruf der Operation für den Klienten erlaubt ist oder abgelehnt wird. Wenn ein Aufruf erlaubt ist, leitet der Interceptor den Aufruf an das Zielobjekt auf dem Server weiter, ansonsten wird der Aufruf abgelehnt. Abbildung 4 Die beschriebene RACCOON-Infrastruktur wird jetzt ebenfalls zum Durchsetzen der Zugriffsschutzpolitik in Web Services-Umgebungen benutzt. Es muss dazu der Interceptor modifiziert werden, da er im Falle von Web Services SOAP-Nachrichten abfangen muss anstelle von CORBA- Aufrufen. Daher haben wir einen Interceptor geschrieben, der SOAP-Nachrichten abfängt und diese dann (genauso wie der CORBA-Interceptor) an die RACCOON-Infrastruktur weiterleitet. Entsprechend der RACCOON-Zugriffsschutzentscheidung wird die SOAP-Nachricht dann weitergeleitet oder abgelehnt.

9 Abbildung 5 zeigt die Integration in die RACCOON-Infrastruktur. Zentrales Element ist der Interceptor für die SOAP-Nachrichten. Dieser basiert auf dem Handler-Konzept, welches von der SOAP-Implementierung Axis [A xis] bereitgestellt wird. Die Web Services sind auf einem Tomcat Web Server [Tomcat] installiert. Sendet ein SOAP-Klient (in unserer Fallstudie Teil des Arzt- und Pflegepersonalklienten) eine SOAP-Nachricht zu einem Web Service, fängt der SOAP-Interceptor die Nachricht ab. Der SOAP-Interceptor implementiert einen CORBA-Klienten, der mit der RACCOON- Infrastruktur zum Zwecke der Zugriffsschutzentscheidung kommunizieren kann. Web Server (Tomcat) Arzt/Pflege Klient SOAP SOAP- Interceptor (Axis) Web Service CORBA RACCOON Abbildung 5 Zusammenfassung und Ergebnisse Wir haben an zwei Beispielen gezeigt, wie sich Web Services im Krankenhaus einsetzen lassen. Web Services können zum einen zur Integration einer internen Krankenhausanwendung mit einer Anwendung dienen, die von einem externen Anbieter über das Internet angeboten wird (Medikamentservice). Zum anderen kann die Zusammenarbeit zwischen Krankenhäusern über das Internet realisiert werden und die Datenquellen mehrerer Krankenhäuser können einfach integriert werden (Patientenaktenservice). Die Patientenakten eines Krankenhauses müssen von anderen Krankenhäusern nicht lokal gehalten werden. Es kann die aktuelle Akte übers Internet angefordert werden, in dem Moment, in dem sie gebraucht wird. Der Verwaltungsaufwand liegt allein bei dem Krankenhaus, welchem die Patientenakte gehört, das Krankenhaus, welches den Patientenakten-Web Service nutzt hat keinen Wartungsaufwand. Die Integration erfolgt dabei immer durch das standardisierte SOAP-Protokoll. Wir haben die Zugriffsschutzanforderungen der vorgestellten Web Services betrachtet und gezeigt, wie sich die Anforderungen mit der View Policy Language in einer Zugriffsschutzpolitik spezifizieren lassen. Zum Durchsetzen der spezifizierten Zugriffsschutzpolitik haben wir die RACCOON- Infrastruktur genutzt, welche auch für die interne Krankenhausanwendung zur Zugriffsschutzverwaltung eingesetzt wird. Wir haben die Implementierung vorgestellt, die es ermöglicht, die RACOON-Infrastruktur zum Durchsetzen von Web Services zu nutzen. Durch die Integration des RACCOON-Zugriffsschutzmodells in Web Service-Umgebungen kann für die Spezifikation der Zugriffsschutzanforderungen der internen Anwendung als auch für die Web Service-Anwendungen ein gemeinsames Zugriffsschutzmodell verwendet werden. Dies vereinfacht dem Sicherheitsadministrator die Verwaltung des Systems durch einheitliche Managementwerkzeuge und verringert die Wahrscheinlichkeit von Administrationsfehlern. Dies erhöht die Gesamtsicherheit des Systems.

10 Referenzen Axis BKK02 BKL03 Brose01 Brose01b Brose02 FKO03 OMG00 Noffke01 Tomcat Apache. Axis. J. Bernarding., M. Koch, R. Kober, Handhabbare Zugriffsschutzverwaltung in verteilten Krankenhaussystemen mit Raccoon, in Proc. 7. Telematik im Gesundheitswesen (TELEMED2002), 2002 G. Brose, M. Koch, K.-P. Löhr, Entwicklung und Verwaltung von Zugriffsschutz in verteilten Objektsystemen - eine Krankenhausfallstudie, in Praxis der Informationsverarbeitung und Kommunikation (PIK), PIK 26 (2003) 1, 2003 G. Brose, Access Control Management in Distributed Systems, Dissertation, Freie Universität Berlin, 2001 G. Brose, Raccoon An infrastructure for managing access control in CORBA. In Proc. International Conference on Distributed Applications and Interoperable Systems (DAIS), Kluwer, 2001 G.Brose, ManageableAccess Control for CORBA. Journal of Computer Security, 4: , 2002 T. Fink, M. Koch, C. Oancea, Specification and Enforcement of Access Control in Heterogeneous Distributed Applications. In Proc. International Conference on Web Services ICWS-Europe 2003, LNCS 2853, pages , Springer Verlag, 2003 OMG. The Common Object Request Broker: Architecture and Specification, Revision 2.4., 2000 N. Noffke, Entwurf und Implementierung eines Rollendienstes für die Zugriffskontrolle in CORBA. Diplomarbeit, Freie Universität Berlin, 2001 Apache. Tomcat.