DE60032733T2

DE60032733T2 - System und Verfahren zur einheitlichen Regelverwaltung mit integriertem Regelumsetzer

Info

Publication number: DE60032733T2
Application number: DE2000632733
Authority: DE
Inventors: Saurabh Saratoga Jain
Original assignee: Alcatel Internetworking Inc
Current assignee: Nokia of America Corp
Priority date: 1999-06-10
Filing date: 2000-06-12
Publication date: 2007-11-08
Anticipated expiration: 2020-06-13
Also published as: DE60028004D1; DE60032733D1; DE60034546D1; DE60034546T2; DE60028004T2

Description

BEREICH DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf Computernetze, und insbesondere auf Geräte und Verfahren zur Bereitstellung effizienter, integrierter und skalierbarer Policy-Managementdienste für entfernte private Netze über das Internet.
HINTERGRUND DER ERFINDUNG
Das Wachstum und die Verbreitung von Computern und Computernetzen ermöglicht Unternehmen, effizient mit ihren eigenen Komponenten sowie mit denen ihrer Geschäftspartner, Kunden und Lieferanten zu kommunizieren. Die Flexibilität und Effizienz, die diese Computer und Computernetze bieten, geht jedoch mit erhöhten Risiken einher, darunter auch Sicherheitsverletzungen von außerhalb des Unternehmens, die versehentliche Veröffentlichung von wichtigen internen Informationen und die unangemessene Nutzung von LAN, WAN, Internet oder Extranet.
Bei der Verwaltung der Erweiterung von Computernetzen sowie bei der Lösung der verschiedenen Sicherheitsprobleme setzen Netzwerkmanager häufig Managementdienste für Netzwerkrichtlinien wie z.B. Firewall-Schutz, Adresszuordnung im NAT-Verfahren (Network Address Translation), Spam-Filter, DNS-Caching, Web-Caching, VPN-Organisation (Virtuelle Private Netzwerke) und -Sicherheit sowie URL-Blocker ein, um die Netzbenutzer daran zu hindern, durch Nutzung der ISPs (Internet Service Provider) der Organisation auf bestimmte Internetseiten zuzugreifen. Jeder Service zum Policymanagement erfordert jedoch in der Regel ein separates Gerät, das konfiguriert, verwaltet und überwacht werden muss. Des Weiteren werden die vorhandenen Geräte immer zahlreicher, wenn die Organisation wächst und sich auf mehrere Standorte ausdehnt, wodurch die entsprechenden Ausgaben und der Aufwand für Konfiguration, Verwaltung und Überwachung der Geräte ebenfalls steigen.
Die Lösung für dieses Problem besteht nicht einfach darin, zahlreiche Managementfunktionen für Netzwerkrichtlinien in ein einzelnes Gerät an jedem Standort zu integrieren und jedem Standort zu ermöglichen, seine Policydaten mit anderen Standorten auszutauschen. Tatsächlich gibt es viele Hindernisse und Herausforderungen bei der Umsetzung einer solchen Methode. So erfordert beispielsweise ein Plan zur effizienten Spezifikation und Verteilung der Daten zum Policymanagement über ein entferntes privates Netz für die gesamte Organisation im Allgemeinen ein gut konzipiertes Objektmodell. Die Synchronisierung mehrerer Datenbanken innerhalb der Organisation mit Updates der Daten zum Policymanagement kann ebenfalls ein komplexes Problem darstellen. Des Weiteren ist die Erstellung von Protokollen und Statistikdaten aus dem entfernten privaten Netz in einem weit verteilten Policy-Managementsystem zur effizienten Analyse und Berichterstellung häufig eine schwierige Aufgabe. Üblicherweise werden nur die Rohdaten protokolliert und gespeichert, die im Allgemeinen zeitaufwändige und individuell erstellte Programme benötigen, um aus den Rohdaten offline sinnvolle Berichte und Statistiken zu erstellen.
Es gibt eine weitere Herausforderung für die Umsetzung eines einheitlichen Policy-Managementsystems. Für einen erhöhten Nutzen sollten diese einheitlichen Policy-Managementfunktionen so weit wie möglich in der Hardware implementiert werden. Die Implementierung des Policy-Managements auf einem Chip erfordert jedoch typischerweise eine effiziente Design-Partitionierung.
Außerdem sollte das einheitliche Policy-Managementsystem die effiziente Konfiguration, Verwaltung und Aktualisierung von virtuellen privaten Netzen ermöglichen, die sich über verschiedene entfernte Standorte erstrecken.
Im Patent EP 1 026 867 A2 werden ein System und ein Verfahren zur Unterstützung konfigurierbarer Dienste-Policies in Verzeichnisbasierten Netzen beschrieben.
Im Dokument „Policy-based networking architecture for QoS interworking in IP management" von D.C. Blight et al., 24. Mai 1999, XP002178128, werden zwei Methoden für eine skalierbare Architektur für den umfassenden Betrieb innerhalb von Unternehmen bzw. für die Öffentlichkeit beschrieben: Policy-Abstraktion und Hierarchie-Organisation mit Präzendenzregeln.
Dementsprechend besteht in der Branche Bedarf an einer Lösung zum Netzwerkmanagement, die diese und andere Hindernisse im gegenwärtigen Stand der Technik überwindet.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf ein einheitliches Policy-Managementsystem, in dem verschiedene Policies, insbesondere eine bestimmte Anzahl an Regeln und Anweisungen, die den Netzwerkbetrieb regeln, von einem einzelnen Standort aus erstellt und durchgesetzt werden können. Gemäß einer Ausführungsvariante der Erfindung umfasst das System eine erste Kanteneinrichtung, die einem ersten Netzwerk zugeordnet ist, das über einen ersten Satz Ressourcen verfügt, die entsprechend konfiguriert sind, um die Policies für das erste Netzwerk entsprechend den in einer ersten Datenbank gespeicherten Policy-Einstellungen zu verwalten. Das System umfasst außerdem eine zweite Kanteneinrichtung, die einem zweiten Netzwerk zugeordnet ist, das über einen zweiten Satz Ressourcen verfügt, die entsprechend konfiguriert sind, um die Policies für das zweite Netzwerk entsprechend den in einer zweiten Datenbank gespeicherten Policy-Einstellungen zu verwalten. Die erste und die zweite Kanteneinrichtung fungieren als Policy-Enforcer für ihre jeweiligen Netzwerke. Bei den durchgesetzten Policies kann es sich um Firewall-Policies, VPN-Policies und Ähnliches handeln.
Das System umfasst außerdem einen zentralen Policy-Server, der mit der ersten und der zweiten Kanteneinrichtung verbunden ist. Der Policy-Server ist entsprechend konfiguriert, um die ersten und die zweiten Policy-Einstellungen zu definieren und die erste und zweite Kanteneinrichtung von einem Standort aus zu verwalten. Auf diese Weise muss der Netzadministrator keine zusätzliche Arbeit oder zusätzliche Kosten für die Konfiguration und die Verwaltung der einzelnen Policy-Enforcer aufwenden.
In alternativen Ausführungsvarianten umfasst das einheitliche Policy-Managementsystem eines oder mehrere der folgenden Funktionen:
Der zentrale Policy-Server kann eine zentrale Datenbank zur Speicherung der Konfigurationsinformationen der Policy-Enforcers umfassen. Bei der zentralen Datenbank sowie bei den den Policy-Enforcern zugeordneten Datenbanken handelt es sich um LDAP-Datenbanken (Lightweight Directory Access Protocol), die entsprechend einer hierarchischen objektorientierten Struktur aufgebaut sind. Diese Struktur umfasst Ressourcenobjekte und Policy-Objekte zur Definition der Policy-Einstellungen für die Policy-Enforcer. Eine solche Struktur trägt dazu bei, das Policy-Management zu vereinfachen, indem verschiedene Elemente des Policy-Managementsystems auf intuitive und umfassende Weise definiert und organisiert werden.
Gemäß einer Ausführungsvariante der Erfindung umfassen die Ressourcenobjekte Einrichtungen, Nutzer, Hosts, Dienste und Zeit. Einrichtungen sind die Policy-Enforcer am Rand des jeweiligen privaten lokalen Netzwerks. Jedes Gerät ist Nutzern und einem Host zugeordnet. Ein Host ist ein Netz (z.B. ein LAN-Subnetz) in einer Organisation. Dienste sind die verschiedenen Dienste (z.B. http, TELNET, FTP), die von dem Policy-Server bereitgestellt werden. Zeit ist eine weitere Dimension bei der Zugangskontrolle für die Netzwerkressourcen.
Die zentrale Datenbank speichert die Konfigurationsinformationen, einschließlich der Policy-Einstellungen, für alle Policy-Enforcer. Wird eine Änderung an den Konfigurationsinformationen vorgenommen, erstellt der Policy-Server ein Protokoll dieser Änderungen und speichert es in der zentralen Datenbank zur späteren Übertragung an die Policy-Enforcer. Sobald die Policy-Enforcer das Änderungsprotokoll empfangen, aktualisieren sie ihre jeweiligen Datenbanken entsprechend und melden dem Policy-Server, ob die Aktualisierung erfolgreich verlaufen ist. War diese erfolgreich, wird das Änderungsprotokoll für diese Policy-Enforcer aus der zentralen Datenbank gelöscht.
Der zentraler Policy-Server kann außerdem einen Satz Nutzer-Anwendungsmodule umfassen, die einem Nutzer, wie beispielsweise dem Netzadministrator, ermöglichen, die Policy-Einstellungen für die Policy-Enforcer zu definieren und die Policy-Enforcer zudem von einem Standort aus zu verwalten. Die Policy-Einstellungen sind vorzugsweise einer Vielzahl von Ressourcen-Objekten, einschließlich Einrichtungen, Nutzern, Hosts, Diensten und Zeit, zugeordnet.
In einer Ausführungsvariante der Erfindung umfasst der Satz Anwendungsmodule ein zentrales Management-Submodul, um die Installation und die Registrierung der Policy-Enforcer im zentralen Policy-Server zu ermöglichen.
In einer anderen Ausführungsvariante der Erfindung umfasst der Satz Anwendungsmodule ein Policy-Management-Submodul zur Verwaltung und Darstellung der Ressourcenobjekte von einem einzigen Standort aus.
In einer weiteren Ausführungsvariante der Erfindung umfasst der Policy-Server einen Satz Nutzeranwendungsmodule, um einem Nutzer zu ermöglichen, den Zustand und den Status der Policy-Enforcer zu überwachen. Jeder Policy-Enforcer sammelt die Informationen über Zustand und Status in einem vordefinierten, gemeinsamen Protokollformat und überträgt sie an den Policy-Server. Der Policy-Server kann dann auf der Basis dieser Informationen verschiedene Berichte erstellen. Man kann daher davon ausgehen, dass die vorliegende Erfindung die Überwachung der Ressourcen in der Organisation während der Übertragung ermöglicht, wodurch die Erfindung weitere Vorteile gegenüber dem vorherigen Stand der Technik bietet, bei dem im Allgemeinen nur Rohdaten gesammelt werden und die langwierige Erstellung von Berichten erforderlich ist.
Die Funktionen der Policy-Enforcer bei der Durchsetzung der Policies für ihre jeweiligen Netze können zur effizienten Implementierung der Hardware auch aufgeteilt werden. Gemäß einer Ausführungsvariante der Erfindung umfasst jede Kanteneinrichtung vorzugsweise eine Vielzahl von Modulen, einschließlich einer Klassifikationsmaschine, einer Policy-Maschine und einer Paketweiterleitungsmaschine. Die Klassifikationsmaschine legt ein Protokoll in Verbindung mit einem eingehenden Paket fest. Die Policy-Maschine trifft eine Weiterleitungsentscheidung für das Paket auf der Basis der diesem Paket zugeordneten Policy-Einstellungen. Das Paketweiterleitungsmodul übermittelt das Paket dann auf der Basis der Policy-Einstellungen.
In alternativen Ausführungsvarianten kann das Modul außerdem eine Sicherheitsmaschine zur Überprüfung der Berechtigung eines Nutzers umfassen, der das Paket übermittelt, und/oder ein Statistikmodul zur Erfassung von Statistiken der Pakete, die den Policy-Enforcer durchlaufen.
Jedes der Netze im System kann auch aus privaten Netzen bestehen und jeder dem privaten Netz zugeordnete Policy-Enforcer ist entsprechend konfiguriert, eine Tabelle mit den Informationen der Mitgliedsnetze zu erstellen, die über den Policy-Enforcer erreichbar sind. Die Tabelle wird dann den anderen Mitglieds-Policy-Enforcern im VPN zur Verfügung gestellt. Dies ermöglicht die Erstellung von VPNs, deren Mitgliederlisten dynamisch kompiliert werden.
Unter einem besonderen Aspekt der Erfindung wird die Kommunikation zwischen dem ersten und dem zweiten privaten Netz entsprechend einer Sicherheitspolicy verwaltet, die den Mitgliedsnetzen zugeordnet ist. Die Sicherheitspolicy wird vorzugsweise für eine Gruppe von Sicherheitspolicies definiert, eine so genannte VPN-Cloud, die eine hierarchische Organisation der Gruppe ermöglicht. Die VPN-Cloud umfasst Mitgliedsnetze (Hosts), Nutzer, die Zugriff auf die Mitgliedsnetze haben, und eine Regel, die den Zugriff auf die Mitgliedsnetze kontrolliert. Die von den VPN-Clouds sichergestellte hierarchische Organisation bietet dem Netzadministrator somit die Möglichkeit, vollständig vernetzte VPNs zu erstellen, wobei jeder Standort innerhalb einer VPN-Cloud über die vollständige Connectivity mit jedem anderen Standort verfügt. Der Netzadministrator muss nicht mehr jede mögliche Verbindung im VPN manuell konfigurieren, er braucht lediglich eine VPN-Cloud zu erstellen und die dem VPN zugeordneten Standorte, Nutzer und Regeln zu spezifizieren. Jede Verbindung wird dann auf der Basis der für die VPN-Cloud spezifizierten Konfiguration konfiguriert. Die hierarchische Organisation erleichtert somit die Einrichtung einer VPN mit einer großen Anzahl an Standorten.
Unter einem weiteren Aspekt der Erfindung handelt es sich bei der Regel im VPN um eine Firewall-Regel, die die Zugriffskontrolle für den Verkehr innerhalb der Mitgliedsnetze gewährleistet. Solche Firewall-Regeln bieten dem Administrator die Möglichkeit zur präzisen Zugriffskontrolle für den Verkehr durch innerhalb der VPN, und zwar im Rahmen des verschlüsselten Zugriffs, den eine solche VPN bietet.
Unter einem weiteren Aspekt der Erfindung greift ein entfernter Nutzer von einem entfernten Standort über ein entferntes Nutzerterminal auf die Mitgliedsnetze zu. Das Terminal ist anhand einer Software entsprechend konfiguriert, um die Tabelle den dynamischen Mitgliedsinformationen von der Kanteneinrichtung, mit der es verbunden ist, herunterzuladen. Aktualisierungen der Mitgliedsinformationen werden im Folgenden automatisch an das entfernte Nutzerterminal übertragen, ohne dass das Terminal dazu neu konfiguriert werden muss.
Der Policy-Server und die Policy-Enforcer sowie andere Netzgeräte können ebenfalls im Hinblick auf eine hohe Verfügbarkeit konfiguriert werden, indem neben der Einheit erster Klasse (Primäreinheit) eine Einheit zweiter Klasse (Reserveeinheit) vorhanden ist, wodurch ein einzelner Störungspunkt vermieden wird. Unter einem Aspekt der Erfindung befindet sich die Reserveeinheit ursprünglich im inaktiven Status und geht später in den aktiven Status über, nachdem eine Störung der Primäreinheit erfasst wurde.
Unter einem weiteren Aspekt der Erfindung ermittelt jedes hoch verfügbare Gerät seinen Status als Primäreinheit, Reserveeinheit oder Standalone-Einheit (Einheit dritter Klasse) während der Initialisierung.
Unter einem weiteren Aspekt der Erfindung werden die in den Datenbanken der Primär- und Reserveeinheiten gespeicherten Konfigurationsinformationen synchronisiert, indem die Einheit erster Klasse in den aktiven Status versetzt wird, die Konfigurationsänderungen der ersten Datenbank in der Einheit erster Klasse empfangen und gespeichert werden, die Konfigurationsänderungen an die Einheit zweiter Klasse übertragen werden und die Konfigurationsänderungen in der Einheit zweiter Klasse gespeichert werden. Wenn die Primäreinheit in den inaktiven Status umschaltet, speichert die Reserveeinheit die Konfigurationsänderungen der zweiten Datenbank in der Einheit zweiter Klasse und überträgt diese Änderungen an die Primäreinheit, sobald diese wieder in den aktiven Status übergeht.
Unter einem weiteren Aspekt der Erfindung werden Aktualisierungen in den Primär- und Reserveeinheiten, wie beispielsweise Software-Updates, ebenfalls synchronisiert, indem die Update-Informationen an die Primäreinheit übertragen werden, die Primäreinheit aktualisiert wird, die Aktualisierung von der Primäreinheit an die Reserveeinheit übertragen und somit die Reserveeinheit aktualisiert wird. Somit braucht der Netzadministrator nicht den gleichen Aufwand nochmals zur Aktualisierung der Reserveeinheiten aufwenden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Diese und andere Merkmale, Ausführungen und Vorteile der vorliegenden Erfindung werden beim Durchlesen der folgenden, detaillierten Beschreibung, der anhängenden Ansprüche und der beiliegenden Zeichnungen deutlich, wobei:
1 stellt ein schematisches Blockdiagramm eines beispielhaften, einheitlichen Policy-Managementsystems dar;
2 stellt die hierarchische, objektorientierte Struktur der Policies dar, die für eine Organisation entsprechend den Prinzipien der Erfindung gespeichert sind;
3 stellt ein schematisches Blockdiagramm eines Policy-Servers im Policy-Managementsystem aus 1 dar;
4 stellt ein schematisches Diagramm eines zentralen Management-Submoduls im Policy-Server aus 3 dar;
5 stellt ein beispielhaftes Ablaufdiagramm eines Einrichtungs-Registrierungsverfahrens dar, das vom zentralen Management-Submodul aus 4 durchgeführt wird;
6 stellt eine Bildschirmdarstellung einer beispielhaften graphischen Benutzerschnittstelle für die Registrierung einer Einrichtung dar;
7 stellt eine Bildschirmdarstellung einer beispielhaften globalen Benutzerschnittstelle zur Überwachung der Zustands- und Statusinformationen einer Einrichtung dar;
8 ist eine Bildschirmdarstellung einer beispielhaften graphischen Benutzerschnittstelle, die das Submodul für Policy-Management im Policy-Server aus 3 bietet;
9 ist eine Bildschirmdarstellung einer beispielhaften graphischen Benutzerschnittstelle zur Verwaltung von Systemeinrichtungen;
10 ist eine Bildschirmdarstellung einer beispielhaften graphischen Benutzerschnittstelle zur Verwaltung von Systemhosts;
11 ist eine Bildschirmdarstellung einer beispielhaften graphischen Benutzerschnittstelle zur Verwaltung von Systemeinrichtungen;
12 ist eine Bildschirmdarstellung einer beispielhaften graphischen Benutzerschnittstelle zur Verwaltung von Zeitgruppen;
13 ist eine Bildschirmdarstellung einer beispielhaften graphischen Benutzerschnittstelle, die eine Reihe von VPN-Clouds anzeigt;
14 ist eine Bildschirmdarstellung einer beispielhaften graphischen Benutzerschnittstelle zur Eingabe einer neuen Firewall-Policy;
15 ist ein schematisches Blockdiagramm von Policy-Enforcern, die ihre jeweiligen VPN-Mitgliedschaftsinformationen aktualisieren;
16 ist ein Blockdiagramm von Komponenten in einem selbstextrahierenden Ausführungsprogramm zum Herunterladen eines entfernten VPN-Clients;
17 ist ein Funktionsblockdiagramm zum Herunterladen des selbst-extrahierenden Ausführungsprogramms aus 16;
18 ist ein schematisches Blockdiagramm eines Policy-Enforcers im Policy-Managementsystem aus 1;
19 ist ein detailliertes, schematisches Blockdiagramm einer Policy-Maschine im Policy-Enforcer aus 18;
20 ist ein detaillierteres, schematisches Blockdiagramm einer Protokoll-Klassifikationsmaschine des Policy-Enforcers aus 18;
21 ist ein detaillierteres, schematisches Blockdiagramm einer Internetprotokoll-Sicherheitsmaschine im Policy-Enforcer aus 18;
22 ist eine schematische Darstellung eines allgemeinen Protokollformats gemäß einer Ausführungsvariante der Erfindung;
23 ist ein Blockdiagramm einer LDAP-Baumstruktur gemäß einer Ausführungsvariante der Erfindung;
24 ist ein detaillierteres Blockdiagramm eines Zweigs der LDAP-Baumstruktur aus 23;
25 ist ein Ablaufdiagramm der Protokollierung und Weiterleitung von LDAP-Änderungen an die Policy-Enforcer;
26 ist ein schematisches Blockdiagramm eines hochverfügbaren Systems, das eine Primäreinheit und eine Reserveeinheit umfasst;
27 ist ein Ablaufdiagramm eines beispielhaften Prozesses zur Statusermittlung, der von einer hochverfügbaren Einheit ausgeführt wird;
28 ist ein Ablaufdiagramm eines Prozesses zur Aufrechterhaltung der Konfigurationsinformationen, die in der Primär- und in der Reserveeinheit aus 26 synchronisiert werden;
29 ist ein beispielhaftes Ablaufdiagramm der Aktualisierung von Primär- und Reserveeinheit aus 26, im dem beide betriebsbereit sind; und
30 ist ein beispielhaftes Ablaufdiagramm der Aktualisierung von Primär- und Reserveeinheit aus 26, in dem die Primäreinheit nicht betriebsbereit ist.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
I. EINHEITLICHE ARCHITEKTUR DES POLICY-MANAGEMENTSYSTEMS
1 ist ein schematisches Blockdiagramm eines beispielhaften einheitlichen Policy-Managementsystems gemäß einer Ausführungsvariante der Erfindung. Wie in 1 dargestellt, sind die privaten lokalen Netze 102, 104 und 106 alle über entsprechende Router (generell mit 110 bezeichnet) und Internet Service Provider (ISPs) (nicht abgebildet) mit einem öffentlichen Netz, wie beispielsweise dem Internet 108, verbunden. Ebenso über die ISPs mit dem öffentlichen Internet 108 verbunden sind Internet-Surfer 112, über temporäre Wählverbindungen verbundene Netzwerk-Nutzer 114, Server 116, die unbefugte Websites bieten, Mail-Spammer 118, die unaufgefordert Junk-Mail versenden, sowie entfernte VPN-Clients 140, die Zugang zu den privaten lokalen Netzen 102 erhalten möchten.
Gemäß einem Beispiel verbindet das lokale Netz 102 Nutzer und Ressourcen, beispielsweise Workstations, Server, Drucker und Ähnliches, an einem ersten Standort der Organisation, beispielsweise der Zentrale der Organisation, und das lokale Netz 104 verbindet Nutzer und Ressourcen an einem zweiten Standort der Organisation, beispielsweise in einer Niederlassung. Des Weiteren verbindet das lokale Netz 106 Nutzer und Ressourcen eines Kunden der Organisation, der speziellen Zugang zu den Nutzern und Ressourcen der Organisation benötigt. Befugte, über Wählverbindungen verbundene Nutzer 114 der Organisation befinden sich an vom ersten und zweiten lokalen Netz entfernten Standorten und benötigen ebenfalls speziellen Zugang zu den Nutzern und Ressourcen der Organisation. Des Weiteren kommunizieren Internet-Surfer 112 mit dem Internet-Server 120 der Organisation über das öffentliche Internet 108 und greifen auf die Internetseite des Unternehmens zu.
Das lokale Netz 102 umfasst einen Policy-Server 122 zur Definition und Verwaltung der Netzwerkdienste und der Policies für die Organisation. Die Netzwerk-Policies sind ein Satz mit Regeln und Anweisungen, die den Betrieb des Netzes sowie Firewall, VPN, Bandbreite und Verwaltungsrichtlinien festlegen. Die Firewall- Policies entscheiden über den Datenverkehr im Netz, der aus dem öffentlichen Internet 108 für die lokalen Netze 102, 104, freigegeben wird und über den Datenverkehr, der blockiert werden soll. Die Bandbreiten-Policies entscheiden über die Art der Bandbreite, die dem Datenverkehr in den lokalen Netzen zugeordnet werden soll. Die VPN-Policies legen die Regeln für die Implementierung der Connectivity mit mehreren Standorten über die lokalen Netze fest. Die Verwaltungs-Policies legen die Nutzer fest, die Zugang zu den Verwaltungsfunktionen haben, die Art der diesen Nutzern zugeordneten Verwaltungsfunktionen und die Policy-Enforcer 124, 126, für die diese Nutzer diese Verwaltungsfunktionen ausüben können. Die Firewall-, VPN-, Bandbreiten- und Verwaltungs-Policies für die gesamte Organisation werden vorzugsweise in einer Policy Server-Datenbank 130 gespeichert, die vom Policy-Server 122 verwaltet wird.
Jedes lokale Netz 102, 104, umfasst auch eine Kanteneinrichtung, hier als Policy-Enforcer 124, 126, bezeichnet, für die Zugangskontrolle zum Netz. Jeder Policy-Enforcer 124, 126, verwaltet die Netzwerk-Policies und Dienste für die Nutzer und Ressourcen der jeweiligen lokalen Netze 102, 104, gemäß der Freigabe des Policy-Servers 122. Die entsprechenden Anteile der Policy Server-Datenbank 130 werden in die Datenbanken 132, 134, der Policy-Enforcer kopiert, damit die Policy-Enforcer die Netz-Policies und Dienste für die lokalen Netze 102, 104, verwalten können.
Gemäß einer Ausführungsvariante der Erfindung können der Policy-Server 122 und die Policy-Enforcer 124, 126, auf ähnliche Weise implementiert werden wie die Policy-Router FORT KNOX von der Firma Alcatel Internetworking Inc. in Milpitas, Kalifornien.
II. OBJEKTMODELL FÜR DAS NETZPOLICY-MANAGEMENT
Gemäß einer Ausführungsvariante der Erfindung handelt es sich bei der Policy Server-Datenbank 130 und den Policy Enforcer-Datenbanken 132, 134, um LDAP-Datenbanken, die sich an eine einheitliche, hierarchische, objektorientierte Struktur halten. Das LDAP Directory Service-Modell basiert auf Einträgen, wobei jeder Eintrag eine Auflistung von Attributen darstellt, die mit einem eindeutigen Namen (DN) bezeichnet werden. Jedes Attribut beinhaltet einen Typ und einen oder mehrere Werte. Der Typ ist üblicherweise eine mnemonische Zeichenfolge, wie z.B. „o" für Organisation, „c" für Country (Land) oder „mail" für E-Mail-Adressen. Die Werte hängen vom Attributtyp ab. Das Attribut „mail" kann beispielsweise den Wert „babs@umich.edu" beinhalten. Das Attribut „jpegPhoto" kann ein Foto in einem binären JPEG/JFIF-Format enthalten. Weitere Angaben über das LDAP Directory Service-Modell sind unter RFC 1777 „The Lightweight Directory Access Protocoll" (W. Yeong, T. Howes und Kille, Network Working Group, März 1995) und "LDAP Programming: Directory-enabled Applications with Lightweight Directory Access Protocol" (T. Howes und M. Smith, Macmillan Technical Publishing, 1997) definiert.
Die Einträge in der LDAP-Datenbank sind vorzugsweise in einer hierarchischen, baumähnlichen Struktur aufgebaut, die politische, geographische und/oder organisatorische Grenzen berücksichtigt. Die Einträge, die Länder darstellen, erscheinen an der Spitze der Baumstruktur. Darunter erscheinen die Einträge, die staatliche oder nationale Organisationen darstellen. Unter den staatlichen oder nationalen Organisationen können Einträge in Bezug auf Personen, Organisationseinheiten, Drucker, Dokumente und Ähnliches aufgeführt werden.
2 ist eine schematische Darstellung der einheitlichen, hierarchischen, objektorientierten Struktur, an die sich die Policy-Server-Datenbank 130 gemäß einer Ausführungsvariante der Erfindung hält. Die Policy Enforcer-Datenbanken 132, 134, folgen mit Ausnahme weniger Unterschiede der gleichen Struktur. So enthalten die Policy-Enforcer-Datenbanken zum Beispiel vorzugsweise weder ein Policy- Server-Domänenobjekt 201 oder damit verbundene Policy-Serverobjekte, noch ein Policy-Domänenobjekt 240.
Wie in 2 dargestellt, wird jedes Objekt in der Struktur vorzugsweise als LDAP-Eintrag gespeichert. An der Spitze der Hierarchie ist das Policy-Server-Domänenobjekt 201 angeordnet, das verschiedene Policy-Serverressourcen und eine Reihe von Policy-Domänenobjekten (im Allgemeinen mit 204 bezeichnet) umfasst. Jedes Policy-Domänenobjekt 240 ist eine Gruppierung von Policy-Enforcern mit gemeinsamen Policies. Jedes Policy-Domänenobjekt 240 umfasst ein Ressourcen-Wurzelobjekt 200 und ein Gruppen-Wurzelobjekt 202. Sämtliche Policy-Managementfunktionen sind vorzugsweise in Form von Ressourcenobjekten implementiert, die Einrichtungen 204, Nutzer 206, Hosts 208, Dienste 210 und Zeit 220 umfassen. Somit kann eine Firewall-Policy definiert werden, indem einfach die für die Policy geltenden Einrichtungen, Nutzer, Hosts, Dienste und Zeiten zugeordnet werden. Die Einrichtungen, Nutzer, Hosts und Dienste sind vorzugsweise in Gruppen 212, 214, 216 und 218, mit einem Gruppennamen, einer Beschreibung und den Mitgliedsinformationen organisiert, um eine intuitivere Art der Adressierung und Organisation der Ressourcen zu gewährleisten.
Die Nutzer 206 sind vorzugsweise einer Nutzerdomäne zugeordnet, die ein sicheres und effizientes Mittel zu Überprüfung der Nutzerberechtigung bietet. Jede Nutzerdomäne verfügt über einen einzelnen Policy-Enforcer, der befugt ist, die Nutzerberechtigung zu überprüfen. Somit gewährleisten Nutzerdomänen, dass sich der zur Überprüfung berechtigte Agent im Allgemeinen im gleichen lokalen Netz befindet wie der Nutzer. Auf diese Weise können die Kosten der Netzabhängigkeit oder der Netzlatenzzeit während des Nutzer-Überprüfungsprozesses reduziert werden. Es ist jedoch anzumerken, dass es sich bei den Nutzern auch um befugte, im Wählverfahren angeschlossene Nutzer 114 und Nutzer aus dem Kundennetz 106 handeln kann. Diese Nutzer kontaktieren einen entfernten Agenten zur Überprüfung der Berechtigung, der die Nutzerüberprüfung zurück an den entsprechenden Proxy-Policy-Enforcer übermittelt.
Hosts 208 sind die verschiedenen, in einer Organisation vorhandenen Netze. Ein bestimmtes LAN-Teilnetz kann beispielsweise in einem System als Host spezifiziert werden. Hosts 208 sind vorzugsweise auf der Grundlage ihres physischen Standorts innerhalb der Organisation organisiert. Der physische Standort eines Hosts wird von der Einrichtung (Policy-Enforcer) 204 gekennzeichnet, die dem Host zugeordnet ist.
Dienste 210 beinhaltet die verschiedenen Dienste, die vom Policy-Server 122 bereitgestellt werden. Solche Dienste sind beispielsweise Multimedia-Streaming/-Konferenzen, Abruf von Informationen, Sicherheit und Überprüfung von Berechtigungen, Datenbankanwendungen, E-Mail-Anwendungen, Routing-Anwendungen, Standard-Kommunikationsprotokolle und Ähnliches. Die dem jeweiligen Dienst zugeordneten Attribute umfassen vorzugsweise Dienstnamen, Beschreibung, Typ (z.B. HTTP, HTTPS, FTP, TELNET, SMTP, Real Networks und Ähnliches) und Gruppe.
Einrichtungen 204 sind die Policy-Enforcer 124, 126, an den Kanten eines bestimmten lokalen Netzes. Jede/-r Einrichtung/Policy-Enforcer umfasst vorzugsweise Nutzer 206 und ein/-en Host/Netz 208, das von dem Policy-Enforcer verwaltet wird.
Zeit 220 ist eine weitere Dimension für die Zugangskontrolle zu den Netzwerkressourcen. Bei der Erstellung der Firewall-Policies können verschiedene Zeitobjekte, die einen bestimmten Zeitbereich abdecken, erstellt und genutzt werden.
Ähnlich wie Ressourcen werden auch die Netz-Policies vorzugsweise in Form von Objekten zur effizienten und intuitiven Definition der Policies definiert. Policies werden von den Administratoren definiert und von den Policy-Enforcern 124, 126, im Netzverkehr zwischen dem öffentlichen Internet 108 und den lokalen Netzen 102 und 104 durchgesetzt.
Gemäß einer Ausführungsvariante der Erfindung umfasst ein Policy-Objekt 222 eine Bandbreiten-Policy 224, eine Firewall-Policy 226, eine Verwaltungspolicy 228 und eine VPN-Policy 230. Die VPN- Policy 230 definiert eine Sicherheitspolicy für die Mitgliedsnetze und umfasst eine oder mehrere VPN-Clouds 232. Jede VPN-Cloud 232 ist ein einzelnes VPN oder eine Gruppe VPNs, die eine Gruppe mit Sicherheitspolicies definieren, die eine Liste der Standorte 234 und Nutzer 236 umfasst, die miteinander kommunizieren können. Ein Standort ist vorzugsweise eine Gruppe aus Hosts/Netzen, die physisch hinter einem der Policy-Enforcer 124, 126 angeordnet sind. In anderen Worten ist ein Standort die Definition eines Netzes, das den Policy-Enforcer umfasst, der mit ihm verbunden ist. Die Policy-Enforcer für die Standorte fungieren als VPN-Tunnelendpunkte, sobald die Hosts an den Standorten zu kommunizieren beginnen. Diese Kommunikationen unterliegen bestimmten Regeln 238, die für jede VPN-Cloud konfiguriert werden. Die Regeln 238 können, unter anderem, VPN-Zugangsberechtigungen und Sicherheitsmerkmale, wie z.B. das Niveau der Verschlüsselung und die verwendete Zugangsberechtigung für die Connectivity auf der jeweiligen Netzebene vorgeben.
Die objektorientierte Struktur aus 2 bietet den Netzadministratoren die Möglichkeit, die Policies auf intuitive und umfassende Weise zu definieren. Solche Policies können durch einfache Zuordnung von Ressourcen und Policies definiert werden. Dies ermöglicht ein auf die Policy ausgerichtetes Managementmodell, in dem der Administrator den Eindruck erhält, dass ein einzelner logischer Server die Firewall, das Bandbreiten-Management und die VPN-Dienste für das gesamte Unternehmen bereitstellt. Die Tatsache, dass die Policy über einzelne Policy-Enforcer an verschiedenen Standorten durchgesetzt wird, ist für den Administrator transparent.
III. POLICY-BASIERTE NETZARCHITEKTUR
3 ist ein detaillierteres schematisches Blockdiagramm des Policy-Servers 122 gemäß einer Ausführungsvariante der Erfindung. Der Policy-Server 122 umfasst vorzugsweise ein Management-Modul 302, das die zentrale Steuerung der Policy-Enforcer 124, 126, von einer einzelnen Konsole aus ermöglicht. Der Policy-Server 122 umfasst außerdem ein Protokollerfassungs- und -archivierungsmodul 304 und ein Policy-Server-Berichtmodul 316. Das Protokollerfassungs- und -archivierungsmodul 304 erfasst Informationen über den Status und den Einsatz der Ressourcen von den Policy-Enforcern 124, 126, sowie vom Management-Modul 302, und speichert diese in einer Archivdatenbank 318. Das Policy-Server-Berichtmodul 316 verwendet die erfassten Protokolle und Archivdaten, um Berichte in einem strukturierten Berichtformat zu erstellen.
In Bezug auf das Management-Modul 302, umfasst das Management-Modul 302 vorzugsweise vier Submodule, die die zentrale Steuerung unterstützen, insbesondere ein zentrales Management-Submodul 306, ein Policy-Management-Submodul 308, eine sicheres, rollenbasiertes Management-Submodul 310 und ein Management-Submodul für die Connectivity mit mehreren Standorten 312.
Das zentrale Management-Submodul 306 bietet dem Netzadministrator die Möglichkeit, einzelne Policy-Enforcer von einem zentralen Standort aus zu installieren und zu verwalten. Der Netzadministrator nutzt vorzugsweise eine graphische Benutzerschnittstelle auf Webbasis, um die Netzkonfiguration des Policy-Enforcers zu definieren und verschiedene Aspekte der Einrichtung zu überwachen, z.B. den Status der Einrichtung, die Alarmmeldungen, den VPN-Anschlussstatus und Ähnliches.
Das Policy-Management-Submodul 308 bietet dem Netzadministrator die Möglichkeit, Policies zu erstellen, die zahlreiche Funktionsaspekte des Policy-Enforcers (z.B. Firewall, Bandbreiten-Management und virtuelle private Netze), zahlreiche Ressourcen (z.B. Nutzer, Hosts, Dienste und Zeit) und mehrere Policy-Enforcer umfassen.
Das sichere, rollenbasierte Management-Submodul 310 gewährleistet ein rollenbasiertes Management, das den Administratoren die Möglichkeit bietet, die Verwaltungsfunktionen an andere Administratoren zu delegieren. Dieses Submodul gewährleistet vorzugsweise die maximale Sicherheit in Bezug auf den Zugriff auf die Managementfunktionen.
Das Management-Submodul für die Connectivity mit mehreren Standorten 312 ermöglicht dem Netzadministrator, sichere Kommunikationskanäle zwischen einem oder mehreren entfernten Standorten einzurichten. Dabei nutzt dieses Submodul das zentrale Management-Submodul 306, das Policy-Management-Submodul 308, die dynamischen Routingfähigkeiten der Policy-Enforcer 124, 126, und die Managementinfrastruktur, um virtuelle private Netze innerhalb des Unternehmens mit detaillierter Zugangskontrolle bereit zu stellen.
4 ist eine detailliertere schematische Darstellung des zentralen Policy-Management-Submoduls 306 gemäß einer Ausführungsvariante der Erfindung. Das Submodul umfasst einen Policy-Server-Installationsassistenten 404, der eine interaktive Benutzerschnittstelle bietet, die Hilfestellung für die Installation des Policy-Servers 122 bietet. Zu diesem Zweck hat der Netzadministrator Zugang zu einem Personal Computer, der über ein Verbindungskabel, einen Hub oder Ähnliches an den LAN-Port des Policy-Servers 122 angeschlossen ist. Der Netzadministrator stellt die Verbindung zum Policy-Server 122 vorzugsweise durch die Eingabe der URL des Policy-Servers 122 in einen Standard-Internetbrowser, wie beispielsweise den Microsoft Internet Explorer, her. Die URL weist vorzugsweise folgende Form auf:
„http://<ipaddress>:88/index.html", wobei <ipaddress> der dem Policy-Server zugeordneten IP-Adresse entspricht. Die IP-Adresse wird dem Policy-Server automatisch zugeordnet, wenn der Browser versucht, mit dieser Adresse Verbindung aufzunehmen. Wenn der Personal Computer des Administrators eine Address Resolution Protocol-Anfrage für die IP-Adresse versendet, erfasst der Policy-Server, dass ein Paket an Port 88 nicht beansprucht wird und nimmt die IP-Adresse an.
Sobald die Verbindung hergestellt ist, ruft der Policy-Server-Installationsassistent 404 die interaktive Benutzerschnittstelle auf, den Netzadministrator bei der Einrichtung des Policy Servers 122 zu unterstützen. Der Policy-Server-Installationsassistent 404 fordert den Administrator unter anderem auf, einen Servernamen, eine IP-Adresse für den Server und eine IP-Adresse für den Router einzugeben. Außerdem fordert der Policy-Server-Installationsassistent 404 den Administrator auf, eine der verschiedenen Standard-Policies zur Erstellung von Standard- Firewall, VPN, Bandbreite und Administrator-Policies auszuwählen. Diese Policies werden dann auf jedem neuen Policy-Enforcer repliziert, der beim Policy-Server 122 registriert wird.
Das zentrale Management-Submodul 306 umfasst außerdem einen Policy-Enforcer-Installationsassistenten 406, der eine interaktive Benutzerschnittstelle zur Unterstützung der Installation der Policy-Enforcer 124, 126, bietet. Ebenso wie bei der Installation des Policy-Servers 122, erfolgt der Zugriff auf den Assistenten 406 vorzugsweise auf Webbasis über den Personal Computer des Netzadministrators.
Sobald die Verbindung hergestellt ist, fordert der Policy-Enforcer-Installationsassistent 406 die interaktive Benutzerschnittstelle auf, den Netzadministrator bei der Einrichtung eines bestimmten Policy-Enforcers 124, 126 zu unterstützen. Der Policy-Enforcer-Installationsassistent 464 fordert den Administrator unter anderem auf, die IP-Adresse des Policy-Servers, die IP-Adresse des Policy-Enforcers und die IP-Adresse des Routers einzugeben. Der Policy-Enforcer wird dann im Policy-Server 122 registriert, indem er im Policy-Server die URL mit seinen eigenen grundlegenden Bootstrap-Informationen aufruft. Die Registrierung des Policy-Enforcers ermöglicht die Initialisierung der Policy-Enforcer-Datenbank 132, 134, mit den Konfigurationsinformationen sowie die Überwachung von Status und Zustand des Policy-Enforcers über den Policy-Server 122.
Vor der Registrierung des Policy-Enforcers im Policy-Server 122, meldet der Netzadministrator den Policy-Enforcer vorzugsweise im Policy-Server an. Diese Voranmeldung ermöglicht die Erstellung eines Platzhalterknotens im Policy-Server für die Daten des Policy-Enforcers, wenn sich der Policy-Enforcer tatsächlich registriert. Zu diesem Zweck umfasst das zentrale Management-Submodul 306 eine Konfigurationsschnittstelle 410, die die Voranmeldung eines neuen Policy-Enforcers ermöglicht.
5 ist ein beispielhaftes Ablaufdiagramm für den Voranmelde- und Registrierungsprozess eines Policy-Enforcers gemäß einer Ausführungsvariante der Erfindung. In Schritt 401 wird der Policy-Enforcer mit dem Netz verbunden und mit Hilfe des oben beschriebenen Policy-Enforcer-Installationsassistenten 406 an seinem tatsächlichen, physischen Standort installiert. Der Netzadministrator, der über die Seriennummer der neuen Einrichtung verfügt, meldet den Policy-Enforcer an, indem er in Schritt 403 einer Gerätegruppe einen neuen Policy-Enforcer hinzufügt. Zu diesem Zweck ruft die Konfigurationsschnittstelle 410 eine interaktive graphische Schnittstelle auf, wie in 6 dargestellt, die dem Netzadministrator die Möglichkeit bietet, den Gerätenamen 415, die Seriennummer 417 und die Angaben zum Standort 419 einzugeben; außerdem hat der Administrator die Möglichkeit, eine Gerätegruppe 421 auszuwählen, der der neue Policy-Enforcer angehören soll. Durch die Betätigung einer Schaltfläche 423 nimmt der neue Policy-Enforcer in Schritt 405 mit dem Policy-Server 122 Verbindung auf, indem er vorzugsweise eine URL im Policy-Server aufruft. Sobald die Verbindung zum Policy-Server hergestellt wurde, übermittelt der neue Policy-Enforcer dem Policy-Server sein Registrierungspaket. Das Registrierungspaket umfasst mindestens die Seriennummer des neuen Policy-Enforcers sowie die IP-Adressen von LAN, WAN und DMS im Policy-Enforcer. In Schritt 407 vergleicht das zentrale Management-Submodul 306 die Seriennummer des neuen Policy-Enforcers mit der Liste der im Policy-Server 122 vorangemeldeten Policy-Enforcer. Wird eine Übereinstimmung gefunden, führt der Policy-Server 122 den Registrierungsprozess durch, indem er in Schritt 409 die Einstellungen, die bei der Installation für den Policy-Enforcer festgelegt wurden, vorzugsweise in einer Datei im LDAP-Datenaustauschformat (ldif) abspeichert. In Schritt 411 wird die Datei an den Policy-Enforcer, vorzugsweise über einen HTTPS-Kanal übertragen, indem ein Common Gateway Interface (CGI) im Policy-Enforcer aufgerufen wird. Der Policy-Enforcer verwendet dann die Datei, um in Schritt 413 seine Konfigurationsdatenbank, z.B. die Datenbank 132, 134, zu initialisieren.
Wiederum unter Bezug auf 4 umfasst das zentrale Management-Submodul 306 ebenfalls eine globale Monitor-Benutzerschnittstelle 402 und ein Datenerfassungsprogramm 412, die jeweils den Zustand und den Status aller Policy-Enforcer anzeigen und erfassen, die vom Policy-Server 122 verwaltet werden. Das Datenerfassungsprogramm 412 erhält die Zustands- und Statusinformationen von allen Up-and-Running-Policy-Enforcern, die es verwaltet, und überträgt die relevanten Informationen an die globale Monitor-Benutzerschnittstelle. Ein Zustands-Agent, der als Deamon in allen Policy-Enforcern läuft, die regelmäßig überwacht werden, erfasst die Daten des Geräts und analysiert dessen Status. Die erfassten Daten werden an den Policy-Server 122 übermittelt, wenn diese vom Datenerfassungsprogramm 412 abgerufen werden.
7 ist eine Bildschirmdarstellung einer beispielhaften globalen Monitor-Benutzerschnittstelle 402, die verschiedene Typen von Zustands- und Statusinformationen anzeigt. Solche Informationen können sich auf den Zustand der Einrichtung, wie Systembelastung 712 und Netz-Benutzungsinformationen 714 beziehen. Die Informationen können sich auch auf aktuelle Alarmmeldungen 716 für die Einrichtung, einschließlich Alarmname, Typ, Beschreibung und Ähnliches beziehen. Die Informationen können sich außerdem auf aktuelle VPN-Verbindungen 718, einschließlich Verbindungstyp, Quelle/Ziel, Dauer und VPN-Verkehrsvolumen beziehen.
Erneut unter Bezug auf 3 ermöglicht das Policymanagement-Submodul 308 das Policymanagement der Policy-Enforcer 124, 126. Wie oben beschrieben, sind alle Funktionen für das Policy-Management in Form von Ressourcenobjekten implementiert, die in den Policy-Datenbanken 130, 132, 134, gespeichert sind, einschließlich Nutzern, Einrichtungen, Hosts, Diensten und Zeit. Vorzugsweise sind alle Ressourcen den Standard-Policy-Einstellungen, die vom Administrator während des Installationsprozesses ausgewählt werden, zugeordnet. Der Netzadministrator kann sich die Policies zentral über eine graphische Benutzerschnittstelleq, die von dem Policy-Management-Submodul 308 bereit gestellt wird, anzeigen lassen, weitere hinzufügen oder modifizieren. Dies ermöglicht ein zentrales Policy-Managementmodell, wobei dem Administrator der Eindruck vermittelt wird, dass ein einzelner logischer Server die Firewall, das Bandbreitenmanagement und die VPN-Dienste für das gesamte Unternehmen bereitstellt. Die Tatsache, dass die Policy über einzelne Policy-Enforcer an verschiedenen Standorten durchgesetzt wird, ist für den Administrator transparent.
8 ist eine beispielhafte graphische Benutzerschnittstelle, die von dem Policy-Management-Submodul 308 bereitgestellt wird. Die Schnittstelle umfasst eine Ressourcenpalette 718, die eine Liste der Ressourcenregister umfasst, einschließlich einem Nutzerregister 718a, einem Geräteregister 718b, einem Hostregister 718c, einem Diensteregister 718d und einem Zeitregister 718e. Die Ressourcenpalette bietet dem Administrator die Möglichkeit, Ressourcendefinitionen über eine einzelne Konsole hinzuzufügen und zu ändern.
Nach der Auswahl des Benutzerregisters 718a erfolgt die Anzeige der für das System definierten Nutzergruppen 722. Der Gruppe können neue Nutzer hinzugefügt werden, indem eine bestimmte Gruppe ausgewählt wird und die verschiedenen Nutzerattribute wie z.B. Login-Name, vollständiger Name, Policy-Enforcer, dem der Nutzer zugeordnet ist, Berechtigungsschema, Passwort und Ähnliches definiert werden.
Nach der Auswahl der Geräteregisterkarte 718b werden verschiedene Symbole zur Geräteverwaltung zur Verwaltung des Policy-Servers 122 und der Policy-Enforcer 124, 126, angezeigt, wie in 9 dargestellt. Ein Symbol für die Policy-Server-Systemeinstellungen 750 bietet dem Netzadministrator die Möglichkeit, Systemeinstellungen wie LAN oder WAN/DMS-IP-Adressen des Policy-Servers 122 anzuzeigen und zu ändern. Ein Symbol für die Policy-Server-Archivoptionen 752 ermöglicht die Spezifikation von Berichten oder anderen Datenbank-Archivoptionen für den Policy-Server 122. Ein Symbol zur globalen URL-Blockierung 754 bietet dem Administrator die Möglichkeit, eine Liste von nicht zugelassenen Internet-Seiten 116 zu erstellen, die von allen Policy-Enforcern 124, 126, des Systems blockiert werden sollen. In gleicher Weise ermöglicht das Symbol für eine globale Spam-Liste 756 dem Administrator, eine Liste aller E-Mail-Adressen von Spammern 118 zu erstellen, die von allen Policy-Enforcern blockiert werden sollen.
Der Administrator kann die Informationen über alle Policy-Enforcer 124, 126, anzeigen, indem er das Symbol 758 auswählt. Informationen über einen speziellen Policy-Enforcer können durch die Auswahl eines speziellen Policy-Enforcers 760 in einer bestimmten Gerätegruppe 761 angezeigt werden. Solche Informationen umfassen Informationen über die Geräteeinstellungen 762, Informationen über URL-Blockierungen 764, Informationen über die Spam-Liste 766 und ähnliche Informationen, die die für ausgewählten Policy-Enforcer spezifisch sind. So erfolgt beispielsweise nach der Auswahl des Symbols für die URL-Blockierinformationen 764 des Policy-Enforcers die Anzeige der verschiedenen URL-Kategorien 768, die der Netzadministrator für die Blockierung durch den gewählten Policy-Enforcer auswählen kann.
Nach der Auswahl des Hostregisters 718c erfolgt die Anzeige verschiedener Hosts (Netze) des Systems, wie in 10 dargestellt. Ein Host ist auf der Basis seines physischen Standorts organisiert und zudem einem bestimmten Policy-Enforcer 124, 126, zugeordnet. Hosts sind verschiedenen Attributen zugeordnet, einschließlich eines eindeutigen Namens 770, einer IP-Adresse im Netz 772 und einer Subnet-Maske 774. Außerdem kann der Netzadministrator festlegen, ob es sich bei dem Host um einen externen Host 776 handelt, der zu einem Netz gehört, das nicht vom Policy-Server 122 verwaltet wird. Falls es sich um einen externen Host handelt, spezifiziert der Administrator eine IP-Adresse 778 der externen Einrichtung, zu der der Host gehört. Ein Einrichtungsfeld 780 bietet dem Administrator die Möglichkeit, den Namen des Policy-Enforcers einzugeben, zu dem der Host gehört. Jeder Host ist außerdem einer bestimmten Gruppe 782 zugeordnet, die vom Administrator festgelegt wird.
Nach der Auswahl des Diensteregisters 718d erfolgt die Anzeige verschiedener Dienstegruppen, die vom Policy-Server 122 unterstützt werden, wie in 11 dargestellt. Solche Dienstegruppen umfassen beispielsweise Multimedia-Streaming/-Konferenzen, die Abfrage von Informationen, Sicherheit und Berechtigungen, E-Mail-Anwendungen, Routing-Anwendungen, Datenbank-Anwendungen, Standard-Kommunikationsprotokolle und Ähnliches. Falls gewünscht, können die Nutzer auch neue Dienstegruppen hinzufügen.
Jedem Dienst sind ein Name 784, eine Beschreibung 786 und ein Diensttyp 788 (z.B. HTTP, HTTPS, FTP, TELNET, SMTP, Real Networks oder Ähnliches) zugeordnet. Außerdem ist jeder Dienst einer Dienstegruppe 790 zugeordnet. Auf der Basis des Diensttyps können für den Dienst auch zusätzliche Informationen spezifiziert werden. Für einen HTTP-Dienst kann der Administrator beispielsweise angeben, ob die URL-Blockierung 792 aktiviert werden soll.
Nach der Auswahl des Zeitregisters 718e erfolgt die Anzeige verschiedener Zeitgruppen-Symbole 794, die den Zeitbereich abdecken, der in den Firewall-Policies verwendet werden soll, wie in 12 dargestellt. Die Auswahl des Symbols einer Arbeitszeitgruppe bietet dem Netzadministrator beispielsweise die Möglichkeit, Tage und Zeiten einzugeben, die als Arbeitstage und -zeiten eingestellt werden sollen.
Wiederum unter Bezug auf 8 umfasst die Schnittstelle außerdem ein Policy-Canvas 720, einschließlich einer Liste der Policies, die im System verfügbar sind. Eine Policy-Definition ist vorzugsweise eine Zuordnung eines Ressourcensatzes, der von der Ressourcenpalette 718 gezogen und im Policy-Canvas 720 abgelegt werden kann.
Nach der Auswahl eines Firewall-Registers 720a erfolgt die Anzeige aller Firewall-Policies, die für eine bestimmte Policy-Domäne spezifiziert wurden, einschließlich eines oder mehrerer Policy-Enforcer. Der Netzadministrator entscheidet während der Voranmeldung des Policy-Enforcers, zu welcher Domäne der Policy-Enforcer gehören soll. Die Schnittstelle bietet dem Administrator die Möglichkeit, verschiedene Policies vom Policy-Server 122 anzuzeigen, hinzuzufügen und zu ändern und die Änderungen an den Policy-Enforcern 124, 126, durchzuführen, ohne dass diese Änderungen einzeln an jedem Policy-Enforcer durchgeführt werden müssen.
Gemäß einer Ausführungsvariante der Erfindung umfasst jede Firewall-Policy ein Policy-Identifizierungsattribut (ID) 724 zur Identifizierung einer bestimmten Policy-Regel in der Liste der Policies. Ein Nummernattribut 726 für die Policy-Regel gibt die Reihenfolge an, in der die Policy angewendet werden soll. Zu diesem Zweck ruft der Policy-Enforcer 124, 126, für das lokale Netz nacheinander jeweils eine Regel ab, vergleicht diese mit dem Netzwerkverkehr und wendet vorzugsweise die erste Regel an, die dem Netzwerkverkehr entspricht.
Jede Firewall-Policy enthält außerdem ein Beschreibungsattribut 728 zur Beschreibung der Firewall-Policy, die umgesetzt werden soll. Die Beschreibung kann beispielsweise anzeigen, dass die Policy Spam-Blockierung, URL-Blockierung, VPN-Keymanagement und Ähnliches ermöglicht. Ein Aktionsflaggen-Attribut 730 zeigt an, ob der Datenverkehr für die angezeigte Policy zugelassen oder abgelehnt wird. Ein aktives Kennzeichenattribut 732 zeigt an, ob die Policy aktiviert oder deaktiviert wurde. Auf diese Weise kann der Netzadministrator eine Policy erstellen und sie zu einem späteren Zeitpunkt aktivieren. Eine deaktivierte Policy hat vorzugsweise keine Auswirkungen auf den Netzwerkverkehr.
Jede Firewall-Policy umfasst außerdem ein Nutzerattribut 734, ein Quellattribut 736, ein Dienstattribut 738, ein Zielattribut (nicht abgebildet) und ein Zeitattribut (nicht abgebildet). Jedes dieser Attribute wird vorzugsweise von einem Gruppennamen oder einem Ressourcennamen dargestellt. Der Name fungiert als Pointer für eine Eingabe im Gruppenwurzelobjekt 202 oder dem Ressourcenwurzelobjekt der LDAP-Datenbank 130, 132 oder 134.
Das Nutzerattribut 734 gibt vorzugsweise die Nutzergruppen und Nutzer an, die für die Policy ausgewählt werden können. Das Quellattribut 736 gibt den Ursprungspunkt im Netzwerkverkehr an, der dem Nutzer zugeordnet ist. Das Dienstattribut 738 gibt die Dienste an, die von der Policy freigegeben oder gesperrt werden. Das Zielattribut gibt ein spezifisches LAN-, WAN- oder DMS-Segment oder spezifische Hosts an, in denen die spezifizierten Dienste zugelassen oder gesperrt sind. Um auf einem E-Mail-Server SMTP-POP-Dienste zu konfigurieren, kann der Host die IP-Adresse darstellen, auf der der E-Mail-Server läuft, und die spezifizierten Dienste sind SMTP. Das Zeitattribut gibt einen Zeitschlitz an, in dem die Policy wirksam ist.
Neben den oben Genannten umfasst jede Firewall-Policy außerdem ein Authentifikationsattribut (nicht abgebildet), das das Authentifikationsschema für die Policy (z.B. ohne, LDAP, SecurID, RADIUS, WinNT oder alle) angibt.
14 ist eine Bildschirmdarstellung einer beispielhaften graphischen Benutzerschnittstelle zum Hinzufügen einer neuen Firewall-Policy zur Policy-Domäne nach Betätigung der Schaltfläche „Hinzufügen" 725. Die bestehenden Firewall-Policies können anhand der Betätigung der Schaltfläche „Ändern" 727 bzw. „Löschen" 729 geändert oder gelöscht werden.
Wie in 14 dargestellt, kann eine neue Firewall-Policy definiert werden, indem die Beschreibung der Policy einfach im Beschreibungsbereich 728a hinzugefügt wird, indem die Aktion, die auf den entsprechenden Netzwerkverkehr angewendet werden soll, in einem Aktionsfeld 730a ausgewählt wird und im aktiven Bereich 732a angegeben wird, ob die Policy aktiviert oder deaktiviert werden soll. Des Weiteren legt der Netzadministrator Nutzer, Quelle, Dienste, Ziel und Zeit-Ressourcen im Nutzerbereich 734a, Quellbereich 736a, Dienstebereich 738a, Zielbereich 739a bzw. Zeitbereich 741 fest. Der Netzadministrator wählt in einem Authentifikationsbereich 743 außerdem ein Authentifikationsschema für die Policy. Nach Betätigung der Schaltfläche OK 745 werden die entsprechenden Einträge im LDAP-Baum der Policy Server-Datenbank geändert, um die Eingabe der neuen Policy entsprechend widerzuspiegeln. Die Änderung wird auch an die jeweiligen Policy-Enforcer übermittelt, wie dies im Folgenden detailliert beschrieben wird.
Wiederum unter Bezug auf 8 ermöglicht die Auswahl des Bandbreiten-Registers 720c die Anzeige, das Hinzufügen und die Änderung verschiedener Bandbreiten-Policies, die die Art der Bandbreite bestimmen, die dem Verkehr zugeordnet wird, der durch einen bestimmten Policy-Enforcer fließt. Verschiedene Bandbreiten können für unterschiedliche Nutzer, Hosts und Dienste spezifiziert werden.
Die Auswahl des Verwaltungsregisters 720d ermöglicht die Anzeige, das Hinzufügen und die Änderung verschiedener Verwaltungs-Policies, die dem obersten Netzadministrator die Möglichkeit bieten, die Verwaltungsverantwortung an andere Administratoren zu delegieren. Zu diesem Zweck spezifiziert der oberste Netzadministrator Verwaltungs-Policies, die festlegen, welche Nutzer Zugriff auf welche Funktionen und auf welche Einrichtungen haben. Die Verwaltungs-Policies umfassen vorzugsweise ähnliche Attribute wie die Firewall-Regeln, mit Ausnahme der Spezifikation eines Rollenattributs. Bestimmten Nutzern können in Abhängigkeit von ihrer Rolle zusätzliche Verwaltungsprivilegien gewährt werden.
IV. VIRTUELLES PRIVATES NETZ MIT AUTOMATISCHER AKTUALISIERUNG VON BENUTZERERREICHBARKEITSINFORMATIONEN
Wiederum unter Bezug auf 3 ermöglicht das Managementmodul für die Connectivity mehrerer Standorte 312 die Erstellung von VPNs mit dynamischem Routing, wobei die VPN-Mitgliedslisten automatisch, ohne statische Konfiguration der Mitgliedsinformationen durch den Netzadministrator erstellt werden. Sobald der Administrator daher ein VPN über das LAN eines Policy-Enforcers zu einem anderen konfiguriert, erfahren die Routingprotokolle, wie z.B. RIPv1 oder RIPv2, die auf LAN-Schnittstellen laufen, von den Netzen, die über ihre jeweiligen Schnittstellen erreichbar sind. Diese Netze werden dann zu Mitgliedern des VPN und die Policy-Enforcer 124, 126, auf einer Seite des VPN erstellen Mitgliedstabellen, indem sie die bekannten Strecken verwenden. Die Mitgliedsinformationen werden vorzugsweise über die LDAP-Datenbanken 132, 134, zwischen Policy-Enforcern 124, 126, ausgetauscht. Auf diese Weise ermöglicht der kombinierte Einsatz von Routing-Protokollen und LDAP die Erstellung von VPNs, deren Mitgliedslisten dynamisch kompiliert werden.
Wiederum in Bezug auf 8 konfiguriert der Netzadministrator VPN-Policies für die Connectivity mehrerer Standorte unter Verwendung der Ressourcenpalette 718 und des Policy-Canvas 720. Nach der Auswahl des VPN-Registers 720b im Policy-Canvas 720 erfolgt die Anzeige einer Auswahl an VPN-Clouds 270, die bereits für das System konfiguriert wurden, wie in 13 dargestellt. Wie oben beschrieben, ist eine VPN-Cloud ein einzelnes VPN oder eine Gruppe von VPNs, für die eine Sicherheitspolicy definiert werden kann. Jede VPN-Cloud umfasst eine Liste der Standorte eines Standortknotens 234 sowie der Nutzer eines Nutzerknotens 236, die miteinander kommunizieren können. Ein Standort ist ein Satz aus Hosts, die physisch hinter einem der Policy-Enforcer 124, 126, angeordnet sind. Die Policy-Enforcer für die Standorte fungieren vorzugsweise als VPN-Tunnelendpunkte, sobald die Hosts der Standorte beginnen, miteinander zu kommunizieren.
Die Nutzer in der VPN-Cloud sind die Nutzer, die Zugang zu den Standorten 234 zugeordneten Hosts haben. Die Nutzer haben als VPN-Clients auf die Hosts Zugriff, indem sie die VPN Client-Software nutzen, die auf jedem Nutzer-PC installiert ist, wie im Folgenden detailliert beschrieben wird.
Jede VPN-Cloud 270 umfasst außerdem einen Firewall-Regelknoten 276, einschließlich Firewall-Regeln, die auf alle Verbindungen in der Cloud Anwendung finden. Diese Regeln bestimmen unter anderem die VPN-Zugangsberechtigungen, die Sicherheitsfunktionen, wie z.B. das Verschlüsselungsniveau und die Authentifikation, die für die Connectivity auf Netzebene eingesetzt wird.
Die von den VPN-Clouds bereitgestellte hierarchische Organisation bietet dem Netzadministrator somit die Möglichkeit, vollständig vernetzte VPNs zu erstellen, wobei jeder Standort innerhalb einer VPN-Cloud über die vollständige Connectivity mit allen anderen Standorten verfügt. Der Netzadministrator braucht nicht mehr jede mögliche Verbindung innerhalb des VPN manuell zu konfigurieren, er braucht nur noch eine VPN-Cloud zu erstellen und die Standorte, Nutzer und Regeln spezifizieren, die dem VPN zugeordnet werden sollen. Jede Verbindung wird dann auf der Basis der für die VPN-Cloud spezifizierten Konfiguration hergestellt. Die hierarchische Organisation erleichtert somit die Einrichtung eines VPN mit einer großen Anzahl an Standorten.
Der Netzadministrator fügt eine neue VPN-Cloud vorzugsweise hinzu, indem er die Schaltfläche „Hinzufügen" 280 betätigt. Daraufhin erstellt der Policy-Server 122 automatisch den Standortknoten 272, den Nutzerknoten 274 und den Regelknoten 276 für die VPN-Cloud. Der Administrator spezifiziert dann die Standorte und Nutzer im VPN.
Gemäß einer Ausführungsvariante der Erfindung umfasst der Regelknoten 276 anfangs eine VPN-Standardregel 278 entsprechend den Policy-Einstellungen, die der Netzadministrator während der Einrichtung des Policy-Servers 122 ausgewählt hat. Die VPN-Standardregel 278 ermöglicht uneingeschränkten Zugang zu den Hosts im VPN.
Der Administrator kann die Zugangskontrolle innerhalb der VPN-Cloud implementieren, indem er die Standardregel 278 löscht und spezifische Firewall-Regeln für das VPN eingibt. Solche Firewall-Regeln bieten dem Administrator die Möglichkeit, detaillierte Zugangskontrolle für den Verkehr innerhalb des VPN zu gewährleisten, und zwar im Rahmen des von einem solchen VPN gebotenen verschlüsselten Zugangs. Die Firewall-Regeln werden auf das Klartext-Paket angewendet, nachdem es entschlüsselt wurde, bzw. bevor es verschlüsselt wird.
Gemäß einer Ausführungsvariante der Erfindung wählt der Administrator die Standardregel 278 aus, um solche Änderungen an der Standardregel vorzunehmen. Nach der Auswahl der Standardregel wird eine graphische Benutzerschnittstelle aufgerufen, ähnlich der in 8 dargestellten. Der Netzadministrator definiert detaillierte Zugangsregeln für das VPN, indem er die für das VPN geltenden Firewall-Regeln definiert. Die Parameter in diesen Firewall-Regeln sind vorzugsweise identisch mit den allgemeinen Firewall-Regeln, die in 8 dargestellt sind.
Sobald eine VPN-Cloud konfiguriert wurde, werden von den Policy-Enforcern 124, 126, im Netz dynamisch VPN-Mitgliedsinformationen erstellt. Zu diesem Zweck umfasst jeder VPN-Standort ein Register, in dem die diesem Standort zugeordneten Hosts identifiziert werden. In Laufzeit ordnen die Policy-Enforcer 124, 126, des jeweiligen Standortes dem Register IP-Adressen zu, indem sie die Hosts an jedem Standort identifizieren. Auf diese Weise können die IP-Adressen dynamisch ermittelt werden, ohne dass eine statische Konfiguration der IP-Adressen erforderlich ist.
Nach der Erstellung der Mitgliedstabellen werden Änderungen in den Routing-Informationen erfasst und den Policy-Enforcern der Mitglieder anhand eines Publish-Subcribe-Verfahrens gemeldet. Die tatsächlichen Änderungen werden von dem Policy-Enforcer abgerufen, indem er die LDAP-Datenbank des jeweiligen Netzes abfragt, das den geänderten Routing-Informationen entspricht.
15 ist ein schematisches Blockschaltbild der Policy-Enforcer 124, 126, an den entgegengesetzten Enden eines VPN-Tunnels, die ihre jeweiligen Routing-Informationen aktualisieren. Wie in 15 dargestellt, umfasst jeder Policy-Enforcer 124, 126, ein Gate-Modul 252, 261, das als Daemon konfiguriert ist, um ein oder mehrere Routingprotokolle zum Austausch von Strecken im Netz laufen zu lassen. Solche Routingprotokolle können RIPv1, RIPv2, OSPF und Ähnliche umfassen.
Wenn ein Netzadministrator dem mit dem Policy Enforcer 124 verbundenen lokalen Netz 102 eine neue Strecke hinzufügen möchte, meldet der Administrator die neue Strecke in Schritt 241 im Gate-Modul 252 des Policy-Enforcers 124 an. Dies erfolgt typischerweise anhand der Konfiguration eines Downstreams im Policy-Enforcer für ein zusätzliches Netz. Diese Information wird dann durch Standard-Routingprotokolle an das Gate-Modul 252 des Policy-Enforcers 124 weitergeleitet. Der Policy-Server 122 kann die neue Strecke beispielsweise dem Policy-Enforcer 124 bekannt geben, dem die neue Strecke zugeordnet werden soll. Die Strecke kann beispielsweise anhand einer LDAP-Anweisung wie z.B. „LAN_Group@PR1" spezifiziert werden, die eine neue Strecke zwischen dem Policy-Enforcer PR1 und einem LAN mit der Bezeichnung LAN_Group festlegt. In Schritt 242 speichert das Gate-Modul 252 die neue Strecke in einem Kernel 253 des Policy-Enforcers, einschließlich eines VPN-Treibers 254, so dass der Policy-Enforcer die entsprechenden Meldungen über die neue Strecke richtig weiterleiten kann. Außerdem schreibt das Gate-Modul 252 die neue Strecke in Schritt 243 in seine LDAP-Datenbank 132.
Das Gate-Modul 252 übermittelt den Namen der neuen Strecke in Schritt 244 an einen DN-Monitor (Distinguished Name Monitor)-Daemon 255, der entsprechend konfiguriert ist, um die Aktualisierungen in der LDAP-Datenbank 132 zu überwachen. Der DN-Monitor wiederum informiert in Schritt 245a und 245b einen VPN-Daemon 256 und eine PDP-Maschine (Policy Deployment Point) 257 über die Änderung in der LDAP-Datenbank 132. Die PDP-Maschine aktualisiert dann die Module, die die Policies durchsetzen, mit der Änderung.
In Schritt 246 verwendet der VPN-Daemon 256 den Streckennamen, um auf die LDAP-Datenbank 132 zuzugreifen, um die vollständigen Streckeninformationen, eine Liste aller VPNs, zu der die neue Strecke gehört, und eine Liste aller anderen Policy-Router, die mit diesen VPNs verbunden sind, zu erhalten. In Schritt 247 übermittelt der VPN-Daemon 256 den neuen Streckennamen an alle anderen Policy-Router.
Wenn der Policy-Router 126 einen neuen Streckennamen vom Policy-Router 124 erhält, greift sein Netzwerk-Daemon 258 in Schritt 248 auf die LDAP-Datenbank 132 im Sende-Policy-Router 124 zu, um die vollständigen neuen Streckeninformationen zu erhalten. Wenn die neue Strecke zu mehr als einem VPN gehört und für die verschiedenen VPNs verschiedene Parameter aufweist, ordnen die Router in den verschiedenen VPNs die verschiedenen Informationen den jeweiligen VPNs zu.
In Schritt 249 schreibt der Netzwerk-Daemon 258 die empfangenen, neuen Streckeninformationen in seine eigene LDAP-Datenbank 134 und leitet sie an sein eigenes DN-Monitor-Modul weiter. Wie im Sende-Policy-Router 124 übermittelt das DN-Monitor-Modul 259 im Empfangs-Policy-Router 126 die neuen Streckeninformationen an seine PDP-Maschine 260 zur Aktualisierung seines Kernels 265 mit den aktuellen Änderungen.
Obwohl 15 in Bezug auf die Erweiterung eines Policy-Enforcers und der ihm zugeordneten VPNs um eine neue Strecke beschrieben wurde, ist es für den Fachmann sicherlich offensichtlich, dass die im Wesentlichen gleichen Techniken auch zum Löschen einer Strecke (wenn beispielsweise eine Netzwerkkomponente funktionsunfähig oder kommunikationsunfähig wird) oder zur Änderung einer Strecke (der Policy-Router kann erkennen, wenn eine Strecke bereits in einer anderen Form existiert und diese einfach überschreiben) eingesetzt werden können. Auf diese Weise kann das VPN-System, bzw. können die Systeme die Routing-Informationen zwischen ihren Policy-Enforcern bei minimalem Arbeitsaufwand des Systemadministrators dynamisch pflegen.
V. VIRTUELLES PRIVATES NETZ MIT AUTOMATISCHER AKTUALISIERUNG DER CLIENT-ERREICHBARKEITSINFORMATIONEN
Entfernte Nutzer kommunizieren über das öffentliche Internet 108 mit den anderen, hinter den Policy-Enforcern 124, 126, angeordneten Mitgliedern des VPN, nachdem sie ihre entsprechenden Berechtigungsnachweise erbracht haben. Diese entfernten Nutzer haben als VPN-Clients 140 mit Hilfe einer VPN Client-Software Zugang zu den privaten Netzen. Gemäß einer Ausführungsvariante der Erfindung bietet das System dem entfernten Nutzer die Möglichkeit, eine selbstextrahierende Programmdatei herunterzuladen, die nach der Ausführung sowohl die VPN Client-Software als auch die VPN-Erreichbarkeitsinformationen installiert, die für den entfernten Nutzer in dem entfernten Nutzerterminal eindeutig sind.
Jeder Policy-Enforcer 124, 126, beinhaltet vorzugsweise eine Kopie der selbstextrahierenden Programmdatei der VPN Client-Software, einschließlich eines Setup-Programms und der Vorlage für die VPN-Erreichbarkeitskonfiguration. Mit Hilfe des Setup-Programms kann die VPN Client-Software auf dem VPN-Client 140 installiert werden. Beim Herunterladen der selbstextrahierenden Programmdatei wird die Konfigurationsvorlage durch die VPN-Erreichbarkeitsinformationen ersetzt, die spezifisch für den herunterladenden Nutzer sind.
Gemäß einer anderen Ausführungsvariante der Erfindung bietet das System dem VPN-Client 140 die Möglichkeit, eine selbstextrahierende Programmdatei herunterzuladen, die nach der Ausführung lediglich die VPN-Erreichbarkeitsinformationen installiert, die für den Nutzer eindeutig sind. Gemäß dieser Ausführungsvariante ist die VPN Client-Software bereits auf dem VPN-Client 140 installiert. In diesem Szenario ermöglicht das Setup-Programm die Installation der Erreichbarkeitsinformationen, die für den herunterladenden Nutzer spezifisch sind, auf den VPN-Client 140.
Gemäß einer dritten Ausführungsvariante der Erfindung bietet das System dem VPN-Client 140 die Möglichkeit, die VPN-Erreichbarkeitsinformationen jedes Mal automatisch herunterzuladen, wenn eine Verbindung zum Policy-Enforcer 124, 126, hergestellt wird. Auf diese Weise sind die VPN-Erreichbarkeitsinformationen für jeden VPN-Client 140 immer auf dem neuesten Stand. Sobald eine VPN-Sitzung hergestellt wird, gilt die Verbindung zwischen dem VPN-Client 140 und dem Policy-Enforcer bereits als sicher. Der VPN-Client führt vorzugsweise eine CGI-Abfrage (Common Gateway Interface) bei einem Web-Server durch, der auf dem Policy-Enforcer läuft, und lädt die aktuellen VPN-Erreichbarkeitsinformationen von der entsprechenden LDAP-Datenbank herunter.
16 ist ein Blockdiagramm der Komponenten in einer selbstextrahierenden Programmdatei 290 gemäß einer Ausführungsvariante der Erfindung. Die selbstextrahierende Programmdatei 290 kann mit Hilfe handelsüblicher Tools, wie z.B. INSTALLSHIELD EXEBUILDER von der InstallShield Software Corporation in Schaumburg, Illinois, erstellt werden.
Die selbstextrahierende Programmdatei 290 umfasst vorzugsweise eine ausführbare Setup-Datei 292 zur Installation der VPN Client-Software und/oder der VPN-Konfigurationsinformationen. Die Setup-Datei 292 bildet vorzugsweise den statischen Anteil 298 der selbstextrahierenden Programmdatei, da sich diese Informationen nicht in Abhängigkeit von dem herunterladenden VPN-Client ändern. Die selbstextrahierende Programmdatei 290 umfasst außerdem VPN- Konfigurationsdatei-Vorlagen für die VPN-Erreichbarkeitsinformationen 294 und gemeinsame Schlüsselinformationen 296 des VPN-Clients. Die VPN-Erreichbarkeitsinformationen 294 und die gemeinsamen Schlüsselinformationen 296 des VPN-Clients bilden vorzugsweise den dynamischen Anteil 299 der selbstextrahierenden Programmdatei 290, da sich diese Informationen in Abhängigkeit von dem herunterladenden VPN-Client ändern. Die selbstextrahierende Programmdatei 290 wird dann als Vorlagedatei in den Policy-Enforcern 124, 126, gespeichert und kann anschließend von den entfernten Nutzern heruntergeladen werden.
17 ist ein Blockdiagramm zum Herunterladen der selbstextrahierenden Programmdatei 290 aus 16 gemäß einer Ausführungsvariante der Erfindung. In Schritt 320 erstellt ein neuer VPN-Client 140 zunächst eine sichere Verbindungssitzung mit dem Policy-Enforcer 124, 126, um die selbstextrahierende Programmdatei 290 herunterzuladen. Dies erfolgt vorzugsweise mittels einer HTTPS-Protokollsitzung im Webbrowser des VPN-Clients oder Ähnlichem. In Schritt 322 und 324 führen die Policy-Enforcer mit dem VPN-Client ein Authentifikationsverfahren durch, bei dem der Policy-Enforcer Nutzernamen und Passwort abfragt und der VPN-Client diese Informationen liefert. In Schritt 326 vergleicht der Policy-Enforcer die gelieferten Informationen mit den Einträgen in seiner VPN Client-Datenbank 328. Sind die Informationen korrekt, findet der Policy-Enforcer entsprechende gemeinsame Schlüssel für den Nutzer, und ermittelt in Schritt 330 außerdem die VPN-Erreichbarkeitsinformationen des Client aus einer VPN-Konfigurationsdatenbank 332. Die VPN Client-Datenbank 328 und die VPN-Konfigurationsdatenbank 332 können als Teil einer einzigen LDAP-Datenbank 312, 314, gespeichert sein, die vom Policy-Enforcer 124, 126, verwaltet wird, oder sie können jeweils separate LDAP-Datenbanken darstellen.
In Schritt 334 ersetzt der Policy-Enforcer den dynamischen Anteil 299 der selbstextrahierenden Programmdatei 290 durch die VPN-Erreichbarkeitsinformationen und den gemeinsamen Schlüssel, der für den VPN-Client eindeutig ist. Die neu generierte, selbstextrahierende Programmdatei wird dann in Schritt 336 auf den VPN-Client 140 heruntergeladen. Wenn die Programmdatei läuft, installiert sie entweder die VPN Client-Software und/oder die VPN-Erreichbarkeitsinformationen.
Ähnliche Techniken können auch zum Herunterladen einer neuen und aktualisierten Kopie der VPN-Konfigurationsinformationen auf den VPN-Client eingesetzt werden, und zwar immer, wenn der Client eine Verbindung zum Policy-Enforcer herstellt und einen Sitzungsschlüssel beantragt. Zusätzlich kann der Nutzer die neueste Konfiguration des VPN-Netzes erhalten, indem er diese Informationen explizit beim Policy-Enforcer abfragt. Auf diese Weise muss der VPN-Client nicht jedes Mal, wenn Aktualisierungen an den VPN-Erreichbarkeitsinformationen vorgenommen werden, neu installiert und konfiguriert werden.
VI. INTEGRIERTE POLICY-ENFORCER
Gemäß einer Ausführungsvariante der Erfindung sind die Funktionen der Policy-Enforcer 124, 126, zur Durchsetzung der Policy zur effizienten Implementierung der Hardware aufgeteilt. Für den Fachmann ist es jedoch sicherlich offensichtlich, dass einige oder alle Funktionen in der Software, der Hardware oder verschiedenen Kombinationen davon implementiert werden können.
18 ist ein Blockschaltbild des Policy-Enforcers 124, 126, in dem die Aufteilung der verschiedenen Funktionen gemäß einer Ausführungsvariante der Erfindung dargestellt wird. Der Policy-Enforcer umfasst eine IPSec-Maschine (Internet Protocol Security) 502 zur Durchführung der Sicherheits- und Authentifikationsfunktionen, beispielsweise zur Implementierung von virtuellen privaten Netzen. Eine Datenstrom-Tabelle 506 assembliert die Pakete, die den Policy-Enforcer passieren, zu Datenströmen. Eine Protokollklassifikations-Maschine 508 dekodiert die Protokolle, die bei der Weiterleitung der Pakete verwendet werden. Eine Policy-Maschine setzt die Policies für die Pakete auf der Basis der Policy-Einstellungen durch, die in der Policy-Datenbank 132, 134, gespeichert sind. Ein Paket-Weiterleitungsmodul 504 empfängt Pakete aus dem öffentlichen Internet über den Router 110 und speichert die Pakete zwischen, leitet sie weiter oder löscht sie auf der Basis der durchgesetzten Policies. Ein Bandbreiten-Managementmodul 514 gewährleistet Bandbreiten-Gestaltungsdienste für die Pakete, die auf der Basis der Bandbreiteneinstellungen weitergeleitet werden, die in der Policy-Datenbank 132, 134, gespeichert sind.
In der Praxis wird ein eingehendes Paket mit der Datenstromtabelle 506 verglichen um festzustellen, ob bereits ein passender Eintrag in der Tabelle existiert. Falls nicht, wird ein neuer Eintrag hinzugefügt. Die Datenstromtabelle beinhaltet vorzugsweise ausreichend Anteile des Pakets, um einen Datenstrom eindeutig zu identifizieren. Bei der Durchsetzung von Policies für den Datenverkehr zwischen IP-Ebene drei und IP-Ebene vier kann die Datenstromtabelle beispielsweise Quell-IP, Ziel-IP, Quellanschluss, Zielanschluss und Protokollnummer des eingehenden Pakets speichern.
Die Protokollklassifikations-Maschine 508 nimmt den neuen Datenstrom und erzeugt für den Strom eine detaillierte Protokolldekodierung. Anschließend werden die Policy-Regeln, die auf den Datenstrom angewendet werden sollen, in der Policy-Maschine 510 abgefragt. Basierend auf den Policy-Regeln, die von der Policy-Maschine 510 zurückgesandt werden, verarbeitet das Paket-Weiterleitungsmodul 504, die IPSec-Maschine 502 und/oder das Bandbreiten-Managementmodul 514 die Datenströme dementsprechend. Die Verarbeitung kann rekursiv sein, bis alle Aktionen an den Paketen im Datenstrom vorgenommen wurden, die in den für sie geltenden Policy-Regeln spezifiziert sind.
Der Policy-Enforcer umfasst außerdem ein Statistikmodul 512 zur Erstellung von Statistiken für die Pakete, die über das lokale Netz weitergeleitet werden, sowie für andere Status- und Ressourcennutzungsinformationen, und speichert diese in Protokollen und Archiven zum Versand an den Policy-Server 122. Gemäß einer Ausführungsvariante der Erfindung führt das Statistikmodul 512 laufend Bytezählungen an den Paketen durch, die durch das Netz 102, 104, weitergeleitet werden. Diese Bytezählungen können automatisch nach Klassen sortiert werden, wobei diese Klassen auf bestimmten Ressourcen (z.B. Nutzer, Hosts, Dienste) oder auf den Bytes, die von den Policies blockiert werden, oder auf Ausnahmen basieren, wie beispielsweise Firewall-Policies. Zu diesem Zweck pflegt das Statistikmodul 512 in einem Cache eine Statustabelle, die eine Liste der Ressourcen beinhaltet, die an den einzelnen, von der Firewall freigegebenen Verbindungen beteiligt sind. Bei jedem Paket, das im Rahmen der Verbindung weitergeleitet wird, führt das Statistikmodul eine Paket- und eine Bytezählung für jede der Ressourcen in der Liste durch. Das Statistikmodul 512 leitet die strukturierten Informationen dann an den Policy-Server 122 weiter, der die Informationen direkt in Tabellen einträgt, die nach bestimmten Klassen geordnet sind und regelmäßig gelöscht werden.
19 ist ein detaillierteres Blockschaltbild der Policy-Maschine 510 gemäß einer Ausführungsvariante der Erfindung. Die Policy-Maschine 510 umfasst eine Policy-Abfragetabelle 602, die als Warteschlange für alle Policy-Entscheidungsabfragen fungiert. Zu diesem Zweck wird der Anteil des Pakets, der zu den Informationen passt, die in der Datenstromtabelle 506 gespeichert sind, der Policy-Maschine 510 in Form einer Policy-Abfrage präsentiert. Die Policy-Abfrage wird dann in die Warteschlage der Policy-Abfragetabelle 602 eingestellt.
Eine Ressourcenmaschine 604 pflegt ein aktuelles Mapping der Ressourcen-Gruppennamen in Bezug auf das Mitgliedsmapping. Ein Datenbankpuffer für Policy-Regeln 608 speichert ein aktuelles Policy-Regelset, das von der Policy-Maschine 510 angewendet werden soll. Die in dem Puffer 608 gespeicherten Policy-Regeln liegen vorzugsweise in dem gruppenbasierten Original-Regelspezifikationsformat vor. Der Puffer 608 speichert daher eine für eine Gruppe erstellte Regel in ihrer gruppenbasierten Form, anstelle der Instantiierung einer Regel für jedes Mitglied der Gruppe.
Eine Entscheidungsmaschine 606 umfasst eine Logik zur Bearbeitung der eingehenden Policy-Entscheidungsanfragen in der Policy-Abfragetabelle 602 durch Abgleich mit dem Policy-Regelset im Puffer der Policy-Regeldatenbank 608 auf der Basis der aktuellen Mitgliedsinformationen, die von der Ressourcenmaschine 604 geliefert werden. Die relevante gruppenbasierte Regel, die mit dem Datenverkehr übereinstimmt, wird identifiziert und in der Datenstromtabelle werden Datenbits gesetzt, um die entsprechenden Aktionen umzusetzen. Die Entscheidungsbits stellen daher den Satz an Aktionen dar, die an den Paketen des Datenstroms durchgeführt werden sollen. Alle Pakete, die mit dem Datenstrom übereinstimmen, werden dann auf der Basis dieser Entscheidungsbits verarbeitet. Die Entscheidungsmaschine kann auch eine Zugangskontrollliste (ACL), einschließlich eines Regelsatzes, der den Datenverkehr freigibt/sperrt, einen DiffServ-Standard zur Sicherstellung der Dienstgüte-Qualität für den Datenverkehr und/oder VPN-Implementierungsinformationen festlegen.
20 ist ein detaillierteres Blockschaltbild der Protokoll-Klassifikationsmaschine 508 gemäß einer Ausführungsvariante der Erfindung. Wie in 20 dargestellt, umfasst die Protokoll-Klassifikationsmaschine 508 eine Datenstromeinheit 702, ein Datenstrom-Gleitfenster 704, einen ASN.1-Block 706, eine Protokollklassifkationsstatus-Maschine 708 und eine Protokolldefinitionssignatur-Datenbank 710. Die Datenstromeinheit 702 extrahiert und reassembliert den Datenanteil eines eingehenden Paket-Datenstroms und speichert ihn im Datenstrom-Gleitfenster 704 ab. Das Datenstrom-Gleitfenster folgt vorzugsweise FIFO-Protokollen. Der ASN.1-Decoder dekodiert den Datenstrom, sofern erforderlich, anhand herkömmlicher ASN.1-Codier-/Decodierstandards. Die Protokollklassifikationsstatus-Maschine 708 gleicht dann die vollständig reassemblierten und decodierten Daten mit der Protokolldefinitionssignatur-Datenbank 710 ab. Diese Datenbank 710 umfasst vorzugsweise ein Mapping der Protokollnamen mit den Datenmustern, die im Datenstrom zu finden sind. Das abgeglichene Protokoll wird dann an die Datenstromtabelle 506 zurückgesandt.
Somit bietet die Protokoll-Klassifikationsmaschine 508 eine umfassende Protokoll-Decodierung und Paketklassifikation für Ebene drei bis Ebene sieben, einschließlich der vollständigen Identifikation von dynamischen Datenströmen durch den Einsatz einer dynamisch aktualisierten Signaturdatenbank, die auf der Basis von Skriptprotokolldefinitionen kompiliert wird. Wenn in Zukunft neue Protokolle definiert werden und/oder Nutzer ihre eigenen individuellen Anwendungen mit individuellen Protokollen erstellen, kann es erforderlich werden, der Protokoll-Klassifikationsmaschine eine Erkennung dieser Protokolle hinzuzufügen. Die beschriebene Protokollklassifizierungsmaschinen-Architektur ermöglicht derartige Erweiterungen durch einfaches Hinzufügen der neuen Skriptdefinition des neuen Protokolls zur Protokoll-Klassifikationsmaschine, ohne dabei jedes Mal das Design ändern zu müssen, wenn ein neues Protokoll hinzugefügt wird. Dies gewährleistet den Support von individuellen Protokollen und die zukünftige Erweiterungsfähigkeit von Protokollen.
21 ist ein detaillierteres Blockschaltbild der IPSec-Maschine 502 gemäß einer Ausführungsvariante der Erfindung. Wie in 21 dargestellt, umfasst die IPSec-Maschine 502 eine Pseudo-Zufallszahlengenerator-Funktion (PRNG) 802 zur Erzeugung von Zufallszahlen, die zur Erzeugung von Verschlüsselungscodes mit allgemein bekannten Verfahren verwendet werden. Ein Diffie Hellman-804 sowie ein RSA-Block 812 implementieren die entsprechenden asymmetrischen, öffentlichen Verschlüsselungs-/Entschlüsselungs-/Signaturalgorithmen, die der Fachwelt ebenfalls bekannt sind. Ein IKE-Block 806 kommuniziert mit einer IPSec SA-Tabelle 808 zur Implementierung von ISAKMP/Oakley (IKE)-Standard-Codeaustauschprotokollen. Ein Verschlüsselungs-Umcodierungsblock 814 implementiert die symmetrischen Standard-Verschlüsselungs-/Entschlüsselungsalgorithmen. Ein IPSec-Encapsulation-/Decapsulation-Block 810 führt Standard-Encapsulation-/Decapsulationfunktionen aus. Dementsprechend bietet die IPSec-Maschine 502 eine ausgereifte, auf Standards basierende IKE/IPSec-Implementierung, die öffentliche Codezertifikate unterstützt und die erforderlichen Verschlüsselungs- und Entschlüsselungsfunktionen für die Paketweiterleitung durch die privaten lokalen Netze 102, 104, bietet.
VII. NETZWERK-POLICY-PROTOKOLLE UND STATISTIK-AUFBAU
Wiederum in Bezug auf 3 sammelt das Protokoll-Erfassungs- und Archivierungsmodul 304 die Informationen über den Status und den Einsatz von Ressourcen von den Policy-Enforcern 124, 126, sowie vom Managementmodul 302 und speichert diese in der Archivdatenbank 318 ab. Das Policy-Server-Berichtmodul 316 verwendet die erfassten Protokolle und Archive dann, um Berichte in einem strukturierten Berichtformat zu erstellen.
Gemäß einer Ausführungsvariante der Erfindung pflegt jeder Policy-Enforcer 124, 126, eine Protokolldatei mit den erfassten Informationen über den Datenverkehrsfluss durch die Policy-Enforcer sowie über den Status und den Einsatz der Ressourcen, die dem Policy-Enforcer zugeordnet sind. Alle Protokolldateien entsprechen einem vordefinierten, gemeinsamen Protokollformat, das vorzugsweise für die Erstellung kompakter Protokolle konzipiert ist.
22 ist eine schematische Darstellung eines solchen Protokollformats gemäß einer Ausführungsvariante der Erfindung. Jeder Protokolleintrag umfasst einen Zeitstempel 820 im Format jjjjmmtthhmmss, der das Jahr, den Monat, die Stunde, Minute und Sekunde angibt, an dem der Protokolleintrag erstellt wurde. Ein Dienstfeld 822 gibt den Diensttyp an, der von dem Policy-Enforcer 124, 126, erbracht wird. Solche Dienste sind beispielsweise VPN, FTP, Telnet, HTTP, Paketfilter, Bandbreite und Ähnliches. Jeder Protokolleintrag enthält außerdem Quell-IP-Adresse und -Anschluss 824, die die Quelle angeben, von der ein Paket empfangen wurde, sowie Ziel-IP-Adresse und -Anschluss 826, die das Ziel angeben, an das das Paket übermittelt wurde.
Ein Nutzer-ID-Feld 828 gibt den Nutzer an, der das Paket übermittelt. Die Nutzer-ID kann einem Eintrag in der LDAP-Datenbank 130, 132 oder 134, zugeordnet werden, um weitere Angaben über den Nutzer zu erhalten.
Ein Statusfeld 830 gibt den Status einer Operation an und kann einen Ergebniscode, einen Fehlercode und Ähnliches umfassen. Für einen Paketfilter-Dienst kann das Statusfeld beispielsweise den Ergebniscode „p" beinhalten, wenn das Paket passieren konnte, oder „b", wenn das Paket blockiert wurde.
Ein Operationsfeld 832 enthält Codes für den von dem Dienst gebotenen Operationstyp. Operationen für einen VPN-Dienst können beispielsweise den Versand von Paketen und dem Empfang von Paketen umfassen. Operationen für einen FTP-Dienst können GET- und PUT-Operationen umfassen. Operationen für einen HTTP-Dienst können GET- und POST-Operationen umfassen.
Neben den oben genannten Angaben umfasst jeder Protokolleintrag ein In-Bytes-Feld 832, in dem die Anzahl an Bytes angegeben ist, die der Policy-Enforcer infolge eines Vorgangs erhalten hat, und ein Out-Bytes-Feld 834, in dem die Anzahl an Bytes angegeben ist, die von dem Policy-Enforcer übermittelt wurde. Außerdem ist in einem Dauerfeld 836 die Dauer (z.B. in Sekunden) des Vorgangs angegeben.
Bestimmte Felder können in bestimmten Protokolleinträgen frei gelassen werden, wenn sie für einen bestimmten Dienst nicht zutreffen, beispielsweise bei einem FTP-Download. Liegt kein abgehender Datenverkehr vor, wird das Out-Bytes-Feld freigelassen. Des Weiteren können in Abhängigkeit vom Typ des protokollierten Dienstes zusätzliche Felder eingefügt werden. Bei einem HTTP-Vorgang wird beispielsweise die URL, auf die zugegriffen wird, im Protokolleintrag ebenfalls festgehalten. Die zusätzlichen Felder werden vorzugsweise an das Ende des Standard-Protokollformats angehängt.
Der Fachmann wird sicherlich erkennen, dass das Hinzufügen, Löschen und andere Arten von Änderungen am Protokollformat erfolgen können, solange das Protokollformat für alle Policy-Enforcer gleich ist und zum Ziel hat, kompakte Protokolle zu erzeugen.
Die von den Policy-Enforcern 124, 126 erstellten Protokolldateien werden auf der Basis der Archivoptionen, die vom Policy-Server vorgegeben werden, an den Policy-Server 122 übertragen. Zu diesem Zweck spezifiziert der Netzadministrator eine Maximalgröße für die Protokolle, die von den Policy-Enforcern erstellt werden, durch Auswahl der Policy-Server-Archivoption 752 aus 9. Überschreitet die Protokolldatei die spezifizierte Größe, wird sie an den Policy-Server 122 gesandt. Vorzugsweise werden die Protokolle mindestens einmal täglich an den Policy-Server 122 übermittelt, auch wenn die Maximalgröße nicht überschritten wurde. Die Protokolle können auch lokal im Policy-Enforcer archiviert werden, wenn dies vom Netzadministrator so festgelegt wurde.
Sobald der Policy-Server 122 die Protokolle empfängt, werden diese in der Archivdatenbank 318 gespeichert, vorzugsweise in Form einer SQL-Datenbank. Das Policy-Server-Berichtmodul 316 fragt diese Datenbank ab, um Berichte für jeden Policy-Enforcer 124, 126, zu erstellen. Außerdem können die Protokolle in einem Format exportiert werden, das von handelsüblichen Produkten wie beispielsweise WEBTRENDS, einem Produkt der WebTrends Corporation in Portland, Oregon, interpretiert werden kann.
Die vom Berichtmodul 316 erstellten Berichte beinhalten Nutzungsberichte für die verschiedenen Ressourcen, z.B. für Policy-Enforcer, Nutzer, Dienste, Hosts und VPNs. Diese Berichte können beispielsweise VPN-Übersichten, Bandbreiten-Übersichten, Paketfilterberichte und Ähnliches für jeden Policy-Enforcer umfassen.
Die Berichte weisen vorzugsweise den Einsatz aller Ressourcen über einen bestimmten Zeitraum aus. Anfangs- und Endzeitpunkt für den Bericht können vom Nutzer spezifiziert werden. Der Nutzer kann außerdem die Zeitdimension oder die Ressourcendimension einstellen, um spezifische Zeiten und spezifische Ressourcen anzuzeigen. Bei der Erstellung der Paketfilterberichte kann der Nutzer beispielsweise eine Anfangs- und eine Endzeit, die Quell-IP-Adresse, den Quellanschluss, die Ziel-IP-Adresse und den Zielanschluss angeben. Alle Pakete, die diese Kriterien erfüllen, wenn dann aus der Archivdatenbank 318 abgerufen und in einem Paketbericht angezeigt.
VIII. VERFAHREN ZUR SELEKTIVEN LDAP-DATENBANKSYNCHRONISIERUNG
Gemäß einer Ausführungsvariante der Erfindung handelt es sich bei den Datenbanken 130, 132, 134, im einheitlichen Policy-Managementsystem aus 1 um LDAP-Datenbanken, die Policy- Managementinformationen speichern, einschließlich der Policies für Firewall, VPNs, Bandbreite, Verwaltung, Nutzeraufzeichnungen, Netzaufzeichnungen, Dienste und Ähnliches. Wie oben beschrieben basiert das LDAP-Verzeichnisservice-Modell auf den Einträgen, wobei jeder Eintrag eine Ansammlung von Attributen darstellt. Die Einträge werden in einer Baumstruktur angeordnet, die sich nach dem geographischen und organisatorischen Aufbau richtet. Die Einträge werden entsprechend ihrer Position in der Hierarchie mit einem eindeutigen Namen (DN) gekennzeichnet.
Der Policy-Server 122 speichert die Policy-Managementinformationen für alle Policy-Enforcer vorzugsweise in der Policy-Serverdatenbank 130. Diese Informationen sind in der Datenbank 130 in Form eines oder mehrerer DNs mit den entsprechenden Attributen organisiert. Die entsprechenden Anteile der Policy-Serverdatenbank werden dann in die Datenbanken der Policy-Enforcer 132, 134, kopiert.
23 ist ein Blockdiagramm einer LDAP-Baumstruktur, die eine LDAP-Wurzel 265 und eine Vielzahl an Zweigen 264, 266, 268, 270, beinhaltet. Gemäß einem Beispiel pflegt der Policy-Server 122 in der Policy-Serverdatenbank 130 Zweige, 264 und 266, mit Policy-Managementinformationen für alle Policy-Enforcer 124, 126. Jeder Policy-Enforcer 124, 126, pflegt außerdem Anteile der Zweige 264 und/oder 266 in den jeweiligen Policy-Enforcer-Datenbanken 132, 134, als Unter-Verzweigungen der Policy-Server-Datenbank 130. Die Anteile der von jedem Policy-Enforcer 124, 126, gepflegten Zweige beziehen sich vorzugsweise auf Konfigurationsinformationen für diesen Policy-Enforcer sowie auf einige Zusatzinformationen über die anderen Policy-Enforcer. Diese Zusatzinformationen werden verwendet, um mit den anderen Policy-Enforcern zu kommunizieren.
Der Policy-Server 122 kann außerdem den Zweig 268 mit Speicherinformationen pflegen, die nur von den Anwendungen verwendet werden, die auf dem Server laufen, und den anderen Policy-Enforcern 124, 126, nicht zur Verfügung stehen. Gleichermaßen können die Policy-Enforcer 124, 126, einen Anteil des Zweigs 268 pflegen, der Informationen enthält, die nur von den Anwendungen auf den Policy- Enforcern genutzt werden und anderen nicht zur Verfügung stehen. Typischerweise werden die in Zweig 268 gespeicherten Daten dynamisch generiert und von den Anwendungen genutzt, die auf dem entsprechenden Server oder Agenten laufen.
Zweig 270 wird vorzugsweise nur für die Policy-Serverdatenbank 130 in die LDAP-Baumstruktur aufgenommen und speichert die protokollierten Policy-Managementänderungen, die an die Policy-Enforcer 124, 126 weitergeleitet werden können. Solche Änderungen umfassen beispielsweise das Hinzufügen, Löschen oder Ändern eines Nutzers für eine Einrichtung, VPN-Cloud, Bandbreiten-Policy oder Firewall-Policy, die vom Netzadministrator über die verschiedenen, oben beschriebenen graphischen Benutzerschnittstellen vorgenommen werden. Solche Änderungen resultieren in einer Aktualisierung der Policy-Datenbank 130, in der der entsprechende DN der LDAP-Baumstruktur hinzugefügt, gelöscht oder geändert wird. Der Policy-Server 122 erstellt außerdem ein Protokoll der Änderungen und speichert diese in Zweig 270 zur späteren Verteilung an die Policy-Enforcer 124, 126.
24 ist ein detaillierteres Blockdiagramm von Zweig 270 der LDAP-Baumstruktur aus 23. Die LDAP-Wurzel 265 umfasst einen ApplyLog-Eintrag 270a, der wiederum einen Nutzerprotokoll-Eintrag 270b und einen Geräteprotokoll-Eintrag 270c umfasst. Die Nutzerprotokoll-Einträge umfassen spezifische Adminstratorprotokoll-Einträge, die mit spezifischen DNs 270d gekennzeichnet sind, die die Änderungen widerspiegeln, die von den jeweiligen Administratoren vorgenommen wurden. Der Geräteprotokoll-Eintrag 270c umfasst spezifische Geräteprotokoll-Einträge, die mit spezifischen DNs 270e gekennzeichnet sind, die die Änderungen widerspiegeln, die an die jeweiligen Policy-Enforcer 124, 126, verteilt werden sollen. Vorzugsweise werden die von den Administratoren vorgenommenen Änderungen nach Betätigung der Schaltfläche „Apply", wie beispielsweise der in 6 dargestellten Schaltfläche „Apply" 417, an die Policy-Enforcer 124, 126, weitergeleitet.
25 ist ein Ablaufdiagramm für die Protokollierung und Weiterleitung der LDAP-Änderungen an die Policy-Enforcer gemäß einer Ausführungsvariante der Erfindung. In Schritt 420 nimmt ein bestimmter Netzadministrator eine Änderung an einer Policy-Einstellung vor. Gemäß einem Beispiel handelt es sich bei dem Administrator um den Administrator „adm", der in der Domäne „domain1" arbeitet, und bei der Änderung um das Hinzufügen eines neuen Nutzers für eine Einrichtung.
In Schritt 422 wird die vom Administrator vorgenommene Änderung in der Policy-Server-Datenbank 130 umgesetzt. Zu diesem Zweck werden die Zweige 264 und 266 der LDAP-Baumstruktur entsprechend geändert, um die Änderung der Policy-Einstellung widerzuspiegeln. Zusätzlich erstellt der Policy-Server 122 in Schritt 424 ein Protokoll der Änderungen für den Administrator zur späteren Verarbeitung und zum Versand an den entsprechenden Policy-Agenten. In Schritt 426 aktualisiert der Policy-Server 122 das Protokoll des Administrators 270d, um die Änderung wiederzuspiegeln. In dem oben angeführten Beispiel und gemäß der Darstellung in 24 wird das erstellte Protokoll „A_L1" genannt und der Policy-Server 122 aktualisiert DN 270d für „adm" in „domain1", um ein „Apply"-Attribut 270f zu erstellen, das den Wert „A_L1" 270g aufweist. Andere, vom Administrator vorgenommene Änderungen werden in separaten Protokollen (z.B. „A_L2", „A_L3") erfasst und an den bestehenden Wert des Apply-Attributs im Administrator-Protokoll DN 270d angehängt.
In Schritt 428 prüft der Policy-Server 122, ob die vom Administrator vorgenommenen Änderungen an die entsprechenden Policy-Enforcer 124, 126, weitergeleitet werden sollen. Wie oben erläutert, werden die Änderungen vorzugsweise nach Betätigung der Schaltfläche „Apply" auf der graphischen Benutzerschnittstelle des Administrators weitergeleitet.
Wenn die Schaltfläche „Apply" betätigt wurde, erstellt der Policy-Server in Schritt 430 ein Protokoll für jeden Policy-Enforcer, an den die Änderung übermittelt werden soll. Zu diesem Zweck erfasst der Policy-Server 122 alle vom Administrator vorgenommenen Änderungen, die in den Werten 270g, 270h des Apply-Attributs 270f des Administrator-Protokolls DN 270d enthalten sind. Diese Änderungen werden für jeden Policy-Enforcer verarbeitet, der zur Domäne des Administrators gehört. Diese Verarbeitung umfasst vorzugsweise das Auslesen der relevanten Änderungen und die entsprechende Änderung der DNs für die LDAP des Policy-Enforcers. Derartige Änderungen können beispielsweise aufgrund von Differenzen in den Baumstrukturen in der Policy-Serverdatenbank 130 und den Policy-Enforcer-Datenbanken 132, 134, erforderlich sein. So kann eine Änderung im Administratorprotokoll beispielsweise eine DN enthalten, die den Domänennamen des Policy-Enforcers angibt. Bei der Anwendung dieser Änderung auf den Policy-Enforcer wird der Domänenname in der DN nicht angegeben, da die Baumstruktur des Policy-Enforcers keinen Domänennamen enthält.
Die entsprechend vorgenommenen Änderungen für die LDAP jedes Policy-Enforcers werden dann in einem Geräteprotokoll gespeichert. Die Protokoll-DNs aller Policy-Enforcer 270e werden dann der Änderung entsprechend angepasst und an den jeweiligen Policy-Enforcer übermittelt. Im oben angeführten Beispiel und gemäß der Darstellung in 24 wird das erstellte Geräteprotokoll „PE_L1" genannt, der Policy-Server 122 aktualisiert den DN 270e für den jeweiligen Policy-Enforcer „PE1" in „domain1", um ein „Apply"-Attribut 270i zu erstellen, das den Wert „PE_L1" 270j aufweist.
In Schritt 432 wird das Apply-Attribut 270f für das Administratorprotokoll-DN 270d aus der LDAP-Baumstruktur gelöscht. In Schritt 434 werden die für jeden Policy-Enforcer ausgelesenen Änderungen, die in den Werten 270j und 270k des Apply-Attributs 270i des Policy-Enforcer-Protokoll-DN 270e enthalten sind, an den Policy-Enforcer zur Aktualisierung seiner Datenbank 132, 134, übermittelt. Die Änderungen werden vorzugsweise über den HTTPS-Kanal an die Policy-Enforcer übermittelt.
In Schritt 436 prüft der Policy-Server 122, ob die Aktualisierungen erfolgreich waren. Zu diesem Zweck wartet der Policy-Server 122, bis er eine Bestätigung vom Policy-Enforcer erhält, dass die Aktualisierungen erfolgreich abgeschlossen wurden. Nach einer positiven Antwort des Policy-Enforcers löscht der Policy-Server 122 das Apply-Attribut 270e aus dem Protokoll-DN des Policy- Enforcers 270e. Falls die Aktualisierung jedoch nicht erfolgreich war (z.B. weil der Policy-Enforcer abgeschaltet war), wird das Apply-Protokoll erneut gesendet, wenn das nächste Mal eine andere Apply-Funktion aufgerufen wird. Alternativ übermittelt der ausgefallene Policy-Enforcer eine Anfrage an den Policy-Server 122 über das Protokoll der nicht umgesetzten Änderungen, sobald er wieder im Netz ist (z.B. nach einem Neustart).
IX. STATUS-ÜBERGANGSPROTOKOLL FÜR HOCHVERFÜGBARE EINHEITEN
Gemäß einer Ausführungsvariante der Erfindung können der Policy-Server 122, die Policy-Enforcer 124, 126, sowie andere Netzwerkeinrichtungen im Hinblick auf eine Hochverfügbarkeit konfiguriert werden, indem neben der Primäreinheit eine Reserveeinheit bereit gehalten wird.
26 ist ein schematisches Blockdiagramm eines hochverfügbaren Systems, bestehend aus einer Primäreinheit 902 und einer Reserveeinheit 904. Die beiden Einheiten, 902 und 904, kommunizieren miteinander, indem sie über die Parallelanschlüsse 906a, 906b und ein Kabel 908 Heartbeats austauschen. Bei diesen Parallelanschlüssen 906a, 906b, sowie dem Kabel 908 handelt es sich um herkömmliche Komponenten, die in der Technik allgemein verfügbar sind.
Die Primäreinheit 902 und die Reserveeinheit 904 sind jeweils in ähnlicher Weise mit den anderen Komponenten 910, 912, 914, über die Anschlüsse 920a, 920b, 922a, 922b, 924a, bzw. 924b, verbunden. Bei diesen Komponenten 910, 912, 914, kann es sich um Hubs, Schalter, Steckverbindungen oder Ähnliches handeln. Da die Primäreinheit 902 und die Reserveeinheit 904 ähnliche Dienste und Funktionen gewährleisten und gegeneinander auswechselbar eingesetzt werden können, ist jede Einheit vorzugsweise mit den gleichen Komponenten 910, 912, 914, verbunden.
Das Parallelanschlusskabel 908 ist vorzugsweise ein herkömmliches LAP-Verbindungskabel, das für die Verbindung von zwei Parallelanschlüssen und die Kommunikation untereinander konzipiert ist. Die Primäreinheit 902 und die Reserveeinheit 904 kommunizieren vorzugsweise mittels TCP-Paketen über die hochverfügbaren Anschlüsse 906a, 906b, miteinander. Vorzugsweise existiert ein Punkt-zu-Punkt-Anschluss zwischen der Primäreinheit 902 und der Reserveeinheit 904 über die hochverfügbaren Anschlüsse 906a, 906b.
Vorzugsweise ist die Primäreinheit 902 für die Überprüfung des Status ihrer Netzanschlüsse auf Störungen oder Ausfälle verantwortlich. Wenn die Primäreinheit 902 beispielsweise feststellt, dass einer ihrer Netzanschlüsse nicht betriebsbereit ist, z.B. Anschluss 922a, prüft die Primäreinheit 902, ob der entsprechende Anschluss 922b in der Reserveeinheit 904 betriebsbereit ist. Nach der Feststellung, dass der entsprechende Anschluss 922b in der Reserveeinheit 904 betriebsbereit ist, sendet die Primäreinheit 902 eine Anfrage an die Reserveeinheit 904, die Systemfunktionen als aktive Einheit zu übernehmen. Die Primäreinheit 902 gibt dann ihre Rolle als aktive Einheit auf, schaltet sich selbst ab und ermöglicht so der Reserveeinheit 904, die Aufgaben der Primäreinheit 902 zu übernehmen. Wenn die Primäreinheit 902 ihren Betrieb wieder aufnimmt, erhält die Reserveeinheit 904 eine Anfrage von der Primäreinheit 902, ihre Rolle als aktive Einheit aufzugeben.
Wenn die Primäreinheit 902 aktiv ist und keine Störungen an ihren Anschlüssen feststellt, prüft sie permanent den hochverfügbaren Anschluss 906a, um den Status der Reserveeinheit 904 zu überwachen. Die Primäreinheit 902 prüft den hochverfügbaren Anschluss 906a auf Signale von der Reserveeinheit 904. Wenn die Reserveeinheit 904 eingeschaltet ist und läuft, stellt sie eine Verbindung zur Primäreinheit 902 her. Sobald die Verbindung hergestellt ist, beginnt die Reserveeinheit 904 mit dem Versand von Heartbeats an die Primäreinheit 902. Die Reserveeinheit 904 sendet kontinuierlich, in vordefinierten Intervallen, Heartbeats an die Primäreinheit 902. Gemäß einer Ausführungsvariante der Erfindung sendet die Reserveeinheit 904 einmal pro Sekunde ein „Keep Alive"-Paket, einschließlich eines KEEP_ALIVE-Befehls an die Primäreinheit 902.
Die Primäreinheit 902 antwortet auf das „Keep Alive"-Paket, indem sie das Befehlsfeld des Pakets in einen KEEP_ALIVE_RESP-Befehl abändert und das Paket an den Absender zurücksendet. Wenn die Reserveeinheit 904 über einen vordefinierten Zeitraum (z.B. eine Sekunde) keine Antwort auf das „Keep Alive"-Paket von der Primäreinheit 902 erhält, beginnt die Reserveeinheit 904, sich auf die Übernahme der aktiven Rolle vorzubereiten. Der vordefinierte Zeitraum sollte vorzugsweise nicht länger sein als zwei aufeinander folgende „Keep Alive"-Pakete.
Nach Übernahme der Rolle als aktive Einheit versucht die Reserveeinheit 904 in regelmäßigen Intervallen, wieder eine Verbindung zur Primäreinheit 902 herzustellen, um festzustellen, ob die Störung, bzw. der Ausfall der Primäreinheit behoben wurde. Wenn die Störung, bzw. der Ausfall behoben wurde, gibt die Reserveeinheit 904 die Kontrolle an die Primäreinheit 902 ab, nachdem sie die IP-Adressen aller Netzwerk-Schnittstellenkarten auf den entsprechenden Wert zurückgesetzt hat.
In Situationen, in denen die Reserveeinheit 904 die aktive Rolle von der Primäreinheit 902 übernimmt, wird eine Warnung/Alarmmeldung an den Netzadministrator gesandt, in der dieser Wechsel angezeigt wird. Falls die Primäreinheit 902 keine Heartbeats mehr von der Reserveeinheit 904 erhält, wird ebenfalls eine Warnung/Alarmmeldung an den Netzadministrator versandt, die anzeigt, dass die Reserveeinheit ausgefallen ist.
Es kann die Situation auftreten, in der sowohl die Primäreinheit 902 als auch die Reserveeinheit 904 voll funktionsfähig sind und die Reserveeinheit 904 dennoch die aktive Rolle übernehmen will. In diesem Fall übermittelt die Reserveeinheit einen Abschaltbefehl an die Primäreinheit 902, die dann die Kontrolle abgibt. Die Reserveeinheit 904 setzt ihre Rolle als aktive Einheit fort, bis die Primäreinheit 902 eine Anfrage an die Reserveeinheit 904 übermittelt, ihre aktive Rolle aufzugeben.
Gemäß einer Ausführungsvariante der Erfindung basiert das anfängliche Protokoll zur Statusermittlung jeder hochverfügbaren Einheit als Primär-, Reserve- oder Standalone-Einheit auf einem Selbsttest-Verfahren. 27 ist ein Ablaufdiagramm eines beispielhaften Prozesses zur Statusermittlung gemäß einer Ausführungsvariante der Erfindung. In Schritt 930 fährt eine erste hochverfügbare Einheit (Einheit X), die ihren Status als Primär- oder Reserveeinheit noch nicht endgültig ermittelt hat, hoch und übernimmt in Schritt 932 die Rolle einer Reserveeinheit. In Schritt 934 durchsucht Einheit X das Netz nach einer Primäreinheit und fragt in Schritt 936 an, ob eine Primäreinheit erfasst wurde. Ist die Antwort YES (Ja), versucht Einheit X, eine Verbindung zur Primäreinheit herzustellen. Wird diese erfolgreich hergestellt, initialisiert sich Einheit X in Schritt 938 als Reserveeinheit. Erfasst Einheit X jedoch keine Primäreinheit, übernimmt Einheit X in Schritt 940 die Rolle der Primäreinheit.
In Schritt 942 durchsucht Einheit X das Netz nach einer Reserveeinheit. Wird eine Reserveeinheit erfasst, wie in Schritt 944 angefragt, stellt Einheit X eine Verbindung zur Reserveeinheit her und initialisiert sich in Schritt 946 als Primäreinheit. Erfasst Einheit X jedoch innerhalb eines vordefinierten Zeitraums keine anderen Einheiten im Netz, initialisiert sich Einheit X in Schritt 948 als Standalone-Einheit.
Sobald die Primär- und die Sekundäreinheiten initialisiert wurden, werden die Konfigurationsänderungen der Primäreinheit ebenfalls an die Reserveeinheit übermittelt, um die beiden Einheiten zu synchronisieren. Die Konfigurationsinformationen werden vorzugsweise in einer LDAP-Datenbank, wie beispielsweise in der zentralen Policy-Server-Datenbank 130 oder einer Policy-Agent-Datenbank, 124, 126, gespeichert.
28 ist ein Ablaufdiagramm eines Prozesses zur Synchronisierung der Konfigurationsinformationen der Primär- und Reserveeinheit. In Schritt 950 fährt die Primäreinheit hoch und in Schritt 952 erfasst sie die Reserveeinheit. In Schritt 954 empfängt die Reserveeinheit die Informationen über die Konfigurationsänderungen von der Primäreinheit, sofern diese funktionsfähig ist. Andernfalls werden die Konfigurationsänderungen vom Netzadministrator direkt in die Reserveeinheit eingegeben. Wenn die Konfigurationsänderungen an die Primäreinheit übermittelt werden sollen, teilt die Primäreinheit der Reserveeinheit mit, falls Konfigurationsänderungen in der Primäreinheit auftreten. Die Änderungen werden dann an die Reserveeinheit übermittelt und umgesetzt. Die Reserveeinheit wiederum übermittelt den Status von Übermittlung und Umsetzung zurück an die Primäreinheit.
In Schritt 956 wird die Primäreinheit überprüft um festzustellen, ob sie funktionsfähig ist. Ist dies der Fall, wird die Primäreinheit gleichermaßen mit der Konfigurationsänderung aktualisiert. Ist die Primäreinheit jedoch nicht funktionsfähig, übernimmt die Reserveeinheit die aktive Rolle und wird in Schritt 958 zur aktiven Einheit. Die Primäreinheit kann aufgrund von Störungen der CPU, der Netzwerk-Schnittstellenkarte oder der Stromversorgung funktionsunfähig und damit inaktiv werden.
In Schritt 960 markiert die Reserveeinheit die Änderungen, um diese an die Primäreinheit zu übertragen, sobald die Primäreinheit funktionsfähig wird. Sobald die Primäreinheit funktionsfähig wird, wird die Primäreinheit mit den von der Reserveeinheit markierten Änderungen aktualisiert, wie in Schritt 962 dargestellt.
Gemäß einer Ausführungsvariante der Erfindung werden Software-Updates in der Primär- und der Reserveeinheit ebenfalls synchronisiert, um die Primär- und die Reserveeinheit seriell in einem einzigen Zyklus zu aktualisieren, ohne mehrere Aktualisierungszyklen durchführen zu müssen. Der Netzadministrator muss somit seine Arbeiten zur Aktualisierung der Reserveeinheit mit den gleichen Informationen wie die Primäreinheit nicht doppelt durchführen.
29 ist ein beispielhaftes Ablaufdiagramm für die Aktualisierung der Primär- und Reserveeinheit, wenn beide funktionsfähig sind. In Schritt 970 wird ein Update, beispielsweise ein nicht in den LDAP-Datenbanken gespeichertes Software-Update, von einer dem Netzadministrator zugänglichen Managementstation an die Primäreinheit gesandt/übermittelt. Die Primäreinheit aktualisiert sich dann in Schritt 972 selbst. In Schritt 974 sendet/übermittelt die Primäreinheit die Update-Informationen automatisch an die Reserveeinheit. In Schritt 976 aktualisiert sich die Reserveeinheit mit den Update-Informationen, die sie von der Primäreinheit erhalten hat, selbst.
30 ist ein beispielhaftes Ablaufdiagramm für die Aktualisierung der Primär- und der Reserveeinheit, wenn die Primäreinheit nicht funktionsfähig ist. In Schritt 978 wird die Primäreinheit funktionsunfähig und in Schritt 980 sendet/übermittelt der Netzadministrator ein Update direkt an die Reserveeinheit, anstatt an die Primäreinheit. In Schritt 982 aktualisiert sich die Reserveeinheit mit den Informationen, die sie von der Managementstation empfangen hat, selbst und wartet, bis die Primäreinheit wieder funktionsfähig wird. Sobald die Primäreinheit funktionsfähig wird, wird das Update in Schritt 986 automatisch zur Aktualisierung an die Primäreinheit gesandt/übermittelt. Die Primäreinheit aktualisiert sich in Schritt 988 selbst.
Obwohl die vorliegende Erfindung detailliert in Bezug auf die bevorzugten Ausführungsvarianten beschrieben wurde, ist es für den Fachmann sicherlich einleuchtend, dass die verschiedensten Änderungen und Modifikationen an den hier beschriebenen Beispielen vorgenommen werden können.
Das einheitliche Policy-Managementsystem aus 1 sollte beispielsweise eher als Beispiel, denn als Einschränkung betrachtet werden. Für den Fachmann ist nach Durchsicht der vorliegenden Erfindung sicher offensichtlich, dass zahlreiche alternative Konfigurationen möglich sind. Es können beispielsweise zusätzliche Netze mit Policy-Enforcern oder gar keine zusätzlichen Netze vorhanden sein. Des Gleichen müssen die Policy-Enforcer nicht zwingend über das Internet auf den Policy-Server zugreifen, sondern können die Verbindung mit anderen Mitteln, wie z.B. WAN, MAN etc. herstellen. Kurz gesagt können Anzahl und Typ der Nutzer und Ressourcen innerhalb und außerhalb der Organisation erheblich variieren, ohne den Umfang der vorliegenden Erfindung zu überschreiten.

1

Policy Enforcer: Policy-Enforcer
Policy Server: Policy-Server
Public Internet: Öffentliches Internet
Router: Router
Web Server: Web-Server

2

Admin. Groups: Administratorgruppen
Admin. Policies: Administrator-Policies
Administrators: Administratoren
Alarms: Alarmmeldungen
Alternate DMZ: Alternierende DMZ
Alternate LAN: Alternierendes LAN
Archive: Archive
Authentication: Authentifizierung
Bandwidth: Bandbreite
Certs: Zertifizierungen
Config.: Konfiguration
Control: Steuerung
Custom: Individuell
Device: Gerät
Device Group: Gerätegruppe
Dimensions: Abmessungen
Direct Proxy: Direkter Proxy
Dynamic Routes: Dynamische Strecken
FW Policy: Firewall-Policy
Global Info: Globale Informationen
Group Root: Gruppenwurzel
Host: Host
Host Group: Hostgruppe
License: Genehmigung
MO: Verwaltungsorganisation
Nat: National
Nat Pool: Nationaler Pool
Networks: Netze
Policy Server: Policy-Server
Policy Server Domain: Domain des Policy-Servers
Priv. Key: Priv. Schlüssel
Proxy Port: Proxy-Port
Resource Root: Ressourcenquelle
Routes: Strecken
Rules: Regeln
Service: Dienst
Service Group: Dienstegruppe
Sites: Standorte
SNMP Settings: SNMP-Einstellungen
Thresholds: Grenzwerte
Time: Zeit
User: Nutzer
User Group: Nutzergruppe
Video Nat: Video, national
VPN Clouds: VPN-Clouds
Weights: Gewichte

3

Administrator: Administrator
Centralized Management: Zentrale Verwaltung
Log Collecting and Archiving: Protokollerfassung und -archivierung
Multi-site Connectivity: Verwaltung der Connectivity mit
Management: mehreren Standorten
Policy Management: Policy-Verwaltung
Policy Server Reports: Policy-Server-Berichte
Secure Role Based Management: Sichere, rollenbasierte Verwaltung

4

Administrator: Administrator
Configuration Interface: Konfigurationsschnittstelle
Data Collector: Datenerfassung
Global Monitor UI: Globaler Monitor UI
Policy Server Install: Installation des Policy-Servers
Poliy Enforcer Install: Installation des Policy-Enforcers

5

Start: Start
Install and Connect Device to Network: Gerät installieren und mit dem Netz verbinden
Add Device to Device Groupe: Gerät einer Gerätegruppe hinzufügen
Transmit Registration Packet: Registrierungspaket übermitteln
Serial NO. Matched: Übereinstimmung der Seriennummern
YES: Ja
No: Nein
Package Settings for Policy-Enforcer: Paketeinstellungen für Policy-Enforcer
Transfer File to Policy Enforcer: Datei an Policy-Enforcer übermitteln
Initialize Configuration Database: Konfigurationsdatenbank initialisieren
End: Ende

6 & 7

Add New Device: Neues Gerät hinzufügen
Address: Adresse
Admin.: Administrator
Alarms: Alarmmeldungen
All: Alle
All Devices: Alle Geräte
All Devices' Status: Status aller Geräte
Applet Viewer: Presentation: Applet-Viewer: Darstellung des
Mainmenu: Hauptmenüs
Apply: Anwenden
Attached Device Group: Dazugehörige Gerätegruppe
Back: Zurück
Bandwidth: Bandbreite
Cancel: Abbrechen
Description: Beschreibung
Device Explored: Bearbeitetes Gerät
Device Name: Gerätename (Boston)
Device Serial Number: Seriennummer des Geräts
East Coast Device Group: Gerätegruppe Ostküste
Edit: Bearbeiten
Favorites: Favoriten
File: Datei
Forward: Weiter
Global Monitor Explored: Bearbeiteter allgemeiner Monitor
Global Spam List: Allgemeine Spam-Liste
Global URL Blocking: Allgemeine URL-Blockierung
Go: Gehe zu
Help: Hilfe
Links: Links
Location: Standort
Manager: Verwalten
Monitor: Überwachen
Name: Name
Network: Netzwerk
Network Status: Netzwerkstatus
OK: Bestätigen
Policy Server: Policy-Server
Policy Server Archive Options: Policy-Server Archivoptionen
Policy Server System Settings: Policy-Server Systemeinstellungen
Registered: Registriert
Remove: Löschen
Reports: Berichte
Reset: Zurücksetzen
Stop: Stopp
System Load: Systemauslastung
Time: Zeit
UITeam: UI-Team
Up/Down: Weiter/Zurück
View: Ansicht
VPN Connections: VPN-Verbindungen

8

Manager: Verwalten
Monitor: Überwachen
Reports: Berichte
Admin.: Administrator
Apply: Anwenden
Help: Hilfe
User Explored: Bearbeiteter Nutzer
All: Alle
Admin User: Administrator-Nutzer
Sales and Marketing: Vertrieb und Marketing
Finance: Finanzen
Manufacturing: Produktion
Customer Service: Kundendienst
Engineering: Entwicklung
Mobile Users: Mobile Nutzer
Partners: Partner
VPN Users: VPN-Nutzer
Firewall: Firewall
VPN: VPN
Bandwidth: Bandbreite
Administration: Verwaltung
Policy List: Policy-Liste
Add: Hinzufügen
Modify: Ändern
Delete: Löschen
Up: Weiter
Down: Zurück
Filter: Filter
Print: Drucken
Refresh: Neu laden
ID: ID
Order: Reihenfolge
Description: Beschreibung
Action: Aktion
Active: Aktiv
User: Nutzer
Source: Quelle
Services: Dienste
Allow any: Alle zulassen
User Group: Nutzergruppe
All: Alle
Spam Blocking: Spam blockieren
Host group: Host-Gruppe
URL Blocking: URL blockieren
VPN Key Ma..: VPN-Schlüsselmanager
Internet Acc...: Internet-Account
Allow: Zulassen

9

Device Explored: Bearbeitetes Gerät
Policy Server: Policy-Server
System Settings: Systemeinstellungen
Archive Options: Archivoptionen
Global URL Blocking: Allgemeine URL-Blockierung
Global Spam List: Allgemeine Spam-Liste
All: Alle
UITEam: UI-Team
Authentication Settings: Authentifizierungs-Einstellungen
East Coast Device Group: Gerätegruppe Ostküste
Modify URL of Aspen: URL für Aspen ändern
Enable List Download: Download der Liste freigeben
Download URL: URL herunterladen
Password: Passwort
Day of the Week: Wochentag
Time of Day: Tageszeit
Profile Management: Profilmanagement
Categories: Kategorien
Violence and Profanity: Gewalt und Verunglimpfung
Sexual Text: Texte mit sexuellem Inhalt
Sex Education: Sexualkunde
Sports and Leisure: Sport und Freizeit
Partial Nudity: Freizügige Darstellungen
Gross Depictions: Unsittliche Bilder
Gambling: Glücksspiel
Full Nudity: Nacktfotos
Militant and Extremist: Militante und extremistische Darstellungen
Null: Nichtig
OK: Bestätigen
Reset: Zurücksetzen
Cancel: Abbrechen

10

Manager: Verwalten
Monitor: Überwachen
Reports: Berichte
Admin.: Administrator
Apply: Anwenden
Help: Hilfe
Host Explored: Bearbeiteter Host
All: Alle
LAN: LAN
WAN: WAN
DMZ/Servers: DMZ/Server
Sales and Marketing: Vertrieb und Marketing
Engineering: Entwicklung
Manufacturing: Produktion
Finance: Finanzen
Partners: Partner
Remote Sites: Entfernte Standorte
Mobile Users: Mobile Nutzer
Customer Service: Kundendienst
Add New Host: Neuen Host hinzufügen
Name: Name
IP Address: IP-Adresse
Netmask: Netzmaske
External Host: Externer Host
External Device IP Address: IP-Adresse des externen Geräts
Device: Gerät
Attachted Host Group: Zugehörige Host-Gruppe
Remove: Entfernen
OK: Bestätigen
Reset: Zurücksetzen
Cancel: Abbrechen

11

Manager: Verwalten
Monitor: Überwachen
Reports: Berichte
Admin.: Administrator
Apply: Anwenden
Help: Hilfe
Service Explored: Bearbeiteter Dienst
All: Alle
Multimedia Streaming/Conferencing: Multimedia-Streaming/Konferenzen
Information Retrieval: Informationsabfrage
Security and Authentication: Sicherheit und Authentifizierung
Mail Applications: Mail-Anwendungen
Routing Protocols: Routing-Protokolle
Standard Protocols: Standard-Protokolle
Database Applications: Datenbank-Anwendungen
Popular Internet Protocols: Verbreitete Internet-Protokolle
Modify Service: Dienst-Änderung
Name – http and URL Tracking: Name – http und URL-Verfolgung
Description: Beschreibung
http with URL Blocking enabled: http mit URL-Blockierung freigegeben
Type: Typ
Attached Service Group: Zugehörige Dienstegruppe
http Configuration: http-Konfiguration
Enable URL Blocking: URL-Blockierung freigeben
OK: Bestätigen
Reset: Zurücksetzen
Cancel: Abbrechen

12

Manager: Verwalten
Monitor: Überwachen
Reports: Berichte
Admin.: Administrator
Apply: Anwenden
Help: Hilfe
Time Explored: Bearbeiteter Zeitraum
All: Alle
Any: Beliebig
Evening: Abend
Work: Arbeitszeit
Weekends: Wochenenden
Modifiy Time Work: Arbeitszeiten ändern
Name: Name
Description: Beschreibung
Working Hours/Week Days: Arbeitszeiten/Wochentage
Day of Week/Hour of Day: Wochentag/Tageszeit
Sunday: Sonntag
Monday: Montag
Tuesday: Dienstag
Wednesday: Mittwoch
Thursday: Donnerstag
Friday: Freitag
Saturday: Samstag
AM/PM: Vormittag/Nachmittag
OK: Bestätigen
Reset: Zurücksetzen
Cancel: Abbrechen

13

Firewall: Firewall
Bandwidth: Bandbreite
Administration: Verwaltung
VPN Policy: VPN-Policy
West/East Coast Cloud: Cloud West-/Ostküste
Host Group: Host-Gruppe
Customer Service: Kundendienst
Device: Gerät
Users Group: Nutzergruppe
Rules: Regeln
Sites: Standorte
Users: Nutzer
VPN Rule: VPN-Regel
Order: Auftrag
Desc:: Beschreibung
Policy Created by System for VPN: Policy zur Freigabe der VPN-
Cloud Functioning: Cloud-Funktion wurde vom System erstellt

14

Firewall: Firewall
Bandwidth: Bandbreite
Administration: Verwaltung
New/FW Policy: Neue/Firewall-Policy
Description: Beschreibung
Action: Aktion
Allow: Freigabe
Active: Aktiv
User: Nutzer
Source: Quelle
Services: Dienste
Destination: Ziel
Time: Zeit
Authentikation: None: Authentifizierung: Keine
OK: Bestätigen
Reset: Zurücksetzen
Cancel: Abbrechen

15

DNMON: Domain
New Route: Neue Strecke
Gate: Gate
PDP Engine: PDP-Maschine
Kernel: Kernel
VPN Driver: VPN-Treiber

16 & 17

Setup File: Setup-Datei
VPN Reachability Configuration File: Datei mit der VPN-Erreichbarkeits-Konfiguration
Client's VPN Preshared Key File: Datei mit den vordefinierten VPN-Client-Codes
Self-extracting Executable: Selbstextrahierende Programmdatei
Static Portion (Executable): Statischer Anteil (Programmdatei)
Dynamic Portion (Dynamic Configuration): Dynamischer Anteil (Dynamische Konfiguration)
Replace Dynamic Portion with Client-specific VPN-Configuration: Dynamischen Anteil durch Clientspezifische VPN-Konfiguration ersetzen
Verify Authentication: Authentifizierung überprüfen
VPN Client: VPN-Client
Client opens Https Connection: Client öffnet Https-Verbindung
Reques Authentication: Authentifizierungsanfrage
Respond to Authentication: Authentifizierung übermitteln
Deliver Self-extraction: Selbstextrahierende Programmdatei
Executable: übertragen
Policy-Enforcer: Policy-Enforcer
Authentication/Authorization DB: Datenbank für Authentifizierung/Autorisierung
VPN Configuration DB: Datenbank für VPN-Konfiguration
Access VPN Configuration: Zugriff auf VPN-Konfiguration

18

IP SEC Engine: IP SEC-Maschine
Packet Forwarding: Paketübermittlung
Stream Table: Datenstrom-Tabelle
Stats: Status
Protocol Classification Engine: Protokoll-Klassifikationsmaschine
Policy Engine: Policy-Maschine
B/W Management: B/W-Management

19

Policy Request Table: Policy-Abfragetabelle
Decision Engine: Entscheidungsmaschine
User Group: Nutzergruppe
Host Group: Host-Gruppe
Service Groupe: Dienstegruppe
Time Group: Zeitgruppe
Policy Rules Database Buffer: Datenbank-Zwischenspeicher für Policy-Regeln
Resource Engine: Ressourcen-Maschine

20

Stream Data Assembly: Zusammenstellung des Datenstroms
Sliding Stream Data Window: Datenstrom-Gleitfenster
ANS. 1: Antwort 1
Protocol Classification State: Maschine für den Status der
Machine: Protokoll-Klassifizierung
Protocol Definition Signature DB: Datenbank für die Signatur der Protokolldefinition

21

PRNG: Pseudo-Zufallszahlengenerator
Diffie Hellman: Diffie-Hellman-Block
IKE: IKE-Block
IPSEC SA Table: IPSEC SA-Tabelle
RSA: RSA-Block
Bulk Cryptographic Transforms: Generelle Verschlüsselung
IPSEC Encapsulation/Decapsulation: IPSEC-Einkapselung/Entkapselung

22–24

Timestamp: Zeitstempel
Service: Dienst
Source/Destination IP Address and Port: IP-Adresse und Anschluss von Quelle/Ziel
User ID: Nutzer-ID
Status: Status
Operation: Operation
In/Out Bytes: Ein-/Ausgehende Bytes
Duration: Dauer
LDAP Root: LDAP-Wurzel
Branch: Zweig
Apply Log: Anwendungsprotokoll
User: Nutzer
Device: Gerät
Domain: Domain
Apply: Anwenden

25

Start: Start
Admin. makes a Policy Setting Change: Administrator ändert die Policy-Einstellungen
Update LDAP-Tree with Change: Aktualisierung des LDAP-Verzeichnisbaums mit der Änderung
Create Log with Change: Änderungsprotokoll erstellen
Update Admin. Log DN: Administrator-Protokolldomain aktualisieren
Apply Invoked: Anwendung aufgerufen?
Create Log for each Policy Enforcer in Domain: Protokoll für jeden Policy-Enforcer der Domain erstellen
Clear Apply Attribute in Admin's Log DN: Eindeutige Zuordnung der Attribute im Administrator-Protokoll
Transmit Updates to Policy-Enforcer: Aktualisierungen an Policy-Enforcerübermitteln
Update Successful?: Aktualisierung erfolgreich?
Clear Apply Attribute in: Eindeutige Anwendung der
Successful Policy Enforcers DN: Attribute in der Domain des erfolgreichen Policy-Enforcers
End: Ende

26

Primary Unit: Primäreinheit
Backup Unit: Reserveeinheit

27

Start: Start
Boot up: Hochfahren
Assume Role of First Class Unit: Übernahme der Rolle als Primäreinheit
Search Network for Second Class Unit: Suche nach Reserveeinheit im Netz
Second Class Unit Detected?: Reserveeinheit erfasst?
Yes: Ja
Initialize als First Class Unit: Als Primäreinheit initialisieren
No: Nein
Assume Role of Second Class Unit: Übernahme der Rolle als Reserveeinheit
Search Network für First Class Unit: Suche nach Primäreinheit im Netz
First Class Unit Detected?: Primäreinheit erfasst?
Initialize als Second Class Unit: Als Reserveeinheit initialisieren
Initialize als Third Class Unit: Als Dritteinheit initialisieren
End: Ende

28

Start: Start
Boot up Primary Unit: Primäreinheit hochfahren
Detect Backup Unit: Reserveeinheit erfassen
Receive Config. Changes: Empfang von Konfigurationsänderungen
Primary Functional?: Primäreinheit funktionsfähig?
Yes: Ja
No: Nein
Backup Unit Becomes Active Unit: Reserveeinheit wird zu aktiven Einheit
Tag Config. Changes: Tag für Konfigurationsänderungen setzen
Update Primary Unit: Primäreinheit aktualisieren

29

Start: Start
Management Station Sends Update to Primary Unit: Managementstation sendet Aktualisierung an Primäreinheit
Primary Unit Updates: Aktualisierung der Primäreinheit
Primary Unit Sends Update to: Primäreinheit sendet
Backup Unit: Aktualisierung an Reserveeinheit
Backup Unit Updates: Aktualisierung der Reservereinheit
End: Ende

30

Start: Start
Primary Unit Becomes: Primäreinheit wird
Nonfunctional: funktionsunfähig
Managementstation Sends Update to Backup Unit: Managementstation sendet Aktualisierung an Reserveeinheit
Backup Unit Updates: Aktualisierung der Reserveeinheit
Primary Unit Becomes Functional: Primäreinheit wird funktionsfähig
Backup Unit Sends Update to: Reserveeinheit sendet
Primary Unit: Aktualisierung an Primäreinheit
Primary Unit Updates: Aktualisierung der Primäreinheit
End: Ende

Claims

System zur Verwaltung von Policy-Diensten in einer Organisation, wobei diese Organisation ein erstes Netz (102) und ein zweites Netz (104) beinhaltet, und das System Folgendes umfasst: eine erste Kanteneinrichtung (124), die entsprechend konfiguriert ist, um Policys für das erste Netz (102) entsprechend ersten Policy-Einstellungen zu verwalten, und eine zweite Kanteneinrichtung (126), die entsprechend konfiguriert ist, um Policys für das zweite Netz entsprechend zweiten Policy-Einstellungen zu verwalten, einen zentralen Policy-Server (122), der mit der ersten und der zweiten Kanteneinrichtung (124, 126) verbunden und entsprechend konfiguriert ist, um die ersten und zweiten Policy-Einstellungen zu definieren und die erste und die zweite Kanteneinrichtung (124, 126) von einem einzigen Standort aus zu verwalten, wobei das genannte System dadurch gekennzeichnet ist, dass jede Kanteneinrichtung (124, 126) eine Protokoll-Klassifikationsmaschine (508) zur Festlegung eines Protokolls, das einem eingehenden Paket zugeordnet wird, eine Policy-Maschine (510), die eine Entscheidung über die Weiterleitung des Pakets auf der Basis der dem Paket zugeordneten Policy-Einstellungen trifft, und ein Paket-Weiterleitungsmodul (504) zur Weiterleitung des Pakets basierend auf den Policy-Einstellungen umfasst, wobei die genannte Protokoll-Klassifikationsmaschine (508) zudem eine Protokoll-Datenbank (710) umfasst, die das Mapping der Protokolle mit den Datenmustern speichert, die in einem Datenstrom erfasst werden, und wobei die genannte Protokoll-Klassifikationsmaschine (508) entsprechend konfiguriert ist, um eine dynamisch aktualisierte Signaturdatenbank zu nutzen, die aus Skript-Protokolldefinitionen kompiliert wurde.
Das System gemäß Anspruch 1, wobei die Policy-Maschine (510) außerdem eine Ressourcen-Maschine (604) mit dem aktuellen Mapping der Ressourcengruppen-Namen für die Mitglieder in jeder Gruppe umfasst.
Das System gemäß Anspruch 2, wobei die Policy-Maschine (510) außerdem einen Policy-Regelpuffer (608) umfasst, der die für die Gruppe, der das Paket zugeordnet wurde, spezifizierten Policy-Einstellungen speichert.
Das System gemäß Anspruch 3, wobei die Policy-Maschine (510) außerdem eine Entscheidungsmaschine (606) zum Abgleich des Pakets mit den Policy-Einstellungen im Policy-Regelpuffer (608) basierend auf den Mitgliedsinformationen von der Ressourcen-Maschine (604) umfasst.
Das System gemäß Anspruch 1, das außerdem eine Sicherheitsmaschine (502) zur Überprüfung der Berechtigung des Nutzers, der das Paket übermittelt, umfasst.
Das System gemäß Anspruch 1, das außerdem ein Statistikmodul (512) zur Erfassung von Statistiken zu den Pakten umfasst, die die Kanteneinrichtung (124, 126) durchlaufen.
Das System gemäß Anspruch 6, wobei das Statistikmodul (512) entsprechend konfiguriert ist, um eine Bytezählung der Pakete durchzuführen, die die Kanteneinrichtung (124, 126) durchlaufen, wobei die Bytezählung entsprechend den den Paketen zugeordneten Ressourcen organisiert ist.
Ein Verfahren zum Einsatz in einem System, das eine erste Kanteneinrichtung (124), die Policys für ein erstes Netz (102) entsprechend ersten Policy-Einstellungen verwaltet, und eine zweite Kanteneinrichtung (126) umfasst, die Policys für ein zweites Netz (104) entsprechend zweiten Policy-Einstellungen verwaltet, wobei das System außerdem einen zentralen Policy-Server (122) umfasst, der mit der ersten und der zweiten Kanteneinrichtung (124, 126) verbunden und der entsprechend konfiguriert ist, um die ersten und zweiten Policy-Einstellungen zu definieren und die erste und die zweite Kanteneinrichtung (124, 126) von einem einzigen Standort aus zu verwalten, wobei das genannte Verfahren durch die folgenden Schritte gekennzeichnet ist: Festlegung eines Protokolls, das einem eingehenden Paket zugeordnet wird; Treffen einer Entscheidung über die Weiterleitung des Pakets basierend auf den diesem Paket zugeordneten Policy-Einstellungen; und Weiterleitung des Pakets basierend auf den Policy-Einstellungen, wobei die genannte Festlegung außerdem umfasst: Speichern des Mappings von Protokollen mit Datenmustern, die in einem Datenstrom erfasst wurden, in einer Protokolldatenbank (710); und Abgleich der Pakete mit einem Protokoll, das in der Protokolldatenbank (710) gespeichert ist, wobei die Protokoll-Klassifikationsmaschine (508) der entsprechenden Kanteneinrichtung (124, 126) eine dynamisch aktualisierte Signaturdatenbank nutzt, die aus Script-Protokolldefinitionen kompiliert wurde.
Das Verfahren gemäß Anspruch 8, das außerdem die Pflege des aktuellen Mapping der Ressourcengruppen-Namen mit den Mitgliedern jeder Gruppe in einer Ressourcenmaschine (604) umfasst.
Das Verfahren gemäß Anspruch 9, das außerdem die Speicherung der für die Gruppe, die dem Paket zugeordnet ist, spezifizierten Policy-Einstellungen in einem Policy-Regelpuffer (608) umfasst.
Das Verfahren gemäß Anspruch 10, das außerdem den Abgleich des Pakets mit den Policy-Einstellungen im Policy-Regelpuffer (608) basierend auf den Mitgliedsinformationen von der Ressourcenmaschine (604) umfasst.
Das Verfahren gemäß Anspruch 8, das außerdem die Überprüfung der Berechtigung des Nutzers, der das Paket übermittelt, umfasst.
Das Verfahren gemäß Anspruch 8, das außerdem die Erfassung von Statistiken zu den Paketen, die die Kanteneinrichtung (124, 126) durchlaufen, umfasst.
Das Verfahren gemäß Anspruch 13, wobei die Erfassung außerdem Folgendes umfasst: Durchführung einer Bytezählung der Pakete, die die Kanteneinrichtung (124, 126) durchlaufen; und Organisation der Bytezählung entsprechend den den Paketen zugeordneten Ressourcen.