DE112012002741T5

DE112012002741T5 - Identitäts- und Berechtigungsprüfungsverfahren für die Sicherheit einer Cloud-Datenverarbeitungsplattform

Info

Publication number: DE112012002741T5
Application number: DE112012002741.8T
Authority: DE
Inventors: David Yu Chang; John Yow-Chun Chang; Messaoud Benantar; Vishwanath Venkataramappa
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-06-30
Filing date: 2012-06-26
Publication date: 2014-03-13
Also published as: US20130007845A1; CN103563294A; US8769622B2; WO2013000080A1; GB2506564B; GB201401348D0; GB2506564A; US9288214B2; US20150007274A1; CN103563294B

Abstract

Ein Plug-In-Modell zur Identitäts- und Berechtigungsprüfung für eine Cloud-Datenverarbeitungsumgebung ermöglicht Cloud-Kunden, die Kontrolle über ihre Unternehmensdaten zu behalten, wenn ihre Anwendungen in der Cloud bereitgestellt werden. Der Cloud-Dienstanbieter stellt eine einbindbare Schnittstelle für Kundensicherheitsmodule bereit. Wenn ein Kunde eine Anwendung bereitstellt, ordnet der Cloud-Umgebungsadministrator der Anwendung und den Daten des Kunden eine Ressourcengruppe zu (z. B. Prozessoren, Speicher und Arbeitsspeicher). Der Kunde registriert sein eigenes Sicherheitsmodul zur Identitäts- und Berechtigungsprüfung bei dem Cloud-Sicherheitsdienst, und anhand dieses Sicherheitsmoduls wird dann kontrolliert, welche Personen oder Einheiten auf Daten zugreifen können, die der bereitgestellten Anwendung zugehörig sind. Der Cloud-Umgebungsadministrator ist jedoch typischerweise nicht (als zugelassener Benutzer) bei dem Sicherheitsmodul des Kunden registriert; somit ist der Cloud-Umgebungsadministrator nicht in der Lage, auf die dem Cloud-Kunden zugewiesenen Ressourcen (obwohl er diese Ressourcen selbst zugewiesen hat) oder die zugehörigen Geschäftsdaten zuzugreifen (bzw. sie für andere oder für den allgemeinen Ressourcen-Pool der Cloud freizugeben). Um die Rechte der verschiedenen Parteien des Weiteren auszutarieren, schützt ein Drittanbieter-Notardienst die Vertraulichkeit und das Zugriffsrecht des Kunden, wenn seine Anwendung und seine Daten in der Cloud bereitgestellt werden.

Description

HINTERGRUND DER ERFINDUNG
Technisches Gebiet
Diese Offenbarung bezieht sich im Allgemeinen auf das Sicherstellen von Unversehrtheit, Vertraulichkeit und Schutz von Geschäftsdaten in einer Umgebung, in der Ressourcen in einem gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen bereitgestellt werden.
Hintergrund der verwandten Technik
Eine Benutzeridentitätsprüfung ist eine Funktion, die Dienstanbieter bereitstellen, um sicherzustellen, dass Benutzer, die auf Ressourcen zugreifen (z. B. Anwendungen, Web-Inhalte usw.) über eine entsprechende Berechtigung verfügen. Um sicherzustellen, dass ein Benutzer kein Betrüger ist, fragen Dienstanbieter (z. B. Web-Server) im Allgemeinen nach Benutzernamen und Kennwort eines Benutzers, um die Identität zu überprüfen, bevor sie den Zugriff auf Ressourcen zulassen. Single Sign-On (SSO, Einmalanwendung) ist ein Zugriffskontrollmechanismus, der es einem Benutzer ermöglicht, einmalig seine Identität nachzuweisen (indem er z. B. einen Benutzernamen und ein Kennwort bereitstellt) und dann Zugriff auf Software-Ressourcen zu erhalten, die auf mehrere Systeme verteilt sind. Üblicherweise gestattet ein SSO-System den Benutzerzugriff auf Ressourcen innerhalb eines Unternehmens oder einer Organisation. Federated Single Sign-on (F-SSO) erweitert das Konzept des Single Sign-On auf mehrere Unternehmen und stellt dadurch Partnerschaften zwischen verschiedenen Organisationen und Unternehmen her. F-SSO-Systeme beinhalten üblicherweise auf Anwendungsebene angesiedelte Protokolle, mit denen ein Unternehmen (z. B. ein Identitätsanbieter) einem anderen Unternehmen (z. B. einem Dienstanbieter) die Identität und andere Attribute eines Benutzers bereitstellen kann.
Ein neu aufkommendes IT-Bereitstellungsmodell ist die Cloud-Datenverarbeitung, bei der gemeinsam genutzte Ressourcen, Software und Daten über das Internet anderen Computern und Einheiten nach Bedarf bereitgestellt werden. Die Cloud-Datenverarbeitung kann Kosten und Komplexität der Informationstechnologie erheblich senken und gleichzeitig die Auslastungsoptimierung und Dienstbereitstellung verbessern. Bei dieser Herangehensweise kann eine Anwendungsinstanz von Ressourcen auf der Grundlage des Internets bereitgestellt und verfügbar gemacht werden, auf die über einen herkömmlichen Web-Browser mittels HTTP zugegriffen werden kann.
Obwohl die Cloud-Datenverarbeitung zahlreiche Vorteile bereitstellt, ist die Datensicherheit ein erhebliches Problem. Insbesondere Unternehmen, die ihre Unternehmensanwendungen innerhalb einer Cloud-Umgebung bereitstellen wollen, unterhalten und verwalten oft kritische Geschäftsdaten in Zusammenhang mit derartigen Anwendungen. Wenn diese Anwendungen in der Cloud bereitgestellt werden, sind diese kritischen Geschäftsdaten gegenüber dem Cloud-Datenverarbeitungs-Dienstanbieter zwangsläufig offengelegt. Folglich sind diese Geschäftsdaten einem Risiko ausgesetzt, da eine Cloud-Datenverarbeitungsumgebung die Daten ihrem Wesen nach der Verwaltungskontrolle des Cloud-Datenverarbeitungs-Dienstanbieters unterstellt. Obwohl technische und gesetzliche Schutzvorkehrungen vorhanden sein mögen, können die Unversehrtheit, Vertraulichkeit und der Schutz der Geschäftsdaten nicht hundertprozentig sichergestellt werden. Ein beispielhaftes Szenario: Wenn der Cloud-Dienstanbieter aufgekauft wird, können die Unternehmensgeschäftsdaten gegenüber Dritten, ja sogar gegenüber möglichen Wettbewerbern offengelegt werden. Diese Möglichkeit ist nicht akzeptabel.
Sofern die Kunden von Cloud-Anbietern nicht sicher sein können, dass sie die Sicherheitskontrolle über ihre Geschäftsdaten aufrechterhalten können, werden sie zögern, ihre geschäftsentscheidenden Anwendungen in einer Cloud-Datenverarbeitungsumgebung bereitzustellen. Der Gegenstand dieser Offenbarung behebt dieses Problem.
KURZDARSTELLUNG
Diese Offenbarung beschreibt ein Plug-In-Modell zur Identitäts- und Berechtigungsprüfung für eine Cloud-Datenverarbeitungsumgebung, mit der Cloud-Kunden die Kontrolle über ihre Unternehmensdaten behalten können, wenn Anwendungen und diese Daten in der Cloud bereitgestellt werden. Hierfür ermöglicht der Cloud-Dienstanbieter (z. B. über einen Plug-In-Dienst) einem Unternehmenskunden, sich (in die Umgebung) einzuklinken und sein eigenes Sicherheitsmodul zur Identitäts- und Berechtigungsprüfung zu verwenden.
Der Cloud-Dienstanbieter verfügt über einen Cloud-Umgebungsadministrator, der Kunden, die Anwendungen in der Cloud-Umgebung bereitstellen, Ressourcengruppen zuordnet. Wenn ein Kunde eine Anwendung bereitstellt, ordnet der Cloud-Umgebungsadministrator der Anwendung und den Daten des Kunden eine Ressourcengruppe zu (z. B. Prozessoren, Speicher und Arbeitsspeicher). Der Kunde registriert sein Sicherheitsmodul zur Identitäts- und Berechtigungsprüfung bei dem Cloud-Sicherheitsdienst, und anhand dieses Sicherheitsmoduls wird dann kontrolliert, welche Personen oder Einheiten auf Daten zugreifen können, die der bereitgestellten Anwendung zugehörig sind. Der Cloud-Umgebungsadministrator ist jedoch nicht (als zugelassener Benutzer) bei dem Sicherheitsmodul des Kunden registriert; somit ist der Cloud-Umgebungsadministrator nicht in der Lage, auf die dem Cloud-Kunden zugewiesenen Ressourcen (obwohl er diese Ressourcen selbst zugewiesen hat) oder die zugehörigen Geschäftsdaten zuzugreifen (bzw. sie für andere oder für den allgemeinen Ressourcen-Pool der Cloud freizugeben).
Das Plug-In-Sicherheitsmodell stellt sicher, dass die Daten des Unternehmenskunden sicher sind. Um diesen Ansatz zu ermöglichen, wird ein Drittanbieter-Notardienst als Mittler zwischen dem Unternehmenskunden und dem Cloud-Anbieter bereitgestellt. Der Drittanbieter-Notardienst kann einem oder mehreren Cloud-Anbietern zugehörig sein, ist dabei jedoch eine getrennte und unabhängige Einheit, die nicht der Kontrolle durch den Cloud-Anbieter untersteht. Der Notar kann eine Regierungsstelle, eine private Einheit, eine öffentliche Einheit oder dergleichen sein. Er fungiert als Zertifizierungsstelle (oder, allgemeiner gesprochen, als maßgebende Drittpartei), die – vorzugsweise auf automatisierte Art und Weise – eine Vereinbarung zwischen dem Kunden, dem Cloud-Anbieter und dem Drittanbieter-Notardienst testieren kann. Neben anderen Vorkehrungen regelt die Vereinbarung, dass die dem Cloud-Kunden zugewiesene(n) Ressourcengruppe(n) (d. h. die Cloud-Ressourcen) nur unter bestimmten Bedingungen zur Verwendung durch einen anderen Kunden freigegeben werden dürfen. Eine solche Bedingung ist z. B. dann gegeben, wenn sowohl der Cloud-Umgebungsadministrator als auch der Cloud-Kundenadministrator sich anmelden, um die Freigabe zu genehmigen, wobei dies weiter daran geknüpft ist, dass die Inhalte (z. B. die Geschäftsdaten des Kunden) vor einer derartigen Freigabe gelöscht werden. Ein weiteres Beispiel für eine solche Bedingung ist der Empfang einer Anmeldung eines zulässigen notariellen Benutzers und des Cloud-Umgebungsadministrators, was z. B. der Fall sein kann, wenn der Kunde einer Verpflichtung, die sich aus der Cloud-Dienstvereinbarung ergibt, nicht nachkommt. Auch bei diesem Szenario ist die Freigabe der Ressourcengruppe jedoch an die Löschung der Daten des (nun ehemaligen) Kunden geknüpft. Diese Herangehensweise stellt sicher, dass der Cloud-Umgebungsadministrator nicht dem Kunden zugeordnete Ressourcen einseitig zurücknehmen und/oder für den Kunden sensible Daten einsehen kann, selbst wenn der Kunde die Dienstvereinbarung verletzt und als Kunde ausscheidet.
In obigen Ausführungen wurden einige der besonders relevanten Merkmale der Erfindung dargelegt. Diese Merkmale sind rein veranschaulichend zu verstehen. Wie weiter unten beschrieben, lassen sich viele andere vorteilhafte Ergebnisse realisieren, indem die offenbarte Erfindung auf andere Art und Weise angewendet oder indem sie angepasst wird.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Für ein umfassenderes Verständnis der vorliegenden Erfindung und der damit einhergehenden Vorteile wird nun auf die folgenden Beschreibungen in Verbindung mit den beigefügten Zeichnungen verwiesen, wobei:
1 ein bildhaftes Blockschaubild einer verteilten Datenverarbeitungsumgebung zeigt, in der beispielhafte Aspekte der veranschaulichenden Ausführungsformen realisiert sein können;
2 ein bildhaftes Blockschaubild eines verteilten Datenverarbeitungssystems zeigt, in dem beispielhafte Aspekte der veranschaulichenden Ausführungsformen realisiert sein können;
3 ein beispielhaftes Blockschaubild ist, das eine bekannte „Federated Single Sign-On”-(F-SSO)-Methode veranschaulicht;
4 Abstraktionsmodellschichten einer Cloud-Datenverarbeitungsumgebung zeigt, in der ein Identitätsanbieter-Erkennungsprozess gemäß einer Ausführungsform der Erfindung realisiert sein kann;
5 ein beispielhaftes Blockschaubild ist, das eine bekannte Cloud-Datenverarbeitungsumgebung und die einer bereitgestellten Kundenanwendung zugeordneten Cloud-Ressourcen veranschaulicht;
6 ein Identitäts- und Berechtigungsprüfmodel veranschaulicht, das die Sicherheit einer Cloud-Datenverarbeitungsplattform für Kundendaten gemäß dieser Offenbarung sicherstellt;
7 veranschaulicht, wie ein kundenspezifisches Identitäts- und Berechtigungsprüfungsmodul gemäß dieser Offenbarung in die Cloud-Infrastruktur eingebunden wird;
8 veranschaulicht, wie ein Notardienst mit dem Cloud-Nutzer und dem Cloud-Anbieter interagiert, um den Abschluss einer sicheren, nicht bestreitbaren elektronischen Nutzungsüberlassung für eine Ressourcengruppe zu ermöglichen; und
9 ein typisches Anwendungsszenario des Systems veranschaulicht.
AUSFÜHRLICHE BESCHREIBUNG EINER VERANSCHAULICHENDEN AUSFÜHRUNGSFORM
Bezugnehmend auf die Zeichnungen und insbesondere auf die 1 und 2 werden beispielhafte Darstellungen von Datenverarbeitungsumgebungen bereitgestellt, in denen veranschaulichende Ausführungsformen der Offenbarung realisiert sein können. Dabei sollte klar sein, dass die 1 und 2 lediglich beispielhaft sind und keinerlei Einschränkung mit Blick auf die Umgebungen geltend machen oder implizieren sollen, in denen Aspekte oder Ausführungsformen des offenbarten Erfindungsgegenstands realisiert sein können. An den abgebildeten Umgebungen können viele Verbesserungen vorgenommen werden, ohne vom gedanklichen Wesensgehalt und inhaltlichen Umfang der vorliegenden Erfindung abzuweichen.
Das Client-Server-Modell
Mit Blick auf die Zeichnungen zeigt 1 eine bildhafte Darstellung eines beispielhaften verteilten Datenverarbeitungssystems, in dem Aspekte der veranschaulichenden Ausführungsformen realisiert sein können. Ein verteiltes Datenverarbeitungssystem 100 kann ein Netzwerk von Computern beinhalten, in dem Aspekte der veranschaulichenden Ausführungsformen realisiert sein können. Das verteilte Datenverarbeitungssystem 100 enthält mindestens ein Netzwerk 102, welches das Medium ist, mit dem Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Computern hergestellt werden, die innerhalb des verteilten Datenverarbeitungssystems 100 miteinander verbunden sind. Das Netzwerk 102 kann Verbindungen wie Leitungen, drahtlose Datenübertragungsverbindungen oder Lichtwellenleiter beinhalten.
In dem abgebildeten Beispiel sind ein Server 104 und ein Server 106 zusammen mit einer Speichereinheit 108 mit dem Netzwerk 102 verbunden. Zusätzlich sind auch Clients 110, 112 und 114 mit dem Netzwerk 102 verbunden. Diese Clients 110, 112 und 114 können z. B. Personal Computer, Netzwerkcomputer oder dergleichen sein. In dem abgebildeten Beispiel stellt der Server 104 Clients 110, 112 und 114 Daten wie z. B. Boot-Dateien, Betriebssystemabbilder und Anwendungen bereit. Die Clients 110, 112 und 114 sind in dem abgebildeten Beispiel Clients des Servers 104. Das verteilte Datenverarbeitungssystem 100 kann zusätzliche Server, Clients und andere Einheiten beinhalten, die hier nicht abgebildet sind.
In dem abgebildeten Beispiel ist das verteilte Datenverarbeitungssystem 100 das Internet, wobei das Netzwerk 102 für eine weltweite Zusammenstellung von Netzwerken und Gateways steht, welche die TCP/IP-Protokollfamilie (Transmission Control Protocol/Internet Protocol) nutzen, um untereinander Daten auszutauschen. Der Kern des Internet ist ein Hauptnetzwerk von Hochgeschwindigkeits-Datenübertragungsleitungen zwischen wichtigen Knoten oder Host-Computern, das aus Tausenden von Computersystemen gewerblicher Unternehmen, Behörden, Bildungseinrichtungen und anderen Computersystemen besteht, die Daten und Nachrichten weiterleiten. Selbstverständlich kann das verteilte Datenverarbeitungssystem 100 auch so realisiert sein, dass es eine Anzahl verschiedener Arten von Netzwerken enthält, wie z. B. ein Intranet, ein Nahbereichsnetz (Local Area Network, LAN), ein Weitverkehrsnetz (Wide Area Network, WAN) oder dergleichen. Wie oben erwähnt, ist 1 als Beispiel und nicht als architektonische Beschränkung verschiedener Ausführungsformen des offenbarten Erfindungsgegenstands gedacht, so dass die einzelnen Elemente aus 1 mit Blick auf die Umgebungen, in denen die veranschaulichenden Ausführungsformen der vorliegenden Erfindung realisiert sein können, nicht als einschränkend zu verstehen sind.
Mit Blick auf 2 wird ein Blockschaubild eines Datenverarbeitungssystems gezeigt, indem veranschaulichende Ausführungsformen realisiert sein können. Ein Datenverarbeitungssystem 200 ist beispielsweise ein Computer, z. B. der Server 104 oder der Client 110 aus 1, in dem sich computernutzbarer Programmcode oder Befehle befinden können, womit die Prozesse für veranschaulichende Ausführungsformen realisiert werden. In diesem veranschaulichenden Beispiel beinhaltet das Datenverarbeitungssystem 200 eine Datenübertragungsstruktur 202, welche die Datenübertragung zwischen einer Prozessoreinheit 204, einem Arbeitsspeicher 206, einem permanenten Speicher 208, einer Datenübertragungseinheit 210, einer Ein-/Ausgabe-Schnittstelle (E/A-Schnittstelle) 212 und einer Anzeige 214 bereitstellt.
Die Prozessoreinheit 204 dient zum Ausführen von Befehlen für Software, die in den Arbeitsspeicher 206 geladen werden kann. Die Prozessoreinheit 204 kann ein Satz aus einem oder mehreren Prozessoren oder ein Mehrprozessorkern sein, wobei dies abhängig von der jeweiligen Realisierung ist. Des Weiteren kann die Prozessoreinheit 204 unter Verwendung eines oder mehrerer heterogener Prozessorsysteme realisiert sein, bei denen auf einem einzigen Chip ein Hauptprozessor mit sekundären Prozessoren vorhanden ist. In einem weiteren veranschaulichenden Beispiel kann die Prozessoreinheit 204 ein symmetrisches Mehrprozessorsystem (Symmetric Multi-Processor, SMP) sein, das mehrere Prozessoren desselben Typs beinhaltet.
Der Arbeitsspeicher 206 und der permanente Speicher 208 sind Beispiele für Speichereinheiten. Eine Speichereinheit ist eine beliebige Hardware-Einheit, die in der Lage ist, Daten vorübergehend und/oder dauerhaft zu speichern. Der Arbeitsspeicher 206 kann in diesen Beispielen ein Direktzugriffsspeicher oder eine beliebige anderweitige geeignete, flüchtige oder nichtflüchtige Speichereinheit sein. Der permanente Speicher 208 kann je nach Realisierung verschiedene Formen annehmen. So kann der permanente Speicher 208 z. B. eine oder mehrere Komponenten oder Einheiten beinhalten. Der permanente Speicher 208 kann beispielsweise eine Festplatte, ein Flash-Speicher, eine wiederbeschreibbare optische Platte, ein wiederbeschreibbares Magnetband oder eine beliebige Kombination der obigen Komponenten sein. Die von dem permanenten Speicher 208 verwendeten Medien können auch entfernbar sein. So kann z. B. eine entfernbare Festplatte als permanenter Speicher 208 verwendet werden.
Die Datenübertragungseinheit 210 stellt in diesen Beispielen die Datenübertragung mit anderen Datenverarbeitungssystemen oder -einheiten bereit. In diesen Beispielen ist die Datenübertragungseinheit 210 eine Netzschnittstellenkarte. Die Datenübertragungseinheit 210 kann die Datenübertragung entweder über physische oder drahtlose Datenübertragungsverbindungen oder aber über beides bereitstellen.
Die Ein-/Ausgabe-Einheit 212 ermöglicht die Ein- und Ausgabe von Daten mit Blick auf andere Einheiten, die mit dem Datenverarbeitungssystem 200 verbunden sein können. So kann die Ein-/Ausgabe-Einheit 212 z. B. eine Verbindung für eine Benutzereingabe über eine Tastatur und Maus bereitstellen. Des Weiteren kann die Ein-/Ausgabe-Einheit 212 eine Ausgabe an einen Drucker senden. Die Anzeige 214 stellt einen Mechanismus zum Anzeigen von Daten für einen Benutzer bereit.
Befehle für das Betriebssystem und Anwendungen oder Programme befinden sich im permanenten Speicher 208. Diese Befehle können zur Ausführung durch die Prozessoreinheit 204 in den Arbeitsspeicher 206 geladen werden. Die Prozesse der verschiedenen Ausführungsformen können durch die Prozessoreinheit 204 unter Verwendung computerrealisierter Befehle ausgeführt werden, die sich in einem Arbeitsspeicher wie z. B. dem Arbeitsspeicher 206 befinden können. Diese Befehle werden als Programmcode, computernutzbarer Programmcode oder computerlesbarer Programmcode bezeichnet, der durch einen Prozessor in der Prozessoreinheit 204 gelesen und ausgeführt werden kann. Der Programmcode in den verschiedenen Ausführungsformen kann auf verschiedenen physischen oder greifbaren computerlesbaren Medien wie z. B. im Arbeitsspeicher 206 oder im permanenten Speicher 208 enthalten sein.
Ein Programmcode 216 befindet sich in einer funktionalen Form auf einem computerlesbaren Medium 218, das wahlweise entfernbar ist, und kann in das Datenverarbeitungssystem 200 geladen bzw. auf dieses übertragen werden, um durch die Prozessoreinheit 204 ausgeführt zu werden. Der Programmcode 216 und die computerlesbaren Medien 218 bilden in diesen Beispielen ein Computerprogrammprodukt 220. In einem Beispiel können die computerlesbaren Medien 218 in einer physischen Form vorliegen, z. B. als eine optische oder magnetische Platte, die für die Übertragung an eine Speichereinheit wie z. B. eine Festplatte, die Teil des permanenten Speichers 208 ist, in ein Laufwerk oder eine andere Einheit geschoben oder gelegt wird, das/die Teil des permanenten Speichers 208 ist. In einer physischen Form können die computerlesbaren Medien 218 auch die Form eines permanenten Speichers annehmen, z. B. einer Festplatte, eines USB-Sticks oder eines Flash-Speichers, die/der mit einem Datenverarbeitungssystem 200 verbunden ist. Die physische Form von computerlesbaren Medien 218 wird auch als ein Computer-aufzeichnungsfähiges Speichermedium bezeichnet. In manchen Fällen kann ein Computer-aufzeichnungsfähiges Medium 218 nicht entfernbar sein.
Alternativ kann der Programmcode 216 über eine Datenübertragungsverbindung mit der Datenübertragungseinheit 210 und/oder über eine Verbindung mit der Ein-/Ausgabe-Einheit 212 von dem computerlesbaren Medium 218 an das Datenverarbeitungssystem 200 übertragen werden. In den veranschaulichenden Beispielen können die Datenübertragungsverbindung und/oder die Verbindung in physischer Form oder drahtlos vorliegen. Das computerlesbare Medium kann auch die Gestalt eines nichtphysischen Mediums annehmen, z. B. von Datenübertragungsverbindungen oder drahtlosen Übertragungen, die den Programmcode beinhalten. Die verschiedenen für das Datenverarbeitungssystem 200 veranschaulichten Komponenten sind nicht als architektonische Beschränkung der Art und Weise zu verstehen, wie verschiedene Ausführungsformen realisiert sein könnten. Die verschiedenen veranschaulichenden Ausführungsformen können in einem Datenverarbeitungssystem realisiert sein, das Komponenten zusätzlich zu den bzw. anstelle der für das Datenverarbeitungssystem 200 veranschaulichten Komponenten enthält. Andere in 2 gezeigte Komponenten können von den in den veranschaulichten Beispielen gezeigten Komponenten abweichen. In einem Beispiel ist eine Speichereinheit in dem Datenverarbeitungssystem 200 eine beliebige Hardware-Vorrichtung, die Daten speichern kann. Der Arbeitsspeicher 206, der permanente Speicher 208 und das computerlesbare Medium 218 sind Beispiele von Speichereinheiten, die in einer physischen Form vorliegen.
In einem weiteren Beispiel kann ein Bussystem zum Realisieren der Datenübertragungsstruktur 202 verwendet werden und einen oder mehrere Busse aufweisen, wie z. B. einen Systembus oder einen Ein-/Ausgabebus. Selbstverständlich lässt sich das Bussystem mit jeder geeigneten Art von Architektur realisieren, die eine Übertragung von Daten zwischen verschiedenen Komponenten oder Einheiten vorsieht, die mit dem Bussystem verbunden sind. Zusätzlich kann eine Datenübertragungseinheit eine oder mehrere Einheiten aufweisen, die zum Senden und Empfangen von Daten verwendet werden, z. B. einen Modem oder einen Netzwerkadapter. Des Weiteren kann ein Arbeitsspeicher z. B. der Arbeitsspeicher 206 oder ein Cachespeicher sein, wie er in einem Interface Controller Hub (ICH) und Memory Controller Hub (MCH) zu finden ist, der in der Datenübertragungsstruktur 202 vorhanden sein kann.
Computerprogrammcode zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann in einer beliebigen Kombination von einer oder mehreren Programmiersprachen geschrieben sein, darunter eine objektorientierte Programmiersprache wie Java, Smalltalk, C++ oder ähnliche sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C” oder ähnliche Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder aber vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. Im letztgenannten Szenario kann der entfernt angeordnete Computer über eine beliebige Art von Netzwerk, darunter ein Nahbereichsnetz (LAN) oder ein Weitverkehrsnetz (WAN), mit dem Computer des Benutzers verbunden sein, oder die Verbindung kann mit einem externen Computer (z. B. über das Internet unter Verwendung eines Internet-Dienstanbieters) hergestellt werden.
Der Fachmann weiß, dass die Hardware aus den 1 und 2 je nach Realisierung variieren kann. Zusätzlich oder anstelle der in den 1 und 2 abgebildeten Hardware können auch andere interne Hardware- oder Peripherie-Einheiten wie z. B. ein Flash-Speicher, ein gleichwertiger nicht flüchtiger Speicher oder optische Plattenlaufwerke und dergleichen verwendet werden. Darüber hinaus können die Prozesse der veranschaulichenden Ausführungsformen auf ein Mehrprozessor-Datenverarbeitungssystem, das nicht mit dem zuvor erwähnten SMP-System gleichzusetzen ist, angewendet werden, ohne vom gedanklichen Wesensgehalt und inhaltlichen Umfang des offenbarten Erfindungsgegenstands abzuweichen.
Bei dem standardmäßigen Client-Server-Paradigma, wie es in 1 veranschaulicht ist, tauschen Client-Maschinen Daten mit einem über das Internet zugänglichen Portal auf der Grundlage des Webs aus, das einen Satz von einer oder mehreren Maschinen ausführt. Insbesondere verwenden die Endbenutzer mit dem Internet verbindbare Einheiten (z. B. Desktop-Computer, Notebook-Computer, Internet-fähige mobile Einheiten oder dergleichen), die in der Lage sind, auf das Portal zuzugreifen und damit zu interagieren. Üblicherweise ist jede Client- oder Server-Maschine ein Datenverarbeitungssystem wie das in 2 veranschaulichte, das Hardware und Software aufweist, wobei diese Einheiten über ein Netzwerk wie z. B. das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder ein(e) beliebige(s) andere(s) Datenübertragungsmedium oder -verbindung untereinander Daten austauschen. Ein Datenverarbeitungssystem enthält üblicherweise einen oder mehrere Prozessoren, ein Betriebssystem, eine oder mehrere Anwendungen und ein oder mehrere Dienstprogramme. Die Anwendungen auf dem Datenverarbeitungssystem stellen eine systemeigene Unterstützung für Web-Dienste bereit, einschließlich, ohne darauf beschränkt zu sein, der Unterstützung für HTTP, SOAP, XML, WSDL, UDDI und WSFL. Informationen zu SOAP, WSDL, UDDI und WSFL sind vom World Wide Web Consortium (W3C) erhältlich, das für die Entwicklung und Pflege dieser Standards zuständig ist; weitere Informationen zu HTTP und XML sind von der Internet Engineering Task Force (IETF) erhältlich. Die Vertrautheit mit diesen Standards wird vorausgesetzt.
Der Begriff „Zusicherung” („Assertion”), wie er hier als zusätzliche Hintergrundinformation verwendet wird, stellt einen indirekten Nachweis für eine bestimmte Aktion bereit. Zusicherungen können indirekte Nachweise für Identität, Identitätsprüfung, Attribute, Berechtigungsprüfungsentscheidungen oder andere Daten und/oder Operationen bereitstellen. Eine Identitätsprüfungszusicherung stellt einen indirekten Identitätsprüfungsnachweis durch eine Einheit bereit, die nicht der Identitätsprüfungsdienst ist, jedoch den Identitätsprüfungsdienst überwacht hat. Nach dem Stand der Technik ist eine SAML-Zusicherung (Security Assertion Markup Language) ein Beispiel für ein mögliches Zusicherungsformat, das mit der vorliegenden Erfindung verwendet werden kann. SAML wurde von der Organization for the Advancement of Structured Information Standards (OASIS) veröffentlicht, einem nicht gewinnorientierten, weltweiten Konsortium. In „Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)”, Committee Specification 01, 31. Mai 2002, wird SAML wie folgt beschrieben:
Security Assertion Markup Language (SAML) ist ein Schema auf der Grundlage von XML für das Austauschen von Sicherheitsdaten. Diese Sicherheitsdaten werden in Form von Zusicherungen zu Subjekten ausgedrückt, wobei ein Subjekt eine (menschliche oder Computer-)Einheit ist, die über eine Identität in einer Sicherheitsdomäne verfügt. Ein typisches Beispiel für ein Subjekt ist eine Person, die durch ihre eMail-Adresse in einer bestimmten Internet-DNS-Domäne kenntlich gemacht ist. Zusicherungen können Informationen zu Identitätsprüfungsaktionen, die von Subjekten durchgeführt werden, zu Attributen von Subjekten und zu Berechtigungsprüfungsentscheidungen dazu bereitstellen, ob Subjekten der Zugriff auf bestimmte Ressourcen erlaubt wird. Zusicherungen werden als XML-Konstrukte dargestellt und weisen eine verschachtelte Struktur auf, wobei eine einzelne Zusicherung mehrere unterschiedliche interne Aussagen über Identitätsprüfung, Berechtigungsprüfung und Attribute enthalten kann. Dabei ist zu beachten, dass Zusicherungen, die Identitätsprüfungsaussagen enthalten, lediglich zuvor erfolgte Identitätsprüfungsaktionen beschreiben. Zusicherungen werden von SAML-Instanzen (SAML Authorities) ausgegeben, d. h. von Identitätsprüfungsinstanzen, Attributinstanzen und Richtlinienentscheidungspunkten. SAML definiert ein Protokoll, mit dem Clients Zusicherungen von SAML-Instanzen anfordern und eine Antwort von ihnen erhalten können. Dieses aus Anfrage- und Antwortnachrichtenformaten auf der Grundlage von XML bestehende Protokoll kann an viele verschiedene darunterliegende Datenübertragungs- und Transportprotokolle gebunden sein; derzeit definiert SAML eine einzige Bindung (an SOAP über HTTP). Beim Erzeugen ihrer Antworten können SAML-Instanzen verschiedene Informationsquellen nutzen, z. B. externe Richtlinienspeicher und Zusicherungen, die als Eingaben bei Anfragen empfangen wurden. Während Clients Zusicherungen stets verbrauchen, können SAML-Instanzen somit sowohl Erzeuger als auch Verbraucher von Zusicherungen sein.
Die SAML-Spezifikation legt fest, dass eine Zusicherung ein Paket von Daten ist, das eine oder mehrere Aussagen zur Verfügung stellt, die von einer Ausgabestelle getätigt wurden. Dabei können Ausgabestellen drei verschiedene Arten von Zusicherungsaussagen tätigen: eine Identitätsprüfung, bei der die Identität des angegebenen Subjekts durch ein bestimmtes Mittel zu einer bestimmten Zeit geprüft wurde; eine Berechtigungsprüfung, bei der eine Anfrage, dem angegebenen Subjekt den Zugriff auf die angegebene Ressourcen zu erlauben, genehmigt oder abgewiesen wurde; und ein Attribut, bei dem das angegebene Subjekt den bereitgestellten Attributen zugehörig ist.
Die Identitätsprüfung ist der Prozess des Bestätigens eines Satzes von Identitätsnachweisen, die von einem Benutzer oder für einen Benutzer bereitgestellt werden. Eine Identitätsprüfung erfolgt, indem etwas überprüft wird, was ein Benutzer weiß, was er hat oder was er ist, d. h. ein physisches Merkmal des Benutzers. Etwas, das ein Benutzer weiß, kann ein gemeinsames Geheimnis wie z. B. das Kennwort eines Benutzers beinhalten, oder es wird etwas überprüft, was nur ein bestimmter Benutzer weiß, z. B. der Verschlüsselungsschlüssel eines Benutzers. Etwas, das ein Benutzer hat, kann eine Smartcard oder ein Hardware-Token beinhalten. Ein bestimmtes physisches Merkmal des Benutzers kann eine biometrische Eingabe beinhalten wie beispielsweise einen Fingerabdruck oder eine Netzhautanalyse. Dabei ist zu beachten, dass ein Benutzer zwar üblicherweise, aber nicht notwendigerweise, eine natürliche Person ist; ein Benutzer könnte auch eine Maschine, eine Datenverarbeitungseinheit oder eine andere Art von Datenverarbeitungssystem sein, die eine Datenverarbeitungsressource nutzt. Zu beachten ist auch, dass ein Benutzer üblicher- aber nicht notwendigerweise einen eindeutigen Bezeichner besitzt; bei manchen Szenarien können mehrere eindeutige Bezeichner einem einzigen Benutzer zugehörig sein.
Ein Identitätsprüfungsnachweis ist ein Satz von Abfrage-/Antwortdaten, der bei verschiedenen Identitätsprüfungsprotokollen verwendet wird. So ist z. B. eine Kombination aus Benutzername und Kennwort die gängigste Form von Identitätsprüfungsnachweis. Andere Formen von Identitätsprüfungsnachweisen können verschiedene Formen von Abfrage-/Antwortdaten, PKI-Zertifikaten (Public Key Infrastructure), Smartcards, biometrischen Daten usw. beinhalten. Ein Identitätsprüfungsnachweis ist von einer Identitätsprüfungszusicherung zu unterscheiden: Ein Identitätsprüfungsnachweis wird von einem Benutzer als Bestandteil einer Identitätsprüfungs-Protokollsequenz für einen Identitätsprüfungs-Server oder -dienst vorgelegt, während eine Identitätsprüfungszusicherung eine Aussage über die erfolgreiche Vorlage und Bestätigung des Identitätsprüfungsnachweises eines Benutzers ist, die anschließend bei Bedarf zwischen Einheiten übertragen wird.
Federated SSO
Single Sign-On (SSO, Einmalanmeldung) ist ein Zugriffskontrollmechanismus, der es einem Benutzer ermöglicht, einmalig seine Identität nachzuweisen (indem er z. B. einen Benutzernamen und ein Kennwort bereitstellt) und dann Zugriff auf Software-Ressourcen zu erhalten, die auf mehrere Systeme verteilt sind. Üblicherweise gestattet ein SSO-System den Benutzerzugriff auf Ressourcen innerhalb eines Unternehmens oder einer Organisation. Federated Single Sign-on (F-SSO, föderierte Einmalanmeldung) erweitert das Konzept des Single Sign-On auf mehrere Unternehmen und stellt dadurch Partnerschaften zwischen verschiedenen Organisationen und Unternehmen her. F-SSO-Systeme beinhalten üblicherweise Protokolle wie z. B. SAML, mit denen ein Unternehmen (z. B. ein Identitätsanbieter) einem anderen Unternehmen (z. B. einem Dienstanbieter) die Identität und andere Attribute eines Benutzers bereitstellen kann. Anders ausgedrückt: Ein F-SSO-System hilft bei der vertrauenswürdigen Übertragung des Identitätsprüfungsnachweises des Benutzers vom Identitätsanbieter zum Dienstanbieter unter Verwendung eines geeigneten Protokolls (üblicherweise HTTP). 3 ist ein Blockschaubild, das den typischen Ablauf von Operationen in einem bekannten F-SSO-Prozess veranschaulicht. Wie in 3 gezeigt beinhaltet der F-SSO-Prozess 300 den Datenaustausch zwischen einem Identitätsanbieter 302, einer Benutzeranwendung 304 und einem Dienstanbieter 306. Der Identitätsanbieter 302 und der Dienstanbieter 306 beinhalten ein F-SSO-System 308, das Logik beinhaltet, um die Identität eines Benutzers zu überprüfen, den Identitätsprüfungsnachweis des Benutzers zu erstellen und ein verschlüsseltes Sicherheits-Token (z. B. ein Cookie) mit Benutzerdaten zu erzeugen. Zusätzlich kann der Dienstanbieter 306 auch eine oder mehrere Zielanwendungen 310 und 312 beinhalten. Die Zielanwendungen können innerhalb derselben Web-Umgebung angesiedelt oder Bestandteil unterschiedlicher Web-Umgebungen 314 und 316 (z. B. Apache, WebSphere^® usw.) innerhalb desselben Dienstanbieters 306 sein. Die Benutzeranwendung 304 kann Logik (z. B. einen Web-Browser) enthalten, um dem Benutzer Inhalte (z. B. Web-Seiten) darzustellen.
Bei einer Ausführungsform erbringt die Benutzeranwendung zunächst einen Identitätsnachweis gegenüber dem Identitätsanbieter 302 (indem sie z. B. einen Benutzernamen und ein Kennwort bereitstellt), wie in Schritt 1 angegeben. In Schritt 2 gibt das F-SSO-System 308 des Identitätsanbieters dem Benutzer ein Sicherheits-Token zurück. Das Sicherheits-Token kann zeitgebunden (z. B. eine Zeitmarke enthalten) und kryptografisch unterzeichnet sein. Das Sicherheits-Token kann die Identität (z. B. den Benutzernamen) und andere Attribute (z. B. die Benutzeridentifizierungsnummer) des Benutzers beinhalten, die der Identitätsanbieter 302 dem Dienstanbieter 306 bereitstellen möchte. Die Benutzeranwendung 304 kann das Sicherheits-Token dem F-SSO-System des Dienstanbieters vorlegen und dabei jede geeignete Methode (z. B. eine HTTP-Anforderung) und Nachrichtenstruktur (z. B. unter Verwendung von HTTP-Abfragezeichenfolgen, HTTP POST-Daten usw.) verwenden, die durch das F-SSO-Protokoll definiert sind (siehe auch Schritt 3). In Schritt 4 prüft das F-SSO-System 308 des Dienstanbieters die kryptografische Signatur des Sicherheits-Tokens, um die Identitätsprüfung des Token-Ursprungs nachzuweisen und zu bestätigen, dass der Inhalt des Sicherheits-Tokens vertrauenswürdig ist. Das F-SSO-System des Dienstanbieters kann zudem die Identität und die zugehörigen Attribute des Benutzers aus dem Sicherheits-Token entnehmen und ein F-SSO-Attribut-Cookie mit der Identität und den Attributen des Benutzers erzeugen.
Wenn der Benutzer nach erfolgter Einmalanmeldung (d. h. nach dem Übertragen von Benutzerattributen vom F-SSO-System des Identitätsanbieters an das F-SSO-System des Dienstanbieters) auf eine vom Dienstanbieter 306 bereitgestellte Zielanwendung (z. B. 310) zugreifen möchte, kann die Benutzeranwendung 304 ein F-SSO-Attribut-Cookie, das vom SSO-System 308 des Dienstanbieters empfangen wurde, an die Zielanwendung weiterleiten (siehe auch Schritt 5). Alternativ dazu können Attribute in einem Proxy gespeichert und weitergeleitet werden, wenn eine Benutzeranforderung den Proxy passiert, so dass keine Cookies erforderlich sind. In dieser Beispielausführungsform erfolgt die Übertragung von Benutzerattributen (z. B. in einem F-SSO-Cookie) auf vertrauenswürdige und sichere Art und Weise und kann auf der Grundlage der für F-SSO festgelegten Protokolle (üblicherweise HTTP) durchgeführt werden. Wenn die in einem F-SSO-Attribut-Cookie enthaltenen Daten von der Zielanwendung akzeptiert und verstanden werden (z. B. wenn die Zielanwendung den Cookie-Inhalt entschlüsseln und abrufen kann), bestätigt die Zielanwendung (z. B. 310) ihre Gültigkeit und erzeugt eine Sitzung für den Benutzer. Bei manchen Ausführungsformen verstehen die Zielanwendungen (z. B. 310) das F-SSO-Attribut-Cookie oder können ein Bestandteil des F-SSO-Prozesses sein (d. h. die Zielanwendung beinhaltet unter Umständen kein F-SSO-System).
Das Cloud-Datenverarbeitungsmodell
Als zusätzliche Hintergrundinformation ist die Cloud-Datenverarbeitung ein Modell einer Dienstbereitstellung, um einen komfortablen, bedarfsgesteuerten Netzwerkzugriff auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z. B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Arbeitsspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste) zu ermöglichen, die mit möglichst geringem Verwaltungsaufwand und möglichst wenig Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Merkmale, mindestens drei Dienstmodelle und mindestens vier Bereitstellungsmodelle beinhalten, wie sie sämtlich in „Draft NIST Working Definition of Cloud Computing” von Peter Mell und Tim Grance vom 07. Oktober 2009 ausführlicher beschrieben werden.
Typische Merkmale sind insbesondere:
Bedarfsgesteuerte Selbstbedienung: Ein Cloud-Verbraucher kann einseitig und automatisch nach Bedarf Datenverarbeitungskapazitäten wie z. B. Server-Zeit und Netzwerkspeicher bereitstellen, ohne dass hierfür eine menschliche Interaktion mit dem Anbieter des Dienstes notwendig ist.
Breiter Netzwerkzugriff: Kapazitäten werden über ein Netzwerk zur Verfügung gestellt, wobei der Zugriff über Standardmechanismen erfolgt, die eine Verwendung durch verschiedenartige Thin- oder Thick-Client-Plattformen ermöglichen (z. B. Mobiltelefone, Laptops und PDAs). Ressourcenbündelung: Die Datenverarbeitungsressourcen des Anbieters sind gebündelt, um unter Verwendung eines Multi-Tenant-Modells mehreren Verbrauchern bereitzustehen, wobei verschiedene physische und virtuelle Ressourcen dynamisch und nach Bedarf zugewiesen bzw. neu zugewiesen werden. Standortunabhängigkeit ist insofern gegeben, als der Verbraucher im Allgemeinen den genauen Standort der bereitgestellten Ressourcen weder kontrolliert noch kennt, jedoch unter Umständen in der Lage ist, auf einer höheren Abstraktionsebene (z. B. Land, Bundesland oder Rechenzentrum) einen Standort festzulegen.
Flexible Anpassungsfähigkeit: Kapazitäten lassen sich schnell und elastisch (in einigen Fällen automatisch) bereitstellen, um eine rasche Skalierung nach oben zu ermöglichen, sowie – für eine rasche Skalierung nach unten – schnell wieder freigegeben zu werden. Für den Verbraucher scheinen die zur Bereitstellung verfügbaren Kapazitäten häufig unbegrenzt zu sein und können jederzeit in jeder beliebigen Menge erworben werden.
Dienstmessung: Cloud-Systeme kontrollieren und optimieren die Ressourcennutzung automatisch, indem sie in einer bestimmten, der Art des Dienstes angemessenen Abstraktionsschicht eine Messfunktion nutzen (z. B. Speicherung, Verarbeitung, Bandbreite und aktive Benutzerkonten). Die Ressourcennutzung kann überwacht, kontrolliert und protokolliert werden, wodurch sowohl für den Anbieter als auch für den Verbraucher des genutzten Dienstes Transparenz bereitgestellt wird.
Typische Dienstmodelle sind:
Software as a Service (SaaS): Die dem Verbraucher bereitgestellte Kapazität besteht darin, die in einer Cloud-Infrastruktur ausgeführten Anwendungen des Anbieters zu verwenden. Der Zugriff auf die Anwendungen kann über eine Thin-Client-Schnittstelle wie z. B. einen Web-Browser von verschiedenen Client-Einheiten aus erfolgen (z. B. eine eMail-Nachricht auf der Grundlage des Webs). Mit Ausnahme beschränkter benutzerspezifischer Einstellungen der Anwendungskonfiguration wird die darunterliegende Cloud-Infrastruktur wie Netzwerk, Server, Betriebssysteme, Speicher oder auch einzelne Anwendungsfunktionen vom Verbraucher weder verwaltet noch kontrolliert.
Platform as a Service (PaaS): Die dem Verbraucher bereitgestellte Kapazität besteht darin, dass vom Benutzer erzeugte oder erworbene Anwendungen, die anhand von vom Anbieter bereitgestellten Programmiersprachen und Werkzeugen erstellt wurden, in der Cloud-Infrastruktur bereitzustellen. Die darunterliegende Infrastruktur wie Netzwerke, Server, Betriebssysteme oder Speicher wird vom Verbraucher weder verwaltet noch kontrolliert, er hat jedoch die Kontrolle über die bereitgestellten Anwendungen und möglicherweise über Konfigurationen der Hosting-Umgebung für die Anwendungen.
Infrastructure as a Service (IaaS): Die dem Verbraucher bereitgestellte Kapazität besteht darin, Verarbeitung, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Verbraucher in der Lage ist frei wählbare Software wie z. B. Betriebssysteme und Anwendungen bereitzustellen und auszuführen. Die darunterliegende Cloud-Infrastruktur wird vom Verbraucher weder verwaltet noch kontrolliert, er hat jedoch die Kontrolle über Systeme und Einheiten (z. B. Betriebssysteme, Speicher, bereitgestellte Anwendungen usw.) und möglicherweise eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z. B. Host-Firewalls).
Typische Bereitstellungsmodelle sind:
Private Cloud: Die Cloud-Infrastruktur wird für lediglich eine Organisation betrieben. Sie kann von der Organisation selbst oder von einem Dritten verwaltet werden und sich an Ort und Stelle oder an einem anderen Ort befinden.
Gemeinschafts-Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezifische Gemeinschaft mit gemeinsamen Anliegen (z. B. Aufgabe, Sicherheitsanforderungen, Richtlinie und Einhaltung von Gesetzen und Richtlinien). Sie kann von den Organisationen selbst oder von einem Dritten verwaltet werden und sich an Ort und Stelle oder an einem anderen Ort befinden.
Öffentliche Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Branchengruppe bereitgestellt und ist Eigentum einer Organisation, die Cloud-Dienste verkauft.
Hybrid-Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren (privaten, Gemeinschafts- oder öffentlichen) Clouds, die eigenständige Einheiten bleiben, aber durch eine standardisierte oder herstellerspezifische Technologie miteinander verbunden sind, die eine Portierbarkeit von Daten und Anwendungen ermöglicht (z. B. das Cloud Bursting für den Lastausgleich zwischen Clouds).
Eine Cloud-Datenverarbeitungsumgebung ist dienstorientiert, wobei der Schwerpunkt auf Zustandslosigkeit, geringer Kopplung, Modularität und semantischer Kompatibilität liegt. Im Mittelpunkt einer Cloud-Datenverarbeitung steht eine Infrastruktur, die ein Netzwerk von miteinander verbundenen Knoten aufweist. Ein repräsentativer Cloud-Datenverarbeitungsknoten ist in 2 (oben) veranschaulicht. Insbesondere gibt es in einem Cloud-Datenverarbeitungsknoten ein Computersystem/einen Server, das bzw. der mit zahlreichen anderen Universal- oder Spezialsystemumgebungen oder -konfigurationen betrieben werden kann. Beispiele bekannter Datenverarbeitungssysteme, -umgebungen und/oder -konfigurationen, die für eine Verwendung mit einem Computersystem/Server geeignet sein könnten, sind, ohne darauf beschränkt zu sein, Personal-Computersysteme, Server-Computersysteme, Thin Clients, Thick Clients, Taschen- oder Laptop-Einheiten, Mehrprozessorsysteme, Systeme auf der Grundlage von Mikroprozessoren, Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Mini-Computersysteme, Großrechner-Computersysteme sowie verteilte Cloud-Datenverarbeitungsumgebungen, die eine(s) der obigen Systeme oder Einheiten beinhalten, und dergleichen. Das Computersystem/der Server lässt sich im allgemeinen Zusammenhang von Befehlen beschreiben, die durch ein Computersystem ausführbar sind, wie z. B. Programmmodule, die von einem Computersystem ausgeführt werden. Allgemein können Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen usw. beinhalten, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen realisieren. Das Computersystem/der Server kann in verteilten Cloud-Datenverarbeitungsumgebungen eingesetzt werden, wo Aufgaben von entfernt angeordneten Verarbeitungseinheiten durchgeführt werden, die über ein Datenübertragungsnetzwerk miteinander verbunden sind. In einer verteilten Cloud-Datenverarbeitungsumgebung können sich Programmmodule sowohl in lokalen als auch in entfernt angeordneten Computersystem-Speichermedien wie beispielsweise Arbeitsspeichereinheiten befinden.
Als zusätzliche Hintergrundinformation wird mit Blick auf 4 ein Satz von funktionsbezogenen Abstraktionsschichten gezeigt, der von einer Cloud-Datenverarbeitungsumgebung bereitgestellt wird. Dabei sollte von Anfang an klar sein, dass die in 4 gezeigten Komponenten, Schichten und Funktionen lediglich zur Veranschaulichung gedacht und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie abgebildet, werden die folgenden Schichten und zugehörigen Funktionen bereitgestellt:
Eine Hardware- und Software-Schicht 400 enthält Hardware- und Software-Komponenten. Beispiele für Hardware-Komponenten beinhalten Großrechner wie z. B. IBM^® zSeries^® Systeme; Server auf der Grundlage der RISC-Architektur (Reduced Instruction Set Computer) wie z. B. IBM pSeries^® Systeme; IBM xSeries^® Systeme; IBM BladeCenter^® Systeme; Speichereinheiten; Netzwerke und Netzwerkkomponenten. Beispiele für Software-Komponenten beinhalten Software für Netzwerk-Anwendungs-Server wie z. B. IBM WebSphere^® Anwendungs-Server-Software; sowie Datenbank-Software wie z. B. IBM DB2^® Datenbank-Software. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere und DB2 sind Handelsmarken der International Business Machines Corporation, die in vielen Ländern weltweit eingetragen sind.)
Eine Virtualisierungsschicht 402 stellt eine Abstraktionsschicht bereit, welche die folgenden Beispiele für virtuelle Einheiten zur Verfügung stellen kann: virtuelle Server; virtueller Speicher; virtuelle Netzwerke wie z. B. virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme; sowie virtuelle Clients.
In einem Beispiel kann eine Verwaltungsschicht 404 die im Folgenden beschriebenen Funktionen bereitstellen. Die Ressourcenbereitstellung stellt eine dynamische Beschaffung von Datenverarbeitungs- und anderen Ressourcen bereit, mit denen Aufgaben innerhalb der Cloud-Datenverarbeitungsumgebung durchgeführt werden. Messungs- und Preisermittlungsfunktionen stellen eine Kostenerfassung bei der Nutzung von Ressourcen innerhalb der Cloud-Datenverarbeitungsumgebung sowie eine Fakturierung bzw. Abrechnung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungs-Software aufweisen. Eine Sicherheitsfunktion stellt eine Identitätsprüfung für Cloud-Verbraucher und -Aufgaben sowie einen Schutz für Daten und andere Ressourcen bereit. Eine Benutzerportalfunktion stellt Verbrauchern und Systemadministratoren einen Zugriff auf die Cloud-Datenverarbeitungsumgebung bereit. Eine Dienstgüteverwaltungsfunktion stellt eine Zuordnung und Verwaltung von Cloud-Datenverarbeitungsressourcen bereit, so dass erforderliche Dienstgütestufen erreicht werden. Eine Planungs- und Ausführungsfunktion von Dienstgütevereinbarungen (Service Level Agreement, SLA) stellt eine Vorabfestlegung und Beschaffung von Cloud-Datenverarbeitungsressourcen bereit, für die gemäß einer SLA eine künftige Anforderung erwartet wird.
Eine Auslastungsschicht 406 stellt Beispiele einer Funktionalität bereit, für welche die Cloud-Datenverarbeitungsumgebung genutzt werden kann. Beispiele für Auslastungen und Funktionen, die von dieser Schicht bereitgestellt werden können, lauten: Zuordnung und Navigation; Software-Entwicklung und Lebenszyklusverwaltung; Bereitstellung von virtuellen Schulungen; Datenanalyseverarbeitung; Transaktionsverarbeitung; sowie – gemäß den Lehren dieser Offenbarung – eine Cloud-Anwendung, für die ein Rich Client einen Identitätsprüfungsnachweis erbringen möchte.
Obwohl diese Offenbarung eine ausführliche Beschreibung der Cloud-Datenverarbeitung beinhaltet, sollte vorab klar sein, dass die Realisierung der hier dargelegten Lehren nicht auf eine Cloud-Datenverarbeitungsumgebung beschränkt ist. Vielmehr können Ausführungsformen der vorliegenden Erfindung in Verbindung mit jeder anderen Art von Datenverarbeitungsumgebung nach dem derzeitigen oder künftigen Stand der Technik realisiert werden.
Somit weist eine repräsentative Cloud-Datenverarbeitungsumgebung einen Satz von übergeordneten Funktionskomponenten auf, die eine Front-End-Identitätsverwaltungseinheit, eine Funktionskomponente für Geschäftsunterstützungsdienste (Business Support Services, BSS), eine Funktionskomponente für Betriebsunterstützungsdienste (Operational Support Services, OSS) und die Cloud-Datenverarbeitungskomponente enthalten. Die Identitätsverwaltungseinheit ist zuständig für das Bereitstellen einer Schnittstelle zu anfordernden Clients, um eine Identitätsverwaltung bereitzustellen, und kann mit einem oder mehreren bekannten Systemen wie z. B. dem Tivoli Federated Identity Manager (TFIM) System realisiert sein, das von der IBM Corporation mit Sitz in Armonk, New York, erhältlich ist. Unter geeigneten Umständen kann TFIM verwendet werden, um anderen Cloud-Komponenten F-SSO bereitzustellen. Die BSS-Komponente stellt bestimmte administrative Funktionen wie z. B. Fakturierungsunterstützung bereit. Die OSS-Komponente übernimmt das Bereitstellen und die Verwaltung der anderen Cloud-Komponenten wie z. B. Instanzen von virtuellen Maschinen (VMs). Die Cloud-Komponente steht für die primären Datenverarbeitungsressourcen, bei denen es sich üblicherweise um eine Vielzahl von VM-Instanzen handelt, die zum Ausführen der Zielanwendung 410 dienen, welche für einen Zugriff über die Cloud zugänglich gemacht wird. Eine oder mehrere Datenbanken dienen zum Speichern von Verzeichnis-, Protokoll- und anderen Arbeitsdaten. All diese Komponenten (einschließlich der Front-End-Identitätsverwaltungseinheit) befinden sich „innerhalb” der Cloud, obwohl dies nicht zwingend der Fall sein muss. Bei einer alternativen Ausführungsform kann die Identitätsverwaltungseinheit auch außerhalb der Cloud betrieben werden.
Lediglich beispielhaft handelt es sich bei einer in der Cloud bereitgestellten repräsentativen Unternehmensanwendung um eine Client-Server-Anwendung wie z. B. IBM^® LotusLive, die eine über die Cloud zur Verfügung gestellte Sammlung von Technologien bereitstellt, welche Web-Konferenz-, Nachrichtenübermittlungs- und Kooperationsdienste in einer einfach zu nutzenden Umgebung auf der Grundlage des Webs verbinden. Als Komponente von IBM^® LotusLive stellt LotusLive Notes^® eine umfassende eMail-, Kalender- und Kontaktverwaltung sowie Instant Messaging bereit. Ein Benutzer kann auf verschiedene Arten direkt über das Internet auf den Dienst zugreifen, z. B. mit einem Web-Browser oder einer Rich-Client-Anwendung (wie z. B. dem Notes Rich Client). Bei diesem Dienst verlagert ein Unternehmen seine eMail-, Kalender- und/oder Kooperationsinfrastruktur an den Cloud-Dienst, und ein Benutzer verwendet den Notes-Client, um auf seine eMail zuzugreifen, eine Kalenderoperation durchzuführen oder eine Online-Zusammenarbeit zu ermöglichen. Bei einer repräsentativen Ausführungsform liegt der Notes Rich Client in der Version 8.5.2 oder höher vor.
Das obige Beispiel (unter Verwendung von LotusLive) hat lediglich repräsentativen Charakter. Die im Folgenden beschriebenen Methoden sind nicht auf eine Verwendung mit einer bestimmten Unternehmensanwendung beschränkt, die innerhalb der Cloud-Umgebung bereitgestellt wird.
5 veranschaulicht eine repräsentative Ausführungsform der Anwendung bei ihrer Bereitstellung. Bei dieser Ausführungsform weist der Cloud-Anbieter 500 einen Satz von gemeinsamen Verwaltungsplattformkomponenten auf. Diese Komponenten beinhalten eine oder mehrere Instanzen der Identitätsverwaltungseinheit 502, der Cloud-BSS-Funktion 504 und der Cloud-OSS-Funktion 506, die alle weiter oben mit Blick auf 4 beschrieben wurden. Die Cloud-Datenverarbeitung 508 weist die VM-Instanzen auf, welche die Datenverarbeitungsinfrastruktur einschließlich des von der Anwendung verwendeten Speichers 510 bereitstellen. In diesem Beispiel weist ein Satz von gemeinsamen Verwaltungsplattformkomponenten zudem ein Modul pam_Idap 507 auf, das ein Mittel für Linux- oder UNIX-Server und Arbeitsplatzrechner bereitstellt, um ihre Identität gegenüber LDAP-Verzeichnissen nachzuweisen, ein Verzeichnisintegrationsmodul (TDI) 509, das Identitätsdaten, die in verschiedenen Verzeichnissen, Datenbanken, Dateien, Kooperationssystemen und Anwendungen vorliegen, umwandelt und synchronisiert, einen LDAP-Verzeichnisdienst 512 und einen (nicht abgebildeten) Sicherheits-Token-Dienst. Der Sicherheits-Token-Dienst verwendet sichere Nachrichtenübermittlungsmechanismen von Web Services Trust (WS-Trust), um zusätzliche Erweiterungen für die Ausgabe, den Austausch und die Bestätigung von Sicherheits-Token zu definieren. WS-Trust ist ein OASIS-Standard, der die Kompatibilität von Sicherheits-Token ermöglicht, indem er ein Anfrage-Antwort-Protokoll definiert. Mit dem WS-Trust-Protokoll kann ein Web-Dienst-Client eine vertrauenswürdige Stelle um den Austausch eines bestimmten Sicherheits-Tokens bitten. Hierfür bildet ein WS-Trust-Client 511 einen Bestandteil der gemeinsamen Verwaltung und stellt, wie abgebildet, (über einen kundenseitigen WS-Trust-Client) eine Schnittstelle zu einem Kunden-LDAP 514 bereit. Die externen Daten des Kunden werden in einer Datenbank 520 unterstützt. Die gemeinsame Verwaltungsplattform beinhaltet auch ein Datenarchiv 505, eine Protokolldatenbank 517 und ein gemeinsam genutztes LDAP 515. Der Client-Zugriff wird über einen Web-Browser 501 oder einen Rich Client bereitgestellt, d. h. eine Maschine, die einen Direktzugriffs-Client wie z. B. CIFS unterstützt. Wie gezeigt, stellt die Identitätsverwaltungskomponente 502 in der Regel über HTTPS eine Schnittstelle zu der Cloud-Datenverarbeitungsinfrastruktur bereit, während der Rich Client über CIFS eine Schnittstelle zu dem Speicher 510 bereitstellt.
Für Benutzer mit einem vom Cloud-Anbieter 500 verwalteten Benutzernamen und Kennwort kann die F-SSO-SAML-Zusicherung den Benutzernamen und das Kennwort oder lediglich einen Benutzernamen beinhalten; in beiden Fällen stellt der Cloud-Anbieter dem Benutzer eine einfache Interaktion bereit, um ein Cloud-seitiges Kennwort für den Zugriff auf Cloud-Dienste festzulegen. Danach verfügt der Benutzer über ein Konto, das im Cloud-LDAP 512 angelegt wurde und als ein Benutzer mit „lokaler Identitätsprüfung” gekennzeichnet ist, wobei auch das Kennwort des Benutzers durch das LDAP verwaltet wird. Wenn der Benutzer versucht, auf den Speicher 510 zuzugreifen, fängt das Modul pam_Idap 507 den Benutzernamen und das Kennwort ab und versucht, sie zu bestätigen. Hierbei ist ein Proxy (wie z. B. das TDI 509) der Empfänger dieser Bestätigungsanforderung für den Benutzernamen und das Kennwort. Der Proxy stellt zunächst fest, ob es sich um einen lokalen Benutzer handelt (dessen Identität somit lokal geprüft wird); wenn dies der Fall ist, versucht der Proxy, eine Bestätigung des Benutzernamens und Kennworts durch das lokale LDAP 512 zu erhalten. Wenn es sich nicht um einen „lokalen” Benutzer handelt, erzeugt der Proxy dagegen eine WS-Trust-Anforderung und fordert unter Verwendung des WS-Trust-Clients 511 vom Identitätsanbieter des Benutzers (Kunden-LDAP 514) die Bestätigung des Benutzerkennworts an. Bei dieser Herangehensweise muss der Cloud-Anbieter nicht notwendigerweise das Kennwort eines Benutzers verwalten, kann dies jedoch für diejenigen Kunden übernehmen, die keine vollständige Proxy-Lösung implementieren möchten. Die Verwendung von WS-Trust im obigen Beispiel hat lediglich repräsentativen Charakter.
Plug-In-Modell zur Identitäts- und Berechtigungsprüfung
Vor dem Hintergrund der obigen Informationen wird nun der Erfindungsgegenstand beschrieben. Auch wenn die Cloud-Datenverarbeitung viele Vorteile bietet, haben Cloud-Kunden, die ihre Unternehmensanwendungen innerhalb einer Cloud-Umgebung bereitstellen möchten, – wie oben erwähnt – erhebliche Bedenken bezüglich der Datensicherheit. Wie die Bereitstellung aus 5 veranschaulicht, werden die externen Daten 520 des Kunden gegenüber dem Anbieter des Cloud-Datenverarbeitungsdienstes zwangsläufig offengelegt. Unversehrtheit, Vertraulichkeit und Schutz der Geschäftsdaten können daher nicht hundertprozentig sichergestellt werden.
Der hier dargelegte Erfindungsgegenstand befasst sich mit diesem Problem und löst es.
Wie im Folgenden erläutert und in 6 gezeigt, kann der beschriebene Erfindungsgegenstand mehrere Einheiten umfassen. Eine erste Einheit 600 ist der Cloud-Dienstanbieter, der den Cloud-Dienst, welcher mitunter auch als die Cloud-Datenverarbeitungsumgebung bezeichnet wird, herstellt und aufrechterhält. Im Allgemeinen weist diese Umgebung einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen auf, wie sie z. B. in 4 veranschaulicht sind. Eine zweite Einheit ist der Cloud-Kunde 602, bei dem es sich üblicherweise um ein Unternehmen handelt, das einen Teilsatz der konfigurierbaren Ressourcen vermietet, um die Ausführung einer Kundenanwendung, die ganz oder teilweise von dem Cloud-Dienst bereitgestellt wird, in der Cloud zu ermöglichen. Der Cloud-Kunde wird mitunter auch als „Nutzer” oder „Klient” des von dem Cloud-Anbieter bereitgestellten Cloud-Dienstes bezeichnet. Die zweite Einheit in dem in 5 bereitgestellten Beispiel ist ein Unternehmen (z. B. eine Geschäftseinheit), das seine Anwendung (in diesem Beispiel Lotuslive) oder Teile davon in der Cloud ausführen lassen möchte. Eine dritte Einheit 604 ist ein Notardienst, bei dem es sich um eine Einheit handelt, die von der Cloud-Diensteinheit 600 und den Cloud-Kunden (wie z. B. dem Kunden 602) getrennt und unabhängig ist. Der Notar kann eine Regierungsstelle sein, die geschaffen wurde, um eine notarielle Funktion bereitzustellen, oder es kann sich um eine öffentliche oder private Einheit handeln. Der Cloud-Dienstanbieter und/oder ein Cloud-Kunde können mit dem Notar zusammenarbeiten, wobei die Kontrolle über den Notar jedoch vorzugsweise außerhalb der anderen Einheiten des Systems angesiedelt ist. Durch diese Trennung der Kontrolle kann der Notar unabhängig vom Cloud-Dienstanbieter 600 einerseits und den Cloud-Kunden 602 andererseits agieren. Die grundlegende Aufgabe des Notardienstes besteht darin, die Umsetzung der Ressourcengruppe(n), die dem Kunden 602 durch den Dienstanbieter 600 zugeordnet wurden, zu verwalten und insbesondere sicherzustellen, dass diese Ressourcengruppe(n) mit Ausnahme von bestimmten, vom Notar umgesetzten Bedingungen nicht für andere Einheiten (oder für den gemeinsam genutzten Pool im Allgemeinen) freigegeben werden können.
Wie oben beschrieben, fungiert der Notardienst 604 als Zertifizierungsstelle (oder, allgemeiner gesprochen, als maßgebender Dritter), die – vorzugsweise auf automatisierte Art und Weise – eine Vereinbarung zwischen dem Kunden 602, dem Cloud-Anbieter 600 und dem Notar testieren kann. Neben anderen Vorkehrungen regelt die Vereinbarung, dass die dem Cloud-Kunden 602 zugewiesene(n) Ressourcengruppe(n) (d. h. die Cloud-Ressourcen) nur unter bestimmten Bedingungen zur Verwendung durch einen anderen Kunden freigegeben werden dürfen. Eine solche Bedingung ist z. B. dann gegeben, wenn sowohl der Cloud-Umgebungsadministrator (eine Person oder ein automatisierter Prozess, der dem Cloud-Dienstanbieter 600 zugehörig ist) als auch der Cloud-Kundenadministrator sich anmelden, um die Freigabe derartiger Cloud-Ressourcen zu genehmigen, wobei dies weiter daran geknüpft ist, dass die Inhalte (z. B. die Geschäftsdaten des Kunden) vor einer derartigen Freigabe gelöscht werden. Ein weiteres Beispiel für eine solche Bedingung ist der Empfang einer Anmeldung eines zulässigen notariellen Benutzers (einer Person oder eines automatisierten Prozesses, die/der dem Notar 604 zugehörig ist) und des Cloud-Umgebungsadministrators, was z. B. der Fall sein kann, wenn der Kunde einer Verpflichtung, die sich aus der Cloud-Dienstvereinbarung ergibt, nicht nachkommt. Auch bei diesem letztgenannten Szenario ist die Freigabe der Ressourcengruppe jedoch an die Löschung der Daten des (nun ehemaligen) Kunden geknüpft.
Die Herangehensweise unter Einbindung des Notardienstes stellt sicher, dass der Cloud-Umgebungsadministrator nicht einseitig dem Kunden zugeordnete Ressourcen zurücknehmen und/oder für den Kunden sensible Daten einsehen kann, selbst wenn der Kunde die Dienstvereinbarung verletzt und als Kunde ausscheidet.
Gemäß einem weiteren Aspekt dieser Offenbarung wird ein Plug-In-Modell zur Identitäts- und Berechtigungsprüfung innerhalb der Cloud-Datenverarbeitungsumgebung realisiert. Dies wird in 7 veranschaulicht. Dieses Plug-In-Sicherheitsmodell ersetzt oder ergänzt das derzeitige Sicherheitsparadigma, das, wie oben mit Blick auf 5 dargelegt, die Anwendungsdaten des Kunden unter Umständen Sicherheitsrisiken aussetzt. Unter diesem im 7 veranschaulichten Aspekt stellt der Cloud-Dienstanbieter 700 dem Kunden 702 (in dieser Figur als der „Klient” bezeichnet) eine Möglichkeit bereit, sein eigenes Identitäts- und/oder Berechtigungsprüfungsmodul 705 einzubringen. Wie oben erwähnt, beinhaltet das System auch den Notar 704, der die Erstellung und Umsetzung von Vereinbarungen (jeweils abgebildet als eine Nutzungsüberlassung 708) ermöglicht. Eine Nutzungsüberlassung 708 ist einem isolierten Ressourcenbereich (Ressourcen-Sandbox) 710 zugehörig, bei dem es sich um einen Satz von einem oder mehreren Ressourcen aus einem gemeinsam genutzten Pool handelt. Das Identitäts- und/oder Berechtigungsprüfungsmodul 705 erzwingt die betreffenden Identitäts- und/oder Berechtigungsprüfungsfunktionen, die der Kunde realisiert haben möchte, auch wenn die Anwendung selbst in der Cloud bereitgestellt wird. Anders ausgedrückt: Die eigenen Identitäts- und/oder Berechtigungsprüfungsschemata des Kunden werden in der Cloud umgesetzt, ohne dass der Cloud-Dienstanbieter hieran direkt beteiligt ist. Zu diesem Zweck ermöglicht der Plug-In-Dienst 703 des Cloud-Anbieters, dass das Modul 705 in den Cloud-Dienst eingeklinkt wird, wobei der Zugriff des Cloud-Anbieters auf das Modul 705 jedoch beschränkt ist. Insbesondere werden dem Cloud-Dienstanbieter keine Superuser-Rechte (oder andere Rechte für den Zugriff auf das Cloud-System) eingeräumt; vielmehr wird der Zugriff auf die Daten des Kunden über das Modul 705 umgesetzt, und der Cloud-Umgebungsadministrator ist nicht bei dem Benutzerregister (oder einer gleichwertigen Einheit) registriert, das sich innerhalb des Moduls 705 befindet oder diesem zugehörig ist. Der Cloud-Dienstanbieter ordnet dem Administrator des Cloud-Kunden eine Ressourcengruppe zu (oder eine derartige Ressourcengruppe wird bei der Registrierung des Moduls automatisch zugeordnet), wobei der Dienstanbieter jedoch nicht – aufgrund der Architektur des Plug-In-Moduls im Allgemeinen und durch das Sperren einer Benutzerregistrierung im Besonderen – daran gehindert wird, einen genehmigten Zugriff auf die Daten des Kunden zu erhalten. Somit ist der Cloud-Umgebungsadministrator nicht in der Lage, auf die dem Cloud-Kunden zugeordneten Ressourcen zuzugreifen.
Die Laufzeitsicherheitsfunktion des Cloud-Betriebssystems (Plattform) ruft bei Bedarf das Identitäts- und Berechtigungsprüfungsmodul 705 auf. Um diese Plug-In-Architektur zu unterstützen, stellt der Cloud-Dienst eine Anwendungsprogrammschnittstelle (Application Programming Interface, API) 707 bereit. Die API 707 realisiert ein PAM-Schema (Pluggable Authentication Modules), bei dem es sich um eine bekannte Methode zum Einbinden mehrerer untergeordneter Identitätsprüfungsschemata (z. B. das Modul 705) in eine übergeordnete API handelt. Durch PAM können Programme, die eine Identitätsprüfung benötigen, unabhängig von einem darunterliegenden Identitätsprüfungssystem geschrieben werden. Für weitere Einzelheiten zu PAM wird auf das Dokument „Open Software Foundation Request for Comment (RFC) 86.0” vom Oktober 1995 verwiesen. Ein alternativer Ansatz besteht darin, eine in das Betriebssystem einbindbare Sicherheitsfunktion wie z. B. Module, die in den Kern des Linux-Betriebssystems ladbar sind, oder dergleichen zu verwenden. Zudem kann eine beliebige andere Plug-In-Architektur verwendet werden.
8 ist ein Blockschaubild, das veranschaulicht, wie der Notardienst 804 mit dem Cloud-Dienstanbieter 800 und dem Cloud-Nutzer 802 interagiert. Dabei wird der Notardienst vorzugsweise als ein automatisierter elektronischer Prozess oder ein Satz von Prozessen realisiert, der innerhalb einer Datenverarbeitungsumgebung ausgeführt wird. Er kann eine(n) oder mehrere Maschinen, Server, Anwendungen, Prozesse, Programme und Dienstprogramme aufweisen. Der Notardienst 804 ist einer PKI 806 zugehörig (oder hat Zugriff darauf), die bekannte Public-Key-Verschlüsselungsprotokolle und Methoden wie digitale Signaturen, Public-Key-Zertifikate, Public-Key-Verschlüsselungssysteme und dergleichen realisiert oder umsetzt. Wie in 8 veranschaulicht, ermöglicht (makelt) der Notardienst 804 ein sicheres, nicht bestreitbares Protokoll für eine digitale Signatur, durch das eine Vereinbarung 810 abgeschlossen wird. Durch die Verwendung der bekannten PKI-Schemata kann die Vereinbarung 810 weder vom Cloud-Anbieter 800 noch vom Cloud-Nutzer 802 bestritten werden. Der Notardienst 804 verwaltet die abgeschlossene Vereinbarung in einem Datenspeicher, wobei der Notar vorzugsweise als einzige Einheit (neben dem Cloud-Anbieter 800 und dem Nutzer 802) dazu berechtigt ist, die Bedingungen der Vereinbarung durchzusetzen oder offenzulegen. Um die Vereinbarung auf diese Weise zu erstellen, zu verwalten und durchzusetzen, können verschiedene bekannte Verschlüsselungsprotokolle und -schemata verwendet werden.
Insbesondere wird bei der Bereitstellung ein Nutzer einem eindeutigen PKI-Zertifikat zugeordnet. Die PKI-Infrastruktur 806 interagiert während des Prozesses der Zertifikatbereitstellung für den Nutzer mit dem Notar 804, um eine Zuordnung zwischen dem Nutzer und dem PKI-Zertifikat des Nutzers herzustellen. Diese Zuordnung wird auf sichere Art und Weise hergestellt. Wenn für den Notar 804 die Notwendigkeit entsteht, die Vereinbarung oder einen Nachweis darüber (z. B. gegenüber einem Gericht) bereitzustellen, ermöglicht das PKI-System einem Gericht (oder einer anderen berechtigten staatlichen Stelle oder Vollzugsbehörde), die Zuordnung zwischen dem Nutzer und dem PKI-Zertifikat des Nutzers zu überprüfen, um so die nicht bestreitbare Herkunft der Originalsignaturen, mit denen die Vereinbarung abgeschlossen wurde, nachzuweisen. Die PKI-Mechanismen stellen sicher, dass der Nutzer die sichere Zuordnung und insbesondere seine Signatur auf dem Dokument (bei der es sich üblicherweise um eine digitale Signatur handelt) nicht abstreiten kann.
Vor dem Hintergrund der obigen Informationen und bezugnehmend auf 9 werden im Folgenden verschiedene Nutzungsszenarien beschrieben. Diese Szenarien haben lediglich repräsentativen Charakter.
Der Cloud-Dienstanbieter verfügt über einen Cloud-Umgebungsadministrator, der Kunden, die Anwendungen in der Cloud-Umgebung bereitstellen, eine oder mehrere Ressourcengruppen zuordnet. Eine Ressourcengruppe weist einen Satz von einer oder mehreren Cloud-Datenverarbeitungsressourcen auf, wobei derartige Ressourcen von recht unterschiedlicher Art sein können. Typischerweise weisen die Ressourcen Prozessoren (CPUs), Festplattenlaufwerke (DASD) und Arbeitsspeicher auf. Wenn ein Kunde eine Anwendung bereitstellt (Schritt 900), ordnet der Cloud-Umgebungsadministrator der Anwendung und den Daten des Kunden eine Ressourcengruppe zu (z. B. Prozessoren, Speicher und Arbeitsspeicher). In Schritt 902 registriert der Kunde sein Sicherheitsmodul zur Identitäts- und Berechtigungsprüfung bei dem Cloud-Sicherheitsdienst. Wie oben beschrieben, wird anhand dieses kundenspezifischen Sicherheitsmoduls dann kontrolliert, welche Personen oder Einheiten auf Daten zugreifen können, die der bereitgestellten Anwendung zugehörig sind. Der Cloud-Umgebungsadministrator ist jedoch nicht (als zugelassener Benutzer) bei dem Sicherheitsmodul des Kunden registriert; somit ist der Cloud-Umgebungsadministrator nicht in der Lage, auf die dem Cloud-Kunden zugewiesenen Ressourcen (obwohl er diese Ressourcen selbst zugewiesen hat) oder die zugehörigen Geschäftsdaten zuzugreifen (bzw. sie für andere oder für den allgemeinen Ressourcen-Pool der Cloud freizugeben). In Schritt 904 registriert sich der Nutzer bei dem Notar, und in Schritt 906 wird die sichere Vereinbarung ausgehandelt (abgeschlossen). Die Reihenfolge der obigen Schritte hat lediglich repräsentativen Charakter, und ein oder mehrere dieser Schritte können gleichzeitig oder in einer anderen Reihenfolge durchgeführt werden. Unter der Voraussetzung, dass ihre Identität und/oder Berechtigung durch das kundenspezifische Sicherheitsmodul überprüft und bestätigt wurde, wird in Schritt 908 den Endbenutzern, die dem Cloud-Nutzer zugehörig sind, erlaubt, auf die Anwendung zuzugreifen und sie zu verwenden.
Ein alternatives Szenario beginnt, indem der Nutzer eine Ressourcenanforderung an den Cloud-Dienstanbieter stellt. Als Reaktion darauf bereitet der Cloud-Dienstanbieter einen Vertrag vor, der dann von dem Nutzer, dem Anbieter und dem Notar digital unterzeichnet wird. Sobald der Vertrag unterzeichnet ist, weist der Dienstanbieter dem Klienten die Ressource zu, woraufhin der Klient über die Plug-In-Dienstschnittstelle seinen Identitäts- und Berechtigungsprüfungsmechanismus einrichtet. Da der Klient die Ressourcengenehmigung lediglich für den Zugriff durch den Klienten einrichtet, können nur Endbenutzer, die ihre Identität über das Plug-In-Modul nachweisen können, auf die Ressource zugreifen. Wie erwähnt, ist dem Anbieter ein derartiger Zugriff verwehrt. Wenn zu einem späteren Zeitpunkt der Klient die Vereinbarung verletzt oder der Vertrag ausläuft, bittet der Dienstanbieter den Notar um die Genehmigung, dem Klienten die Ressource zu entziehen. Der Notar erteilt daraufhin dem Dienstanbieter die Genehmigung, die Ressource zurückzunehmen, und der Dienstanbieter löscht die Daten des Kunden und stellt die Ressource wieder in den gemeinsam genutzten Pool zurück (bzw. weist sie einem anderen Klienten zu). Bei einer Alternative zu dem Standardszenario kann der Klient selbst die Ressource aufgeben, indem er eine der Ressource zugewiesene Genehmigung (in seinem Sicherheitsmodul) entfernt. Sobald der Dienstanbieter in einem solchen Fall darüber benachrichtigt wird, dass der Klient selbst die Genehmigung zurückgenommen hat, kann er in eingeschränktem Maße zu berechtigt sein, eine Standardgenehmigung für die Ressource zuzuweisen. Diese Standardbereitstellung kann den Dienstanbieter dann in die Lage versetzen, auf seine eigene Ressource zuzugreifen, z. B. für eine Verwaltungs- oder anderweitige Unterstützungstätigkeit.
Die Vereinbarung zwischen den beteiligten Einheiten stellt sicher, dass die Geschäftsdaten des Nutzers sicher bleiben. So regelt die zwischen dem Nutzer und dem Dienstanbieter abgeschlossene Vereinbarung neben anderen Vorkehrungen z. B., dass die dem Cloud-Kunden zugewiesene(n) Ressourcengruppe(n) (d. h. die Cloud-Ressourcen) nur unter bestimmten Bedingungen zur Verwendung durch einen anderen Kunden freigegeben werden dürfen. Eine solche Bedingung ist z. B. dann gegeben, wenn sowohl der Cloud-Umgebungsadministrator als auch der Cloud-Kundenadministrator sich anmelden, um die Freigabe zu genehmigen, wobei dies weiter daran geknüpft ist, dass die Inhalte (z. B. die Geschäftsdaten des Kunden) vor einer derartigen Freigabe gelöscht werden. Ein weiteres Beispiel für eine solche Bedingung ist der Empfang einer Anmeldung eines zulässigen notariellen Benutzers und des Cloud-Umgebungsadministrators, was z. B. der Fall sein kann, wenn der Kunde einer Verpflichtung, die sich aus der Cloud-Dienstvereinbarung ergibt, nicht nachkommt. Auch bei diesem Szenario ist die Freigabe der Ressourcengruppe jedoch an die Löschung der Daten des (nun ehemaligen) Kunden geknüpft.
Wenn sich der Klient also dazu entschließt, die Cloud-Nutzung nicht mehr fortzusetzen, werden seine Kundendaten aus dem Anbieterspeicher des Anbieters gelöscht, bevor die Nutzungseinwilligung für den Dienst zurückgenommen oder beendet wird, wobei diese Erneuerung oder Beendigung nur mit vorheriger Genehmigung des Notars erfolgen kann. Diese Genehmigung wird vorzugsweise sicher und auf eine Art und Weise erhalten, die nicht durch eine der an der Transaktion beteiligten Parteien bestritten werden kann.
Wenn der Cloud-Dienstanbieter von einem Dritten aufgekauft wird, kann sich der Nutzer entscheiden, ob er die Cloud-Verwendung unter dem neuen Eigentümer fortsetzen möchte, ohne sich dabei Sorgen machen zu müssen, dass seine Daten preisgegeben werden. Der neue Eigentümer hat nur dann Zugriff auf die Daten, wenn der Nutzer eine derartige Genehmigung über das ausschließlich vom Nutzer verwaltete und kontrollierte Sicherheitsmodul erteilt.
Das Plug-In-Sicherheitsmodell und die Verwendung des unabhängigen Notardienstes stellen sicher, dass die Daten des Unternehmenskunden sicher sind. Das Plug-In-Modell gestattet dem Cloud-Datenverarbeitungskunden, die Kontrolle über seine Unternehmensdaten zu behalten, wenn er seine Unternehmensanwendung und -daten in der Cloud bereitstellt. Das Notarmodell schützt die Vertraulichkeit und das Zugriffsrecht des Kunden, wenn seine Anwendungssoftware und seine Daten in der Cloud bereitgestellt werden.
Dabei kann die Methode in Zusammenhang mit einer öffentlichen Cloud, einer privaten Cloud oder einer (teils öffentlichen, teils privaten) Hybrid-Cloud verwendet werden.
Das Plug-In des Klienten (d. h. das Kundensicherheitsmodul) wird auf jeder zur Umsetzung genutzten Maschine installiert. Wie aus den obigen Beispielszenarien hervorgeht, kann das Plug-In vor oder nach dem Aushandeln des Vertrags installiert werden. Wie in 7 gezeigt, kann selbstverständlich eine beliebige Anzahl von Klienten die Methode gleichzeitig verwenden, vorausgesetzt, dass die Klienten daran gehindert werden, auf die Ressource anderer Klienten zuzugreifen. Hierfür stellt der Cloud-Anbieter die Ressourcen, die einem bestimmten Klienten zugeordnet (und einer bestimmten Vereinbarung zugehörig) sind, in einen isolierten Bereich (Sandbox).
Im beschriebenen Beispiel ist das Kundensicherheitsmodul für einen bestimmten Kunden spezifisch, obwohl dies nicht notwendigerweise der Fall sein muss. Bei einem alternativen Szenario stellt der Dienstanbieter selbst ein Sicherheitsmodul zur Verfügung, das er an den Klienten „vermietet”. Unabhängig davon, ob der Klient oder der Anbieter das Sicherheitsmodul bereitstellt, ist es – wie oben beschrieben – der Client, der (durch ein korrektes Zuordnen von berechtigten Benutzern zu Ressourcen) kontrollieren sollte, welche seiner Benutzer in der Lage sind, (über das Sicherheitsmodul) auf die ausgehandelten Cloud-Ressourcen zuzugreifen.
Bei der obigen Ausführungsform wird die Vereinbarung mittels PKI umgesetzt, wodurch eine Nichtbestreitbarkeit erzielt wird. Allerdings stellt dies keine Beschränkung dar, da auch andere Methoden verwendet werden können, um die Vereinbarung umzusetzen. So kann bei einer alternativen Ausführungsform zu diesem Zweck z. B. eine andere konkrete Einheit verwendet werden. Diese (analog zu einem ordentlichen Gericht) als „Gerichtseinheit” bezeichnete Einheit hat ihr eigenes Paar von öffentlichen/privaten Schlüsseln sowie ein digitales Zertifikat. Die Vereinbarung kann dann wie folgt abgeschlossen werden. Der Nutzer verschlüsselt den Text der Vereinbarung anhand seines geheimen Schlüssels. Der Cloud-Anbieter verschlüsselt dieselbe Vereinbarung anhand seines geheimen Schlüssels. Danach unterzeichnet die Gerichtseinheit eine Vereinigung der beiden verschlüsselten Dokumente. Um die Vereinbarung zu überprüfen, wird der umgekehrte Prozess durchgeführt. Insbesondere verwendet das Gericht seinen öffentlichen Schlüssel, um seine Signatur in dem vereinten Dokument (d. h. den beiden verschlüsselten Vereinbarungen) zu überprüfen. Danach verwendet das Gericht den öffentlichen Schlüssel des Anbieters, um den ersten Teil des vereinten Dokuments zu entschlüsseln, und den öffentlichen Schlüssel des Nutzers, um den zweiten Teil des vereinten Dokuments zu entschlüsseln. Im Anschluss daran legt die Gerichtseinheit dem Notar die beiden Dokumente vor.
Unterstützungsdienste für die Cloud-Ressourcen können durch den Dienstanbieter oder den Kunden bereitgestellt werden. So kann z. B. während des Zeitraums der Nutzungsüberlassung und wenn der Nutzer die vollständige Kontrolle über die Maschine hat, der Klient etwaige notwendige Wartungsarbeiten (z. B. Software-Korrekturen) durchführen, wobei dies eventuell unter Anleitung durch den Anbieter stattfindet. Wenn der Klient die Maschine oder die darin enthaltenen Ressourcen aufgibt (indem er sein Sicherheitsmodul entfernt oder die Zugriffsrichtlinie ändert), kann der Anbieter mit herkömmlichen Sicherungs-/Wiederherstellungsfunktionen eine Ressource in einem bekannten funktionierenden Zustand wiederherstellen. Falls gewünscht, kann der Klient auch sein eigenes virtuelles Betriebssystemabbild installieren und verwalten; alternativ dazu, kann der Anbieter dem Klienten ein zeitlich begrenztes Betriebssystemabbild bereitstellen, das der Klient während der Dauer der Nutzungsüberlassung aktualisieren kann.
Wenn die Nutzungsüberlassung endet (z. B. durch Ablauf der Dauer oder bei einem Verstoß des Klienten), nimmt der Anbieter die Ressourcen zurück, indem er das Sicherheits-Plug-In des Kunden entfernt (oder verhindert, dass der Kunde ein beliebiges allgemeines Modul nutzt, das möglicherweise in Verwendung ist). Als Folge hiervon und da der Anbieter im Besitz der Ressource ist, wird ein standardmäßiger Sicherheitsmechanismus bzw. werden standardmäßige Sicherheitsmechanismen aktiviert, wodurch der Anbieter den vollen Zugriff zurückerhält. Während der Dauer der Vereinbarung verhindert das Sicherheits-Plug-In, dass der Anbieter auf eine beliebige, der Vereinbarung unterliegende Ressource zugreift. Obwohl dies nicht erforderlich ist, wird dem Notar und/oder dem Klienten vorzugsweise eine Benachrichtigung bereitgestellt, falls der Anbieter versucht, vereinbarungswidrig auf die Ressourcen zuzugreifen (oder eine andere unangemessene Handlung in diesem Zusammenhang vorzunehmen). Vielmehr muss der Anbieter zunächst eine entsprechende Genehmigung von dem Notar einholen. Sobald eine solche Genehmigung erhalten wurde, kann der Anbieter den Zugriff des Klienten wie beschrieben aufheben.
Um die Rückgabe der Datenverarbeitungsressourcen zu ermöglichen, kann der Notar über einen „Schlüssel” (oder einen ähnlichen Mechanismus) verfügen, der das Plug-In bei Bedarf deinstalliert. Insbesondere stellt der Notar bei einem Verstoß durch den Klienten dem Dienstanbieter den Schlüssel (oder ein Zertifikat) bereit, um ihm zu ermöglichen, die Ressourcen in den gemeinsam genutzten Pool zurückzustellen. Allerdings ist die Verwendung eines derartigen Schlüssels nicht immer notwendig. Wenn der Klient z. B. lediglich die Hardware- und Betriebssystemressourcen des Anbieters nutzt und erst später den Vertrag verletzt, muss der Anbieter (sobald eine Genehmigung von dem Notar vorliegt) nur die Daten des Klienten sichern und anschließend die betroffene Festplatte neu starten und formatieren. Für den Fall, dass der Klient auch seine eigene virtuelle Maschine installiert und dann zu einem späteren Zeitpunkt den Vertrag verletzt, kann der Anbieter (sobald eine Genehmigung vorliegt) auf den Hypervisor (auf dem die VM ausgeführt wird) zugreifen und die VM entfernen. In diesen Fällen behält der Anbieter ausreichend Zugriff auf die darunter liegenden Ressourcen, um den Entfernungsvorgang zu ermöglichen, obwohl er unter keinen Umständen Zugriff auf Anwendungen innerhalb der virtuellen Maschinen des Klienten hat.
Im Gegensatz dazu entfernt ein korrekt handelnder Klient das Sicherheits-Plug-In selbsttätig (z. B. wenn die Vereinbarung endet).
Der beschriebene Erfindungsgegenstand hat zahlreiche Vorteile. Bei der Herangehensweise gibt der Cloud-Kunde die Kontrolle über seine Unternehmensdaten nicht auf, wenn er die Cloud-Umgebung abonniert. Die Herangehensweise stellt sicher, dass der Cloud-Umgebungsadministrator (oder eine andere nicht berechtigte Person oder Einheit) keine dem Kunden zugeordneten Ressourcengruppen (oder – allgemeiner gesprochen – eine oder mehrere Cloud-Ressourcen) zurücknehmen kann, ohne dass eine Genehmigung des Kunden oder eines berechtigten Dritten, der dem Notardienst zugehörig ist, eingeholt wurde. Auf diese Weise hat der Cloud-Kunde die vollständige Kontrolle über seine Daten in der Cloud-Datenverarbeitungsumgebung, und es besteht kein wesentliches Risiko, dass ein Cloud-Administrator oder eine andere Einheit ohne Genehmigung oder Befugnis auf die Daten des Kunden zugreifen kann. Wenn der Cloud-Dienstanbieter von einem neuen Cloud-Unternehmen aufgekauft wird und sogar, wenn Hardware-Ressourcen gestohlen werden, bleiben die Daten des Kunden geschützt, da ein Zugriff auf diese Daten und ihre Anzeige nur über das kundeneigene Sicherheits-Plug-In zur Identitäts- und Berechtigungsprüfung möglich ist (d. h. indem die Identitäts- und Berechtigungsprüfungen des Kunden bestanden werden). Vorzugsweise hat weder der Cloud-Administrator noch eine andere Person oder Einheit eine Superuser-Kennung für das Betriebssystem der Cloud-Umgebung, um auf Kundendaten zuzugreifen oder sie anderweitig zu verwalten.
Der Notardienst stellt weitere Vorzüge bereit. Wie erwähnt, hilft der Notardienst dabei sicherzustellen, dass die Daten des Kunden sicher bleiben, da er zur Umsetzung einer Vereinbarung (zwischen dem Kunden, dem Cloud-Anbieter und dem Notar) dient, die sicherstellt, dass die Ressourcen, in denen sich die Daten befinden, nur unter bestimmten Bedingungen freigegeben werden können. Wenn die eine Partei gegen die Vereinbarung verstößt, kann die andere Partei den Vertrag über den Notar widerrufen, wobei dieser als unabhängige Zertifizierungsstelle dient, die den Vertrag testieren kann. Diese Herangehensweise stellt sicher, dass der Cloud-Umgebungsadministrator nicht einseitig dem Kunden zugeordnete Ressourcen zurücknehmen und/oder für den Kunden sensible Daten einsehen kann, selbst wenn der Kunde die Dienstvereinbarung verletzt und als Kunde ausscheidet. Andererseits stellt die Verwendung des Notardienstes auch sicher, dass sich der Kunde keine unrechtmäßigen Vorteile von dem Cloud-Anbieter verschafft, indem er beispielsweise die Dienstvereinbarung des Anbieters verletzt und dennoch die Cloud-Dienste in Anspruch nimmt.
Die Methode stellt ein neues Sicherheitsparadigma für eine Cloud-Datenverarbeitung bereit, die den Schutz von Kundendaten sicherstellt. Kunden eines Cloud-Dienstes verwalten ihre eigenen Identitäts- und Berechtigungsprüfungs-Sicherheitsdienste, indem sie sich in das Plug-In-Modell der Cloud einklinken. Ein staatlicher oder Drittanbieter-Sicherheitsdienst (der Notar) überwacht die Ausführung der Sicherheitsrichtlinie innerhalb der Umgebung auf eine Art und Weise, welche die Interessen aller Beteiligten berücksichtigt.
Die oben beschriebene Plug-In- und Notardienst-Funktionalität kann als eigenständiger Ansatz realisiert sein, z. B. als eine Funktion auf der Grundlage von Software, die durch einen Prozessor ausgeführt wird, oder sie kann als ein verwalteter Dienst (z. B. als ein Web-Dienst über eine SOAP/XML-Schnittstelle) zur Verfügung gestellt werden. Die hier beschriebenen konkreten Einzelheiten der Hardware- und Software-Realisierung dienen lediglich zur Veranschaulichung und sind nicht als Beschränkung des inhaltlichen Geltungsumfangs des beschriebenen Erfindungsgegenstands zu verstehen.
Allgemeiner gesprochen, sind Datenverarbeitungseinheiten in Zusammenhang mit der offenbarten Erfindung jeweils ein Datenverarbeitungssystem wie das in 2 veranschaulichte, das Hardware und Software aufweist, wobei diese Einheiten über ein Netzwerk wie z. B. das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder ein(e) beliebige(s) andere(s) Datenübertragungsmedium oder -verbindung Daten austauschen. Die Anwendungen in dem Datenverarbeitungssystem stellen eine systemeigene Unterstützung für Web- und andere bekannte Dienste und Protokolle bereit, einschließlich, ohne darauf beschränkt zu sein, der Unterstützung für HTTP, FTP, SMTP, SOAP, XML, WSDL, SAML, Liberty, Shibboleth, OpenID, WS-Federation, Cardspace, WS-Trust, UDDI und WSFL. Informationen zu SOAP, WSDL, UDDI und WSFL sind vom World Wide Web Consortium (W3C) erhältlich, das für die Entwicklung und Pflege dieser Standards zuständig ist; weitere Informationen zu HTTP, FTP, SMTP und XML sind von der Internet Engineering Task Force (IETF) erhältlich. Die Vertrautheit mit diesen bekannten Standards und Protokollen wird vorausgesetzt.
Neben Cloud-basierten Infrastrukturen kann das hier beschriebene Schema auch in oder in Verbindung mit verschiedenen Server-seitigen Architekturen realisiert sein. Dazu gehören, ohne darauf beschränkt zu sein, einfache n-tier-Architekturen, Web-Portale, föderierte Systeme und dergleichen.
Wie in den obigen Beispielen veranschaulicht wird, können eine oder mehrere Plug-In- oder Notardienstfunktionen innerhalb oder außerhalb der Cloud bereitgestellt werden.
Noch allgemeiner gesprochen, kann der hier beschriebene Erfindungsgegenstand in Gestalt einer vollständig in Hardware realisierten Ausführungsform, einer vollständig in Software realisierten Ausführungsform oder einer Ausführungsform vorliegen, die sowohl Hardware- als auch Software-Elemente enthält. Bei einer bevorzugten Ausführungsform wird die mehrschichtige Abmeldefunktion als Software realisiert, einschließlich, ohne darauf beschränkt zu sein, Firmware, speicherresidente Software, Mikrocode und dergleichen. Die Daten können in einer Datenstruktur (z. B. einer Anordnung, einer verknüpften Liste usw.) konfiguriert und in einem Datenspeicher wie z. B. einem Computerspeicher gespeichert sein. Die hier beschriebene Instanzen-Erkennungsfunktionalität des Identitätsanbieters kann des Weiteren, wie oben erwähnt, in Gestalt eines Computerprogrammprodukts vorliegen, auf das über ein computernutzbares oder computerlesbares Medium zugegriffen werden kann, das Programmcode bereitstellt, der durch oder in Verbindung mit einem Computer oder einem beliebigen anderen System zur Befehlsausführung verwendet werden kann. Zum Zwecke dieser Beschreibung kann ein computernutzbares oder computerlesbares Medium jedwede Vorrichtung sein, die das Programm, welches durch oder in Verbindung mit dem Befehlsausführungssystem, der Befehlsausführungsvorrichtung oder -einheit verwendet wird, enthalten oder speichern kann. Das Medium kann ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem (oder eine entsprechende Vorrichtung bzw. Einheit) sein. Beispiele für ein computerlesbares Medium beinhalten einen Halbleiter- oder Festkörperspeicher, ein Magnetband, eine wechselbare Computerdiskette, einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), eine magnetische Festplatte und eine optische Platte. Gegenwärtige Beispiele für optische Festplatten beinhalten Compact Disk Read Only Memory (CD-ROM), Compact Disk Read/Write (CD-R/W) und DVD. Das computerlesbare Medium ist ein physischer Artikel.
Das Computerprogrammprodukt kann ein Produkt mit Programmbefehlen (oder Programmcode) sein, um eine oder mehrere der beschriebenen Funktionen zu realisieren. Diese Befehle bzw. dieser Code können/kann auf einem computerlesbaren Speichermedium in einem Datenverarbeitungssystem gespeichert sein, nachdem sie/er über ein Netzwerk von einem entfernt angeordneten Datenverarbeitungssystem heruntergeladen wurde(n). Alternativ können diese Befehle bzw. kann dieser Code auf einem computerlesbaren Speichermedium in einem Server-Datenverarbeitungssystem gespeichert und so gestaltet sein, dass sie/er über ein Netzwerk auf ein entfernt angeordnetes Datenverarbeitungssystem heruntergeladen werden können/kann, um auf einem computerlesbaren Speichermedium innerhalb des entfernt angeordneten Systems verwendet zu werden.
Bei einer repräsentativen Ausführungsform sind die Plug-In- und Notardienstkomponenten in einem Spezialcomputer und hier vorzugsweise in Form von Software realisiert, die durch einen oder mehrere Prozessoren ausgeführt wird. Für eine Verwendung darin vorgesehene zugehörige Daten sind in einem zugehörigen Datenspeicher gespeichert. Die Software wird zudem in einem oder mehreren Datenspeichern oder Speichern verwaltet, die dem einen oder den mehreren Prozessoren zugehörig sind, und ist als ein oder mehrere Computerprogramme realisierbar.
Die Plug-In-Funktion kann als ein Zusatz oder eine Erweiterung einer bestehenden Zugriffsmanager- oder Richtlinienverwaltungslösung realisiert sein.
Obwohl die obigen Ausführungen eine bestimmte Reihenfolge von Arbeitsschritten beschreiben, die durch bestimmte Ausführungsformen der Erfindung durchgeführt werden, sollte klar sein, dass eine derartige Reihenfolge lediglich beispielhaften Charakter hat, da alternative Ausführungsformen die Arbeitsschritte in einer anderen Reihenfolge durchführen, bestimmte Arbeitsschritte kombinieren, bestimmte Arbeitsschritte einander überschneiden lassen können usw. Wenn in der Patentschrift auf eine gegebene Ausführungsform Bezug genommen wird, bedeutet dies, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine Struktur oder ein kennzeichnendes Element enthält, wobei jedoch nicht notwendigerweise jede Ausführungsform das betreffende Merkmal, die Struktur oder das kennzeichnende Element enthält.
Auch wenn gegebene Komponenten des Systems getrennt beschrieben wurden, weiß der Fachmann abschließend, dass manche der Funktionen in gegebenen Befehlen, Programmabfolgen, Code-Teilen und dergleichen kombiniert oder gemeinsam genutzt werden können.
Im vorliegenden Kontext sollte die „Client-seitige” Anwendung im weitesten Sinne so verstanden werden, dass sie sich auf eine Anwendung, eine einer Anwendung zugehörige Seite oder eine anderweitige Ressource oder Funktion bezieht, die von einer Client-seitigen Anforderung an die Anwendung aufgerufen wird. Ein „Browser” ist im vorliegenden Kontext nicht als Bezugnahme auf einen bestimmten Browser (z. B. Internet Explorer, Safari, FireFox und dergleichen) gedacht, sondern sollte im weitesten Sinne so ausgelegt werden, dass er sich auf jede Client-seitige Wiedergabeeinheit bezieht, die auf über das Internet zugängliche Ressourcen zugreifen und diese anzeigen kann. Ein „Rich Client” bezieht sich typischerweise auf eine nicht auf HTTP beruhende Client-seitige Anwendung wie z. B. einen SSH- oder CFIS-Client. Obwohl des Weiteren die Client-Server-Interaktionen typischerweise unter Verwendung von HTTP erfolgen, stellt auch dies keine Beschränkung dar. Die Client-Server-Interaktion kann entsprechend dem Simple Object Access Protocol (SOAP) formatiert sein und unter Verwendung von HTTP (über das öffentliche Internet) oder FTP übertragen werden, oder es kann ein beliebiger anderer zuverlässiger Transportmechanismus (wie z. B. IBM^® MQSeries^® Technologien und CORBA für den Transport über ein Unternehmens-Intranet) zum Einsatz kommen. Jede hier beschriebene Anwendung oder Funktionalität kann als systemeigener Code realisiert sein, indem Programmeinstiegsmöglichkeiten in eine andere Anwendung bereitgestellt werden, indem die Verwendung des Mechanismus als Plug-In ermöglicht wird oder indem der Mechanismus verknüpft wird, usw.
Die hier vorkommende Bezeichnung „Plug-In” ist nicht als Beschränkung zu verstehen. Die von dem Plug-In bereitgestellte Grundfunktion besteht im Abfangen von Sicherheitsprüfungen. Somit ist das Plug-In allgemein gesprochen jeder Code, der so funktioniert, dass er Sicherheitsprüfungen abfängt.

Claims

Verfahren für eine Identitäts- und Berechtigungsprüfung in einer Umgebung, in der Datenverarbeitungsressourcen in einem gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen bereitgestellt werden, aufweisend: Empfangen einer Anforderung von einer ersten Einheit für den Zugriff auf den gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen, der durch eine zweite Einheit verwaltet wird; bei Abschluss einer Vereinbarung zwischen der ersten Einheit, der zweiten Einheit und einer dritten Einheit, die sich von der ersten Einheit und der zweiten Einheit unterscheidet, Zuweisen einer Ressourcengruppe zu der ersten Einheit; Registrieren eines der ersten Einheit zugehörigen Plug-In-Sicherheitsmoduls bei einem Plug-In-Dienst, der von der zweiten Einheit in Zusammenhang mit dem gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen betrieben wird; und Beschränken des Zugriffs auf die Ressourcengruppe, sofern er nicht über das Plug-In-Sicherheitsmodul erfolgt.
Verfahren nach Anspruch 1, des Weiteren aufweisend ein Empfangen und Speichern von Daten, welche berechtigten Benutzern der ersten Einheit zugehörig sind, in der Ressourcengruppe.
Verfahren nach Anspruch 2, des Weiteren aufweisend ein Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool bei Auftreten eines Ereignisses.
Verfahren nach Anspruch 3, wobei der Schritt des Zurückgebens der Ressourcengruppe aufweist: bei Auftreten des Ereignisses Ausgeben einer Anforderung an die Drittpartei, wobei mit der Anforderung die Genehmigung angefordert wird, die Zuordnung der ersten Einheit zu der Ressourcengruppe aufzuheben; und Empfangen einer Antwort von der Drittpartei, wobei die Antwort angibt, dass die zweite Einheit die Erlaubnis hat, die Zuordnung der ersten Einheit zu der Ressourcengruppe aufzuheben.
Verfahren nach Anspruch 4, des Weiteren aufweisend ein Löschen der Daten, die berechtigten Benutzern der ersten Einheit zugehörig sind, vor dem Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool.
Verfahren nach Anspruch 3, wobei der Schritt des Zurückgebens der Ressourcengruppe aufweist: Empfangen eines Hinweises darauf, dass eine der Ressourcengruppe zugehörige Genehmigung durch die erste Einheit zurückgenommen wurde; und Löschen der Daten, die einem berechtigten Benutzer der ersten Einheit zugehörig sind, vor dem Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool.
Verfahren nach Anspruch 1, wobei die Vereinbarung kryptografisch geschützt ist, so dass sie weder durch die erste Einheit noch durch die zweite Einheit zurückgewiesen werden kann.
Vorrichtung für eine Identitäts- und Berechtigungsprüfung in einer Umgebung, in der Datenverarbeitungsressourcen in einem gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen bereitgestellt werden, aufweisend: einen Prozessor; Computerspeicher mit Computerprogrammbefehlen, die bei Ausführung durch den Prozessor ein Verfahren durchführen, aufweisend: Empfangen einer Anforderung von einer ersten Einheit für den Zugriff auf den gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen, der durch eine zweite Einheit verwaltet wird; bei Abschluss einer Vereinbarung zwischen der ersten Einheit, der zweiten Einheit und einer dritten Einheit, die sich von der ersten Einheit und der zweiten Einheit unterscheidet, Zuweisen einer Ressourcengruppe zu der ersten Einheit; Registrieren eines der ersten Einheit zugehörigen Plug-In-Sicherheitsmoduls bei einem Plug-In-Dienst, der von der zweiten Einheit in Zusammenhang mit dem gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen betrieben wird; und Beschränken des Zugriffs auf die Ressourcengruppe, sofern er nicht über das Plug-In-Sicherheitsmodul erfolgt.
Vorrichtung nach Anspruch 8, wobei das Verfahren des Weiteren ein Empfangen und Speichern von Daten, welche berechtigten Benutzern der ersten Einheit zugehörig sind, in der Ressourcengruppe aufweist.
Vorrichtung nach Anspruch 8, wobei das Verfahren des Weiteren ein Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool bei Auftreten eines Ereignisses aufweist.
Vorrichtung nach Anspruch 10, wobei der Schritt des Zurückgebens der Ressourcengruppe aufweist: bei Auftreten des Ereignisses Ausgeben einer Anforderung an die Drittpartei, wobei mit der Anforderung die Genehmigung angefordert wird, die Zuordnung der ersten Einheit zu der Ressourcengruppe aufzuheben; und Empfangen einer Antwort von der Drittpartei, wobei die Antwort angibt, dass die zweite Einheit die Erlaubnis hat, die Zuordnung der ersten Einheit zu der Ressourcengruppe aufzuheben.
Vorrichtung nach Anspruch 11, wobei das Verfahren des Weiteren ein Löschen der Daten, die berechtigten Benutzern der ersten Einheit zugehörig sind, vor dem Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool aufweist.
Vorrichtung nach Anspruch 10, wobei der Schritt des Zurückgebens der Ressourcengruppe aufweist: Empfangen eines Hinweises darauf, dass eine der Ressourcengruppe zugehörige Genehmigung durch die erste Einheit zurückgenommen wurde; und Löschen der Daten, die einem berechtigten Benutzer der ersten Einheit zugehörig sind, vor dem Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool.
Vorrichtung nach Anspruch 8, wobei die Vereinbarung kryptografisch geschützt ist, so dass sie weder durch die erste Einheit noch durch die zweite Einheit zurückgewiesen werden kann.
Computerprogrammprodukt auf einem computerlesbaren Medium zur Verwendung in einem Datenverarbeitungssystem für eine Identitäts- und Berechtigungsprüfung in einer Umgebung, in der Datenverarbeitungsressourcen in einem gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen bereitgestellt werden, wobei das Computerprogrammprodukt Computerprogrammbefehle enthält, die bei Ausführung durch das Datenverarbeitungssystem ein Verfahren durchführen, aufweisend: Empfangen einer Anforderung von einer ersten Einheit für den Zugriff auf den gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen, der durch eine zweite Einheit verwaltet wird; bei Abschluss einer Vereinbarung zwischen der ersten Einheit, der zweiten Einheit und einer dritten Einheit, die sich von der ersten Einheit und der zweiten Einheit unterscheidet, Zuweisen einer Ressourcengruppe zu der ersten Einheit; Registrieren eines der ersten Einheit zugehörigen Plug-In-Sicherheitsmoduls bei einem Plug-In-Dienst, der von der zweiten Einheit in Zusammenhang mit dem gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen betrieben wird; und Beschränken des Zugriffs auf die Ressourcengruppe, sofern er nicht über das Plug-In-Sicherheitsmodul erfolgt.
Computerprogrammprodukt nach Anspruch 15, wobei das Verfahren des Weiteren ein Empfangen und Speichern von Daten, welche berechtigten Benutzern der ersten Einheit zugehörig sind, in der Ressourcengruppe aufweist.
Computerprogrammprodukt nach Anspruch 16, wobei das Verfahren des Weiteren ein Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool bei Auftreten eines Ereignisses aufweist.
Computerprogrammprodukt nach Anspruch 17, wobei der Schritt des Zurückgebens der Ressourcengruppe aufweist: bei Auftreten des Ereignisses Ausgeben einer Anforderung an die Drittpartei, wobei mit der Anforderung die Genehmigung angefordert wird, die Zuordnung der ersten Einheit zu der Ressourcengruppe aufzuheben; und Empfangen einer Antwort von der Drittpartei, wobei die Antwort angibt, dass die zweite Einheit die Erlaubnis hat, die Zuordnung der ersten Einheit zu der Ressourcengruppe aufzuheben.
Computerprogrammprodukt nach Anspruch 18, wobei das Verfahren des Weiteren ein Löschen der Daten, die berechtigten Benutzern der ersten Einheit zugehörig sind, vor dem Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool aufweist.
Computerprogrammprodukt nach Anspruch 17, wobei der Schritt des Zurückgebens der Ressourcengruppe aufweist: Empfangen eines Hinweises darauf, dass eine der Ressourcengruppe zugehörige Genehmigung durch die erste Einheit zurückgenommen wurde; und Löschen der Daten, die einem berechtigten Benutzer der ersten Einheit zugehörig sind, vor dem Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool.
Computerprogrammprodukt nach Anspruch 15, wobei die Vereinbarung kryptografisch geschützt ist, so dass sie weder durch die erste Einheit noch durch die zweite Einheit zurückgewiesen werden kann.
In einem gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen betriebene Vorrichtung, aufweisend: einen Prozessor; Computerspeicher mit Computerprogrammbefehlen, die durch den Prozessor ausgeführt werden, um (i) eine Anwendungsprogrammschnittstelle (Application Programming Interface, API) bereitzustellen, die erste und zweite Sicherheitsmodule als Plug-Ins empfängt, wobei das erste Sicherheitsmodul einem ersten Klienten des gemeinsam genutzten Pools von konfigurierbaren Datenverarbeitungsressourcen zugehörig ist, wobei das zweite Sicherheitsmodul einem zweiten Klienten des gemeinsam genutzten Pools von konfigurierbaren Datenverarbeitungsressourcen zugehörig ist, und um (ii) jedem der ersten und zweiten Klienten erste und zweite Ressourcengruppen zuzuordnen, wobei der Zugriff auf die erste Ressourcengruppe untersagt ist, sofern keine Genehmigung durch das erste Sicherheitsmodul vorliegt, wobei der Zugriff auf die zweite Ressourcengruppe untersagt ist, sofern keine Genehmigung durch das zweite Sicherheitsmodul vorliegt.
Vorrichtung nach Anspruch 23, wobei die Computerprogrammbefehle durch den Prozessor ausgeführt werden, um (iii) eine Ressourcengruppe bei einem gegebenen Geschehnis an den gemeinsam genutzten Pool zurückzugeben.
Vorrichtung nach Anspruch 23, wobei das gegebene Geschehnis ein Empfang eines Hinweises von einem Drittanbieter-Notar ist, der für die Rückgabe der Ressourcengruppe bürgt.
Vorrichtung nach Anspruch 24, wobei die Computerprogrammbefehle durch den Prozessor ausgeführt werden, um (iv) alle klientenspezifischen Daten vor einem Zurückgeben der Ressourcengruppe an den gemeinsam genutzten Pool zu löschen.
Einem gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen zugehörige Vorrichtung, wobei der gemeinsam genutzte Pool durch einen Dienstanbieter betrieben wird und eine Ressourcengruppe beinhaltet, die gemäß einer Vereinbarung zwischen dem Dienstanbieter, dem Nutzer und einem Dritten, der die Vorrichtung verwaltet, einem Nutzer zur Verwendung zugeordnet wurde, wobei als ein Ergebnis der Vereinbarung dem Nutzer ein Plug-In-Sicherheitsmodul zugehörig ist und dazu verwendet wird, den Zugriff auf die Ressourcengruppe zu beschränken, sofern er nicht über das Plug-In-Sicherheitsmodul erfolgt, wobei die Vorrichtung aufweist: einen Prozessor; Computerspeicher mit Computerprogrammbefehlen, die durch den Prozessor ausgeführt werden, um die Vereinbarung umzusetzen, indem (i) eine Anforderung von dem Dienstanbieter empfangen wird, bei einem gegebenen Ereignis die Zuordnung des Nutzers zu der Ressourcengruppe aufzuheben, und (ii) eine Antwort an den Dienstanbieter auszugeben, die angibt, dass der Dienstanbieter die Erlaubnis hat, die Zuordnung des Nutzers zu der Ressourcengruppe aufzuheben.