DE19952527C2 - Verfahren und Transaktionsinterface zum gesicherten Datenaustausch zwischen unterscheidbaren Netzen - Google Patents

Description

Die Erfindung betrifft ein Verfahren und Transaktionsinter­ face zum gesicherten Austausch zwischen unterscheidbaren Netzen, insbesondere zwischen einem externen und einem in­ ternen Netz, wie beispielsweise dem Internet und einem fir­ meneigenen Intranet.

Derartige Verfahren und Vorrichtungen zum gesicherten Aus­ tausch zwischen Netzen mit vorzugsweise unterschiedlichen Sicherheitsstandards gehören zum Stand der Technik.

So gehört es zum Stand der Technik, ein internes Datennetz vom externen Netz durch eine sogenannte gesicherte Schnitt­ stelle zu trennen. Die gesicherte Schnittstelle umfaßt da­ bei im besten Falle einen externen und einen internen Ser­ ver, die über eine Firewall miteinander in Datenverbindung stehen. Etwaig vom externen Server aufgenommene Kundenan­ fragen werden im externen Server verarbeitet und nach un­ terschiedlichen Sicherheitschecks über die Firewall an den internen Server gegeben, der schließlich auf die innerhalb des zu schützenden internen Netzes abgelegten Daten zu­ greift.

Die zwischen dem internen und externen Server befindliche Firewall soll dabei verhindern, daß von außen, insbesondere mißbräuchliche Transaktionen oder Veränderungen am ge­ schützten Datenbestand des inneren Netzes möglich sind.

Die Firewall verhindert im Ergebnis, daß externe Kunden oh­ ne entsprechende Berechtigung in eine Datenverbindung mit dem internen Netz treten und daß bei bestehender Datenver­ bindung unzulässige Daten, beispielsweise Virenprogramme durch die Firewall in das interne Netz eingespeist werden. Hierdurch werden zum Beispiel bei fehlender Berechtigung auch an sich zulässige wünschenswerte Kundendienstabfragen die interne Datentransaktionen erfordern, abgeblockt.

Eine übliche Lösung hierfür, besteht in der Öffnung eines zusätzlichen speziellen Kunden-Gateways, der einen entspre­ chenden Zugriff erlaubt. Dies hat wiederum den Nachteil, daß über dieses zwar besonders gesicherte Gateway nun doch Angriffe auf den internen Datenbestand möglich sind.

Eine andere Lösung beläßt alle etwaigen Kundenfragen auf dem externen Server und vermeidet somit etwaig unerwünschte gefährliche direkte Datenverbindungen nach außen. Nachtei­ lig bei dieser Lösung ist aber, daß etwaig vertrauliche Kundendaten auf einem ungeschützten externen Server zwi­ schengespeichert werden. Aus diesem Grund werden die Daten durch Spiegelung häufig abgeglichen. Dies wird infolge der dadurch wachsenden Datenmenge mit einer erhöhten Prozessor­ leistung bzw. einem schlechteren Zeitverhalten bezahlt. Au­ ßerdem ist bei dieser Lösung ein Zugriff in Echtzeit auf den geschützten Datenbestand des internen Netzes kaum mög­ lich.

Aus der internationalen Anmeldung WO 97/16911 A1 ist zur Lösung dieser Probleme ein sogenanntes "Securite-Gateway- Interface" (SGI) bekannt, das die beschriebenen Probleme dadurch zu lösen versucht, daß aufgrund einer Kundenanfrage zunächst eine Authentikation des Kunden erfolgt und im Fal­ le einer entsprechende Berechtigung des Kunden generiert der externe Server dann anhand der Kundenabfrage eine eige­ ne zulässige Abfrage. Zwar ist durch diesen Stand der Tech­ nik eine Authentifizierung des Übertragungskanals vom ex­ ternen Netz zum internen Netz gegeben, aber nach Herstel­ lung dieses gesicherten Kanals erfolgt aktiv ein Zugriff vom externen Netz auf das interne Netz des zu sichernden Systems. Hierzu müssen zwangsläufig geschützte Daten, bei­ spielsweise die Adressierung der angefragten internen Daten nach außen bekannt gemacht werden, die mißbraucht werden können. Dabei sind diese Daten als solche zur Beantwortung der Kundenabfrage nicht notwendig. Grundsätzlich stellt je­ der aktive Zugriff von außen nach innen ein Sicherheitsri­ siko dar.

Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfah­ ren und eine Vorrichtung zum gesicherten Datenaustausch zwischen unterscheidbaren Netzen zu schaffen, das bzw. die eine vollständige Entkopplung der beiden Netze sicherstellt und überdies die erwähnten Nachteile des vorbekannten Standes der Technik vermeidet.

Diese Aufgabe wird durch ein Verfahren zum gesicherten Da­ tenaustausch gemäß Anspruch 1 und ein Transaktionsinterface gemäß Anspruch 15 gelöst.

Dadurch, daß im Unterschied zum Stand der Technik, sämtli­ che Abfragen externer Nutzer von einem Schnittstellenserver aufbereitet und in definierter Form in einem Schnittstel­ lenspeicher zwischengespeichert werden, die vollständige Bearbeitung dieser Abfragen einschließlich der Authentika­ tion des Nutzers aber innerhalb des gesicherten internen Netzes erfolgt, ist keinerlei Zugriff von außen auf sicher­ heitsrelevante Datenbereiche des internen Netzes möglich.

Vorteilhafte Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen 2 bis 14.

Gemäß Anspruch 2 wird die im Schnittstellenspeicher ange­ legte Warteschlange ausschließlich vom inneren Server in einer definierten Frequenz abgefragt. Es ist demnach nicht möglich, aktiv von einem externen Netz aus irgendeine Da­ tentransaktion im inneren Netz auszulösen, da sämtliche Ak­ tionen vom gesicherten Bereich des inneren Netzes ausgehen und auch von hier initiiert werden und schließlich voll­ ständig hier abgewickelt werden. Hierzu zählt insbesondere auch die Authentikation des Nutzers.

Das Sicherheitslevel des Verfahrens kann durch Verwendung einer äußeren Firewall zwischen der neutralen Zone und dem vorgeschalteten externen Netz weiter gesteigert werden. Au­ ßerdem ist hierdurch der mißbräuchliche Zugriff auf in der neutralen Zone abgelegte Daten erschwert, auch wenn diese Daten an sich nicht sicherheitsrelevant sind.

In diesem Sinn wird eine weitere Steigerung des Sicherheit­ standards durch Zwischenschaltung einer weiteren inneren Firewall zwischen der neutralen Zone und dem internen Netz erreicht. Die innere Firewall stellt auch einen wirksamen Schutz gegen die Spionage von innen, also den Zugriff vom internen Netz auf in der neutralen Zone abgelegten Nutzer­ daten sicher.

Die innere Firewall erzwingt eine ausschließlich unidirek­ tionale Kommunikation. Dabei werden Aufrufe grundsätzlich nur aus dem Bereich des internen Netzes akzeptiert. Ein Aufruf aus der neutralen Zone in den Bereich des gesicher­ ten internen Netzes ist nicht möglich.

Die Nutzerabfragen können in unterschiedlichen Datenforma­ ten eingehen. Hierzu kann es sinnvoll sein, in der neutra­ len Zone einen speziellen externen Server vorzusehen, der für bestimmte ausgewählte Datenformate zuständig ist und die hier eingehenden Nutzerabfragen vor der Weiterleitung an den eigentlichen Schnittstellenserver zunächst konver­ tiert und ggf. eine Eingangsbestätigung an den Nutzer über­ mittelt.

Dadurch, daß einmal in der Warteschlange des Schnittstel­ lenspeichers aufgenommene Abfragen bis zu ihrer vollständi­ gen Abarbeitung resistent zwischengespeichert werden, kann die Bearbeitung selbst nach einem vollständigen Systemab­ sturz im wesentlichen ohne Datenverlust wieder aufgenommen werden. Schlimmstenfalls muß die Bearbeitung der Abfrage wiederholt werden. Hierdurch ist das erfindungsgemäße Ver­ fahren in höchstem Maße störsicher. Dies stellt sowohl eine Maßnahme der Datensicherheit als auch der Bedienerfreund­ lichkeit dar.

Ein weiteres Leistungsmerkmal des erfindungsgemäßen Verfah­ rens besteht darin, daß die Bearbeitungsgeschwindigkeit an die jeweilige Last angepaßt werden kann. Dies geschieht ge­ mäß Anspruch 7 zum einen durch lastabhängige Frequenzsteue­ rung der Abfragen des Schnittstellenspeichers.

Dies kann aber auch mit Vorteil durch das Aktivieren von parallelen Prozessen innerhalb des Schnittstellenservers und/oder des inneren Servers erfolgen. Die Laststeuerung wird dabei mit von dem externen Server des Systems oder mittels eines Laststeuerungsmoduls der Firewall durchge­ führt. Dies macht insoweit Sinn, weil die Laststeuerung hierdurch an Stellen angeordnet ist, die in Zugriffsrich­ tung vor dem Schnittstellenserver und/oder innerem Server liegen und somit die erforderlichen Prozessorkapazitäten bereitstellen können bevor sie benötigt werden. Hierdurch wird ebenfalls die Bedienfreundlichkeit des Systems erhöht.

Neben der softwaremäßigen Zuschaltung und Aktivierung wei­ terer Prozesse können auch zusätzliche Prozessoraktivität­ ten gemäß Anspruch 10 durch eine entsprechende Laststeue­ rung freigegeben oder gesperrt werden.

Die im Schnittstellenspeicher abgelegten Nutzerabfragen werden mit Vorteil verschlüsselt. Die Verschlüsselung die­ ser Abfragen erschwert den Zugriff von außen aber auch von innen auf etwaig vertrauliche Nutzerabfragen. Hierdurch wird ebenfalls sowohl der Spionage von außen als auch von innen vorgebeugt.

Ein vorteilhaftes Verschlüsselungsverfahren ist gemäß An­ spruch 12 gegeben. Hierbei ist ein besonderes Sicherheits­ merkmal durch die individuell vorbestimmbare Lebensdauer der jeweils eingesetzten Schlüssel gegeben. Dies bedeutet, daß selbst falls es einem mißbräuchlich Zugreifenden gelingen sollte, einen eingesetzten Schlüssel zu entschlüsseln, so ist hierdurch längst nicht sichergestellt, daß er einen erfolgreichen Mißbrauch oder gar eine Datentransaktion durchführen kann, da der mit der Schlüsselvergabe definier­ te Zeitkorridor so eng bemessen ist, daß eine mißbräuchli­ che Zweitverwendung des Schlüssels schon aufgrund seiner begrenzten Lebensdauer so gut wie ausgeschlossen erscheint.

Ein weiteres wesentliches Sicherheitssmerkmal des Verfah­ rens liegt darin, daß die Authentikation des jeweiligen Nutzers von der eigentlichen Bearbeitung getrennt erfolgt.

Entscheidend ist gemäß Anspruch 14, daß obwohl die Authen­ tikation des Nutzers vollständig im gesicherten Bereich des internen Netzes vorgenommen wird, zu keinem Zeitpunkt das einem Nutzer jeweils zugeordnete Passwort von der neutralen Zone in das interne Netz oder in umgekehrter Richtung über­ mittelt wird.

Das Verfahren wird vorteilhaft mit einem Transaktionsinter­ face gemäß dem unabhängigen Anspruch 15 durchgeführt.

Vorteilhafte Weiterbildungen der erfindungsgemäßen Vorrich­ tung ergeben sich aus den Unteransprüchen 16 bis 27.

Das Sicherheitsniveau der erfindungsgemäßen Vorrichtung kann gemäß Anspruch 16 oder 17 durch Verwendung einer inne­ ren und/oder äußeren Firewall weiter erhöht werden.

Die Bedienfreundlichkeit und Anwendungsbreite des Transak­ tionsinterfaces kann durch einen zusätzlichen externen Ser­ ver, der in der neutralen Zone angeordnet ist, erhöht sein.

Bei dem erfindungsgemäßen Transaktionsinterface kann zu ei­ ner besseren Lastanpassung auch der Schnittstellenspeicher selbst durch eine entsprechende Skalierung an die jeweilige Last angepaßt werden.

Ebenfalls einer besseren Lastansteuerung dient die Anord­ nung mehrerer Netzwerkrechner innerhalb der neutralen Zone.

Aus dem gleichen Grund können auch mehrerer Netzwerkrechner im Bereich des internen Netzes angeordnet sein.

Dadurch, daß das erfindungsgemäße Transaktionsinterface mit einer CORBA-Schnittstelle versehen ist, können im Bereich des internen Netzes unterschiedliche Betriebssysteme zusam­ menarbeiten und über das erfindungsgemäße Transaktionsin­ terface geschützt sein.

In besonders vorteilhafter Ausgestaltung ist das gesamte Transaktionsinterface mit einer durchgehenden CORBA-BUS- Architektur versehen.

Die Kommunikation innerhalb des Transaktionsinterface wird mit Vorteil verschlüsselt abgewickelt, vorzugsweise DES- verschlüsselt.

Dadurch, daß gemäß Anspruch 25 vor der Bearbeitung entspre­ chender Nutzerabfragen eine Bestätigungsanfrage an den Nut­ zer übermittelt werden kann, ist das Transaktionsinterface zum korrekten Vertragsabschluß innerhalb des Internets in der Lage. Die hierdurch erlangte nochmalige Bestätigung der Nutzerabfrage oder des Vertrages stellt einen einwandfreien Vertragsschluß im Bereich des e-commerce sicher.

Der gesamte Betrieb des Transaktionsinterfaces wird mittels eines entsprechenden Logging-Moduls innerhalb eines soge­ nannten Logging-Protokolls aufgezeichnet. In diesem Log­ ging-Protokoll sind sämtliche Transaktionen und Informationen, wie etwa die Verweildauer der jeweiligen Nutzerabfra­ gen in der Warteschlange, die ID der Nutzer u. ä., verzeich­ net.

Hierdurch ist es einem Administrator möglich, den Betrieb zu überwachen, etwaige Fehlfunktionen frühzeitig aufzuspü­ ren und insbesondere etwaige Mißbrauchsversuche zu entdec­ ken.

Die Erfindung wird nachstehend anhand eines oder mehrerer in der Zeichnung nur schematisch dargestellten Ausführungs­ beispiele näher erläutert. Es zeigen:

Fig. 1 ein Blockschaltbild zum Aufbau des Transak­ tionsinterfaces,

Fig. 2 ein Laufdiagramm zum Verfahren des gesicher­ ten Datenaustausches und

Fig. 3 ein Blockschaltbild zum Verfahrensablauf,

Fig. 1 zeigt ein externes Netz 1 und ein internes Netz 2, die über ein Transaktionsinterface 3 miteinander in Daten­ verbindung treten können.

Beim externen Netz 1 handelt es sich zumeist um das Inter­ net, wobei als internes Netz 2 das Intranet eines Unterneh­ mens, häufig ein LAN-Netzwerk, in Frage kommt. Das Transak­ tionsinterface 3 ist streng genommen nicht abgeschlossen zwischen beiden Netzen angeordnet.

Im Prinzip beginnt der gesicherte Datenaustausch bereits innerhalb des externen Netzes 1 und führt schließlich im Ergebnis zu Transaktionen innerhalb des internen Netzes 2, die anhand der gestrichelten Linie in Fig. 1 verdeutlicht werden soll.

Im übrigen weist das Transaktionsinterface 3 eine äußere Firewall 4 zur Abschottung einer neutralen Zone 5 gegenüber dem externen Netz 2 auf.

Die neutrale Zone 5 ist wiederum gegenüber dem internen Netz 2 durch eine weitere innere Firewall 6 abgeschottet. Die in Fig. 1 symbolisch dargestellten Pfeile symbolisierer nur die Wechselwirkung zwischen den, gegeneinander abge­ grenzten Bereichen und nicht etwa Datenflußrichtungen.

Die neutrale Zone 5 umfaßt einen Schnittstellenserver 7 so­ wie einen externen Server 10. Beim externen Server 10 wird es sich in den allermeisten Fällen um einen üblichen Web- Server handeln. Darüber hinaus ist in der neutralen Zone ein Schnittstellenspeicher 11 vorzugsweise als Bestandteil des Schnittstellenservers 7 vorgesehen. Der Schnittstellen­ server 7 steht über die innere Firewall 6 mit einem inneren Server 12, der bereits innerhalb des gesicherten Bereichs des internen Netzes 2 angeordnet ist, in Datenverbindung. Der innere Server 12 ist über eine CORBA-Schnittstelle mit einem oder mehreren Netzservern oder vorzugsweise verteilten Datenbankanwendungen 15 über einen CORBA-BUS verbunden. Der CORBA-BUS stellt ein offenes Bus-System dar, das sich dadurch auszeichnet, daß unterschiedlichste Systeme also auch unterschiedliche Betriebssysteme über diesen CORBA-BUS miteinander kommunizieren können.

So können beispielsweise Unix- oder Windows-Betriebs­ systeme, Gebäudesteuerungssysteme oder Sun-Workstations über denselben CORBA-BUS angesprochen werden.

Die genannte CORBA-Bus-Architektur wird in bevorzugter Aus­ führung für den gesamten Datenaustausch innerhalb des Transaktionsinterfaces 3 eingesetzt.

Der genaue Ablauf des Verfahrens zum gesicherten Datenaus­ tausch aufgrund einer Nutzerabfrage, eines sogenannten Re­ questes, aus dem externen Netz 1 wird nachstehend ausführ­ lich anhand Fig. 2 und 3 erläutert:
Ein externer Nutzer 17 kann sich über das HTP-Protokoll des Internet, beispielsweise ein HTML-Formular zum Datenaus­ tausch mit dem internen Netz 2 beschaffen. Er hat dann Ge­ legenheit, seine Anfrage innerhalb dieses HTML-Formulares zu formulieren. Die Verwendung des HTML-Formulares ist not­ wendig, weil innerhalb des hier beschriebenen Verfahrens des gesicherten Datenaustausches nur vorbestimmte zulässige Datentransaktionen möglich sind. Insoweit ist durch die Verwendung von HTML-Formularen sichergestellt, daß auch nur diese vorbestimmten Abfragen von den externen Nutzern 17 formuliert werden. Das HTML-Formular wird dann über ein Client-Interface 20, beispielsweise eine Java-Konsole ver­ schlüsselt durch das Internet übertragen und gelangt, so­ fern der externe Nutzer 17 über die entsprechenden Berech­ tigungen bzw. Paßworte verfügt, über eine externe Firewall 4 auf den externen Server 10, der innerhalb der neutralen Zone 5 angeordnet ist. Bei dem externen Server 10 handelt es sich im hier vorliegenden Falle um einen Web-Server. Das Transaktionsinterface 3 kann im Rahmen der Erfindung auch mit anderen Datenformaten, wie etwa RMI, in Datenverbindung treten. So kann der Austausch auch mittels älterer Browsertypen oder mit anderen Netzformaten aus dem Internet abge­ wickelt werden.

Derartige Abfragen werden dann nicht über den externen Ser­ ver 10 abgewickelt, sondern gelangen direkt auf den Schnittstellenserver 7.

Dabei kann der Webserver 10 durchaus eine eigene Prozes­ soreinheit oder ein Modul des Schnittstellenservers 7 sein. Es muß sich dabei nicht unbedingt um eine abgeschlossene Rechnereinheit handeln. In dem in Fig. 3 dargestellten Aus­ führungsbeispiel besteht die neutrale Zone 5 im wesentli­ chen aus dem Schnittstellenserver 7, der eine ganze Reihe von Modulen aufweist.

Die gestrichelten Pfeillinien innerhalb von Fig. 3 stehen dabei für einen Aufruf, der eine Aktion an der aufgerufenen Stelle auslöst, und die durchgezogenen Pfeillinien für ei­ nen Datenfluß in Pfeilrichtung.

Nach Eingang im Webserver 10 wird die aus dem Internet 2 empfangene Abfrage zunächst entschlüsselt ausgelesen und schließlich an den Schnittstellenserver 7 übermittelt. Der Schnittstellenserver 7 weist ein Begrüßungsmodul 21 zur selbsttätigen Bestätigung des Eingangs bzw. zur Begrüßung des Nutzers 17 aus. Vor allem anderen wird eine Eingangsbe­ stätigung bzw. Begrüßung des externen Nutzers 17 über den Web-Server 10 und die äußere Firewall 4 an den Nutzer 17 zurückgegeben.

Je nach Abfrage ist zu diesem Zeitpunkt entschieden und dem Nutzer 17 mitgeteilt worden, ob eine synchrone oder asyn­ chrone Bearbeitung der eingegangenen Abfrage erfolgt. Bei einer synchronen Bearbeitung erhält der externe Nutzer noch in derselben Online-Sitzung das Ergebnis seiner Abfrage.

Im Unterschied hierzu wird bei einer asynchronen Bearbei­ tung das Ergebnis erst in einer nächsten Online-Sitzung oder in einem gesonderten Vorgang an den externen Nutzer übermittelt. Die Entscheidung, ob eine synchrone oder asyn­ chrone Bearbeitung erfolgt, richtet sich nach Mächtigkeit und Sicherheitsrelevanz der vom externen Nutzer 17 empfan­ genen Abfrage.

Der Schnittstellenserver 7 beginnt nun die empfangene An­ frage in unkritische Datenpakete zu zerlegen und in eine Warteschlange 22 bzw. 22 einzustellen, die in einem spezi­ ellen Schnittstellenspeicher 11 bzw. 11', der ebenfalls in­ nerhalb der neutralen Zone 5 angeordnet ist.

Dabei wird zumindest in dem hier vorliegenden Ausführungs­ beispiel zwischen einer Warteschlange 22 zur Authentikation des Nutzers 17 und einer Warteschlange 22' mit der eigent­ lichen Abfrage unterschieden. In der Regel wird es sich da­ bei um ein und dieselbe Warteschlange, jedoch unterscheid­ bare, Speicherbereiche handeln.

Eine herkömmliche Nutzerabfrage umfaßt u. a. auch die Nutzer ID und ein Passwort. Die Nutzer ID wird unter Verwendung des vom Nutzer 17 im Rahmen seiner Abfrage übermittelten Passwortes verschlüsselt in der Warteschlange 22 abgelegt.

Zur Authentikation des Nutzers 17 wird die jeweilige Nutzer ID auf Anfrage des inneren Servers 12 unter Überwindung der inneren Firewall 6, aber ansonsten unverschlüsselt, in den Bereich des internen Netzes 2 an ein Authentifikationsmodul 23 gegeben.

Innerhalb des Authentikationsmoduls 23 wird unter Verwen­ dung des im Bereich des internen Netzes 2 zu der jeweiligen Nutzer-ID abgelegten Passwortes die Nutzer-ID verschlüs­ selt und über die innere Firewall 6 verschlüsselt in die neutrale Zone 5 zurückgegeben.

In der neutralen Zone 5 wird dann mittels eines in der neu­ tralen Zone implementierten Authentikationsservices 24 des Schnittstellenservers 7 die jeweilige Nutzer-ID unter Ver­ wendung des vom Nutzer 17 eingegebenen Passwortes ent­ schlüsselt und die erhaltene Nutzer-ID mit der zwischenge­ speicherten Nutzer-ID verglichen.

Für den Fall, daß die beiden ID's übereinstimmen, wird die Bearbeitung fortgesetzt bzw. freigegeben, ansonsten erfolgt eine entsprechende Miteilung an den externen Nutzer 17.

Bevor die vom externen Nutzer 17 empfangene Abfrage in der entsprechend aufbereiteten Form in die Warteschlange 22' eingestellt wird, erfolgt eine Verifizierung der Abfrage. Es werden nur solche Datensätze in die Warteschlange einge­ stellt, die semantisch korrekt sind. Ansonsten wird die Be­ arbeitung abgebrochen und eine entsprechende Message über den Web-Server 10 an den externen Nutzer 17 abgegeben.

Darüber hinaus wird in der neutralen Zone 5 eine Bearbei­ tungsprotokoll 25 der aktuell laufenden Bearbeitungen ge­ führt.

Die im Schnittstellenspeicher 11 angelegte Warteschlange 22' wird in regelmäßigen Abständen vom inneren Server 12 auf etwaig vorhandene und noch zu bearbeitende Abfragen ge­ prüft.

Dies stellt sicher, daß unter keinen Umständen der Zugriff des externen Nutzers 17 irgendeine Aktivität innerhalb des geschützten internen Netzes 2 auslöst, sondern der Zugriff auf die in die Warteschlange 22' eingestellten Abfragen er­ folgt vielmehr selbsttätig von seiten des internen Servers 12. Dies ist ein wesentlicher Aspekt, um etwaige Manipula­ tionen zu verhindern.

Für den Fall, daß auf die vom inneren Server 12 veranlaßte Abfrage der Warteschlange 22' innerhalb der Warteschlange 22' noch abzuarbeitende Nutzerabfragen festgestellt werden, werden diese vom inneren Server 12 angefordert. Vor der Übermittlung der Anfrage an den inneren Server 12 erfolgt jedoch zunächst eine Verschlüsselung der Anfrage. Diese Verschlüsselung erfolgt nach dem Verfahren DES mit einer Schlüssellänge von 56 BIT. Selbstverständlich können auch andere Verschlüsselungsverfahren und Schlüssellängen einge­ setzt werden. Die eingesetzten Schlüssel werden in einem Schlüsselmanagement überwacht und permanent verändert.

Die Verschlüsselung erfolgt mittels eines bei der Konfigu­ ration des Systems erstellten Basisschlüssel, der eine asynchrone SSL-Verschlüsselung bewirkt. Im weiteren erfolgt dann unter Verwendung dieses Basisschlüssels eine synchrone DES-Verschlüsselung.

Insbesondere haben die eingesetzten Schlüssel nur eine in­ dividuell konfigurierbare Lebensdauer. Dies bedeutet, daß mit der Schlüsselvergabe ein schmaler Zeitkorridor zum ge­ sicherten Datenaustausch eröffnet wird. nach Ablauf der Le­ bensdauer kann der Schlüssel, selbst wenn es einer unbefug­ ten Person gelänge, ihn zu entschlüsseln, nicht mehr ge­ nutzt werden. Eine mißbräuchliche Zweitverwertung von Schlüsseln ist hierdurch nahezu ausgeschlossen.

Diese erneute Verschlüsselung der Abfrage vor der Übermitt­ lung an den inneren Server 12 dient in erster Linie dazu, ein Hacking von innen also ein Abhören vertraulicher Nutzerabfragen im Bereich des geschützten inneren Netzes 2 zu vermeiden.

Hierdurch beugt das beschriebene Verfahren im gesicherten Datenaustausch zusätzlich einer Spionage von innen vor. Die derart verschlüsselte Abfrage wird erneut hinsichtlich der Struktur, Inhalt und den Feldinhalten überprüft.

Für den Fall, daß die nunmehr erzeugte Abfrage sich als nicht zulässig erweist, wird an dieser Stelle die Weiterbe­ arbeitung abgebrochen und eine entsprechende Mitteilung an den externen Nutzer 17 übermittelt.

Für den Fall, daß die Abfrage weiter zulässig ist, also ei­ ner vorbestimmten Datenabfrage oder Transaktion entspricht, wird die betreffende Abfrage über die innere Firewall 6 des Transaktionsinterfaces 3 an den inneren Server 12 übermit­ telt. Die Datenbankabfrage kann je nach Sicherheitsrelevanz und Mächtigkeit auf einen oder mehreren Servern 12, 12' oder 12" unter Hinzuziehung von einer oder mehreren Datenbank­ anwendungen 15 abgearbeitet werden. Somit werden alle si­ cherheitsrelevanten Vorgänge im gesicherten Bereich des in­ ternen Netzes 2 abgewickelt.

Hierzu muß zunächst die am inneren Server 12 angelangte Ab­ frage vor der Weiterbearbeitung entschlüsselt werden.

Nach Bearbeitung der Anfrage erfolgt eine Ergebnisausgabe, die verschlüsselt über die innere Firewall 6 an den Schnittstellenserver 7 zurückgegeben wird. Der Schnittstel­ lenserver 7 führt dann eine sogenannte "Matching-Kontrolle" durch; d. h. es wird überprüft, ob das im Bereich des inter­ nen Netzes 2 erzeugte Ergebnis mit der Nutzerabfrage im Einklang steht. Falls dies nicht der Fall ist, wird eine Fehlermeldung an den externen Nutzer 17 übermittelt.

Sollte dies der Fall sein, wird das Ergebnis an den Web- Server 10 übermittelt, in ein geeignetes Format umgesetzt und schließlich über die äußere Firewall 4 an das Internet 1 an den externen Nutzer 17 übertragen. Somit ist eine vollständige Datentransaktion unter Verwendung des erfin­ dungsgemäßen Transaktionsinterfaces 3 beschrieben.

Das Transaktionsinterface 3 ist überdies mit einer dynami­ schen Laststeuerung versehen, die eine Anpassung des Trans­ aktionsinterfaces 3 an den jeweiligen "Traffic" ermöglicht. Zusätzlich kann, wie aus Fig. 3 deutlich wird, anhand des traffics eine lastabhängige Skalierung des Schnittstellen­ speichers 11' erfolgen. Dies wird in Fig. 3 durch die mög­ liche Vervielfältigung des mit dem Bezugszeichen 11' verse­ henen Bereiches dargestellt.

Dies bedeutet, daß der Schnittstellenserver 7 in Abhängig­ keit von der anstehenden Last die eingehenden Anfragen ent­ sprechend geschickt in die Warteschlange 11 bzw. 11' ein­ reiht und bedarfsweise weitere Prozesse also parallele War­ teschlangen 11' aktiviert, die parallel abgearbeitet werden können. Hierzu können innerhalb der neutralen Zone 5 auch mehrere Schnittstellenserver 7, 7' bzw. Serverbereiche vor­ gesehen sein, die je nach Last aktiviert werden. Die Last­ steuerung wird dabei entweder vom Web-Server 10 oder von einem Modul der äußeren Firewall 4 übernommen bzw. einem Laststeuerungsmodul 26 des Schnittstellenservers 7.

Das vorbeschriebene Lastmanagement wird vorteilhafterweise durch eine entsprechende Laststeuerung auch im Bereich des internen Netzes 2 unterstützt.

So können in Abhängigkeit von der anfallenden Last mehrere innere Server 12, 12' aktiviert oder gesperrt werden und zusätzliche Datenbankanwendungen 15 zur Bearbeitung der eingehenden Nachfrage im Bereich des internen Netzes 2 ak­ tiviert werden.

Hierbei ist es hilfreich, das gesamte Transaktionsinterface 3 mit einer durchgängigen CORBA-BUS-Architektur zu verse­ hen, so daß jeder Abfrage eine oder mehrere Serverprozesse zugeordnet werden können.

Der auf Seiten des internen Netzes 2 agierende innere Ser­ ver 12 ist hierzu mit einer CORBA-Schnittstelle verse­ hen.

Die im System eingesetzten inneren und äußeren Firewalls 4 und 6 können vollkommen herkömmliche Softwareprodukte sein. Der CORBA-Bus ermöglicht im übrigen auf Seiten des internen Netzes die Zusammenschaltung verschiedener Betriebssysteme wie Windows, NT oder Unix.

Die oben beschriebene spezielle Architektur des Transakti­ onsinterfaces 3 gestattet es, die im Zusammenhang mit einem wirksamen Vertragsschluß im Bereich des e-commerce erfor­ derlichen Mindestanforderungen zu erfüllen. So kann eine über den Web-Server 10 an den Schnittstellenserver 7 über­ mittelte Anfrage zunächst dahingehend überprüft werden, ob es sich um eine Vertragsanfrage handelt. Für den Fall, daß es sich um eine derartige Anfrage handelt, kann ein soge­ nanntes auf den Schnittstellenserver 7 angelegtes Vertrags­ modul vor der Weiterbearbeitung zunächst eine Bestätigungs­ anfrage an den externen Nutzer richten und erst im Falle, daß über den Web-Server 10 diese Bestätigung eingeht, eine Weiterbearbeitung wie oben beschrieben erfolgen.

Der Schnittstellenserver 7 ist darüber hinaus mit einem Logging-Modul versehen, das sämtliche Transaktionen des Transaktionsinterfaces 3 protokolliert. Hierdurch können sämtliche Prozesse ständig von einem Administrator über­ wacht und gegebenenfalls Fehlfunktionen oder Mißbrauchver­ suche sofort aufgedeckt werden.

Der Administrator sitzt ausschließlich im Bereich des in­ ternen Netzes 2. Die Konfiguration des Transaktionsinterfa­ ces kann nur von hier erfolgen.

Somit ist ein Verfahren und ein Transaktionsinterface 3 zum gesicherten Datenaustausch zwischen zwei unterscheidbaren Netzen 1, 2 gegeben, das bei vollständiger Entkopplung der Netze 1 und 2 mit einer hohen Performance arbeitet und ei­ nen Mißbrauch von außen wie von innen unmöglich erscheinen läßt.

BEZUGSZEICHENLISTE

1

externes Netz

2

internes Netz

3

Transaktionsinterface

4

äußere Firewall

5

neutrale Zone

6

innere Firewall

7

Schnittstellenserver

10

externer Server

11

Schnittstellenspeicher

12

,

12

',

12

" innerer Ser­ ver

15

Datenbankanwendung

17

externer Nutzer

20

Client-Interface

21

Begrüßungsmodul

22

,

22

' Warteschlange

23

Authentikationsmodul

24

Authentikationsservice

25

Sitzungsprotokoll

26

Laststeuerungsmodul

Claims (28)

1. Verfahren zum gesicherten Datenaustausch zwischen einem ex­ ternen und einem internen Netz (1 und 2) über ein Transakti­ onsinterface (3) hinweg, bei dem ein externer Nutzer (17) vor­ bestimmte Datentransaktionen innerhalb des internen Netzes (2) vornehmen kann, wobei das Transaktionsinterface (3)
ein Portal im externen Netz (1),
eine in Zugriffsrichtung dahinterliegende neutrale Zone (5) mit wenigstens
einem Schnittstellenserver (7) und
einem Schnittstellenspeicher (11),
sowie einen inneren Server (12), der bereits innerhalb des internen Netzes (2) angeordnet ist,
umfaßt,
wobei Abfragen externer Nutzer (17), die eine Daten­ transaktion innerhalb des internen Netzes (2) auslösen können,
vom Schnittstellenserver (7) aufbereitet und
in definierter Form im Schnittstellenspeicher (11) zwi­ schengespeichert werden,
der Schnittstellenspeicher (11) in einer definierten Frequenz vom inneren Server (12) abgefragt wird und nach Übermittlung dieser zwischengespeicherten entspre­ chend aufbereiteten Abfragen an den inneren Server (12) die vollständige Bearbei­ tung dieser Abfragen einschließlich eines Teils der Nut­ zerauthentifikation innerhalb des internen Netzes (2) erfolgt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß folgende Schritte durchlaufen werden:

• - etwaig über das Portal eingegebene Nutzerabfragen werden vom Schnittstellenserver (7), der innerhalb der neutralen Zone (5) angeordnet ist, ausgelesen und ggf. quittiert,
• - wobei diese etwaige Quittierung an den Nutzer über­ mittelt wird,
• - der Schnittstellenserver (7) überprüft die Zulässig­ keit der Abfrage anhand eines Vergleichs mit einer Menge vorbestimmter zulässiger Abfragen und deren semantische Korrektheit, wobei im Fehlerfalle die Abfrage abgewiesen und ansonsten wie folgt weiter bearbeitet wird:
• - im Falle der Weiterbearbeitung stellt der Schnitt­ stellenserver (7) die Abfrage in eine Warteschlange (22, 22'), die innerhalb des Schnittstellenspeichers (11) angelegt ist,
• - diese Warteschlange (22, 22') wird in der defi­ nierten Frequenz vom inneren Server (12) abgefragt,
• - wobei auf diese Abfrage hin eine Übermittlung der aufbereiteten Abfrage in das interne Netz (2) er­ folgt,
• - wobei dann die vollständige Bearbeitung einschließ­ lich des genannten Teils der Authentikation des Nutzers (17) im internen Netz (2) erfolgt,
• - das Ergebnis an den Schnittstellenserver (7) zurück­ gegeben wird und
• - nach einer Überprüfung, ob Ergebnis und Abfrage in Einklang stehen,
• - bejahendenfalls eine Antwort an den Nutzer (17) ausgegeben wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeich­ net, daß die Nutzerabfragen vom externen Netz (1) unter Überwindung einer äußeren Firewall (4) in die neutrale Zone (5) gegeben werden.

4. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß der Datenaustausch zwischen der neutralen Zone (5) und dem internen Netz (2) unter Überwin­ dung einer inneren Firewall (6) abgewickelt wird.

5. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß in der neutralen Zone (5) zusätz­ lich ein externer Server (10), vorzugsweise ein Web-Server, angeordnet ist, wobei zumindest ein Teil der Nutzerabfragen über diesen externen Server (10) an den Schnittstellenser­ ver (7) übermittelt wird.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß einmal in der Warteschlange (22, 22') des Schnittstellen­ speichers (11) aufgenommene Abfragen bis zur vollständigen Abarbeitung oder bis zu einem definierten Zeitablauf resi­ stent gespeichert werden.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß die Frequenz der Warteschlangen-Abfragen in Abhängigkeit von der Anzahl und/oder der Mächtigkeit der Nutzerabfragen mittels einer entsprechenden Frequenzsteuerung verändert wird.

8. Verfahren nach Anspruch 7, da­ durch gekennzeichnet, daß in Abhängigkeit von der Anzahl und/oder der Mächtigkeit der Nutzerabfragen parallele Pro­ zesse innerhalb des Schnittstellenservers (7) und/oder inneren Servers (12) freigegeben oder deaktiviert werden.

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß innerhalb der neutralen Zone (5) mehrere Schnittstellenser­ ver (7) angeordnet sind, die je nach Anzahl und/oder Mäch­ tigkeit der Nutzeranfragen aktiviert oder deaktiviert wer­ den, wobei die hierzu erforderliche Laststeuerung mittels des externen Servers (10) und/oder mittels eines Laststeue­ rungsmoduls der äußeren Firewall (4) erfolgt.

10. Verfahren nach Anspruch 8 und 9, dadurch gekennzeich­ net, daß innerhalb des internen Netzes (2) mehrere innere Server (12) angeordnet sind, die je nach Anzahl und/oder Mächtigkeit der Nutzeranfragen aktiviert oder deaktiviert werden, wobei die hierzu erforderliche Laststeuerung mit­ tels des Schnittstellenservers (7) und/oder mittels eines Laststeuerungsmoduls der inneren Firewall (6) erfolgt.

11. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß die Nutzerabfragen vor ihrer Übermittlung in das interne Netz (2) innerhalb der neutralen Zone (5) verschlüsselt werden.

12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß die zur Verschlüsselung jeweils eingesetzten Schlüssel eine individuell vorbestimmbare Lebensdauer haben.

13. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß die Authentikation des Nutzers (17) unabhängig von der sonstigen Bearbeitung der Nutzerab­ frage erfolgt.

14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, daß zur Authentikation des Nutzers (17) folgende Schritte durchlaufen werden:

- Separierung einer Nutzer-ID und eines Nutzerpasswor­ tes aus der Nutzerabfrage in der neutralen Zone (5),

• - auf Anfrage des inneren Servers (12) Übermittlung der Nutzer-ID an das interne Netz (2),
• - Verschlüsselung der Nutzer-ID im inneren Netz (2) unter Verwendung des im inneren Netz (2) zu dieser Nutzer-ID abgelegten Passwortes,
• - und Rückgabe der solcherart verschlüsselten Nutzer- ID in die neutrale Zone (5),
• - Entschlüsselung der aus dem inneren Netz(2) zurück­ gegebenen Nutzer-ID unter Verwendung des vom Nutzer (17) eingegebenen und in der neutralen Zone (5) zwi­ schengespeicherten Passwortes,
• - Vergleich der entschlüsselten Nutzer-ID und der vom Nutzer eingegebenen, wobei im Falle der Übereinstim­ mung die Authentizität des externen Nutzers (17) be­ stätigt oder andernfalls verneint wird und in Abhängig­ keit hiervon die Nutzerabfrage weiter bearbeitet wird oder nicht.

15. Transaktionsinterface zum gesicherten Datenaustausch zwi­ schen einem externen und einem internen Netz (1 und 2) über dieses Transaktionsinterface (3) hinweg, wobei ein externer Nutzer (17) vorbestimmte Datentransaktionen innerhalb des in­ ternen Netzes (2) vornehmen kann und hierzu das Transaktions­ interface (3)
ein Portal im externen Netz (1),
eine in Zugriffsrichtung dahinterliegende neutrale Zone (5) mit wenigstens
einem Schnittstellenserver (7) zur Aufbereitung der Ab­ fragen externer Nutzer (17), die eine Datentransaktion innerhalb des internen Netzes (2) auslösen können,
einem Schnittstellenspeicher (11) zur Zwischenspeiche­ rung der entsprechend aufbereiteten Abfragen in defi­ nierter Form,
sowie einen inneren Server (12), der bereits innerhalb des internen Netzes (2) angeordnet ist, zur Abfrage des Schnittstellenspeichers (11) in einer definierten Fre­ quenz, aufweist, wobei
nach Übermittlung dieser zwischengespeicherten aufberei­ teten Abfragen an diesen inneren Server (12) die voll­ ständige Bearbeitung einschließlich eines Teils der Nut­ zerauthentifikation innerhalb des internen Netzes (2) erfolgt.

16. Transaktionsinterface nach Anspruch 15, dadurch gekenn­ zeichnet, daß die neutrale Zone (5) gegenüber dem externen Netz (1) mittels einer äußeren Firewall (4) abgeschottet ist.

17. Transaktionsinterface nach Anspruch 15 oder 16, dadurch gekennzeichnet, daß das interne Netz (2) gegenüber der neu­ tralen Zone (5) mittels einer inneren Firewall (6) abge­ schottet ist.

18. Transaktionsinterface nach einem der Anspruch 15 bis 17, dadurch gekennzeichnet, daß innerhalb der neutralen Zo­ ne (5) zusätzlich ein externer Server (10) vorgesehen ist, der aus dem externen Netz(1) unmittelbar oder mittelbar über den Schnittstellenserver (7) zur Bearbeitung von Nut­ zerabfragen ansprechbar ist.

19. Transaktionsinterface nach einem der Ansprüche 15 bis 18, dadurch gekennzeichnet, daß der Schnittstellenspeicher (11) derart skalierbar ist, daß aus dem externen Netz (1) eingehende Nutzerabfragen je nach Umfang und Dringlichkeit entsprechend in eine Warteschlange (22, 22') des Schnitt­ stellenspeichers (11) einsortiert werden und gegebenenfalls zusätzli­ che Prozesse aktivierbar sind.

20. Transaktionsinterface nach Anspruch 18, dadurch gekenn­ zeichnet, daß innerhalb der neutralen Zone (5) mehrere Netzwerkrechner angeordnet sind, auf denen jeweils ein Schnittstellenserver (7) angeordnet ist, wobei in Abhängig­ keit von der Anzahl und/oder Mächtigkeit der Nutzerabfragen zusätzliche Server (7) aktiviert oder deaktiviert werden können, wobei die Laststeuerung vom externen Server (10) und/oder der äußeren Firewall (4) erfolgt.

21. Transaktionsinterface nach Anspruch 18 oder 19, dadurch gekennzeichnet, daß im Bereich des internen Netzes (2) meh­ rere Netzwerkrechner angeordnet sind, die jeweils mit einem inneren Server (12) versehen sind, die je nach Umfang und Mächtigkeit der Nutzeranfragen aktivierbar oder deaktivier­ bar sind, wobei die Laststeuerung von der inneren Firewall (6) bzw. einem oder mehreren Schnittstellenservern (7) übernommen wird.

22. Transaktionsinterface nach einem der vorhergehenden An­ sprüche 15 bis 21, dadurch gekennzeichnet, daß der innere Server (12) über einen CORBA-Bus mit dem internen Netz (2) kommuniziert.

23. Transaktionsinterface nach Anspruch 22, dadurch gekenn­ zeichnet, daß das gesamte Transaktionsinterface (3) über ein durchgehendes CORBA-Bus-System in Datenverbindung steht.

24. Transaktionsinterface nach einem der vorhergehenden Ansprüche 15 bis 23, dadurch gekennzeichnet, daß die gesamte interne Schnittstellenkommunikation SSL-verschlüsselt, vorzugsweise DES verschlüsselt, erfolgt.

25. Transaktionsinterface nach einem der vorhergehenden Ansprüche 15 bis 24, dadurch gekennzeichnet, daß der Schnittstellenser­ ver (7) vor der Einstellung bestimmter Nutzerabfragen eine Bestätigungsanfrage an den Nutzer (17) übermittelt und erst nach Eingang der Bestätigung die Weiterbearbeitung erfolgt.

26. Transaktionsinterface nach einem der vorhergehenden Ansprüche 15 bis 25, dadurch gekennzeichnet, daß mittels eines Logging- Moduls ein Logging-Protokoll aufgezeichnet wird, das sämt­ liche über das Transaktionsinterface (3) abgewickelten Transaktionen aufzeichnet.

27. Transaktionsinterface nach einem der vorhergehenden Ansprüche 15 bis 26, dadurch gekennzeichnet, daß die Konfiguration des Schnittstellenservers (7) ausschließlich aus dem internen Netz (2) durchführbar ist.