Sicherheit in Computational Grids

Transkript

1 Sicherheit in Computational Grids Peter Seydel Seminar Grid-Computing, SS04 Prof. Dr. Fuhr Universität Duisburg-Essen Basierend auf den Artikeln A Security Architecture for Computational Grids von Ian Foster, Carl Kesselman, Gene Tsudik und Steven Tuecke und A National Scale Authentication Infrastructure von Randy Butler Von Welch, Douglas Engert, Ian Foster, Steven Tuecke, John Volmer und Carl Kesselman Sicherheit in Computational Grids 1

2 Inhaltsverzeichnis 0 Übersicht Einleitung Rahmenbedingungen Typische Schwierigkeiten Anforderungen an einen Sicherheitsmechanismus Grundlegende Sicherheitsfunktionen Entwicklung einer Sicherheitsarchitektur Eine Sicherheitspolitik Weitere Sicherheitsobjekte Vererbung und Delegation User-Proxy und Resource-Proxy Mapping GSI Eine Implementierung der Architektur GSI Grundlagen GSI Technik Das GSS-API Ablauf einer Grid-Session Weitere Sicherheitsmechanismen Kerberos DCE SSH / SSL CRISES Legion Abschließende Betrachtung...15 Sicherheit in Computational Grids 2

3 0 Übersicht Die folgenden Ausführungen zum Thema Sicherheit in Computational Grids gliedern sich in fünf Kapitel, die überwiegend aufeinander aufbauen: In Kapitel 1 wird ein Überblick darüber gegeben, welche Rahmenbedingungen man in einem modernen Grid vorfindet und welche speziellen Anforderungen daher an ein Sicherheitssystem für moderne Grids gestellt werden müssen. Es wird kurz auf einige typische Schwierigkeiten geschaut, die beim Erfüllen der Anforderungen auftreten. Zudem werden die grundlegenden Sicherheitsfunktionen beschrieben und gegeneinander abgegrenzt. Einige sich hieraus ergebene Forderungen werden dabei näher ausgeführt. Kapitel 2 beschäftigt sich mit der Entwicklung einer Sicherheitsarchitektur. Es wird kurz erläutert, was unter einer Sicherheitspolitik zu verstehen ist und einige wichtige Begriffe in Bezug auf Sicherheitssysteme werden eingeführt. Die Begriffe Vererbung und Delegation werden näher betrachtet und die Beziehung zwischen diesen beiden Prinzipen wird behandelt. Danach werden die beiden wichtigen Strukturen, der User-Proxy (als Session-Manager) und der Resource-Proxy (als Vertreter für eine Ressource) vorgestellt und ihre Funktionsweise beschrieben. Das Global-To-Local-Mapping wird als eine grundlegende Methode zum Umgang mit verteilten Ressourcen vorgestellt und es werden vier wichtige Protokolle, auf denen unser Sicherheitssystem beruhen soll, eingeführt. Das dritte Kapitel handelt von GSI, einer recht weit entwickelten Implementierung der in Kapitel 2 vorgestellten Architektur. Nach einem Überblick über GSI und seine Funktionsweise folgt eine genauere Betrachtung der Technologien, die innerhalb von GSI zum Einsatz kommen. Die GSS-API wird als eine Bibliothek von Highlevel-Sicherheitsmethoden vorgestellt, und ihre Lage in der Sicherheitshierarchie wird auf einer Abbildung gezeigt. Am Ende des Kapitels werden anhand einer Grafik der Ablauf einer Grid- Session und das Zusammenspiel der Sicherheitskomponenten verdeutlicht. Im vierten Kapitel werden fünf weitere häufig verwendete Sicherheitsarchitekturen vorgestellt. Es wird ein Überblick über Kerberos, DCE, SSL und SSH, Legion und CRISIS gegeben. Ihre Einsatzgebiete werden beschrieben, sowie Vor- und Nachteile durch ihren Einsatz in modernen Grids. Es wird deutlich gemacht, wieso GSI eine bessere und umfassendere Lösung für Sicherheit in Grids darstellt. Den Abschluss der Thematik Sicherheit in Computational Grids bildet das fünfte Kapitel. Hier werden noch einmal die wichtigsten Erkenntnisse in Bezug auf Sicherheitsarchitekturen zusammengefasst und vier Kernthesen formuliert. Sicherheit in Computational Grids 3

4 1 Einleitung 1.1 Rahmenbedingungen An Berechnungen, die über ein Grid ablaufen, können sehr viele Prozesse beteiligt sein. Allein innerhalb einer einzelnen Berechnung können es tausende Prozesse sein, die parallel zueinander in unterschiedlichen Komponenten ausgeführt werden. Diese enorm große Anzahl an separaten Abläufen während einer Grid- Session macht eine effiziente Sicherheitsarchitektur erforderlich. Diese muss in besonderem Maße Wert darauf legen, durch ihre Sicherheitsoperationen die Leistung des Grids nur so gering wie möglich zu beeinträchtigen. Eine weitere wichtige Eigenschaft eines Grids ist, dass die verschiedenen Komponenten sich häufig in heterogenen Umgebungen befinden. Damit ist zum einen gemeint, dass die Computerplattformen, auf denen die Ressourcen arbeiten, mit unterschiedlichen Betriebssystemen ausgestattet sind. Gängige Betriebssysteme sind unter anderem die Microsoft Windows 2000 Server Gruppe, Suse und Red Hat Linux, Unixware, Solaris und OS/400 von IBM. Zum anderen ist aber auch die Vielfalt der möglichen Komponenten gemeint. Dies sind z.b. Rechenmaschinen, Datenspeicher oder wissenschaftliche Geräte wie Teleskope oder Elektronenmikroskope, die über mehrere Länder verteilt sein können. In der Regel werden diese Ressourcen von einem lokalen Administrator verwaltet und durch ein eigenes, autonomes Sicherheitssystem geschützt. Dies ist ebenfalls eine wichtige Voraussetzung, unter der ein Sicherheitsmechanismus arbeiten muss. Eine globale Sicherheitsarchitektur muss so beschaffen sein, dass diese lokalen Sicherheitssysteme problemlos einbezogen werden können und ihre autonome Verwaltung erhalten bleibt. Ebenso ist es wichtig, dass nicht nur Offenheit für bereits existierende sondern auch für in Zukunft entwickelte Systeme besteht. 1.2 Typische Schwierigkeiten Zu den typischen Herausforderungen für eine Sicherheitsarchitektur zählt eine Grundeigenschaft des Grids: Die ständig wachsende und fallende Anzahl an Nutzern und Ressourcen. Es ist nicht vorhersehbar, wie viele Ressourcen zum Zeitpunkt einer Berechnung im Netz verfügbar sind und wie viele Ressourcen im Laufe einer Berechnung ins Grid hinzukommen oder vom Netz genommen werden. Ebenso verhält es sich mit der Benutzerzahl. Es ist ungewiss, wie viele Nutzer eine Komponente zur gleichen Zeit verwenden wollen und wie viele Anfragen eine Komponente zur gleichen Zeit bearbeiten kann. Ein weiteres nicht triviales Problem ist, dass die einzelnen Verbindungen zwischen Komponenten im Grid während einer Berechnung oft nicht persistent sind. Wegen der schwankenden Anzahl an verfügbaren Ressourcen sowie verschiedener Stufen, aus denen eine Berechnung bestehen kann, muss es möglich sein, Verbindungen während einer laufenden Berechnung auf- und abzubauen. Die Anzahl der möglichen bestehenden Verbindungen zur gleichen Zeit kann die Anzahl der an der Anwendung beteiligten Prozesse um ein Vielfaches übersteigen. Somit besteht die Gefahr, dass die Leistung des Grids stark beeinträchtigt wird, wenn bei jedem Verbindungsaufbau alle Sicherheitsoperationen, wie z.b. die Authentifizierung. erneut durchgeführt werden müssen. Zu den Hauptschwierigkeiten ist auch die lokale Administration auf Seite der Ressourcen zu zählen, die im vorherigen Abschnitt beschrieben wurde. Sicherheit in Computational Grids 4

5 1.3 Anforderungen an einen Sicherheitsmechanismus Eine Forderung von Seiten des Benutzers an einen Sicherheitsmechanismus ist, dass er selber so wenig wie möglich von den Sicherheitsoperationen mitbekommen und schon gar nicht von ihnen belästigt werden möchte. Daher sollte ein geeigneter Sicherheitsmechanismus das sog. single sign-on unterstützen. Das bedeutet, der Benutzer meldet sich zu Beginn seiner Berechnung einmalig am Grid an. Genauer gesagt meldet er sich in einer bestimmten Anwendung an, die dann ihrerseits das Grid verwendet. Im Laufe der Berechnung muss er dann kein weiteres Mal aufgefordert werden, sich erneut anzumelden und seinen Zugang zu bestätigen. Der Benutzer braucht die Berechnung nur einzuleiten und am Ende die Ergebnisse abzuholen. Alles Weitere, wie z.b. die Anforderung einer Ressource zur Laufzeit sowie die Authentifizierung wird vom System erledigt. Eine weitere Forderung ist, dass die Zugangs- und Log-in-Daten des Benutzers privat bleiben. Sensible Daten wie Passwörter oder Zugangsschlüssel sollten nicht über das Netz versendet werden. Gerade die Übertragung von Daten zwischen den einzelnen Komponenten über das Grid beherbergt das größte Sicherheitsrisiko innerhalb einer Berechnung. Besonders diese Verbindungen sind anfällig, von Dritten abgehört zu werden. Auf Seiten der Ressourcen sollten bei Einführung einer globalen Sicherheitsarchitektur keine Änderungen nötig sein. Lokale Sicherheitsmechanismen müssen ebenfalls ohne Modifikationen einbezogen werden können. Um den bereits angesprochenen Leistungsverlust auf Grund der sehr großen Menge von Prozessen zu vermeiden, sollte es möglich sein, diese zu gruppieren. Prozesse mit den gleichen Berechtigungen können zu Gruppen zusammengeschlossen werden. Könnten sich diese Prozesse gemeinsam als Gruppe an Ressourcen anmelden und mit anderen Gruppen oder Einzelprozessen kommunizieren, würden viele Sicherheitsoperationen wegfallen. So könnte eine Gruppe aus einhundert Prozessen bestehen und sich mit einer einzigen Sicherheitsoperation bei einer Grid-Komponente authentifizieren. Auf diese Weise wären neunundneunzig Authentifizierungs-Operationen eingespart. An diesem einfachen Beispiel wird ersichtlich, welches große Potential zur Performance-Wahrung in einem Gruppierungs-Mechanismus steckt Eine beinahe schon triviale Forderung an jede globale Sicherheitsarchitektur ist, dass es möglich sein muss, beliebige Implementierungs-Technologien verwenden zu können. Entwickler dürfen nicht darin eingeschränkt werden, welche Technologien sie benutzen weder bei der Implementierung der Architektur selbst noch bei der Entwicklung von Anwendungen, die innerhalb der Sicherheitsarchitektur arbeiten sollen. Dies würde gegen das Prinzip der Offenheit verstoßen und diese Architektur für Entwickler unattraktiv machen. 1.4 Grundlegende Sicherheitsfunktionen Es folgt eine Beschreibung der Basisfunktionen, auf denen alle Sicherheitsoperationen beruhen und die jeder umfassende Sicherheitsmechanismus beinhalten muss: Authentifizierung: Dies ist der Vorgang, innerhalb dessen ein Benutzer, eine Ressource oder ein anderer Teilnehmer seine Identität nachweist. Die Authentifizierung spielt eine zentrale Rolle, wenn es um Sicherheitsfragen geht. Eine zuverlässige Identifizierung des Kommunikationspartners ist Voraussetzung für alle weitere Kommunikation. Autorisierung: Datenschutz: Der Prozess der Autorisierung klärt, welche Rechte ein Teilnehmer besitzt eine Komponente zu verwenden. Hierbei geht es um die Privatsphäre von Daten, die über das Grid gesendet werden. Es ist wichtig, Dritten keine Möglichkeit zu geben, den Datenverkehr abzuhören und Sicherheit in Computational Grids 5

6 auszuwerten. Der Schutz von Daten gegen unberechtigten Zugriff und Einblick ist ebenfalls eine grundlegende Forderung an jeden Sicherheitsmechanismus. Datensicherheit: Im Gegensatz zum Datenschutz geht es bei der Datensicherheit um die Fehlerfreiheit von Daten. Es müssen Mechanismen existieren, die fehlerhafte Daten erkennen und ggf. korrigieren. Meist übernimmt diese Rolle das eingesetzte Übertragungsprotokoll. Zugriffskontrolle: Ähnlich wie bei der Autorisation klärt die Zugriffskontrolle die Rechte eines Nutzers oder Prozesses, auf Daten und Methoden verschiedener Grid-Komponenten zuzugreifen. 2 Entwicklung einer Sicherheitsarchitektur 2.1 Eine Sicherheitspolitik Die Definierung einer Sicherheitspolitik geht allen Entwicklungsphasen der Architektur voraus. Eine Sicherheitspolitik ist einfach ausgedrückt eine Ansammlung von Regeln. Diese Regeln bestimmen das Verhalten der Teilnehmer innerhalb einer Sicherheitsoperation sowie ihre Reaktionen auf Anfragen und Anforderungen. Eine Sicherheitspolitik definiert security subjects oder auch nur subjects. Ein subject in einer Sicherheitsoperation kann ein Benutzer sein oder auch ein Prozess, der von einem Benutzer ausgeht. Subjects sind die aktiven Teilnehmer einer Operation. Sie können Ressourcen anfordern und weitere Prozesse erzeugen, die wiederum den Status eines subjects annehmen können. Eine Sicherheitspolitik definiert security objects oder objects. Im Gegensatz zu subjects nehmen objects keine aktive Rolle ein. Ressourcen, die verwendet werden, sowie Prozesse, die selbst keine Aktionen ausführen und lediglich ein Ergebnis an den Aufrufer zurückliefern, sind objects. Eine Sicherheitspolitik definiert Verbindungen und Beziehungen zwischen subjects und objects. Verbindungsaufbau und -abbau werden dabei lediglich von den subjects eingeleitet. 2.2 Weitere Sicherheitsobjekte trust domain: Unter einer domain versteht man in diesem Fall eine Menge von geographisch verteilten Grid-Komponenten oder verschiedenen logischen Komponenten auf demselben Host, die zu einer Gruppe zusammengeschlossen sind. Wie der Name trust domain schon andeutet, vertrauen die einzelnen Komponenten innerhalb einer solchen Gruppe sich gegenseitig in Sicherheitsangelegenheiten. Man kann sich eine trust domain als eine Kuppel vorstellen, welche die Gruppe überspannt. Innerhalb der Kuppel gibt es keine Barrieren bzw. Sicherheitsschanken. Nach außen hin verhält sich diese Gruppe auf Anfragen wie eine Einheit. credentials: Hierbei handelt es sich um Identitätsnachweise. Credentials können Passwörter oder Authentifizierungs-Schlüssel sein. Meistens handelt es sich allerdings um Zertifikate. Viele heutige Sicher-heitsstandards im Internet beruhen auf X.509-Zertifikaten. Diese sind mit Ausweisen wie einem Führerschein, Reisepass oder Mitgliedsausweis vergleichbar. Sicherheit in Computational Grids 6

7 Ein X.509-Softwarzertifikat kann folgenden Aufbau haben: Name des Inhabers Adresse des Inhabers Adresse, unter der die aktuelle Zertifikatsgültigkeit geprüft werden kann Max Mustermann ldap://trustcenter.generali.at/o=generali,c=at?certificaterevocationlist% 3Bbinary Art des Zertifikats Aussteller ou=light Zertifikat o=generali,c=at Seriennummer des Zertifikats Gültig ab Gültig bis Öffentlicher Schlüssel Abbildung BEGIN CERTIFICATE----- MIIEmDCCBAGgAwIBAgIENvZygTA NBgkqhkiG9w0BAQUFADBUMQswCQ YDVQQGEwJB -----END CERTIFICATE----- Im Zertifikat sind der öffentliche Schlüssel des Zertifikatbesitzers, sowie dessen Name, dessen Adresse, die ausstellende Beglaubigungsstelle, der Gültigkeitszeitraum und das Verfahren, nach dem das Zertifikat erstellt wurde, festgehalten. Mit X.509-Zertifikaten kann man auf den gesicherten Bereich einer Web-Seite zugreifen oder s elektronisch unterzeichnen und/oder verschlüsseln. Quelle: Vererbung und Delegation Die Vererbung von Rechten und Privilegien ist das wichtigste Prinzip, trotz der großen Menge an aktiven Prozessen und Komponenten innerhalb einer Grid-Session die Performance-Einbuße und die Menge an nötigen Sicherheitsoperationen gering zu halten. Von Vererbung spricht man, wenn der Benutzer einem Prozess, den er startet, einen Teil seiner Rechte abgibt. In der Regel sind das gerade so viele Rechte, wie der Prozess zur Ausführung seiner Aufgaben benötigt. Dies können z.b. Berechtigungen sein, bestimmte Ressourcen im Namen des Benutzers anzufordern oder weitere Prozesse an andere Stelle (z.b. auf Seiten einer Ressource) zu starten. Neben dem Benutzer können auch Prozesse einen Teil ihrer eigenen Rechte an andere Prozesse weitergeben. Dadurch wird beispielsweise verhindert wird, dass eine Anfrage von einer Ressource an den Benutzer gestellt werden muss, um die Rechte eines Prozesses abzufragen, der diese Ressource anfordern möchte. Durch das Vererbungsprinzip entsteht eine Hierarchie mit dem Benutzer selbst als Ursprung. Prozesse, die vom Benutzer erzeugt wurden, befinden sich auf der nächst höheren Ebene und verfügen über einen Teil der Benutzerrechte. Prozesse, die von anderen Prozessen erzeugt werden, befinden sich jeweils eine Hierarchie-Ebene höher und sind in der Regel mit weniger Rechten als ihr Erzeuger ausgestattet. Dadurch ergibt sich eine Art Eltern-Kinder -Beziehung. Prozesse können in Ebenen oder Generationen aufgeteilt werden und es ergeben sich Gruppen mit gemeinsamen Berechtigungen. Die Delegation kann als Erweiterung der Vererbung angesehen werden. Während bei der Vererbung lediglich Rechte weitergegeben werden, kommen bei der Delegation auch Pflichten bzw. Aufgaben hinzu. Somit kann der Benutzer an einen Prozess oder ein Prozess an einen von ihm erzeugten Prozess bestimmte Aufgaben übergeben. Das führt zu einer Entlastung für den Benutzer oder den Mutterprozess und kann dabei helfen Engpässe, sog. Bottlenecks, zu vermeiden, indem ein Teil der Sicherheits- Sicherheit in Computational Grids 7

8 operationen von einem untergeordneten Prozess übernommen werden. Dieser kann natürlich auf einer anderen Maschine oder gar an einem anderen Ort ausgeführt werden. 2.4 User-Proxy und Resource-Proxy Der User-Proxy ist ein Session-Manager-Prozess. Beim Einloggen in das Grid erzeugt der Benutzer einen User-Proxy. Dieser besitzt alle Rechte des Benutzers und übernimmt im Laufe einer Berechnung alle seine Aufgaben. Man könnte es so ausdrücken, dass der User-Proxy den Benutzer innerhalb aller zukünftigen Sicherheitsoperationen vertritt. Somit ist es nicht notwendig, dass der Benutzer selber, der Mensch, an seinem Rechner oder Terminal bleiben muss, solange die Berechnung läuft, um Sicherheitsanfragen zu beantworten. Durch diese Methode wird der Forderung nach dem single sign-on (siehe Kapitel 1.5) Folge geleistet. Die Lebenszeit des User-Proxys ist an die Dauer einer Berechnung bzw. Grid-Session gebunden. Beim ersten Einloggen in das Grid wird er erzeugt und besteht solange, bis die gesamte Berechnung abgeschlossen ist. Da er sämtliche Rechte und credentials des Benutzers besitzt, braucht sich dieser nach dem Start der Session nicht weiter um den Ablauf zu kümmern. Der Resource-Proxy ist das Interface einer Ressource zum Grid. Ähnlich wie der User-Proxy übernimmt der Resource-Proxy Sicherheitsaufgaben für seinen Erzeuger. Er ist die Schnittstelle zwischen den globalen Sicherheitsoperationen und den internen lokalen Sicherheitsmechanismen. Versucht ein Benutzer oder ein Prozess eine Verbindung zu einer Ressource aufzubauen, dient der Resource-Proxy als Anprechpartner. Anfragen, wie Anforderungen oder der Wunsch einen Prozess auf Ressourcen-Seite zu starten, werden vom Resource-Proxy an die lokalen Sicherheitsmechanismen weitergeleitet. Dadurch wird verhindert, dass von außen eine direkte Verbindung mit internen Mechanismen aufgebaut werden kann. Das würde zum einen zu Sicherheitslücken führen und zum anderen die Überwachung der Einhaltung sowie die Durchsetzung der lokalen Sicherheitspolitk erschweren. 2.5 Mapping Über das Global-To-Local-Mapping wird der Zugriff auf globale Ressourcen ermöglicht. Ressourcen, die sich an geographisch weit entfernten Orten befinden, können verwendet werden, als wären sie lokal verfügbar und würden sich direkt im örtlichen System befinden. Über einen Mapping-Table werden globale in lokale Namen umgewandelt, bzw. umgekehrt. Jede Komponente in einem Grid besitzt einen globalen Namen, unter dem sie ansprechbar ist. Ebenso besteht jede Komponente, die von außen wie eine Einheit wirkt, in Wirklichkeit meist aus vielen Teilkomponenten, die jede für sich ebenfalls interne Bezeichnungen besitzen. Einen Benutzer oder Prozess, der z.b. einen Speichercluster verwenden möchte, interessiert es im Allgemeinen nicht, auf welcher lokalen Speichermaschine seine Daten gesichert werden (oft werden die Daten auch auf freie Speicherräume in verschiedenen Maschinen aufgeteilt). Der Benutzer/Prozess sieht nur den globalen Namen der Ressource. Das Global-To-Local-Mapping ersetzt bei Anfragen die globalen Bezeichnungen mittels eines Mapping-Tables durch interne und leitet dann die Anfragen weiter. In einfachen Fällen handelt es sich bei einem Mapping-Table um eine zweispaltige Tabelle: In einer Spalte stehen die globalen Namen und ihnen gegenüber in der zweiten Spalte die internen Bezeichnungen. Ausgehende Daten werden während des Vorgangs des Global-To-Local-Mappings mit credentials der Ressource versehen, womit die Daten eindeutig als echt identifiziert werden können. Sicherheit in Computational Grids 8

9 3 GSI Eine Implementierung der Architektur 3.1 GSI Grundlagen Die Abkürzung GSI steht für Global Security Infrastructur. GSI wurde als Teil des Globus-Projekts ( entwickelt und stellt die Standardsicherheitslösung der Globusstruktur dar. GSI verwendet ausschließlich Public-Key-Verfahren zur Datenverschlüsselung, die im Vergleich zu Shared- Key-Verfahren erhöhte Sicherheit bieten. Shared-Key-Verschlüsselungen kommen heute allerdings noch immer in vielen Sicherheitsmechanismen zum Einsatz. Dadurch, dass der Dechiffrierungs-Schlüssel bei der Public-Key-Methode nur dem Empfänger bekannt ist, besteht eine wesentlich geringere Gefahr, dass der Schlüssel in falsche Hände fallen könnte. Beim Shared-Key-Verfahren müssen hingegen sowohl Sender als auch Empfänger über den gleichen Schlüssel verfügen. Dieser Umstand erhöht die Gefahr eines Diebstahls des Schlüssels. Schon heute hat GSI eine so große Akzeptanz, wie sie nur wenige andere Sicherheitsimplementierungen besitzen und wird es bereits in zahlreichen Supercomputer- und Datenspeicher-Systemen eingesetzt. GSI bringt eigene Versionen von FTP und Remote-Log-in mit. Es stellt Entwicklern von Sicherheitsanwendungen das GSS-API als Programmiererschnittstelle zur Verfügung (siehe Kapitel 3.3 Das GSS- API). 3.2 GSI Technik GSI verwendet X.509-Zertifikate als private Schlüssel zum Identitätsnachweis von security-objects. (Für genauere Informationen über die Zertifikate und einen Beispielaufbau siehe Kapitel 2.2 Weitere Sicherheitsobjekte.) Der Authentifizierungsalgorithmus verwendet das SSLv3-Protokoll bzw. die freie Version von SSLv3, SSLeay, zur Kontrolle der Identitäten (siehe Kapitel 4.3 SSL/SSH). Das Mapping geschieht bei GSI über einfache Mapping-Tables, mit deren Hilfe globale in lokale Namen umgesetzt werden (siehe Kapitel 2.5). Gemäß der im Kapitel 2 beschriebenen Architektur und den Anforderungen für einen Sicherheitsmechanismus, bietet GSI die Möglichkeit Berechtigungen zu vererben. Aufgaben können, wie im Prinzip der Delegation gefordert, an untergeordnete subjects (Prozesse) vergeben werden. Ebenso wird durch GSI die Bedingung der Lokalen Autonomie erfüllt. Das heißt, auf Seiten der Ressourcen können eigene, lokale Sicherheitsmechanismen Verwendung finden und müssen dem globalen Sicherheitssystem nicht extra angepasst werden. Diese Funktion wurde ursprünglich mit Hilfe einer Access-Control-List verwirklicht. Abbildung 3-1 zeigt das Beispiel einer einfachen Access-Control-List. Abbildung 3-1 Sicherheit in Computational Grids 9

10 3.3 Das GSS-API Das Kürzel GSS steht für Generic Security Service und ist ebenfalls Teil des Globus-Toolkits und von GSI. Es bietet Entwicklern standardisierte Sicherheitsfunktionen wie z.b. Authentifizierung oder Delegation. Beim GSS-API handelt es sich um eine Bibliothek mit Highlevel-Sicherheitsfunktionen, die Entwicklern bereits fertig zur Verfügung gestellt werden. Programmierer können beim Implementieren von Sicherheitsanwendungen auf diese vorgefertigten Methoden zurückgreifen und sie unkompliziert in ihre Programme integrieren. Dies spart nicht nur Zeit während der Entwicklungsphase sondern stellt darüber hinaus auch eine gewisse Standardisierung sicher. Das GSS-API ist transport- und mechanism-independend. Transport-Independence bedeutet, dass GSS nicht vorschreibt, welche Kommunikationsprotokolle und -bibliotheken verwendet werden müssen. Es produziert während des Betriebs Sequenzen von sog. Tokens. Mit welcher Methode diese über das Netz transportiert werden, bleibt dem Entwickler überlassen. GSI verwendet in der aktuellen Version TCP-Sockets und die Nexus- Kommunikationsbibliothek. Mechanism-Independence bedeutet, dass GSI keine speziellen Sicherheitsprotokolle wie z.b. RSA Kerberos, DCE oder andere (siehe Kapitel 4 Weitere Sicherheitsmechanismen) erfordert und überlässt auch hier dem Entwickler selbst die Wahl. Es gibt vier grundlegende Protokolle zur Umsetzung der in Kapitel 2 vorgestellten Architektur: Protocoll 1 ist für den Log-in eines Benutzers ins Grid. Das ist gleichbedeutend mit der Erzeugung eines User-Proxys, der die Aufgaben des Benutzers im Ablauf einer Grid-Session übernimmt. Protocoll 2 dient der Ressourcenanforderung durch den Benutzer. Protocoll 3 dient ebenfalls zur Anforderung von Ressourcen; in diesem Fall allerdings durch einen Prozess, der als subject handelt. Protocoll 4 steuert das Global-To-Local-Mapping. Abbildung 3-2: Die Lage des GSS-API in der Security-Hierarchie Sicherheit in Computational Grids 10

11 3.4 Ablauf einer Grid-Session Abbildung 3-3 Abbildung 3-3 zeigt die Basisoperationen, die von GSI unterstützt werden. Folgt man der schwarzen Linie, die vom Benutzer in der oberen linken Ecke ausgeht, sieht man zuerst die Benutzerauthentifizierung mittels des Public-Key-Verfahrens und unter Verwendung der Benutzer-Credentials (C U). Dann wird der User- Proxy erzeugt, der über die Rechte des Benutzers verfügt und diese als sog. User-Proxy-Credentials (C UP) besitzt. Der User-Proxy kann nun selbstständig Ressourcen anfordern, die ihrerseits durch ihren Resource-Proxy repräsentiert werden. Dieser enthält selbst die Resource-Credentials (C R) die Berechtigungen und Identitätsnachweise der Ressource. Nach der Autorisierung wird nun ein Prozess auf Seiten der Ressource gestartet, der seine eigenen credentials (C P) erhält, die aus Teilen der Rechte des User-Proxys und des Ressource-Proxys bestehen. Darüber hinaus ist auf der Grafik zu erkennen, wie der Prozess auf Site 2 aufgrund seiner Rechte eine weitere Ressource anfordern kann und dort ebenfalls ein Prozess gestartet wird. Dieser besitzt wiederum seine eigene Rechte, die ihm von seinem Erzeuger vererbt wurden. Sicherheit in Computational Grids 11

12 4 Weitere Sicherheitsmechanismen 4.1 Kerberos Kerberos ist ein Netzwerk-Authentifizierungsprotokoll und wurde von der MIT-Gruppe entwickelt. Es wird seit Mitte der achtziger Jahre weit verbreitet eingesetzt und hat sich seitdem ständig weiterentwickelt. Kerberos verwendet hochwertige Krypthographie zur Verschlüsselung der Daten. Allerdings beruhen alle bisher verfügbaren Implementierungen auf dem Shared-Key-Prinzip. Die Verwendung von Public-Key- Verschlüsselungen ist nur über Extensions möglich. Ebenso ist die geforderte Funktion single sign-on in der Basisversion von Kerberos nicht vorhanden und bis heute auch nicht implementiert. Kerberos ist eine Client-Server-Architektur. Genauer gesagt ist es ein Werkzeug zur Sicherung der Identität von Clients und Servern. Dazu benötigt Kerberos während des Betriebs immer einen Sicherheitsserver, einen sicheren Host, der die Identitätskontrolle übernimmt. Diesem müssen alle Passwörter und Zugänge von Client und Server bekannt sein. Eine Peer-to-Peer-Architektur wurde für Kerberos zwar entwickelt, aber auch hier gibt es keine aktuell verfügbare Implementierung. Ein weiterer Nachteil ist von Kerberos ist, dass es nicht kompatibel mit lokalen Systemen ist. Es bietet zudem nur unzureichende Möglichkeiten autonome Sicherheitsmechanismen auf Seite von Client oder Server einzubinden. Für genauere Informationen über die Arbeitsweise von Kerberos und anderen Sicherheitssystemen, die auf einem sog. Ticket-System arbeiten, gibt es einen sehr guten Artikel. Dieser stellt den Dialog zweier Entwickler dar, die Kerberos life entwickeln. ( Ablauf des Verbindungsaufbaus eines Clients mit einem Server: Zunächst schickt der Client eine Anfrage an den Sicherheitsserver, dass er Verbindung mit einem Server aufnehmen möchte (1). Der Sicherheitsserver überprüft die Identität des Clients und ob dieser berechtigt ist, mit dem Wunschserver Kontakt aufzunehmen. Er sendet ihm ggf. ein sog. Ticket zu (2). Dieses Ticket schickt der Client an den Server, zu dem er Kontakt haben möchte, woraufhin der Server die Gültigkeit des Tickets überprüft (3). War dieser Vorgang erfolgreich, kann der Client die eigentlichen Anfragen stellen und seine Arbeit aufnehmen (4). Abbildung 4-4.1: Kerberos-Funktionsweise Sicherheit in Computational Grids 12

13 4.2 DCE DCE steht für Distributed Computing Environment und wird von der OpenGroup entwickelt ( Es ist eine Ableitung und Weiterentwicklung von Kerberos und arbeitet grundsätzlich mit der gleichen Architektur. Sehr viele Aspekte von Kerberos sind auch in DCE zu finden. Bei der Verwendung von DCE ist es ebenfalls erforderlich, dass in jeder Domain ständig ein Sicherheitsserver (Trusted Third Party) verfügbar ist. Der Authentifizierungsmechanismus von DCE ist weiter entwickelt als der von Kerberos selbst. Zudem bringt DCE eigene Versionen eines Time-Service, Name-Service und File-Service mit. Das ist einerseits ein Vorteil, weil dadurch ein vollständiges System angeboten werden kann. Andererseits kann es für Entwickler aber auch ein gravierender Nachteil sein, da es sehr schwierig ist, nur bestimmte Teile der gesamten Funktionen zu verwenden. Wie Kerberos arbeitet DCE im Shared-Key-Verfahren. Es sind zwar auch Implementationen verfügbar, die das primäre Log-in als Public-Key-Verfahren unterstützen, allerdings ist DCE genau wie Kerberos dort nicht einsetzbar, wo Public-Key-Verschlüsselung explizit gefordert ist. 4.3 SSH / SSL SSH wurde hauptsächlich als Lösung für Remote-Log-in, File-Transfer und Remote-Execution (das Aufrufen von Methoden und Programmen auf entfernten Rechnern) entwickelt. Es handelt es sich dabei um eine Alles-oder-Nichts -Lösung. Wird SSH als Sicherheitslösung verwendet, ist es nicht möglich andere Sicherheitsmechanismen einzubeziehen; lokale und autonom verwaltete Sicherheitsmechanismen können nicht verwendet werden. Ein weiterer Nachteil von SSH ist, dass es im Massen-Verschlüsselungs- Verfahren arbeitet (bulk encryption). Das bedeutet, sämtlicher Datenverkehr wird verschlüsselt, wodurch große Einbußen in der Übertragungsleistung entstehen. Vor allem Sender und Empfänger, die den kompletten Datenstrom verschlüsseln und entschlüsseln müssen, werden stark belastet. Ein Problem für Entwickler ist es, dass SSH keine ausreichende Programmiererschnittstelle bietet. Es ist deswegen z.b. sehr kompliziert, Kommunikations- und Sicherheitsdienste separat zu benutzen. SSL ist das Standard-Kommunikationspaket von Netscape. Es wird hauptsächlich zur Sicherung von Verbindungen auf HTTP-Basis im Web verwendet und ist in diesem Bereich stark verbreitet. SSL arbeitet mit stream-orientierter Datenübertragung und benutzt Low-Level-Verbindungsprotokolle wie z.b. TCP. Nachdem eine sichere Authentifizierung stattgefunden hat, verfügt SSL im Gegensatz zu SSH auch über die Möglichkeit von unverschlüsseltem Datenverkehr. Hierdurch kommt es zu erheblich weniger Leistungseinbuße während der Kommunikation und Datenübertragung. Sowohl SSL als auch SSH sind für eine Client-Server Architektur ausgelegt. Bei beiden Mechanismen wird eine sichere Ende-zu-Ende -Verbingung aufgebaut. Allerdings beinhalten weder SSL noch SSH Verfahren zur Autorisierung, ebenso werden Vererbung und Delegation von beiden Mechanismen nicht unterstützt. SSH und SSL arbeiten in allen Belangen streng nach dem Public-Key-Verfahren und bieten somit einen hohen Sicherheitsstandard. 4.4 CRISES CRISIS ist das Standardsicherheitssystem von Web-OS. Web-OS ist ein Betriebssystem, das speziell für den Einsatz in Wide-Area-Netzwerken entwickelt wurde und es findet dort durchaus Verbreitung. Es hat grundsätzlich ähnliche Ziele wie das Globus-Projekt: Nahtlosen Zugriff auf Rechner und Dateien in einem Sicherheit in Computational Grids 13

14 geographisch weit verteilten Netzwerk. Ebenso wie GSI verwendet CRISIS das SSL-Protokoll, um Punktzu-Punkt -Verbindungen herzustellen und benutzt X.509-Zertifikate zur Authentifizierung. CRISIS unterstützt zwar lokale, autonome Sicherheitspolitiken, bietet aber keine Möglichkeiten andere Sicherheitsmechanismen mit einzubeziehen. Das bedeutet, der Administrator einer Ressource kann zwar die Regeln, mit denen er sein lokales System schützt, selbst festlegen; es ist ihm jedoch nicht möglich eigene Sicherheitsmechanismen zu verwenden. Er ist auf das Funktionsangebot von CRISIS angewiesen.. Die CRISIS-Architektur bietet sowohl Lösungen zur Authentifizierung als auch für die Zugriffskontrolle und sie unterstützt das Speichern und Weitergeben von Credentials. Allerdings ist es nicht möglich Prozesse als eigenständige subjects zu behandeln und sie können nicht selbstständig weitere Ressourcen anfordern bzw. Prozesse auf entfernten Systemen erzeugen. Insgesamt kann man sagen, dass CRISIS eine web-orientierte Architektur ist und unter diesen Voraussetzungen entwickelt wurde. Daher eignet sich CRISIS nur bedingt zum Einsatz in Computational Grids. 4.5 Legion Ebenso wie CRISIS verfolgt auch Legion ähnliche Ziele wie das Globus-Projekt. Legion ist besonders für den Einsatz mit objektorientierten Softwaretechnologien entwickelt worden. Gerade die Modularität von objektorientierten Systemen eignet sich dazu, autonome Sicherheitssysteme einzubeziehen. An objects (z.b. Dateien) befinden sich sog. Hooks. Es ist möglich, an diesen Haken Sicherheitsdienste oder Credentials wie Passwörter oder Zertifikate zu befestigen. Dadurch kann jedes Objekt, das über das Grid versendet wird, seine eigenen Berechtigungsnachweise mitbringen. Es ist nicht notwendig, zuerst eine gesicherte Verbindung aufzubauen, wodurch keine explizite Authentifizierungsoperation stattfinden muss. Legion ist ein High-Level-Sicherheitsmodell. Es existiert keine bestimmte Architektur oder Implementierung. Ebenso gibt es keine fertigen Protokolle oder Bibliotheken mit vorgefertigten Methoden für den Einsatz bei der Entwicklung von Sicherheitsanwendungen. Mit dem Globus-Toolkit ist es allerdings möglich, das Legion-Modell ohne größere Schwierigkeiten zu implementieren und zum Einsatz zu bringen. Sicherheit in Computational Grids 14

15 5 Abschließende Betrachtung Die Hauptaufgabe einer Sicherheitsarchitektur besteht aus zwei Bereichen: Authentifizierung zum Identitätsnachweis und sichere Datenübertragung im Sinne eines Schutzes vor unbefugtem Zugriff auf Daten und Ressourcen. Gerade der dynamische Auf- und Abbau von Verbindungen zur Laufzeit gibt der Authentifizierung eine zentrale Rolle. Hierbei ist es wichtig, eine effiziente Lösung zu entwickeln, mit der man die große Anzahl an parallel ablaufenden und zur Laufzeit generierten Prozessen bewältigen kann. Auch die Verwaltung von dynamischen Ressourcenanforderungen während einer Grid-Session benötigt eine angemessene Strategie. Es besteht ein aktiver Trade-Off zwischen Sicherheit und Performance. Je mehr Sicherheitsverfahren wie Authentifizierungsoperationen oder Datenverschlüsselungen in den Betrieb des Grids einbezogen werden, desto stärker wird die Leistung des gesamten Grids reduziert. Daher muss abgewogen werden, wie viel Sicherheit notwendig ist. Es gilt das allgemein bekannte Prinzip: So wenig wie möglich aber so viel wie nötig. Entwicklern von Anwendungen müssen ausreichend Möglichkeiten gegeben werden, selbst bestimmen zu können, ob und wie sehr sie Sicherheitsmechanismen und -operationen in ihre Programme einbeziehen wollen. Dazu brauchen sie die Freiheit, lokale Sicherheitsmechanismen, eigene Sicherheitspolitiken und bestehende Sicherheitslösungen innerhalb einer globalen Architektur verwenden zu dürfen. Diese müssen einfach eingebunden werden können. Entwickler dürfen nicht zu stark auf ein bestimmtes Sicherheitssystem festgelegt werden, das ihnen zu wenige Möglichkeiten der Skalierung und Anpassung an ihre speziellen Zwecke bietet. Da die Entwicklung im Bereich von Verteilten Systemen und insbesondere Computational Grids sehr rasch voranschreitet, ist es entscheidend, dass eine Sicherheitsarchitektur mit der ständig wachsenden Anzahl verschiedenster Anwendungen und lokaler Sicherheitsmechanismen zurechtkommt. Sie muss genug Spielraum für Erweiterungen lassen. Genauso stellt die große Zahl unterschiedlicher Ressourcen, vom Massenspeicher bis zum Superteleskop, ihre eigenen Anforderungen an Sicherheitsmechanismen. Grundlegend verschiedene Arten von Grid-Komponenten benötigen jeweils spezielle Sicherheitspolitiken. Die Daten, die sie liefern und über das Netz versenden, können darüber hinaus von unterschiedlicher Sensibilität sein. Das setzt eine angemessene Skalierbarkeit des Sicherheitsmechanismus voraus. Sicherheit in Computational Grids 15