ePages 5 Technical White Paper
Werbung
Technical Whitepaper epages.com/de e-commerce. now plug & play. Die in diesem Dokument enthaltenen Informationen können jederzeit ohne Benachrichtigung geändert werden. Dieses Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Alle Rechte sind ausdrücklich vorbehalten, einschließlich der Rechte auf Vervielfältigung, Reproduktion, Übersetzung, Mikroverfilmung, Speicherung auf elektronischen Medien und Verarbeitung in elektronischer Form. Alle Firmen-, Produkt- und Markennamen sind Warenzeichen oder eingetragene Warenzeichen der entsprechenden Inhaber. Copyright © 2008 ePages Software GmbH. Alle Rechte vorbehalten. Sollten Sie Fragen oder Hinweise zu unseren Produkten haben, so wenden Sie sich bitte an folgende Adresse: ePages Software GmbH Pilatuspool 2 20355 Hamburg Tel.: +49 (0) 40 / 350 188 – 100 Fax: +49 (0) 40 / 350 188 – 222 E-Mail: [email protected] www.ePages.com/de Hamburg, Mai 2009 Inhaltsverzeichnis Einleitung .................................................................3 Allgemeines ....................................................................... 3 Weitere ePages Dokumentationen.................................................... 3 ePages Systemarchitektur........................................4 Allgemeines ....................................................................... 4 Web-Server ........................................................................ 4 Applikations-Server ........................................................... 5 Request Router und Pools .................................................. 5 Datenbank-Server .............................................................. 5 Sybase High Availability und Replication Server ab Merchant Enterprise ........................................................................................ 6 File-Server ......................................................................... 6 Set Up & Mögliche Konfigurationen.......................... 7 Set Up bei ePages Hosting-Partnern ................................... 7 Hardwarevoraussetzungen ............................................................... 7 Installation ...................................................................................... 8 Set Up bei ePages Merchant-Partnern ................................ 8 Hardwarevoraussetzungen ............................................................... 8 Installation ...................................................................................... 8 Minimalkonfiguration ........................................................ 9 Verteilte Installationen ...................................................... 9 Einzelner Datenbank-Server ............................................................. 9 Parallelverteilung gemeinsamer Web- und Applikations-Server....... 10 Parallelverteilung getrennter Web- und Applikations-Server............ 10 Datenbank im Cluster .................................................................... 11 Verteilung von Datenbanken auf mehrere Datenbank-Server .......... 12 Sicherheitsmechanismen ....................................... 13 Unabhängige logische Module ..........................................13 Passwortschutz ................................................................14 Zugriffsrechte ................................................................... 15 Session-Sicherheit............................................................ 15 Anfragenprüfung .............................................................. 16 Verschlüsselung .............................................................. 16 Kommunikation mit anderen Systemen ............................. 17 Erweiterungsmöglichkeiten .................................... 18 Einleitung Allgemeines Dieses Dokument gibt einen Überblick über die ePages-Architektur, die Sicherheitsmechanismen sowie Anforderungen für bestimmte Größenordnungen von Hardwarekonfigurationen. Dabei liegt das Augenmerk auf folgenden Punkten: • Zugriffsschutz unabhängiger logischer Module untereinander • Rechtesystem • Hohe Leistungsfähigkeit • Skalierbarkeit • Hochverfügbarkeit (High Availability - HA) • Niedrige Gesamtbetriebskosten (“Total Cost of Ownership” - TCO) Die Daten in diesem Dokument basieren auf Erfahrungen und Messergebnissen und stellen einen möglichst ökonomischen Kompromiss zwischen den unterschiedlichen Zielen für B2B- und B2C-Anwendungen dar. Es handelt sich daher um Beispielszenarien. Gern erstellen wir auch einen spezifischen Hardwarevorschlag. Nutzen Sie dazu unsere ConsultingAbteilung unter: [email protected] Weitere ePages Dokumentationen Zur Arbeit mit ePages Software existieren darüber hinaus die Dokumentationen: [1] „ePages 6 White Paper“ [2] „ePages 6 Handbuch zum Erstellen und Verwalten von Shops und Webseiten“ Die Installation und der Betrieb eines ePages-Systems werden beschrieben in: [3] „ePages 6 Installationshandbuch“ [4] „ePages 6 Handbuch für Business Administratoren“ [5] „ePages 6 Handbuch für Technische Administratoren“ [6] „ePages 6 Entwicklerhandbuch“ [7] „ePages 6 und Suchmaschinen“ ePages 6 | Technical White Paper Seite 3 ePages Systemarchitektur Allgemeines Prinzipiell besteht ePages-Software aus folgenden Komponenten: • Web-Server • Applikations-Server • Datenbank-Server • File-Server Die nachfolgende Abbildung zeigt den grundlegenden Architekturaufbau sowie den Ablauf einer Anfrage an das System. Ablauf einer Anfrage an das System Der Nutzer ruft eine Seite in der Storefront des Shops auf. Diese Anfrage wird an den Web-Server übertragen. Der Request-Router leitet die Anfrage an einen verfügbaren Applikations-Server weiter. Dieser prüft, ob die vom Nutzer angeforderte Seite bereits vorher einmal angefordert wurde. Liegt die Seite bereits auf dem File-Server, wird sie an den Web-Server geschickt und von dort aus über das Internet an den Client ausgeliefert. Ist die angeforderte Seite noch nicht vorkompiliert vorhanden, holt sich der Applikations-Server die entsprechenden Daten aus der Datenbank, erstellt die Seite und leitet sie über den Web-Server an die Storefront. Web-Server Welcher Web-Server eingesetzt wird, hängt vom Betriebssystem ab. ePages bietet seine Produkte für folgende Betriebssysteme an: • MS Windows Server 2003 • Linux Red Hat Enterprise 5 (32- und 64-bit) • Linux SuSE Enterprise 10 (32- und 64-bit) ePages 6 | Technical White Paper Seite 4 Für Windows empfiehlt ePages als Web-Server den MS-IIS, unter Linux Apache (ab 2.2.9, im Lieferumfang enthalten). Es besteht die Möglichkeit, mehrere Web-Server-Maschinen parallel zu schalten. Applikations-Server Der ePages-Applikations-Server ist eine Eigenentwicklung, die mit einer der Web-Standardsprachen (Perl) programmiert wurde. Für ePages 6 wurde die Perl-Version 5.10 verwendet. Diese unterstützt modernste Technologien wie beispielsweise Web Services. Auf jeder physischen Maschine können mehrere Instanzen ApplikationsServer gestartet werden, wobei die Anzahl vom installierten RAM und den verfügbaren CPU abhängig ist. Je mehr Applikations-Server zur Verfügung stehen, umso mehr Anfragen pro Sekunde können beantwortet werden. Es besteht die Möglichkeit, mehrere Applikations-Server-Maschinen parallel zu schalten. Da der Applikations-Server am leichtesten zu skalieren ist, wurde ePages 6 so entwickelt, dass hier die Hauptlast der Anwendung liegt. Die gesamte Business-Logik liegt auf dem Applikations-Server, häufig angeforderte Daten werden hier zwischengespeichert. Damit wird der Datenbank-Server entlastet. Request Router und Pools Einen besondern Stellenwert hat der Request-Router (RR). Er verteilt eingehende Anfragen auf die entsprechenden Applikations-Server. Auch RR können über mehrere Maschinen verteilt und somit hochverfügbar ausgelegt werden. Mehrere RR teilen sich dann ebenfalls die Abarbeitung der eingehenden Requests. Für sehr große Installationen mit bspw. sehr vielen Shops können sog. Pools gebildet werden. Dabei fasst man Datenbanken und Applikationsserver-Instanzen zu Gruppen (Pools) zusammen. Somit können Teile der Applikation dediziert einzelnen Shops oder Gruppen von Shops zugewiesen werden, um einerseits die Performance besser auszubalancieren und andererseits unterschiedliche ePages Unterversionen zu verwalten. Außerdem können bestimmte Request-Arten, z.B. Zugriffe über Web Services, zur Laststeuerung in Pools gegliedert werden. Datenbank-Server ePages verwendet Sybase ASE (Adaptive Server Enterprise) Version 15.0 als integrierte Datenbank. Diese hat sich als sehr robust, leistungsfähig und zuverlässig erwiesen. Anfragen der Applikations-Server werden mit SQL-Anweisungen ausgeführt. Für ePages 6 Merchant besteht die Möglichkeit, mehrere Datenbank-ServerMaschinen parallel zu schalten – für eine einzelne Datenbank ist dazu ist ein Cluster erforderlich. Mit dem ePages 6 Hosting-Produkt können mehrere Datenbanken (mit jeweils mehreren Shops) zu einem System vereint werden. In diesem Fall kann jede einzelne Datenbank ihre eigene physische Maschine haben. Bei der dedizierten Lösung von ePages 6 ist eine verteilte Installation leider nicht möglich. ePages 6 | Technical White Paper Seite 5 Sybase High Availability und Replication Server ab Merchant Enterprise Die Versionen ePages Hosting sowie Merchant Enterprise und Corporate sind mit den Funktionen High Availability und Replication Server ausgestattet. Die Funktionen sind insbesondere für große Massenshopinstallationen und große Shops mit überdurchschnittlichen Anforderungen an Leistung und Ausfallsicherheit interessant. Mit dem Feature High Availability können Sie innerhalb einer Clusterarchitektur die Datenbank auf mehreren Servern redundant absichern und Datenbankzugang auch bei Rechnerausfall sicherstellen. Alle laufenden Datenbankprozesse werden bei Serverausfall ohne Zeitverzögerung vom zweiten Server übernommen. Der Sybase Replication Server vereinfacht die Bereitstellung und Synchronisierung von Daten auf Unternehmensebene. Sie können redundante Disaster-Recovery-Sites einrichten und Daten über heterogene Datenbankplattformen hinweg zu synchronisieren (Sybase ASE, Oracle, IBM DB2 und Microsoft SQL Server). Für ihre Kunden hat das erhebliche Vorteile, denn die Daten, die zusammen mit anderen Anwendungen in zentralisierten Anwendungsspeichern verwaltet werden, können örtlich und zeitlich flexibel abgerufen und zur Nutzung bereitgestellt werden. File-Server Bilder und andere Multimediadateien sowie statische Seiten werden aus Gründen der Leistungsfähigkeit nicht in der Datenbank gespeichert. Sie liegen im Dateisystem meist auf dem Web-, Applikations- oder DatenbankServer. In der Datenbank ist lediglich der Verweis auf diese Datei gespeichert. Ebenso werden auf dem File-Server Konfigurationsdateien zentral verwaltet, sowie sämtliche Templates und CSS-Dateien (Cascading Style Sheet), welche für das Design von Storefront und Back Office erforderlich sind. Meist wird der File-Server nicht auf einer separaten Maschine installiert, sondern häufig entweder auf dem Web- oder dem Applikations-Server betrieben, in bestimmten Fällen auch auf dem Datenbankserver. Selbstverständlich können bei großen Installationen auch Filer mit Network Attached Storage (NAS) oder Storage Area Networks (SAN) zum Einsatz kommen. ePages 6 | Technical White Paper Seite 6 Set Up & Mögliche Konfigurationen Set Up bei ePages Hosting-Partnern Hardwarevoraussetzungen Hostingplattformen sind immer unterschiedlich, daher gibt es keine standardisierten Antworten auf die Frage nach der geeigneten Hardwarekonfiguration. Für das jeweilige Projekt entwirft unsere Consultingabteilung in Absprache mit Ihnen ein individuelles Anforderungsprofil und berät sie beim Aufsetzen des Systems. Dennoch, um den etwaigen Aufwand grob abschätzen zu können, sei hier ein praxisnahes Beispiel genannt. Folgende Hardware-Konfiguration wird für den Betrieb von ePages 6 empfohlen: • Network Load Balancer (NLB) • ausfallsicherer NFS file share im Backend (optimal: NetApp-Filer aufgrund der Snap-Shot-Möglichkeiten) • Datenbank-Server mit folgender Konfiguration: 1 x Quad core AMD Opteron, 3.20 GHz, 8 GByte RAM, 4 x 146 GByte HD as 2 x RAID1 RH Linux Enterprise 5, 64 Bit oder SuSe Enterprise 10, 64 Bit • Web- / Application-Server mit folgender Konfiguration: 1 x Quad core XEON, 3.20 GHz, 16 GByte RAM, 2 x 73 GByte HD as RAID1 RH Linux Enterprise 5, 64 Bit oder SuSe Enterprise 10, 64 Bit • Test System: 1 x quad core XEON, 3.20 GHz, 8 GByte RAM, 146 GByte HD RH Linux Enterprise 5, 64 Bit oder SuSe Enterprise 10, 64 Bit Die Anzahl der benötigten Server hängt von der zu erwartenden Anzahl an Shops ab. Um den Betrieb des Systems zu gewährleisten werden mindestens 2 Web-/Application-Server und 2 Datenbank-Server (1 live, 1 stand by) benötigt. Die Hardwareempfehlung für steigende Shopzahlen verdeutlicht die folgende Tabelle: Anzahl Shops Web-/Applicationserver DatenbankServer NFS Speicherplatz 2.000 2 2 150 GB 4.000 4 2 250 GB 8.000 8 4 500 GB ePages 6 | Technical White Paper Seite 7 Installation ePages 6 ist vollständig in Parallels Operation Automation (POA) integriert. Die ePages Hosting-Partner können über POA die ePages Installation hinsichtlich der Provisionierung verwalten. Dazu gehören das Anlegen, Upgraden, Schließen und Löschen von Shops in einer Massenshopumgebung. Als Provider können Sie unterschiedliche Shoptypen verwenden und ePages Shops im Hostingpaket mit anderen Produkten (z.B. Webspace) kombinieren. Die Kommunikation zwischen ePages und Parallels erfolgt über Web Services. Natürlich lässt sich ePages auch auf „herkömmlichen Wege“ installieren. Nähere Informationen zum Installationsvorgang im konkreten Fall erhalten Sie durch unsere Consultingabteilung. Set Up bei ePages Merchant-Partnern Hardwarevoraussetzungen Auch hier gilt, dass kein Projekt einem anderen entspricht. Die Mindestanforderungen an eine einzelne ePages-Installation sind: • 1 CPU • 1 GB RAM freier Arbeitsspeicher • 10 GB freier Festplattenspeicher Um ein performantes System zu gewährleisten ist es jedoch ratsam, ein leistungsstärkeres Hardwareprofil zu verwenden. Für ein kleines MerchantStarter-Projekt empfehlen wir beispielsweise: • 3 CPUs (2 x App-Server, 1 x DB-Server) • 2 GB RAM freier Arbeitsspeicher Für Projekte basierend auf einer Merchant Pro mit 12 Application Servern raten wir zu folgender Konfiguration: • 6 CPUs (4 x App-Server, 2 x DB-Server • 8 GB RAM freier Arbeitsspeicher Sowie eine dem jeweiligen Projektumfang entsprechende Menge an freiem Festplattenspeicher (abhängig von der Anzahl an Produkten, Kunden, Bildern und Inhalten, …). Bitte beachten Sie, dass die oben genannten Beispiele lediglich zur Orientierung dienen sollen. Die tatsächlich benötigte Hardware für Ihr individuelles Projekt zu ermitteln ist ein komplexer Vorgang, bei dem viele Parameter eine Rolle spielen. ePages hilft Ihnen dabei, ein geeignetes Anforderungsprofil zu erstellen. Installation Informationen für die Installation auf einer oder mehreren Maschinen, in einer Nicht-Hosting-Umgebung, entnehmen Sie bitte dem ePages Installationshandbuch oder setzen Sie sich mit dem ePages Support in Verbindung. ePages 6 | Technical White Paper Seite 8 Minimalkonfiguration Die einfachste Variante ist die Installation aller Komponenten auf einer Maschine. Wie die Grafik verdeutlicht, werden im Standard vier Applikations-Server installiert. Verteilte Installationen Einzelner Datenbank-Server Die Leistungsfähigkeit lässt sich oft durch die Abtrennung des DatenbankServers erhöhen. Damit können Datenbankprozesse unabhängig von Zugriffen auf statische Dateien und Applikations-Server-Prozessen laufen. Zusätzlich wurde die Anzahl der Applikations-Server-Instanzen erhöht, um ein breiteres Spektrum für die Behandlung von Anfragen zur Verfügung zu haben. ePages 6 | Technical White Paper Seite 9 Parallelverteilung gemeinsamer Web- und Applikations-Server Einen weiteren Gewinn an Leistungsfähigkeit erreicht man durch die Parallelisierung von Web- und Applikations-Server. Diese Konfiguration ist aus zwei unterschiedlichen Gesichtspunkten interessant: • Hochverfügbarkeit: Fällt eine Maschine aus, übernimmt die andere Maschine den kompletten Betrieb. Für diese Variante ist ein LoadBalancer erforderlich (nicht im ePages 6-Lieferumfang enthalten). • Dedizierte Zuweisung bestimmter Shops (URLs): In einer MultiHosting-Umgebung ist es möglich, eine Maschine gezielt für einzelne Shops zu verwenden. Die Parallelisierung von Web- und Applikations-Servern kann prinzipiell weiter fortgesetzt werden. Parallelverteilung getrennter Web- und Applikations-Server Eine Abtrennung des Web-Servers ist immer dann sinnvoll, wenn der Applikations-Server von sehr vielen Webdaten (Bilder, umfangreiche Seiten) entlastet werden soll. Eine Leistungssteigerung ergibt sich vor allem aus der Vorverlagerung des File-Servers auf den Web-Server und dessen Separierung. ePages 6 | Technical White Paper Seite 10 Die Parallelisierung von Web- und Applikations-Servern kann prinzipiell weiter fortgesetzt werden. Datenbank im Cluster Um die Ausfallsicherheit zu erhöhen, können zwei Datenbank-Server eingesetzt werden. Diese werden in einem sogenannten Cluster (nicht im ePages-Lieferumfang enthalten) betrieben. Die Datenbestände beider Server werden laufend konsistent gehalten. Fällt ein Datenbank-Server aus, würde automatisch der verbleibende Datenbank-Server den Betrieb übernehmen und so die Funktionstüchtigkeit der gesamten Anwendung garantieren. D.h. ein Datenbank-Server ist aktiv, der andere „standby“. Um den „standby“- Server nicht ungenutzt zu lassen, solange beide Maschinen fehlerfrei laufen, wird er als File-Server benutzt. ePages 6 | Technical White Paper Seite 11 Verteilung von Datenbanken auf mehrere Datenbank-Server Falls das Produkt ePages 6 Hosting mit mehreren Datenbanken betrieben wird, können die einzelnen Datenbanken jeweils ihre eigene Maschine erhalten. Damit wird die Leistung datenbankseitig erhöht, Datenbankprozesse werden verteilt und laufen schneller ab. Zum Betrieb von ePages 6 ist eine sogenannte Site-Datenbank erforderlich. Diese wird vor allem in einer Hosting-Umgebung genutzt, um die einzelnen Shops zu verwalten. Auch diese Datenbank kann auf eine separate Maschine ausgelagert werden. ePages 6 | Technical White Paper Seite 12 Sicherheitsmechanismen Unabhängige logische Module ePages 6 ist in einzelne Module für • die technische Administration • die Business-Administration • die Administration durch die Betreiber von Shops und Webseiten sowie • das Frontend (Ansicht für Kunden des Shops bzw. Betrachter der Webseite) getrennt. Die Module sind dabei voneinander isoliert und jedes von ihnen ist speziell für seine Funktionen gestaltet. So wird die Sicherheit des Systems vor unbefugten Zugriffen gewährleistet. Dank spezieller Zugriffsrechte für jedes einzelne Modul ist der Zugriff nur dem Nutzer mit entsprechender Berechtigung möglich. Zum Beispiel ist ein Zugriff eines Händlers auf Funktionen oder Daten der Business-Administration ausgeschlossen. Jedes Modul wird durch eine eigene URL aufgerufen. Nur der technische Administrator ist in der Lage, Datenbankzuweisungen und Installationen durchzuführen. Der technische Administrator stellt dem Business-Administrator Daten bereit, auf deren Grundlage der Business-Administrator Shop- bzw. Homepagetypen definiert und sich einen Überblick über die Homepages und Shops verschaffen kann. Allerdings kann der Business Administrator nicht auf die eigentlichen Produkt- oder Bestelldaten eines Shops oder die Inhalte einer Homepage zugreifen. Der Händler verwaltet seinen Shop mit Hilfe von sieben Modulen, in denen er Bestellungen, Produkte, Kunden, etc. bearbeiten kann, für den Betreiber ePages 6 | Technical White Paper Seite 13 einer Webseite sind entsprechend weniger Funktionen notwendig. Er kann allerdings keinen Einfluss auf den Funktionsumfang nehmen, den der Business-Administrator zur Verfügung stellt. Der Endkunde hat die Möglichkeit, sich Frontend zu bewegen, zu suchen und bei Shops zu bestellen bzw. bei Homepages Reservierungen zu tätigen. Selbstverständlich hat er keinen Einfluss auf Inhalte, die Produktbeschreibungen, Preise, Rabatte, etc. Im Jahr 2006 fand eine erfolgreiche Überprüfung des Shopsystems durch den TÜV Rheinland statt. Passwortschutz Jedes Administrationsmodul und auch der Zugriff auf persönliche Daten registrierter Endkunden („Mein Konto“) ist durch Login und Passwort geschützt. Struktur und Design von ePages 6 verhindern den Zugriff auf jedwede Information „hinter“ der Login-Seite. Alle Passwortinformationen werden verschlüsselt in der Datenbank gespeichert. Die Verschlüsselung ist irreversibel, d.h. ein einmal gespeichertes Passwort kann durch keinen Nutzer eingesehen werden. Vergessene Passwörter können nach entsprechender Authentifizierung zurückgesetzt werden. Dabei wird vom System ein neues Passwort generiert. Bei der Wahl eines Passwortes sollten bestimmte Regeln beachtet werden. Passwörter sollten enthalten: • mindestens einen Großbuchstaben • mindestens einen Kleinbuchstaben • mindestens eine Zahl • mindestens ein Sonderzeichen ePages 6 | Technical White Paper Seite 14 Passwörter sollten in keinem Fall: • einzelne Wörter sein, die in einem Wörterbuch (für eine beliebige Sprache) stehen • einzelne Wörter sein, die in einem Wörterbuch (für eine beliebige Sprache) stehen und die durch ein numerisches Suffix oder Präfix ergänzt werden (z.B. Haus13 oder 12Monkies) • Namen von wirklichen oder fiktiven Orten, Personen, Haustieren, Booten, Fahrzeugen, Produkten usw. sein • mehr als zwei sich wiederholende Zeichen enthalten (z.B. AAA1111) • Zeichen und/oder Ziffern in Folge enthalten (z.B. ABC1234) • mehr als zwei Zeichen einer Tastatursequenz enthalten (z.B. QWErt46) • mit dem Benutzernamen identisch sein Zugriffsrechte Durch die Unabhängigkeit der einzelnen Module untereinander ist auch die Verteilung der Rechte geregelt. Dabei ist es möglich, die Rechte für den Zugriff auf Daten und Funktionen • grob, d.h. pro Modul oder • granularer, d.h. im Detail bezogen auf einzelne Aktionen zu regulieren. Nach der Anmeldung am jeweiligen Modul per Login und Passwort ist die Rolle des Nutzers klar definiert und damit auch seine Berechtigungen. So hat beispielsweise ein Händler vollen Zugriff auf alle Bestell- und Kundendaten seines Shops. Damit ist es ihm z.B. möglich, eine fehlerhafte Kundenadresse zu korrigieren. Der registrierte Endkunde kann über „Mein Konto“ auf seine Bestellungen zugreifen, diese allerdings lediglich einsehen und nicht ändern. Ein Quereinstieg in Funktionen bzw. der Zugriff auf Daten, zu denen der Nutzer in seiner Rolle nicht berechtigt ist, ist damit ausgeschlossen – selbst, wenn jemand versucht, per URL oder nachgebautem Formular Aktionen auszuführen. Einen zusätzlichen Schutz stellt ePages 6 dadurch bereit, dass für Zugriffe auf die Datenbank ein anderer (interner) Nutzer verantwortlich ist. Selbst wenn jemand ein Händlerpasswort ausspioniert hat, sind unerlaubte Direktzugriffe von außen auf die Datenbank unmöglich, da der Datenbankserver zusätzlich hinter einer Firewall steht und nur die Schnittstelle für Datenbankzugriffe (Datenbank-Port) geöffnet haben kann. Session-Sicherheit Session-ID Eine Session (Sitzung) ist die gesamte Dauer einer Reihe von Anfragen an das ePages-System. Dabei muss jede Anfrage des Nutzers an das System stets eindeutig diesem Nutzer zugeordnet werden. ePages 6 generiert dafür eine sogenannte Session-ID, welche der eindeutigen Authentifizierung von Nutzeranfragen an den Server dient. Die Sessioninformation muss dabei auf Seiten des Servers und des Clients (Nutzer, der Anfragen an ePages 6 stellt) vorhanden sein. Erfolgt also eine erneute Anfrage eines Nutzers mit ePages 6 | Technical White Paper Seite 15 derselben Session-ID, so kann der Server diese zuordnen und entsprechend verarbeiten. Damit ist bspw. gewährleistet, dass ein gefüllter Warenkorb eindeutig zu einer Session, also einem bestimmten Nutzer „gehört“ und weitere Produkte, welche dieser Nutzer dem Warenkorb hinzufügt, in genau diesen Warenkorb gelangen. Session-Cookie Auf der Seite des Clients arbeitet ePages 6 mit sogenannten SessionCookies. Die Sessioninformation wird also in einer kleinen Datei gespeichert, welche sich allerdings lediglich im Arbeitsspeicher des ClientComputers befindet. Die Sessioninformation wird nicht auf der Festplatte gespeichert und geht mit dem Schließen des Browserfensters verloren. Diese Technologie garantiert ein Höchstmaß an Sicherheit, weil die Sessioninformationen nicht in der URL auftauchen und somit nicht in falsche Hände gelangen können. Gleichzeitig trägt eine Session-ID-freie URL sehr zur Suchmaschinenfreundlichkeit bei (siehe [7]). Session-Cookies sind bei allen Internet-Browsern auch bei einem hohen Grad von Sicherheitseinstellungen erlaubt und stellen damit keine Hürde für den Nutzer dar. Falls der Nutzer Session-Cookies dennoch deaktiviert hat, wird die Session-ID in der URL mitgeführt. Die Kombination von Sicherheitslogik sowie die Unabhängigkeit der einzelnen Module und Anfragen verhindern vollständig den unerlaubten Zugriff auf Daten oder die nicht autorisierte Ausführung von Funktionen. Anfragenprüfung Ein weiteres Sicherheitsmerkmal ist die Prüfung aller Anfragen (Requests) an den Server auf Gültigkeit. Parallel zur korrekten Session-ID werden nur gültige Anfragen behandelt. Dabei werden evtl. ungültige Parameter ebenso ignoriert wie der Aufruf einer Back Office-Funktion durch einen Frontend-Nutzer. Selbst wenn der Nutzer die Berechtigung hat, auf das Back Office zuzugreifen, so ist dennoch nur in der Lage, den für das Back Office und seine Rolle gültigen Funktionsumfang zu nutzen. Beispiel: Selbst wenn ein Administrator Zugriff auf das Back Office hat, so kann er keine Änderungen an einem Warenkorb vornehmen, den ein Kunde gerade im Frontend zusammenstellt. Zusätzlich können Anfragen für die Administrationsebenen (Technischer und Business-Administrator) nur für bestimmte IP-Adressen zugelassen werden. Voraussetzung dafür ist ein separater Web-Server für diese Bereiche. Verschlüsselung ePages 6 unterstützt selbstverständlich die Verschlüsselung der Seiten und der übermittelten Daten. Dabei wird SSL (Secure Socket Layer) eingesetzt. ePages empfiehlt, alle Administrationsebenen sowie alle Seiten, auf denen im Frontend persönliche Daten (z.B. Adressen oder Zahlungsinformationen) eingegeben werden, zu verschlüsseln. ePages 6 | Technical White Paper Seite 16 Kommunikation mit anderen Systemen Bei der Kommunikation von ePages 6 mit anderen Systemen gelten besondere Bedingungen für die Datenübermittlung. So wird beispielsweise für die Bezahlung über ein elektronisches System in jedem Fall eine verschlüsselte Kommunikation (siehe oben) benutzt. Bei den meisten Anbietern derartiger Systeme (z.B. „PayPal“) werden dabei die Kreditkartendaten nicht innerhalb der ePages-Applikation erfasst. ePages 6 übermittelt auf abhörsicherem Weg lediglich den Betrag und die Währung der Bestellung an das E-Payment-System. Der Endkunde gibt auf diesem die Kreditkarteninformationen ein und autorisiert die Abbuchung für diese Transaktion. ePages 6 und damit auch der Händler erhält lediglich die Bestätigung über den Erfolg (oder Misserfolg) der Transaktion, nicht aber die Kreditkartendaten selbst. Das Plus an Sicherheit liegt hierbei also darin, dass die sicherheitsrelevanten Daten nicht zwischen den verschiedenen Systemen ausgetauscht werden müssen und auch die Shopdatenbank diese Daten nicht verwalten muss. Web Services Eine andere Möglichkeit stellen Web Services dar. Diese Technologie, welche ein spezielles Protokoll (SOAP) und XML-Strukturen als Datencontainer verwendet, wird bspw. bei der Verbindung zwischen ePages 6 und einem Warenwirtschaftssystem (ERP), einem Kundenmanagementsystem (CRM) oder einem Logistiksystem benutzt. Zugriffe über Web Services sollten einerseits verschlüsselt erfolgen (es sei denn, beide Systeme stehen im internen und damit sicheren Netz in Verbindung) und werden andererseits durch die zusätzliche Übermittlung Login-Name und Passwort abgesichert. Der Sicherheit der Daten von miteinander kommunizierenden Anwendungen und der Autorisierung der Funktionsaufrufe sollte bei jeder Integration von ePages 6 große Bedeutung beigemessen werden. ePages 6 | Technical White Paper Seite 17 Erweiterungsmöglichkeiten ePages 6 kann sowohl hinsichtlich der shop-internen Funktionen erweitert werden, als auch bezüglich der Interaktion mit externen Systemen. Diese Anpassungen sind auf verschiedenen Wegen möglich. Um alle Eigenentwicklungen hinsichtlich Design, Datenbankerweiterungen und PerlCodierung zu vereinen, werden die Eigenentwicklungen in Form von “Cartridges” zusammengefasst und dem Shopsystem hinzugefügt. Cartridges orientieren sich an bestimmten ePages 6 Standards und weisen somit eine Reihe von Vorteilen auf: • Sie sind installierbar und deinstallierbar. • Sie kennen Abhängigkeiten und Rechte. • Sie können sämtliche Funktionen der Standard-API nutzen. Für die Erstellung von Cartridges stellt ePages eine “CartridgeDevelopment-Toolbox” zur Verfügung. Diese umfasst hilfreiche Skripte, umfangreiche Dokumentationen mit Code-Beispielen und Datenbankmodellen sowie zwei größere Beispiel-Cartridges. Im Lieferumfang enthalten ist darüber hinaus eine “Diagnostics-Cartridge”. Diese gibt dem Entwickler einen umfassenden Überblick über Details des ePages-Systems sowie über seine eigenen Entwicklungen. ePages 6 | Technical White Paper Seite 18 Headquarters ePages Software GmbH Pilatuspool 2 20355 Hamburg Germany +49-40-350 188-0 phone +49-40-350 188-222 fax [email protected] Jena ePages Software GmbH Leutragraben 1 07743 Jena Germany +49-40-350 188-0 phone +49-40-350 188-111 fax [email protected] London ePages Software Ltd. Hudson House 8 Tavistock Street London, WC2E 7PP United Kingdom +44-203-178 5330 phone +44-203-031 1224 fax [email protected] Barcelona ePages Southern Europe S.L. Entenza 332-334, 3a2o 08029 Barcelona Spain +34-91-453 4355 phone [email protected] San Francisco ePages Software 268 Bush Street, Suite 4040 San Francisco, CA 94104 USA +1-415-294 4343 phone [email protected] epages.com/de © 2009 ePages Software GmbH. Alle Rechte und Änderungen vorbehalten. Alle genannten Warenzeichen sind Eigentum der jeweiligen Hersteller.
