-
HINTERGRUND DER ERFINDUNG
-
1. GEBIET DER ERFINDUNG
-
Die
Erfindung betrifft im Allgemeinen Rechnersysteme und insbesondere
Verfahren und Vorrichtungen zur Bereitstellung von adaptierbaren
Sicherheits- und Aufzeichnungsmodulen in einer Serverumgebung.
-
2. BESCHREIBUNG DES EINSCHLÄGIGEN STANDES
DER TECHNIK
-
Das
explosive Wachstum des Internethandels, auch als E-Commerce bezeichnet,
ließ die
Suche nach Möglichkeiten
entscheidend werden, sowohl die Leistungsfähigkeit, eine große Anzahl
von sicheren Transaktionen über
das Internet abzuwickeln, zu verbessern als auch die Leistungsfähigkeit, diese
Transaktionen wirksam aufzuzeichnen, bereitzustellen.
-
Gegenwärtig weisen
die meisten Webbrowser eine sehr einfache Lösung zur Vernetzung auf, wie
in 1 veranschaulicht. Angesichts eines Webbrowsers 100 und
eines URLs (universeller Fundstellenanzeiger nach engl. universal
resource locator), welcher einen Wirtsnamen und ein Dokument auf diesem
Wirt (auch als eine http-Anforderung bezeichnet) enthält, zerlegt
(gliedert) ein Browser 102 den URL in einen benannten Wirtsabschnitt 104 und
ein angefordertes Dokument 106. In einer Ausführungsform
der Erfindung nimmt das angeforderte Dokument 106 die Form
von HTML-Anweisungen (Hypertext-Beschreibungssprache nach engl.
HyperText Markup Language) an, welche den Fachleuten allgemein bekannt
sind. Falls das angeforderte Dokument nicht in einem lokalen Cache-Speicher
gespeichert ist, stellt der Browser 102 eine TCP-Verbindung („Übertragungssteuerungsprotokoll" nach engl. transmission
control protocol) mit dem benannten Wirt 104 her, der einen
Server 108 umfasst. Bezogen auf das Web ist ein Webserver
ein (normalerweise im Wirtsrechner 104 befindliches) Computerprogramm, welches
angeforderte HTML-Seiten oder – Dateien zur
Verfügung
stellt, wohingegen ein Webclient das Anforderungsprogramm (wie beispielsweise
der Browser 100) ist, das mit dem Benutzer verbunden ist.
-
In
manchen Fällen
nimmt das angeforderte Dokument 106 die Form von statischen
Webseiten 110 an, welche im Wirtsrechner 104 gespeichert
sind. In einem anderen Fall ist das angeforderte Dokument 106 jedoch
eine so genannte dynamische Webseite 112. Normalerweise
ist die dynamische Webseite 112 zum Beispiel in einer Datenbank
gespeichert, die normalerweise eine externe Datenbank 114 ist,
auf die der Server 108 über
eine allgemeine Netzübergangsschnittstellenanwendung
(CGI für
engl. common gateway interface) zugreift.
-
Die
allgemeine Netzübergangsschnittstelle (CGI)
ist ein Standardverfahren, mit dem ein Webserver die Anforderung
eines Webbenutzers an ein Anwendungsprogramm weiterleitet und Daten
zur Weitersendung an den Benutzer zurückerhält. Wenn der Benutzer eine
Webseite anfordert (zum Beispiel durch Anklicken eines hervorgehobenen
Wortes oder Eingeben einer Website-Adresse), sendet der Server 108 die
angeforderte Seite in Form einer http-Antwort zurück. Wenn
jedoch ein Benutzer ein Formular auf einer Webseite ausfüllt und
einsendet, muss es für gewöhnlich durch
ein Anwendungsprogramm verarbeitet werden. Der Webserver 108 leitet
die Formularinformation normalerweise an ein kleines Anwendungsprogramm
weiter, welches die Daten verarbeitet und basierend auf der bereitgestellten
Information eine Antwort zurücksendet.
-
Unglücklicherweise
ist die allgemeine Netzübergangsschnittstelle
leistungsschwach und betriebsmittelintensiv. Zum Beispiel brauchen
die meisten modernen Webanwendungen irgendeine Art von Datenbankzugang.
Das Verwenden einer CGI-Anwendung bedeutet, dass jedes Mal, wenn
die CGI läuft,
eine neue Datenbankverbindung hergestellt wird, was jedes Mal einige
Sekunden dauert. Daher ist die CGI für die Abwicklung einer großen Anzahl von
Transaktionen (die als „Treffer" bezeichnet werden,
welche in die Tausende oder Hunderttausende und in manchen Fällen darüber hinaus
gehen können und
auch gehen), die für
eine wirtschaftliche Verwendung des Internets erforderlich sind,
nicht geeignet. Eine Lösung
für den
Engpass, der durch die CGI verursacht wird, wird als ein Servlet
oder, wenn in einem Java-basierten Webserver integriert, Java-Servlet bezeichnet.
-
Ein
Java-Servlet ist ein Java-Programm, das auf dem Web- oder HTTP-Server
als Reaktion auf Anforderungen (d.h. http-Anforderungen) von einem Webbrowser
abläuft.
Die Webserver-Software
verwendet eine virtuelle Java-Maschine, um das Servlet auszuführen und
eine HTML-Seite zu erzeugen. Das Servlet nimmt eine Eingabe von
der HTML-Seite (http-Anforderung),
welche HTML-Eingabemarkierungen enthält, verarbeitet sie und sendet
eine antwortende HTML-Seite (http-Antwort) mit den Ergebnissen zurück. Da das
Java-Servlet einem
einzigen Browser zugeordnet ist, ist das Servlet imstande, viel mehr
Verkehr (in Form von http-Anforderungen
und damit verbundenen http-Anworten) abzuwickeln, als dies bei herkömmlichen
CGI-Anwendungen möglich ist.
-
Trotz
dieser Vorteile können
Java-Servlets keine kundenspezifischen Sicherheits- und Aufzeichnungsprotokolle
bereitstellen. Gegenwärtig
werden Sicherheits- und Aufzeichnungsprotokolle eben nur durch den
Webserver bereitgestellt, welche für alle Webanwendungen, die
damit unterstützt
werden, gleich sind. Auf diese Weise können alle mit einem bestimmten
Webserver gekoppelten Anwendungen (oder HTTP-Server), welche Sicherheits-
und Aufzeichnungsprotokolle auch immer geboten werden, nur diesen
konkreten Webserver verwenden, ungeachtet der spezifischen Bedürfnisse
einer bestimmten Anwendung. Diese Inflexibilität bedeutet beträchtliche
Zusatzkosten für
die Realisierung einer E-Commerce-Website, da ein Benutzer/Server
einen Webserver finden muss, der die spezifischen Sicherheits- und
Aufzeichnungsanforderungen der gewünschten Website zusätzlich zu
der Garantie erfüllt, dass
der so ausgewählte
Server auch die Anzahl von (hoffnungsvoll) erwarteten Transaktionen
(Treffern) abwickeln oder den Sicherheits- und Aufzeichnungscode
als Teil der Anwendung entwickeln kann.
-
WO
99/05813 beschreibt Systeme und Verfahren zur Verwendung eines Authentifizierungs-Applets,
um einen Benutzer in einem Rechnernetz zu identifizieren und zu
authentifizieren. Ein Client fordert über einen globalen Server,
welcher Teil des Internets ist, einen Dienst an. Der Server sendet
ein Authentifizierungs-Applet an den Client, welcher eine Client-Antwort
zum Beispiel in Form eines Benutzerinformations-Hashs erzeugt, die
an den Server gesendet wird. Der Server umfasst eine Servlet-Wirtsmaschine, welche
einen sicheren Kommunikationskanal bereitstellt, und Servlets, welche
ein Authentifizierungs-Servlet
umfassen. Das Authentifizierungs-Servlet verarbeitet die Client-Antwort,
um sie durch Nachschlagen der Benutzerdaten zu überprüfen. Verschiedene Ebenen des
Zugriffs auf Dienste können
basierend auf verschiedenen Authentifizierungsparametern gewährt werden.
Der Client kann auf drei Arten Zugriff auf den angeforderten Dienst erlangen:
der Server kann eine direkte Verbindung zu einem Ferndienst bereitstellen;
der Server kann als Proxy zu einem Ferndienst für den Client fungieren; oder,
wenn sich der Dienst auf dem Server befindet, liefert der Server
dem Applet, das eine sichere Verbindung mit dem Server herstellt,
die Dienstadresse, und das Applet fungiert als eine I/O-Schnittstelle
mit dem Dienst auf dem Server.
-
„Applying
Military Grade Security to the Internet", C. I. Dalton and J. F. Griffin, Computer
Networks and ISDN Systems, 29 (1997) 1799–1808, North Holland Publishing,
beschreibt ein Verfahren zur Bereitstellung von sicheren Benutzersitzungen
für WWW-Anwendungen
basierend auf einem Anwendungsübergang
mit einer Workstation mit Abteilungsmodus (CMW für engl. Compartmented Mode
Workstation). Bei der CMW weist die gesamte Information ein mit
ihr verbundenes Sensitivitätsetikett
auf, welches eine Klassifizierung und eine Anzahl von Abteilungen
umfasst. Das Betriebssystem etikettiert Dateien, Prozesse und Netzverbindungen,
um zu steuern, was gelesen und geschrieben werden kann. Ein zuverlässiger Kernteil
des Betriebssystems kann Systemaufrufe prüfen, um jede Zugriffsverweigerung
oder jeden Operationsversuch ohne die erforderliche Berechtigung
aufzuzeichnen. Zuverlässige
Programme können
auch ihre Aktionen aufzeichnen, damit ein verdächtiges Verhalten, wie beispielsweise
das Außerkraftsetzen
einer obligatorischen Zugriffskontrolle (MAC für engl. mandatory access control),
durch einen Administrator verfolgt werden kann. Um eine sichere
Sitzung zu beginnen, wird einem Benutzer in einem Cookie eine Sitzungs-ID
gesendet, die allen nachfolgenden Benutzeranforderungen angehängt wird.
Eine SESSIOND-Komponente
validiert Benutzeranforderungen durch Überprüfen von Benutzernamen und Passwörtern, erzeugt
auch Sitzungs-IDs, Antwortabfragen
bei Sitzungen und wendet einen Reauthentifizierungsgrundsatz an.
Die SESSIOND-Komponente kann die Aufzeichnung von Systemaufrufen
abstellen und ihre eigenen Eingaben in die Systemprotokolldateien
eingeben.
-
Daher
werden ein Verfahren und eine Vorrichtung zur Bereitstellung kundenspezifischer
Sicherheits- und Aufzeichnungsprotokolle in einer Servletumgebung
gewünscht.
-
Gemäß einem
ersten Aspekt der Erfindung wird eine Servleteinrichtung bereitgestellt,
welche so ausgelegt ist, dass sie adaptierbare Sicherheits- und Aufzeichnungsprotokolle
bereitstellt, und umfasst: einen Servlet-Container, welcher umfasst:
ein Sicherheitsmodul, das so ausgelegt ist, dass es ein ausgewähltes Sicherheitsprotokoll
bereitstellt, welches Authentifizierungs- und Autorisierungsprotokolle
umfasst, wobei die Authentifizierungsprotokolle garantieren, dass
eine durch die Servleteinrichtung empfangene Anforderung eine verifizierte
Quelle aufweist, und wobei die Autorisierungsprotokolle garantieren,
dass die verifizierte Quelle eine entsprechende Erlaubnis hat, und
wobei, wenn die durch die Servleteinrichtung empfangene Anforderung
nicht authentifiziert oder autorisiert wird, ein entsprechendes
Fehlerkennzeichen erzeugt wird, das einen Fehlercode umfasst, der
die Fehlerart anzeigt; ein Aufzeichnungsmodul, das mit dem Sicherheitsmodul
gekoppelt und so ausgelegt ist, dass es die gelieferten Aufzeichnungsprotokolle
so bereitstellt, dass jene empfangenen Anforderungen, welche nicht
von der verifizierten Quelle stammen oder welche keine entsprechende
Erlaubnis haben, durch das Aufzeichnungsmodul protokolliert werden,
wenn das entsprechende Fehlerkennzeichen durch das Sicherheitsmodul
gesetzt ist; und ein Servlet, das mit dem Sicherheitsmodul und dem
Aufzeichnungsmodul gekoppelt und so ausgelegt ist, dass es nur jene
empfangenen Anforderungen bearbeitet, die durch das Sicherheitsmodul
authentifiziert und autorisiert sind, und wobei das Servlet das
Aufzeichnungsmodul verständigt,
jene Anforderungen zu protokollieren, welche durch das Servlet erfolgreich
bearbeitet wurden und für
welche kein Fehlerkennzeichen durch das Sicherheitsmodul gesetzt
wurde.
-
Gemäß einem
zweiten Aspekt der Erfindung wird ein Verfahren zum Zugreifen auf
ein geschütztes Betriebsmittel
bereitgestellt, das mit einer Servleteinrichtung gekoppelt ist,
welche so ausgelegt ist, dass sie kundenspezifisch adaptierbare
Sicherheits- und Aufzeichnungsprotokolle bereitstellt, wobei die
Servleteinrichtung ein Sicherheitsmodul, das so ausgelegt ist, dass
es ein kundenspezifisch ausgewähltes Sicherheitsprotokoll
bereitstellt, welches Authentifizierungs- und Autorisierungsprotokolle
umfasst, ein Aufzeichnungsmodul und ein Servlet, das mit dem Sicherheitsmodul
und dem Aufzeichnungsmodul gekoppelt ist, umfasst, wobei das Verfahren
umfasst: Empfangen einer Betriebsmittelzugriffsanforderung durch
die Servleteinrichtung; Bestimmen durch das Sicherheitsmodul, dass
die empfange Zugriffsanforderung von einer verifizierten Quelle
basierend auf den Authentifizierungsprotokollen stammt und dass die
empfangene Zugriffsanforderung eine entsprechende Erlaubnis basierend
auf den Autorisierungsprotokollen hat; und, wenn die empfangene
Zugriffsanforderung nicht authentifiziert oder autorisiert wird,
anschließendes
Erzeugen eines entsprechenden Fehlerkennzeichens, das einen Fehlercode
umfasst, der die Fehlerart anzeigt; Protokollieren durch das Aufzeichnungsmodul
basierend auf den Aufzeichnungsprotokollen jener Anforderungen,
welche nicht von der verifizierten Quelle stammen oder keine entsprechende
Erlaubnis haben, wenn das Fehlerkennzeichen durch Sicherheitsmodul
gesetzt ist; Bearbeiten durch das Servlet nur jener empfangenen Anforderungen,
welche durch das Sicherheitsmodul authentifiziert und autorisiert
sind; Verständigen
des Aufzeichnungsmoduls durch das Servlet, jene Anforderungen zu
protokollieren, welche durch das Servlet erfolgreich bearbeitet
wurden und für
welche kein Fehlerkennzeichen durch das Sicherheitsmodul gesetzt
wurde; und Bereitstellen von Zugriff auf das geschützte Betriebsmittel
durch das Servlet für
jene Anforderungen, für
welche kein Fehlerkennzeichen durch das Sicherheitsmodul gesetzt
wurde.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Erfindung kann zusammen mit weiteren Vorteilen davon unter Bezugnahme
auf die folgende Beschreibung in Verbindung mit den beiliegenden Zeichnungen
am besten verstanden werden, wobei:
-
1 eine
herkömmliche
Browser/Server-Konfiguration darstellt;
-
2 einen
Java-basierten Server und einen damit verbundenen Servlet-Container
darstellt, welcher benutzerkonfigurierbare Sicherheits- und Aufzeichnungsprotokolle
gemäß einer
Ausführungsform
der Erfindung bereitstellt;
-
3 ein
Ablaufdiagramm ist, welches einen Servlet-Lebenszyklus gemäß einer Ausführungsform der
Erfindung detailliert;
-
4 ein
Ablaufdiagramm ist, welches einen Prozess detailliert, der die Abwicklung
der Sicherheitsoperation von 3 realisiert;
-
5 ein
Ablaufdiagramm ist, welches einen Prozess detailliert, der die Abwicklung
der Aufzeichnungsoperation von 3 realisiert;
-
6 ein
Rechnersystem veranschaulicht, das eingesetzt werden kann, um die
vorliegende Erfindung zu realisieren.
-
AUSFÜHRLICHE
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
-
In
der folgenden Beschreibung werden Rahmen und Verfahren zur Bereitstellung
von kundenspezifischen Sicherheits- und Aufzeichnungsprotokollen
in einem Webserver, wie beispielsweise einer Browser/Serverumgebung,
beschrieben. Es ist zu erwähnen,
dass, obwohl die Erfindung anfänglich
hinsichtlich einer Serveranwendung, welche sich in einem objektorientierten
Multithread-Rechnersystem befindet, beschrieben wird, die vorliegende
Erfindung in jedem System verwendet werden kann, das imstande ist,
http-Anforderungen und -Antworten zu bearbeiten.
-
Wenn
ein Browser, der auch als eine HTTP-Seite bezeichnet wird und mit
einem Webserver gekoppelt ist, eine http-Anforderung erzeugt, authentifiziert
im Allgemeinen ein durch einen Programmierer/Entwickler bereitgestelltes
Sicherheitsmodul, das im Webserver enthalten ist, den Browser (d.h. bestätigt in
einer Ausführungsform
die Identität
des Browsers), der die http-Anforderung bereitstellt. Wenn die Authentifizierung
erfolgreich ist, d.h. der Browser gebührlich identifiziert ist, dann
stellt das Sicherheitsmodul fest, ob der Browser über die
geeignete Autorisierung verfügt,
um auf die angeforderte Datenbank zuzugreifen. In jenen Fällen, in
denen der Browser sowohl gebührlich
identifiziert wurde als auch über
die geeignete Autorisierung verfügt,
wird das angeschlossene Servlet darauf aufgerufen, die validierte
http-Anforderung nötigenfalls
durch Zugreifen auf ein geschütztes
Betriebsmittel, wie beispielsweise eine sichere Datenbank, zur Verfügung zu
stellen.
-
Sobald
das angeschlossene Servlet die http-Anforderung bearbeitet hat,
protokolliert ein angeschlossenes Aufzeichnungsmodul den Status
der http-Anforderungsbearbeitung.
In einer Ausführungsform
werden nur jene http-Anforderungen als erfolgreich aufgezeichnet,
die nicht mit einem Fehlerkennzeichen verbunden sind (d.h. deren
Bearbeitung „erfolgreich" war). In einer anderen
Ausführungsform werden
durch das Aufzeichnungsmodul auch alle Fehlautorisierungen und -authentifizierungen
aufgezeichnet. Auf diese Weise können
Versuche, eine sichere Datenbank oder einen sicheren Webserver „aufzuhacken" oder anderweitig
darin einzubrechen, verfolgt werden, und der oder die Täter können unter Verwendung
allgemein bekannter Identifizierungs- und Verfolgungstechniken identifiziert
werden.
-
In
einer Ausführungsform
basiert die Autorisierung während
einer so genannten Sitzung zum Teil auf einem Cookie (der sich im
Browser befindet), der durch das Sicherheitsmodul vorher bereitgestellt wird.
Wie für
die Fachleute zu erkennen ist, ist eine Sitzung ein Mechanismus,
den Servlets verwenden, um den Zustand einer Reihe von Anforderungen
von demselben Benutzer (d.h. demselben Browser) über einen bestimmten Zeitraum
aufrechtzuerhalten. Ein Cookie ist ein Mechanismus, den ein Servlet
verwendet, um zu bewirken, dass Clients eine kleine Menge von Zustandsinformationen,
die mit dem Benutzer verbunden sind, speichern. Servlets können die
Information in einem Cookie verwenden, wenn der Benutzer die Site
betritt (zum Beispiel als eine Benutzeranmeldung auf niedriger Sicherheitsebene),
während
der Benutzer auf der Site navigiert (zum Beispiel als einen Aufbewahrungsort
von Benutzereinstellungen) oder sowohl als auch.
-
Die
meisten Webserver weisen eine sehr einfache Lösung zur Vernetzung auf, wie
in 2 veranschaulicht. Ein Browser 200 (auch
als eine Clientanwendung- oder -programm bezeichnet) ist ein Programm,
das sich auf einem lokalen Rechner 202 befindet, welcher
eine so genannte http-Anforderung erzeugt,
die einen benannten Wirtsrechner 204 und ein mit dem Wirtsrechner 204 gekoppeltes
Dokument enthält,
das normalerweise in einer externen Datenbank 206 gespeichert
wird. Der Wirtsrechner 204 ist normalerweise mit einer
Gruppe von Rechnern in einem Netz, wie beispielsweise einem lokalen
Datennetz (LAN für
engl. local area network) oder einem Weitbereichsnetz (WAN für engl.
wide area network), oder insbesondere als Teil des Internet-Rechnernetzes
gekoppelt. In der beschriebenen Ausführungsform umfasst der Wirtsrechner 204 ein
Webserveranwendungsprogramm (Server) 208.
-
In
der beschriebenen Ausführungsform
umfasst der Server 208 seinerseits einen Servlet-Container 210,
welcher ein Sicherheitsmodul 212 umfasst, das mit einem
Aufzeichnungsmodul 214 gekoppelt ist, das seinerseits mit
einem Servlet 216 gekoppelt ist. Bei einer Realisierung
wird der Servlet-Container 210 auch als eine Servleteinrichtung bezeichnet
und stellt eine Schnittstelle zwischen dem Server 208 und
dem Servlet 216 bereit. In jenen Fällen, in welchen das Sicherheitsmodul 212 aktiv
ist (d.h. Entwickler/Programmierer-Sicherheitsprotokolle bereitstellt),
verarbeitet oder bearbeitet das Servlet 216 nur jene http-Anforderungen,
welche durch das Sicherheitsmodul 212 sowohl authentifiziert
als auch autorisiert wurden. In jenen Fällen, in welchen das Sicherheitsmodul 212 nicht
aktiv ist oder der Serverprogrammierer entschieden hat, dass keine
spezifischen Sicherheitsprotokolle gebraucht werden, werden in einer
Realisierung der Erfindung die Sicherheitsprotokolle, die durch
den Webserver 204 bereits bereitgestellt wurden, in einem
Standardmodus verwendet.
-
Falls
die http-Anforderung weder authentifiziert noch autorisiert wird,
wird ein Fehlerkennzeichen an das Aufzeichnungsmodul 214 gesendet. Solche
Fehlerkennzeichen können
Fehlercodes umfassen, wie beispielsweise einen so genannten „401"-Fehlercode, der
anzeigt, dass die Authentifizierung fehlgeschlagen ist. In einem
anderen Fehlermodus wird ein wird ein „404"-Fehlercode erzeugt, der anzeigt, dass
ein bestimmtes Objekt nicht gefunden wurde. Einer der Vorteile der
vorliegenden Erfindung ist es, dem Servleteinrichtungs-Entwickler/Programmierer
diese Fähigkeit
zu verleihen, sowohl die Art als auch die Anzahl von Fehlercodes,
für welche
das Aufzeichnungsmodul 214 protokolliert, kundenspezifisch
anzupassen. Auf diese Weise kann der Servlet-Programmierer/Entwickler
zum Beispiel die Fähigkeit
des Verfolgens von (sowohl potenziellen als auch tatsächlichen)
Hackern durch Aufzeichnen von mehrfachen Fehlzugriffen durch einen
bestimmten Browser innerhalb eines bestimmten Zeitraums oder Bestimmen
der Häufigkeit
und der Art von verschiedenen Sicherheitsfehlern, welche durch den
Benutzer eines bestimmten Browsers verbreitet werden, bereitstellen.
-
Wenn
die http-Anforderung andernfalls durch das Sicherheitsmodul 212 validiert
wurde, wird die validierte http-Anforderung an das Servlet 216 weitergeleitet.
In der beschriebenen Ausführungsform
bearbeitet das Servlet 216 die http-Anforderung zum Beispiel
durch Erzeugen eines Dokumenten-Objektmodells (DOM), das dem angeforderten Dokument
entspricht, das in der Datenbank 206 gespeichert ist, die
mit der gültigen
http-Anforderung verbunden ist. Sobald das angeforderte Dokument aus
der Datenbank 206 abgerufen ist, wird es an das Servlet 216 weitergeleitet.
Das Servlet 216 verständigt
dann das Aufzeichnungsmodul 214 im Wesentlichen gleichzeitig
mit der Weitergabe des abgerufenen Dokuments an den Browser 200 in
Form einer http-Antwort.
-
Das
Aufzeichnungsmodul verfolgt normalerweise Information, die in einer
Ausführungsform
mit IP-Information (IP für
Internetprotokoll) verbunden ist, welche für den virtuellen Standort des
Browsers 200, sowie die Anzahl von erfolgreichen Treffern
gegenüber
der Anzahl von nicht autorisierten und/oder nicht authentifizierten Anforderungen,
welche ihm durch das Sicherheitsmodul 212 gesendet wurden, kennzeichnend
ist. Mit dieser Information ist ein Entwickler imstande, die Anzahl
und die Art von http-Anforderungen, welche das Servlet verarbeitet,
zu verfolgen. Auf diese Weise ist der Website-Inhaber imstande,
die Website-Benutzung besser zu verfolgen, und er ist auch imstande,
die Anzahl von Benutzern, welche eine bestimmte Site zu betreten
versuchten, und jene, welche beim Betreten der betreffenden Site scheiterten
und/oder Erfolg hatten, zu bestimmen.
-
Falls
sich ein Benutzer entscheidet, eine Sitzung zu starten, dann liefert
das Sicherheitsmodul 212 in einer Ausführungsform während des
Starts der Sitzung einen Cookie 218 an den Browser 200,
welcher während
der Dauer der Sitzung aktiv ist. Ein Beispiel für eine derartige Sitzung ist,
wenn ein Benutzer zum Beispiel ein Applet 220 in dem Browser 200 instanziert,
um auf eine sichere Website oder die Datenbank 206 zuzugreifen.
In einem Fall kann der Benutzer wünschen, ein sicheres Geschäft abzuwickeln,
indem er auf Sensitivinformation zugreift, die in der Datenbank 206 gespeichert
ist, um zum Beispiel die Online-Banking-Website einer Bank zu verwenden oder
das Neueste in Sachen Herrenkleidung zu bestellen. Der Cookie 218 versieht
den Browser 200 mit der notwendigen Autorisierung und Authentifizierung,
wie während
des für
die Sitzung definierten Zeitraums erforderlich. Solange der Cookie 218 gültig ist,
umgehen in diesem Zeitraum alle http-Anforderungen, die durch das Applet 220 für die sichere Website
erzeugt werden, wirksam das Sicherheitsmodul 212 und werden
durch das Servlet 216 bearbeitet. Wenn jedoch der Cookie 218 in
irgendeinem Moment ungültig
wird, indem er zum Beispiel verfällt oder
die konkrete Sitzung zu Ende ist, muss das Sicherheitsmodul 212 einen
neuen Cookie basierend auf den entsprechenden Sicherheitsprotokollen
neu ausgeben.
-
3 ist
ein Ablaufdiagramm, welches einen Servlet-Lebenszyklus 300 gemäß einer
Ausführungsform
der Erfindung detailliert. Es ist zu erwähnen, dass der Servlet-Lebenszyklus 300 hinsichtlich eines
Java-Servlets beschrieben wird, das dazu bestimmt ist, in einer
virtuellen Java-Maschine in einem objektorientierten Rechensystem
abzulaufen. In einer Ausführungsform
der Erfindung beginnt der Servlet-Lebenszyklus 300 bei 302 durch
Instanzieren eines Servlets, worauf der Server das Servlet bei 304 initialisiert.
Um ein Servlet zu initialisieren, lädt der Server das Servlet und
führt das „Servlet-Initialisierungsverfahren" aus. Es ist zu erwähnen, dass
die Servlet-Initialisierung abschließt, bevor Client-Anforderungen
bearbeitet werden und bevor das Servlet zerstört wird. Wenngleich die meisten
Servlets in Multithread-Servern ausgeführt werden, weisen Servlets
keine Gleichzeitigkeitsausgaben während der Servlet-Initialisierung auf.
Der Server ruft das Initialisierungsverfahren einmal auf, wenn der
Server das Servlet lädt,
und er ruft das Initialisierungsverfahren nicht mehr auf, es sei
denn, der Server lädt
das Servlet nach. Der Server kann ein Servlet erst nachladen, nachdem
der Server das Servlet durch Aufrufen des Zerstörungsverfahrens zerstört hat.
Nachdem der Server das Servlet initialisiert hat, wartet das Servlet
bei 306 auf eine http-Anforderung. Wenn eine http-Anforderung empfangen
wurde und wenn eine Client-Sitzung Teil der http-Anforderung ist, dann erfolgt bei 308 eine
Feststellung, ob die Client-Sitzung authentifiziert wurde oder nicht.
Normalerweise erfolgt diese Authentifizierung durch Feststellen,
ob ein Cookie, welcher der Sitzung entspricht, unverfallen ist und/oder
eine entsprechende Anmeldung aufweist. Wenn festgestellt wird, dass
die Sitzung nicht authentifiziert ist, bearbeitet das Sicherheitsmodul die
Sicherheit bei 310 zum Beispiel durch Authentifizieren
der Sitzung durch Prüfen
des Cookies. Falls die empfangene http-Anforderung die http-Anfangsanforderung
für eine bestimmte
Sitzung ist, dann wird diese http-Anforderung durch das Sicherheitsmodul
validiert (d.h. sowohl authentifiziert und autorisiert), worauf
ein neuer Cookie an den Client-Browser ausgegeben wird.
-
Wenn
andererseits die Sitzung bei 308 authentifiziert wurde,
dann wird die http-Anforderung durch das Servlet bei 312 verarbeitet,
worauf die http-Antwort durch das Aufzeichnungsmodul bei 314 aufgezeichnet
wird. Es ist zu erwähnen,
dass immer, wenn das Sicherheitsmodul feststellt, dass die http-Anforderung
aus irgendeinem Grund fehlerhaft ist, ein entsprechendes Fehlerkennzeichen
an das Aufzeichnungsmodul gesendet wird.
-
Wenn
zurück
bei 306 die empfangene http-Anforderung nicht Teil einer
Sitzung ist, bearbeitet das Sicherheitsmodul die Sicherheit bei 310,
wobei Fehler an das Aufzeichnungsmodul zum Aufzeichnen bei 314 gesendet
werden, wohingegen validierte http-Anforderungen durch das Servlet
bei 312 verarbeitet werden.
-
Es
ist zu erwähnen,
dass, wenn keine zusätzlichen
http-Anforderungen
innerhalb eines vorher ausgewählten
Zeitraums bei 306 bevorstehen, bei 316 bestimmt
wird, ob das Servlet zu zerstören
ist oder nicht. Wenn bestimmt wird, dass das Servlet nicht zu zerstören ist,
dann geht die Steuerung zu 306 zurück, bis eine http-Anforderung
empfangen wird. Wenn andererseits bestimmt wird, dass das Servlet
zu zerstören
ist, dann zerstört
der Server das Servlet durch Ausführen des Servlet-Zerstörungsverfahrens
bei 318. In der beschriebenen Ausführungsform wird das Zerstörungsverfahren
einmal ausgeführt,
und der Server führt
dieses Servlet erst wieder aus, nachdem der Server das Servlet nachgeladen und
reinitialisiert hat. Nachdem das Zerstörungsverfahren einmal abgelaufen
ist, ist das Servlet Müll,
der bei 320 eingesammelt wird. Es ist zu erwähnen, dass in
einem Multithread-System eine abgesicherte Abschaltung bereitge stellt
werden muss, da lang laufende Threads noch Dienstanforderungen ausführen könnten.
-
4 ist
ein Ablaufdiagramm, welches einen Prozess 400 detailliert,
der die Abwicklung der Sicherheitsoperation 310 von 3 realisiert.
Es ist zu erwähnen,
dass der Prozess 400 nur eine Möglichkeit der Sicherheitsbearbeitung
gemäß der vorliegenden
Erfindung ist und entsprechend nicht als den Rahmen der Erfindung
einschränkend
ausgelegt werden sollte. Der Prozess 400 beginnt bei 402 durch Feststellen,
ob das Sicherheitsmodul auf aktiv gesetzt ist. Wenn festgestellt
wird, dass das Sicherheitsmodul nicht auf aktiv gesetzt ist, dann
verwendet das Servlet bei 404 den Standardsicherheitsmodus des Servers.
Wenn andererseits festgestellt wird, dass das Sicherheitsmodul auf
aktiv gesetzt ist, dann wird zum Authentifizieren einer empfangenen http-Anforderung
bei 406 ein Authentifizierungsverfahren durch das verbundene
Sicherheitsmodul als eine Authentifizierungsanforderung aufgerufen.
Bei 408 wird dann festgestellt, ob die Authentifizierung erfolgreich
war oder nicht. Wenn die Authentifizierung nicht erfolgreich war,
geht die Steuerung zu 314 (Aufzeichnung) über, andernfalls
ruft das Sicherheitsmodul bei 410 ein Autorisierungsverfahren
für die http-Anforderung
auf. Wenn die Autorisierung nicht erfolgreich ist, geht die Steuerung
zu 314 (Aufzeichnung) über,
andernfalls wird die http-Anforderung durch das Servlet bei 312 verarbeitet.
-
5 ist
ein Ablaufdiagramm, welches einen Prozess 500 detailliert,
der die Abwicklung der Aufzeichnungsoperation 314 von 3 realisiert.
Es ist zu erwähnen,
dass der Prozess 500 nur eine Möglichkeit der Aufzeichnungsbearbeitung
gemäß der vorliegenden
Erfindung ist und entsprechend nicht als den Rahmen der Erfindung
einschränkend
ausgelegt werden sollte. Der Prozess 500 beginnt bei 502 durch
Feststellen, ob das http- Antwortobjekt
einen Fehlercode gesetzt aufweist. Wenn kein Fehlercode gesetzt
ist, dann wird die http-Anforderung durch Aufrufen eines Aufzeichnungsverfahrens durch
das Aufzeichnungsmodul aufgezeichnet. Wenn andererseits der Fehlercode
gesetzt wurde, dann wird die http-Anforderung bei 504 durch
Aufrufen eines Fehleraufzeichnungsverfahrens durch das Aufzeichnungsmodul
aufgezeichnet. In jedem Fall wird das Servlet nach Abschluss der
Aufzeichnungsverfahren in einen Wartezustand versetzt, bis bei 306 die
nächste
http-Anforderung empfangen wird.
-
6 veranschaulicht
ein Rechnersystem 600, das zur Realisierung der vorliegenden
Erfindung eingesetzt werden kann. Das Rechnersystem 600 oder
insbesondere die CPUs 602 können so ausgelegt sein, dass
sie eine virtuelle Maschine unterstützen, wie für die Fachleute zu erkennen
ist. Wie auf dem Fachgebiet allgemein bekannt, dient ein ROM dazu,
Daten und Anweisungen unidirektional an die CPUs 602 zu übertragen,
während
ein RAM normalerweise dazu verwendet wird, Daten und Anweisungen
auf eine bidirektionale Weise zu übertragen. Die CPUs 602 können im
Allgemeinen jede Anzahl von Prozessoren umfassen. Beide Primärspeichergeräte 604, 606 können jedes
geeignete maschinenlesbare Medium umfassen. Ein Sekundärspeichermedium 608,
das normalerweise ein Massenspeichergerät ist, ist ebenfalls bidirektional
mit den CPUs 602 gekoppelt und stellt eine zusätzliche
Datenspeicherkapazität
bereit. Das Massenspeichergerät 608 ist
ein maschinenlesbares Medium, welches verwendet werden kann, um
Programme, welche einen Rechnercode, Daten und dergleichen umfassen,
zu speichern. Normalerweise ist das Massenspeichergerät 608 ein
Speichermedium, wie beispielsweise eine Festplatte oder ein Band,
welches im Allgemeinen langsamer als die Primärspeichergeräte 604, 606 ist. Das
Massenspeichergerät 608 kann
die Form eines Magnetband- oder Lochstreifenlesegeräts oder
irgendeines anderen bekannten Geräts annehmen. Es ist zu erkennen,
dass die Information, welche innerhalb des Massenspeichergeräts 608 festgehalten wird,
in geeigneten Fällen
als Teil des RAMs 606 als virtueller Speicher standardmäßig integriert
werden kann. Ein spezifisches Massenspeichergerät 604, wie beispielsweise
eine CD-ROM, kann ebenfalls Daten unidirektional an die CPUs 602 übertragen.
-
Die
CPUs 602 sind auch mit einem oder mehr Eingabe/Ausgabegeräten 610 gekoppelt,
welche solche Geräte,
wie beispielsweise Videobildschirme, Rollkugeln, Mäuse, Tastaturen,
Mikrophone, Berührungsbildschirme,
Wandler-Kartenlesegeräte, Magnetband-
oder Lochstreifenlesegeräte,
Tabletts, Styli, Sprach- und Handschriftenerkennungsprogramme, oder
andere allgemein bekannte Eingabegeräte, wie beispielsweise natürlich andere
Rechner, umfassen, ohne darauf beschränkt zu sein. Schließlich können die
CPUs 602 wahlweise mit einem Rechner- oder Telekommunikationsnetz
gekoppelt sein, wie beispielsweise einem Internet-Netz oder eine
Intranet-Netz, und eine Netzverbindung verwenden, wie bei 612 allgemein
dargestellt. Bei einer derartigen Netzverbindung ist vorgesehen,
dass die CPUs 602 im Laufe der Durchführung der zuvor beschriebenen
Verfahrensschritte Information vom Netz empfangen oder Information
ans Netz ausgeben könnten.
Diese Information, welche häufig
als eine Folge von Anweisungen dargestellt wird, die unter Verwendung
der CPUs 602 auszuführen
sind, kann zum Beispiel in Form eines Computerdatensignals, das
in einer Trägerwelle
eingebettet ist, vom Netz empfangen und ans Netz ausgegeben werden. Die
zuvor beschriebenen Geräte
und Materialien sind den Fachleuten auf dem Gebiet der Computer-Hardware
und – Software
vertraut.
-
Obwohl
nur ein paar Ausführungsformen
der vorliegenden Erfindung beschrieben wurden, versteht es sich
von selbst, dass die vorliegende Erfindung in vielen anderen spezifischen
Formen verwirklicht werden kann.
-
Obwohl
die Verfahren zur Bereitstellung von kundenspezifischen Sicherheits-
und Aufzeichnungsprotokollen in einer Servleteinrichtung gemäß der vorliegende
Erfindung besonders zur Realisierung in Bezug auf eine JavaTM-basierte Umgebung geeignet sind, können die
Verfahren im Allgemeinen in jeder geeigneten objektbasierten Umgebung
angewendet werden. Insbesondere sind die Verfahren zur Verwendung
in plattformunabhängigen
objektbasierten Umgebungen geeignet. Es sollte zu erkennen sein, dass
die Verfahren auch in gewissen verteilten objektorientierten Systemen
realisiert werden können.
-
Obwohl
die vorliegende Erfindung so beschrieben wurde, dass sie mit einem
Rechnersystem verwendet wird, das einen angeschlossenen Webbrowser
und einen angeschlossenen Webserver aufweist, sollte zu erkennen
sein, dass die vorliegende Erfindung im Allgemeinen in jedem geeigneten
objektorientierten Rechnersystem realisiert werden kann. Daher sind
die vorliegenden Beispiele als veranschaulichend und nicht als einschränkend zu
betrachten, und die Erfindung ist nicht auf die hierin angegebenen
Einzelheiten beschränkt.