DE69334091T2

DE69334091T2 - Zugangskontrollen-Untersystem und Verfahren für ein verteiltes Rechensystem, das lokal gespeicherte Authentifizierungsdaten benutzt

Info

Publication number: DE69334091T2
Application number: DE69334091T
Authority: DE
Inventors: Martin Palo Alto Abadi; Andrew Los Altos Birrell; Edward Menlo Park Wobber; Butler Cambridge Lampson
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 1992-07-21
Filing date: 1993-07-14
Publication date: 2007-04-26
Anticipated expiration: 2013-07-15
Also published as: DE69334091D1; JPH06202998A; EP0580350B1; US5235642A; EP0580350A1

Description

Die vorliegende Erfindung betrifft allgemein das Kontrollieren des Zugangs zu Computerressourcen in einem verteilten Computersystem und insbesondere Vorrichtungen und Verfahren, um solche Zugangskontrollsysteme effizienter zu machen, indem Authentifizierungsdaten für Identitätsträger, die die Nutzung der Ressourcen des betreffenden Computers anfordern, in jedem Computer lokal cache-gespeichert werden.
Computersicherheitssysteme basieren oft auf dem Basiszugangskontrollmodell, das ein Fundament für Vertraulichkeits- und Integritätssicherheitsverfahren bildet. Siehe zum Beispiel den Artikel von Butler Lampson, "ACM Operating System Reviews", Band 8, Nr. 1, Januar 1974, Seiten 18–24, aus dem Jahr 1974. Die Elemente dieses Modells sind:

– Objekte, die Ressourcen wie zum Beispiel Dateien, Geräte oder Bauelemente oder Prozesse sind;
– Anforderungen, Operationen an den Objekten auszuführen;
– Quellen von Anforderungen, die Identitätsträger sind;
– ein Referenzüberwacher, der jede Anforderung für einen Zugang zu einem bestimmten Objekt prüft und entscheidet, ob ihr stattgegeben wird.

Der Referenzüberwacher stützt seine Entscheidung auf das Objekt, den Identitätsträger, der die Anforderung stellt, die Operation in der Anforderung und eine Regel, die sagt, welche Identitätsträger die betreffende Operation ausführen dürfen. Es versteht sich, dass die Funktion des Referenz überwachers separat und eigenständig von anderen Sicherheitsfragen abläuft, wie zum Beispiel, ob ein Anforderer der ist, für den er sich ausgibt. Diese Art der Sicherheit wird in der Regel durch die Verwendung von Verschlüsselungs- und Digitale-Signatur-Techniken bereitgestellt, mitunter als "Authentifizierung" bezeichnet, wie der Fachmann weiß. Die vorliegende Erfindung betrifft eine Technik, um die Authentifizierung von Anforderern effizienter zu machen.
Im Allgemeinen erfordert bei den meisten Systemen des Standes der Technik das Authentifizieren jeder Anforderung durch einen Anforderer ein digitales Signieren der Anforderung sowie einen Austausch von Informationen, als "Berechtigungsdaten" bezeichnet, zwischen dem Anforderer und dem Server, um den Server in die Lage zu versetzen, die digitale Signatur auf der Anforderung zu authentifizieren. Der Authentifizierungsprozess kann den Betrieb von verteilten Computersystemen mit erheblichem Verwaltungsdatenaufwand belasten, insbesondere wenn die Anzahl von Anforderungen, die zwischen Knoten übertragen werden, hoch ist.
In US 4471163 ist ein Sicherheitsschutzsystem zum Kontrollieren des Zugangs zu einer Computerressource offenbart, wobei ein Programmsperrenmechanismus den Zugriff auf Prozesse verhindert, wenn nicht eine Anforderung autorisiert wird, indem ein Zahlencode in dem Prozess zu einem Code in der Sperre und zu einem Tastencode, der an die Sperre übermittelt wird, in Beziehung gesetzt wird.
In EP 0398492 wird eine Schnittstelle zu Authentifizierungsquellen in einem verteilten Datenverarbeitungssystem beschrieben, die eine Anzahl möglicher Authentifizierungsvorschriften enthält. Die offenbarten Vorrichtungen und Verfahren stellen verteilte Dienstfunktionen und ein Benutzerprogramm bereit, das ein Authentifizierungsregime für Ressourcenanforderungen darstellt. Die Kerberos-Authentifi zierungsvorschrift leitet speziell aufgebaute Datentickets, die für spezielle Nutzer eindeutig sind, an Datenserver. Die Authentifizierung beinhaltet das Durchsuchen von Nutzeridentifikationstabellen, die auf einer Diskette oder in Ticket-Caches im Speicher gespeichert sind. Für jede Anforderung müssen neue Tickets ausgestellt werden, und sie können nach der Authentifizierung nicht wiederverwendet werden.
Die Erfindung in ihrer breitesten Form wird durch eine Sicherheitsvorrichtung nach Anspruch 1 und ein Verfahren zum Betreiben eines verteilten Computersystems nach Anspruch 6 verkörpert. In den abhängigen Ansprüchen sind bevorzugte Merkmale der Erfindung gemäß ihren verschiedenen Aspekten genannt. Insbesondere wird im vorliegenden Text ein Sicherheitssystem beschrieben, das den Zugang zu Objekten in einem verteilten Computersystem regelt. Der Computer in jedem Knoten des verteilten Systems hat eine vertrauenswürdige Rechenbasis, die einen Authentifizierungsagenten zum Authentifizieren von Anforderungen enthält, die von Identitätsträgern an anderen Knoten im System empfangen werden. Die Anforderungen werden zu Servern als Meldungen übertragen, die einen ersten Identifikator (als "Auth-ID" bezeichnet), der von dem Anforderer stammt, und einen zweiten Identifikator (als der "Unterkanalwert" bezeichnet), der von dem Authentifizierungsagenten des Anfordererknotens stammt, enthalten. Jeder Serverprozess hat einen zugehörigen lokalen Cache, der Anforderer identifiziert, deren vorherige Anforderungsmeldungen authentifiziert wurden. Wenn eine Anforderung empfangen wird, so überprüft der Server den ersten und den zweiten Identifikator der Anforderung anhand der Einträge in seinem lokalen Cache. Wenn es eine Übereinstimmung gibt, so weiß man, dass die Anforderung authentisch ist, ohne Authentifizierungsdaten vom Knoten des Anforderers einzuholen, weil die Authentifizierungsagenten die Authentizität solcher Anforderungsmeldungen garantieren.
Wenn der Identifikator in einer Anforderungsmeldung nicht mit einem der Einträge in dem lokalen Cache des Servers übereinstimmt, so wird der Authentifizierungsagent des Serverknotens angerufen, um Authentifizierungsdaten vom Knoten des Anforderers zu erhalten, um die Anforderungsmeldung zu authentifizieren. Nach dem Empfang der angeforderten Berechtigungsdaten von dem Authentifizierungsagenten des Anforderer-Knotens werden der Identitätsträger-Identifikator des Anforderers und die empfangenen Berechtigungsdaten durch den Authentifizierungsagenten des Serverknotens in einem lokalen Cache gespeichert. Der Serverprozess speichert außerdem einen Datensatz in seinem lokalen Cache, der anzeigt, dass Anforderungsmeldungen von dem bestimmten Anforderer als authentisch bekannt sind, wodurch der Prozess des Authentifizierens empfangener Anforderungen beschleunigt wird.
Eine weitere Optimierung ist, dass der lokale Cache des Serverprozesses dafür verwendet wird, eine Liste der Objektzugangskontrolllisteneinträge, die zuvor durch jeden Anforderer erfüllt wurden, zu speichern, wodurch es dem Serverprozess ermöglicht wird, die Gewährung des Zugangs zu Objekten, auf die schon einmal zugegriffen wurde, zu beschleunigen.
Ein tiefergehendes Verständnis der Erfindung erhält man aus dem Studium der folgenden detaillierten Beschreibung einer bevorzugten Ausführungsform, die beispielhaft gegeben wird und in Verbindung mit den begleitenden Zeichnungen zu verstehen ist, in denen Folgendes dargestellt ist:
1 ist ein Blockschaubild eines verteilten Computersystems mit einem vertrauenswürdigen Namensdienst zum Speichern sicherer Daten, die von den Mitgliedern des Systems gemeinsam genutzt werden.
2 und 3 sind Blockschaubilder eines Knotens des in 1 gezeigten verteilten Computersystems.
4 ist ein Blockschaubild von zwei Computern, einer mit einem Anfordererprozess, der Zugang zu einem Serverprozess in dem zweiten Computer anfordert.
5A und 5B zeigen schematisch eine Authentifizierungs-ID-Tabelle und eine Kanalzuweisungstabelle, die in der bevorzugten Ausführungsform der vorliegenden Erfindung durch Authentifizierungsagenten verwaltet wird.
6 stellt schematisch ein Datenpaket dar.
7 zeigt schematisch einen "lokalen Cache" aus Authentifizierungsdaten, der in der bevorzugten Ausführungsform der vorliegenden Erfindung durch Authentifizierungsagenten verwaltet wird.
8 zeigt schematisch einen lokalen Cache aus Authentifizierungsdaten, der in der bevorzugten Ausführungsform der vorliegenden Erfindung im Namen jedes Serverprozesses verwaltet wird.
9 ist ein Blockschaubild, das eine Zugangskontrollliste darstellt.
10 ist ein Flussdiagramm des Authentifizierungsprozesses, der durch die Authentifizierungsagenten, die einem Anforderer und einem Server zugeordnet sind, ausgeführt wird.
Unter Bezugnahme auf 1 ist die vorliegende Erfindung ein Sicherheitssystem und ein Sicherheitsverfahren, das in der Regel im Kontext eines verteilten Computersystems 100 arbeitet, das eine Gruppe von Computern 102-1 bis 102-N aufweist, die durch ein Nah- oder ein Fernbereichsnetz 110 oder ein anderes Kommunikationsmedium miteinander verbunden sind. Von jedem dieser Computer 102 sagt man, dass er sich an einem eigenständigen Knoten des verteilten Computersystems 100 befindet.
Für die Zwecke dieses Dokuments wollen wir annehmen, dass die Knoten durch Drähte miteinander verbunden sind, die nicht physisch sicher sind. In der bevorzugten Ausführungsform wird eine Gemeinschaftsschlüsselverschlüsselung verwendet, um Kanäle zwischen den Knoten des verteilten Systems zu sichern, und diese Kanäle werden dann multiplexiert, um alle anderen Kanäle zu erhalten, die von dem Netzwerk benötigt werden. Weil das Betriebssystem an jedem Knoten ohnehin vertrauenswürdig sein muss, ist eine tiefergehende Verschlüsselung (zum Beispiel zwischen Prozessen) nicht erforderlich. Alternativ könnten Verschlüsselungstechniken mit öffentlichem Schlüssel verwendet werden, um die Kanäle zwischen Knoten zu sichern, obgleich die Verschlüsselung mit öffentlichem Schlüssel in der Regel viel langsamer ist als die Gemeinschaftsschlüsselverschlüsselung.
Jeder Computer 102 enthält die standardmäßigen Computersystemkomponenten, einschließlich einer Datenverarbeitungseinheit (CPU) 112, eines Systembus' 114, eines Primärspeichers (Direktzugriffsspeichers) 116, eines Sekundärspeichers 118 (zum Beispiel magnetische oder optische Disks), eines virtuellen Speicherverwalters 120, einer Benutzerschnittstelle 122 (zum Beispiel Tastatur, Monitor und Drucker) und einer Netzwerksteuerung 124 zum Anbinden des Computers 102 an das Netzwerk 110. Eine Taktschaltung 126 oder ein gleichwertiger Mechanismus versorgt jeden Computer 102 mit Zeitwerten (die durch die weiter unten besprochene Sicherheitsvorrichtung verwendet wird). Diese physikalischen Computerkomponenten werden durch die vorliegende Erfindung nicht verändert und werden darum im vorliegenden Text nicht eingehender beschrieben.
Um eine vereinfachte schematische Darstellung zu ermöglichen, ist das Betriebssystem 130 des Computers in 2 so gezeigt, dass es sich im Primärspeicher befindet, aber dem Fachmann ist natürlich klar, dass Teile des Betriebssystems 130, wenn sie nicht gebraucht werden, durch den virtuellen Speicherverwalter 120 des Computers im Sekundärspeicher gespeichert werden. Das Betriebssystem 130 enthält einen Referenzüberwacher 132 und einen Authentifizierungsagenten 134, die beide weiter unten eingehender besprochen werden.
Ebenfalls in 2 gezeigt ist der (virtuelle) Speicher, der zwei Prozessen, B1 und B2, zugewiesen ist, zu denen Anwendungsprogramme wie auch Datenstrukturen und Software, die mit der vorliegenden Erfindung zu tun haben, gehören. Wie dem Fachmann natürlich klar ist, ist der Speicherplatz, der diesen Prozessen zugewiesen ist, zwar aus Gründen der Einfachheit so dargestellt, dass er sich im Primärspeicher befindet, doch ein Großteil des Speicherplatzes, der jedem Prozess zugewiesen ist, wird durch den virtuellen Speicherverwalters 120 des Computers bei Nichtgebrauch im Sekundärspeicher gespeichert.
In 3 ist ein Knoten 102-1 des verteilten Systems detaillierter gezeigt. Jeder Knoten muss eine vertrauenswürdige Rechenbasis (VRB) 135 haben, bei der es sich in der Regel um eine kleine Menge Computerhardware und -software handelt, von der die Sicherheit abhängt und die sich vom Rest des Knoten unterscheidet, der sich falsch verhalten kann, ohne die Sicherheit zu beeinträchtigen. Die VRB 135 enthält ein Referenzüberwacherprogramm 132 (mitunter als der "Referenzüberwacher" bezeichnet), das die Informationen sammelt, die benötigt werden, um eine Zugangskontrollentscheidung zu rechtfertigen. Das Referenzü berwacherprogramm 132 läuft innerhalb des Adressraums jedes Prozesses ab. Die VRB 135 enthält einen Authentifizierungsagenten 134, bei dem es sich in der vorliegenden Erfindung um einen Satz Software im Betriebssystem des Computers handelt, der Berechtigungsdaten mit den Authentifizierungsagenten anderer Knoten austauscht, um die Quelle von Anforderungsmeldungen zu authentifizieren. Der Authentifizierungsagent 134 führt außerdem eine Anzahl zugehöriger Aufgaben aus, um zu gewährleisten, dass Meldungen, die durch Prozesse an seinem Knoten hervorgebracht wurden, mit gültigen Absenderidentifikationsdaten markiert oder signiert werden, wie weiter unten beschrieben wird.
Die VRB 135 enthält weder die Speichervorrichtungen oder -bauelemente, aus denen Daten abgerufen werden, noch die Übertragungskanäle, über die Meldungen empfangen werden. Das liegt daran, dass digital signierte Meldungen von ungesicherten Orten geholt werden können, ohne das Vertrauen zu verlieren, dass der Signierer sie tatsächlich ursprünglich gesandt hat. Die Einzelheiten von Verschlüsselung, Entschlüsselung und digitalen Signaturen und dergleichen sind nicht das Thema dieses Dokuments. Diese Themen werden in der Computersicherheitsliteratur weithin besprochen. Die vorliegende Erfindung betrifft vor allem den Authentifizierungsagenten 134 und das Verringern des Austauschs von Berechtigungsdaten, die zu Authentifizierungsmeldungen gehören, die zwischen Anforderern und Servern auf verschiedenen Knoten des verteilten Computersystems versandt werden.
Für die Zwecke von 3 wurde ein Prozess A1 im Knoten 102-2 mit "Anforderer" bezeichnet, weil er eine Anforderung zu einem der Serverprozesse B1 bis BN auf dem Knoten 102-1 sendet. Es ist jedoch zu beachten, dass allgemeiner betrachtet der Anforderer ein Identitätsträger sein kann, der einen beliebigen der Computer in dem verteilten System verwendet.
Mit "Identitätsträger" ist im vorliegenden Text die Quelle einer Anforderung oder Geltendmachung gemeint. Normalerweise stellt man sich einen Identitätsträger als eine Person oder eine Maschine vor, die im Namen einer Person agiert. Jedoch können auch Prozesse, die viele Ebenen von der unmittelbaren menschlichen Anweisung entfernt sind, wie zum Beispiel jene in einem Transaktionsverarbeitungssystem, Identitätsträger sein.
Objekte können Dateien, Prozesse, Datensätze, wie zum Beispiel eine Tabelle oder Datenbank, Programme (zum Beispiel ein Schnittstellenprogramm, das die Verwendung eines Eingabe-Ausgabe-Gerätes steuert), und so weiter sein. In der bevorzugten Ausführungsform werden die Objekte 136, zu denen der Zugang durch das Referenzüberwacherprogramm 132 auf dem Knoten 102-1 geregelt wird, in dem Computer an jenem Knoten gespeichert (andere Anordnungen können auch möglich sein). Jedes Objekt 136 enthält eine Zugangskontrollliste (ZKL) 138, welche die Gruppe von "Identitätsträgern" definiert, die befugt sind, auf das Objekt 136 zuzugreifen.
Wie aus 4 ersichtlich, enthält jeder Knoten des verteilten Systems in seiner VRB einen Authentifizierungsagenten 134. Im Kontext von 4 betrachten wir die Aktionen der Authentifizierungsagenten 134, die zu dem Prozess A1 auf dem Knoten 102-2 gehören, der eine Anforderung zu einem Serverprozess B1 auf Knoten 102-1 sendet.
Vor dem Senden von Anforderungen zwischen zwei Knoten muss ein sicherer Kanal 140 zwischen den zwei Knoten hergestellt werden. Ein Verfahren zum Herstellen eines sicheren Kanals zwischen zwei Knoten ist, dass man die zwei Knoten einen Host-zu-Host-Schlüssel festlegen lässt, der dafür verwendet wird, alle Datenpakete, die zwischen den zwei Knoten übertragen werden, sowohl zu verschlüsseln als auch zu ent schlüsseln. Die Datenpakete werden in der bevorzugten Ausführungsform mittels einer Verschlüsselungsmethodologie des privaten Schlüssels verschlüsselt, wie zum Beispiel DES CBC. Im Stand der Technik gibt es eine beliebige Anzahl von Mechanismen zum Verteilen von Verschlüsselungsschlüsseln in einem Netzwerk. Eine solche Methodologie, die am Massachusetts Institute of Technology entwickelt wurde, ist unter dem Namen KERBEROS bekannt. Weitere Methodologien sind als Systeme mit öffentlichem Schlüssel bekannt. In jedem Fall müssen sich im Kontext der vorliegenden Erfindung jeweils zwei Hostcomputer, die Datenpakete zwischen sich übertragen, zuerst auf einen "Host-zu-Host"-Verschlüsselungsschlüssel einigen, der dafür verwendet wird, die sicheren Teile von Datenpaketen, die zwischen jenen zwei Computern übertragen werden, zu verschlüsseln. Des Weiteren ist zur Gewährleistung der Datenintegrität ein CRC-Fehlererkennungscode (CRC = Cyclic Redundancy Check) in jedes Datenpaket – in der Regel am Ende des Datenpaketes – integriert, um beschädigte Pakete zu erkennen und um Pakete zu erkennen, die mit dem Ziel, die Sicherheitsvorkehrungen des Systems zu überlisten, manipuliert wurden. Darum muss jedes Paket, das durch die Netzwerksteuerung 124 eines Knotens empfangen wurde, entschlüsselt und mittels einer CRC-Schaltung auf Fehler überprüft werden, bevor es durch den empfangenden Hostcomputer 102 verwendet werden kann.
Sobald ein sicherer Kanal 140 hergestellt wurde, werden alle Datenpakete, die durch einen der Knoten über den sicheren Kanal 140 versandt werden, durch den Authentifizierungsagenten 134 des Absenders geleitet. Der Authentifizierungsagent 134 weist jedem Anforderer-/Serverprozess-Paar, für das ein Anfordererprozess auf dem Knoten des Authentifizierungsagenten Datenpakete zu einem Serverprozess auf dem anderen Knoten überträgt, einen anderen virtuellen "Unterkanal" des sicheren Kanals zu. Unterkanäle ähneln Prozess-zu-Prozess-Kommunikationskanälen, wie man sie in herkömmlichen Betriebssystemen findet. Zum Beispiel stellt das Internet Transmission Control Protocol eine bidirektionale Verbindung zwischen zwei Prozessen bereit. In der vorliegenden Erfindung jedoch werden Unterkanäle auf sichere Knoten-zu-Knoten-Kanäle aufgesetzt, und zu den durch sie hindurchfließenden Daten können Authentizitätsgarantien gegeben werden. Jeder Unterkanal hat zwei eindeutige Endpunkte. Der Authentifizierungsagent an jedem Endpunkt garantiert die Eindeutigkeit des Endpunktes, den er kontrolliert. Weil ein zugrundeliegender Knoten-zu-Knoten-Kanal impliziert wird, kann darum jeder Endpunkt annehmen, dass alle Daten, die durch den Unterkanal hindurch empfangen werden, von dem eindeutigen Knoten und Prozess stammen, der zu dem anderen Endpunkt jenes Unterkanals gehört.
In der bevorzugten Ausführungsform wird jedem Identitätsträger, der dem Knoten 102 zugeordnet ist, ein eigener Authentifizierungs-Identifikator zugewiesen, im vorliegenden Text als "Auth-ID" bezeichnet. In der Regel erfolgt die Zuweisung der Auth-ID zu einem Identitätsträger in dem Moment, wo sich der Identitätsträger in das System einloggt. Es ist möglich, dass ein einzelner Prozess A1 Arbeit im Namen mehrerer Identitätsträger ausführt, wobei in einem solchen Fall jedem Identitätsträger, der zu dem Prozess gehört, ein eigener Auth-ID gegeben wird.
Der Authentifizierungsagent 134 jedes Knotens verwaltet eine in 5A gezeigte Auth-ID-Tabelle 142, die den Namen des Identitätsträgers und seine zugewiesene Auth-ID auflistet. Jeder Datensatz in der Tabelle würde normalerweise noch andere Informationen enthalten, wie zum Beispiel den Namen des Prozesses, in den der Identitätsträger eingeloggt ist.
Der Authentifizierungsagent 134 jedes Knotens verwaltet außerdem eine in 5B gezeigte Kanalzuweisungstabelle 144, die für jeden Kommunikations-Unterkanal, der einem Prozess zugewiesen wurde, Identifikatoren auflistet, die zu dem Kanal, Unterkanal, Anfordererprozess und Serverprozess, für den der Unterkanal verwendet wird, gehören.
Gemäß 6 enthält jedes Datenpaket 146, das zwischen Knoten übertragen wird, Daten, die durch den Prozess, der das Datenpaket sendet, bereitgestellt werden, und wenigstens ein Feld, dessen Wert durch den Authentifizierungsagenten erzeugt wird. Insbesondere erzeugt der Anfordererprozess in der Regel ein Datenpaket 146, das Zielortdaten 148, ein Feld 150, das die vorgebliche Auth-ID des Identitätsträgers, in dessen Namen das Datenpaket versendet wird, enthält, sowie weitere Paketkopfdaten 152 und den Paketkörper 154 beinhaltet. Die Zielortdaten 148 – unabhängig davon, ob sie in dem Datenpaket enthalten sind oder separat durch den sendenden Prozess bereitgestellt werden – identifizieren den Serverknoten und den Prozess, zu dem das Datenpaket gesendet wird. Zum Beispiel können die Zielortdaten 148 einen Knoten-Identifikator und einen Prozess-Identifikator umfassen.
Der Authentifizierungsagent fügt dem Datenpaket 146 einen Unterkanalwert 156 hinzu, der dem Anforderer- und dem Serverprozess entspricht. Wenn diesem Prozess-Paar nicht bereits ein Unterkanal zugewiesen wurde, wo wird ein eindeutiger Unterkanalwert zugewiesen, und der Kanalzuweisungstabelle 144 wird ein neuer Eintrag hinzugefügt, und dann wird der zugewiesene Unterkanalwert dem Datenpaket hinzugefügt. Wenn diesem Prozess-Paar bereits ein Unterkanal zugewiesen wurde, so wird der zugewiesene Unterkanal aus der Kanalzuweisungstabelle 144 erhalten und dann dem Datenpaket 146 hinzugefügt. Das Unterkanalwert-Feld 156 identifiziert – zusätzlich zum Identifizieren des Sende- und des Empfangsprozesses – eindeutig den sicheren Kanal, über den das Paket gesendet wird. Darum enthält das Unterkanal-Feld 156 direkt oder indirekt einen Kanal-Identifikator. Zum Beispiel kann das Unterkanal-Feld einen Wert enthalten, der von der Netzwerksteuerung des empfangenden Knotens verwendet wird, um zu bestimmen, welcher Entschlüsselungsschlüssel zum Entschlüsseln des Datenpaketes zu verwenden ist.
Lokaler Auth-ID-Cache für Authentifizierungsagenten.
Wenn eine Anforderungsmeldung von einem Anforderer-Identitätsträger zu einem Serverprozess gesendet wird, so muss die Authentizität jeder Anforderung verifiziert werden. Die vorliegende Erfindung modifiziert Authentifizierungsverfahren des Standes der Technik durch Verwalten von zwei Arten "lokaler Cache-Speicher" 160 und 164 (eigentlich Tabellen von Daten, die im Speicher gespeichert sind), die Anforderer identifizieren, deren vorherige Anforderungsmeldungen authentifiziert wurden. Der lokale Cache 160 für den Authentifizierungsagenten listet den Kanal, den Unterkanal und den Auth-ID jedes Identitätsträgers auf, von dem Meldungen empfangen wurden. Der Datensatz 162 in dem lokalen Cache 160 für jeden solchen Identitätsträger enthält außerdem einen Identitätsträger-Identifikator, Berechtigungsdaten, die vom Hostcomputer des Identitätsträgers empfangen wurden und die die Meldungen des Identitätsträgers authentifizieren, und einen Zeitstempel, der ein Zeitlimit bezüglich der Gültigkeit dieser Berechtigungsdaten angibt.
Wenn eine Meldung eines Identitätsträgers authentifizierte wird, so wird ein Satz verschiedener Berechtigungsdaten versandt, um die Meldung zu authentifizieren, einschließlich Berechtigungsdaten, die den Knoten authentifizieren, sowie benutzerspezifische Berechtigungsdaten. Jedes Berechtigungsdatenelement hat ein zugehöriges Zeitlimit, das die Gültigkeit dieses Berechtigungsdatenelements begrenzt. Wenn ein Authentifizierungsagent einen Satz Berechtigungsdaten für einen bestimmten Anforderer empfängt, so speichert er in dem entsprechenden Datensatz 162 einen Zeitstempel, der das am kürzesten dauernde Zeitlimit darstellt, das den empfangenen Berechtigungsdaten zugeordnet ist. Das heißt, jedes empfangene Berechtigungsdatenelement wird mit einem Zeitlimit übermittelt (zum Beispiel ein Datenelement, das anzeigt, dass das entsprechende Berechtigungsdatenelement N Sekunden lang gültig ist), und der Authentifizierungsagent wandelt diese Zeitdauerbegrenzungen in einen Zeitwert um, der während späterer Versuche, den Datensatz 162 zu benutzen, mit dem aktuellen Zeitwert des Computers (der durch den Computer in Verbindung mit seiner Taktschaltung 126 verwaltet wird) verglichen wird.
Lokaler Auth-ID-Cache für Serverprozesse.
In der bevorzugten Ausführungsform verwaltet jeder Serverprozess einen lokalen Cache 164 in seinem eigenen Adressraum. Wie in 8 gezeigt, identifiziert jeder Datensatz 166 des lokalen Cache-Speichers des Serverprozesses einen Anforderer-Identitätsträger, von dem eine Anforderung zuvor empfangen wurde, den Auth-ID des Anforderers und den Unterkanal, über den Anforderungsmeldungen von diesem Anforderer empfangen wurden, einen Zeitstempel, der ein Zeitlimit bezüglich der Gültigkeit des Eintrages in dem lokalen Cache anzeigt, sowie eine Liste der ZKL-Einträge des Objekts, von denen man weiß, dass der Anforderer-Identitätsträger sie erfüllt.
Wie zuvor angesprochen, hat jedes Objekt eine zugehörige Zugangskontrollliste (ZKL). In der Regel enthält jede ZKL 136 eine Liste mit Einträgen, von denen jeder die Art des Zugangs angibt, die für einen bestimmten Identitätsträger gestattet wird. Wie in 9 gezeigt, besteht die ZKL 136 eines Objekts aus einem Satz Einträge 170 für jede eigenständige Art des Zugangs, die zu dem Objekt gehört. Wenn zum Beispiel ein Objekt ein Satz Daten ist, so ist es möglich oder sogar wahrscheinlich, dass einige Identitätsträger nur Lesezugriff haben, während andere Identitätsträger sowohl Lese- als auch Schreibzugriff haben. Jeder Eintrag 170 definiert einen Identitätsträger oder zusammengesetzten Identitätsträger, der befugt ist, auf das Objekt zuzugreifen.
Das Konzept zusammengesetzter Identitätsträger ermöglicht praktisch eine unbegrenzte Komplexität bei der Definierung eines Anforderers oder der Definierung einer Partei, die befugt ist, auf ein Objekt zuzugreifen. Zusammengesetzte Identitätsträger und ihre Verwendung in Computerzugangskontrollsystemen werden ausführlich in US 5315657 mit dem Titel "Compound Principals in Access Control Lists" und in US 5173939 mit dem Titel "Access Control Subsystem and Method for Distributed Computer System Using Compund Principals" besprochen.
Authentifizieren von Anforderungen.
Wenden wir uns dem Flussdiagramm in 10 zu. Immer, wenn eine Anforderungsmeldung zu einem Serverprozess an einem anderen Knoten übertragen wird, identifiziert der empfangende Knoten den Anforderer anhand des Kanals, über den das Datenpaket übertragen wurde, sowie anhand des Unterkanal- und des Auth-ID-Feldes 156 bzw. 150 in dem Datenpaket. Es ist zu beachten, dass, obgleich das Unterkanal-Feld 156 in der bevorzugten Ausführungsform sowohl Kanal- als auch Unterkanalwerte enthält, in anderen Ausführungsformen der Kanal auf andere Weise identifiziert werden könnte, wobei der resultierende Kanalwert zusammen mit dem empfangenen Datenpaket zu dem Serverprozess geleitet wird. In jedem Fall liegt es in der Zuständigkeit des Serverprozesses zu gewährleisten, dass der Unterkanalwert in der empfangenen Meldung dem tatsächlichen sicheren Kanal entspricht, auf dem die Anforderung empfangen wurde.
In der bevorzugten Ausführungsform erzeugt der Anfordererprozess die Anforderungsmeldung (Schritt 200), die einen vorgeblichen Auth-ID-Wert enthält, und der Authentifizierungsagent fügt die Kanal- und Unterkanalinformationen auf der Grundlage der Identitäten des Anforderer- und des Serverprozesses, zwischen denen das Datenpaket übertragen wird, zu dem entsprechenden Datenpaket hinzu (Schritt 202), bevor das Anforderungsmeldungs-Datenpaket zu dem Knoten übertragen wird, der zu dem Anforderer-Server gehört. Unter der Maßgabe, dass das Paket unbeschädigt an seinem vorgegebenen Zielknoten eintrifft, wird das Datenpaket in den Adressraum des spezifizierten Serverprozesses übermittelt (Schritt 204), zum Beispiel Prozess B1 von Knoten 102-1. Der Serverprozess B1 überprüft dann seinen lokalen Cache 164, um entsprechend der Identifizierung anhand der "Kanal-, Unterkanal- und Auth-ID"-Werte, die zu dem empfangenen Datenpaket gehören, nachzusehen, ob es bereits einen Eintrag für den Anforderer gibt (Schritt 206).
Wenn der Anforderer nicht in dem lokalen Cache 164 des Servers aufgelistet ist oder wenn der Eintrag 166 für den Anforderer nicht mehr gültig ist (gemäß Feststellung durch Vergleichen des Zeitstempelwertes in dem Eintrag 166 mit einem aktuellen Zeitwert, der durch den Computer in Verbindung mit seiner Taktschaltung 126 verwaltet wird), so fordert der Serverprozess den Autorisierungsagenten 134 für seinen Knoten auf, die Anforderungsmeldung authentifiziert (Schritt 208). Da der Authentifizierungsagent 134 für den Knoten des Servers möglicherweise schon bei einer früheren Transaktion Berechtigungsdaten für den Anforderer empfangen hat, sucht er in seinem lokalen Cache nach einem Datensatz, der mit dem Kanal, dem Unterkanal und dem Auth-ID der Anforderer-Meldung übereinstimmt (Schritt 210). Wenn der lokale Cache 160 des Authentifizierungsagenten einen Datensatz enthält, der mit dem Kanal, dem Unterkanal und dem Auth-ID, die zu der empfangenen Meldung gehören, übereinstimmt, und der Zeitstempelwert anzeigt, dass der Datensatz 162 für den Anforderer immer noch gültig ist, so bedeutet das, dass die Anforderungsmeldung "vorauthentifiziert" ist, wobei in einem solchen Fall der Authentifizierungsagent den Serverprozess darüber informiert, dass die Anforderungsmeldung authentisch ist (Schritt 212), und übermittelt an den Serverprozess den Zeitstempel und (optional) den Identitätsträger-ID für den Anforderer. Durch Einbinden des Identitätsträger-ID des Anforderers in den lokalen Cache 164 des Serverprozesses wird das Zugreifen auf Objekte mittels des Identitätsträger-ID des Anforderers effizienter gemacht.
Wenn der Auth-ID des Anforderers nicht in dem lokalen Cache 160 des Authentifizierungsagenten gefunden wird, so sendet der Authentifizierungsagent eine Anforderung an den Authentifizierungsagenten des Knotens des Anforderers für Berechtigungsdaten zum Authentifizieren der Anforderungsmeldung (Schritt 214). Der Authentifizierungsagent des Knotens des Anforderers überprüft die Authentizität der "Kanal-, Unterkanal- und Auth-ID"-Werte, die zu der Anforderungsmeldung gehören. Der erste Schritt dieses Überprüfungsprozesses ist das Durchsuchen seiner Kanalzuweisungstabelle 144 nach dem Anforderungsprozess, der zu dem Kanal und Unterkanal der Anforderungsmeldung gehört. Der zweite Schritt ist das Durchsuchen der Auth-ID-Tabelle 142, um nachzusehen, ob der spezifizierte Auth-ID-Wert einem Identitätsträger zugewiesen ist, der in den Prozess eingeloggt ist, der in der Kanalzuweisungstabelle 144 gefunden wurde. Wenn der Authentifizierungsagent feststellt, dass die "Kanal-, Unterkanal- und Auth-ID"-Werte, die zu der Anforderungsmeldung gehören, gültig sind, so sendet er an den Authentifizierungsagenten in dem Serverknoten den Identitätsträger-ID für den Anforderer sowie die angeforderten Berechtigungsdaten unter Verwendung einschlägig bekannter Digitalsignier-Protokolle, wodurch die Anforderungsmeldung authentifiziert wird (Schritt 215). Wenn der Authentifizierungsagent des Anforderer-Knotens feststellt, dass die "Kanal-, Unterkanal- und Auth-ID"-Werte, die zu der Anforderungsmeldung gehören, nicht gültig sind, so sendet er eine negative Bestätigung (nak-Meldung) zurück an den Authentifizierungsagenten des Serverknotens, der dann die Anforderungsmeldung ungültig macht.
Nach Erhalt der angeforderten Berechtigungsdaten speichert der Authentifizierungsagent des Serverknotens die Berechtigungsdaten in einem Datensatz 162 in seinem lokalen Cache 160 und informiert den Serverprozess darüber, dass die Anforderungsmeldung authentisch ist (Schritt 212). Der Serverprozess fügt dann zu seinem lokalen Cache 164 für den Anforderer, der zu der nun authentifizierten Anforderungsmeldung gehört, einen Datensatz 166 hinzu und fährt mit der Ausführung der angeforderten Aufgaben fort (Schritt 216).
Kehren wir zu Schritt 206 zurück. Wenn der Anforderer in dem lokalen Cache 164 des Servers aufgelistet ist und der Zeitstempel für den Anforderer anzeigt, dass die zuvor empfangenen Berechtigungsdaten für diesen Anforderer immer noch gültig sind, so fährt der Serverprozess mit der Ausführung der angeforderten Aufgaben fort (Schritt 218). Wenn der Serverprozess während der Ausführung dieser Aufgaben erfolgreich im Namen des Anforderers Zugriff auf Objekte erhält, so werden die ZKL-Einträge, die durch den Anforderer erfüllt werden, durch den Serverprozess zu dem Datensatz des Anforderers in dem lokalen Cache des Serverprozesses hinzugefügt (Schritt 220). Die Speicherung von ZKL-Einträgen, von denen man weiß, dass sie durch einen bestimmten Anforderer erfüllt werden, in dem lokalen Cache des Servers kann durch den Serverprozess dafür verwendet werden, die Gewährung des Zugriffs auf Objekte zu beschleunigen, auf die schon einmal zugegriffen wurde.
Der Authentifizierungsagent 134 für jeden Knoten überprüft periodisch seinen lokalen Cache 160 auf Datensätze mit abgelaufenen Berechtigungsdaten, so dass solche Datensätze zusammen mit den entsprechenden Datensätzen in den lokalen Cache-Speichern des Serverprozesses gelöscht werden können.
Obgleich die vorliegende Erfindung anhand weniger konkreter Ausführungsformen beschrieben wurde, ist die Beschreibung veranschaulichend für die Erfindung und darf nicht so verstanden werden, als würde sie die Erfindung beschränken.
Dem Fachmann fallen verschiedene Modifizierungen ein, ohne vom Geltungsbereich der Erfindung, wie er in den angehängten Ansprüchen definiert ist, abzuweichen. Es ist zu beachten, dass der Authentifizierungsagent als eine Abstraktion betrachtet werden kann, die verschiedene Teile eines Betriebssystems oder sogar verschiedene sichere Programme, wie zum Beispiel vertrauenswürdige Anwendungen, die auf dem Betriebssystem ablaufen, darstellt, die die Sicherheitsfunktionen der oben beschriebenen Erfindung ausführt.

Claims

Sicherheitsvorrichtung zur Verwendung in einem verteilten Computersystem (100) mit einer Vielzahl miteinander verbundener Computer (102-1 ... 102-N), wobei die Sicherheitsvorrichtung Folgendes umfasst: mehrere Prozesse, wobei jeder Prozess auf einem der Vielzahl von Computern abläuft, wobei die mehreren Prozesse Anfordererprozesse (A1, A2) und Serverprozesse (B1 ... BN) enthalten; sichere Kanäle (140), die erste der Vielzahl von Computern, auf denen jeweilige der Anfordererprozesse ablaufen, mit zweiten der Vielzahl von Computern, auf denen jeweilige der Serverprozesse ablaufen, verbinden; und eine Vielzahl von Authentifizierungsagenten (134-1 ... 134-N), die jeweils in einer vertrauenswürdigen Rechenbasis (135) auf einem anderen der Vielzahl miteinander verbundener Computer ablaufen, wobei einer der Vielzahl von Authentifizierungsagenten, der auf einem der Vielzahl von Computern abläuft, auf denen wenigstens ein Serverprozess abläuft, Folgendes enthält: ein lokales Cache-Mittel (160, 164) zum Speichern von Daten, die zuvor authentifizierte Anforderungen von einem oder mehreren der Anfordererprozesse, die auf anderen der Vielzahl miteinander verbundener Computer ablaufen, identifizieren; und ein Mittel (162) zum Authentifizieren empfangener Anforderungen, um im Namen des wenigstens einen Serverprozesses eine empfangene Anforderung zu authentifizieren, wenn Daten in der empfangenen Anforderung mit den Daten übereinstimmen, die in dem lokalen Cache-Mittel gespeichert sind, und um Berechtigungsdaten zu erhalten, welche die empfangene Anforderung authentifizieren, wenn die Daten in der empfangenen Anforderung nicht mit den Daten übereinstimmen, die in dem lokale Cache-Mitteln gespeichert sind.
Sicherheitsvorrichtung nach Anspruch 1, wobei: jeder Anfordererprozess (A1, A2) ein Mittel zum Erzeugen einer Anforderung zum Initiieren der Übertragung der Anforderung über einen der sicheren Kanäle (140) zu einem bestimmten der Serverprozesse (B1 ... BN) enthält; und jeder Serverprozess Folgendes enthält: ein Cache-Mittel (164) zum Verwalten seines eigenen lokalen Caches aus Daten, die zuvor authentifizierte Anforderungen identifizieren, die durch den Serverprozess empfangen wurden; und ein lokales Authentifizierungsmittel (162) zum Authentifizieren einer empfangenen Anforderung, wenn die ersten Daten in der empfangenen Anforderung mit den Daten übereinstimmen, die in seinem eigenen Cache-Mittel gespeichert sind, und zum Anfordern einer Authentifizierung der empfangenen Anforderung durch den Authentifizierungsagenten, der auf demselben Computer abläuft wie der Serverprozess, wenn die Daten in der empfangenen Anforderung nicht mit den Daten überein stimmen, die in seinem eigenen Cache-Mittel gespeichert sind.
Sicherheitsvorrichtung nach Anspruch 1 oder 2, wobei das lokale Cache-Mittel (160, 164) ein Mittel zum zeitlichen Begrenzen der Gültigkeit der Daten, die zuvor authentifizierte Anforderungen identifizieren, enthält; und das Mittel (162) zum Authentifizieren empfangener Anforderungen ein Mittel enthält, um Daten in der empfangenen Anforderung nicht mit ungültigen Daten in dem lokalen Cache-Mittel in Übereinstimmung zu bringen.
Sicherheitsvorrichtung nach Anspruch 1, wobei: jeder Anfordererprozess ein Mittel zum Erzeugen einer Anforderung und zum Initiieren der Übertragung der Anforderung über einen der sicheren Kanäle zu einem bestimmten der Serverprozesse enthält; die Daten in der empfangenen Anforderung von dem Anfordererprozess (A1, A2) ein erstes Datenelement enthalten, das vorgeblich einen Identitätsträger identifiziert, der dem Anfordererprozess zugeordnet ist; und jeder Authentifizierungsagent (134-1 ... 134-N), der auf einem der Vielzahl von Computern abläuft, auf dem wenigstens ein Anfordererprozess abläuft, Folgendes enthält: ein Anforderungsverarbeitungsmittel zum Hinzufügen eines zweiten Datenelements zu jeder Anforderung, die durch einen Anfordererprozess erzeugt wird, der auf demselben der Vielzahl von Computern wie der Authentifizierungsagent abläuft, wobei das zweite Datenelement eindeutig dem hervorbringenden Anfordererprozess entspricht; und ein Anforderungsauthentifizierungsmittel zum Authentifizieren, dass das erste Datenelement und das zweite Datenelement in einer zuvor gesandten Anforderung gültig sind.
Sicherheitsvorrichtung nach Anspruch 4, wobei: das Mittel (162) zum Authentifizieren empfangener Anforderungen eine empfangene Anforderung authentifiziert, wenn das erste und das zweite Datenelement in der empfangenen Anforderung mit den Daten übereinstimmen, die in dem lokalen Cache-Mittel (160, 164) gespeichert sind, und die Authentifizierung der empfangenen Anforderung von dem Authentifizierungsagenten (134-1 ... 134-N) erhält, der auf demselben Computer läuft wie der Anfordererprozess, der die empfangene Anforderung sandte, wenn das erste Datenelement und das zweite Datenelement in der empfangenen Anforderung nicht mit den Daten übereinstimmen, die in dem lokalen Cache-Mittel gespeichert sind.
Verfahren zum Betreiben eines verteilten Computersystems (100), das eine Vielzahl miteinander verbundener Computer (102-1 ... 102-N) aufweist, wobei das Verfahren Folgendes umfasst: Ablaufenlassen von Anfordererprozessen (A1, A2) auf wenigstens ersten der Vielzahl von Computern und Ablaufenlassen von Serverprozessen (B1 ... BN) auf wenigstens zweiten der Vielzahl von Computern; Verbinden von ersten der Vielzahl von Computern, auf denen jeweilige der Anfordererprozesse ablaufen, über sichere Kanäle (140) mit zweiten der Vielzahl von Com putern, auf denen jeweilige der Serverprozesse ablaufen; Etablieren von Authentifizierungsagenten (134-1 ... 134-N) innerhalb einer vertrauenswürdigen Rechenbasis (135) auf jedem der Vielzahl von Computern; wobei auf den Authentifizierungsagenten wenigstens ein Serverprozess abläuft, zum: Verwalten eines lokalen Cache (164) aus Daten, die zuvor authentifizierte Anforderungen, die durch den wenigstens einen Serverprozess empfangen wurden, identifizieren; und Authentifizieren – im Namen des wenigstens einen Serverprozesses – einer empfangenen Anforderung, wenn die Daten in der empfangenen Anforderung mit den Daten in dem lokalen Cache übereinstimmen; und Erhalten von Berechtigungsdaten, welche die empfangene Anforderung authentifizieren, von dem Authentifizierungsagenten, der auf dem Computer etabliert wurde, auf dem der Anfordererprozess abläuft, welcher die empfangene Anforderung sandte, wenn die Daten in der empfangenen Anforderung nicht mit den Daten übereinstimmen, die in dem lokalen Cache gespeichert sind.
Verfahren nach Anspruch 6, wobei der Anfordererprozess (A1, A2) Anforderungen erzeugt und die Übertragung der Anforderungen über einen oder mehrere der sicheren Kanäle (140) zu bestimmten der Serverprozesse initiiert, wobei die Anforderungen jeweils ein erstes Datenelement enthalten, das vorgeblich einen Identitätsträger identifiziert, der jedem Anfordererprozess zugeordnet ist.
Verfahren nach Anspruch 7, wobei die Authentifizierungsagenten (134-1 ... 134-N) jeder Anforderung, die durch die Anfordererprozesse erzeugt wurde, ein zweites Datenelement hinzufügt, das eindeutig dem einen der Anfordererprozesse entspricht, der jede Anforderung erzeugte.
Verfahren nach Anspruch 8, wobei jeder Serverprozess (B1 ... BN) seinen eigenen lokalen Cache (164) aus Daten verwaltet, welche das erste Datenelement und das zweite Datenelement in zuvor empfangenen authentifizierten Anforderungen, die durch den Serverprozess empfangen wurden, anzeigen; und jeder Serverprozess eine empfangene Anforderung selbst-authentifiziert, wenn das erste Datenelement und das zweite Datenelement in der empfangenen Anforderung mit den Daten übereinstimmt, die in seinem eigenen Cache-Mittel gespeichert sind, und eine Authentifizierung der empfangenen Anforderung durch den Authentifizierungsagenten, der auf demselben Computer abläuft wie der Serverprozess, anfordert, wenn das erste Datenelement und das zweite Datenelement in der empfangenen Anforderung nicht mit den Daten übereinstimmen, die in seinem eigenen Cache-Mittel gespeichert sind.
Verfahren nach Anspruch 6, 7, 8 oder 9, wobei die Authentifizierungsagenten (134-1 ... 134-N) die Gültigkeit der Daten, die für jede zuvor authentifizierte Anforderung in dem lokalen Cache gespeichert sind, zeitlich begrenzen; und die Authentifizierungsagenten eine empfangene Anforderung nicht im Namen des wenigstens einen Serverprozes ses authentifizieren, wenn das erste Datenelement und das zweite Datenelement in der empfangenen Anforderung mit ungültigen Daten in dem lokalen Cache übereinstimmen.