-
Die
Erfindung betrifft ein Verfahren zur Wiederaktivierung einer sicheren
Kommunikationsverbindung zwischen Klienten-Rechnern und einem Server nach einem
Neustart des Servers, wobei sichere Kommunikationsverbindungen,
für welche
zumindest beim Aufbau zwischen dem Server und den Klienten-Rechnern ein Authentifizierungsprozess durchgeführt wird,
für eine Übertragung
von Datenpaketen vorgesehen sind.
-
Von
Kommunikationsnetzen werden Benutzern, welche über z.B. Computer, Terminal
oder andere Endgeräte
Zugang zu einem Kommunikationsnetz haben, Dienste zu Kommunikationszwecken
zur Verfügung
gestellt. Solche Dienste sind beispielsweise die Übertragung
von Sprache oder Daten vor allem in Form von Paketen.
-
Kommunikationsnetze
wie z.B. Firmennetze oder LANs, aber auch große Netze wie das Internet, welche
zur Zeit hauptsächlich
für die Übertragung von
Daten – insbesondere
in Paketform genutzt werden, können
aufgrund ihrer Architektur – d.h.
anhand des konzeptionellen Aufbaus des Kommunikationsnetzes – unterschieden
werden. Neben beispielsweise so genannten Hostsystemen, bei denen
die Benutzer über
Terminals bzw. Datenendgeräte
an einen meist leistungsfähigen
Zentral- oder Großrechner
angeschlossen sind, oder so genannten Peer-to-Peer-Systemen, bei
denen alle Rechner bzw. Computer des Kommunikationsnetzes gleichberechtigt
sind, gibt es auch so genannte Client-Server-Systeme.
-
Bei
einem Client-Server-System werden zwei Typen von Rechnern im Kommunikationsnetz unterschieden – so genannte
Server und so genannte Clients oder Klientenrechner.
-
Der
Server stellt dabei ein Netzelement bzw. einen Rechner im Kommunikationsnetz
dar, von welchem zentral Dienste – so genannte Server-Anwendungen
oder Applikationen – für mehrere
andere Netzelemente bzw. Rechner – die so genannten Clients oder
Klientenrechner – angeboten
werden. Von den Clients oder Klientenrechnern werden diese Server-Dienste
genutzt und dem Benutzer mittels Benutzeroberfläche oder Benutzerschnittstelle
der Zugang zu den zentralen Diensten des Servers angeboten. Zu diesem
Zweck wird vom Klientenrechner Kontakt zum Server aufgebaut. Dieses
Prinzip wird auch als Client-Server-Prinzip
bezeichnet. Dadurch können Ressourcen
(z.B. Anwendungen, Datenbanken, etc.) besser ausgenutzt werden,
als wenn jeder Klientenrechner diese Ressourcen lokal und dauerhaft,
jedoch nur für
eine gelegentliche Nutzung, bei sich selbst vorrätig hält.
-
Server
können
mit den Klientenrechnern über
ein lokales Netz (z.B. Firmennetz, Local Area Network (LAN), etc.)
verbunden sein. Der Zugriff auf den Server von einem Klientenrechner
aus kann allerdings auch über
Telekommunikationsnetze der verschiedensten Art wie beispielsweise
dem Internet, etc. erfolgen.
-
Die
Kommunikation – d.h.
der Austausch von Daten – zwischen
dem Server und den Klientenrechnern erfolgt über eine Kommunikationsverbindung meist
nach dem Client-Server-Prinzip.
Vom Begriff „Kommunikationsverbindung" wird dabei beispielsweise
eine nutzbare, durchgeschaltete physikalische Leitung oder auch
ein so genannter virtueller Pfad zwischen fest definierten Punkten
eines Kommunikationsnetzes – wie
z.B. Server und Klientenrechner – bezeichnet.
-
Die
Regeln, von denen Format und Bedeutung der über die Kommunikationsverbindung
ausgetauschten Nachrichten und Daten bestimmt werden, werden als
Protokoll bezeichnet, welches z.B. aus mehreren Schichten wie z.B.
Netzwerk-, Transport oder Anwendungsschicht aufgebaut sein kann.
Das für
einen Austausch von Daten und Nachrichten eingesetzte Protokoll
hängt von
der Art bzw. dem Einsatzbereich des Servers ab.
-
So
werden z.B. Server, von welchen das so genannte HyperText Transfer
Protocol (http) auf der Anwendungsschicht zur Übertragung von Daten (z.B. Webseiten,
etc.) über
ein Netzwerk (z.B. Internet) eingesetzt wird, auch als http-Server bezeichnet.
Andere Server, von welchen Protokolle wie z.B. das File Transfer
Protocol (FTP) als Protokoll auf der Anwendungsschicht implementiert
werden, um beispielsweise Dateien von einem Server zu einem Klientenrechner,
von einem Klientenrechner zu einem Server oder clientgesteuert zwischen
zwei Servern zu übertragen,
können
allgemein auch als Datei- oder
Datenserver bezeichnet werden. Auf der so genannten Transportschicht
wird bei http bzw. FTP z.B. das so genannte Transmission Control
Protocol (TOP) eingesetzt, durch welches vereinbart wird, auf welche Art
und Weise Daten zwischen den Rechnern ausgetauscht werden sollen.
Auf der so genannten Netzwerkschicht wird beispielsweise häufig das
so genannte Internetprotokoll (IP) verwendet, durch welches exakte
Vereinbarungen getroffen werden, nach denen Daten zwischen Rechnern
bzw. Prozessen ausgetauscht werden, die durch ein Kommunikationsnetz
miteinander verbunden sind. Client-Server-System, von welchen das Internetprotokoll
IP bei Kommunikationsverbindungen eingesetzt wird, können auch
als IP-basierte Client-Server-Systeme bezeichnet werden.
-
Eine
Kommunikationsverbindung wird auch als sichere Kommunikationsverbindung
bezeichnet, wenn zumindest beim Aufbau einer Kommunikationsverbindung
zwischen zwei Rechnern (z.B. Server und Klientenrechner) ein Authentifizierungsprozess durchgeführt wird,
von dem sichergestellt wird, dass die beiden Rechner zur Durchführung dieser
Kommunikationsverbindung berechtigt sind. Durch diesen Authentifizierungsprozess
beim Aufbau der sicheren Kommunikationsverbindung kann festgestellt
werden, ob die Kommunikationsverbindung auch mit einem richtigen
Kommunikationspartner aufgebaut wird – also mit jenem Rechner (z.B.
Server), zu welchem beispielsweise Daten übertragen werden sollen. Zusätzlich können beispielsweise
während
einer bestehende Kommunikationsverbindung in verschiedenen Zeitabständen Authentifizierungs prozesse durchgeführt werden,
um laufend zu prüfen,
ob ein Kommunikationspartner (z.B. Rechner, Server, Klientenrechner,
etc.) z.B. für
die Übertragung
bestimmter Daten legitimiert ist oder z.B. die Kommunikationsverbindung
immer noch eine sichere Verbindung ist. Auf diese Weise kann eine
Kommunikationsverbindung beispielsweise vor Abhören oder dem Zugriff von Unbefugten
auf vertrauliche Daten während
der Übertragung
geschützt
werden.
-
In
manchen Kommunikationsnetzen wird zum Schutz gegen unautorisierten
Zugriff der Authenifizierungsprozess noch zusätzlich mit einem Verschlüsselungsprozess
kombiniert. In diesem Fall wird z.B. während des Authentifizierungsprozesses
ein Schema aus Aufforderung und Antwort zwischen den Kommunikationspartner
(z.B. Klientenrechner, Server, etc.) eingesetzt, durch welches von
jedem an der sicheren Kommunikationsverbindung beteiligte Rechner
bewiesen wird, dass ein gemeinsames Verschlüsselungssystem vorhanden und
dieser Rechner damit zur Teilnahme an der sicheren Kommunikationsverbindung
berechtigt ist. Dabei werden beispielsweise gemeinsame, aber geheime
digitale Zertifikate oder Schüssel
ausgetauscht.
-
Kommunikationsnetze,
von welchen als Protokoll auf der Netzwerkschicht das so genannte
Internetprotokoll (IP) verwendet wird, werden auch als IP-Netze
bezeichnet. Für
Kommunikationsverbindungen über
diese Netze wurde seit 1998 ein eigenes Sicherheitsverfahren – das so
genannte IP Security (Protocol) IPSec entwickelt, welches mittlerweile
von der Internet Engineering Task Force IETF in mehreren Requests
for Coments (RFC) definiert worden ist. Dabei beschreiben der RFC
2401 aus 1998 bzw. der RFC 4301 vom Dezember 2005 – so zu
sagen als Hauptdokumente – die
Struktur von IPSec.
-
Durch
IPSec soll eine sichere Übertragung von
Daten in IP-Netzen
und damit Schutzziele wie z.B. Vertraulichkeit, Authentizität und Integrität gewährleistet
werden. Mit IPSec wird der Aufbau sicherer Kommunikationsverbindungen,
und damit einer sicheren Datenübertragung
ermöglicht.
Dabei werden von IPSec Sicherheitsdienste (z.B. Zugangskontroll,
Authentifizierungs-verfahren, Vertraulichkeit, etc.) zu Verfügung gestellt,
durch welche Rechnern eines IP-Netzes ermöglicht wird, für eine sichere Kommunikationsverbindung
entsprechende Sicherheitsprotokoll auszuwählen, Algorithmen für eine Nutzung
der IPSec-Dienste zu bestimmen und Rahmenbedingungen für eine Definition
von Verschlüsselungsparameter
(z.B. Schlüssel,
Schüssellänge, etc.),
welche von den IPSec-Diensten vorausgesetzt werden, festzulegen.
Von IPSec werden dabei zwei Mechanismen eingesetzt:
- – der
IP-Authentication Header Mechanismus (AH), durch welchen die Authentifizierung
und Identifizierung einer Datenquelle abgewickelt wird. Dieser Mechanismus
wird von der IETF im RFC 2402 bzw. RFC 4302 beschrieben.
- – der
Encapsulation-Security-Payload (ESP), durch welchen die Verschlüsselung
der Daten wahlweise im so genannten Transport-Modus, bei welchem
der so genannte Header eines Datenpaketes nicht verschlüsselt wird,
oder im so genannten Tunnel-Modus, bei dem die gesamten Daten verschlüsselt werden,
durchgeführt
wird. Dieser Mechanismus wird von der IETF im RFC 2406 bzw. im RFC
4303 beschrieben wird.
-
Zur
Verwaltung bei welchen Rechnern eines Kommunikationsnetzes bzw.
welchen Adressen, die den jeweiligen Rechnern zugeordnet sind und über die
diese Rechner angesprochen werden können, IPSec mit welchen Parametern
angewendet werden soll, ist eine Datenbank, die so genannte Security
Policy Database SPD eingerichtet. In dieser Datenbank sind für die entsprechenden
Rechner – getrennt
nach Quell- und Zieladresse beim Versand von Daten – alle notwendigen
Informationen abgelegt. Beim Versand von Daten wird dann in der
Datenbank SPD nachgesehen, wie mit den Daten zu verfahren ist, wobei
es grundsätzlich
drei Möglichkeiten
gibt: die Daten sind zu verwerfen, das heißt, dass die Adresse des empfangenen Rechners
gesperrt ist; die Daten werden unverändert weitergeleitet oder IPSec
ist für die
Daten anzuwenden.
-
Für den Fall,
dass IPSec bei einer Kommunikationsverbindung für die Datenübertragung anzuwenden ist,
können
dann die entsprechenden Verschlüsselungsparameter – zusammengefasst
in einer so genannten Security Association SA aus der SDP entnommen
werden. Eine SA liegt üblicherweise
nur dann vor, wenn zwischen Rechnern bzw. ihren Adressen häufiger Daten
ausgetauscht werden. Ist dies nicht der Fall, so muss vor dem Datenaustausch beim
Aufbau einer sicheren Kommunikationsverbindung eine SA aufgebaut
werden. Dies kann manuell durch Einstellung über ein Netzwerkmanagement oder
unter Nutzung des International Security and Key Management Protocol
ISAKMP erfolgen, welche auch als Internet Key Exchange (IKE) Protokoll
bezeichnet werden kann.
-
Das
ISAKMP bzw. IKE-Protokoll ist in den RFCs 2408, 2409 bzw. auch 4306
der IETF definiert und wird in IP-basierten Netzen, in welchen IPSec eingesetzt
wird, zur Verwaltung von Verschlüsselungsverfahren
verwendet. ISAKMP bzw. IKE dient dabei vor der eigentlichen geschützten Datenübertragung
mit IPSec der Authentifizierung von sendendem und empfangendem Rechner
sowie dem Aushandeln von Verschlüsselungsverfahren
bzw. der SAs zwischen den Rechnern, wobei dies in zwei Phasen durchgeführt wird.
Zuerst wird in einer ersten Phase eine SA – die so genannte Phase1 SA – für eine geschützte Übertragung
der ISAKMP-Daten (z.B. Identifikation eines Rechners, angewendetes
Verschlüsselungsverfahren,
etc.) definiert. In einer zweiten Phase wird dann eine SA – die so
genannte Phase2 SA – für die Verschlüsselung
der Daten, welche mittels IPSec geschützt übertragen werden sollen, zwischen
den Rechnern verhandelt und die entsprechenden Verschlüsselungsinformation
meist bereits verschlüsselt
zwischen den Rechner ausgetauscht.
-
Die
ausgehandelten SAs der ersten und der zweiten Phase können außerdem in
ihrer Gültigkeitsdauer
z.B. durch Definition eines Zeitraums oder einer übertragenen
Datenmenge, für
welche SA gültig ist,
eingeschränkt
werden. Nach Ablauf der Gültigkeitsdauer
einer SA ist dann z.B. eine neuerliche Authentifizierung oder eine
Erneuerung der Verschlüsselungsparameter
notwendig.
-
Sicherheitsvorgaben
und/oder Verschlüsselungsdaten
(z.B. Verschlüsselungsverfahren,
Schlüssel,
Schlüssellänge, etc.),
wie sie beispielsweise bei IPSec in Form von SAs zwischen an einer
Kommunikationsverbindung teilnehmenden Rechnern ausgetauscht werden,
können
auch dann ungültig
bzw. verworfen werden, wenn von einem an einer sicheren Kommunikationsverbindung
teilnehmenden Rechner ein so genannten Re-Boot oder Neustart durchgeführt wird.
Bei einem Re-Boot wird der Rechner neu hochgefahren – d.h. das
so genannte Betriebssystem, von welchem beispielsweise Betriebsmittel
des Rechners wie z.B. Speicher, Ein-/Ausgabegeräte, etc. verwaltet werden,
die Ausführung
von Programmen gesteuert wird, etc., wird neu geladen und dabei beispielsweise
wesentliche Komponenten der Rechners getestet und initialisiert.
-
Nach
einem Re-Boot werden von einem Rechner üblicherweise erst dann entsprechende Prozesse
für sichere
Kommunikationsverbindungen (z.B. Authentifizierung, Versand von
neuen Sicherheitsvorgaben und/oder Verschlüsselungsdaten, etc.) zu anderen
Rechnern durchlaufen, wenn zu diesen Rechnern wieder Daten übertragen
werden sollen – das
ist auch der Fall, wenn zu diesen Rechnern bereits vor dem Re-Boot
sichere Kommunikationsverbindungen bestanden haben. Bei einem Einsatz von
IPSec werden beispielsweise nach einem Re-Boot erst dann neue Phase1
SAs wie auch neue Phase2 SAs mit einem anderen Rechner ausgetauscht,
wenn vom Rechner, der gerade einen Re-Boot durchgeführt hat, das erste Datenpaket
an diesen anderen Rechner übertragen
werden soll. Hat vor dem Re-Boot bereits eine sichere Kommunikationsverbindung
zu diesem anderen Rechner bestanden und sind daher auf diesem Rechner
entsprechende, aus seiner Sicht noch gültige SAs hinterlegt, so werden
diese verworfen und für
die weitere Kommunikation die neu ausgetauschten SAs verwendet.
-
Bei
Client-Server-Systemen, deren Kommunikation nach dem Client-Server-Prinzip
erfolgt, wird die Kommunikation üblicherweise
von Seiten der Klientenrechner, nicht aber vom Server angestoßen. Das
bedeutet, dass bei einem Re-Boot eines Klientenrechners zwar sofort
bei der ersten Kontaktaufnahme mit dem Server die Prozesse für eine sichere Kommunikationsverbindung
durchlaufen werden, dass aber ein Re-Boot des Servers zu Lücken in
der Kommunikation bei Verwendung sicherer Kommunikationsverbindungen
z.B. mittels IPSec führen
kann.
-
Im
Fall dass von einem Server kein Kontakt zu den Klientenrechnern
gestartet wird, wird von einem Klientenrechner, von welchem Daten über eine sichere
Kommunikationsverbindung zum Server gesendet werden, der Re-Boot
nicht erkannt. Vom Klientenrechner werden beispielsweise weiterhin
die vor dem Re-Boot ausgetauschten Sicherheitsvorgaben und/oder
Verschlüsselungsdaten
für die
Datenübertragung über die
sichere Kommunikationsverbindung eingesetzt. Da durch den Re-Boot am Server z.B.
die entsprechenden Verschlüsselungsdaten nicht
mehr gültig
sind, können
die über
die sichere Kommunikationsverbindung übertragenen Daten von Server
dann z.B. nicht mehr erkannt, entschlüsselt oder gelesen werden.
Die Daten werden daher üblicherweise
vom Server verworfen.
-
Erst
wenn von Seiten des Klientenrechners entsprechende Prozesse (z.B.
Authentifizierung, Versand von neuen Sicherheitsvorgaben und/oder
Verschlüsselungsdaten,
etc.) für
eine sichere Kommunikationsverbindung angestoßen werden, weil beispielsweise
die Gültigkeitsdauer
der am Klientenrechner hinterlegten Sicherheitsvorgaben und/oder Verschlüsselungsdaten
abläuft,
kann Kommunikation zwischen Server und Klientenrechner über die
gesicherte Kommunikationsverbindung wieder beginnen. D.h. die über die
gesicherte Kommunikations verbindung übertragenen Daten werden erst
dann wieder vom Server erkannt.
-
Da
allerdings beispielsweise bei IPSec die Gültigkeitsdauer der Phase1 SAs,
in welchen Sicherheitsvorgaben wie z.B. Identifikation eines Rechners, angewendetes
Verschlüsselungsverfahren,
etc. definiert werden, relativ lang sein kann (z.B. bis 24 Stunden),
können
dadurch nach dem Re-Boot eines Servers lange Kommunikationslücken auftreten.
Ist die Gültigkeitsdauer
der Phase1 SA z.B. von der übertragenen
Datenmenge abhängig,
so kann es passieren, dass durch einen Server-Re-Boot diese SA auf
Seiten des Klientenrechners nicht mehr ungültig wird und die Prozesse
für eine
sichere Kommunikationsverbindung vom Klientenrechner daher nicht
mehr angestoßen
werden können.
-
Eine
Möglichkeit,
das zu verhindern, wäre beispielsweise
nach einem Re-Boot des Server auch ein Rücksetzen der bestehenden SAs
auf dem/den Clients oder überhaupt
einen Re-Boot des/der Clients durchzuführen, da dann die entsprechenden Prozesse
für den
Aufbau einer sicheren Kommunikationsverbindung von Seiten des bzw.
der Clients angestoßen
werden würden.
Allerdings ist diese Vorgehensweise sehr aufwendig und setzt voraus,
dass der bzw. die Clients über
jeden Re-Boot des Servers informiert sind.
-
Eine
weitere Möglichkeit
für einen
Klientenrechner festzustellen, ob eine sichere Kommunikationsverbindung
noch aktiv ist, ist beispielsweise die so genannte Dead Peer Detection
DPD, welche z.B. bei IPSec insbesondere beim Tunnel-Modus eingesetzt
wird. Bei der DPD werden zwischen Server und Klientenrechner regelmäßig Status-Meldungen
ausgetauscht, durch die festgestellt wird, ob die Kommunikationsverbindung
noch aktiv ist. Wenn während
einer Zeitbeschränkung
zur DPD-Meldung keine Antwort erhalten wird, wird die Kommunikationsverbindung
(z.B. IPSec-Tunnel) geschlossen, bis sie wieder durch neue Datenübertragung
aktiviert wird. Die DPD muss für
ihren Einsatz allerdings sowohl beim Server als auch beim Klientenrechner
aktiviert sein. Da DPD aber derzeit nicht standardisiert ist, ist
DPD nicht auf allen Rechnersystemen implementiert und damit verfügbar. Außerdem werden
bei DPD durch ein regelmäßiges Versenden
von Status-Meldungen zusätzlich
Datenverkehr und Verwaltungsdaten generiert.
-
Aus
der Schrift
US
2001/0056492 A1 ist ein Verfahren bekannt, welches zur
Aufrechterhaltung von Verbindungen zwischen Rechnern, beispielsweise
Server und Klientenrechnern, durch Versand einer Nachricht eingesetzt
wird. Dabei werden ein oder mehrere Elemente dieser Nachricht gespeichert
und bei einem Fehler des Servers dazu eingesetzt, einen Verbindungsstatus
wie vor dem Ausfall wiederherzustellen. Dabei bezieht sich das in
der Schrift
US 2001/0056492
A1 offenbarte Verfahren auf Prozesse wie Server und Klientenprozesse,
welche von unterschiedlichen Rechnern ausgeführt werden und über ein
Verbindung miteinander kommunizieren. Es wird vor allem dazu eingesetzt,
Verbindungen für
Prozesse offen zu halten, wenn ein z.B. abgestützter Prozess wieder hochgefahren
wird. Von einem z.B. Klienten-Prozess, welcher über eine Verbindung mit dem
abgestützten
Prozess verbunden ist, wird der Absturz nicht festgestellt und dadurch
Datenverluste verhindert. Damit ist das in der genannten Schrift
beschriebenen Verfahren zwar geeignet, negative Effekt durch Prozessabstürze (z.B.
Datenverluste, etc.) zu verhindern, aber mittels diesem Verfahren
ist es nicht möglich,
ohne Zeitverzögerung
durch Authentifizierungsprozesse aufgebaute, sichere Kommunikationsverbindung
zwischen einen Server und Klientenrechnern, welche durch eine Neustart
des Servers unterbrochen worden sind, wiederaufzubauen.
-
Der
vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren
anzugeben, durch welches auf einfache Weise nach einem Re-Boot bzw.
Neustart eines Server von diesem Server aus Prozesse für eine Wiederaktivierung
einer sicheren Kommunikationsverbindung zwischen Server und Klientenrechnern
gestartet werden.
-
Die
Lösung
der Aufgabe erfolgt durch ein Verfahren der eingangs erwähnten Art,
wobei nach dem Neustart des Servers ein Datenpaket an die Adressen
der Klientenrechner versendet wird, wobei vom Server anhand der
Adressen der Klientenrechner versendet wird. Anhand der Adressen
der Klientenrechner wird vom Server erkannt, dass für die Übertragung
des Datenpaketes eine sichere Kommunikations-verbindung vorgesehen
ist, welche durch den Neustart des Servers unterbrochen worden ist,
und durch den Versand dieses Datenpakets werden Prozesse für eine Wiederaktivierung
der sicheren Kommunikationsverbindungen zwischen Server und den
Klientenrechnern ausgelöst.
-
Die
mit der Erfindung erzielten Vorteile bestehen insbesondere darin,
dass eine Wiederaktivierung der sicheren Kommunikationsverbindungen
auf einfache Weise direkt nach dem Neustart des Server ausgelöst wird,
wodurch eventuelle Kommunikationsausfälle zwischen Server und Klientenrechner kurz
gehalten werden. Ein weiterer Vorteil besteht darin, dass die sichere
Kommunikationsverbindung zwischen Server und Klientenrechnern bereits
bei einem Hochlaufen des Servers aktiviert wird und damit die Zeitdauer
für das
Hochlaufen kurz gehalten wird. Außerdem wird durch das erfindungsgemäße Verfahren kein
zusätzlicher
Verwaltungsaufwand am Server generiert.
-
Es
ist günstig,
wenn die gesicherte Kommunikationsverbindung zwischen Server und
Klientenrechnern gemäß Internet
Protocol Security IPSec nach RFC 2401 und/oder RFC 4301 der IETF
erfolgt, da IPSec von der IETF in mehreren RCF – wie beispielsweise dem RFC
2401 oder dem RFC 4301 als Hauptdokument – standardisiert worden ist.
Außerdem
werden in weiteren RFCs (z.B. RFC 2402, RFC 4302, RFC 2406, RFC
2408, RFC 4306, etc.) von der IETF Mechanismen wie z.B. IP-Authentication Header
Mechanismus, Encapsulation-Security-Payload etc. und Protokolle wie z.B.
ISAKMP, etc. für
IPSec definiert.
-
Eine
bevorzugte Weiterbildung der Erfindung sieht vor, dass das Datenpaket
von einer so genannten Startup-Software, welche am Server zwischen Ablauf
einer Betriebssystem-Software
und einer Anwendung ausgeführt
wird, versendet wird, wobei die Start-Up-Software ein Teil der so
genannten Middelware-Software ist, von welcher zwischen Betriebsystem-Software und Anwendungen
vermittelt wird und welche daher vor dem Start einer Anwendung ausgeführt wird.
Daher ist vorteilhafterweise eine sichere Kommunikationsverbindung
bereits vor dem Start einer Anwendung, von welcher eine sichere
Kommunikationsverbindung zwischen Server und Klientenrechnern vorausgesetzt
wird, aktiviert und die Zeitdauer für ein Hochlaufen wird damit
kurz gehalten.
-
Vorzugsweise
wird das Datenpaket an alle Adressen von Klientenrechnern versendet,
für welche
am Server eine sichere Konfigurationsverbindung konfiguriert worden
ist, wobei diese Adressen für
einen Versand des Datenpaketes beispielsweise bei IPSec aus der
so genannten Internet Key Exchange-Policy-Datei ausgelesen werden können. In dieser
Datei werden z.B. bei IPSec jene Adressen von Klientenrechnern administriert,
zu welchen eine sichere Kommunikationsverbindung aufgebaut werden
soll. Da diese Konfigurationsdaten bereits am Server vorhanden sind,
ist daher kein zusätzlicher Verwaltungsaufwand
für den
Versand des Datenpaketes zur Wiederaktivierung einer sicheren Kommunikationsverbindung
notwendig.
-
Bei
einer bevorzugten Fortbildung der Erfindung wird das Datenpaket
an die Adressen jener Klientenrechner versendet, für welche
bis zum Neustart eine gültige,
sichere Kommunikationsverbindung vorgesehen war, wobei idealerweise
diese Adressen vom Server beispielsweise vor dem Neustart oder bei einem
erstmaligen Aufbau einer sicheren Kommunikationsverbindung zu diesem
Klientenrechner in einer Datei abgespeichert werden können. Diese
Variante des erfindungsgemäßen Verfahrens
ist insbesondere dann sinnvoll, wenn bei der Konfiguration der Adressen
für sichere
Kommunikationsverbindungen z.B. in der Internet Key Exchange-Policy-Datei bei
IPSec nicht die einzelnen Adressen der Klientenrechner, sondern
nur so genannte Adressbereiche administriert sind. Dadurch wird
ein großer
Datenlast durch das Versenden des Datenpakets an alle administrierten
Adressen bzw. Adressbereiche auf einfache Weise vermieden, insbesondere
dann, wenn nicht zu allen administrierten Klientenrechnern vor dem
Neustart eine sichere Kommunikationsverbindung bestanden hat, weil
z.B. Klientenrechner gerade nicht eingeschaltet sind.
-
Außerdem ist
es zweckmäßig, wenn
ein Datenpaket gemäß dem User
Datagram Protocol UDP zum Auslösen
der Prozesse für
die Wiederaktivierung der gesicherten Kommunikationsverbindung gesendet
wird, da UDP im RFC 768 von der IEFT standardisiert worden ist und
ein minimales, verbindungsloses Protokoll zum Transport von Datenpaketen
auf der so genannten Transportschicht darstellt. Außerdem ist
UDP im Vergleich zu anderen Protokollen der Transportschicht wie
z.B. TCP schneller und verfügt über eine
geringere Länge
der Datenpakete, wodurch der durch den Versand der Datenpakete generierte
Datenverkehr gering gehalten wird.
-
Es
ist außerdem
vorteilhaft, wenn beim Datenpaket gemäß UDP-Protokoll als Zielportnummer eine vergleichsweise
hohe Portnummer wie z.B. die Portnummer 33434, etc. mitgeschickt
wird. Da die hohen Portnummern beispielsweise nicht von Anwendungen
genutzt und daher nicht belegt sind, wird das UDP-Paket, wenn es
von einem Klientenrechner empfangen wird, üblicherweise nicht beachtet.
Vom UDP-Paket wird aber trotzdem das Auslösen der Prozesse zur Wiederaktivierung
der sicheren Kommunikationsverbindung erfüllt, da diese Prozesse nur durch
den Versand am Server gestartet werden.
-
Weiteres
ist es wichtig, dass für
das erfindungsgemäße Verfahren – insbesondere
in Verbindung mit IPSec – so
genannte „shared
Security Associations (SAs) verwendet werden. Bei shared SAs werden
nicht für
jedes verwendete Protokoll und für jede
Portnummer eigene SAs generiert. Da durch shared SAs eine Generierung
zusätzlicher
Daten auf dem Server bzw. den Klientenrechnern vermieden wird, werden
shared SAs üblicherweise
häufig
eingesetzt.
-
Die
Erfindung wird nachfolgend in beispielhafter Weise anhand der beigefügten Figur
erläutert. Es
zeigt 1 schematisch den Ablauf des erfindungsgemäßen Verfahrens
zur Wiederaktivierung einer sicheren Kommunikationsverbindung.
-
Das
erfindungsgemäße Verfahren
wird beispielhaft für
ein IP-basiertes
Client-Server-System, von welchem IPSec als Sicherheitsverfahren
eingesetzt wird, beschrieben. Das erfindungsgemäße Verfahren ist allerdings
auch für
andere (nicht IP-basierte) Client-Server-Systeme bzw. bei Einsatz
anderer Sicherheitsverfahren für
Kommunikationsverbindungen anwendbar.
-
Das
Verfahren beginnt mit einem Startschritt 1. In einem zweiten
Verfahrenschritt 2 wird ein Neustart bzw. ein Re-Boot eines
Servers eines IP-basierten Client-Server-Systems, von welchem für sichere Kommunikationsverbindungen
IPSec eingesetzt wird, durchgeführt.
Durch den Re-Boot werden alle aktiven sicheren Kommunikationsverbindungen
auf der Seite des Servers inaktiviert – d.h. die für diesen Kommunikationsverbindungen
bestehenden Phase1 und Phase2 Security Associations verlieren durch den
Re-Boot am Server ihre Gültigkeit
bzw. werden am Server verworfen.
-
In
einem dritten Verfahrenschritt 3 wird z.B. beim Ablauf
der Start-Up-Software, welche zwischen einer Betriebssystem-Software und Software
für Anwendungen
ausgeführt
wird, ein Versand eines Datenpakets gemäß dem User Datagram Protocol
UDP – eines
so genannten UDP-Datenpakets – initiiert.
-
In
einem vierten Verfahrensschritt 4 werden für den Versand
des UDP-Datenpakets Adressen von Klientenrechnern vom Server aus
einer Datei ausgelesen. Dazu können
beispielsweise bei IPSec eine so genannte IKE-Policy-Datei oder
in der Security Policy Database SPD hinterlegte Daten verwendet
werden, wenn z.B. das UDP-Datenpaket an alle Klientenrechner, für die eine
sichere Kommunikationsverbindung am Server konfiguriert worden ist, versendet
werden soll. Soll das UDP-Datenpaket nur an jede Klientenrechner
gesendet werde, zu denen vor dem Neustart tatsächlich eine sichere, aktive Kommunikationsverbindung
bestanden hat, so können
die Adressen dieser Klientenrechner in einer eigenen Datei am Server
hinterlegt werden und diese Datei wird dann für den Versand des UDP-Datenpakets herangezogen.
-
Anhand
der Adressen der Klientenrechner bzw. da diese Adressen z.B. in
der Security Policy Database SPD oder der IKE-Policy-Datei eingetragen
sind, wird in einem fünften
Verfahrensschritt 5 vom Server festgestellt, dass die Übertragung
des UDP-Datenpakets an diese Klientenrechner über ein sichere Kommunikationsverbindung
durchgeführt werden
muss. In einem sechsten Verfahrensschritt 6 wird daher
vom Server beispielsweise bei IPSec eine Phase1 Security Association
SA mit den entsprechenden Klientenrechnern aufgebaut. In dieser Phase1
SA werden die so genannten ISAKMP-Daten (z.B. Identifikation eines
Rechners, angewendetes Verschlüsselungsverfahren,
etc.) für
eine geschützte Übertragung
definiert.
-
In
einem siebenten Verfahrensschritt 7 wird die neue Phase1
SA, welche vom Server aufgebaut worden ist, von den entsprechenden
Klientenrechnern erkannt. Von den Klientenrechnern werden daraufhin
eventuell noch vorhandene SAs für
sichere Kommunikationsverbindungen mit dem Server verworfen und
die neue Phase1 SA verwendet.
-
In
einem achten Verfahrenschritt 8 wird dann beispielsweise
bei IPSec – entsprechend
der Zweistufigkeit dieses Sicherheitsverfahrens – vom Server eine neue Phase2
SA mit den Klientenrechnern aufgebaut, in welcher z.B. die Verschlüsselung
der zu übertragenden
Daten festgelegt wird. Von den Klientenrechnern wird daraufhin auch
die neue Phase2 SA verwendet.
-
Durch
den Aufbau neuer Phase1 und Phase2 SAs durch den Server wird z.B.
bei IPSec eine sichere Kommunikationsverbindung zu einem Klientenrechner
in einem neunten Verfahrensschritt 9 wieder aktiviert.
In einem zehnten Verfahrensschritt 10 kann dann das UDP-Datenpaket
gemäß dem eingesetzten
Sicherheitsverfahren und dessen Mechanismen (z.B. IPSec) verschlüsselt an
die jeweiligen Klientenrechner übertragen
werden. Dabei wird beim UDP-Datenpaket beispielsweise eine hohe
Portnummer wie z.B. die Portnummer 33434 als Zielportnummer eingetragen,
da es unerheblich ist, ob das UDP-Datenpaket tatsächlich von
den Klientenrechnern empfangen wird. Wird das UDP-Datenpaket von einem
Klientenrechner empfangen, so wird es wegen der hohen Portnummer
z.B. nicht weiter beachtet oder verworfen und von Klientenrechner
wird beispielsweise eine Antwort, dass die Zielportnummer nicht
erreichbar ist, an den Server gesendet.
-
Da
allerdings die sichere Kommunikationsverbindung zwischen dem Server
und den entsprechenden Klientenrechner durch das erfindungsgemäße Verfahren
auf einfache und rasche Weise wieder aktiviert worden ist, können danach
Daten wieder gesichert und z.B. verschlüsselt über diese Kommunikationsverbindung übertragen
werden.