-
Die
Erfindung betrifft allgemein das Gebiet von Kommunikationssystemen
und insbesondere Secure Sockets Layer (SSL) Virtual Private Network (VPN)
Gateways und andere Typen von sicheren Gateways, die genutzt werden,
um den Zugriff auf interne Ressourcen von Unternehmensnetzen von
externen Servern und anderen Einrichtungen aus zu steuern.
-
Ein
typisches herkömmliches SSL-VPN-Gateway
ist derart konfiguriert, dass es einen Browser basierten Zugriff
auf die internen Ressourcen eines Unternehmensnetzes bereitstellt.
Solche internen Ressourcen können
Server, Computer oder andere Verarbeitungseinrichtungen von vielen verschiedenen
Anbietern umfassen; und auf diesen kann eine breite Vielfalt unterschiedlicher
Protokolle ausgeführt
werden. Eingehende Transaktionen, die an das Gateway gerichtet sind,
werden im Allgemeinen mit Hilfe von Standardprotokollen wie etwa
dem Hypertext Transfer Protokoll (HTTP) oder HTTP Secure Sockets
(HTTPS) initiiert. Ein SSL-VPN-Gateway stellt selbst keine Firewall
dar, sondern ist stattdessen üblicherweise
innerhalb des Unternehmens hinter der Firewall lokalisiert.
-
Beispiele
für herkömmliche
SSL-VPN-Gateways sind die Produkte SA 700, SA 2000, SA 4000, SA
6000 und SA 6000 SP, die kommerziell bei der Juniper Networks, Inc.,
Sunnyvale, Kalifornien, USA erhältlich
sind, die Produkte EX-2500, EX-1500 und EX-750, die kommerziell
bei der Aventail Corp., Seattle, Washington, USA erhältlich sind,
und das Produkt Permeo Base5, das kommerziell bei der Permeo Technologies
Inc., Austin, Texas, USA erhältlich
ist.
-
Ein
wesentlicher Nachteil, der mit herkömmlichen VPN-Gateways der vorstehend
aufgelisteten Art verbunden ist, besteht darin, dass es schwierig sein
kann, Alarmsignale zu behandeln, die von internen Ressourcen des
Unternehmens generiert werden. Solche Ressourcen umfassen oft Produkte
von mehreren Anbietern. Jeder Anbieter hat möglicherweise einen externen
Diensteanbieter, welcher Kundensupport für die Produkte dieses Anbieters
bietet. Ein gegebener Diensteanbieter kann beispielsweise Techniker
und Expertensysteme umfassen, welche die Alarmsignale bearbeiten,
um jedwede Probleme zu lösen,
die möglicherweise
in den Produkten des entsprechenden Anbieters bestehen. Beispielhafte Expertensysteme,
die genutzt werden können,
um Alarmsignale zu bearbeiten, sind in der am 13. September 2004
im Namen der Erfinder S. Ganesh et al. eingereichten US-Patentanmeldung
10/939,694 beschrieben, mit dem Titel "Distributed Expert System for Automatic
Problem Resolution in a Communication System", welche gemeinsam mit der vorliegenden übertragen
worden ist und hier durch Bezugnahme einbezogen wird.
-
Generell
sind die herkömmlichen SSL-VPN-Gateways
nicht dafür
konfiguriert, Alarmsignale von auch als herstellerneutral bezeichneten Multi-Vendor-Produkten
an die diesen zugeordneten Diensteanbieter auszuliefern oder den
Diensteanbietern Zugriff auf die Produkte, welche die Alarmsignale erzeugt
haben, zu gestatten. In vielen Fällen
muss eine Kunde möglicherweise
den Diensteanbieter anrufen, um ihn von einem Problem in Kenntnis
zu setzen, das zu einem Alarm geführt hat. Der Kunde müsste dann
eine explizite Autorisierung bereitstellen, um einem Techniker oder
einem Expertensystem des Diensteanbieters zu gestatten, Zugriff
auf das Produkt zu erlangen, um das Problem zu lösen.
-
Außerdem sind
herkömmliche SSL-VPN-Gateways
typischerweise dafür
ausgelegt, einzelne Nutzer zu authentifizieren. Es ist unpraktikabel,
hunderte oder sogar tausende von Technikern zu authentifizieren,
die möglicherweise
den Diensteanbietern zuzuordnen sind, welche den Support für die verschiedenen
Multi-Vendor-Produkte in einem gegebenen Unternehmen bieten. Die
Techniker von Diensteanbietern müssen
möglicherweise
Hardware-Tokens oder andere ähnliche
Mechanismen nutzen, um Zugriff auf ein Unternehmensnetz zu erlangen,
und jeder Techniker eines Diensteanbieters müsste unterschiedliche Sätze von
Hardware-Tokens für
jeden Kunden nutzen, was unpraktisch und teuer ist. Darüber hinaus
kann eine Authentifizierung großer
Gruppen von Technikern von herstellerneutralen Diensteanbietern
eine übermäßige Last
für den AAA(Administration,
Autorisierung und Authentifizierung)-Server eines gegebenen Unternehmens
bedeuten, was eindeutig unerwünscht
ist.
-
Es
ist daher offensichtlich, dass ein Bedarf an einem verbesserten
SSL-VPN-Gateway besteht, welches eine effizientere Behandlung von
Alarmsignalen ermöglicht,
die von Multi-Vendor-Produkten ausgehen, welche Teil der internen
Ressourcen eines Unternehmensnetzes sind.
-
Die
vorliegende Erfindung überwindet
in einer beispielhaften Ausführungsform
die vorstehend erwähnten
Nachteile des Standes der Technik, indem ein SSL VPN mit einem Alarmmanager
und mit Unterstützung
für eine
eingehende föderierte
Identität (inbound
federated identity) bereitgestellt wird.
-
Entsprechend
einem Aspekt der Erfindung dient ein SSL-VPN-Gateway oder eine andere Art von
sicherem Gateway dazu, den Zugriff auf ein Unternehmensnetz eines
Kommunikationssystems zu steuern. Das Gateway umfasst entsprechend
einem Aspekt der Erfindung einen Alarmmanager. Der Alarmmanager
empfängt
einen Alarm von einem Produkt eines Verkäufers, welches Teil eines Satzes interner
Ressourcen des Unternehmensnetzes ist, und leitet den Alarm an einen
externen Diensteanbieter zur Bearbeitung. Das Gateway empfängt von
dem Diensteanbieter unter Ansprechen auf den Alarm eine auch als "Federated Identity" bezeichnete föderierte
Kennung, welche eine Mehrzahl von Technikern, Expertensystemen oder
anderen dienstleistenden Elementen des Diensteanbieters einschließt. Das
Gateway kann einem oder mehreren speziellen dienstleistenden Elementen
des Diensteanbieters Zugriff auf das den Alarm erzeugende Produkt
auf Basis der föderierten
Identität
gewähren.
-
Bei
einer beispielhaften Ausführungsform
ist das Unternehmensnetz mit einem Kundenstandort verknüpft, und
der Satz interner Ressourcen des Unternehmensnetzes umfasst zumindest
Kundenprodukte, Produkte von einem ersten Verkäufer und Produkte von einem
zweiten Verkäufer.
Der Alarmmanager dient bei dieser Ausführungsform dazu, einen Alarm
von einem der Kundenprodukte zu einem Kundensupport-Server des Kundenstandorts
zu leiten, einen Alarm von einem der Produkte des ersten Verkäufers zu
einem ersten externen Diensteanbieter zu leiten und einen Alarm
von einem der Produkte des zweiten Verkäufers zu einem zweiten externen
Diensteanbieter zu leiten. Der erste und der zweite Diensteanbieter
greifen auf jeweils das erste und das zweite Verkäuferprodukt
unter Ansprechen auf die jeweiligen Alarmsignale von diesen über das
Gateway unter Nutzung unterschiedlicher föderierter Identitäten zu.
-
Ein
gegebener Diensteanbieter kann unter Nutzung einer Authentifizierungsdatenbank
des Diensteanbieters ein bestimmtes seiner dienstleistenden Elemente
authentifizieren. Der Diensteanbieter überträgt vorzugsweise eine Kennung
des bestimmten dienstleistenden Elements an das Gateway, zusammen
mit der föderierten
Kennung des Diesteanbieters. Die föderierte Kennung des Diensteanbieters
wird generell von dem Gateway authentifiziert, bevor Zugriff für das spezielle
dienstleistende Element auf das Verkäuferprodukt gewährt wird;
die Kennung des speziellen dienstleistenden Elements braucht aber.
nicht von dem Gateway authentifiziert zu werden. Stattdessen könnte die
Kennung des bestimmten dienstleistenden Elements für Abrechnungs-
und Prüfungszwecke
protokolliert werden. Der Diensteanbieter kommuniziert in der beispielhaften
Ausführungsform
mit dem Gateway unter Nutzung eines automatisierten SSL-Skripts,
welches einen Login auf SSL-VPN-Basis, der die föderierte Identität umfasst,
bereitstellt.
-
Mit
der beispielhaften Ausführungsform
der Erfindung werden in vorteilhafter Weise die zuvor erwähnten Probleme
des Standes der Technik überwunden.
Beispielsweise wird die Behandlung von Alarmsignalen von Multi-Vendor-Produkten,
die Teil der internen Ressourcen eines Unternehmensnetzes sind,
ermöglicht,
indem eine einzige Stelle zur Steuerung des eingehenden und abgehenden
Zugriff für alle
Diensteanbieter bereitgestellt wird. Der Authentifizierungsprozess
wird wesentlich vereinfacht, indem sich die Notwendigkeit erübrigt, Authentifizierungsinformationen
für jeden/jedes
von möglicherweise
hunderten oder tausenden von Technikern, Expertensystemen oder anderen
dienstleistenden Elementen eines gegebenen Diensteanbieters zu speichern.
Außerdem
bietet es Kompatibilität
mit Sicherheitsrichtlinien des Kunden, während zugleich die Notwendigkeit
wegfällt,
dass Techniker oder Expertensysteme von Diensteanbietern unterschiedliche
Sätze von Hardware-Tokens
für jeden
Kunden unterhalten.
-
Diese
und andere Merkmale und Vorteile der vorliegenden Erfindung werden
anhand der folgenden Zeichnungen und der detaillierten Beschreibung einfacher
verständlich
werden.
-
Es
zeigen:
-
1 ein
beispielhaftes Kommunikationssystem, das ein SSL-VPN-Gateway mit einem Alarmmanager und
mit Unterstützung
für eine
eingehende föderierte
Kennung entsprechend einer beispielhaften Ausführungsform der vorliegenden
Erfindung umfasst,
-
2 ein
vereinfachtes Blockdiagramm, das eine mögliche Implementierung eines
gegebenen Verarbeitungselements des Systems aus 1 zeigt,
und
-
3 ein
vereinfachtes Blockdiagramm, das eine Reihe von Elementen des SSL-VPN-Gateways des
Systems aus 1 in der beispielhaften Ausführungsform
der Erfindung zeigt.
-
Die
Erfindung wird nachstehend in Verbindung mit einem beispielhaften
Kommunikationssystem beschrieben, das ein Unternehmensnetz mit einer
Mehrzahl von Servern, Computern oder anderen Verarbeitungselementen
umfasst. Es sollte jedoch verstanden werden, dass die Erfindung
nicht auf den Einsatz mit einer bestimmten Art von Kommunikationssystem
oder irgendeiner speziellen Konfiguration von Servern, Computern
oder anderen Verarbeitungselementen des Systems beschränkt ist.
Fachleute auf dem Gebiet werden erkennen, dass die offenbarten Verfahren
in jeder Kommunikationssystemanwendung genutzt werden können, bei
welcher es wünschenswert
ist, eine verbesserte Behandlung von Alarmsignalen in einem sicheren
Gateway zur Verfügung
zu stellen.
-
1 zeigt
ein Beispiel für
ein Kommunikationssystem 100 entsprechend einer beispielhaften Ausführungsform
der Erfindung. Das System 100 umfasst einen Kundenstandort 102,
welcher an ein externes Netz 104 angebunden ist. Der Kundenstandort 102 umfasst
ein Unternehmensnetz, das durch eine Firewall 106 von dem
Netz 104 getrennt ist. Das Unternehmensnetz umfasst bei
dieser Ausführungsform
Netzsegmente 108 und 110, welche LAN(lokale Netz)-Segmente,
WAN(Weitverkehrsnetz)-Segmente oder andere Netzsegmente oder Teile
derselben in einer beliebigen Kombination umfassen können. Die
Netzsegmente 108, 110 sind mit einem SSL-VPN-Gateway 120 verbunden.
Entsprechend einem Aspekt der Erfindung ist das SSL-VPN-Gateway 120 derart
konfiguriert, dass es einen Alarmmanager umfasst, dessen Funktionsweise
nachstehend detaillierter beschrieben werden soll. Das SSL-VPN-Gateway 120 ist
außerdem
mit einem oder mehreren Kundensupport-Servern 122 verbunden,
welche beispielsweise einen NMS(Network Managementsystem)-Server,
einen AAA-Server, einen Syslog(System Log)-Server usw. umfassen
können. Diese
verschiedenen Server können
in einem einzigen Computer oder einem anderen Verarbeitungselement
implementiert sein, oder jeder kann ein separates, selbständiges Element
oder einen Satz solcher Elemente umfassen.
-
Das
Unternehmensnetz umfasst bei dieser Ausführungsform ferner einen oder
mehrere Server oder andere Verarbeitungselemente, die als Kundenprodukte 124 bezeichnet
sind, sowie zusätzliche
verarbeitende Elemente 126 und 128. Die Elemente 126 stellen
Computer, Server oder andere Verarbeitungselemente dar, welche Produkte
eines als Verkäufer
A bezeichneten speziellen Verkäufers
sind. Analog stellen die Elemente 128 Computer, Server
oder andere Verarbeitungselemente dar, welche Produkte eines als
Verkäufer
B bezeichneten speziellen Verkäufers
sind. Das Unternehmensnetz, welches dem Kundenstandort 102 zugeordnet
ist, weist also interne Ressourcen auf, welche die Multi-Vendor-Produkte 126 und 128 umfassen,
wie auch zusätzliche
interne Ressourcen, die die Produkte 124 umfassen, welches
die Produkte des Kunden selbst sind. Die Produkte 124, 126 und 128 sind
wie gezeigt mit dem Unternehmensnetzsegment 110 verbunden.
-
Es
sei erwähnt,
dass der Begriff "Kunde", wie er im Zusammenhang
mit der beispielhaften Ausführungsform
genutzt wird, ein Unternehmen bezeichnet, welches die Produkte 126 und 128 von
jeweiligen Verkäufern
A und B erwirbt oder anderweitig erhält und das außerdem eines
oder mehrere seiner eigenen Produkte 124 nutzt. Die als
der Kunde bezeichnete Gesamtheit stellt bei dieser Ausführungsform
also einen Kunden der Verkäufer
A und B dar. Es ist zu erkennen, dass die Erfindung keine solche Kundenanordnung
erfordert, sondern allgemein auf jedes Geschäft, jede Organisation oder
jedes andere Unternehmen anwendbar ist, die interne Ressourcen besitzen,
für welche
eine externer Zugriff über
ein SSL-VPN- oder
ein anderes sicheres Gateway gesteuert wird.
-
Es
sollte außerdem
erkannt werden, dass ein gegebenes verarbeitendes Element des Systems 100 selbst
Multi-Vendor-Produkte
umfassen kann. Somit kann ein eingegebenes Produkt eines Verkäufers in
dem Sinne, wie der Begriff vorliegend verwendet wird, beispielsweise
einen speziellen Teil eines gegebenen verarbeitenden Elements umfassen,
beispielsweise ein Softwareprogramm, das auf diesem Element ausgeführt wird,
eine Hardwarekomponente dieses Elements, usw.
-
Der
Kundenstandort 102 umfasst außerdem eine SSL-Clienteinrichtung 130 für einen
lokalen Kundentechniker. Dies ist ein Techniker, der sich lokal
am Kundenstandort 102 befindet, hinter der Firewall 106 des
Unternehmensnetzes, und der Support für die Kundenprodukte 124 bietet.
Die SSL-Clienteinrichtung 130 des lokalen Kundentechnikers
ist mit dem Segment 108 des Unternehmensnetzes verbunden.
-
Die
verschiedenen Geräte
des Kundenstandorts 102 brauchen sich nicht alle am gleichen physischen
Einrichtungsstandort zu befinden. Beispielsweise kann der Standort
ein verteilter Standort sein, wobei bestimmte Geräte an unterschiedlichen technischen
Einrichtungen lokalisiert sind.
-
Das
externe Netz 104 stellt bei der vorliegenden Ausführungsform
ein Netz dar, welches das Internet- und das Frame Relay-Protokoll
unterstützt, obgleich
natürlich
auch andere Protokolle bei der Implementierung der Erfindung genutzt
werden können. Ein
gegebenes externes oder Unternehmensnetz kann bei einer Ausführungsform
der Erfindung beispielsweise ein globales Kommunikationsnetz wie etwa
das Internet, ein Intranet, ein Extranet, ein LAN, ein WAN, ein
Metropoliten Area Network (MAN), ein drahtloses zellulares Netz
oder ein Satellitennetz wie auch Teile oder Kombinationen dieser
oder anderer drahtgebundener oder drahtloser Kommunikationsnetze
umfassen. Für
die Implementierung der vorliegenden Erfindung ist also keine spezielle
Art von Netz oder kein spezieller Satz von Netzen erforderlich.
-
Das
externe Netz 104 ist mit einem Diensteanbieter 140 verbunden,
der dem Verkäufer
A zugeordnet ist, sowie mit einem Diensteanbieter 150, der
dem Verkäufer
B zugeordnet ist. Die Diensteanbieter 140 und 150 können vorliegend
auch als drittseitige Diensteanbieter bezeichnet werden, da sie Entitäten darstellen
können,
die separat zu dem Kunden oder den Produktanbietern bestehen. Für die Erfindung
ist jedoch keine spezielle Beziehung zwischen dem Kunden, den Diensteanbietern
und den Anbietern erforderlich, und die vorliegend beschriebenen
Verfahren können
in einfach zu übersehender Weise
für eine
Anwendung auf andere Arten von Funktionseinheiten angepasst werden.
-
Der
Diensteanbieter 140 umfasst Techniker- und Expertensysteme 142 für den Verkäufer A sowie eine
Authentifizierungsdatenbank 144. Analog umfasst der Diensteanbieter 150 Techniker-
und Expertensysteme 152 für den Verkäufer B sowie eine Authentifizierungsdatenbank 154.
Die Techniker- und Expertensysteme 142, 152 können jeweils
ein oder mehrere Expertensysteme umfassen, beispielsweise etwa Systeme
der Art, wie sie in der zuvor zitierten US-Patenanmeldung 10/939,694
beschrieben sind, als auch ein oder mehrere Technikergeräte wie etwa Computer,
mobile Kommunikationsgeräte
usw., welche genutzt werden können,
um Technikern zu gestatten, mit dem Kundenstandort 102 zu
kommunizieren. Wie später
detaillierter beschrieben wird, sind die Diensteanbieter 140 und 150 derart
konfiguriert, dass sie auf Alarmsignale ansprechen, die von den jeweiligen
Produkten 126 und 128 des Verkäufers A und des Verkäufers B
erzeugt werden, indem sie auf diese Produkte über das SSL-VPN-Gateway 120 zugreifen.
-
Jedem
der Diensteanbieter 140 und 150 ist eine entsprechende
föderierte
Kennung zugeordnet. Die föderierten
Kennungen dieser entsprechenden Systemelemente können entsprechend den Standards
des Liberty Alliance Projekts, www.projectliberty.org, eingerichtet
werden, wie sie beispielsweise in Liberty ID-FF Architecture Overview,
Version 1.2 beschrieben sind, welche hier durch Bezugnahme einbezogen
werden. Generell fasst eine föderierte
Kennung die Authentifizierungsinformationen zusammen, die typischerweise
erforderlich sind, um auf mehrere Netzentitäten auf individualer Basis
zuzugreifen, und zwar in einer Weise, die es einem Benutzer ermöglicht,
auf alle diese Entitäten über eine
einzige Anmeldung mit Hilfe seiner/ihrer föderierten Kennung zuzugreifen.
Die Netzentitäten
sind also verbündet
oder föderiert
insofern, als sie miteinander in einem gemeinsamen "Vertrauenskreis" verknüpft sind,
der über
die einzige Anmeldung (Single Sign-On – SSO) zugänglich ist. Die Kennung, die
dieser einzigen Anmeldung zugeordnet ist, wird als eine föderierte
Kennung oder Identität
bezeichnet. Ein Aspekt der Erfindung betrifft die Nutzung einer
föderierten
Idetität,
um ein Ansprechen der Diensteanbieter 140 und 150 auf
einen Alarm zu ermöglichen,
wie vorliegend noch detaillierter beschrieben wird.
-
Außerdem ist
an das externe Netz 104 ein SSL-Clientgerät 160 für einen
abgesetzten Kundentechniker angebunden. Dies ist ein Techniker,
der sich entfernt von dem Kundenstandort 102 außerhalb der
Firewall des Unternehmensnetzes befindet und der Support für die Kundenprodukte 124 bereitstellt. Das
SSL-Clientgerät 160 des
entfernten Kundentechnikers ist mit dem externen Netz 104 über ein SSL
VPN verbunden.
-
Die
Einrichtungen 120, 122, 124, 126, 128, 130, 140, 150 und 160 des
Systems 100 stellen Beispiele dafür dar, was vorliegend allgemeiner
als "Verarbeitungselemente" bezeichnet wird.
-
2 zeigt
ein vereinfachtes Blockdiagramm für eine mögliche Implementierung eines
gegebenen Verarbeitungselements 200 des Systems aus 1.
Das Verarbeitungselement 200 kann beispielsweise dem SSL-VPN-Gateway 120,
dem/den Kundensupport-Server(n) 122, einem der Produkte 124, 126 oder 128,
einem Element des Diensteanbieters 140 oder 150 oder
den SSL-Geräten 130 oder 160 entsprechen.
Generell umfasst jedes dieser Verarbeitungselemente einen Prozessor 202,
der mit einem Speicher 204 und einer oder mehreren Netzschnittstellen 206 verbunden
ist. Die Verfahren gemäß der vorliegenden
Erfindung können
zumindest teilweise in Form von Software implementiert sein, die
in dem Speicher 204 gespeichert ist und von dem Prozessor 202 ausgeführt werden
kann. Der Speicher 204 kann einen Direktzugriffsspeicher
(RAM), Nur- Lese-Speicher
(ROM), einen Speicher auf Basis einer optischen oder magnetischen
Platte oder andere Speicherelemente wie auch Teile oder Kombinationen
selbiger darstellen.
-
Fachleute
auf dem Gebiet werden erkennen, dass die einzelnen Komponenten aus 2,
wie sie der Veranschaulichung halber gezeigt sind, in einer oder
mehreren Verarbeitungseinrichtungen kombiniert sein können oder
auf diese verteilt sein können, z.
B. einen Mikroprozessor, eine anwendungsspezifische integrierte
Schaltung (ASIC), einen Computer oder (eine) andere Einrichtung(en).
-
Außerdem kann
das Verarbeitungselement 200 in Abhängigkeit davon, welche der
Systemeinrichtungen es implementiert, ferner zusätzliche Komponenten umfassen,
die nicht in der Figur gezeigt sind, aber typischerweise mit einer
solchen Einrichtung verknüpft
sind. Beispielsweise kann ein gegebenes Verarbeitungselement 200,
das eine Einrichtung 120, 122, 126 oder 128 implementiert,
zusätzliche Komponenten
umfassen, die üblicherweise
einem ansonsten herkömmlichen
Computer, einem Server, einer Gruppe von Servern usw. zugeordnet
sind. Als anderes Beispiel kann ein gegebenes Verarbeitungselement 200,
welches SSL-Clientgeräte 130 oder 160 implementiert,
zusätzliche
Komponenten umfassen, die üblicherweise
einem ansonsten herkömmlichen
Mobilkommunikationsgerät
wie etwa einem Mobiltelefon, einem persönlichen digitalen Assistenten (PDA)
oder einem tragbaren Computer oder einer anderweitigen herkömmlichen,
nicht mobilen Kommunikationseinrichtung wie etwa einem Arbeitsplatzrechner,
einem Server oder einer Gruppe von Servern zugeordnet sind, oder
allgemeiner jeder anderen Art von prozessorbasierter Einrichtung
oder Gruppe von Einrichtungen, die geeignet konfiguriert ist für eine Kommunikation
mit anderen Einrichtungen des Systems 100. Die herkömmlichen
Aspekte dieser und anderer Einrichtungen, die in dem System 100 genutzt
werden können,
sind im Fachgebiet allgemein bekannt und werden vorliegend daher
nicht weiter detailliert beschrieben.
-
Das
System 100 kann zusätzliche
Elemente umfassen, die in der Figur nicht explizit gezeigt sind, beispielsweise
zusätzliche
Server, Router, Gateways oder andere Netzelemente. Das System kann
außerdem
oder alternativ eine oder mehrere Kommunikationssystem-Vermittlungseinrichtungen
wie etwa eine Kommunikationssystem-Vermittlungseinrichtung DEFINITY® für Unternehmenskommunikationsdienst (ECS – Enterprise
Communication Service) umfassen, die bei der Avaya Inc., Basking
Ridge, New Jersey, USA erhältlich
ist. Als weiteres Beispiel kann eine gegebene Kommunikationsvermittlungseinrichtung,
die in Verbindung mit der vorliegenden Erfindung genutzt werden
kann, die Kommunikationssystem-Software MultiVantageTM umfassen,
die ebenfalls bei der Avaya Inc. erhältlich ist. Der Begriff "Verarbeitungselement", wie er vorliegend
genutzt wird, soll solche Vermittlungseinrichtungen wie auch Server,
Router, Gateways oder andere Netzelemente umfassen.
-
Es
sollte daher erkannt werden, dass die vorliegende Erfindung nicht
die speziellen Anordnungen erfordert, die in 1 gezeigt
sind, und zahlreiche alternative Konfigurationen, die zum Bereitstellen
des Alarm-Managements und der anderen vorliegend beschriebenen Funktionalität eines
sicheren Gateways geeignet sind, werden für Fachleute auf dem Gebiet in
einfacher Weise offensichtlich sein.
-
Das
SSL-VPN-Gateway 120 ist in der beispielhaften Ausführungsform
derart konfiguriert, dass es eine verbesserte Verarbeitung von Alarmsignalen, die
in dem System 100 erzeugt werden, bereitstellt. Wie zuvor
erwähnt,
sind herkömmliche SSL-VPN-Gateways
im Allgemeinen nicht dafür
konfiguriert, Alarmsignale von Multi-Vendor-Produkten an die diesen zugeordneten
Diensteanbieter auszuliefern oder den Diensteanbietern Zugang auf
die Produkte, welche die Alarmsignale erzeugt haben, zu gestatten.
Die vorliegende Erfindung löst
in der beispielhaften Ausführungsform
dieses Problem des Standes der Technik, indem ein Alarmmanager in
das SSL-VPN-Gateway integriert ist, um die Alarmsignale in einer
Art und Weise zu verarbeiten, bei welcher die Sicherheit gewahrt
wird, während
zugleich die Effizienz beträchtlich
erhöht
wird.
-
3 zeigt
eine Reihe von Elementen des SSL-VPN-Gateways 120 in der beispielhaften
Ausführungsform.
Bei dieser Ausführungsform
umfasst das SSL-VPN-Gateway einen Alarmmanager 300, der
einen Alarmsensor 302 und einen Alarm-Router 304 aufweist. Das SSL-VPN-Gateway
umfasst ferner einen Protokoll-Konverter 306 und ein Authentifizierungselement 308 für die föderierte
Kennung. Es sollte erkannt werden, dass das SSL-VPN-Gateway im Allgemeinen
zusätzliche
Komponenten umfassen wird, die bekannt sind, welche ähnlich denjenigen vorgesehen
sein können,
die sich in den zuvor aufgelisteten herkömmlichen SSL-VPN-Produkten
von Jumper Networks, Aventail oder Permeo finden.
-
Der
Alarmmanager 300 und andere Elemente des SSL-VPN-Gateways 120 können zumindest teilweise
mit Hilfe eines Prozessors und Speichers des Gateways implementiert
werden, wie sie in der vorstehenden Beschreibung von 2 angegeben sind.
Außerdem
können,
obgleich die Elemente 306 und 308 in der beispielhaften
Ausführungsform
als separat von dem Alarmmanager 300 vorgesehen gezeigt
sind, diese und andere Elemente des SSL-VPN-Gateways bei alternativen
Ausführungsformen
vollständig
oder teilweise in den Alarmmanager 300 integriert sein.
-
Der
Alarmmanager 300 stellt in der beispielhaften Ausführungsform
einen Multi-Protokoll-Alarmmanager dar, der über den Alarmsensor 302 Alarmsignale
von Kundenprodukten 124, Produkten 126 des Verkäufers A
und Produkten 128 des Verkäufers B in dem Unternehmensnetz
des Kundenstandorts 102 empfängt. Der Alarmmanager ist insofern
ein "Multiprotokoll"-Alarmmanager, als er in der Lage ist, Alarmsignale
zu behandeln, die von Einrichtungen erzeugt werden, welche unterschiedliche
Protokolle nutzen. Der Alarm-Router 304 legt einen geeigneten Leitweg
für die
empfangenen Alarmsignale fest. Beispielsweise können Alarmsignale, die Kundenprodukten 124 zuzuordnen
sind, zu dem SSL-Client 130 eines lokalen Kundentechnikers
oder zu dem SSL-Client 160 eines entfernten Kundentechnikers geleitet
werden. Alarmsignale, die Produkten 126 des Verkäufers A
und Produkten 128 des Verkäufers B zuzuordnen sind, können an
jeweils den Diensteanbieter 140 für den Verkäufer A und den Diensteanbieter 150 für den Verkäufer B geleitet
werden.
-
Um
die gewünschte
Wegelenkung auszuführen,
wird ein Alarmprotokoll, das von dem Alarmmanager 300 genutzt
wird, von dem Protokollkonverter 306 des SSL-VPN-Gateways 120 in
ein für
die Kommunikation mit derjenigen Entität, zu welcher der Alarm geleitet
wird, geeignetes Protokoll umgesetzt. Beispielsweise kann das SSL-VPN-Gateway
einen gegebenen Alarm in ein SNMP (Simple Network Management Protocol)-Protokoll
konvertieren, und zwar zur lokalen Verteilung an den Kundensupport-Server 122.
Als weiteres Beispiel kann das SSL-VPN-Gateway einen gegebenen Alarm in
SSL-kodiertes SNPM konvertieren, um diesen an einen der externen
Drittdiensteanbieter 140 oder 150 zu senden. Die
Erfindung erfordert kein spezielles Alarmprotokoll oder Übertragungsprotokoll,
und zahlreiche geeignete Anordnungen werden für Fachleute auf dem Gebiet
in einfacher Weise offensichtlich sein.
-
Wenn
ein gegebener Diensteanbieter 140 oder 150 einen
Alarm empfängt,
kann dieser Diensteanbieter oder ein zugehöriger Techniker, ein Expertensystem
oder ein anderes dienstleistendes Element einen ansonsten herkömmlichen
Webbrowser oder eine andere Zugriffseinrichtung oder einen anderen
Zugriffsmechanismus nutzen, um Zugang auf das den Alarm erzeugende
Produkt über
das SSL-VPN-Gateway 120 zu erlangen.
-
Der
Diensteanbieter 140 oder 150 nutzt eine föderierte
Kennung, um Zugang auf das den Alarm erzeugende Produkt über das
SSL-VPN-Gateway 120 zu erhalten. Bei einer solchen Anordnung
wird das Authentifizierungselement 308 für die föderierte Kennung
des SSL-VPN-Gateways 120 genutzt, um die angebotene föderierte
Kennung zu authentifizieren. Der Diensteanbieter 140 oder 150 kann
ein automatisiertes SSL-Skript
nutzen, das einen Login auf SSL-VPN-Basis, welcher die föderierte
Kennung umfasst, bereitstellt. Die föderierte Kennung kann bei einer
solchen Anordnung sämtliche
Techniker- und Expertensysteme
einschließen,
die dem Diensteanbieter zugeordnet sind. Solche Techniker- und Expertensysteme
sind Beispiele dafür,
was vorliegend allgemeiner als "dienstleistende
Elemente" des Diensteanbieters
bezeichnet wird. Somit braucht das SSL-VPN-Gateway bei einer solchen
Anordnung nur den Diensteanbieter anstatt jedes Techniker- oder Expertensystem
auf einzelner Basis zu authentifizieren. Damit werden in vorteilhafter
Weise die zuvor erwähnten
Probleme vermieden, beispielsweise diejenigen, die damit verbunden
sind, dass es erforderlich ist, dass jeder Techniker eines Diensteanbieters über mehrere
Hardware-Tokens für
die verschiedenen Kunden, für
die er Support bietet, verfügt.
Außerdem wird
durch diesen Ansatz die Belastung des AAA-Servers am Kundenstandort 102 wesentlich
reduziert, indem die Notwendigkeit wegfällt, große Gruppen von Techniker- oder
Expertensystemen von herstellerneutralen Diensteanbieters zu authentifizieren.
-
Ein
gegebener der Diensteanbieter 140 oder 150 würde typischerweise
zunächst
seine Techniker- oder Expertensysteme gegenüber seiner eigenen Authentifizierungsdatenbank 144 oder 154 authentifizieren.
Dies ist insofern vorteilhaft, als es gestattet, dass ein Diensteanbieter
mit hunderten oder tausenden von Technikern diese Techniker mit
Hilfe seiner eigenen Authentifizierungsverfahren authentifiziert. Der
Diensteanbieter würde
dann die Kennung des speziellen Techniker- oder Expertensystems
an das SSL-VPN-Gateway weiterleiten, zusammen mit der föderierten
Kennung, und zwar mit Hilfe des zuvor erwähnten automatisierten SSL-Skripts.
Das SSL-VPN-Gateway würde
wiederum nur die föderierte
Kennung und nicht die individuelle Kennung des Techniker- oder Expertensystems
zu authentifizieren brauchen.
-
Die
eingehende föderierte
Kennung eines gegebenen Diensteanbieters 140 oder 150 kann
in der beispielhaften Ausführungsform
unter Nutzung von SAML (Security Assertion Markup Language) von
OASIS, www.oasis-open.org, bereitgestellt werden, wie beispielsweise
in SAML Version 1.0, SAML Version 1.1 und SAML Version 2.0 beschrieben
ist, die hier alle durch Bezugnahme einbezogen werden. Andere Protokolle
können
ebenfalls oder alternativ genutzt werden, beispielsweise XML (Extensible Markup
Language), SOAP (Simple Object Access Protocol) usw.
-
Ein
gegebener Diensteanbieter kann sich dafür entscheiden, Dienstleistungsabteilungen
in Abhängigkeit
von den Arbeitsfertigkeiten oder anderen Faktoren zu schaffen. Bei
einer solchen Anordnung kann die föderierte Kennung, die unter
Ansprechen auf einen Alarm an das SSL-VPN-Gateway 120 übermittelt
wird, beispielsweise drei Entitätskennungen enthalten,
nämlich
eine Kennung des Diensteanbieters, eine Kennung der dienstleistenden
Abteilung des Diensteanbieters sowie die Kennung eines speziellen
Technikers. Es ist dann möglich,
dass das SSL-VPN-Gateway beispielsweise die ersten beiden Kennungen,
aber nicht die dritte authentifiziert. Die dritte würde jedoch
allgemein für
Abrechnungs- und Prüfzwecke
aufgezeichnet werden. Zahlreiche alternative Anordnungen mit mehreren
Kennungen zum Angeben von bestimmten Abteilungen eines Diensteanbieters
können
genutzt werden.
-
Der
Alarmmanager 300 kann darauf vorprogrammiert werden, Alarmsignale
von verschiedenen Produkten an spezielle Alarmempfänger von
Diensteanbietern zu senden. Diese Alarmempfänger können beispielsweise SSL-fähige Webserver
sein. Das SSL-VPN-Gateway 120 ermöglicht, dass Alarmverkehr in
sicherer und effizienter Weise von internen Ressourcen des Unternehmensnetzes
zu speziellen Elementen außerhalb
der Firewall 106 des Kunden fließt.
-
Die
Funktionsweise des Alarmmanagers 300 des SSL-VPN-Gateways 120 soll
nun mit Bezugnahme auf 1 detaillierter beschrieben
werden. Kommunikationsvorgänge
zwischen den verschiedenen Elementen des Systems 100 sind
durch Linien dargestellt, die in 1 mit Bezugszeichen 1 bis 7 bezeichnet
sind. Diesen Bezugszeichen sind die folgenden speziellen Verbindungsarten
zugeordnet.
-
Das
Bezugszeichen 1 bezeichnet eine eingehende Übermittlung
einer föderierten
Kennung mit Hilfe des SAML-Protokolls.
-
Das
Bezugszeichen 2 bezeichnet eine eingehende standardmäßige Authentifizierung.
-
Das
Bezugszeichen 3 bezeichnet Multi-Protokoll-Alarmsignale, die
Produkten 126 des Verkäufers
A zuzuordnen sind.
-
Das
Bezugszeichen 4 bezeichnet Multi-Protokoll-Alarmsignale, die
Produkten 128 des Verkäufers
B zuzuordnen sind.
-
Das
Bezugszeichen 5 bezeichnet Multi-Protokoll-Alarmsignale, die
Kundenprodukten 124 zuzuordnen sind.
-
Das
Bezugszeichen 6 bezeichnet standardmäßige SNMP-Verbindungen.
-
Das
Bezugszeichen 7 bezeichnet SSL-kodierte SNMP-Verbindungen.
-
Im
Betrieb werden Alarmsignale von Kundenprodukten 124, Produkten 126 des
Verkäufers
A oder Produkten 128 des Verkäufers B an den Alarmmanager 300 des
SSL-VPN-Gateways 120 gesendet. Alternativ oder zusätzlich kann
der Alarmmanager 300 jedes der Produkte periodisch im Hinblick
auf ausstehende Alarmsignale abfragen. Die Alarmsignale können in
einem beliebigen Format vorliegen und die Erfindung ist in dieser
Hinsicht nicht eingeschränkt.
In der beispielhaften Ausführungsform
werden die Alarmsignale mit Hilfe des Protokollkonverters 306 in
ein SNMP-Format konvertiert.
-
Wenn
ein gegebener Alarm von einem der Kundenprodukte 124 ausgeht,
wird der Alarm von dem Alarmmanager mit Hilfe einer standardmäßigen SNMP-Kommunikation
an den NMS-Server der Kundensupport-Server 122 geleitet.
Der NMS-Server oder ein anderes Verarbeitungselement des Kundenstandorts 102 kann
dann den Alarm entweder an den lokalen Kundentechniker 130 oder
den abgesetzten Kundentechniker 160 leiten, um eine Wiederherstellung
des Produkts zu initiieren.
-
Wenn
der gegebene Alarm von einem der Produkte 126 des Verkäufers A
stammt, wird der Alarm von dem Alarmmanager mit Hilfe von SSL-kodiertem
SNMP an den Diensteanbieter 140 geleitet.
-
Wenn
der gegebene Alarm von einem der Produkte 128 des Verkäufers B
stammt, wird der Alarm von dem Alarmmanager mit Hilfe von SSL-kodiertem
SNMP an den Diensteanbieter 150 geleitet.
-
Wenn
der lokale oder der entfernte Kundentechniker auf den Alarm anspricht,
greift er auf das den Alarm erzeugende Produkt 124 über das
SSL VPN mit Hilfe einer standardmäßigen Eingangsauthentifizierung
zu. Es sei angenommen, dass beim Kunden bereits Kennungen sowohl
für den
lokalen als auch für
den abgesetzten Techniker in dem AAA-Server der Kundensupport-Server 122 gespeichert
sind, sodass sich diese Techniker in einfacher Weise gegenüber dem
AAA-Server authentifizieren können.
Somit wird bei dieser speziellen Ausführungsform die föderierte
Kennung bei der Authentifizierung des lokalen oder abgesetzten Technikers
für die
Kundenprodukte 124 nicht genutzt. Bei anderen Ausführungsformen
kann die Authentifizierung solcher Techniker auch die Nutzung einer
föderierten Kennung
beinhalten.
-
Wenn
ein Diensteanbieter 140 oder 150 auf den Alarm
anspricht, greift dieser Diensteanbieter auf das den Alarm erzeugende
Produkt 126 oder 128 mit Hilfe einer eingehenden
föderierten
Kennung zu. In der beispielhaften Ausführungsform wird die eingehende
föderierte
Kennung mit Hilfe von SAML bereitgestellt, obgleich, wie vorliegend
bereits an anderer Stelle erwähnt
worden ist, andere Protokolle wie etwa XML-SOAP genutzt werden können. Das SSL-VPN-Gateway 120 empfängt sowohl
die Diensteanbieter-Kennung, welches die föderierte Kennung ist, als auch
die Kennung eines einzelnen Technikers oder Expertensystems dieses
Diensteanbieters. Das SSL VPN authentifiziert nur die föderierte Kennung,
d. h. die Kennung des Diensteanbieters. Das SSL VPN wird typischerweise
jedoch sowohl die Kennung des Diensteanbieters als auch die Kennung des
Technikers oder Expertensystems für Abrechnungs- und Prüfzwecke
protokollieren. Wie zuvor erwähnt,
kann ein Webskript genutzt werden, um den Authentifizierungsprozess
zu automatisieren.
-
Die
vorliegende Erfindung bietet in den zuvor beschriebenen beispielhaften
Ausführungsformen zahlreiche
Vorteile gegenüber
der herkömmlichen Praxis.
Beispielsweise ermöglicht
sie die Behandlung von Alarmsignalen von Multi-Vendor-Produkten, die Teil der internen
Ressourcen eines Unternehmensnetzes sind, indem eine einzige Stelle
für die
Kontrolle von eingehendem und ausgehendem Zugriff für alle Diensteanbieter
bereitgestellt wird. Indem einem Diensteanbieter gestattet wird,
seine eigenen Techniker, Expertensysteme oder anderen dienstleistenden Elemente
zu authentifizieren und dann eine föderierte Kennung zu nutzen,
um auf einen Alarm anzusprechen, vereinfacht sich ein AAA-Server, der die Abwicklung
für den
Kunden ausführt,
beträchtlich.
Anstatt dass Authentifizierungsinformationen für jeden möglichen von hunderten oder
tausenden Technikern, Expertensystemen oder anderen dienstleistenden
Elementen eines gegebenen Diensteanbieters gespeichert werden, brauchen
nur die Authentifizierungsinformationen für den Diensteanbieter selbst gespeichert
zu werden. Außerdem
ermöglicht
die beispielhafte Ausführungsform
eine Kompatibilität mit
Sicherheitsrichtlinien des Kunden, z. B. Richtlinien, die den Zugriff,
die Überwachung,
die Steuerung, die Protokollierung usw. betreffen. Bei Nutzung der erfindungsgemäßen Verfahren
brauchen Kunden nicht mehr einen externen Diensteanbieter anzurufen,
um diesen von einem Problem zu informieren, das zu einem Alarm geführt hat,
oder eine explizite Autorisierung bereitzustellen, um einem speziellen Techniker
oder Expertensystem des Diensteanbieters zu ermöglichen, Zugriff auf das Produkt
zu erhalten, um das Problem zu lösen.
Darüber
hinaus brauchen Techniker oder Expertensysteme von Diensteanbietern keine
unterschiedlichen Sätze
von Hardware-Tokens für
jeden Kunden zu unterhalten.
-
Wie
bereits erwähnt,
können
eine oder mehrere der Verarbeitungsfunktionen, die vorstehend in Verbindung
mit den beispielhaften Ausführungsformen
der Erfindung beschrieben worden sind, insgesamt oder teilweise
in Software implementiert werden, und zwar unter Nutzung des Prozessors 202 und
des Speichers 204, die einem oder mehreren Verarbeitungselementen
des Systems zugeordnet sind. Andere geeignete Anordnungen aus Hardware, Firmware
oder Software können
genutzt werden, um die erfindungsgemäßen Verfahren zu implementieren.
-
Es
sei erneut betont, dass die vorstehend beschriebenen Anordnungen
lediglich der Veranschaulichung dienen. Es sollte also erkannt werden,
dass die speziellen Elemente, Verarbeitungsvorgänge, Kommunikationsprotokolle
und andere Merkmale, die in den Figuren gezeigt sind, lediglich
beispielshalber angegeben sind und nicht als Anforderungen der Erfindung
betrachtet werden sollten. Beispielsweise können in alternativen Ausführungsformen
andere Konfigurationen der Verarbeitungselemente, andere Verarbeitungsvorgänge und
andere Kommunikationsprotokolle als die aus den beispielhaften Ausführungsformen
genutzt werden. Diese und zahlreiche andere alternative Ausführungsformen,
die innerhalb des Schutzumfangs der folgenden Ansprüche liegen, werden
für Fachleute
auf dem Gebiet offensichtlich sein.