DE10024347A1 - Sicherheitsservice-Schicht - Google Patents

Abstract

Sicherheitsserviceschicht und Verfahren zum Steuern einer Kommunikation zwischen einem eine Anwendung ausführenden Client und einem Target, wobei eine die Kommunikation beschreibende Parameter beinhaltende Nachricht analysiert wird und basierend auf dem Analyseergebnis zumindest einer Serviceroutine von einer Anzahl von zur Verfügung stehenden Serviceroutinen ausgewählt wird. Die Kommunikation wird dann basierend auf den ausgewählten Serviceroutinen gesteuert. Die Erfindung erlaubt es, dass der Client und die am Client laufende Anwendung sicherheitsunabhängig ablaufen, da alle sicherheitsrelevanten Funktionen durch die Sicherheitsserviceschicht im Dienst der Anwendung ausgeführt werden. Anwendungsabhängige Serviceroutinen werden dynamisch während der Kommunikation zwischen dem Client und dem Target ausgewählt. Eine Serviceroutine kann Sicherheitsmechanismen oder Unterstützungsmechanismen beinhalten, wie beispielsweise Datenhandhabung.

Description

TECHNISCHES GEBIET

Die Erfindung betrifft eine Sicherheitsservice- Schichtvorrichtung für ein Steuern einer Kommunikation zwischen einem Client, der eine Anwendung ausführt, und einem Target über einen Kommunikationskanal. Weiter betrifft die Erfindung ein Verfahren zum Steuern einer Kommunikation zwischen einem Client, der eine Anwendung ausführt, und einem Target (Ziel) über einen Kommunikationskanal.

HINTERGRUND DER ERFINDUNG

Eine immer größere Zahl von sicherheitsrelevanten Übermittlungen und Transaktionen werden unter Verwendung heutiger Kommunikationsnetzwerke durchgeführt. Beispielsweise wird eine immer größere Anzahl von Banktransaktionen unter Verwendung von weltweiten Datennetzwerken ausgeführt, was es ermöglicht, dass ein Nutzer sich an einem Ort befindet, der unabhängig von dem Ort der dienstleistenden Institution ist. Es ist jedoch ein naturgemäßes Merkmal dieser internationalen Datennetzwerke, dass allgemein von jedermann für jeden Zweck auf diese Netze zugegriffen werden kann und daher müssen Datentransaktionen, wie beispielsweise die obige Banktransaktion, gegen ein unautorisiertes Lesen oder Entschlüsseln von in Verbindung mit einer Transaktion ausgetauschten Nachrichten, Kennwörtern, Bestätigungen und ähnlichem, gesichert werden. Das gleiche kann beispielsweise auch für Teilnehmer eines Mobiltelefondienstes gelten, die auf persönliche Teilnehmerdaten über ein Netzwerk zugreifen, Forschungsinstitutionen, die Daten austauschen, oder Kunden, die Kreditkarteninformationen über ein Netzwerk für Kaufzwecke übermitteln.

Viele unterschiedliche Ansätze zum Sichern einer Datenübertragung über öffentliche Netzwerke stehen zur Verfügung, einschließlich beispielsweise Kennwörter, Verschlüsselungen und Zugriffssteuerungen, beispielsweise an einem Targetserver (Ziel-Server), der nur begrenzten Zugriff und/oder einen begrenzten Satz von Aktionen nach einem Zugriff erlaubt. Die Anzahl von unterschiedlichen Typen von zur Verfügung stehenden und notwendigen Sicherheitsvorkehrungen und die Anzahl von unterschiedlichen Einheiten, die unterschiedliche Anwendungen nutzen, und über heutige Netzwerke kommunizieren, erfordert einen beträchtlichen Programmierungsoverhead, wenn Anwendungen (Applikationen) geschrieben werden, die sicherheitsempfindliche Datenübermittlungen über ein Netzwerk benötigen.

Eine sicherheitsrelevante Datenübermittlung über ein Netzwerk könnte als den folgenden Schritten folgend gedacht werden.

Eine Anwendung, die auf einem Clientserver läuft und plant, auf ein Target (an einem Server laufend, beispielsweise einer Bank) zuzugreifen, wobei das Target vorzugsweise auch eine Anwendung ausführt, erzeugt eine Nachricht für eine Übermittlung von dem Client zum Server. Da diese Nachricht gegen unautorisiertes Lesen geschützt werden muss, wird die Nachricht für eine Übermittlung verschlüsselt und weiter werden am Target bestimmte Zugriffsrechte in Abhängigkeit von der Anwendung und dem Typ der Kommunikation eingestellt.

Für eine erfolgreiche Datenübermittlung muss die am Client ausgeführte Anwendung und der Server beispielsweise den gleichen Satz von Verschlüsselungs/Entschlüsselungswerkzeugen verwenden und daher muss die Anwendung am Client und die Anwendung am Target, verwendet für ein Empfangen und Verarbeiten der übermittelten Nachricht, aneinander angepasst sein. Daraus ergibt sich jedoch das Problem, das jeder Typ von Anwendung, der auf einen Server oder Target zugreift, voll kompatibel mit der Software am Server sein muss, einschließlich Sicherheitsaspekten. Im Fall, dass eine große Anzahl von Anwendungen dazu ausgelegt ist, auf den Server zuzugreifen, sind beträchtliche Programmierungsaufwendungen notwendig, um die Software am Server kompatibel mit allen Anwendungen zu halten.

Das Sichern von Managementanwendungen in einer verteilten Umgebung ist eine der Herausforderungen für Softwaredesigner und Programmierer von Managementanwendungen und es ist wünschenswert, anwendungsspezifische Routinen, die einer Übermittlung von Information von der Anwendung zu einem Server dienen, und sicherheitsrelevante Aktivitäten zu trennen, so dass jede Gruppe von Aktivitäten durch unterschiedliche Einheiten des Systems ausgeführt werden kann.

Eine Anzahl von unterschiedlichen Ansätzen zum Gruppieren von anwendungsrelevanten Aktionen und sicherheitsrelevanten Aktionen bei einer Datenkommunikation über ein Netzwerk wurden vorgeschlagen, von denen eine CORBA (Common Object Request Broker Architecture) ist, wie beispielsweise beschrieben in "CORBA", Object Management Group, The CORBA Security Service Specification (Version 1.5), Dezember 1998.

CORBA ist eine verteilte Plattformschicht (Layer), die an Einheiten zur Verfügung steht, die über ein Netzwerk kommunizieren, beispielsweise an einem Client und an einem Target. CORBA erlaubt die Ausführung einer Anzahl von Serviceroutinen während einer Kommunikation zwischen einem Client, der eine Anwendung ausführt, und einem Target oder Server, der vorzugsweise auch eine Anwendung ausführt. Bei einem Zugriff durch den Client ruft der verteilte CORBA Layer einen vorbestimmten Satz von Sicherheitsaktivitäten auf, die in Verbindung mit vom Client zu übermittelnden Daten ausgeführt werden. Dies kann eine Sicherheitszuweisung (Security Association), Zugriffssteuerung, Nachrichtenschutz, Audit oder ähnliches einschließen. An der Targetseite erlaubt der CORBA-Layer die Ausführung von entsprechenden Sicherheitsaktivitäten, um eine erfolgreiche Datenübermittlung vom Client zum Target zu ermöglichen. Dies kann, wie zuvor am Client, Sicherheitszuweisung, Zugriffssteuerung, Nachrichtenschutz, Audit und ähnliches betreffen.

Die durch die CORBA Schicht ausgeführten Sicherheits- oder Unterstützungsaktivitäten werden nur zur Zugriffszeit aufgerufen, d. h. zu einer Zeit, zu der der Client auf das Netzwerk für eine Datenübertragungssitzung zugreift. Weiter sind die durch CORBA ausgeführten Sicherheitsaktivitäten nur vom Client abhängig, sind jedoch nicht dazu ausgelegt, von einer bestimmten Anwendung abhängig zu sein, d. h. die aufgerufenen Sicherheitsaktivitäten sind unabhängig vom Typ der Anwendung oder Kommunikation, die der Client ausführt. Beispielsweise werden bestimmte Serviceroutinen bezüglich einer Übertragung von sicherheitsrelevanten Daten zu einer Bank (oder von einem Bankserver zu einem Kunden), oder eine Übermittlungsanforderung von einem Client zu einem Server eines Telekommunikationsdienstes, um teilnehmerrelevante Daten abzurufen, nicht durch CORBA unterstützt.

Unter CORBA hat die Anwendung selbst weitere sicherheitsrelevante Funktionen auszuführen, betreffend die Anwendung selbst oder die ausgeführte Datenübermittlung, einschließlich beispielsweise Zugriffssteuerung, Non- Repudiation, Audit, Delegation oder ähnliches. Weiter hat das Target (das auch eine Anwendung ausführt) und eine Datenübermittlung von der Clientanwendung empfängt, entsprechende Sicherheitsaktivitäten auszuführen, beispielsweise einschließlich Targetanwendungszugriffssteuerung, Non-Repudiation, Audit, Delegation oder ähnliches.

Fig. 5 zeigt eine Sicherheitsserviceanordnung einschließlich eines Client 200, eines Target 210 und einer verteilten Schicht (Layer) 220, beispielsweise eine CORBA Common Object Request Broker Architecture Schicht. Der Client führt eine Anwendung 201 aus, und das Target kann eine entsprechende Anwendung 211 ausführen. Wie oben beschrieben, führen in dieser Anordnung auf der einen Seite die verteilte Plattformschicht und auf der anderen Seite der Client und das Target sicherheitsrelevante Aktivitäten aus, wobei die Aktivitäten auf der Ebene der verteilten Plattformschicht anwendungsunabhängig sind, und die Sicherheitsaktivitäten, die am Client und am Target ausgeführt werden, anwendungsabhängige Sicherheitsaktivitäten sind.

Obwohl diese Architektur einen Vorteil gegenüber dem eingangs beschriebenen grundlegenden System aufweist, wobei alle sicherheits- oder unterstützungsrelevanten Aktivitäten am Client ausgeführt werden, genauer gesagt durch die Anwendung, die am Client ausgeführt wird, und am Target, d. h. der Software oder Anwendung, die am Target ausgeführt wird und die Nachricht von der Clientanwendung erhält, müssen sicherheits- oder unterstützungsrelevante Aktivitäten immer noch durch die Anwendung ausgeführt werden, die am Client läuft, und möglicherweise der am Target laufenden Anwendung. Mit anderen Worten werden Sicherheits- oder Unterstützungsaktivitäten, die vom Zugriff des Clients auf das Netzwerk abhängen, von der Anwendung zur verteilten Plattformschicht, die einen Teil des Netzwerks bildet, verschoben, wohingegen Service- oder Unterstützungsroutinen in Abhängigkeit von der am Client (und Target) laufenden Anwendung auf Anwendungsebene verbleiben.

Es besteht somit immer noch ein Nachteil bei dem mit Bezug auf Fig. 5 beschriebenen System, und sicherheits- oder unterstützungsrelevante Gesichtspunkte müssen immer noch durch Anwendungen behandelt werden, was immer noch erhebliche Programmierungsanstrengungen erfordert.

Aufgrund der Komplexität der Handhabung von Sicherheitsmaßnahmen ist es wünschenswert, einen bestimmten Bestandteil mit der Behandlung aller Sicherheitsmaßnahmen zu beauftragen, die benötigt werden, um eine Managementanwendung auf sichere Weise auszuführen.

ZUSAMMENFASSUNG DER ERFINDUNG

Es ist Aufgabe der Erfindung, ein verbessertes System und Verfahren zum Steuern einer Kommunikation zwischen einem Client, der eine Anwendung ausführt, und einem Target über einen Kommunikationskanal bereitzustellen, was verminderte Programmierungsoverhead erfordert, wenn Anwendungen oder Anwendungswerkzeuge erstellt werden.

Diese Aufgabe der Erfindung wird durch eine Sicherheitsserviceschichtvorrichtung zum Steuern einer Kommunikation zwischen einem Client, der eine Anwendung ausführt, und einem Target über einen Kommunikationskanal mit den Merkmalen des Anspruchs 1 gelöst.

Die Aufgabe der Erfindung wird weiter durch ein Verfahren zum Steuern einer Kommunikation zwischen einem Client, der eine Anwendung ausführt, und einem Target über einen Kommunikationskanal mit den Merkmalen des Anspruchs 11 gelöst.

Die Erfindung erlaubt vorteilhaft, dass Anwendungen auf einer Clientseite laufen können, ohne auf sicherheitsrelevante Gesichtspunkte eingehen zu müssen, d. h. erlaubt ein sicherheitsunabhängiges Laufen der Anwendung am Client und am Target. Weiter erlaubt die Erfindung, dass Anwendungen ohne Berücksichtigung von Unterstützungsaktivitäten laufen, die nicht sicherheitsbezogen sind. Die Sicherheitsserviceschichtvorrichtung und das Verfahren arbeitet für eine Anwendung und erlaubt, dass die Anwendung sicherheitsunabhängig und/oder unterstützungsunabhängig läuft.

Die Erfindung erlaubt es vorteilhaft, dynamisch eine geeignete Serviceregel von einem Serviceregelmanager auszuwählen, der alle erforderlichen Servicefunktionen liefert. Dies kann beispielsweise Sicherheits- oder Unterstützungsaktivitäten einschließen. Damit erlaubt die Erfindung ein Zugreifen auf und Steuern von Sicherheits- und/oder Unterstützungsfunktionen, beispielsweise solchen, die durch weitere darunter liegende Sicherheits- und Unterstützungswerkzeuge bereitgestellt werden.

Die Sicherheitsservicelayervorrichtung der Erfindung kann vorteilhafterweise weiter eine Clientseite-Auswahlvorrichtung umfassen, die an der Clientseite angeordnet ist und mit einer ersten Datenbank verbunden ist, die Serviceroutinen speichert, die am Client zur Verfügung stehen, und eine Targetseite-Auswahlvorrichtung, die an der Targetseite angeordnet ist und mit einer zweiten Datenbank verbunden ist, die am Target zur Verfügung stehende Serviceroutinen speichert, wobei die Auswahl von der zumindest einen Serviceroutine auf der Verfügbarkeit von Serviceroutinen am Client und am Target basiert, und dabei die Verfügbarkeit in einer Verhandlung zwischen der ersten und zweiten Auswahlvorrichtung vor einer Übermittlung der Nachricht festgestellt wird.

Die Steuervorrichtung kann weiter eine Clientseite- Steuervorrichtung umfassen, die an der Clientseite angeordnet ist, und eine Targetseite-Steuervorrichtung, die an der Targetseite angeordnet ist.

Die Auswahlvorrichtung kann dazu vorgesehen sein, zumindest eine Serviceroutine von einer Gruppe von anwendungsunabhängigen Serviceroutinen und anwendungsabhängigen Serviceroutinen auszuwählen.

Die Parameter können den Client, das Target und den Anwendungstyp beschreiben.

Eine Serviceroutine kann einen Sicherheitsmechanismus und/oder einen nicht mit Sicherheit in Beziehung stehenden Unterstützungsmechanismus enthalten.

Die Serviceroutine kann ein Steuern von einem Interface und/oder Zugriff auf das Target und/oder eine Ausführung eines Verarbeitungsverfahrens betreffen.

Weiter kann die Serviceroutine ein Codieren und Decodieren der vom Client zum Target zu übermittelnden Nachricht betreffen.

Die Serviceroutine kann Information bezüglich der Serviceroutine selbst einbeziehen, einschließlich Lebensdauer und Version.

Die Nachrichtvorrichtung kann einen Teil der Anwendung darstellen, die am Client ausgeführt wird, und die Nachricht kann eine Anforderung oder eine Benachrichtigung darstellen.

Weitere vorteilhafte Merkmale der Erfindung werden in weiteren abhängigen Ansprüchen offenbart.

KURZE BESCHREIBUNG DER FIGUREN

Fig. 1 zeigt ein Blockdiagramm der Erfindung gemäss einem ersten Ausführungsbeispiel,

Fig. 2 zeigt ein Flussdiagramm von während einer Kommunikation zwischen einem Client und einem Target gemäss der vorliegenden Erfindung ausgeführten Schritten,

Fig. 3 zeigt ein Blockdiagramm eines zweiten Ausführungsbeispiels der Erfindung,

Fig. 4 zeigt ein Flussdiagramm eines Betriebs gemäss des zweiten Ausführungsbeispiels der Erfindung, und

Fig. 5 zeigt eine Sicherheitsservicearchitektur des Standes der Technik.

DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE

Im folgenden werden die Ausführungsbeispiele der Erfindung mit Bezug auf die Fig. 1 bis 4 beschrieben.

Im folgenden wird mit Bezug auf Fig. 1 ein erstes Ausführungsbeispiel der Erfindung beschrieben.

In Fig. 1 bezeichnet ein Bezugszeichen 10 einen Client, der ein Nutzer eines Telebanking-Dienstes sein kann, oder beispielsweise ein Teilnehmer eines Telekommunikationsdienstes, oder allgemein ein beliebiger Nutzer eines Datendienstes. Der Client 10 führt eine Anwendung aus, um mit einem Target 20 in einer Kommunikationssitzung zu kommunizieren, beispielsweise um eine Nachricht zu senden, eine Benachrichtigung, eine Anforderung und ähnliches. Das Target kann ein Bankserver oder ein Telekommunikationsdienstserver sein und wird vorzugsweise auch eine Anwendung ausführen, um mit der clientseitigen Anwendung zu kommunizieren. Es ist auch möglich, dass Teile einer verteilten Anwendung am Client und Target laufen. Während der Kommunikation, beispielsweise wenn das Target auf eine Anforderung mit einer Bestätigung antwortet, kann das Target die Funktion des Clients übernehmen und der Client kann die Funktion des Targets übernehmen. Das Target kann ein Server eines Systems sein, auf das zugegriffen wird, oder irgendeine andere antwortende Datenverarbeitungsvorrichtung.

Wie aus Fig. 1 ersichtlich ist der Client 10 mit einer Nachrichtenvorrichtung 30 zum Erzeugen einer Nachricht für eine Übermittlung vom Client zum Target verbunden, wobei die Nachricht zumindest Parameter beinhaltet, die die Kommunikation und die am Client laufende Anwendung bestimmen. Es ist auch möglich, dass die Anwendung die Funktion der Nachrichtenvorrichtung 30 übernimmt und die Nachricht selbst erzeugt. Die Nachricht kann eine Anforderung oder eine Benachrichtigung sein, beispielsweise um Daten vom Target abzurufen, oder um Daten vom Client zum Target zu übermitteln.

Die Nachrichtenvorrichtung 30 ist mit einer Analysevorrichtung 40 verbunden, um die Parameter der vom Client zum Target 20 über einen physikalischen Kommunikationskanal oder eine Luftschnittstelle zu übermittelnden Nachricht zu analysieren. Mittel für eine Verbindung zwischen der Nachrichtenvorrichtung 30 und der Analysevorrichtung 40 können beispielsweise ein lokales Netzwerk oder ähnliches sein.

Die Analysevorrichtung ist mit einer Auswahlvorrichtung 50 verbunden, um zumindest eine Serviceroutine von einer Anzahl von zur Verfügung stehenden Serviceroutinen basierend auf den Parametern auszuwählen. Die Serviceroutinen können beispielsweise von einem externen Serviceroutinenspeicher 80 oder einer anderen Datenbank ausgewählt werden.

Eine Serviceroutine kann sicherheitsrelevante Mechanismen bestimmen, einschließlich sicherheitsrelevanter Instruktionen an andere Einheiten, beispielsweise eine darunter liegende Kommunikationsschicht. Weiter kann eine Serviceroutine bestimmte Unterstützungsmechanismen oder Instruktionen bestimmen, die nicht mit Sicherheitsmechanismen in Verbindung stehen, wie beispielsweise Datenhandhabung und ähnliches. Eine Serviceroutine kann sicherheits- und unterstützungsbezogene Aktivitäten zur gleichen Zeit bestimmen.

Die Auswahlvorrichtung 50 ist mit einer Steuervorrichtung 60 und einer verteilten Plattformschicht 70 verbunden, um die Kommunikation einschließlich der Übermittlung der Nachricht basierend auf der zumindest einen ausgewählten Serviceroutine zu steuern. Weiter kann die Auswahlvorrichtung 50 mit der Datenbank 80 zum Speichern einer Anzahl von zur Verfügung stehenden Serviceroutinen entweder direkt oder durch ein Netzwerk verbunden sein, einschließlich der verteilten Plattformschicht 70.

Die Auswahlvorrichtung 50 und die Steuervorrichtung 60 können verteilte Schichtvorrichtungen sein, ähnlich der verteilten Plattformschicht 70. Mit anderen Worten können Einheiten der Auswahlvorrichtung 50, der Steuervorrichtung 60 und der verteilten Plattformschicht 70 auf der Clientseite und an der Targetseite angeordnet sein, und durch ein physikalisches Übermittlungsmedium verbunden sein.

In Fig. 1 enthält der mit 100 bezeichnete Kasten die Hauptbestandteile der Sicherheitsserviceschichtvorrichtung gemäss der Erfindung.

Die Sicherheitsserviceschicht gemäss der Erfindung ist dazu ausgebildet, eine Kommunikation zwischen einem eine Anwendung ausführenden Client 10 und einem Target, das vorzugsweise auch eine Anwendung ausführt, zu steuern. Um eine Ausführung von sicherheitsrelevanten Routinen auf dem Anwendungsniveau zu vermeiden, wird gemäss der Erfindung die Ausführung von sicherheitsrelevanten und/oder unterstützungsrelevanten Routinen einer Schicht zugewiesen, die zwischen dem Client und der tatsächlichen Übermittlungsschicht oder -medium angeordnet ist, bzw. ebenso zwischen dem Target und der tatsächlichen Übermittlungsschicht oder -medium.

Die tatsächliche Übermittlungsschicht kann beispielsweise CORBA (Common Object Request Broker Architecture), DCOM, OSF DCE etc. oder andere zur Verfügung stehende verteilte Plattformschichten sein.

Die Sicherheitsserviceschicht der Erfindung ist dazu angeordnet, eine Nachricht von einer Nachrichtenvorrichtung oder Anwendung zu empfangen, und die Parameter der Nachricht zu analysieren, wobei die Parameter zumindest einen Bestandteil der Gruppe aus Client, dem Target, dem Applikationstyp, und einem Kommunikationstyp bestimmen können. Basierend auf dem von der Analysevorrichtung 40 erhaltenen Analyseergebnis führt die Auswahlvorrichtung eine Auswahl zumindest einer Serviceroutine von beispielsweise einer Datenbank aus, die eine Anzahl von zur Verfügung stehenden Serviceroutinen speichert. Da die Serviceroutinen dynamisch bei Empfang einer Nachricht während der Ausführung einer Anwendung ausgewählt werden, kann die Auswahl von Serviceroutinen abhängig von einem gegenwärtigen Ausführungszustand der Anwendung sein, beispielsweise mit Bezug auf eine bestimmte Datenübermittlung, Anforderung und ähnlichem.

Es ist möglich, dass eine einzelne Serviceroutine aufgrund einer bestimmten Nachricht ausgewählt wird oder dass ein Satz von Serviceroutinen ausgewählt wird.

Die Routinen können anwendungsabhängige Serviceroutinen sein, d. h. Routinen, die von einer Anwendung abhängen, dem Zustand der Anwendung oder einer bestimmten Anwendungskommunikation, die durch die Anwendung angesetzt wird. Weiter können die Serviceroutinen anwendungsunabhängige Serviceroutinen sein, beispielsweise nur abhängig vom Client. Anwendungsabhängige Serviceroutinen und anwendungsunabhängige Serviceroutinen können zusammen ausgewählt werden.

Bei Abruf einer oder einer Vielzahl von Serviceroutinen von der Datenbank 80 fährt die Steuervorrichtung damit fort, die Kommunikation zwischen dem Client und dem Target zu steuern, einschließlich einer Übermittlung der Nachricht vom Client zum Target. Die Serviceroutinen können ein Steuern einer Schnittstelle, Zugriff auf das Target betreffen, oder die Ausführung eines Verarbeitungsverfahrens wie beispielsweise Codieren und Decodieren der vom Client zum Target zu übermittelnden Nachricht. Dies kann auch sicherheitsrelevante Aktivitäten oder Unterstützungsaktivitäten einbeziehen, wie beispielsweise Datenhandhabung. Eine einzelne Serviceroutine kann somit Sicherheitsmechanismen oder Unterstützungsmechanismen betreffen, oder sowohl Sicherheitsmechanismen als auch Unterstützungsmechanismen. Sicherheits- und Unterstützungsmechanismen können selbst Algorithmen zum Verarbeiten einbeziehen oder Instruktionen bezüglich einer Verarbeitung durch andere Einheiten, beispielsweise ausgeführt durch eine darunter liegende Kommunikationsschicht.

Um effektive Sicherheits- und/oder Unterstützungsvorkehrungen zu haben, werden Serviceroutinen vorzugsweise auf der Clientseite vor einer Übermittlung der Nachricht vom Client zum Target ausgeführt. Weiter werden die Serviceroutinen auch an der Targetseite ausgeführt, oder entsprechende Teile der Serviceroutinen, beispielsweise ein Entschlüsselungsalgorithmus, z. B. zum Steuern eines Zugriffs auf das Target oder ein Decodieren von Daten oder Nachrichten vom Client, oder eine Datenhandhabung. Um eine sichere Übermittlung und Zugriff auf das Target zu ermöglichen sind die Serviceroutinen vorzugsweise sowohl am Client als auch am Target verfügbar. Bei einer Auswahl der Serviceroutine basierend auf dem Analyseergebnis von der Analysevorrichtung 40, können die Serviceroutinen sowohl am Client als auch am Target ausgeführt werden. Die Serviceroutinen können unabhängig sowohl am Client und am Target abgerufen werden, so dass sie nicht im Zusammenhang mit der zwischen dem Client und Target eingerichteten Kommunikation übermittelt werden müssen.

Die Erfindung erlaubt, dass der Client und die Anwendung, die am Client läuft, sicherheitsunabhängig laufen und/oder unterstützungsunabhängig, da alle sicherheits- und/oder unterstützungsrelevanten Funktionen für die Anwendung durchgeführt werden durch die Analysevorrichtung 40, Auswahlvorrichtung 50 und Steuervorrichtung 60, basierend auf der durch die Nachrichtenvorrichtung 30 erzeugten Nachricht, die die Anwendung, den Client, das Target und den Typ der Kommunikation und ähnliches bestimmt.

Eine Anwendung ist mit Sicherheit befasst (sicherheitsabhängig, security-aware), falls sie aktiv an einer Sicherheitsbereitstellung für verwendete Daten teilnimmt oder auf die Umgebung einwirkt, um umgebungsabhängige Sicherheitssteuerungen an ihre Bedürfnisse anzupassen. Eine Anwendung ist nicht mit Sicherheit befasst (sicherheitsunabhängig, security-unaware), falls sie nicht aktiv an der Bereitstellung von Sicherheit für von ihr verwendete Daten teilnimmt noch auf die Umgebung einwirkt, um umgebungsabhängige Sicherheitssteuerungen an ihre Bedürfnisse anzupassen.

Es ist ein Gesichtspunkt der Erfindung, Sicherheit von Managementanwendungen fernzuhalten. Eine Grundservicesicherheitsschicht arbeitet in Diensten der Anwendung und erlaubt so, dass die Anwendung sicherheitsunabhängig ist und vermeidet die Notwendigkeit, die Anwendung oder den Kunden, der die Anwendung betreibt, zu kontaktieren. Wenn eine Anwendung läuft kann die Servicesicherheitsschicht so eine geeignete Dienstregel durch einen Dienstregelmanager auswählen und sollte alle benötigten Sicherheits- und/oder Unterstützungsfunktionen bereitstellen. Damit wird die Grundservicesicherheitsschicht auf die Sicherheitsfunktionen zugreifen und diese steuern, die durch darunter liegende Sicherheits/Unterstützungswerkzeuge bereitgestellt werden. Die Grundservicesicherheitsschicht interagiert mit

• - Anwendungseinheiten an der Clientseite oder Targetseite
• - einer darunter liegenden verteilten Plattform und
• - einem Serviceregelmanager.

Auf ähnliche Weise kann die Erfindung Unterstützungsaktivitäten von der Anwendung fernhalten.

Wie oben erläutert kommuniziert die Grundservicesicherheitsschicht (BSSL (Basic Service Security Layer)) mit dem Serviceregelmanager (SPM (Security Policy Manager)), der den Zugriff auf die Serviceregel/Routinedatenbank regelt, um erforderliche Serviceroutinen zu erhalten. Weitere Kommunikationsvorgänge ergeben sich aus einem Zugriff auf einen Namensservice. In OrbixWeb, (Adiron, CORBAsec SL2 User Guide) kann die BSSL Funktionalität unter Verwendung von Interceptoren (Abfängern) implementiert werden, d. h. unter Verwendung von Objekten, die einen oder mehrere spezialisierte Dienste an der ORB Aufrufgrenze bereitstellen, basierend auf dem Kontext der Objektanfrage. Ein Vorteil dieses Implementationstyps liegt in der Tatsache, dass Managementanwendungseinheiten nicht geändert werden müssen, wenn auf die BSSL Funktionalität zurückgegriffen wird. Ein Verwenden von Interceptoren (Abfängern) für Implementationszwecke erfordert, dass beide Kommunikationspartner dieses Konzept bereitstellen.

Im Falle dass ein Namensservice verwendet wird fragt der Client den Servernamen von dem Namensservice zur Aufrufzeit ab, der BSSL fordert den SPM Namen vom Namensservice an und danach fordert er eine Sicherheitsregel vom Sicherheitsregelmanager an.

Die folgenden Schritte können ausgeführt werden:

• 1. Der Client bewirkt eine Nachricht zum Target oder Server, die am Client BSSL Interceptor abgefangen wird.
• 2. Die BSSL fordert eine Objektreferenz vom SPM vom Namensservice an.
• 3. Die BSSL erhält die Objektreferenz vom SPM.
• 4. Die BSSL fordert zumindest eine Serviceroutine vom SPM an.
• 5. Die BSSL erhält die zumindest eine Serviceroutine vom SPM. Danach wird eine sichere Sitzung durch die BSSL in Übereinstimmung mit der zumindest einen Serviceroutine eingerichtet und letztendlich wird die Nachricht zum Server übermittelt.

Die Implementierung des Systems und der Anwendung kann in der Java-Programmiersprache erfolgen. Die darunter liegende Plattform kann WindowsNT sein. Die verwendeten Serviceroutinen können vom TMF-Dokument "Peer-to-Peer Service Configuration Business Agreement", Ausgabe 1.0, 1997 abgeleitet sein.

Die Serviceroutinen können Sicherheitsanforderungen auf unterschiedlichen Feinheitsebenen definieren, beispielsweise Sicherheit- und/oder Unterstützungsanforderungen auf Schnittstellenebene oder Methodenebene, und können Information bezüglich der Serviceroutine selbst beinhalten wie beispielsweise Lebensalter, Version usw.

Die Erfindung erlaubt es, für Verbindungen zwischen Servicemanagementanwendungen Sicherheitsfunktionen bereitzustellen, d. h. der am Client und am Target laufenden Anwendung. Wenn zwei Managementanwendungen oder Teile einer verteilten Managementanwendung miteinander verbunden sind, können die folgenden Arten von Sicherheitsaktivitäten erforderlich sein:

• - Authentisierung: Die Anwendungen sollten wissen, mit wem eine Verbindung versucht wird aufzubauen oder versucht werden soll aufzubauen.
• - Autorisierung: Die Verbindung muss autorisiert sein oder andernfalls muss sie unterbunden werden.
• - Integrität: Die Anwendungen sollten in der Lage sein sicherzustellen, dass die gelieferte Nachricht von der gegenseitigen Einheit kommt und nicht von anderen Einheiten geändert wurde.
• - Vertraulichkeit: Die gelieferte Nachricht sollte verschlüsselt sein; mit anderen Worten, die Nachricht sollte durch unautorisierte Einheiten auf dem Wege der Kommunikation nicht lesbar sein.
• - Audit: Sicherheitssensitive Ereignisse wie eine Sicherheitsverletzung oder Lieferung einer wichtigen Nachricht sollten aufgezeichnet werden und für eine Überprüfung bereit sein.
• - Nicht-Repudiation (Nicht-Zurückweisung): Ein Ereignis einer Lieferung (Senden und Empfang) einer wichtigen Nachricht sollte für Nicht-Zurückweisung aufgezeichnet werden.

Dieses ist besonders wichtig im Falle einer Verbindung zwischen unterschiedlichen Organisationen und im Fall von Geschäften.

Da nicht nur statische Serviceaktivitäten ausgeführt werden können sondern auch anwendungsabhängige Serviceroutinen und sogar Serviceroutinen, die den Typ einer Kommunikation oder Datenübermittlung betreffen, oder den Typ von vom Client zum Target übermittelten Daten, oder bezüglich Unterstützungsfunktionen, kann ein hoher Grad von Anpassung des Systems mit Bezug auf Sicherheitsanforderungen erzielt werden.

Im folgenden wird mit Bezug auf Fig. 2 eine mögliche Sequenz von Steuerungsschritten für eine Kommunikation zwischen einem Client 10, der eine Anwendung ausführt, und einem Target 20 über einen Kommunikationskanal beschrieben.

In einem ersten Schritt 100 kann die Nachrichtenvorrichtung 30 oder direkt die Anwendung eine Nachricht erzeugen, einschließlich Parametern bezüglich der Kommunikation, Parameter bezüglich des Client, des Targets und des Anwendungstyps, des zu übermittelnden Datentyps, des Typs einer Benachrichtigung oder Anforderung. Es ist wichtig, dass die Nachricht alle Parameter einschließt, die für eine Auswahl von Serviceroutinen wichtig sind, da dies die einzige Information ist, die vom Client zur Servicesecurityschicht übermittelt wird.

In einem zweiten Schritt 101 wird die Nachricht an der Analysevorrichtung 40 abgefangen, wo die Nachricht dann analysiert und die Parameter wiedergewonnen werden. Information bezüglich der aus der Nachricht gewonnenen Parameter wird danach zur Auswahlvorrichtung 50 übermittelt und in einem Schritt 102 wird zumindest eine Serviceroutine basierend auf den Parametern ausgewählt. Die Serviceroutinen können aus einer Datenbank ausgewählt werden, die eine Anzahl von zur Verfügung stehenden Serviceroutinen speichert, einschließlich anwendungsabhängigen Serviceroutinen und anwendungsunabhängigen Serviceroutinen.

Die ausgewählten Serviceroutinen werden abgerufen und in einem Schritt 103 wird die Kommunikation basierend auf der zumindest einen ausgewählten Serviceroutine gesteuert. Da die Erfindung es erlaubt, dass anwendungsabhängige Serviceroutinen ausgewählt werden, kann eine dynamische Adaption des Systems an die Anwendung, an zu übermittelnde Daten oder ähnliches erzielt werden. Die Steuervorrichtung 60 kann verwendet werden, um die verteilte Plattformschicht 70 anzuweisen, einen bestimmten Satz von Aktivitäten auszuführen, der der Serviceroutine zugehörig ist, oder kann selbst Aktivitäten in Verbindung mit der zumindest einen ausgewählten Serviceroutine ausführen.

Da die Sicherheitsserviceschicht gemäss der Erfindung in existierende Kommunikationsmodelle zwischen Client und Target auf der einen Seite und eine verteilte Plattformschicht auf der anderen Seite eingepasst werden kann, wie beispielsweise die CORBA Schicht, können existierende Architekturen modifiziert werden, so dass sie durch die Erfindung verbessert werden.

Im folgenden wird mit Bezug auf Fig. 3 ein zweites Ausführungsbeispiel der Erfindung beschrieben.

In Fig. 3 bezeichnen Bezugszeichen, die den Bezugszeichen in Fig. 1 entsprechen, korrespondierende Einheiten. Wie im ersten Ausführungsbeispiel kommunizieren ein Client 10 und ein Target 20 über einen Kommunikationskanal. Der Client ist mit einer Plattformschicht 70 verbunden, wie beispielsweise CORBA oder eine beliebige andere Plattformschicht. Zwischen dem Client (und der Plattformschicht) sind funktionale Einheiten der Sicherheitsserviceschicht angeordnet, eine Analysiervorrichtung 40, Clientseite-Auswahlvorrichtung 51 und eine Clientseite-Steuervorrichtung 61. Der mit 110 bezeichnete Kasten umfasst die Kernbestandteile eines clientseitigen Teils der verteilten Sicherheitsserviceschicht.

In Fig. 3 führt der Client 10 eine mit 11 bezeichnete Anwendung aus. Dies kann irgendeine Anwendung sein, die eine Kommunikation mit dem Target initiiert, beispielsweise eine Managementanwendung oder ähnliches. Das Target führt vorzugsweise eine entsprechende Anwendung aus, oder das Target und der Client führen Teile einer verteilten Anwendung aus.

Die Anwendung 11 in diesem bestimmten Ausführungsbeispiel übernimmt Funktionen der Nachrichtenvorrichtung 30 zum Erzeugen einer Nachricht, d. h. die Nachrichtenvorrichtung 30 kann Teil der am Client 10 laufenden Anwendung 11 darstellen. Die Nachricht umfasst vorzugsweise einen Parameterheader und Nutzlastdaten, wobei der Header Parameter umfasst, die die Kommunikation bestimmen, wie beispielsweise den Client, das Target, den Anwendungstyp, und einen bestimmten in der Kommunikationssitzung zu übermittelnden Datentyp. Die Nachricht kann aufgrund einer Benachrichtigung, einer Anforderung oder ähnlichem für das Target erzeugt werden.

Die am Client erzeugte Nachricht wird wie zuvor zur Analysiervorrichtung 40 übermittelt, wo sie abgefangen wird, und die entweder direkt oder indirekt in der Nachricht enthaltenen Parameter werden wiedergewonnen.

Die Parameter werden zur Clientseite-Auswahlvorrichtung 51 übermittelt, die Zugriff auf einen Clientseite- Serviceroutinenspeicher 81 hat, entweder direkt oder durch die verteilte Plattformschicht oder irgendeine andere Netzwerkkomponente. Die Clientseite-Auswahlvorrichtung 51 wählt zumindest eine geeignete Serviceroutine aus dem Clientseite-Serviceroutinenspeicher 81 aus und übermittelt Informationen bezüglich der zumindest einen Serviceroutine zur Clientseite-Steuervorrichtung 61. Dies kann die abgerufenen Parameter betreffen, eine Sequenznummer der ausgewählten Serviceroutine oder Routinen oder irgendwelche andere Information, einschließlich der Routine selbst.

Die ausgewählten Serviceroutinen können anwendungsabhängig oder anwendungsunabhängig sein, können Sicherheits- und/oder Unterstützungsaktivitäten betreffen, und werden vorzugsweise dynamisch bei Erzeugung und Übermittlung der Nachricht ausgewählt.

An der Targetseite umfasst ein Kasten mit der Bezugsziffer 120 die Kernbestandteile der Servicesicherheitsschicht auf der Targetseite, einschließlich einer Targetseite- Auswahlvorrichtung 52 und einer Targetseite-Steuervorrichtung 62. Das Target 20 ist durch die Targetseite- Auswahlvorrichtung 52 und die Targetseite-Steuervorrichtung 62 mit der verteilten Plattformschicht 70 verbunden. Wie auf der Clientseite hat die Targetseite-Auswahlvorrichtung 52 Zugriff auf einen Targetseite-Serviceroutinenspeicher 82, entweder direkt, über die verteilte Plattform 70 oder irgendeine andere Netzwerkkomponente.

Es wird darauf hingewiesen, dass bei dem obigen Vorgang eine einzige Datenverarbeitungsvorrichtung die Funktionen des Client und zur gleichen Zeit die Funktionen des Targets übernehmen kann.

Bei Auswahl der zumindest einen anwendungsabhängigen oder anwendungsunabhängigen Serviceroutine an der Clientseite wird die Targetseite-Auswahlvorrichtung 52 bezüglich der durchgeführten Auswahl informiert. Dies kann eine Übermittlung der abgerufenen Parameter umfassen, eine Sequenznummer der ausgewählten Serviceroutine oder Routinen oder beliebige andere Information, einschließlich der Routine selbst. An der Targetseite wählt die Targetseite- Auswahlvorrichtung 52 die gleichen Serviceroutinen wie an der Clientseite aus und ruft sie ab. Die ausgewählten Serviceroutinen werden zur Targetseite-Steuervorrichtung 62 übermittelt.

Die Clientseite-Steuervorrichtung und Targetseite- Steuervorrichtung steuern bei Empfang der ausgewählten zumindest einen Serviceroutine darauf basierend die Kommunikation, d. h. die Clientseite-Steuervorrichtung 61 und die Targetseite-Steuervorrichtung 62 steuern die Kommunikation zwischen dem Client und dem Target in Übereinstimmung damit. Vorzugsweise wird die vom Client zum Target zu übermittelnde Nachricht nur übermittelt, nachdem die notwendigen Serviceroutinen nicht nur an der Clientseite ausgewählt wurden sondern auch an der Targetseite ausgewählt wurden. Es ist jedoch auch denkbar, dass die Nachricht übermittelt wird, bevor eine entsprechende Auswahl der Serviceroutinen an der Targetseite durchgeführt wird, und die Nachricht wird an der Targetseite abgefangen und gespeichert, bis die Auswahl von Serviceroutinen an der Targetseite durchgeführt wurde und die Anweisungen an die Targetseite- Steuervorrichtung vervollständigt wurden.

Diese Steuerung kann ein Ansteuern eines Interface, einen Zugriff auf das Target, ein Einstellen von Zugriffsrechten und die Ausführung einer Verarbeitungsmethode, wie beispielsweise ein Codieren der vom Client zum Target zu übermittelnden Nachricht beinhalten.

Die Clientseite-Steuervorrichtung und die Targetseite- Steuervorrichtung können entweder selbst sicherheits- und/oder unterstützungsrelevante Funktionen in Verbindung mit den ausgewählten Serviceroutinen durchführen oder können die darunter liegende verteilte Plattformschicht 70 anweisen, die entsprechenden Sicherheits/Unterstützungsfunktionen auszuführen.

Vorzugsweise wird die Nachricht an der Clientseite abgefangen und nur vom Client zum Target übermittelt oder die Aktivität in Verbindung mit der Nachricht wird nur ausgeführt, nachdem die geeignete Serviceroutine sowohl an der Clientseite als auch an der Targetseite ausgewählt wurde und entsprechende Steueraktivitäten begonnen haben.

Der Targetseite-Serviceroutinenspeicher und der Clientseite- Serviceroutinenspeicher können eine Datenbank oder eine andere Speichervorrichtung zum Speichern einer Vielzahl von anwendungsabhängigen und anwendungsunabhängigen Serviceroutinen sein, die am Target zur Verfügung stehen.

Weiter können die Serviceroutinen Information bezüglich der Serviceroutine selbst beinhalten, wie beispielsweise Lebensdauer, Version und ähnliches der ausgewählten Serviceroutine.

In einem weiteren Ausführungsbeispiel ist anstelle des Clientseite-Serviceroutinenspeichers und Targetseite- Serviceroutinenspeichers nur ein Serviceroutinenspeicher verfügbar und die Clientseite-Auswahlvorrichtung 51 und die Targetseite-Auswahlvorrichtung 52 können zu diesem einzelnen Serviceroutinenspeicher Zugriff haben. In diesem Fall kann der Serviceroutinenspeicher beispielsweise mit der verteilten Plattformschicht verbunden sein oder jedem anderen Netzwerk, auf das von der Clientseite und der Targetseite zugegriffen werden kann, und die Targetseite-Auswahlvorrichtung 52 wird durch die Clientseite-Auswahlvorrichtung 51 bei Auswahl der Serviceroutinen, in Übereinstimmung mit den Parametern der Nachricht, benachrichtigt. Die Targetseite-Auswahlvorrichtung 52 schreitet dann damit fort, die gleichen Serviceroutinen von dem Serviceroutinenspeicher abzurufen.

Es ist auch denkbar, dass zumindest ein Teil der Nachricht bezüglich der einbezogenen Parameter zur Targetseite übermittelt wird, insbesondere zur Targetseitenanalysevorrichtung, die dann diesen Nachrichtenteil analysieren wird und basierend darauf die Auswahlroutinen von entweder dem Targetseite- Serviceroutinenspeicher oder einem für sowohl die Targetseite als auch die Clientseite gemeinsamen Serviceroutinenspeicher vornehmen wird.

Wie vorhergehend ausgeführt kann die Kommunikation zwischen dem Client und dem Target eine Übermittlung der Nachricht, möglicherweise in verschlüsselter Form, ein Steuern einer Schnittstelle, Zugriffsrechte zum Target und ähnliches einbeziehen.

In einem weiteren Ausführungsbeispiel kann die Clientseite- Auswahlvorrichtung 51 und die Targetseite-Auswahlvorrichtung 52 die Auswahl der zumindest einen Serviceroutine, die eine anwendungsabhängige oder anwendungsunabhängige Serviceroutine sein kann, von der Verfügbarkeit von Serviceroutinen am Client und weiter von der Verfügbarkeit von Serviceroutinen am Target abhängig machen. Dies ist insbesondere in einem Fall wichtig, in dem sowohl die Clientseite- Auswahlvorrichtung 51 als auch die Targetseite- Auswahlvorrichtung 52 mit unterschiedlichen Serviceroutinenspeichern verbunden sind, wie beispielsweise der Clientseite-Serviceroutinenspeicher 81 und der Targetseite-Serviceroutinenspeicher 82; jeweilig in Fig. 3 gezeigt, und können somit nicht den gleichen Satz von Serviceroutinen verfügbar haben.

Demzufolge kann die Auswahl der zumindest einen Serviceroutine von der Verfügbarkeit von Serviceroutinen am Client und am Target abhängig gemacht werden, wobei die Verfügbarkeit in einer Verhandlung zwischen der Clientseite- Auswahlvorrichtung 51 und der Targetseite-Auswahlvorrichtung 52 vor einer Übermittlung der Nachricht begründet werden kann.

Eine Verhandlung einer Auswahl von Serviceroutinen ist jedoch auch in einem Fall relevant, in dem beide Auswahlvorrichtungen Zugriff auf den gleichen Serviceroutinenspeicher haben.

Die Auswahl der gemeinsam verfügbaren Serviceroutinen kann in einer Verhandlung zwischen der Clientseite-Auswahlvorrichtung 51 und der Targetseite-Auswahlvorrichtung 52 erfolgen. In dieser Verhandlung einigen sich beide Seiten auf einen gemeinsam verfügbaren geeigneten Satz von Serviceroutinen und dieser Satz von Serviceroutinen, oder entsprechende Gesichtspunkte der jeweiligen Serviceroutinen werden am Client und am Target verwendet.

Die Verhandlung einer Serviceroutine kann eine Übereinstimmung zwischen einer Client-BSSL Einheit und einer Target-BSSL Einheit bezüglich einer Serviceroutine beinhalten, beispielsweise in einem Fall, dass ein Satz von Serviceroutinen in der Auswahlphase ausgewählt wurde und nicht eine einzelne Serviceroutine, und/oder in einem Fall, dass Mehrdeutigkeiten innerhalb einer Serviceroutine gelöst werden müssen.

Am Ende der Verhandlungsphase muss eine vollständige Übereinstimmung bezüglich der folgenden Punkte erzielt sein:

• - Der Satz von bereitzustellenden Sicherheitsfunktionen, und
• - die Art wie sie bereitgestellt werden.

Die Funktionalität der BSSL kann damit umfassen:

• - Die Auswahl der Serviceroutine in Abhängigkeit vom Anwendungstyp und dem Kommunikationsverhältnis (Client, Target),
• - die Verhandlung der Serviceroutine zwischen den BSSL Einheiten, und
• - die Ausführungsüberwachung der Serviceroutine, einschließlich
• - dem Zuweisen von Serviceroutinen auf Sicherheitskomponenten, und
• - die Steuerung und Ausnahmehandhabung dieser Komponenten.

Nachdem man sich auf einen Satz von Serviceroutinen aufgrund einer Kommunikation zwischen dem Client und dem Target geeinigt hat, kann für folgende Nachrichten dieser Satz von Serviceroutinen verwendet werden. Nur in dem Fall, dass der Ausführungszustand der Anwendung oder der Typ einer Kommunikation sich verändert, wird eine Nachricht analysiert, um einen neuen Satz von Serviceroutinen zu definieren.

Darüber hinaus können während einer Kommunikation der Client und das Target Rollen tauschen, d. h., nach einer Benachrichtigung oder Anforderung kann das Target zum Client werden und der Client kann zum Target werden. Wie in Fig. 3 gezeigt, kann das Target auch eine Anwendung 21 ausführen, mit unterbrochenen Linien gezeigt, und kann auch eine Targetseitennachrichtenvorrichtung 31 umfassen, ebenso mit unterbrochenen Linien gezeigt, und eine Targetseitenanalysevorrichtung 41. Im Falle dass das Target als Client arbeitet, beispielsweise wenn eine Bestätigung oder ähnliches zum Client, der als Target arbeitet, übermittelt wird, wird die erzeugte Nachricht an der Targetseitenanalysevorrichtung 41 analysiert, geeignete Serviceroutinen werden wie oben beschrieben ausgewählt und weiter wird die Steuerung der Kommunikation zwischen dem Target und dem Client durchgeführt, wie ebenso oben beschrieben.

Der Satz von Serviceroutinen, bezüglich dem Einigkeit erzielt wurde, kann unverändert verbleiben, solange die Kommunikationsgrundsätze sich nicht verändern.

Im folgenden wird ein Beispiel einer möglichen Sequenz von Nachrichten zwischen dem Client und dem Target beschrieben, im Falle dass ein Namensservice verwendet wird.

Zuerst wird eine Targetseitenbootstrappingsequenz des BSSL beschrieben. Ein Bediener muss möglicherweise explizit anfangs die Benutzung der BSSL auslösen, d. h. muss sich beim Namensservice registrieren. Danach können die BSSL Einheiten eine SPM Schnittstelle remote benutzen. Allgemein ist es möglich, mehr als ein SPM zu haben. In diesem Fall müssen die BSSL Einheiten wissen, welcher SPM ihnen zugewiesen ist.

Die Serveranwendungseinheit registriert sich dann ebenfalls beim Namensservice. Der Ruf wird durch die Server-BSSL Einheit abgefangen, die nun ihre Umgebung initialisiert: Diese registriert sich selbst auch beim Namensservice, was ebenso in Übereinstimmung mit dem beschriebenen Namensschema gemacht wird. Dann holt sie die SPM Adresse ein, um in der Lage zu sein, später Serviceroutinen abzurufen. Danach wird der abgefangene Ruf der Serveranwendungseinheit fortgeführt.

Im folgenden wird ein Beispiel einer Clientseitenbootstrappingsequenz der BSSL beschrieben. Der Bediener muss möglicherweise die Verwendung der BSSL ausdrücklich auslösen. Als ein Beispiel kann das mit bestimmten Befehlszeilenargumenten erzielt werden.

Anfangs muss der Serviceroutinenspeicher sich beim Namensservice anmelden. Danach kann die BSSL Einheit die SPM Schnittstelle remote verwenden. Es wird darauf hingewiesen, dass es allgemein möglich ist, mehr als einen SPM zu haben. Wenn die Clientanwendungseinheit die Serveranwendungseinheit vom Namensserver erfährt, wird diese Nachricht durch die Client-BSSL Einheit abgefangen. Auf diese Weise kann die Client-BSSL Einheit die Adresse der Server-BSSL Einheit bestimmen, die sich von einem oben beschriebenen eindeutigen Namensschema ableitet.

Danach authentisiert sich der Bediener (an der Clientseite). Da die Clientanwendung und die Client-BSSL Einheiten den gleichen Adressraum teilen können, kann auf diese Information durch die BSSL zugegriffen werden, um die anfängliche Eingangsauthentisierung durchzuführen.

Nach der Initialisierung von sowohl der Middleware und der BSSL senden die verteilte Anwendung oder die getrennten Anwendungen am Target und am Client die erste Nachricht. Wie für alle anderen Nachrichten wird diese Nachricht durch die BSSL abgefangen. Diese Nachricht kann nun die geeigneten Serviceroutinen bestimmen. Um dies zu tun erfragt die Client- BSSL Einheit nun die Adresse des SPM und der Server-BSSL Einheiten. Unter dem bekannten Nutzernamen, dem Anwendungstyp und der Targetdomain sendet die Client-BSSL nun eine Serviceroutinenanfragenachricht zum SPM. Falls die Parameter übereinstimmen, d. h. falls eine gültige Serviceroutine vorliegt, wird sie zum Anrufer zurückgesendet. Andernfalls wird eine Ausnahme festgestellt und die Nachricht vom Client zur Serveranwendung wird verworfen.

Falls die Serviceroutinenanforderungsnachricht erfolgreich war, sendet die Client-BSSL Einheit eine Verhandlungsserviceroutinenachricht zur Server-BSSL Einheit mit der Identität und der Versionsnummer der Serviceroutine, die sie vom SPM erhalten hat. Die Server-BSSL Einheit überprüft, ob die Werte dieser Parameter identisch zu ihrer eigenen Bestimmung einer Serviceroutine sind. Falls sie übereinstimmen, wird sie anzeigen fortzufahren, andernfalls wird sie signalisieren, dass die Serviceroutine nicht akzeptiert ist. Allgemein könnten diese Schritte so lange wiederholt werden, bis die Client- und die Server-BSSL sich auf eine gemeinsame Serviceroutine oder einen Satz von Serviceroutinen einigen.

Nach der Bestimmung und Verhandlung der Serviceroutine überwacht die BSSL die Sicherheitseinstellungen, die durch die Serviceroutine bestimmt sind. Dieses ist abhängig von den darunter liegenden Sicherheitskomponenten.

Alle Nachrichten zwischen den Client- und Serveranwendungseinheiten werden durch die Client- und Server-BSSL Einheiten abgefangen. Nach der Ausführungsüberwachung der Serviceroutinen durch die BSSL Einheiten und nachdem die gegenwärtige Nachricht zur Server- BSSL Einheit übermittelt worden ist, handhabt die BSSL eine möglicherweise aufgetretene Ausnahme. Zuletzt wird die Nachricht zum Target übermittelt.

Im folgenden wird mit Bezug auf Fig. 4 eine mögliche Sequenz von Schritten während einer Kommunikation zwischen dem Client und dem Target beschrieben.

Am Client läuft eine Anwendung und in einem Schritt 110 erzeugt die Anwendung eine Nachricht einschließlich zumindest Parametern bezüglich der Kommunikation. Die Parameter können den Client betreffen, die Anwendung selbst und den Kommunikationszustand der Anwendung oder ähnliches.

In einem Schritt 111 wird die vom Client zum Target zu übermittelnde erzeugte Nachricht abgefangen und analysiert, um die in der Nachricht beinhalteten Parameter zu gewinnen.

In einem Schritt 112 wird überprüft, ob eine Serviceroutine oder ein Satz von Serviceroutinen bereits für die bestimmte Anwendung oder Kommunikation, die der Client und das Target ausführen, ausgewählt sind. Es kann auch überprüft werden, ob die Anwendungsgrundsätze oder Kommunikationsgrundsätze sich geändert haben und ein neuer Satz von Serviceroutinen ausgewählt werden muss. Im Falle dass kein Satz von Serviceroutinen ausgewählt war oder ein neuer Satz von Serviceroutinen ausgewählt werden muss, aufgrund der obigen Gründe, wird im Schritt 113 zumindest eine Serviceroutine basierend auf den an der Clientseite analysierten Parametern ausgewählt.

In einem Schritt 114 fragt die Clientseite-Auswahlvorrichtung 51 an, ob die ausgewählte Serviceroutine am Target verfügbar ist, und im Falle dass sie es nicht ist, wird eine neue Serviceroutine in einem Schritt 113 ausgewählt.

Schritte 113 und 114 werden wiederholt, bis Einigung bezüglich einer gemeinsam verfügbaren Serviceroutine oder Satz von Serviceroutinen erzielt wurde. Danach schreitet der Ablauf zum Schritt 115 voran und die Kommunikation wird basierend auf der zumindest einen ausgewählten Serviceroutine gesteuert.

Falls im Schritt 112 eine Serviceroutine oder ein Satz von Serviceroutinen bereits ausgewählt war, oder bestimmt wurde, dass ein neuer Satz von Serviceroutinen nicht erforderlich ist, schreitet der Ablauf auch zum Schritt 115 voran.

Wie oben ausgeführt kann die Steuerung der Kommunikation basierend auf der gewählten zumindest einen Serviceroutine ein Anweisen einer darunter liegenden verteilten Plattformschicht beinhalten, wie beispielsweise CORBA, um zur Verfügung stehende Sicherheitsaktivitäten auszuführen, basierend auf Instruktionen von der Clientseite- Steuervorrichtung und der Targetseite-Steuervorrichtung.

Weitere Plattformen können beispielsweise sein DCOM, das ein robustes Objektmodel bereitstellt, insbesondere für Microsoft-Betriebssysteme; es wird auf andere Plattformen übertragen, und OSF (Open Software Foundation) Distributed Computing Environment (DCE) stellt einen Satz von Standards bereit, die durch die OSF entwickelt wurden.

Weiter können die Clientseite-Steuervorrichtung und die Targetseite-Steuervorrichtung selbst sicherheitsrelevante Aktivitäten ausführen, beispielsweise Verschlüsselung oder Entschlüsselung der Nachricht.

Claims (20)

1. Sicherheitsserviceschichtvorrichtung zum Steuern einer Kommunikation zwischen einem Client (10), der eine Anwendung (11) ausführt, und einem Target (20) über einen Kommunikationskanal, umfassend:
eine Nachrichtenvorrichtung (30, 31) zum Erzeugen einer Nachricht für eine Übermittlung vom Client (10) zum Target (20) einschließlich die Kommunikation beschreibender Parameter,
eine Analysevorrichtung (40, 41) zum Analysieren der Parameter der Nachricht,
eine Auswahlvorrichtung (50; 51, 52) zum Auswählen zumindest einer Serviceroutine von einer Anzahl von zur Verfügung stehenden Serviceroutinen, basierend auf den Parametern, und
eine Steuervorrichtung (60; 61, 62) zum Steuern der Kommunikation einschließlich einer Übermittlung der Nachricht basierend auf der zumindest einen ausgewählten Serviceroutine.

2. Sicherheitsserviceschichtvorrichtung nach Anspruch 1, wobei die Auswahlvorrichtung weiter umfasst:
eine Clientseite-Auswahlvorrichtung (51), an der Clientseite angeordnet, und mit einer ersten Datenbank (81) verbunden, die Serviceroutinen speichert, die am Client (10) zur Verfügung stehen,
eine Targetseite-Auswahlvorrichtung (52), die an der Targetseite angeordnet ist und mit einer zweiten Datenbank (82) verbunden ist, die Serviceroutinen speichert, die an der Targetseite zur Verfügung stehen, und
wobei die Auswahl der zumindest einen Serviceroutine auf der Verfügbarkeit von Serviceroutinen am Client (10) und am Target (20) basiert, wobei die Verfügbarkeit in einer Verhandlung zwischen der Clientseite-Auswahlvorrichtung (51) und der Targetseite-Auswahlvorrichtung (52) vor einer Übermittlung der Nachricht festgestellt wird.

3. Sicherheitsserviceschichtvorrichtung nach einem der Ansprüche 1 und 2, wobei die Steuervorrichtung weiter eine an der Clientseite angeordnete Clientseite- Steuervorrichtung (61) und eine an der Targetseite angeordnete Targetseite-Steuervorrichtung (62) umfasst.

4. Sicherheitsserviceschichtvorrichtung nach einem der vorhergehenden Ansprüche, wobei die Auswahlvorrichtung (50; 51, 52) dazu angeordnet ist, die zumindest eine Serviceroutine von einer Gruppe von anwendungsunabhängigen Serviceroutinen und anwendungsabhängigen Serviceroutinen auszuwählen.

5. Sicherheitsserviceschichtvorrichtung nach einem der vorhergehenden Ansprüche, wobei die Parameter den Client und/oder das Target und/oder den Anwendungstyp beschreiben.

6. Sicherheitsserviceschichtvorrichtung nach einem der vorhergehenden Ansprüche, wobei eine Serviceroutine Sicherheitsmechanismen und/oder nicht auf Sicherheit bezogene Unterstützungsmechanismen umfasst.

7. Sicherheitsserviceschichtvorrichtung nach einem der vorhergehenden Ansprüche, wobei die Serviceroutinen ein Steuern einer Schnittstelle und/oder Zugriff auf das Target und/oder eine Ausführung eines Verarbeitungsverfahrens betreffen.

8. Sicherheitsserviceschichtvorrichtung nach einem der vorhergehenden Ansprüche, wobei die Serviceroutinen ein Codieren und Decodieren der von dem Client (10) zum Target (20) zu übermittelnden Nachricht betreffen.

9. Sicherheitsserviceschichtvorrichtung nach einem der vorhergehenden Ansprüche, wobei die Serviceroutinen Information bezüglich der Serviceroutine selbst beinhalten, einschließlich Lebenszeit und Version.

10. Sicherheitsserviceschichtvorrichtung nach einem der vorhergehenden Ansprüche, wobei die Nachrichtenvorrichtung (30, 31) einen Teil der am Client geführten Anwendung darstellt, und die Nachricht eine Anforderung oder eine Benachrichtigung darstellt.

11. Verfahren zum Steuern einer Kommunikation zwischen einem Client (10), der eine Anwendung ausführt, und einem Target (20) über einen Kommunikationskanal mit den Schritten:
Erzeugen einer Nachricht am Client (10) für eine Übermittlung vom Client (10) zum Target (20) einschließlich die Kommunikation beschreibender Parameter,
Analysieren der Parameter der Nachricht,
Auswählen zumindest einer Serviceroutine von einer Anzahl von zur Verfügung stehenden Serviceroutinen basierend auf den Parametern, und
Steuern der Kommunikation einschließlich einer Übermittlung der Nachricht basierend auf der zumindest einen ausgewählten Serviceroutine.

12. Verfahren nach Anspruch 11, wobei die Auswahl der zumindest einen Serviceroutine von der Verfügbarkeit von Serviceroutinen in einer ersten Datenbank (81) an der Clientseite und einer zweiten Datenbank (82) an der Targetseite abhängt, wobei die Verfügbarkeit in einer Verhandlung zwischen der Clientseite-Auswahlvorrichtung (51) und Targetseite-Auswahlvorrichtung (52) vor einer Übermittlung der Nachricht vom Client (10) zum Target (20) bestimmt wird.

13. Verfahren nach einem der Ansprüche 11 und 12, wobei die Kommunikation an der Clientseite und an der Targetseite gesteuert wird.

14. Verfahren nach einem der Ansprüche 11 bis 13, wobei die erste Auswahlvorrichtung die zumindest eine Serviceroutine von einer Gruppe von anwendungsunabhängigen Serviceroutinen und anwendungsabhängigen Serviceroutinen auswählt.

15. Verfahren nach einem der Ansprüche 11 bis 14, wobei die Parameter den Client und/oder das Target und/oder den Anwendungstyp beschreiben.

16. Verfahren nach einem der Ansprüche 11 bis 15, wobei eine Serviceroutine Sicherheitsmechanismen und/oder nicht auf Sicherheit bezogene Unterstützungsmechanismen umfasst.

17. Verfahren nach einem der Ansprüche 11 bis 16, wobei die Serviceroutinen ein Steuern einer Schnittstelle und/oder Zugriff auf das Target und/oder die Ausführung eines Verarbeitungsverfahrens betreffen.

18. Verfahren nach einem der Ansprüche 11 bis 17, wobei die Serviceroutinen ein Codieren und Decodieren der vom Client (10) zum Target (20) zu übermittelnden Nachricht betreffen.

19. Verfahren nach einem der Ansprüche 11 bis 18, wobei die Serviceroutinen Information bezüglich der Serviceroutine selbst beinhalten, einschließlich Lebensdauer und Version.

20. Verfahren nach einem der Ansprüche 11 bis 19, wobei die Nachricht durch die an dem Client laufende Anwendung erzeugt wird und eine Anforderung und/oder eine Benachrichtigung beinhaltet.