Sicherheit beim E-Commerce
| Jürgen Rieber, Hugo-Eckener-Schule Friedrichshafen |
|
Einleitung Überall dort, wo Waren im Internet verkauft oder Dienstleistungen in Anspruch genommen werden, sind die Online-Kassen gefragt. Inzwischen bieten eine Vielzahl von Herstellern Komplettlösungen an, deren Standardfunktionalität weit über die sichere Bezahlungsmöglichkeit im Internet hinausgeht. Den Shop-Betreibern wird durch die Software die Möglichkeit gegeben, ihre Website auf komfortable Weise zu administrieren. Dazu gehört u. a. die Gestaltung des Produktkatalogs, die Definition von Rabatten und Sonderangeboten sowie die Verwaltung und Auswertung von Benutzerprofilen. Kundenseitig bieten die Systeme eine einfache und übersichtliche Navigation durch den meist hierarchisch strukturierten Online-Katalog. Eine mit dem realen Einkaufswagen vergleichbare Warenkorbfunktionalität lässt den Besucher zuerst im Angebot des Händlers stöbern und seine Auswahl treffen, bevor er zur Kasse gebeten wird. Das komplexe Transaktionsmanagement des mehrstufigen Einkaufvorgangs wird ebenfalls von der Shop-Software abgedeckt, zu dem die
gehört. Die Softwarepakete sind modular aufgebaut. Sie bestehen zumeist aus einem Web-Server und einer Datenbank sowie Administrationstools und produktspezifischen Bindegliedern, die diese Komponenten zu einem funktionierenden Gesamtsystem vereinen. Datenbankabfragen werden über ein CGI-Programm oder eine serverspezifische Erweiterung an die externe Shop-Anwendung weitergereicht. Über eine permanente Verbindung zur Datenbank werden nach festgelegten Regeln individuelle Angebote generiert, dynamische Katalogseiten erstellt oder den Warenkörben der Kunden neue Produkt hinzugefügt. Je nach Komplexität der eingesetzten Software verweisen intelligente Systeme auf Basis vorhandener Kundeprofile auch auf zusätzliche Produkte, die das Interesse des Käufers und somit den Umsatz steigern sollen. Die Integration von Verfahren zur Abwicklung des elektronischen Zahlungsverkehrs über das Internet, der eine immer wichtigere Rolle in kommerziellen Geschäftsbeziehungen zwischen Anbietern und Endkunden, dem sog. Business-to-Consumer Commerce, spielt, wird auf ihre Sicherheitsanforderungen hin betrachtet. Davon gänzlich verschieden können die Anforderungen in einem virtuellen Verbund zwischen Geschäftspartnern sein, dem Business-to-Business Commerce. Datenbankanbindung im Internet (Punkte 1-4, 6 -7) Da die Online-Shops technisch gesehen mehr oder minder komplexe Datenbankanwendungen mit Schnittstelle zum Internet und integrierter Bezahlungsmöglichkeit darstellen, haben Maßnahmen zur Sicherstellung von Vertraulichkeit, Integrität, Verbindlichkeit und Anonymität höchste Priorität. Oftmals ist der Zugriff auf interne Firmendaten notwendig, der einige Sicherheitsprobleme aufwirft, aber aufgeschlossenen Konsumenten und ideenreichen Anbietern auch eine Reihe von Vorteilen bietet. Erstmals steht im Gegensatz zu anderen elektronischen Massenmedien wie CD-ROM-Katalogen, Radio oder Fernsehen mit dem Internet ein direkter Rückkanal zur Verfügung, über den die Interessen der Besucher individuell erfasst und ausgewertet werden können (one-to-one marketing). Zudem werden Medienbrüche vermieden, da der Kunde als aktiver Teilnehmer bei der Auftragsabwicklung seine Daten selbst eingibt. Geschäftsprozesse werden dadurch beschleunigt, fehlerhafte Eingaben vermieden und letztlich Kosten reduziert. Im Geschäftskundenbereich (business to business) fallen deutlich weniger Kommunikations- und Infrastrukturkosten im Vergleich zu proprietären Systemen an, da Standardsoftware zum Einsatz kommt und teure Mietleitungen entfallen. Die Entwicklung funktionaler Anwendungen im Internet bedingt allerdings eine Nutzbarmachung interner Informationsressourcen, die in nahezu keinem Unternehmen in einem der HTML-Spezifikation entsprechenden Darstellungsformat vorliegen. In den meisten Fällen sind relationale Datenbanksysteme im Einsatz, die den Datenbestand strukturiert in Tabellen verwalten. Darauf zugegriffen wird über eigenentwickelte Anwendungen oder eine Standardsoftware wie SAP R/3, die standardisierte Geschäftsprozesse in ihrer Programmlogik abbildet. Als Abfragesprache kommt in der Regel die von der ISO genormte Structured Query Language (SQL) oder einer ihrer herstellerspezifischen Dialekte zum Einsatz. Die Abfrage von Daten wird in SQL beispielsweise mit der SELECT Anweisung formuliert. Das DBMS antwortet entweder mit einem konkreten Datensatz, einer größeren Ergebnismenge oder einer Fehlermeldung. Es können weiterhin Datensätze hinzugefügt (INSERT), geändert (UPDATE) oder aus den Tabellen gelöscht (DELETE) werden. Für die Erteilung von Zugriffsrechten (GRANT) auf die Daten sind im Standard eigene Sprachkonstrukte zur Datendefinition enthalten. Mittlerweile existieren die unterschiedlichsten Ansätze, Web-Server und firmeninterne Datenbanken miteinander zu koppeln. Zum einen kann eine erweiterte Anwendungslogik über den Web-Server auf die Daten im DBMS zugreifen, sie entsprechend den Benutzeraktionen auslesen, ändern oder löschen. Eine andere Möglichkeit besteht darin, die vorhandenen Funktionen in den existierenden Applikationen zu nutzen, und sie über ein spezielles Web/Datenbank-Gateway anzusteuern. In diesem Fall müssen die Transaktionen im Internet auf die des bestehenden Systems umgesetzt werden. Voraussetzung dafür ist allerdings, daß die vorhandenen Anwendungen für derartige Integrationsvorhaben ausgelegt sind und eine offene API bieten. Ein Beispiel dafür ist der SAP Internet Transaction Server. Die vom DBMS generierte Antwort muß abschließend in HTML-Code transformiert werden, um sie auf einem Web-Browser anzeigen zu können. Für die meisten interaktiven Anwendungen bleibt der anonyme Benutzerzugriff der normale Zugriff. Erst mit dem Aufruf von Funktionen, die auf kundenindividuelle Informationen wie spezielle Preisnachlässe oder den Auftrags- und Lieferstatus zugreifen, sollte sich der Anwender vorher als nutzungsberechtigte Person identifizieren. Ist er einmal gegenüber dem System bekannt, muss ein systemübergreifendes Zugriffskonzept dafür sorgen, dass weder die Dateien auf dem Web-Server noch die Daten im DBMS unrechtmäßig ausgelesen oder manipuliert werden können. Andererseits haben auch die Benutzer ein Recht darauf, einen Identitätsnachweis vom Serviceanbieter zu verlangen, der ihn zweifelsfrei als den tatsächlichen Betreiber des Systems auszeichnet. Zu den anwendungsspezifischen Zugriffskontrollen müssen die operativen Systeme auch vor Angriffen über die Netzwerkprotokolle geschützt werden. Schließlich ist die Firewall nun nicht mehr länger nur eine Einbahnstraße für den internen Datenverkehr; sondern hat sich gegebenenfalls auch Anfragen aus dem externen Netz zu öffnen, die Verbindungen zu den vorhandenen Systemen im Unternehmensnetz aufbauen wollen. Die Identifikations- und Transaktionsdaten müssen zum Schutz beider Kommunikationspartner vertraulich behandelt und vor Manipulationen geschützt übertragen werden. Dies gilt es vor allem auf der Wegstrecke über das Internet zwischen dem Browser des Kunden und dem Web-Server des Anbieters sicherzustellen. Von größerer Bedeutung ist in diesem Zusammenhang vielmehr die Korrektheit der übermittelten Daten. So ist z.B. bei einem elektronischen Bestellwesen die Abnahmemenge oder Lieferadresse in aller Regel keine Information, die für Außenstehende von besonderem Interesse ist. Eine Integritätsverletzung dieser Daten würde hingegen einen unnötigen Zeit- und Kostenaufwand auf beiden Seiten verursachen. Mit der Integration des Internet in die wichtigsten Geschäftsprozesse eines Unternehmens steigt auch die Abhängigkeit in die Verfügbarkeit der angebotenen Dienste. Ausfälle bedeuten je nach Dauer und Häufigkeit ihrer Nutzung einen irreparablen finanziellen Schaden. Vom Umfang der bereitgestellten Funktionen abhängig ist das erforderliche Maß an Verbindlichkeit. Die Suche in einem dynamisch aus internen Datenquellen erstellten Produktkatalog oder offenen Stellenanzeigen verlangt selbstverständlich noch kein unwiderrufliches Nachweisverfahren. Wird die Website dagegen als Verkaufswerkzeug eingesetzt, um Bestellungen von Kunden und Geschäftspartnern in der Datenbank zu sammeln, dann empfiehlt es sich, die automatische Weiterleitung an die Warenauslieferung von einer verbindlichen Bestätigung des Käufers abhängig zu machen. Der Verfügbarkeit ist eine hohe Bedeutung beizumessen. Diese betreffen vorrangig die beiden Hauptkomponenten der Anwendung, das Datenbanksystem und den Web-Server. Die Datenbank muss als besonders abzusicherndes System betrachtet werden, da sie unternehmensinterne Daten verwaltet, die indirekt aus dem Internet abgerufen werden. Systemausfälle oder -anomalien in Folge von erfolgreichen Einbrüchen haben damit auch einen direkten Einfluss auf interne Arbeitsabläufe. Kommt es trotz sorgfältiger Schutzmaßnahmen zu unberechtigten Zugriffen, dann muss die Integrität der Daten so schnell und zeitnah wie möglich wiederhergestellt werden. Die meisten Datenbanksysteme verfügen zu diesem Zweck über einen eigenen Backup- und Recovery-Mechanismus, der verlorengegangene Daten im flüchtigen Speicher und auf der Festplatte sowie unvollendete Transaktionen rekonstruieren kann. Dazu muss im Rahmen eines Datensicherungskonzeptes regelmäßig ein komplettes Abbild der Datenbank erstellt werden, mit dem der Status zu einem bestimmten Zeitpunkt vor Eintritt des Zwischenfalls rekonstruiert werden kann . Außerdem zeichnet ein Datenbanksystem alle abgeschlossenen Transaktionen in einer separaten Log-Datei auf. Mit diesem Protokoll lassen sich anschließend alle Änderungen im Datenbestand wieder einspielen, die zwischen der Erstellung des Image und dem Störfall stattgefunden haben (roll-forward recovery). Image, Änderungsprotokoll und die Datenbank sollten auf getrennten Medien gespeichert werden, um das Risiko eines kompletten Datenverlusts bei einem Hardwareausfall zu minimieren und die Performance zu verbessern. Durch den Zugriff auf die unternehmensinternen Informationen über das Internet wird der Web-Server unvermeidlich zum zentralen Vermittler zwischen dem Datenbanksystem und den Web-Browsern der Kunden. Neben seiner ursprünglichen Aufgabe, statische HTML-Dateien im Dokumentenverzeichnis aufzusuchen und an den Benutzer zurückzuschicken, wird er nun außerplanmäßig noch mit der Formulierung von Datenbankabfragen und der Aufbereitung der Ergebnisse in Form von dynamisch generierten Web-Seiten belastet. Um die Leistung des Servers für den erhöhten Datendurchsatz und die stärkere Prozessorbelastung zu optimieren, bleibt neben einer soliden Hardwareausstattung ein Feintuning oftmals nicht aus. Die meisten Produkte bieten hier vielfältige Möglichkeiten. So können z. B. oft abgerufene Dokumente, wie die Homepage oder das Bestellformular zum Programmstart in den Arbeitsspeicher geladen werden. Dadurch werden beispielsweise die Antwortzeit erheblich verbessert und Zugriffe auf die Platte minimiert. Abhängig von der Größe des Hauptspeichers ist es auch sinnvoll, eine bestimmte Anzahl von Prozessen auf Abruf vorzuhalten. Eingehende HTTP-Requests können sofort bearbeitet werden, und der Server muss nicht jedesmal erst eine Kopie erstellen. Gleiches gilt für Systeme, die mit mehreren prozeßinternen, quasi-parallelen Programmpfaden (engl. threads) arbeiten. Konzept 1 Der wohl einfachste, aber zugleich auch am wenigsten flexible und aus Sicht der Performance ungünstigste Ansatz ist die Verbindung eines HTTP-Daemons mit der Datenbank über ein CGI-Skript Nachdem der Browser das HTML-Formular vom Web-Server empfangen hat (1), macht der Benutzer seine Eingaben und sendet sie via HTTP GET- oder POST-Befehl zurück. Im Anschluß daran wird ein CGI-Skript auf dem Web-Server gestartet. Der in obiger Abbildung zweistufige Ansatz ist für den Datenbankzugriff besonders geeignet, weil auf diese Weise der Web-Server und der DB-Server räumlich getrennt werden können. Das DBMS läuft hinter dem Firewall, und ist somit vor direkten Zugriffen geschützt. Der Web-Server verbleibt zwar vor dem Firewall wird aber durch den Paketfilter vor unerwünschten Datenpaketen abgeschirmt. Für die Kommunikation zwischen dem Web-Server und der Datenbank sollte nach Möglichkeit ein TCP-Relay auf dem Firewall installiert werden. Ähnlich einem Mail-Relay dienen diese einfachen Programme dazu, TCP-Verbindungen wie ein Proxy stellvertretend zwischen dem internen und externen Netzwerksadapter hin und her zu kopieren. Der Relay darf nur Pakete vom Web-Server an das interne System weiterleiten, die sich über ihre Absenderadresse und Portnummer eindeutig der Anwendung auf dem Web-Server zuordnen lassen. Durch den Einsatz des Relays ist es nicht notwendig, das IP-Routing auf der Firewall zu aktivieren. Die CGI-Anwendung nimmt eine Plausibilitätsprüfung vor und formuliert aus den Benutzereingaben eine SQL-Abfrage (3), die entweder über die Funktionsbibliothek eines produktspezifischen Datenbank-Clients (z. B. in C mit Embedded SQL) oder eine Middleware wie ODBC (Open Database Connectivity) an den DBMS-Server abgesetzt wird. ODBC definiert eine herstellerneutrale SQL-Schnittstelle, die zwischen den proprietären APIs der Datenbanksysteme und den Anwendungen liegt. Spezielle Treiber nehmen die standardisierten SQL-Anweisungen entgegen, formulieren sie entsprechend den systemspezifischen Abfragekonventionen um und leiten die Ergebnisse an die Anwendung zurück. Ein großer Vorteil des Konzeptes liegt darin, dass existierende Programme nicht angepasst werden müssen, wenn z.B. aufgrund von Leistungsengpässen ein neues DBMS installiert wird. Bevor die Daten ausgelesen oder verändert werden können, muss sich der Client beim Datenbankserver ordnungsgemäß mit einer User-ID und Passwort anmelden. Bei anonymen Abfragen ist die Verwendung einer dem Web-Server zugeordneten Benutzerkennung (z. B. WWW) für den Zugriff zu empfehlen, die über die notwendigen Berechtigungen der Internet-Anwendung in der Datenbank verfügt. Sollen kundenspezifische Informationen abgerufen werden, dann muss sich der Benutzer vorher durch seine gültige User-ID und das nur ihm bekannte Passwort identifizieren. Die Übertragung dieser Daten zum Web-Server sollte verschlüsselt erfolgen. SSL oder S-HTTP sind für diesen Zweck völlig ausreichend, da die Kommunikation ausschließlich zwischen Kunde und Anbieter verläuft. Zu beachten ist, dass der Web-Server in Besitz eines gültigen, von einer vertrauenswürdigen Zertifizierungsinstanz (CA) unterzeichneten Schlüsselzertifikats sein muss. Anderenfalls könnte ein Angreifer über eine DNS-Spoofing-Attacke die Website vortäuschen, um so in den Besitz sämtlicher Benutzerkennungen und Passwörter zu gelangen. Die Unterschrift eines bekannten Trust Centers unter dem Public Key gibt dem Kunden die Gewissheit, mit dem echten Anbieter zu kommunizieren. Für die Authentifikation über HTTP-Mechanismen gilt das gleiche: Eine vorab etablierte SSL-Verbindung muss die Übertragung der Identifikationsdaten gegen unerlaubtes Mitlesen absichern. Die Anmeldung am DBMS und die Übertragung der SQL-Abfrage über das Datenbankprotokoll (4) erfolgt in der Regel unverschlüsselt. Gelingt es beispielsweise einem Eindringling, Administrationsrechte auf dem Web-Server zu erlangen, so ist es ihm ein leichtes, dort einen Sniffer zu installieren. Um den Web-Server vor direkten Angriffen zu schützen, darf der Paketfilter nur Datagramme weiterleiten, die auf Dienste (Ports) zugreifen, die in der Sicherheitspolitik festgelegt wurden (z.B. DNS (53), HTTP (80) und SSL (443)). Zusätzlich müssen Filterregeln zur Abwehr von IP-Spoofing-Attacken konfiguriert werden, die am externen Adapter empfangene Datenpakete mit der Absenderadresse des Web-Servers oder der Firewall blockieren. Mit der Rückmeldung des DBMS (5) beendet die Anwendung die Datenbanksitzung und übergibt das Resultat der Abfrage im HTML-Format über die CGI-Schnittstelle an den Web-Server (6). Dieser reicht die Daten an den Browser weiter (7). Konzept 2 Mit jeder einzelnen Abfrage aus dem Internet wird ein weiterer Prozess gestartet, der sich immer wieder aufs Neue anmelden und abmelden muss. Dass dieses Verfahren bei stark frequentierten Websites schnell zu Kapazitätsengpässen führen kann, ist offensichtlich. Abhilfe versprechen proprietäre Web-Server-APIs wie das ISAPI von Microsoft oder Netscapes NSAPI, die den Aufruf von CGI-Skripten überflüssig machen. Der Serverprozeß holt sich statt dessen zur Laufzeit die entsprechenden Anwendungsfunktionen aus einer DLL und führt sie innerhalb seines Prozess- und Adressraums aus. Das wiederholte Starten und Beenden der Datenbanksitzungen entfällt damit, und der Web-Server kann eine dauerhafte Verbindung zum DBMS aufrechterhalten. Die enge Bindung an den Web-Server hat allerdings den Nachteil, dass ein Fehler in der Anwendung, wie z.B. eine Speicherverletzung, auch den unmittelbaren Abbruch des Servers zur Folge hat. Ausfallzeiten und unter Umständen auch ein Verlust von Daten sind die Folge. Die erzielten Performancevorteile werden bei den Server-APIs durch eine plattformspezifische Lösung aufgewogen, die bei Wechsel des Produktes oder des Betriebssystems oftmals nicht wiederverwendet werden kann. Zusätzlicher Entwicklungsaufwand ist dann nötig, um die Funktionalität zu portieren. Konzept 3 Eine dritte Alternative für den serverseitigen Zugriff bietet die sog. FastCGI-Schnittstelle, eine um die Performanceprobleme bereinigte Weiterentwicklung des bewährten Standardinterface. FastCGIProgramme laufen nach Erledigung ihrer Aufgabe weiter und halten eine Verbindung zum Web-Server über ein spezielles Protokoll aufrecht. So kann z. B. während der Tageszeiten mit hohem Abfragevolumen eine permanente DBMS-Sitzung eingerichtet werden. Bei den bisher beschriebenen Verfahren war die Programmlogik der Datenbankanwendung immer ein Bestandteil des Web-Servers. Aus sicherheitstechnischen Überlegungen muss es daher Ziel sein, die auf dem Web-Server laufenden Programme in ihrem Funktionsumfang so einfach wie möglich zu gestalten. Empfehlenswert ist daher eine Verlagerung der wesentlichen Bestandteile der Datenbank-anwendung auf den durch die Firewall gesicherten DB-Server. Entgegennahme der Benutzereingaben vom TCP-Relay auf der Firewall Plausibilitätsprüfung der Eingaben Formulierung der Datenbankabfragen Empfang des Abfrageergebnisses vom DBMS Aufbereitung des Resultats in das HTML-Format und Weiterleitung an das TCP-Relay (5). Die zurückgelieferten Daten müssen nur noch vom Query Relay an den Web-Server durchgereicht werden (6). Der Application Server hält außerdem eine permanente Verbindung zum DBMS aufrecht, um zeitraubende An- und Abmeldeprozeduren zu vermeiden. Die hier beschriebene Architektur findet sich in vielen kommerziellen OnlineShop-Softwarepaketen wieder; die die Funktionalität auf die gleiche Weise trennen, um die Performance ihrer Produkte zu verbessern. Neben der bisher betrachteten Variante, Datenbankabfragen in einer externen Anwendung zu implementieren, unterstützen viele Hersteller inzwischen auch die Speicherung von fertig compilierten Anwendungsfunktionen innerhalb des DBMS. Die Anwendung benötigt dann zum Aufruf dieser sog. Stored Procedures lediglich noch den Namen und die aktuellen Parameter. Stored Procedures verbessern die Performance und damit die Verfügbarkeit des Systems, da sie in kompilierter Form vorliegen und die Kommunikation zwischen Applikation und DBMS reduzieren. Insbesondere Hersteller von Web-Servern und Anbieter von kompletten Entwicklungsumgebungen für Web/Datenbankanbindungen bieten mit ihren Produkten die Möglichkeit, Variablen und neue Sprachkonstrukte in dynamischen HTML-Dokumenten einzusetzen, mit deren Hilfe auch der ungeübte Programmierer Datenbankzugriffe formulieren kann. In einem Deklarations- und Abfragebereich wird der Anwendungscode und die Ergebnisdarstellung direkt in sog. HTML-Schablonen (templates) beschrieben. Fordert ein Kunde beispielsweise eine Preisinformation an, so werden seine Eingaben und der in den Seiten enthaltene Programmcode per CGI oder Server API einer Anwendung übergeben, die das Ergebnis der Datenbankabfrage in die entsprechend vorbereiteten Felder der HTML-Schablone einsetzt. Letztlich entspricht diese Form der Datenbankanbindung der zuallererst beschriebenen Methode. Bezahlung (Punkt 5) Um einen Überblick über die verschiedensten Zahlungskonzepte im Internet zu bekommen, verweise ich auf den Artikel von Andreas Grupp. Hier soll es um grundlegende Gedanken zu Sicherheitskonzepte bei Zahlung in Online-Shops gehen. Der Zahlungsverkehr ist zweifelsohne die aus Kunden-, Anbieter- und Bankensicht sensibelste Dienstleistung im Internet. Um Zahlungstransaktionen juristisch sicher abzuwickeln, sind eine Reihe von Aspekten zu berücksichtigen. Die über die Netzwerke ausgetauschten Daten müssen vor Abhören sicher sein und dürfen nur den an der Transaktion beteiligten Kommunikationspartnern bekannt sein. Dem Kunden muß eine größtmögliche Sicherheit für die Vertraulichkeit seiner personen- und finanzbezogenen Informationen gewährleistet werden. Daneben zählt der sichere Schutz vor unberechtigten Veränderungen zu den Grundvoraussetzungen für die sichere Zahlungsabwicklung über das Internet. Für den Fall, daß ein Kunde eine von ihm bestätigte Transaktion im nachhinein als gefälscht darstellt, liegt es in der Pflicht des Händlers, dem Kunden nachzuweisen, daß er in den fraglichen Geschäftsvorfall verbindlich eingewilligt hat. Obwohl sich der Anbieter bei Kreditkartenzahlungen im Falle eines Betrugs auf die Zahlungsgarantie der Kreditkartenorganisation berufen kann, dürfte es nicht in seinem Interesse liegen, regelmäßig von Betrügern heimgesucht zu werden. Eine unmittelbare Überprüfung der Identität, Rechtmäßigkeit und Bonität des Karteninhabers liegt somit im beiderseitigen Interesse von Kartengeselischaften und Händlern. Unabhängig vom verwendeten Zahlungsmittel ist für das Vertrauen des Kunden in das System seine Akzeptanz von großer Bedeutung. Dies wird oftmals nicht nur durch technische Raffinessen gewonnen, sondern hat auch immer etwas mit der Seriosität der Betreiber zu tun. Einer unbekannten Hinterhoffirma wird niemand die Überprüfung seiner Kreditkartennummer anvertrauen, selbst wenn das dahinter operierende System einen sehr hohen Sicherheitsstandard verspricht. Die Kooperation der Händler mit namhaften Organisationen bei der Zahlungsabwicklung ist daher von großer Bedeutung und betrifft in erster Linie die Clearing- und Zertifizierungsfunktion. Gelingt es einem Eindringling, sich Zugang in das lokale Netz oder den lokalen Rechnern zu verschaffen, sind nicht nur allgemeine Daten wie die Produkt- und Preisinformationen gefährdet, sondern auch alle kundenspezifischen Daten. Selbst wenn kein nennenswerter Schaden durch Zerstörung oder Manipulation entsteht, kann alleine die Bekanntgabe eines solchen Vorfalls schwere Folgen nach sich ziehen. Eine sorgfältig geplante Zugriffskontrolle muß unkontrollierten Zugängen einen Riegel vorschieben, um solchen Gefahren prophylaktisch entgegenzuwirken. Nicht nur aus datenschutzrechtlichen Gründen sollte mit der Ermittlung personenbezogener Daten behutsam umgegangen werden. Schnell vergrault man als Anbieter seine Klientel, wenn ohne ersichtlichen Grund oder nennenswerte Gegenleistungen nach Name, Adresse und persönlichen Vorlieben gefragt wird, um den Kunden schon beim nächsten Besuch mit einem individualisierten Angebot zu begrüßen. Schließlich muß man in einem realen Geschäft auch nicht gleich den Personalausweis vorzeigen, nur weil man die Umkleidekabine betritt. Konzept 1 Viele Online-Shops akzeptieren trotz der zahlreichen Neuentwicklungen im Bereich der Internet-basierten Zahlungssysteme nach wie vor nur Kreditkarten in Verbindung mit dem SSL-Verschlüsselungsprotokoll. Der Vorteil dieser Lösung liegt in ihrer Einfachheit begründet. Die Plastikkarten sind weit verbreitet und weltweit anerkannt. Der Kunde braucht keine zusätzliche Software zu installieren, da das Protokoll im Funktionsumfang eines Standardbrowsers bereits vorhanden ist. Verkäuferseitig sind die Aufwände auch minimal. Ein SSL-Web-Server ist preiswert und schnell konfiguriert. Die Beglaubigung des öffentlichen Schlüssels durch eine anerkannte Zertifizierungsstelle kann unter Umständen online erfolgen, so daß schon nach kurzer Zeit der Betrieb aufgenommen werden kann. Das Vertrauen in das als sehr sicher angenommene Protokoll kam durch den Ende 1995 geglückten Versuch von zwei französischen Studenten ins Wanken, die einen 40-Bit-RC4-Schlüssel in weniger als fünf Tagen knackten. Das Ergebnis wurde nochmals von einem Verbund aus mehreren Teilnehmern einer Mailingliste übertroffen, die einen weiteren »exportfähigen« 40-Bit-Schlüssel in nur 31 Stunden ermittelten. Auch die US-Version war kurzzeitig gegen Angriffe nicht mehr sicher; als durch zwei Studenten der Berkeley Universität bekannt wurde, daß der Algorithmus zur Erzeugung der Zufaliszahlen vorhersehbare Ergebnisse produzierte. Dadurch war es möglich, Schlüssel jeder Länge in Sekundenschnelle zu berechnen. Trotz seiner Schwachstellen hat sich SSL als De-facto-Standard für die verschlüsselte Kommunikation im Internet durchgesetzt, nicht zuletzt wegen der schnellen Verfügbarkeit kostenloser SSL-Bibliotheken. Obwohl SSL die an ein sicheres Zahlungssystem gestellten Anforderungen durch sein grundlegendes Design in einigen Punkten nicht erfüllen kann, wird es gegenwärtig hauptsächlich für Kreditkarten-zahlungen im Internet eingesetzt. Das der Transportschicht zuzuordnende Kryptoprotokoll ist nicht in der Lage, Anwendungsdaten digital zu signieren und somit die Verbindlichkeit von Transaktionen sicherzustellen. Die relevanten Informationen werden beim Client in das entsprechende Nachrichtenformat der Anwendung gebracht und noch vor der Übergabe an die Server-Applikation von der Transportschicht wieder dekodiert. Außerdem bietet SSL für einen Händler im Internet keine Möglichkeit, die vom Käufer angegebene Kreditkatennummer und deren Gültigkeit online zu überprüfen. Er ist dazu gezwungen, diese Kundendaten auf seinem Server zwischenzuspeichen, um sie für eine spätere Rechnungsstellung parat zu haben. Daß dieses Verfahren aus Sicht der Kunden auch nicht optimal ist, liegt auf der Hand. Schließlich wird auf diese Weise jeder SSL-Server im Internet zum Sammeltopf für Kartennummern, die nicht nur für den Händler von großem Interesse sind. Je häufiger ein Kunde seine Zahlungsinformationen an unterschiedliche SSL-Server preisgibt, desto größer ist die Wahrscheinlichkeit, daß bei einem erfolgreichen Einbruch auch seine Kreditkartennummer in die falschen Hände gerät. Konzept 2 Als zweite Möglichkeit wird auf die Kreditkartenzahlungen mit SET auf dessen Sicherheitskonzepte eingegangen. Die häufigste Ausprägung des E-Commerce im Internet, das Online-Shopping, erfordert insbesondere bei der Zahlungsabwicklung ein aufeinander abgestimmtes Zusammenspiel zwischen mehr als nur zwei an der Zahlungsabwicklung beteiligten Parteien: Der Kunde reicht nach der Bestellung der Waren eine Zahlungsanweisung bei seinem Händler über das Internet ein, der die Gültigkeit der vom Kunden angegebenen Daten bei seiner Abrechnungsstelle bzw. Bank erfragt. Die Abrechnungsstelle übernimmt gegen eine prozentuale Beteiligung am Kaufwert der Ware die Autorisierung und Überweisung elektronischer Zahlungen und tauscht die dazu erforderlichen Informationen über bankinterne Nachrichtenformate und Netze mit dem kartenausgebenden Finanzinstitut des Kunden aus. Abhängig von der Rückmeldung wird der Auftrag entweder dem Kunden bestätigt oder abgebrochen. Der Zahlungsvorgang wird mit der Verrechnung zwischen Kunden- und Händlerbank abgeschlossen. Ein sicheres Protokoll für Kreditkartenzahlungen im Internet sollte die Kunden als berechtigte Karteninhaber identifizieren, den Händler als autorisierte Kartenannahmestelle gegenüber dem Kunden ausweisen und die Authentizität der beteiligten Abrechnungsstellen und Banken sicherstellen. Darüber hinaus ist die Integrität und Vertraulichkeit der Zahlungsinformationen zu gewährleisten. Eine SET-Transaktion besteht aus insgesamt acht Teilschritten. SET sieht für jeden Karteninhaber ein Signaturschlüsselpaar und für Händler und Banken je zwei Schlüsselpaare vor: eines zum Austausch der temporären Sitzungsschlüssel, das andere zum Unterschreiben von Nachrichten. Für beide öffentlichen Schlüssel wird ein gültiges Zertifikat benötigt, das von einer SET- Zertifizierungsstelle beglaubigt sein muß. Das mit SET eingeführte Konzept der dualen Signatur sorgt dafür, daß die Zahlungsanweisung vertraulich behandelt wird und die Bestellung der Abrechnungsstelle unzugänglich bleibt. Durch sie werden die zwei getrennten Nachrichten so miteinander verbunden, daß sie zwar getrennt versendet und überprüft, nicht aber aus ihrem Zusammenhang gelöst und manipuliert werden können. Die strikte Trennung zwischen den beiden Datensätzen ist aus Gründen der Vertraulichkeit von großer Bedeutung. Der Händler sollte niemals die Kreditkartennummer zu sehen bekommen. Eine Bestätigung über deren Gültigkeit ist für seine Belange innerhalb des Transaktionsvorgangs vollkommen ausreichend. Genauso wenig sind die Auftragsdaten für die Abrechnungsstelle von Interesse. Um den Händler vor gesperrten oder ungültigen Kreditkarten zu schützen, ist nur die Kartennummer notwendig. Trotzdem muß dafür gesorgt werden, daß die Abrechnungsstelle nur die der Bestellung zugeordnete Zahlungsanweisung gegenüber dem Händler autorisiert. Auf der anderen Seite möchte der Händler sicher gehen, daß die Bestellung nur dann ausgeliefert wird, wenn die mit ihr übermittelten Kreditkarten-informationen authentisch sind und von der Abrechnungsstelle als gültig bestätigt wurden. Die Integration von SET in eine bereits bestehende Anwendungslandschaft ist von Produkt zu Produkt verschieden. Die Spezifikation gibt lediglich den Ablauf, die Formate und Inhalte der Nachrichten vor. Aussagen über technische Schnittstellen zu anderen Systemen werden nicht getroffen. Viele Hersteller gehen deshalb dazu über; für die Architektur ihrer SET-Produkte einen ähnlichen Ansatz zu wählen, wie er auch bei der Einbindung von Datenbanken Verwendung fand. Eine CGI- (bzw. API-) Erweiterung des Web-Servers wird jedesmal aufgerufen, wenn ein Kunde SET-Nachrichten an den Verkäufer sendet. Entsprechend den Übergabeparametern in den GET- oder POST-Requests veranlaßt das relativ einfach gehaltene CGI-Programm, Aktionen in einer separaten Anwendung anzustoßen. Sie ist das eigentliche Kernstück des Systems und generiert die kundenspezifischen SET-Nachrichten. Durch diese Trennung der Anwendungslogik ist es wieder möglich, Komplexität hinter die Firewall zu verlagern und eine permanente Verbindung zur Datenbank aufrecht zu erhalten (siehe Abb.3-5). Mit dem DB-Server werden u.a. die ausstehenden Autorisierungs- und Verrechnungsanfragen an die Abrechnungsstelle verwaltet sowie abgeschlossene Transaktionen aufgezeichnet. Die Kommunikation mit den Finanzinstituten erfolgt über HTTP, das die SET-Nachrichten transportiert. Es ist davon auszugehen, dass sich SET als weltweiter Standard für die Bezahlung im Internet durchsetzen wird. Quellen: http://www.electronic-commerce.org Walter Gora, Erika Mann, Handbuch Electronic Commerce. Kompendium zum elektronischen Handel. (1999), Springer-Verlag, Berlin. Jörg Krause Praxishandbuch Electronic Commerce (1999), Verlag Hanser Electronic PC Professionell 6/99 N26- N28 PC Professionell 2/99 N22- N24 Frank Mattes, Electronic Business-to-Business (1999), Schaeffer-Poeschel Verlag Martin Räpple, Sicherheitskonzepte für das Internet (1998) dpunkt Verlag Internet Professionell 5/99 S. 96 Internet Professionell 6/99 S. 68-71 http://set.ch/demo/demo00-de.html Electronic Commerce InfoNet, herausgegeben von FTK - Forschungsinstitut für Telekommunikation Martin-Schmeisser-Weg 4 44227 Dortmund |
