![]() ![]() |
Web-Transaktionen archivieren
Webbasierte Prozesse wie im E-Commerce oder E-Banking setzen sich mehr und mehr durch. Aus diesen Prozessen besteht das Geschäft selbst, daher sind sie durch und durch relevant für die Rechtssicherheit, die Compliance eines Unternehmens. Wie kann man diese Webprozesse im Zweifelsfall belegen? Wie lassen sich Webtransaktionen archivieren? Das Speichern von Webseiten hingegen ist an vielen Arbeitsplätzen zur täglichen Routine geworden. Durch Bookmarking können wir heute sehr einfach zeitversetzt den Content auf Webseiten lesen und verarbeiten. Nachweispflicht bei HandelstransaktionenStellen wir uns folgende Situation vor: Wir wollen über ein Online-Portal eine Digitalkamera kaufen. In der seitlichen Navigation steht vielleicht ein Konfigurator zur Verfügung, der unsere Interessen hinsichtlich Preisvorstellungen und Produktleistung einzugrenzen hilft. Den nutzen wir, füllen ihn aus, klicken "ok" und erhalten eine Liste passender Produkte. Ganz oben erscheint ein Super-Schnäppchenangebot. Schnell das Bestellformular ausgefüllt – und ab damit. Wir erhalten den freundlichen Hinweis, dass die Bestellung erfolgreich eingegangen ist und fünf Tage später die Ware mit Rechnung.Kommt sie allerdings mit einem ganz anderen Preis an, wer muss (und kann) nachweisen, dass zum Bestellzeitpunkt der Aktionspreis richtig war? Hier ist die Rechtsprechung bisher ziemlich eindeutig: Die Informations- und Nachweispflicht liegt gemäß § 312e Abs. 1 Satz 1 Nr. 2 des Bürgerlichen Gesetzbuchs beim anbietenden Unternehmen. Auch muss der Anbieter bei einem Vertragsschluss im Internet nachweisen, dass der Vertrag mit dem Bietenden tatsächlich zustande gekommen ist. Um den Betreibern von Online-Shops, Reise-, Flug- oder Ticketportalen Sicherheit zu offerieren, bieten einige Web-Content-Management-Systeme (WCM) hierfür zum Teil fragwürdige Versionierungen an, mit denen eine lückenlose Dokumentation aller Prozesse jedoch kaum gewährleistet werden kann. Oft ist unklar, was genau archiviert werden sollte: Sind es die Seiten, die Inhalte, die Sicherungen der Datenbank und der Stylesheets? Wie verhält es sich mit Bildern und Videos? Die Flüchtigkeit von Webseiten – oder wie Webseiten funktionierenWie kann ein Portalbetreiber und kommerzieller Anbieter nun Handlungen und Webprozesse dokumentieren, um seiner Nachweispflicht nachzukommen, wenn Webseiten "flüchtig" sind, sprich sich ständig verändern? Schauen wir uns dazu zunächst die Unterschiede zwischen statischen und dynamischen Webseiten an, um später zu einem Verfahren zu gelangen, das so einfach wie sicher ist – das Compliant Transaction Recording (CTR). Statische Seiten zeichnen sich dadurch aus, dass sie langfristig stabile Inhalte präsentieren. Deshalb sind sie sehr gut zitierbar als langfristig verfügbare Referenz. Wird eine statische Seite von einem Browser, also einem Nutzer, angefordert, schickt dieser die entsprechende URL an den Server.Der Server identifiziert anhand der URL die gesuchte Datei (HTML, Bilder), liest sie ein und schickt sie unverändert zurück. Die Gesamtinformation ist im (statischen) HTML- oder XML-Dokument enthalten. Der Nutzer kann bestimmen, welche Seiten er sehen will, aber nicht deren Inhalt. Ferner zeichnen sich statische Seiten durch langfristige Lesbarkeit durch Mensch und Maschine aus. Hierfür ist allerdings eine langfristige Datenpflege notwendig, Stichwort Migration und Lesbarkeit von Datenformaten. Um statische Webseiten zur Absicherung für den Betreiber bzw. Anbieter zu sichern, könnten verschiedenste Versionen gespeichert und diese Speicherung protokolliert werden. Da dies nicht wirklich praktikabel für E-Commerce-Anwendungen ist, wird überwiegend auf dynamische Webseiten zurückgegriffen, denn in vielen Fällen reicht es nicht aus, nur eine statische Datei auszuliefern. Vielmehr werden komplexe datenbankgestützte Shopsysteme und Internetseiten mit sich ständig ändernden Inhalten realisiert, die von diversen Browser-Formaten verarbeitet werden müssen sowie personalisierte Seiten ermöglichen sollen. Um all das zu realisieren, könnte immerhin eine sich nicht verändernde Datei vom Server ausgeliefert werden, deren Inhalt erst auf dem Browser des Nutzers durch aktive Bestandteile, wie zum Beispiel JavaScript, nachträglich modifiziert wird; eine clientseitige Generierung. Mithilfe von JavaScript und allen unter dem Sammelbegriff DHTML zusammengefassten Techniken kann der Inhalt von HTML-Dokumenten nachträglich verändert werden. Die Anweisungen hierzu sind im HTML-Text eingebettet und werden durch den Browser ausgeführt – falls er über diese Fähigkeit verfügt. Dadurch ist es zum Beispiel möglich, ein aktuelles Datum auszugeben, abhängig von der Browsersoftware bestimmte Aktionen auszuführen oder über Cookies benutzerspezifische Informationen abzuspeichern und wieder auszulesen. Diese Technik ist allerdings in der Praxis problematisch, da Java-Script nicht immer vorhanden und aktiviert ist. Außerdem ist die Implementierung der DHTML-Fähigkeiten von Browser zu Browser unterschiedlich und gelegentlich sogar fehlerhaft. Lotterie der FunktionalitätDas Benutzen dieser Funktionen wird damit zum Glücksspiel und kann zu ungewollten Resultaten führen. Zum anderen muss die angeforderte Datei nicht sofort an den Client ausgeliefert werden, sondern kann erst durch ein Programm verändert oder sogar erst bei der Anforderung durch ein Programm erzeugt werden (serverseitige Generierung). Dynamische Webseiten zeichnen sich durch kurzfristig aktualisierte Inhalte aus, wobei die Aktualisierung automatisch aus der Datenbank oder anderen Applikationen erfolgen kann. Solche Webseiten sind besonders für die kurzfristige Einbindung von Daten geeignet: Informationen lassen sich aufgrund einer Anfrage aktuell zusammenstellen (Scripts, Nutzereingaben, Datenbanken), und es sind personalisierte Seiten möglich, da der Nutzer den Inhalt der Seiten, soweit vorgesehen, durch seine Anfrage mitbestimmen kann.Allerdings setzen dynamische Seiten die Verfügbarkeit von bestimmten Browsern, Interpretern und nicht selten spezieller Betriebssysteme voraus und werden oft auf Client-Server-Architekturen realisiert. Sie finden häufig ihre Anwendung, wenn Aktualität und Zeitnähe Vorrang haben: Börse, Prozessrechner, E-Commerce, Konzertprogramm, Tagesangebote und andere. Die langfristige Aufbewahrung derartiger Webseiten gestaltet sich schwieriger als bei statischen Seiten. Genau dieser Anforderung sieht sich aber jeder E-Commerce-Anbieter gegenüber, um den gesetzlichen Bestimmungen gerecht werden zu können – um also neudeutsch "compliant" zu sein. Fazit: Eine URL bezeichnet also keine konkrete Datei, sondern vielmehr eine vom Server bereitgestellte kurzlebige Informationseinheit, die archiviert werden soll, sobald sie geschäftsrelevante Handlungen abbildet, um Compliance-Anforderungen zu erfüllen. Automatische Abbildung komplexer ProzesseWenn nun der dynamisch generierte Inhalt einer Webseite langfristig aufgehoben werden soll, könnte es also hilfreich sein, zum Zeitpunkt bzw. bei Abschluss einer Transaktion einen Snapshot zu erzeugen. Hierbei gäbe es zwei denkbare Vorgehensweisen. Einerseits wäre eine automatische Abbildung oder Snapshot vor der Übergabe der aktuell erstellten Seite an den Browser möglich. Andererseits bietet es sich an, genau diesen Snapshot erst beim Auslösen der Transaktion zu erzeugen und damit sicherzustellen, dass zum Zeitpunkt der Bestellung alle sichtbaren Inhalte der Webseite noch gültig waren.Das kann wichtig sein, da zwischen dem Anzeigen der Inhalte, dem Lesen und der Bestellung bereits Änderungen eingetreten sein können. So könnte der Zeitpunkt des Aktionsangebotes oder die Anzahl der limitierten Angebote bereits überschritten worden sein, was jedoch erst durch eine nochmalige Aktualisierung des Browsers sichtbar ist. Diese Aktualisierung kann mit dem Vorgang der Bestellung vorgenommen werden und somit parallel zu dem Snapshot. Bei einem solchen Snapshot- oder Freezing-Verfahren bleiben dann noch das Endformat sowie der finale Speicherort zu klären, um eine Unveränderbarkeit zu gewährleisten. Als nahezu ideale Lösung empfiehlt sich hier einerseits die Erzeugung eines TIFFG-Formates oder einer PDF- bzw. PDF/A-Datei, die dann gern noch mit einem Hashwert versehen und in einem separaten digitalen Archivsystem, Dokumenten-Management- bzw. Enterprise-Content-Management-System abgelegt werden sollte. Durch eine derartige Speicherung der erzeugten Snapshot-Dokumente ist im unerwünschten Fall einer juristischen Beweisführung eine schnelle Recherchierbarkeit einschließlich Zugriff auf den gesamten Inhalt des Dokumentes als Volltext möglich. Compliance Transaction RecordingCompliance Transaction Recording (CTR) ist ein technologisches Verfahren für die rechtssichere optische Speicherung von Webprozessen. Es stellt eine komplette Lösung für das Zusammenspiel eines Web-Content-Management-Systems und des ECM-Systems dar und ermöglicht nicht nur einfach die Speicherung statischer Webseiten und deren Änderungen oder Entwicklungen durch den Betreiber. Zusätzlich dazu ist die revisionssichere Archivierung dynamischer Webseiten möglich sowie beliebiger Geschäftsprozesse und Transaktionsabläufe – Aufträge, Informationsabruf oder jegliche andere Interaktionen eines Besuchers auf der Webseite.Compliant Transaction Recording trifft auf Aktionen sowohl in öffentlichen als auch in geschlossenen Systemen wie beispielsweise Intranet zu und bedeutet, dass sensible Daten, oder die zu einem bestimmten Zeitpunkt enthaltenen Informationen einer Webseite, jederzeit genau in der Form nachweisbar sind, in der sie der Webseite-User gesehen hat. Das Verfahren realisiert die automatische Abbildung komplexer Prozesse durch die sichere Archivierung aller Vorgänge, die über eine Webseite abgewickelt wurden. Ähnlich wie eine Blackbox im Flugzeug, übernimmt das System die "Aufzeichnung", Erfassung und Archivierung. Durch eine Art Freezing-Verfahren entstehen automatisch unveränderbare optische Kopien der zum Zeitpunkt einer Transaktion gültigen Webseite.
10/2008, Iven Jainta
| ![]() ![]() | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
© 1999-2010 FEiG & PARTNER | Nutzungsbedingungen | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() | ||
![]() |