Rollenbasierte Rechtevergabe (RBAC)

Zugriffskontrolle erf¨ullt die Aufgabe der ¨Uberwachung des Zugriffs auf bestimmte Res-sourcen mit dem Ziel, die Integrit¨at, Vertraulichkeit und Verf¨ugbarkeit von Informationen

59Fingerabdruck, Iris-Muster etc.

60Biometrische Systeme verwenden zur Authentifizierung die Hashwerte von bestimmten digitalisierten K¨orpermerkmalen. Unter der Voraussetzung, dass man die f¨ur die Hash-Errechnung verwendeten Verfahren kennt und ¨uber das passende Ger¨at zur ¨Ubermittlung der Daten an das authentifizierende System verf¨ugt, kann man mit einem vertretbaren Aufwand die Identit¨at einer anderen Person vort¨auschen (

”stehlen“).

sicherzustellen. Ein Zugriffskontrollsystem ¨ubernimmt die Aufgaben der Zugriffskotrolle und entscheidet auf der Basis eines Regelwerks, ob der Zugang auf bestimmte Dienste und Ressourcen gew¨ahrt oder verwehrt wird. F¨ur den Einsatz im Bereich der medizinischen For-schung muss ein Zugriffskontrollsystem mehrere Anforderungen erf¨ullen (vgl. [bsi11d, M 2.8, M 2.80]):

• Die Zugriffsentscheidungen d¨urfen nicht manipulierbar sein (Integrit¨at der Zugriffs-entscheidungen).

• Das System muss fehlertolerant sein. Bei Systemausf¨allen und -st¨orungen muss das Zugriffskontrollsystem in geeigneter Weise reagieren, ohne die Funktionalit¨ at/Sicher-heit der gesamten Infrastruktur zu gef¨ahrden.

• Das Zugriffskontrollsystem muss leicht wartbar sein, da die ¨Anderungen der Zu-griffsumgebung (z. B. bei Personal¨anderungen) eine schnelle/einfache Anpassung erfordern.

• Um die Unterschiede der Forschungsnetzteilnehmer in Bezug auf die Sicherheit der Verbindung bzw. der Arbeitsumgebung zu ber¨ucksichtigen, muss das Zugriffskon-trollsystem eine Parametrisierung der Zugriffe unterst¨utzen.

• Das System muss eine ausf¨uhrliche Protokollierung erm¨oglichen, da im Forschungsnetz mit vertraulichen Patientendaten gearbeitet wird.

• Insbesondere im Behandlungszusammenhang muss das System eine hohe Verf¨ugbarkeit aufweisen, damit kontrollierte Zugriffe stattfinden k¨onnen.⁶¹

Jedes Zugriffskontrollsystem basiert auf einem Zugriffskonzept, dessen prim¨ares Ziel in der Uberpr¨¨ ufung der Zul¨assigkeit von Datenzugriffen besteht. Eine ausf¨uhrliche Auflistung und Bewertung der m¨oglichen Zugriffskonzepte w¨urde den Rahmen dieses Abschnitts sprengen, sodass an dieser Stelle auf die weiterf¨uhrende Literatur verwiesen wird.⁶² IT-Sicherheitsexperten sind sich dar¨uber einig, dass die Berechtigungen einer Person von den durch diese Person zu verrichtenden T¨atigkeiten bestimmt werden sollen, wobei manche Autoren zus¨atzlich zwischen den Organisations- und Rollenmodellen unterscheiden. Die Unterscheidung wird dadurch begr¨undet, dass im Organisationsmodell der

Organisations-61In [Ser01] wird zwischen drei Verf¨ugbarkeitsstufen unterschieden. Danach m¨ussen h¨ochstverf¨ugbare Systeme innerhalb von wenigen Sekunden auf eine Anfrage reagieren, die Wartezeit bei einem hoch-verf¨ugbaren System darf maximal einige Minuten betragen, geringe Verf¨ugbarkeit bedeutet, dass ein System auch f¨ur l¨angere Zeit ausfallen darf. Als Beispiel f¨ur ein System mit geringer Verf¨ugbarkeit wird das Rollenvergabemodul als Bestandteil des Zugriffkontrollsystems genannt. Da dieses Modul f¨ur die Vergabe und Zur¨ucknahme von Berechtigungen zust¨andig ist, liegt es nahe, seine Verf¨ugbarkeitseinstufung als”hoch“ zu deklarieren. In F¨allen des Datenmissbrauchs oder bei Verletzung der Sicherheitsleitlinie m¨ussen den betroffenen Accounts ihre Zugriffsprivilegien schnell wieder entzogen werden k¨onnen. Im Forschungskontext kann eine sogenannte R¨uckfallposition definiert werden: Beispielsweise wird dem nicht administrativen Personal beim Ausfall des Moduls oder dessen Fehlfunktion der Zugriff auf Daten verwei-gert. Im Behandlungskontext w¨are diese L¨osung inakzeptabel, da das Leben und die Gesundheit eines Patienten h¨ohere Priorit¨at als die Geheimhaltung der Patientendaten vor dem Krankenhauspersonal haben w¨urden.

62Umfassende Beschreibungen der Sicherheitsmodelle sind beispielsweise in [Eck07], [Mos02] und [Sch99]

zu finden.

aufbau mithilfe von Benutzergruppen abgebildet wird; beim rollenbasierten Modell stehen die ausgef¨uhrten Aufgaben im Vordergrund (vgl. [PE06]). In der Praxis wird man eine Mischform der beiden Modelle vorfinden, wobei der Schwerpunkt im Folgenden auf den rollenbasierten Zugriffskonzepten liegen wird, zumal wissenschaftliche Untersuchungen die grunds¨atzliche Eignung rollenbasierter Zugriffskonzepte f¨ur den Einsatz im medizinischen Bereich beweisen (vgl. [PBB⁺96]). F¨ur die bessere Eignung dieses Zugriffsmodell spricht auch die Tatsache, dass externe Forschungsnetzteilnehmer nicht zu der Organisation des Forschungsnetzes im engeren Sinne geh¨oren.

Das Verfahren zur Vergabe von rollenbasierten Berechtigungen in Mehrbenutzersyste-men oder Rechnernetzen wird auch als

”Role Based Access Control“ (RBAC) bezeichnet (vgl. [ans04], [FSG⁺01]). RBAC entstand aus Forschungsprojekten des US-Verteidigungsmi-nisteriums (Department of Defense) mit dem Ziel, ein Verfahren zur Zugriffseinschr¨ankung auf vertrauliche Informationen zu entwerfen. Die damals entwickelten Methoden der Zugriffskontrolle: Discretionary Access Control (DAC) und Mandatory Access Control (MAC) erwiesen eine viel zu hohe Komplexit¨at bei der Konzeptumsetzung.⁶³ RBAC als Weiterentwicklung der Konzepte stellt eine alternative Technik dar. Bei RBAC erfolgt die Einteilung der Benutzer in Gruppen, wobei ein Benutzer (Person) seinerseits meh-reren Gruppen angeh¨oren kann. Je nach Gruppenzugeh¨origkeit werden ihm dann die Zugriffsrechte auf Ressourcen erteilt oder verwehrt. Eine Gruppe tr¨agt bei RBAC die Bezeichnung

”Role“ (Rolle) und impliziert in der Regel die auszuf¨uhrende(n) Aufgabe(n) (z. B. Manager, Administrator, Arzt etc.). Durch die Aufteilung in Benutzer und Rollen ist es m¨oglich, Zugriffsrechte auf Gruppenebene (f¨ur mehrere Benutzer gleichzeitig) zu vergeben oder zu ¨andern, was die Administration von Benutzerberechtigungen deutlich erleichtert (vgl. [San96], [SCFY96], [FK92]).

Um zu vermeiden, dass ein Benutzer mehr Berechtigungen erh¨alt, als er f¨ur die Ausf¨uhrung seiner Aufgabe ben¨otigt, muss seine T¨atigkeit vor der (rollenbasierten) Berechtigungsverga-be genau Berechtigungsverga-beschrieBerechtigungsverga-ben werden. Ein Benutzer erh¨alt dabei nur die f¨ur die Ausf¨uhrung seiner T¨atigkeit notwendigen Privilegien (Minimalanforderung), deren Bestimmung nicht immer trivial ist. Oft finden die dieselben Zugriffsrechte in mehreren Rollen wieder; daher bedient man sich der Hierarchien zwecks Vermeidung der Redundanzen in Rollendefinitionen. So kann die Rolle eines behandelnden Arztes s¨amtliche Berechtigungen an einer Patientenakte beinhalten, die auch ein nicht behandelnder Arzt an der Akte besitzt.

63DAC basiert auf der Vergabe von Zugriffsberechtigungen auf Daten, die als Eigentum von Benutzern angesehen werden, was im Falle von Organisationen (und auch im Forschungsnetz) meistens nicht zutrifft.

Die MAC-basierten Zugriffsberechtigungen werden auf Basis der Datenvertraulichkeitseinstufung und der Berechtigung eines Subjektes, auf die Daten bestimmter Vertraulichkeitsstufe zuzugreifen, vergeben. [FK95]:

”(...). A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e. clearance) of subjects to access information of such sensitivity. (...)“. Obwohl DAC und MAC in einigen Zugriffsmodellen wieder zu finden sind, sind sie f¨ur die Abbildung von komplexen Berechtigungsmodellen in der Wirklichkeit nur bedingt geeignet. Der Abgleich der Zugriffsrechte eines Individuums mit der Vertraulichkeitsstufe des entsprechenden Dokuments ist in der realen Welt nicht praktikabel (vgl. [FK92]).

Eine Rolle kann parametrisiert werden: Zugriffsberechtigungen k¨onnen aufgrund von Parametern bestimmt werden. Dies ist z. B. bei der Definition der Rolle

”behandelnder Arzt“ der Fall. Ein behandelnder Arzt unterscheidet sich von einem nicht behandelnden Arzt lediglich durch den Behandlungszusammenhang-Parameter in Bezug auf einen Patienten.

Formal wird die Zugriffskontrolle (ZK) als eine Relation zwischen den Benutzern und den Zugriffsberechtigungen definiert: ZK ⊆Benutzer ×Zugriffsberechtigungen. Ein Benutzer b erh¨alt Zugriffsberechtigung z nur dann, wenn (b, z)∈ZK. RBAC teilt diese Relation in Benutzer- (BZ) und Berechtigungszuweisung (RZ) auf:

BZ ⊆Benutzer ×Rollen,RZ ⊆Rollen×Zugriffsberechtigungen;ZK :=BZ ◦RZ. Somit kann die Zugriffskontrolle auch definiert werden als:

∃rolle ∈Rollen : (b,rolle)∈ZK ∧(rolle, z)∈RZ.

Diese Basisdefinition von RBAC ber¨ucksichtigt allerdings keine dynamischen Zugriffs-einschr¨ankungen⁶⁴ und eignet sich somit weniger gut f¨ur die Abbildung der Zugriffskon-trollstrukturen f¨ur das Forschungsnetz. Aus diesem Grund wird f¨ur die Beschreibung der Zugriffsszenarien in dieser Arbeit eine erweiterte Definition der RBAC nach Torsten Lodderstedt [Lod03] verwendet, die in der Abbildung 6 dargestellt ist.

Subject

Abbildung 6.:Erweiterung des Modells nach Torsten Lodderstedt [Lod03]: Die erweiterte RBAC-Definition erlaubt die Abbildung von solchen dynamischen Zugriffseinschr¨ankungen wie Art der Verbindung, zeitliche Komponente etc. Dies erfolgt durch die Verwendung von sogenannten Constraints.

Nach der erweiterten RBAC-Definition in [Lod03] werden Benutzer, Prozesse und Benut-zergruppen zum Basistyp

”Subjekt“ zusammengefasst. Den Rollen werden Berechtigungen zugeordnet, wobei die Berechtigungen aus Aktionen auf Objekten bestehen. Die o. g. dyna-mischen Abh¨angigkeiten werden mithilfe von Constraints abgebildet. Constraints versehen die Berechtigungen mit Einschr¨ankungen. So kann man beispielsweise die maximale Anzahl der erfolglosen Anmeldeversuche eines Forschungsnetzteilnehmers auf drei beschr¨anken, um die W¨orterbuch- oder Brute-Force-Angriffe vorzubeugen. Die M¨oglichkeiten f¨ur die Nutzung dieser erweiterten RBAC-Definition f¨ur die Berechtigungsvergabe f¨ur die

Szenari-64Standort des Systems, Art der Verbindung, zeitliche Komponente etc.

en in den medizinischen Forschungsnetzen werden im Abschnitt C.3.5

”Beschreibung eines RBAC-Konzeptes mithilfe von SecureUML“ er¨ortert.

Notwendigkeit f¨ur die Vervollst¨andigung rollenbasierter Zugriffsberechtigungskon-zepte durch administrative und organisatorische Vorkehrungen: Unsere Welt besteht aus Ausnahmen und ein Zugriffskonzept ist ein Beispiel daf¨ur. In medizinischen Einrich-tungen steht die Gesundheit bzw. das Leben der Patienten im Vordergrund – Situationen in denen man die beschriebenen Sicherheitsvorkehrungen umgehen k¨onnen muss. In Notsi-tuationen hat nicht die Informationssicherheit oder der Datenschutz die h¨ochste Priorit¨at, sondern die Erhaltung des menschlichen Lebens. Eine umfangreiche Protokollierung der Zu-griffe soll Missbrauch des Notfallkonzeptes minimieren bzw. bei der sp¨ateren Untersuchung des Vorfalls unterst¨utzen.

Die Schwachstelle eines jeden Zugriffsberechtigungskonzeptes besteht in der Tatsache, dass es auf einem Modell⁶⁵ basiert. Schwer zu quantifizierende Elemente wie beispielsweise zwischenmenschliche Beziehungen k¨onnen i. d. R. nicht ber¨ucksichtigt werden. So kann eine unbefugte Kooperation zwischen den Forschungsnetzteilnehmern durch das rollenbasierte Konzept kaum vermieden werden. Die in den Abschnitten 3.3 und 3.4 beschriebenen organisatorischen und administrativen Maßnahmen vervollst¨andigen die rollenbasierten Berechtigungskonzepte und k¨onnen beispielsweise die Umgehung der bei der Vergabe der Zugriffsberechtigungen einzuhaltenden Vier-Augen-Prinzips verhindern.

3.5.5. Zugangsszenarien von Netzteilnehmern zu den Forschungsnetzdiensten

F¨ur den Zugriff von Nutzern auf das Forschungsnetz gelten diverse Einschr¨ankungen, die das Risiko des Datenmissbrauchs minimieren. So werden einem Forscher nicht beliebige Daten zur Verf¨ugung gestellt, sondern nur krankheitsspezifische, klar definierte f¨ur sein Forschungsvorhaben relevante Inhalte. Ein restriktives Zugriffsberechtigungskonzept, die Zweiteilung der Daten inIDAT und MDAT, technische Sicherheit der Datenbankserver, ausgefeilte Anonymisierungs- und Pseudonymisierungsverfahren und viele weitere Maß-nahmen sorgen f¨ur ein geringes Reidentifizierungspotenzial (vgl. [RDSP06]). Trotz der erw¨ahnten Sicherheitsmaßnahmen ist es nicht empfehlenswert, die Forschungsdatenbank zu ver¨offentlichen bzw. jedem Interessenten Zugriff auf diese Datenbank pauschal zu gew¨ahren. Einer der Gr¨unde, die gegen die pauschale Datenfreigabe sprechen, ist die bedingte Anonymisierbarkeit von Patientendaten bzw. die Relativit¨at des Personenbezugs der Daten (vgl. [RHJ08, S. 27 ff.]). Insbesondere l¨asst sich der Personenbezug bei biolo-gischen Proben und den daraus gewonnenen Daten nur schwer bis gar nicht eliminieren

65Das Modell ist ein Abbild, das nicht alle Details der realen Welt erfasst (s. a. Begriffsdefinition im Glossar).

(vgl. [Pom11a]). Die Reidentifizierung von Patientendaten aufgrund von Alleinstellungs-merkmalen ist ebenfalls m¨oglich.⁶⁶ Außerdem k¨onnen Fehler im Anonymisierungs- bzw.

Pseudonymisierungsverfahren entdeckt werden, die eine vereinfachte Reidentifizierung erm¨oglichen. Diese Risikofaktoren in Verbindung mit einer stetig wachsenden Anzahl von Personendatens¨atze enthaltenden (Referenz-)Datenbanken machen die Freischaltung der Forschungsdatenbank nur f¨ur einen auserw¨ahlten vertrauensw¨urdigen Benutzerkreis notwendig (vgl. [Pom10a], [Kre06]). Mit einer ¨ahnlichen Aufgabenstellung wird ein Un-ternehmen bei der Anbindung von Außendienstmitarbeitern oder der Einrichtung von Home-Arbeitspl¨atzen konfrontiert – also dann, wenn ein Ger¨at des Unternehmens die sichere LAN-Umgebung verl¨asst (vgl. [AE08], [RDSP06], [SPR⁺06]).

Das Rezept f¨ur die Sicherung eines kleineren Unternehmensnetzes ist relativ einfach: Man er-mittle die Grenzen eines Netzwerkes sowie dessen Anbindungspunkte an die Außenwelt und sichere diese mithilfe des Firewallings und des Routings ab. Eventuell erhalten die Systeme innerhalb des Netzes zus¨atzliche Immunisierung in Form von Antivirensoftware, Personal Firewalls, Sicherheitspatches und werden regelm¨aßig mithilfe von Compliance-Software auf die Einhaltung von Sicherheitsstandards untersucht. F¨ur ein gr¨oßeres Unternehmen ist diese Aufgabe nicht mehr so einfach zu l¨osen: Das Unternehmensnetz besteht in der Regel aus mehreren r¨aumlich verteilten Segmenten. In der Unternehmenswelt neigt man dazu, diese Segmente ¨uber dedizierte Leitungen miteinander zu verkn¨upfen und die Teilnehmer-systeme an bestimmte Standards zu binden. Man spricht auch von einer harten Schale, die solche Einrichtungen um ein Netz bilden. Das Innere eines Netzes bleibt dagegen leicht angreifbar. Eine Malware, die die sichere ¨außere Schutzschicht ¨uberwindet, kann innerhalb der meist homogenen Struktur immense Sch¨aden anrichten, da die Systeme weitestge-hend gleiche Konfiguration aufweisen⁶⁷ und was noch wichtiger ist, nach dem Prinzip des gegenseitigen Vertrauens funktionieren. Aus diesem Grund wird der

”Defense in Depth“-Ansatz zunehmend popul¨ar. Dieser Ansatz sieht vor, dass Infrastrukturbestandteile durch diverse Maßnahmen (Personal Firewalls, HIDS, Weiterleitung von sicherheitsrelevanten Informationen an auswertende Systeme etc.) gegen Angriffe immunisiert werden. Dies f¨uhrt dazu, dass ein Angriff auch dann erkannt und gestoppt werden kann, wenn die ¨außere Verteidigungslinie versagt.⁶⁸

Ein Firmennetz ist i. d. R. so aufgebaut, dass jeder Mitarbeiter Zugang zu fast allen Infor-mationen hat. Nur die wenigen kritischen Bereiche, wie Gehaltslisten, Business-Continuity-Pl¨ane, Finanzbereich etc. bleiben dem gr¨oßten Teil der Belegschaft vorenthalten. In der Versicherungsbranche ist es beispielsweise ¨ublich, komplette Kunden- und Maklerkarteien

66DieMDATenth¨alt nicht nur Befunde und Diagnosen, sondern auch die sogenannten soziodemografischen Daten (u. a. Alter, Bildung, Lifestylefaktoren, Umweltdaten) und sonstige Begleitdaten (Archivierungsort, Daten des behandelnden Arztes etc.), die die unerw¨unschte Reidentifizierung erm¨oglichen bzw. vereinfachen k¨onnten (s. a. Glossar).

67Und folglich gegen¨uber gleichen Angriffen anf¨allig sind.

68So kann z. B. die Kompromittierung eines Systems von einem Anti-Rootkit erkannt werden, obwohl das

pauschal f¨ur alle Mitarbeiter freizugeben, da viele Gesch¨aftsprozesse auf der Verf¨ugbarkeit dieser Informationen aufbauen.

Ein Forschungsnetz ist mit einem ¨ublichen Unternehmensnetzwerk kaum vergleichbar.

Streng genommen existiert ¨uberhaupt kein dediziertes klar abgegrenztes Netz.⁶⁹ Die Teil-nehmer des Forschungsnetzes geh¨oren unterschiedlichen Organisationen an und k¨onnen unterschiedliche Ziele verfolgen. Die grunds¨atzliche Freigabe aller Ressourcen und die Sper-rung lediglich kritischer Bereiche (nach dem Vorbild eines ¨ublichen Unternehmensnetzes) sind auf ein Forschungsnetz nicht anwendbar. Aus diesem Grund kann die Freigabe von Ressourcen in einem medizinischen Forschungsnetz nur nach dem

”Need-to-know-Prinzip“

erfolgen.

Anders als bei einem Unternehmensnetz, in welchem es durch organisatorische und admi-nistrative Maßnahmen m¨oglich ist, die Infrastruktur einheitlich zu halten, ist es bei allen Teilnehmern des Forschungsnetzes nicht realistisch, von einer sicheren Umgebung auszuge-hen. Die Hard- und Softwareausstattung der Teilnehmer ist unterschiedlich. Restriktive Maßnahmen, die auf die Homogenisierung der Systemlandschaft abzielen, w¨urden lediglich zu einer verringerten Teilnehmerakzeptanz f¨uhren. Heterogene Umgebung erlaubt keine Sicherheitskonzepte, die auf der Integrit¨at teilnehmender Systeme aufbauen: Ein versierter Angreifer mit einem physikalischen Zugang zu einem solchen System w¨are trotzdem in der Lage, es zu manipulieren, um beispielsweise Patienten- oder Arztdaten auszusp¨ahen (s. a.

Abschnitt 3.5.1).

Es w¨are somit nicht ratsam, dem Client eine Menge von Daten zur Verf¨ugung zu stel-len und zu hoffen, dass die lokal auf dem Teilnehmersystem installierte Software die Filterungsfunktion zuverl¨assig ausf¨uhrt und dem Teilnehmer – basierend auf dem Zu-griffsberechtigungskonzept – nur die Daten liefert, in die er Einsicht nehmen darf. Auf der Client-Seite d¨urfen nur die Daten ankommen, deren Zul¨assigkeit f¨ur den Benutzer in der sicheren Serverumgebung ¨uberpr¨uft ist.⁷⁰ Eine webbasierte L¨osung ist f¨ur ein sol-ches Einsatzszenario pr¨adestiniert. Doch auch eine webbasierte L¨osung befreit nicht von der Notwendigkeit, die Authentizit¨at der Teilnehmer und die Integrit¨at der verwendeten Client-Software zu ¨uberpr¨ufen. Die Zurverf¨ugungstellung von Forschungsnetzdiensten in Form des f¨ur alle Internetteilnehmer verf¨ugbaren Webangebots wird nicht empfohlen. Es wurde bereits erl¨autert, wieso keine pauschale Annahme der absoluten Anonymit¨at von medizinischen Daten erfolgen kann, sodass man sich nicht nur auf die Anonymisierungs-bzw. Pseudonymisierungsmaßnahmen verlassen darf. Im Abschnitt 3.5.1

”Sichere Arbeits-umgebung“ wird die Verwendung einer virtualisierten Arbeitsumgebung vorgeschlagen.

Beim Zugriff auf die webbasierten Forschungsnetzdienste werden Daten zwischen der in der

69Abgesehen von einem relativ kleinen Administrationskern bzw. zentralen Diensten (s. a. Abschnitte 3.1 und 3.2).

70Desktop-Datenbanken, die zuerst die Tabelleninhalte in den Speicher laden und erst nachtr¨aglich die relevanten Eintr¨age ausfiltern, w¨aren in diesem Zusammenhang nicht empfehlenswert.

virtualisierten Umgebung laufenden Anwendung⁷¹ und dem Forschungsnetzserver ausge-tauscht. Da die Daten¨ubertragung i. d. R. ¨uber ein ¨offentliches Netz stattfindet, muss diese verschl¨usselt werden. Im Abschnitt C.3.2 werden einige Anbindungsm¨oglichkeiten f¨ur die externen Forschungsnetzteilnehmer auf ihre Praxistauglichkeit untersucht. Dabei werden Aspekte des Einsatzes von virtuellen privaten Netzen (VPN) und standleitungsbasierten An-bindungen betrachtet; auch die M¨oglichkeiten der Verwendung von PKI sowie die g¨angigen Standards und ihre Alternativen werden er¨ortert. F¨ur die Authentifizierung der Benutzer k¨onnen die im n¨achsten Abschnitt behandelten X.509v3-Zertifikate verwendet werden. Die Identit¨at eines Forschungsnetzteilnehmers kann dabei an ein Schl¨usselpaar gebunden und durch eine CA beglaubigt werden. Die Authentifizierung von Forschungsnetzteilnehmern wird im Abschnitt 3.5.3 er¨ortert.

3.5.6. Verzeichnisdienste (LDAP, OCSP)

Aufgrund der i. d. R. weiten r¨aumlichen Verteilung der Forschungsnetzteilnehmer bzw.

-systeme ist der manuelle Austausch von ¨offentlichen Schl¨usseln zwischen den Teilnehmern (sogenannte manuelle Public-Key-Verteilung) nicht praktikabel. Um die Zugeh¨origkeit eines

¨offentlichen Schl¨ussels zu einer Person festzustellen, verwendet man digitale Zertifikate, denn ein digitales Zertifikat bindet einen ¨offentlichen Schl¨ussel an den Schl¨usselinhaber.

Daf¨ur unterzeichnet eine anerkannte Beglaubigungsinstanz (Certification Authority (CA)) eine aus den identifizierenden Informationen des Schl¨usselinhabers und dem ¨offentlichen Schl¨ussel bestehende Nachricht. Es existieren mehrere Zertifikatformate; am verbreitets-ten ist X.509v3 (vgl. [HPFS02]). Ausf¨uhrliche Informationen zum Aufbau des X.509v3-Zertifikats befinden sich in [BP01]. X.509v3-Zertifikate sind flexibel bez¨uglich der Namens-formate und erm¨oglichen Identifizierung des Zertifikatsinhabers anhand von E-Mail-Adresse, Domainnamen, X.500-Verzeichnisnamen, IP-Adresse etc. Mehrere Parteien sind in eine PKI-Infrastruktur involviert:

• Die Certification Authority (CA) (Zertifizierungsstelle) ist f¨ur die Authentizit¨at der Teilnehmer verantwortlich. CA ¨uberpr¨uft die Identit¨at der Teilnehmer, vergibt, ver-waltet und widerruft die Zertifikate. Daf¨ur verteilt eine CA ihren eigenen ¨offentlichen Schl¨ussel in Form eines Zertifikats. Das Zertifikat wird entweder von einer anderen CA oder von der CA selbst unterschrieben. In solchen F¨allen spricht man von so-genannten self-signed Zertifikaten. Man unterscheidet zwischen zwei Formen von CAs: ¨offentliche und private. ¨Offentliche CAs bedienen einen breiten Benutzerkreis;

die privaten betreuen nur die Benutzer der eigenen Gemeinschaft. Eine CA umfasst nicht nur die Dienste, sondern auch Hard- und Softwarekomponenten sowie Personal, operative Prozeduren und Richtlinien.

• Die Registration Authority (RA) ubernimmt die verwaltungstechnischen Aufgaben¨ einer CA. RAs werden eingerichtet, um die administrative Last einer CA zu ¨

uberneh-71

men. So nehmen die RAs Registrierungsinformationen von Neuanmeldungen entgegen, generieren Schl¨ussel f¨ur Benutzer, verwalten und autorisieren Zertifikatswiderrufe und organisieren Verteilung und Zur¨ucknahme von SmartCards. Außerdem erf¨ullen die RAs durch die ¨Ubernahme der CA-Aufgaben eine Schutzfunktion, da sie lokal betrieben werden, und die CA daf¨ur in einer besonders sicheren Offline-Umgebung arbeiten kann.

• Der Zertifizierungsserver ist f¨ur die Herausgabe der Zertifikate zust¨andig. Der Zertifizierungsserver kombiniert den ¨offentlichen Schl¨ussel des Teilnehmers mit seinen identifizierenden Informationen und signiert die dadurch entstehende Zertifikats-struktur mit dem privaten CA-Schl¨ussel.

• DasZertifikatsverzeichnis ist eine zentrale Zertifikatverwaltungs- und -verteilungsstel-le. Verzeichnisse werden i. d. R. eingesetzt, um pers¨onliche Attributsinformationen samt Zertifikaten zu speichern. Dadurch werden Benutzerinformationen in eine ubersichtliche Form gebracht. Clients k¨¨ onnen auf die Zertifikatsverzeichnis-Inhalte mithilfe von Verzeichnisprotokollen (z. B. X.500 oder LDAP) zugreifen.

• Der Schl¨usselwiedergewinnungsserver bzw. Schl¨usselsicherungs- und -wiederherstel-lungsserver sichert die Schl¨ussel bei der Erzeugung und hilft sp¨ater, die verlorenen Schl¨ussel wiederherzustellen. Der Schl¨usselwiedergewinnungsserver ist notwendig angesichts der großen Teilnehmerzahl eines Forschungsnetzes und dem Bed¨urfnis, auf die Daten trotz des Verlusts der SmartCard oder der PIN zugreifen zu k¨onnen.

Schl¨ussel-Wiedergewinnung ¨ahnelt der Schl¨ussel-Hinterlegung bei einem Treuh¨ander.

Der maßgebliche Unterschied besteht darin, dass die Schl¨usselwiedergewinnung intern erfolgt und bei der Schl¨usselhinterlegung eine dritte Partei den Schl¨ussel zur Aufbewahrung erh¨alt.

• Die Verwaltungsprotokolle (z. B. Certificate Management Protocol (CMP)) werden f¨ur die PKI-interne Kommunikation eingesetzt. Sie unterst¨utzen Registrierung von Benutzern, helfen bei der Zertifizierung und Initialisierung. Die Verwaltungsprotokolle werden bei der Schl¨usselwiedergewinnung, -aktualisierung und -widerruf verwendet

• Die Verwaltungsprotokolle (z. B. Certificate Management Protocol (CMP)) werden f¨ur die PKI-interne Kommunikation eingesetzt. Sie unterst¨utzen Registrierung von Benutzern, helfen bei der Zertifizierung und Initialisierung. Die Verwaltungsprotokolle werden bei der Schl¨usselwiedergewinnung, -aktualisierung und -widerruf verwendet

Im Dokument Entwurf und Beschreibung wesentlicher Komponenten einer Sicherheitsarchitektur für medizinische Forschungsnetze (Seite 57-66)