-
Die
vorliegende Erfindung bezieht sich auf eine Rechneranordnung (nachfolgend
alternativ auch als Rechnernetzwerk bezeichnet) mit automatisierter
Zugriffssteuerung von und mit automatisierter Zugriffskontrolle
auf eine oder mehrere Applikation(en). Die vorliegende Erfindung
bezieht sich darüber
hinaus auf ein entsprechendes Zugriffssteuerungs- und Zugriffskontrollverfahren.
-
Heutige
Rechnernetzwerke überschreiten, insbesondere
beim sog. Grid-Computing, die Grenzen von einzelnen Organisationen
bei der Benutzung von Rechenressourcen. Die Nutzung von reiner Rechenzeit
und von Speicherplatz findet heutzutage häufig nicht mehr nur innerhalb
einer einzelnen Organisation, sondern auch bei anderen Organisationen, also
durch die eigene Organisation bei Dritten statt. Hierdurch treten
Fragestellungen zu Tage, wie die Zugriffssteuerung und die Zugriffskontrolle
auf Applikationen bei fremden Organisationen bzw. Dritten automatisch
ermöglicht
werden kann. Es ist insbesondere zu klären, in wiefern Lizenzen in
einem solchen Rechnernetzwerk bzw. im Grid-Umfeld benutzt werden können. Unter
einer Lizenz wird hierbei eine Erlaubnis eines Rechners der eigenen
Organisation (Anwenderrechner) und/oder eines Anwenders innerhalb
der eigenen Organisation zum Zugriff auf ein Anwendungsprogramm
bzw. eine Applikation, welche(s) auf einem anderen Rechner, insbesondere
auf einem Ressourcenrechner, der von einer anderen Organisation
innerhalb des Rechnernetzwerkes zur Verfügung gestellt wird, installiert
ist, verstanden. Lizenzen erlauben somit den Zugriff auf entfernt
installierte Applikationen.
-
Grundsätzlich sind
zwei Szenarien denkbar:
- 1. Der Anwender nutzt
Lizenzen, die außerhalb der
eigenen Organisation, also beim Ressourcenprovider bzw. auf einem
entsprechenden Ressourcenrechner, vorhanden sind.
- 2. Der Anwender bringt eigene Lizenzen mit zum Ressourcenprovider
bzw. zum Ressourcenrechner.
-
Die
gegenwärtig
im Stand der Technik verwendeten automatisierten Zugriffssteuerungs-
und Zugriffskontrollverfahren sehen dabei verschiedene Lizenzierungsmodelle
vor, deren Realisierungen wie folgt zusammen gefasst werden können:
- 1. Eine Software bzw. Applikation wird mit
einer sog. Node-Lock-Lizenz versehen, d. h. die Applikation wird
an einen festen Rechner gebunden und kann nur dort benutzt werden.
Diese Lizenzform erlaubt lediglich eine Nutzung vor Ort, d. h. in Bezug
auf Grid-Computing kann ein Anwender lediglich vorinstallierte Lizenzen
verwenden. Eine Mitnahme einer eigenen Lizenz zum Ressourcenprovider
ist somit nicht möglich.
- 2. Eine zweite technische Realisierung der Lizenzierung stellt
die sog. Floating-Lizenz dar: Ein zentraler Server wird beim Lizenznehmer
eingerichtet und mit der Anzahl der Lizenzen bzw. anderen Vorgaben
konfiguriert. So fragt bei jeder auszuführenden Aufgabe (beispielsweise:
Berechnungsjob) die Applikation (z. B. Simulations- oder Berechnungssoftware)
bei diesem Zentralserver an, ob momentan eine freie Lizenz verfügbar ist.
Ist dies der Fall, kann diese Lizenz für die aktuell abzuarbeitende
Aufgabe benutzt werden. Ist keine freie Lizenz verfügbar, so
wird die Aufgabe nicht abgearbeitet.
- 3. Eine dritte Lizenzierungsform ist unter dem Namen „Named
User” bekannt:
Hierbei wird der Zugriff auf eine Applikation nur bestimmten Benutzern
gestattet. Dabei wird die Applikation oft an den lokalen Benutzernamen
gekoppelt.
-
Offensichtlich
ist eine Node-Lock-Lizenz nur für
Ressourcenanbieter möglich,
die eine feste Anzahl von Lizenzen für die Nutzung im Grid bereitstellen.
Ein Anwender kann hier nicht seine eigene Lizenz übermitteln.
Eine Nutzung einer Floating-Lizenz ist prinzipiell möglich. Die
Lizenz kann beim Jobstart entweder von einem Lizenzserver des Anwenders oder
des Ressourcenbetreibers abgerufen werden, unterliegt jedoch einigen
Einschränkungen:
- 1. Der Lizenzserver muss vom Ort der Berechnung
aus erreichbar sein, damit beim Jobstart die Lizenz freigegeben
werden kann. Dies ist je nach Konfiguration der Netzwerkumgebung
des Ressourcenproviders nicht gegeben und vor Beginn des Rechenjobs
auch nicht unbedingt überprüfbar.
- 2. Zum Start des Rechenjobs muss der entsprechende Lizenzserver
auch tatsächlich
eine Lizenz vorhalten. Sollte ein Job keine Lizenz vorfinden, so
wird er sich beenden, ohne die Berechnung durchzuführen. Unter
Umständen
verliert der Anwender so diejenige Zeit, die der Job in einer Batchqueue
gewartet hat. Eventuell fallen auch Kosten für die Reservierung der Ressourcen
an.
-
Im
Falle einer ”Named
User”-Lizenz
muss die Identität
eines Benutzers überprüft werden.
Dabei ergibt sich im Grid-Umfeld jedoch das Problem der Delegation:
Der lokale Benutzer ist nicht notwendigerweise auch der Benutzer,
der den Job abgeschickt hat. Im Prinzip wäre es möglich, den ursprünglichen
Benutzer über
sein Zertifikat beim Abschicken eines Jobs zu ermitteln – diese
Funktionalität
ist jedoch in keiner Grid-Middleware
vorgesehen und daher nicht einfach zu implementieren.
-
Ausgehend
vom Stand der Technik ist es daher die Aufgabe der vorliegenden
Erfindung, eine Rechneranordnung für die automatisierte Zugriffssteuerung
und/oder Zugriffskontrolle von Applikationen zur Verfügung zu
stellen, in welcher einfach, schnell, auf genau definierte Art und
Weise und mit einem hohen Schutz gegen die Umgehung der Zugriffssteuerung
bzw. Zugriffskontrolle die Steuerung des Zugriffs auf eine oder
mehrere Applikationen durch an die Rechneranordnung angeschlossene Anwenderrechner
bzw. durch an der Rechneranordnung tätige Anwender möglich ist.
Aufgabe der vorliegenden Erfindung ist es darüber hinaus, ein entsprechendes
automatisiertes Zugriffssteuerungs- und Zugriffskontrollverfahren zur Verfügung zu
stellen.
-
Diese
Aufgabe wird durch die Rechneranordnung gemäß Patentanspruch 1 sowie durch
das Zugriffssteuerungs- und
Zugriffskontrollverfahren gemäß Patentanspruch
16 gelöst.
Vorteilhafte Ausgestaltungsformen der erfindungsgemäßen Rechneranordnung
bzw. des erfindungsgemäßen Verfahrens lassen
sich dabei den jeweiligen abhängigen
Ansprüchen
entnehmen. Vorteilhafte Verwendungen einer solchen Anordnung oder
eines solchen Verfahrens sind in den Verwendungsansprüchen beschrieben.
-
Nachfolgend
wird die vorliegende Erfindung zunächst allgemein beschrieben
und dann anhand eines allgemein gehaltenen Ausführungsbeispiels vorgestellt.
Dem schließt
sich ein spezielles Ausführungsbeispiel,
in dem eine konkrete Implementierung bzw. Ausgestaltung eines erfindungsgemäßen Rechnernetzwerkes
bzw. Zugriffssteuerungs- und Zugriffskontrollverfahrens beschrieben
ist, an.
-
Die
konkrete Kombination der einzelnen Merkmale, wie sie in dem allgemeinen
und dem speziellen Ausführungsbeispiel
beschrieben ist, ist für die
Ausführung
der Erfindung nicht unbedingt notwendig, d. h. im Rahmen der vorliegenden
Erfindung können
einzelne Merk male der gezeigten Kombination gemäß den unabhängigen Patentansprüchen auch
in anderen Kombinationen verwirklicht werden bzw. realisiert sein.
-
Eine
erfindungsgemäße Rechneranordnung mit
automatisierter Zugriffssteuerung von einer und Zugriffskontrolle
auf eine Applikation weist eine Anwenderkomponente, eine zum bidirektionalen
Datenaustausch mit der Anwenderkomponente ausgebildete Lizenzserverkomponente
und eine zum bidirektionalen Datenaustausch mit der Anwenderkomponente
ausgebildete Ressourcenkomponente, die eine Applikation steuert,
die als Teil einer Applikation ausgebildet ist oder auf der eine
Applikation installiert ist, auf. Selbstverständlich sind dabei in der Regel
jeweils mehrere Anwenderkomponenten entsprechend mit der Lizenzserverkomponente
und der (oder auch den mehreren) Ressourcenkomponente(n) verbunden.
Erfindungsgemäß ist auf
Basis von der Anwenderkomponente auf Basis von ersten Eingabedaten für die Applikation
und/oder von Hardware-Merkmalen der Anwenderkomponente ein Lizenzdeskriptor generierbar.
Dieser Lizenzdeskriptor ist dann an die Lizenzserverkomponente übermittelbar
und durch letztere dahingehend überprüfbar, ob
eine Zugriffsberechtigung der Anwenderkomponente, eines Anwenders
und/oder der ersten Eingabedaten auf die Applikation gegeben ist.
Bei Vorliegen einer solchen Zugriffsberechtigung ist dann von der
Lizenzserverkomponente ein den Zugriff auf die Applikation ermöglichender
Lizenztoken generierbar und an die Anwenderkomponente übermittelbar.
Durch die Anwenderkomponente sind dann der Lizenztoken (oder auf
diesem basierende Lizenzinformationen) sowie zweite Eingabedaten
für die
Applikation an die Ressourcenkomponente übermittelbar. Der Lizenztoken (oder
die Lizenzinformationen) ist/sind dann durch die Ressourcenkomponen te
und/oder die Applikation dahingehend überprüfbar, ob die Zugriffsberechtigung
der Anwenderkomponente, des Anwenders und/oder der zweiten Eingabedaten
auf die Applikation gegeben ist. Ist dies der Fall, dann kann die
Applikation die ihr übermittelten
zweiten Eingabedaten verwenden, also beispielsweise mit diesen Eingabedaten
Berechnungen durchführen
und die Ergebnisse dieser Berechnungen an die Anwenderkomponente
zurück übermitteln.
-
In
der Regel werden dabei die ersten Eingabedaten mit den zweiten Eingabedaten
identisch sein (diese Daten werden daher nachfolgend meist auch vereinfacht
als Eingabedaten ohne weitere Spezifikation bezeichnet). Es ist
jedoch auch denkbar, dass der Anwender zunächst basierend auf ersten Eingabedaten
für die
Applikation einen Lizenzdeskriptor generiert, diesen dann an die
Lizenzserverkomponente übermittelt
und den dann auf Basis der ersten Eingabedaten generierten und zurück übermittelten Lizenztoken
empfängt.
Der Anwender kann dann die ersten Eingabedaten (beispielsweise wenn
er feststellt, dass noch zusätzliche
Berechnungen notwendig sind) durch andere für die Applikation geeignete Eingabedaten
(zweite Eingabedaten) austauschen und diese dann, zusammen mit dem
Lizenztoken (der einen solchen Austausch in diesem Falle zulässt) an
die die eigentlichen Berechnungen durchführende Ressourcenkomponente übermitteln.
-
Die
erfindungsgemäße Rechneranordnung kann
insbesondere im Bereich der Simulation von technischen Systemen
eingesetzt werden: Bei der Simulation solcher Systeme (z. B. bei
der Simulation von medizinischen Röntgensystemen oder auch Therapiesystemen,
beispielsweise Strahlentherapiesystemen) sind häufig bei der virtuellen Abbildung des
entsprechenden techni schen Systems in einem Rechnersystem eine Vielzahl
von Berechnungen (z. B. Monte Carlo-Simulationsrechnungen oder ähnliches)
notwendig, die, damit der Anwender nicht zu lange auf die Rechenergebnisse
warten muss, auf mehrere einzelne Ressourcenkomponenten verteilt werden
müssen.
-
Wie
dem Fachmann unmittelbar klar ist, können die einzelnen Komponenten
je nach konkreter Systemanforderung sowohl als Software-Elemente, als
auch als Hardware-Elemente, oder als Software- und Hardware-Elemente ausgebildet
sein. Wird von einem Client oder von einem Server gesprochen, so ist
dies z. B. nicht einschränkend
dahingehend zu verstehen, dass der Client als Software ausgebildet sein
muss und der Server als Hardware (so kann beispielsweise ein Client
als reine Software-Lösung
realisiert sein, es kann sich dabei jedoch auch um ein Rechnersystem
mit entsprechend installierten Komponenten handeln, usw.).
-
In
der Regel werden die einzelnen Komponenten, also die Anwenderkomponente(n),
die Ressourcenkomponente(n) und die Lizenzserverkomponente jeweils
auf getrennten, separaten Einzelrechnern installiert sein (bzw.
als entsprechende Einzelrechner ausgebildet sein). Es ist jedoch
alternativ dazu auch möglich,
mehr als eine Komponente auf ein und demselben Einzelrechner (z.
B. PC) auszubilden: So können
beispielsweise eine Anwenderkomponente und eine Ressourcenkomponente
auf einem gemeinsamen Anwender- und Ressourcenrechner installiert
sein. Ebenso ist es denkbar, die Lizenzserverkomponente und eine
Ressourcenkomponente auf einem gemeinsamen Lizenzserver- und Ressourcenrechner
auszubilden. Im ersten Fall ist dann die Lizenzserverkomponente
auf einem Lizenzser ver getrennt vom Anwender- und Ressourcenrechner
ausgebildet. Im zweiten Fall ist dann mindestens eine Anwenderkomponente
getrennt vom Lizenzserver- und Ressourcenrechner auf einem separaten
Einzelrechner ausgebildet, der dann über ein Netzwerk (beispielsweise
das Internet) mit dem gemeinsamen Lizenzserver- und Ressourcenrechner verbunden ist.
-
Im
Rahmen der weiteren Beschreibung der Erfindung werden daher nachfolgend
die folgenden Synonyme verwendet (jede Nummer bezeichnet synonym
verwendete Ausdrücke):
- 1. Rechneranordnung, Rechnernetzwerk, Grid-Umgebung
und Grid-Umfeld;
- 2. Anwenderkomponente, Anwenderrechner, Anwender, Lizenznehmer,
Client, Anwenderclient und Benutzerclient;
- 3. Lizenzserverkomponente, Lizenzserver, Lizenzgeber und Hersteller
einer Applikation bzw. Software;
- 4. Ressourcenkomponente, Ressourcenrechner, Ressourcenprovider,
Ressourcenanbieter und Berechnungsbackend;
- 5. Lizenztoken, Token und Lizenz.
-
Bei
der vorliegenden Erfindung werden die Lizenztoken somit vorteilhafterweise
je nach Bedarf erzeugt und in den entsprechenden Dateien gespeichert,
d. h. sie können
auf andere Rechner transferiert werden. Dabei ist, wie nachfolgend
noch beschrieben wird, kein Missbrauch zu befürchten. Es sind die folgenden Einsatzszenarien
realisierbar:
- 1. Der Lizenztoken wird an eine
Eingabedatei für eine
Applikation gekoppelt. Die Lizenz bezieht sich dabei bevorzugt auf
die Verwendung der Applikation mit genau dieser Eingabedatei (wie
vorbeschrieben, ist es jedoch auch möglich, die Lizenz auf Verwendung
der Applikation mit anderen, gegebenenfalls ausgetauschten oder
ergänzten
Eingabedaten zu beziehen). Beispielsweise können Batch-Programme als Eingabedatei
verwendet werden.
- 2. Daneben (oder auch zusätzlich)
kann das erfindungsgemäße System
auch zur dynamischen Zuweisung von Floating-Lizenzen verwendet werden.
Dabei wird die Lizenz nicht an eine Eingabedatei, sondern an die
lokale Hardware gebunden. So kann beispielsweise ein Benutzer eines Pre-Processing
Tools für
ein Simulationsprogramm für
eine Dienstreise eine Lizenz für
sein Notebook erstellen, welche dann an die Hardware des Notebooks
(CPU-ID, MAC-Adresse etc.) gebunden ist.
-
Im
Folgenden wird die vorliegende Erfindung zunächst anhand der Verknüpfung von
Lizenzen mit den Eingabedaten beschrieben. Danach werden kurz die
notwendigen Anpassungen für
Hardware-gebundene Lizenzen beschrieben. Es folgt ein spezielles Ausführungsbeispiel
mit einem konkreten Systementwurf sowie mit einer konkreten Umsetzung.
-
Es
zeigen:
-
1 eine
erfindungsgemäße Rechneranordnung,
bei der die Anwenderkomponente, die Lizenzser verkomponente und die
Ressourcenkomponente jeweils als separate Einzelrechner realisiert sind
(und daher auch so bezeichnet werden) in Übersicht;
-
2 ein
Beispiel für
einen Lizenzdeskriptor;
-
3 die
Architektur eines konkret implementierten Lizenzdienstes in einem
erfindungsgemäßen Rechnernetzwerk;
-
4 eine
konkrete Implementierung eines Lizenzdeskriptors.
-
1 zeigt
ein Beispiel für
den grundlegenden Aufbau eines erfindungsgemäßen Rechnernetzwerkes mit automatisierter
Zugriffssteuerung und Zugriffskontrolle. Das Netzwerk weist einen
als PC 1PC ausgebildeten Anwenderrechner 1 auf
(der die Anwenderkomponente bildet), der zum bidirektionalen Datenaustausch
mit einem als PC 2PC ausgebildeten Lizenzserver 2 (der
die Lizenzserverkomponente bildet) ausgebildet ist (Pfeile oben).
Darüber
hinaus ist der Anwenderrechner 1 auch zum bidirektionalen Datenaustausch
mit einem als PC 3PC ausgebildeten Ressourcenrechner 3,
der die Ressourcenkomponente bildet, ausgebildet (Pfeile unten im
Bild). Auf dem Ressourcenrechner ist eine Applikation 4 installiert,
hier ein Simulationsprogramm, welches auf Basis von Eingabedaten
Simulationsrechnungen durchführt.
-
In 1 ist
lediglich ein Anwenderrechner 1 gezeigt, es ist jedoch
selbstverständlich
auch möglich,
eine Vielzahl entsprechend ausgebildeter Anwenderrechner jeweils
zum bidirektionalen Datenaustausch mit dem Lizenzserver zu verbinden.
Darüber
hinaus ist es ebenso möglich,
eine Vielzahl von Ressourcenrechnern 3 statt des lediglich
einen gezeigten Ressourcenrechners zur Verfügung zu stellen, mit denen
dann die Anwenderrechner jeweils zum bidirektionalen Datenaustausch
verbindbar sind. Ein Anwenderrechner kann dabei mit mehreren Ressourcenrechnern
verbunden werden oder umgekehrt.
-
Im
Anwenderrechner 1 sind Eingabedaten 5 gespeichert,
die so ausgebildet sind, dass die Applikation 4 mit ihnen
zum Start einer Simulationsrechnung und zum Übermitteln der entsprechenden
Simulationsergebnisse veranlasst werden kann. Aus diesen Eingabedaten 5 generiert
der Anwenderrechner 1 einen Lizenzdeskriptor 7.
Dies geschieht im vorliegenden Fall dadurch, dass der Anwenderrechner 1 aus
den Eingabedaten 5 einen kryptographischen Code in Form
eines Hash-Codes berechnet. Dieser berechnete Code wird dann zusammen
mit Anwenderidentifikationsdaten, die der Identifikation des Anwenderrechners 1 und
eines an ihm tätigen Anwenders 1a dienen,
zu dem Lizenzdeskriptor zusammen gefasst.
-
Alternativ
oder kumulativ dazu ist es jedoch auch möglich, dass der Anwenderrechner 1 basierend
auf Hardware-Merkmalen 6 des Anwenderrechners und/oder
Informationen über
den Anwender 1a (beispielsweise auf Basis einer CPU-Identifikationsnummer
der CPU des Anwenderrechners oder einer MAC-Adresse des Anwenderrechners)
einen kryptographischen Code in Form eines Hash-Codes berechnet.
Ebenso wie vorbeschrieben, kann dann dieser kryptographische Code
mit Anwenderidentifikationsdaten zum Lizenzdeskriptor zusammen gefasst werden.
-
Zudem
werden dem Lizenzdeskriptor Daten hinzugefügt, die notwendig sind, um
dem Lizenzserver 2 zu ermöglichen, festzustellen, ob
für die
entsprechenden Eingabedaten 5 eine Zugriffsberechtigung
des Anwenderrechners (bzw. des Anwenders) auf die Applikation 4 gegeben
ist.
-
Im
vorliegenden Fall wird lediglich der aus den Eingabedaten 5 berechnete
Hash-Code vom Anwenderrechner 1 an den Lizenzserver 2 übermittelt. Es
ist jedoch auch möglich,
zusätzlich
zu diesem Hash-Code auch die Eingabedaten 5 selbst an den Lizenzserver 2 zu übermitteln
(so dass diese dann für weitere
Prüfungen
etc. verwendet werden können).
-
Der
Lizenzdeskriptor 7 wird dann an den Lizenzserver 2 übermittelt,
der die vorbeschriebene Zugriffsberechtigung überprüft. Ist eine entsprechende
Zugriffsberechtigung gegeben (was der Lizenzserver 2 z.
B. anhand einer vorab gespeicherten Tabelle mit Anwenderrechner-
oder Kundendaten und Daten zur der Applikation 4 überprüfen kann),
so verschlüsselt
der Lizenzserver 2 den Lizenzdeskriptor 7 kryptographisch
mit einem geheimen Schlüssel
einer Public-Key-Infrastruktur (beispielsweise einer X.509-basierten
Public-Key-Infrastruktur) und bildet mittels dieser Verschlüsselung
aus dem gegebenenfalls geeignet angepassten oder ergänzten Lizenzdeskriptor 7 einen
Lizenztoken 8. Da eine entsprechende Zugriffsberechtigung
auf die Applikation 4 gegeben ist, wird dieser Lizenztoken 8 anschließend vom Lizenzserver 2 zurück an den
Anwenderrechner 1 übertragen.
Im Anwenderrechner 1 werden dann die zum Start der Simulationsrechnungen
mittels der Applikation 4 zu verwendenden Eingabedaten 5' mit auf dem
Lizenztoken 8 basierenden Lizenzinformationen 8' verbunden und
an den Ressourcenrechner 3 übermittelt. Im vorliegenden
Fall werden vom Anwender des Anwenderrechners 1 diejenigen
Eingabedaten zum Start des Simulationsvorganges der Applikation 4 vorgesehen,
aus denen auch der Hash-Code des Lizenzdeskriptors berechnet wurde.
Die Daten 5 entsprechen also den Daten 5' (Datengleichheit
ist in der Figur durch 5' = 5 gekennzeichnet).
Auch wird der Lizenztoken 8 selbst als diejenige Lizenzinformation 8' verwendet,
die an den Ressourcenrechner 3 übertragen wird. Dies ist durch 8' = 8 gekennzeichnet.
-
Der
vom Anwenderrechner 1 an den Ressourcenrechner 3 übermittelte
Lizenztoken 8 wird dann durch die Applikation 4 im
Ressourcenrechner 3 dahingehend überprüft, ob eine Zugriffsberechtigung
der Eingabedaten 5 des Anwenderrechners 1 auf
die Applikation 4 gegeben ist. Hierzu wird der Lizenztoken 8 durch
die Applikation mittels des öffentlichen
Schlüssels
der oben erwähnten
Public-Key-Infrastruktur (der vom Lizenzserver zur Verfügung gestellt
wird und bereits im Ressourcenrechner 3 abgespeichert wurde)
zunächst
entschlüsselt
und dann entsprechend geprüft.
Zusätzlich
wird durch den Ressourcenrechner (oder auch durch die Applikation selbst)
ein kryptographischer Code in Form eines Hash-Codes auf dieselbe
Art und Weise aus den Eingabedaten 5 berechnet wie im Anwenderrechner 1. Dieser
im Ressourcenrechner 3 berechnete Hash-Code wird dann mit
dem Hash-Code verglichen, der im Lizenzdeskriptor 7 zunächst vom
Anwenderrechner 1 an den Lizenzserver 2 und dann
im verschlüsselten
Lizenzdeskriptor, also im Lizenztoken 8, vom Lizenzserver 2 über den
Anwenderrechner 1 an den Ressourcenrechner 3 übermittelt
wurde. Nur wenn diese beiden Hash-Codes übereinstimmen (und nach erfolgreicher
Entschlüsselung
und Überprüfung des
Lizenztokens 8 mit dem öffentlichen Schlüssel), startet
die Applikation 4 mit den übermittelten Eingabedaten 5 ihre
Simulationsrechnung. Die durch die Applikation aus den Eingabedaten 5 berechneten
Ausgabedaten 9 (Simulationsergebnisse) werden dann vom
Ressourcenrechner 3 an den Anwenderrechner 1 übertragen.
-
Im
beschriebenen Fall geschieht die bidirektionale Datenübertragung
zwischen den Einheiten 1, 2 und 3 im Rahmen des erfindungsgemäßen Rechnernetzwerkes über das
Internet. Es kann jedoch selbstverständlich auch ein lokales Rechnernetzwerk (Intranet
innerhalb einer Organisation) eingesetzt werden.
-
Im
Rahmen des beschriebenen Ausführungsbeispiels
ist es auch möglich,
dass der Lizenzdeskriptor 7 vom Anwenderrechner 1 mit
einer vom Anwender gewünschten
Dauer für
die Lizenz für
die Applikation 4 generiert wird. Der Lizenzdeskriptor 7 wird
dann mit dieser Information an den Lizenzserver 2 übertragen,
der feststellt, ob eine gewünschte
Lizenzdauer möglich
ist (dies kann beispielsweise anhand eines Anwenderkontos eines
Anwenders 1 auf dem Lizenzserver 2 geschehen).
Der Lizenztoken 8 wird dann vom Lizenzserver 2 mit
einer entsprechend festgesetzten Lizenzdauer generiert. Die Lizenzdauer
ist dabei so definiert, dass mit ihr dem Ressourcenrechner 3 letztendlich
ein Zeitfenster übermittelt wird,
während
dessen die Applikation 4 auf Basis der Eingabedaten 5 Simulationsrechnungen
durchführen kann.
-
Darüber hinaus
ist es auch möglich,
nach Durchführung
der Simulationsrechnungen durch die Applikation 4 dem Lizenztoken 8 die
Zeitdauer, die die Simulationsrechnungen auf dem Ressourcenrechner 3 benötigt haben,
hinzuzufügen
und den entsprechend ergänzten
Lizenzto ken 8 zusammen mit den Ausgabedaten 9 zurück an den
Anwenderrechner 1 zu übertragen.
-
Wenn
somit der Anwender 1 seine Eingabedatei 5 für einen
Rechenjob an einen externen Ressourcenprovider 4 übertragen
möchte,
muss er beim Hersteller der Software bzw. beim Lizenzserver einen Lizenztoken 8 für seine
Eingabedaten erstellen lassen. Der Hersteller sichert über diesen
Mechanismus zu, dass für
diese Berechnung eine Lizenzvereinbarung existiert. Der Lizenztoken 8 wird
dann zusammen mit den Eingabedaten 5 an den Ressourcenprovider 3 weitergeleitet.
Beim Start der Applikation 4 kann diese dann den Lizenztoken
prüfen
und die Berechnungen ausführen.
-
Eine
sichere Implementierung muss v. a. Schutz vor Manipulationen bieten
bzw. die Wiederverwendung von Schlüsseln für andere Berechnungen verhindern.
Dies kann beispielsweise einfach durch die Verwendung einer X.509-basierten
Public-Key-Infrastruktur (PKI) erreicht werden: Der Lizenznehmer
erstellt einen Lizenzdeskriptor für die Eingabedaten, indem er
einen kryptographischen Hash der Eingabedaten zum Lizenzgeber schickt. Gleichzeitig
fügt der
Lizenznehmer der Anfrage auch einen Deskriptor mit weiteren Daten
zur eigenen Person (Anwenderidentifikationsdaten) bei. Auf dieser Basis
kann der Lizenzgeber dann beispielsweise entscheiden, ob der Lizenznehmer
bereits bekannt ist und ob ihm die Zugriffsberechtigung gegeben
werden kann. Eventuell können
hier auch Angaben zur Art der gewährleisteten Lizenz übertragen
werden.
-
Ein
Beispiel für
einen solchen Lizenzdeskriptor 7 ist in 2 gegeben.
Die entsprechenden Angaben müssen
natürlich
beim Lizenzgeber verarbeitet werden können.
-
Sollte
die Prüfung
der Kundenanfrage den Anforderungen des Lizenzgebers genügen, so
unterzeichnet er den Lizenzdeskriptor 7 mit seinem geheimen
X.509-Schlüssel und
schickt diesen als Lizenztoken 8 zum Lizenznehmer 1 zurück.
-
Der
Lizenznehmer 1 überträgt dann
seine Daten zusammen mit dem Lizenztoken 8 zu einem Ressourcenanbieter 3.
Dieser hat zwar beispielsweise die Software des Lizenzgebers installiert,
besitzt jedoch u. U. selbst keine Lizenz dafür.
-
Der
Job wird ganz normal über
ein Batchsystem gestartet. Die Applikation prüft nun mit Hilfe des öffentlichen
Schlüssels
des Lizenzgebers den Lizenztoken und hat damit eine Vorbedingung
für die Gültigkeit
der Lizenz abgesichert. (Hier wird geprüft, ob der Lizenztoken tatsächlich vom
Lizenzserver ausgestellt wurde; die Prüfung, ob die Lizenz im Anschluss
auch für
diese Eingabedaten gilt, wird wie nachfolgend beschrieben durchgeführt.) Dann
berechnet sie den kryptographischen Hash der Eingabe und vergleicht
ihn mit dem signierten Hash aus dem Lizenztoken. Dies ist möglich, da
der Lizenzdeskriptor mit dem von Anwender generierten Hash an den Lizenzserver übermittelt
wird, dort in den Lizenztoken übernommen
wird und anschließend
an den Anwender- und den Ressourcenrechner übermittelt wird. Sollten diese übereinstimmen,
dann liegt eine gültige Lizenz
für diese
Eingabedaten vor und die Berechnung kann starten.
-
Der
Lizenzserver prüft
somit, ob der Anwender 1a die Applikation benutzen darf.
Dabei wird ein beispielsweise von den Applikationsdaten/Eingabedaten
abhängiger
Lizenztoken erstellt. Der Anwenderrechner muss diesen Lizenztoken
prüfen,
um das Vorliegen einer korrekten Lizenz für die gegebenen Eingabedaten
sicherzustellen. Der Grund hierfür
ist, dass der Ressourcenrechner und der Lizenzserver keine Kenntnis
voneinander haben, d. h. es muss zum Zeitpunkt des Rechenjobstarts
keine Kommunikation nach außen
erfolgen: Die Lizenzprüfung
kann rein mit lokal vorhandenen Daten erfolgen. Im vorliegenden
Fall müssen
somit mehrere Bedingungen zutreffen, damit eine Lizenz für die Eingabedaten
gültig ist
(Prüfverfahren,
das durch die Applikation und/oder den Ressourcenrechner durchgeführt wird):
- 1. korrekte Signatur des Lizenztokens (der
Token selbst ist unmodifiziert);
- 2. der Token bezieht sich auf die Eingabedaten (hier: die Hash-Codes
stimmen überein)
und
- 3. eventuell im Lizenztoken kodierte Einschränkungen (z. B. dass die Berechnungen
nur auf einer CPU des Ressourcenrechners ausgeführt werden dürfen) sind
erfüllt.
-
Es
ist somit für
den Lizenzgeber sehr einfach, anwenderindividuelle Lizenztoken in
einem automatisierten Verfahren zu generieren. Dieser Schritt kann
z. B. auch direkt in die Preprocessing-Tools der Lizenzgeber integriert
werden. Es kann eine Art ”Archiv” für die Submission
zu einem Ressourcenprovider erstellt werden, welches neben den Eingabedaten
auch die Lizenz für
die Applikation beinhaltet. Der Lizenznehmer muss dann nur dieses
Archiv zum Ressourcenprovider schicken.
-
Aus
Sicht der Ressourcenprovider bietet dieses Lizenzierungsverfahren
den Vorteil, dass die Applikation aus den Eingabedaten selbst die
Lizenz prüft.
Es ist nicht nötig,
eine permanente Applikationslizenz vorzuhalten oder eine entsprechende Netzwerkkonfiguration
für den
Lizenzserver jedes Kunden zu pflegen. Im Falle eines fehlgeschlagenen Jobs
(z. B. durch Rechnerausfälle)
kann der Provider auch selbstständig
den Job neu starten, ohne auf eine Lizenz warten zu müssen.
-
Der
Anwender hat bei dieser Lösung
den zusätzlichen
Schritt der Lizenzgenerierung zu tragen, der jedoch komplett in
Software abgewickelt werden kann. In Bezug auf das Handling der
Eingabedaten empfiehlt es sich, innerhalb der Preprocessing-Tools eine
Archivdatei zu generieren, um den Transfer zum Ressourcenprovider
einfach zu halten.
-
In
Ergänzung
zum Binden der Lizenztoken an eine Eingabedatei ist es auch möglich, die
Lizenz an andere Gegebenheiten zu binden. Das Verfahren bleibt dabei
unverändert – lediglich
die Generierung des Hashes wird verändert: Im bisher beschriebenen Abschnitt
wird der Hash aus den Eingabedaten berechnet. Für den Nutzer eines interaktiven
Preprocessing-Tools ist dies natürlich
keine Option, da womöglich
noch keinerlei Eingabedaten existieren. Statt eines Hashes auf die
Eingabedaten ist es hier jedoch möglich, die Benutzerumgebung
durch einen Hash zu charakterisieren. Zusammen mit weiteren Daten kann
daraus ein Lizenzdeskriptor gebildet werden, welcher dann wie üblich zum
Anfordern einer Lizenz (Lizenztoken) benutzt werden kann.
-
Der
Hash stellt dabei eine Identifikation des Rechners des Benutzers
dar, z. B. eine Kombination aus CPU-ID, MAC-Adresse etc. Folgendes
Einsatzszenario ist dabei denkbar: Der Benutzer möchte eine für eine Woche
gültige
Lizenz auf seinem Notebook haben, z. B. um während eines Kundenbesuches
unabhängig
vom Netzwerk arbeiten zu können.
Er startet den Lizenzclient auf dem Notebook, woraufhin dieser einen
kryptographischen Hash aus den Hardware-Komponenten des Notebooks
berechnet. Zusammen mit weiteren Daten, wie z. B. der gewünschten
Lizenzdauer, entsteht ein Lizenzdeskriptor, der dann durch den Lizenzserver
signiert werden kann. Dieser Lizenztoken kann dann in einer Datei
abgespeichert werden.
-
Bei
dem Starten der Applikation wird dann der Lizenztoken zunächst auf
seine Gültigkeit
geprüft und
dann der aktuell kryptographische Hash aus der Hardware berechnet.
Stimmen die beiden Hashes überein,
so gelten die in dem Lizenzdeskriptor beschriebenen Lizenzbedingungen.
-
In
Anlehnung an Floating-Lizenzen in einem lokalen Netzwerk kann es
nötig sein,
dass ein Benutzer seine Lizenz nach der Benutzung zurückgibt.
Da es im Allgemeinen nicht möglich
ist, mit dem Ressourcenrechner zu kommunizieren, auf dem die Berechnung
läuft,
kann die Rückgabe
nur indirekt erfolgen. Dazu wird die Lizenz für eine längere Zeit ausgestellt, als
der Job wirklich benötigt.
Nach Ablauf der Rechnung protokolliert die Applikation die in Anspruch
genommene Rechenzeit.
-
Diese
Protokollierung kann als weiteres Feld in den Lizenztoken mit aufgenommen
und mit der Signatur des Applikationsbinaries versehen werden. Zusammen
mit den Ausgabedaten der Applikation wird der Lizenztoken wieder
zurück
zum Benutzer übertragen.
Dort kann der Lizenzclient den veränderten Lizenztoken wieder
zu rück
an den Lizenzserver schicken.
-
Der
Lizenzserver prüft
seinerseits die Signatur in Bezug auf die Rechenzeit. Falls die
Signatur in Ordnung ist, wird die unbenutzte Rechenzeit zurück auf das
Konto des Benutzers transferiert.
-
Nachfolgend
wird eine konkrete Implementierung eines erfindungsgemäßen Rechnernetzwerkes
beschrieben:
Der Lizenzierungsdienst besteht aus den bereits
genannten Komponenten Benutzerclient (auf Anwenderrechner 1),
Lizenzserver 2 und Lizenzprüfer (Teil des Ressourcenrechners 3).
Darüber
hinaus wird zur Kommunikation noch ein Messaging-Dienst benötigt. Für die folgende
Diskussion der Komponenten wird davon ausgegangen, dass die zugrunde
liegende Applikation aus einer Benutzerkomponente und einem Berechnungsbackend
besteht und die Lizenz an eine Eingabedatei gebunden werden soll.
Dabei werden zunächst
die Komponenten einzeln dargestellt, anschließend das Kommunikationsprotokoll.
Einen Überblick über die
verwendeten Komponenten gibt 3.
-
Der Benutzerclient:
-
Der
Benutzerclient ist eine Softwarekomponente, welche direkt in die
Endanwender-Applikation integriert werden kann. Die Aufgabe des
Benutzerclients ist es, für
einen gegebenen Eingabedatensatz einen Lizenzschlüssel vom
Lizenzserver anzufordern.
-
Dazu
wird der Eingabedatensatz zunächst durch
einen Hash charakterisiert. Neben einem Hash müssen auch weitere Informationen
bezüglich
der Anwendung zusammengestellt werden, z. B. wie viele CPUs verwendet werden
sollen. Ein Beispiel eines Lizenzdeskriptors zeigt 4.
Der interne Ablauf des Benutzerclients sieht so aus:
- 1. In Abhängigkeit
von der Konfiguration des Clients wird ein bestimmter kryptographischer
Hash aus den Eingabedaten berechnet.
- 2. Der Lizenzdeskriptor wird zusammengestellt. Um die Identität des Benutzers
feststellen zu können,
wird der Lizenzdeskriptor mit einer digitalen Signatur versehen.
- 3. Der Lizenzdeskriptor wird mit der Signatur in eine Anfrage
verpackt und zum Lizenzserver geschickt.
- 4. Die Antwort des Servers enthält einen verschlüsselten
Lizenztoken. Der Client fragt den Server nochmals nach dem Entschlüsselungskey. Mit
diesem entschlüsselt
der Client den Lizenztoken.
- 5. Der Lizenztoken wird in einer Datei gespeichert und dem Benutzer
zugänglich
gemacht.
-
Falls
unbenutzte Rechenzeiten wieder zurückgebucht werden sollen, wird
der modifizierte Lizenztoken nach Abschluss der Berechnung wieder zum
Lizenzserver übermittelt.
Sollte hierbei ein Fehler auftreten, wird der Benutzer benachrichtigt.
-
Der Lizenzserver:
-
Der
Lizenzserver ist ein Dämon,
der permanent auf eingehende Lizenzanfragen wartet und diese beantwortet.
Ein gültiger
Lizenztoken wird erzeugt, indem der Lizenzdeskriptor vom Benutzerclient
mit der Signatur des Servers versehen wird. Der interne Ablauf sieht
so aus:
- 1. Der empfangene Lizenzdeskriptor
wird geöffnet und
die Identität
des Benutzers anhand seiner digitalen Unterschrift überprüft. Damit
ist die Anfrage authentifiziert, d. h. es ist klar, wem die Lizenzanfrage
zuzuordnen ist.
- 2. Dann muss der Anwender autorisiert werden, d. h. aufgrund
einer Kundendatenbank etc. wird entschieden, ob der Anwender diese
Lizenz überhaupt
anfragen darf. Dabei können
Details der angefragten license-terms (z. B. Anzahl der CPUs, Berechnungsmodule) überprüft werden.
Diese Funktionalität
ist in einem separaten Lizenzmanagement-Plugin gekapselt.
- 3. Schließlich
wird der Lizenzdeskriptor mit dem geheimen Schlüssel des Lizenzservers signiert. Der
Server vergibt für
diese Anfrage einen symmetrischen Key und verschlüsselt den
Lizenztoken damit. Der Lizenztoken wird nun zurückgeschickt.
- 4. Der Server wartet auf die Nachfrage des Clients nach dem
Key. Falls diese Anfrage eingeht, weiß der Server, dass der Lizenztoken
beim Client angekommen ist. Der Server antwortet mit dem Key, um
die Lizenz freizuschalten.
-
Die
Antwort des Lizenzservers fügt
dem Lizenzdeskriptor also eine Signatur hinzu, wenn die Lizenz gültig ist.
Dieser Lizenztoken bezeugt die Gültigkeit
einer Lizenz zu den Bedingungen, die im Lizenzdeskriptor genannt
sind.
-
Wenn
der Lizenzclient nach Ende des Rechenjobs einen unterschriebenen
Lizenztoken zurückgeben
will, so wird dieser im Hinblick auf die verbrauchte Rechenzeit
ausgewertet.
-
Der Lizenzprüfer:
-
Diese
Komponente wird direkt in das Berechnungsbackend integriert. Ihre
Aufgabe ist es, die Gültigkeit
eines Lizenztokens zu überprüfen. Dazu
werden folgende Schritte durchgeführt:
- 1.
Der Lizenztoken wird geöffnet
und die Signatur des Lizenzservers auf ihre Gültigkeit überprüft.
- 2. Die license-terms des Deskriptors werden geprüft und die
entsprechenden Module des Berechnungsbackends freigegeben.
- 3. Der Hash der Eingabedaten wird berechnet und mit dem Wert
im Lizenzdeskriptor verglichen. Wenn bis hierher alle Prüfungen erfolgreich
sind, ist die Lizenz für
diesen Eingabedatensatz gültig.
-
Wichtig
hierbei ist, dass der Lizenzprüfer
lediglich den öffentlichen
Schlüssel
des Lizenzservers kennen muss. Es ist nicht erforderlich, Netzwerkverbindungen
zum Lizenzserver aufzubauen – die
Prüfung
des Lizenzdeskriptors kann lokal erfolgen.
-
Nach
Ablauf der Berechnung kann der Lizenzprüfer die verbrauchte Rechenzeit
im Lizenztoken dokumentieren und signieren. Der Token kann dann
mit den Ergebnissen zurück
zum Anwender kopiert werden.
-
Der
Lizenzserver und der Benutzerclient tauschen lediglich kompakte
Nachrichten aus, es ist nicht erforderlich, größere Datenmengen auszutauschen.
Es ist daher möglich,
die Kommunikation über eine
Messaging-Queue
abzuwickeln. Dabei können mehrere
physikalische Lizenzserver zu einem logischen verknüpft werden,
um die Ausfallsicherheit zu erhöhen.
Darüber
hinaus muss lediglich die Messaging-Queue über das Internet zugänglich gemacht werden,
sodass keine direkten Angriffe auf die Lizenzserver möglich sind.
-
Das Protokoll:
-
Unter
der Voraussetzung, dass die Nachrichtenübermittlung zwischen Lizenzclient
und Lizenzserver fehlerfrei und zuverlässig funktioniert, kann man
ein sehr einfaches Protokoll realisieren. Das Protokoll muss jedoch
auch bei fehlerhaften Netzwerkverbindungen funktionieren.
-
Bei
genauerer Betrachtung stellte sich heraus, dass der Austausch des
Lizenztokens auf das Problem der byzantinischen Generäle zurückgeführt werden
kann: Wie können
zwei Parteien eine konsistente Sicht auf die Übertragung der Lizenztoken
haben? Dieses Problem ist nicht generell lösbar. Zur Veranschaulichung
kann man sich vorstellen, was passiert, wenn einzelne Nachrichten
verloren gehen: Angenommen, der Client fragt eine Lizenz beim Server
an. Er erhält
die Lizenz, allerdings antwortet er nicht mehr darauf. Der Server
kann nun nicht entscheiden, ob der Client die Lizenz erhalten hat
oder ob die Lizenz nie beim Client angekommen ist.
-
Um
dennoch die Übertragung
des Lizenztokens sicher zu machen, wurde eine zusätzliche
Komponente (der Schlüssel
bzw. Key) in das Protokoll eingefügt. Der Key verschlüsselt den
Lizenztoken symmetrisch. Nachdem der Client den verschlüsselten
Lizenztoken erhalten hat, fragt er nochmals beim Lizenzserver nach
dem zugehörigen
Key. Dabei gibt er eine Transaktionsnummer an, die im gleichen Datenpaket
wie der Lizenztoken vom Server übermittelt wurde.
Wenn die Anfrage nach dem Key beim Server mit der korrekten Transaktionsnummer
empfangen wurde, dann kann die Lizenz endgültig berechnet werden.
-
Die
Nachricht mit dem Key des Servers kann allerdings auch verloren
gehen. In diesem Fall kann der Client dem Benutzer eine Nachricht
anzeigen mit der Transaktionsnummer – mit dieser kann sich der Benutzer
dann an den Lizenzgeber wenden und den Freischaltkey anfragen.
-
Zusammenfassend
lässt sich
sagen, dass dieser Fall zwar nicht ausgeschlossen werden kann, insgesamt
jedoch recht unwahrscheinlich ist. Es ist nicht damit zu rechnen,
dass der Benutzer oft beim Lizenzgeber nach einem Freischaltkey
nachfragen muss.