-
Technischer Bereich
-
Die
Erfindung bezieht sich auf Informationssicherheit und genauer gesagt
auf Systeme und Verfahren zum Verbessern der Sicherheit von Informationstransaktionen über Netze.
-
Technischer Hintergrund
-
Das
Internet wurde zu einem wichtigen Medium für Informationsdienstleistungen
und elektronischen Handel. Im Zuge der Kommerzialisierung des Internet
haben Organisationen anfangs ihren Auftritt im Cyberspace aufgebaut,
indem sie Informationen (typischerweise statische, nicht sicherheitskritische Werbeinformationen)
auf Ressourcen verfügbar
gemacht haben, die gut von der operationalen Infrastruktur der Organisation
getrennt war. Sicherheitsprobleme wurden oft behandelt, indem öffentlich
zugängliche
Ressourcen (z. B. Web-Server) von sensibleren Werten mittels Firewall-Techniken
isoliert wurden. Solange die öffentlich
zugänglichen
Informationen und Ressourcen relativ unsensibel bzw. wenig sicherheitskritisch
waren und Benutzerinteraktionen mit solchen Informationen und Ressourcen
nicht unternehmenskritisch waren, waren relativ einfache Firewall-Techniken angemessen.
Auch wenn Informationen und Ressourcen außerhalb der Firewall gefährdet waren,
konnte das Risiko im allgemeinen auf nicht-proprietäre Informationen
beschränkt
werden, die leicht ersetzbar waren, falls sie kompromittiert wurden.
Proprietäre
Informationen und für
den alltäglichen
Betrieb wesentliche Systeme wurden hinter der Firewall geschützt und
Informationsflüsse über die
Firewall wurden gefiltert, um alle außer den vergleichsweise nicht-bedrohlichen
Diensten wie elektronische Post auszuschließen.
-
Nachdem
das Internet jedoch allgegenwärtig wurde
und der technische Stand bzw. die Komplexität von Werkzeugen und Techniken
gewachsen ist, haben sich etliche Aspekte des sicherheitsbezogenen Umfeldes
dramatisch geändert.
Als erstes haben Firmen die Mächtigkeit
von Informationstransaktionen erkannt, die enger an operationale
Datensysteme gekoppelt sind, wie Verarbeitung von Bestellungen,
Warenbestand, Bezahlsysteme, etc. Solche Systeme umfassen sowohl
elektronischen Handel mit Direkteinkäufern oder Kunden (z. B. Durchsuchen,
Auswählen
und Kaufen von Büchern
von einem Online-Buchverkäufer
durch Jedermann bzw. Teilnehmer am öffentlichen Leben) als auch
Interaktionen in Lieferketten und/oder unter Geschäftspartnern
(z. B. automatische Just-in-Time Inventarverwaltung, kundenspezifische
Preisgestaltung, Informationen über Verfügbarkeit
und Bestellstatus, etc.). Kurz gesagt erfordern kommerziell relevante
Transaktionen zunehmend Informationsströme zu und von sicheren operationalen
Systemen. Als zweites werden auch rein informationsbezogene Dienste
zunehmend unternehmenskritisch für
ihre Dienstanbieter. Das Firmenimage kann durch Nicht-Verfügbarkeit
von oder Zugangsverschlechterung zu ansonsten unkritischen Informationen
wie Informationen zur Kundenunterstützung, Produktverbesserungen
bzw. -upgrades oder Marketing- und Produktinformationen nachteilig beeinflußt werden.
Weil viele Finnen nachhaltig von solchen Funktionen abhängen, stellen
Denial-of-Service-Angriffe eine zunehmende Bedrohung dar.
-
In
Informationssicherheitsumgebungen sind Authentifikationseinrichtungen
typischerweise darauf ausgelegt, bis zu einem gewünschten
Grad von Gewißheit
zu gewährleisten,
daß eine
bestimmte Transaktion im Namen eines bestimmten Auftraggebers durchgeführt wird.
In ähnlicher
Weise sind Autorisierungseinrichtungen darauf ausgelegt, Sicherheitsrichtlinien
durchzusetzen, die den Zugriff im Namen eines authentifizierten
Auftraggebers auf eine bestimmte Teilmenge von Informationsressourcen
einschränken.
Unglücklicherweise
können
Richtlinien zur Informationssicherheit und Systeme, die darauf ausgelegt
sind, solche Richtlinien zu implementieren, trotz richtig ausgelegter
Authentifizierungs- und Autorisierungseinrichtungen durch verunstaltete
Anforderungen oder sogar wohl gestaltete Anforderungen unterlaufen
werden, die versuchen, eine Sicherheitsrichtlinie zu umgehen. Zum
Beispiel können
verunstaltete Anforderungen eingesetzt werden, um auf sichere Systeme
durch Ausnutzen von Pufferüberläufen oder ähnlichen
Arten von Sicherheitslöchern
zuzugreifen. Darüber
hinaus können
verunstaltete Anforderungen in Denial-of-Service-artigen und anderen
böswilligen
Angriffen eingesetzt werden, um einen Server oder eine Informationsressource
zum Absturz zu bringen oder durch Überlast in die Knie zu zwingen.
Eine andere Bedrohung zieht die Übergabe von
Anweisungen (z. B. SQL-Anweisungen, Skripts, etc.) in eine ansonsten
sichere Umgebung ohne Überprüfung und
direkt an einen Interpreter oder eine andere Ausführungsumgebung
nach sich (z. B. eine SQL-Maschine, Shell, etc.). Antwortnachrichten
können
auch in einer Weise eingesetzt werden, die eine Sicherheitsrichtlinie
untergräbt,
auch wenn solche Bedrohungen üblicherweise
kompromittierte Anwendungen oder Anweisungen, die in die sichere
Umgebung übergeben
werden, implizieren.
-
Ein
Dokument mit dem Titel "Firewalling
the Net" von S.
D. Habbard et al., veröffentlicht
im BT Technology Journal, BT Laboratories, GB, Band 15, Nr. 2, 1.
April 1997, diskutiert die Verwendung von Firewalls zur Sicherheit
im Internet. Das Dokument diskutiert die Notwendigkeit, eine Firewall
an der Schnittstelle zwischen einem eigenständigen Unternehmensnetz und
dem Internet zu errichten. Das Dokument gibt einen Überblick über den
Stand der Firewall-Technologie zu dem Zeitpunkt, als es geschrieben
wurde, und beschreibt die Prinzipien hinter den Lösungen,
die von BT zu dieser Zeit angewandt wurden. Es beschreibt ferner,
wie das Unternehmen die Bandbreite des Internet mittels kryptographischer Techniken
verwenden würde,
um seine internen Intranets auszuweiten, und zeigt einige der Richtungen,
in die Firewall-Forschung infolge der Veröffentlichung des Dokuments
fortschreiten wird.
-
Ein
Dokument mit dem Titel "A
Firewall Overview" von
Ted Doty, veröffentlicht
in Connexions, Band 9, Nr. 7, 1. Juli 1995, bietet einen Überblick über die
Firewall-Technologie.
-
Das
Patent in den Vereinigten Staaten Nr. 5.826.014 bezieht sich auf
ein Firewall-System zum Schutz von Netzelementen, die mit einem öffentlichen
Netz verbunden sind. Das Dokument beschreibt das Bereitstellen einer
Firewall zum Isolieren von Netzelementen von einem öffentlich
zugänglichen
Netz, dem solche Netzelemente zugeordnet sind. Die Firewall wird
auf einem Einzel- bzw. Stand-Alone-Computer
betrieben, der zwischen das öffentliche
Netz und die Netzelemente geschaltet ist, die so zu schützen sind,
daß jedweder
Zugriff auf die geschützten
Netzelemente durch die Firewall gehen müssen. Die Firewall-Anwendung,
die auf dem Stand-Alone-Computer abläuft, ist vorzugsweise die einzige
Anwendung, die auf dieser Maschine abläuft. Die Anwendung umfaßt eine
Vielzahl von Proxy-Agenten, die speziell einer eintreffenden Anforderung
gemäß dem Oberflächenprotokoll,
das in der eintreffenden Zugriffsanforderung angezeigt wird, zugewiesen
werden. Ein zugewiesener Proxy-Agent überprüft die Befugnis einer eintreffenden
Anforderung, um auf ein in der Anforderung angegebenes Netzelement
zuzugreifen. Sobald er verifiziert wurde, vervollständigt der
Proxy-Agent die Verbindung mit dem geschützten Netzelement im Namen
der Quelle der eintreffenden Anforderung.
-
Verbesserte
Systeme und Technologien werden gebraucht, um die Informationsflüsse über Sicherheitsgrenzen
hinweg wie solche, die von einer Firewall (oder Firewalls) bereitgestellt
werden, besser zu verwalten. Ansonsten droht der steigende Bedarf
an Zugriff auf operationale Systeme und Daten die Sicherheit solcher
Systeme und Daten zu kompromittieren. Alternativ wird die Sorge
um die Sicherheit die Machbarkeit fortgeschrittener elektronischer Handelstechniken
einschränken.
-
OFFENBARUNG
DER ERFINDUNG
-
Spezielle
und bevorzugte Aspekte der vorliegenden Erfindung sind in den beigefügten abhängigen und
unabhängigen
Ansprüchen
dargelegt.
-
Dementsprechend
wurde ein sicherer Datenmakler entwickelt, der eine eingeschränkte Nachricht basierend
auf dem Datenaustausch zwischen einer Client-Anwendung und einer
gesicherten Informationsressource bereitstellt, indem registrierte
oder überprüfte Nachrichten über eine
Sicherheitsschranke hinweg vermakelt werden dürfen. In einigen Konfigurationen
werden sowohl Anforderungen als auch Antworten validiert und über die
Sicherheitsgrenze hinweg vermakelt. In anderen Konfigurationen werden
entweder Anforderungen oder Antworten validiert. Um die Validierung
zu unterstützen,
werden Nachrichten gemäß einer
vorab definierten Nachrichtenspezifikation für zumindest einen Teil des
Transaktionspfades zwischen einer Clientanwendung und einer Informationsressource,
auf die die Clientanwendung zugreift, formatiert. In einer Konfiguration zum
Beispiel werden eintreffende Anforderungen von einer Clientanwendung
an einem Proxy empfangen, der eine entsprechende Anforderungsnachricht
formatiert und die formatierte Nachricht an einen Parser zur Validierung
gegen die vorab definierte Nachrichtenspezifikation übergibt.
Typischerweise werden vorab definierte Nachrichtenspezifikationen
als eine Grammatik oder andere funktional beschreibende Datendarstellung
kodiert, die geeignet sind, einen Parser anzuweisen, eine formatierte
Nachricht gegen eine strukturierte Sprachdefinition zu validieren. Nachrichtenspezifikationen
sind typischerweise anwendungs- und transaktionsspezifisch, wenngleich
in einigen Implementierungen Gruppen von Anwendungen und/oder Transaktionen
gemeinsame Nachrichtenspezifikationen gemeinsam nutzen können. In
einer Konfiguration werden Nachrichten gemäß einer Erweiterbaren Auszeichnungssprache
(eXtensible Markup Language, XML) formatiert und Nachrichtenspezifikationen
werden als Datentyp-Definitionen (Data Type Definitions, DTDs) kodiert.
-
Aus
Sicherheitsgründen
werden vorab definierte Nachrichtenspezifikationen vorzugsweise kryptographisch
gesichert (z. B. mittels digitaler Unterschrifttechniken), obwohl
in einer bestimmten Implementierung auch andere Verfahren für das Sichern von
Nachrichtenspezifikationen geeignet sein können. In einigen Konfigurationen
werden sichere Protokolle wie HTTPS eingesetzt. Eine brei te Vielfalt
von Sicherheitsbarrieren kommt in Betracht, wenngleich in einer
beispielhaften Konfiguration die Sicherheitsbarriere Firewall-Technologie
einsetzt. Nur validierte Anforderungsnachrichten werden über die
Sicherheitsbarriere weitergeleitet. Daher können durch geeignete Definition
eines legalen Satzes von Anforderungen (einschließlich bei
einigen Konfigurationen sowohl legaler Schlüsselwort-Tags als auch entsprechender
legaler Wertebereiche) Sicherheitsarchitekturen gemäß der vorliegende
Erfindung Sicherheitsbarrieren überwindende
Anforderungen auf gültige Anforderungen
beschränken.
In ähnlicher
Weise können
in Konfigurationen, die Antwortvalidierung einsetzen, die Sicherheitsbarriere überwindende
Antworten auf gültige
Antworten beschränkt
werden.
-
In
einem Beispiel der vorliegenden Erfindung beinhaltet ein Verfahren
zum Sichern von Datentransaktionen über eine Sicherheitsbarriere
das Validieren einer Anforderungsnachricht gegen eine vorab definierte
Anforderungsnachrichten-Spezifikation, Übermitteln der validierten
Anforderungsnachricht über
die Sicherheitsbarriere, Validieren einer Antwortnachricht gegen
eine vorab definierte Anwortnachrichten-Spezifikation, wobei die
Antwortnachricht der validierten Anforderung entspricht, und Übertragen
der validierten Antwortnachricht über die Sicherheitsbarriere.
-
In
einem anderen Beispiel der vorliegenden Erfindung für eine Netzwerkcomputer-Umgebung beinhaltet
ein Verfahren zum Sichern von Zugriffen auf eine Informationsquelle
hinter einer Sicherheitsbarriere das Vorab-Definieren einer Anforderungsnachrichten-Spezifikation,
die einer strukturierten Anforderungssprache entspricht, das Formatieren
einer Zugriffsanforderung gemäß der strukturierten
Anforderungssprache, das Liefern der formatierten Zugriffsanforderung
an eine erste Zwischenstation, wobei die Zwischenstation die formatierte
Zugriffsanforderung gemäß der Anforderungsnachrichten-Spezifikation
validiert, und das Weiterleiten der validierten Zugriffsanforderung über die
Sicherheitsbarriere. In einigen Abwandlungen ist auch eine Validierung
der Antwortnachrichten vorgesehen. In einer anderen Variante enthält das Verfahren
den Zugriff auf die Informationsressource gemäß der validierten Zugriffsanforderung.
-
In
noch einem anderen Beispiel der vorliegenden Erfindung einer Netzwerkcomputer-Umgebung beinhaltet
ein Verfahren zum Sichern des Zugriffs auf eine Informationsressource
hinter einer Sicherheitsbarriere das Vorab-Definieren einer Antwortnachrichten-Spezifikation,
die einer strukturierten Antwortsprache entspricht, das Formatieren
einer Antwort auf eine Zugriffsanforderung, die auf die Informationsressource
abzielt, wobei die formatierte Antwort im Einklang mit der strukturierten
Antwortsprache ist, das Liefern der formatierten Antwort an eine
Zwischenstation, wobei die Zwischenstation die formatierte Antwort
gemäß der Antwortnachrichten-Spezifikation
validiert, und das Weiterleiten einer validierten Antwort über die
Sicherheitsbarriere. In einigen Abwandlungen ist die Validierung
der Anforderungsnachricht ebenfalls vorgesehen. In einer anderen
Abwandlung beinhaltet das Verfahren den Zugriff auf die Informationsquelle
gemäß der Zugriffsanforderung
von einem Client und das Versorgen des Client mit einer Antwort
gemäß der validierten
Antwort.
-
In
noch einem weiteren Beispiel der vorliegenden Erfindung beinhaltet
ein Informationssicherheitssystem eine Sicherheitsbarriere, einen
Proxy für eine
Informationsressource und einen Datenbroker auf der ersten Seite
der Sicherheitsbarriere. Der Proxy und die Informationsressource befinden
sich auf entgegengesetzten ersten bzw. zweiten Seiten der Sicherheitsbarriere.
Der Datenbroker befindet sich auf der ersten Seite der Sicherheitsbarriere,
wobei der Datenbroker als Reaktion auf eine Zugriffsanforderung,
die auf die Informationsressource abzielt, eine Anforderungsnachricht
gegen eine vorab definierte Anforderungsnachrichten-Spezifikation
validiert und nur validierte Anforderungsnachrichten über die
Sicherheitsbarriere weiterleitet.
-
In
noch einem weiteren Beispiel der vorliegenden Erfindung für eine netzorientierte
Informationsumgebung, die einen Client und eine Informationsressource
beinhaltet, die durch eine Sicherheitsbarriere voneinander getrennt
sind, beinhaltet ein Informationssicherheitssystem Maßnahmen
zum Weiterleiten einer Zugriffsanforderung, die auf die Informationsressource
zielt, von dem Client über
einen Proxy, und zum Vorbereiten einer Anforderungsnachricht, die
der Zugriffsanforderung in einer strukturierten Sprache entsprechend
einer vorab definierten Anforderungsnachrichten-Spezifikation entspricht, und Maßnahmen
zum Validieren der Anforderungsnachricht gegen die vorab definierte
Anforderungsnachrichten-Spezifikation und Weiterleiten ausschließlich von
validierten Anforderungsnachrichten über die Sicherheitsbarriere.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
Unter
Bezug auf die beigefügten
Zeichnungen kann die vorliegende Erfindung besser verstanden werden
und ihre zahlreichen Aufgaben, Merkmale und Vorteile liegen dabei
für Fachleute
auf diesem Gebiet auf der Hand.
-
1 zeigt
ein Informationssicherheitssystem, das eine sichere Datenbroker-Konfiguration
gemäß einer
beispielhaften Ausführungsformen
der vorliegende Erfindung einsetzt.
-
2, 3 und 4 zeigen
ein Informationssicherheitssystem, das eine sichere Daten-Broker-Konfiguration gemäß alternativer
beispielhaften Ausführungsformen
der vorliegende Erfindung einsetzt.
-
Die
Verwendung derselben Bezugszahlen in verschiedenen Zeichnungen weist
auf ähnliche
oder identische Gegenstände
hin.
-
ART(EN) DIE ERFINDUNG
AUSZUFÜHREN
-
1 stellt
eine beispielhafte Ausführungsform
eines Informationssicherheitssystems dar, das eine sichere Datenbroker-Konfiguration
gemäß der vorliegende
Erfindung einsetzt. In der Ausführungsform
von 1 sind drei Teile (ein öffentlicher Netzanteil 101,
ein privater Netzanteil 103 und ein entmilitarisierter
Zonen-Anteil 102) einer netzübergreifenden Umgebung dargestellt.
Nichtsdestoweniger können
andere Netzkonfigurationen und andere Kommunikationsnetzumgebungen
eingesetzt werden. Auf der Basis der vorliegenden Beschreibung erkennen
Fachleute auf diesem Gebiet Clients, Dienste, Protokolle und Schnittstellen,
die für
eine bestimmte Netzumgebung oder Konfiguration geeignet sind.
-
Im
allgemeinen kann eine große
Vielfalt von Entitäten
einschließlich
menschlichen Benutzern, die Browser betreiben und/oder sowohl Client-Anwendungen
ohne Browser als auch automatische Agenten und Systeme mit den hier
beschriebenen sicheren Datenbrokereinrichtungen interagieren. Darüber hinaus
kann eine Vielzahl von Schemata zur Identifikation von Informationsressourcen
wie durch Uniform Resource Locator (URL) Ressourceadreß-, Bezeichner-
oder Namens raum-Zuordnung eingesetzt werden. Für Zwecke der Darstellung und
nicht zur Beschränkung
wird jedoch eine beispielhafte Interaktion, die einen Browser und
eine durch URL identifizierte Informationsressource beinhaltet,
hier genauer beschrieben. Nichtsdestoweniger werden Fachleute auf
diesem Gebiet basierend auf der hier enthaltenen Beschreibung die
Anwendbarkeit der hier beschriebenen gesicherten Datenbroker-techniken
auf andere Clients, Dienste, Anwendungen und Protokolle erkennen.
-
Mit
Blick auf eine beispielhafte Client-Entität vom Typ eines Web (WWW) Browser
wird der Web-Browser 105 von einem Benutzer (nicht abgebildet)
betrieben, um eine Zugriffsanforderung zu übermitteln (1), die
auf eine Informationsressource wie die sicheren bzw. gesicherten
Daten 180 abzielt. Typischerweise wird eine Informationsressource durch
eine entsprechende URL, die zu einem Frontend-Anwendungsserver 110 aufgelöst wird,
als Ziel identifiziert. Der Frontend-Anwendungsserver 110 beinhaltet
einen herkömmlichen
Web-Server und eine Web-basierte Anwendung 112 (z. B. einen
Frontend-Anteil einer Anwendung zur Verarbeitung von Bestellungen)
zusammen mit Einrichtungen, für
die Zugriffsanforderung über
eine sichere Datenbroker-Schnittstelle
als Proxy zu dienen. In der dargestellten Konfiguration befinden
sich sowohl ein entsprechender Backend-Anwendungsserver 150 als auch
die gesicherten Daten 180 hinter einer Sicherheitsbarriere 140,
so daß ein
Zugriff auf Pfade eingeschränkt
ist, die von der nun beschriebenen Konfiguration des sicheren Datenbrokers
definiert werden. In einigen Konfigurationen trennt eine zusätzliche
Sicherheitsbarriere den Web-Browser 105 von der entmilitarisierten
Zone 102 (einschließlich
des Frontend-Anwendungsservers 110 und des sicheren Datenbrokers 120).
-
In
einer beispielhaften Realisierung umfaßt der sichere Datenbroker-Proxy
(SDBProxy) 111 eine Anwendungsprogamm-Schnittstelle (API),
die zum Zugriff auf die Komponenten einer SDB-Konfiguration verwendet werden kann.
Der SDBProxy 111 definiert (eine) Methode(n), die der Anwendung 112 erlauben
(z. B. einer Frontend-Anwendung zur Verarbeitung von Bestellungen),
eine Datenzugriffsanforderung an den SDB-Server 120 zu
senden (4) und eine entsprechende Antwort zu empfangen
(17). In der Konfiguration von 1 empfängt die
Anwendung 112 die eintreffende Zugriffsanforderung (z.
B. als Formulardaten über
ein HTTP POST) und bereitet eine entsprechende Antwortnachricht
vor, die in einer strukturierten Anforderungssprache formatiert
ist. Die spezielle Syntax und Semantik der strukturierten Anforderungssprache
sind anwendungs- und in einigen Fällen transaktionsspezifisch.
Jedoch hat in einer beispielhaften Realisierung die Anforderungsnachricht
die Form einer Zeichenkette oder Zeichenketten in erweiterbarer
Auszeichnungssprache (eXtensible Markup Language, XML), die hierarchische Tag-Wert-Paare
kodiert, um Daten in einer strukturierten und validierbaren Weise
zu übertragen.
Die Anwendung 112 transformiert eine eintreffende Zugriffsanforderung,
indem sie die Struktur der Anforderung versteht und einiges von
dieser Struktur der Anforderungsnachricht aufprägt. Zum Beispiel kann in einer
Anwendung zum Verarbeiten von Bestellungen eine Transaktion oder
ein Teil davon einen Benutzer einbeziehen, der Versandinformationen
bereitstellt (z. B. Empfängername,
Adresse und Lieferverfahren wie U.S. Mail oder aufschlagspflichtiger Übernachtlieferservice).
Typischerweise werden solche Informationen 112 von dem
Web-Browser 105 über
ein HTTP POST von Formulardaten einschließlich Empfängerna me, Adresse und Lieferverfahren
an die Anwendung gesandt. Die Anwendung 112 formatiert
daraufhin eine Anforderungsnachricht (z. B. als eine als Zeichenkette
kodierte XML-Nachricht), die die gesandten Daten gemäß einem
vorab festgelegten für die
Anwendung zur Verarbeitung von Bestellungen spezifischen und transaktionsspezifischen
Format zur Übertragung
(über den
SDBProxy 111) an den SDB-Server 120 kodiert. XML-Tags
sind in einer Nachricht in HyperText-Auszeichnungssprache (HyperText Markup
Language, HTML) eingebettet. In der Konfiguration von 1 erfolgt
die Übertragung
(4) über
eine sichere HTTP-Verbindung.
-
Der
SDB-Server 120 empfängt
die Anforderungsnachricht mittels eines darauf implementierten, herkömmlichen
HTTP-Dienstes und leitet (5) die Anforderungsnachricht
an ein SDB-Servlet 122 zur Validierung. In der Konfiguration
von 1 ruft das SDB-Servlet 122 einen XML-Parser 123 auf
(6), um die Anforderungsnachricht gegen eine Spezifikation der
Anforderungsnachricht zu validieren, die als eine Datentyp-Definition
(DTD) kodiert ist, die der speziellen Anwendung und/oder Transaktion
entspricht. DTDs sind eine standardmäßig Kodierung für Spezifikationen
von Anforderungsnachrichten; jedoch sind auch andere Kodierungen
geeignet. Allgemeiner ist jede Kodierung einer Grammatik, welche
die Syntax einer strukturierten Anforderungssprache definiert, zur
Verwendung mit einem entsprechenden Parser geeignet. Implementierungen
von Parsern sind in der Technik wohlbekannt. Zum Beispiel werden
lex und yacc üblicherweise
eingesetzt, um Parserimplementierungen zu erzeugen und eine Vielfalt
von kommerziellen Produkten ist verfügbar. Im allgemeinen sind geeignete
Parser für
XML oder andere strukturierte Anforderungssprachen leicht verfügbar, und
basierend auf der hier enthaltenen Beschreibung erkennen Fachleute
auf diesem Gebiet eine Vielzahl von geeigneten alternativen Implementierungen.
In einer aktuell bevorzugten Realisierung ist die strukturierte Anforderungssprache
XML, die Spezifikationen der Anforderungsnachricht sind als DTDs
kodiert und die Validierung der Anforderungsnachricht wird mittels eines
XML-Parsers (z. B. XML-Parser 123) durchgeführt, der
als eine JavaTM-Komponente implementiert ist.
Java und alle auf Java beruhenden Marken und Logos sind Handelsmarken
oder eingetragene Handelsmarken von Sun Microsystems Inc. in den
Vereinigten Staaten und anderen Ländern.
-
In
der beispielhaften Konfiguration von 1 wählt der
XML-Parser 123 eine passende DTD unter mehreren DTDs mittels
einer Requestld aus, die von der Anwendung 112 übergeben
wird. Zum Beispiel kann eine Requestld, die eine Anforderungsnachricht als
einem Versandinformationseintrag zugeordnet identifiziert, eine
bestimmte zugehörige
DTD zur Verwendung bei der Validierung der Anforderungsnachricht
auswählen.
In anderen Konfigurationen kann eine einzelne Grammatik-Kodierung
legale Nachrichten definieren, die einer Vielzahl von Transaktionen entsprechen.
In jedem Fall wird die Anforderungsnachricht gegen eine Spezifikation
von Anforderungsnachrichten validiert (7), die für die Anwendung und/oder
Transaktion spezifisch ist. Zum Beispiel kann in einer beispielhaften
Versandinformations-Transaktion die Anforderungsnachricht mittels einer
Spezifikation von Anforderungsnachrichten geparst werden, die erfordert,
daß die
kodierte Versandinformation die Form eines NAME-Tag, gefolgt von einer
Zeichenkette, eines ADDRESS-Tag, gefolgt von mindestens zwei, jedoch
nicht mehr als drei Zeichenketten, und eines SHIPPER-Tag, gefolgt
von einer ganzen Zahl (z. B. der Kodierung einer Versenderauswahl)
annehmen. Andere Kodierun gen würden
bei der Validierung fehlschlagen, und eine Fehlerantwort würde typischerweise
erzeugt werden. Man beachte, daß eine
Anforderungsnachricht, die nicht validiert ist, nicht über die
Sicherheitsbarriere 140 übermittelt wird. In einigen
Konfigurationen können
sowohl die Struktur der Anforderungsnachricht als auch die darin
kodierten Werte validiert werden. Zum Beispiel kann eine maximale
Zeichenkettenlänge
in einer Spezifikation von Anforderungsnachrichten kodiert sein.
Auf diese Weise können
viele Pufferüberlauf-artige
Angriffe entschärft
werden. Darüber hinaus
können
Werte gegen Wertebereiche (z. B. Versendernummern zwischen 1 und
5), Randbedingungen bezüglich
des Inhalts oder auf Konsistenz mit einem erwarteten Datentyp (z.
B. einer Zeichenkettenkodierung gemäß einem bekannten Zeichensatz) qualifiziert
werden. Unter Bezug beispielsweise auf die Konfiguration von 1 und
auf ein XML-Anforderungsnachrichtenformat leitet in dem Fall, daß eine XML-kodierte
Anforderungsnachricht erfolgreich mittels einer entsprechenden DTD
geparst wird, das SDB-Servlet 122 die XML-Anforderung über eine
sichere HTTP-Verbindung an einen anderen SDB-Web-Server (z. B. SDB-Server 160) über die
Sicherheitsbarriere 140 weiter (8). Ansonsten
wird eine Fehlerantwortnachricht kreiert und an den SDBProxy 111 zurückgeliefert
(17).
-
Der
SDB-Server 160 empfängt
eine validierte Anforderungsnachricht (8) über die
Sicherheitsbarriere 140 und mittels eines darauf implementierten, herkömmlichen
HTTP-Dienstes und leitet die Anforderungsnachricht (9)
an ein SDB-Servlet 162 zur Weitergabe (10) an
den Backend-Anwendungsserver 150 über eine
sichere HTTP-Verbindung. Der Backend-Anwendungsserver 150 liefert
(11) seinerseits die validierte Anforderungsnachricht,
die in einer beispielhaften Ausführungsform
XML-kodiert ist, an die darauf betriebene Web-basierte Anwendung 152 (z. B.
einen Backend-Anteil
einer Anwendung zur Verarbeitung von Bestellungen). Die Anwendung 152 verarbeitet
die validierte Anforderungsnachricht, indem die zugehörigen sicheren
Daten 180 geholt oder aktualisiert werden (12).
Zum Beispiel kann im Fall einer Zugriffsanforderung, die Versandinformationen übermittelt,
die Anwendung 152 einen Kundendatensatz in einer Datenbank
anlegen oder aktualisieren, um die kodierte Versandinformationen
zu beinhalten. Ein Zugriff durch die Anwendung 152 auf
die sicheren Daten 180 kann über irgendeine aus einer Anzahl von
geeigneten Techniken erfolgen. Zum Beispiel können die sicheren Daten 180 in
einer relationalen Datenbank dargestellt sein, und die Anwendung 152 kann
mit einem zugeordneten Datenbank-Management-System (DBMS) mittels
Strukturierter Abfragesprache (Structured Query Language, SQL) interagieren.
Man beachte, daß in
einer solchen SQL-basierten Konfiguration die Sicherheit der sicheren
Daten 180 verbessert wird, indem die Transaktion gezwungen
wird, die Validierung am SDB-Server 120 zu durchlaufen
und genauer gesagt nicht zuzulassen, daß eine Zeichenkettenkodierung
einer SQL-Anweisung direkt durch die Sicherheitsbarriere 140 auf
eine SQL-Maschine durchgereicht wird. Im allgemeinen sind das Speicherformat
für die
sicheren Daten 180 und der von der Anwendung zum Zugriff auf
die sicheren Daten 180 verwendete Mechanismus (z. B. SQL,
JDBC, RPC, etc.) anwendungsspezifisch und brauchen eine bestimmte
sichere Datenbroker-Konfiguration nicht zu beeinflussen.
-
Man
beachte, daß in
der beispielhaften Konfiguration von 1 weder
der Web-Browser 105 noch die sicheren Daten 180 die
gewählte
strukturierte Anforderungssprache (z. B. XML) zu erzeugen oder zu
verstehen brauchen. Als eine Konsequenz können sichere Datenbroker- Einrichtungen ohne Änderung
des Browsers oder der Informationsressource zwischen bestehende
kommerzielle Ausführungsformen
von Browsern und Informationsressourcen positioniert werden. In
anderen Konfigurationen können
von dem Web-Browser 105 und den sicheren Daten 180 einer
von beiden oder beide XML-Unterstützung integrieren. Im Falle
des Web-Browsers 105 kann die XML-Unterstützung die Form eines Plug-In oder
eine andere unterstützungsspezifische
Form für eine
Suite bzw. Sammlung von eCommerce-Anwendungen annehmen.
-
Sobald
die validierte Anforderungsnachricht durch Holen oder Aktualisieren
von sicheren Daten 180 bedient wurde, wird eine Antwort
geliefert. Zum Beispiel kann die Anwendung 152 als Reaktion
auf einen erfolgreichen Eintrag von Versandinformationen eine Bestätigungsnummer
für die
Bestellung zur Lieferung an den Web-Browser 105 erzeugen.
In der Konfiguration von 1 werden die Antwortnachrichten
gleichfalls gemäß einer
strukturierten Antwortsprache kodiert und gegen eine Spezifikation
der Antwortnachtrichten (z. B. eine Antwort-DTD) validiert. Der
SDB-Server 160 empfängt
(13) die Antwortnachricht über die vorhandene sichere HTTP-Verbindung
und leitet (9) die Antwortnachricht an das SDB-Servlet 162 zur
Validierung. Wie zuvor ruft (14) das SDB-Servlet (z. B.
das SDB-Servlet 162) einen XML-Parser 163 zum
Validieren der Antwortnachricht gegen eine Spezifikation der Antwortnachrichten
auf, die als eine Datentyp-Definition (DTD) entsprechend einer bestimmten
Anwendung und/oder Transaktion kodiert wurde.
-
In
der beispielhaften Konfiguration von 1 wählt der
XML-Parser 163 eine passende DTD unter mehreren DTDs mittels
einer Responseld aus, die von der Anwendung 152 übergeben
wird. Zum Beispiel kann eine Responseld, die eine Antwortnachricht
als mit der Versandbestätigung
verbunden identifiziert, eine bestimmte entsprechende DTD zur Verwendung
bei der Validierung der Antwortnachricht auswählen. Wie zuvor können andere
Kodierungen (z. B. als eine Grammatik) zulässige Nachrichten definieren.
In jedem Fall wird die Antwortnachricht gegen eine Antwortnachricht-Spezifikation validiert (15),
die für
die Anwendung und/oder Transaktion spezifisch ist. Zum Beispiel
kann in der beispielhaften Versandinformations-Transaktion die Antwortnachricht
mittels einer Antwortnachricht-Spezifikation geparst werden, die
es erfordert, daß die
kodierte Information die Form eines CONFIRMATION_NUMBER-Tag, gefolgt
von einer Zeichenkette von vorab festgelegter Länge, annimmt. Man beachte,
daß eine
Antwortnachricht, die nicht validiert wird, nicht über die
Sicherheitsbarriere 140 übermittelt wird. Stattdessen
wird typischerweise eine Fehlerantwort über die vorhandene sichere HTTP-Verbindung übermittelt
(16).
-
Wenn
stattdessen die Antwortnachricht validiert wird, wird eine validierte
Antwortnachricht über die
Sicherheitsbarriere 140 hinweg über die vorhandene sichere
HTTP-Verbindung zu dem SDB-Server 120 übermittelt (16). Der
SDB-Server 120 gibt seinerseits die validierte Antwortnachricht
an den SDBProxy 111 bei dem Frontend-Anwendungsserver 110 über die
vorhandene sichere HTTP-Verbindung weiter (17). In der
beispielhaften Ausführungsform
von 1 extrahiert der SDBProxy 111 seinerseits
Antwortdaten aus der XML-formatierten, validierten Antwortnachricht
und liefert die Antwortdaten an die Anwendung 112 (z. B.
einen Frontend-Anteil einer Anwendung zum Verarbeiten von Bestellungen).
Zum Beispiel kann eine kodierte Bestätigungsnummer für die Bestel-lung an die Anwendung 112 geliefert
werden. Schließlich
liefert der Frontend-Anwendungsserver 110 eine Antwort
(18) (einschließlich
z. B. einer Bestätigungsnummer
für die
Bestellung) an den Web-Browser 105 zur Darstellung für dessen
Benutzer. Man beachte, daß der
SDBProxy 111 eine offene HTTPS-Verbindung mit dem SDB-Server 120 für die Dauer
jeder XML-Anforderungsnachricht (4) unterhält, um die
Transaktion der Antwortnachricht (17) zu validieren. Mehrere
Instanzen des SDBProxy 111 (und in ähnlicher Weise von anderen
Komponenten in einer bestimmten sicheren Datenbroker-Konfiguration)
können
eingesetzt werden, um mehrere gleichzeitige Anforderungen zu behandeln.
Jede SDBProxy-Instanz ist vorzugsweise einstrangig (single-threaded),
um die Korrelation von Anforderungen und Antworten zu erleichtern,
obwohl andere Techniken wie sichere Transaktionsbezeichner (z. B.
Token) auch eingesetzt werden können.
-
In
der Konfiguration von 1 ist die Sicherheitsbarriere 140 ein
Beispiel für
eine Vielzahl von Strukturen und/oder Verfahren, durch die der Backend-Anwendungsserver 150 vor
direktem Zugriff aus dem öffentlichen
Netz 101 oder der entmilitarisierten Zone 102 geschützt wird
oder werden kann. Eine Realisierung der Sicherheitsbarriere 140 enthält eine
Firewall oder andere selektive Filter, auch wenn Paketfilter, Firewall
oder Bastion-Server-basierte Sicherheitsbarrieren zur Zeit vorgezogen
werden. Andere Einrichtungen sind ebenfalls geeignet, zum Beispiel
serverbasierte Einrichtungen, die sicherstellen, daß der SDB-Server 160 nur
Verbindungsanforderungen von dem SDB-Server 120 akzeptiert
und durch die der Backend-Anwendungsserver 150 und andere ähnlich gelegene
Backend-Anwendungsserver nur Verbindungsanforderungen von dem SDB-Server 160 akzeptieren,
können
als Sicherheitsbarriere 140 oder als Teil davon eingesetzt
werden. Eine Bastion-Server-Implementierung setzt einen Server dazwischen,
der Einrichtungen, die separat als SDB-Server 120 und SDB-Server 160 dargestellt
sind, auf einer einzigen Server-Plattform beherbergt.
-
Die
Integrität
einer sicheren Datenbroker-Konfiguration erfordert im allgemeinen,
daß Spezifikationen
der Anforderungs- und Antwortnachrichten (z. B. Anforderungs-DTDs 130 und
Antwort-DTDs 170)
gesichert sind; allerdings ist irgendeiner aus einer Vielzahl von
Mechanismen geeignet. Zum Beispiel verbessert die Verwendung von
Sicherheitsbarrieren 140 und 141 tendenziell die
Sicherheit der Nachrichtenspezifikation. In einigen Konfigurationen werden
Spezifikationen der Anforderungs- und Antwortnachrichten kryptographisch
gesichert, um nicht-autorisierte Änderungen zu verhindern. Herkömmliche
digitale Unterschriften oder Verschlüsselungs-basierte Techniken
können
eingesetzt werden. Alternativ können
Spezifikationen der Anforderungs- und/oder Antwortnachrichten auf
nur lesbaren Medien kodiert werden, um nicht-autorisierte Änderungen zu
verhindern.
-
Die 2–4 stellen
einige Varianten der oben beschriebenen sicheren Datenbroker-Konfiguration dar.
Wie zuvor dienen die beispielhafte Web-(WWW)-Browser-artige Client-Entität und die Internet-Komponenten
nur der Veranschaulichung. Für
andere Netzumgebungen geeignete Clients, Server. Protokolle und
Schnittstellen liegen für
Fachleute auf diesem Gebiet, basierend auf der hier gegebenen Beschreibung,
auf der Hand. 2 stellt eine Konfiguration
dar, in der nur Anforderungsnachrichten gegen entsprechende Spezifikationen
der Anforderungsnachrichten validiert werden. Eine solche, nur die
Anforderungen validierende Konfiguration verbessert tendenziell
den Durchsatz. Im allgemeinen sind falsch aufgebaute oder böswillige
Anforderungen eine größere Bedrohung
als falsch aufgebaute oder böswillige
Antworten, besonders in Konfigurationen eines privaten Netzes 103,
für welche
die Integrität
von Anwendungen einigermaßen
sichergestellt werden kann. Dementsprechend wird auf die Validierung
der Antwortnachricht 13A verzichtet und der Backend-Anwendungsserver 150 braucht
die Antwortnachricht nicht in XML zu kodieren. Nichtsdestoweniger
können
einige Konfigurationen gemäß der vorliegenden
Erfindung XML-Kodierung von Antwortnachrichten entlang zumindest
eines Teils des Rückgabepfades
(13A, 17) zu dem Frontend-Anwendungsserver 119 beinhalten.
In der Konfiguration von 2 ist die Rolle des SDB-Servers 160A ziemlich
eingeschränkt,
indem er nur als ein Weitergabe-Punkt dient. In Konfigurationen,
bei denen die Sicherheitsbarriere 140 eine Firewall beinhaltet,
kann die Verwendung eines Weitergabe-Punktes die Konstruktion von Paketfiltern
vereinfachen.
-
3 stellt
eine Konfiguration dar, bei der der SDB-Server 160 beseitigt
ist, in der validierte Anforderungsnachrichten (10B) direkt
von dem SDB-Server 120B an den Backend-Anwendungsserver 150 geliefert
werden und in der Antwortnachrichten direkt von dem Backend-Anwendungsserver 150 an
den SDB-Server 120B zurückgegeben
werden (13B). Antwortnachrichten werden ihrerseits zurück an den
SDBProxy 111 weitergegeben (17). Eine Vielzahl
von Konfigurationen gemäß 3 einschließlich Bastion-Server-Implementierungen
liegen für
Fachleute auf diesem Gebiet, basierend auf der hier gegebenen Beschreibung,
auf der Hand. Zum Beispiel ist in einer solchen Konfiguration der
SDB-Server 120B auf einem Server beheimatet, der die Routing-Schnittstelle zwischen
der entmilitarisierten Zone 102 und dem privaten Netz 103 bereitstellt.
Wie zuvor braucht der Backend-Anwendungsserver 150 die
Antwortnachricht nicht in XML zu kodieren, auch wenn einige Konfigurationen
gemäß der vorliegenden
Erfindung XML-Kodierung von Antwortnachrichten entlang zumindest
eines Teils des Rückgabepfades
(13A, 17) zu dem Frontend-Anwendungsserver 110 beinhalten
können.
Obgleich in 1 nicht abgebildet, kann ein
solcher Ansatz auch in Konfigurationen eingesetzt werden, in denen
eine Validierung sowohl der Anforderungsnachrichten als auch der
Antwortnachrichten durchgeführt
wird. In einer solchen Konfiguration (nicht abgebildet) könnten Einrichtungen
des SDB-Servers 120 und des SDB-Servers 120 auf
einem Bastion-Server liegen, der als eine zwischen den Frontend-Anwendungsserver 110 und
den Backend-Anwendungsserver 150 zwischengeschaltete Sicherheitsbarriere
fungiert.
-
4 stellt
noch eine weitere Konfiguration gemäß der vorliegenden Erfindung
dar. Obwohl vorige Konfigurationen verbindungsorientierte Verwendung
von Protokollen wie HTTP (oder HTTPS) eingesetzt haben, stellt die
Konfiguration von 4 eine sichere Datenbroker-Konfiguration
dar, in der eine Antwort (13C) nicht über eine vorhandene Verbindung
zurückgegeben
zu werden braucht. Stattdessen werden die Anforderungsnachricht 4C,
die validierte Anforderungsnachricht 10C und die Antwortnachricht 13C mittels
asynchroner Protokolle transportiert. Zum Beispiel können MQSeries-Protokolle eingesetzt
werden. Alternativ kann HTTP in einer unkonventionellen Weise eingesetzt
werden. Zum Beispiel können
die Anforderungsnachricht 4C und die validierte Anforderungsnachricht 10C jeweils
durch HTTPS-Verbindungen transportiert werden, die zu Ende gehen.
Danach kann die Antwortnachricht 13C durch eine unabhängige Transaktion
transportiert werden. Konfigurationen, die andere asynchrone Protokolle
einsetzen, liegen für
Fachleute auf diesem Gebiet, basierend auf der hier gegebenen Beschreibung,
auf der Hand. Die Konfiguration von 4 stellt
einige Sicherheitsherausforderungen wie Schutz gegen Spoofing und
richtungsspezifisches ALLOW/DENY-Verhalten der Sicherheitsbarriere 140C dar.
Nichtsdestoweniger können
Techniken einschließlich
auf dem Einsatz von Token basierter Berechtigungsnachweise (d. h.
Berechtigungsnachweise, die mit der Nachrichtensequenz übergeben werden)
und asymmetrische Paketfilterdefinition eingesetzt werden, um diese
Herausforderungen zu bewältigen.
Wenngleich nicht abgebildet, kann wie zuvor die Funktionalität des SDB-Servers 120C und
der Sicherheitsbarriere 140C auf einem Bastion-Server gelegen
sein, der zwischen die entmilitarisierte Zone 102 und das
private Netz 103 geschaltet ist.
-
In
einigen beispielhaften Ausführungsformen sind
zumindest einige der oben beschriebenen Komponenten als Servlets
implementiert, die in dem Kontext einer kommerziell verfügbaren Webserver-Umgebung
ausführbar
sind. Zum Beispiel ist die JavaTM Embedded
Server (JES) Architektur mit Erweiterungen für Zertifikatsbehandlung, HyperText
Transfer Protocol (HTTP), Simple Network Management Protocol (SNMP),
Secure Socket Layer (SSL), eXtensible Markup Language (XML) Grammatikverarbeitung und
Sicherheits-Access Control List (ACL)-Unterstützung, erhältlich von Sun Microsystems
Inc., eine geeignete Umgebung. Java und alle auf Java beruhenden
Marken und Logos sind Handelsmarken oder eingetragene Handelsmarken
von Sun Microsystems Inc. in den Vereinigten Staaten und anderen
Ländern. In
einigen Konfigurationen sind Teile einer sicheren Datenbroker-Implementierung
in einem einfachen Bezugssystem wie dem eingebetteten Java-Server zum
Erzeugen von verteilten Diensten implementiert. Java-Servlets können in
das Bezugssystem in einer sicheren Weise dynamisch eingefügt werden.
Das Bezugssystem handelt dann die Kommunikation zwischen den Servlets
ab.
-
Im
allgemeinen ist die hier gegebene Beschreibung auf Aspekte einer
sicheren Datenbroker-Einrichtung
ausgerichtet, statt auf Besonderheiten einer bestimmten Implementierungsumgebung. Es
ist vorgesehen, daß sichere
Datenbroker-Einrichtungen gemäß den Lehren
der vorliegenden Erfindung sowohl im Kontext vieler kommerziell
verfügbarer
netzbasierter Informationsdienst-Umgebungen einschließlich Webserver-Umgebungen
als auch in kundenspezifischen Umgebungen und Umgebungen, die in
Zukunft entwickelt werden, implementiert werden kann. Um jedoch
ein Verständnis
der umfassenden Konzepte mittels einer speziellen Beispielumgebung
zu erleichtern und ohne Einschränkung kann
die hier gegebene Beschreibung Terminologie enthalten, die für bestimmte
beispielhafte Serverarchitekturen (z. B. Java-Webserver- und Java-Embedded-Server-Architekturen), Protokolle
(z. B. HTTPS) und Bezugssysteme strukturierter Sprachen (z. B. XML)
spezifisch ist. Nichtsdestoweniger liegen, basierend auf dieser
Beschreibung, für
Fachleute auf diesem Gebiet Implementierungen auf der Hand, die für andere
Umgebungen geeignet sind. Der Schutzumfang der Erfindung, wie durch
die nachfolgenden Ansprüche
definiert, ist nicht auf irgendeine spezifische Implementierungsumgebung
beschränkt.
-
Während die
Erfindung mit Bezug auf verschiedene Ausführungsformen beschrieben wurde, versteht
es sich, daß diese
Ausführungsformen
nur beispielhaft sind und der Bereich der Erfindung nicht darauf
beschränkt
ist. Viele Abwandlungen, Änderungen,
Hinzufügungen
und Verbesserungen sind möglich.
Zum Beispiel sind die Grenzen zwischen verschiedenen Komponenten,
Diensten, Servlets, Registrierungen und Bezugssystemen in gewisser Weise
beliebig und bestimmte Operationen sind im Kontext spezifischer
beispielhafter Konfigurationen dargestellt. Andere Zuordnungen von
Funktionalität kommen
in Betracht und können
in den Bereich der nachfolgenden Ansprüche fallen. Strukturen und Funktionalität, die als
diskrete Komponenten in der bzw. den beispielhaften Ausführungsformen)
dargestellt wurden, können
als eine kombinierte Struktur oder Komponente implementiert werden.
Diese und andere Abwandlungen, Änderungen,
Hinzufügungen und
Verbesserungen können
in den Schutzumfang der Erfindung fallen, wie in den folgenden Ansprüchen definiert.