ePages 5 Technical White Paper

Transcription

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: info@ePages.de
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: consulting@epages.de
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)
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.
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.
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
•
Test System:
1 x quad core XEON, 3.20 GHz, 8 GByte RAM,
146 GByte HD
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
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)
•
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
•
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.
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.
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.
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.
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.
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
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
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
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.
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.
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.
Seite 18
Headquarters
Pilatuspool 2
20355 Hamburg
Germany
+49-40-350 188-0 phone
+49-40-350 188-222 fax
info@epages.com
Jena
Leutragraben 1
07743 Jena
Germany
+49-40-350 188-0 phone
+49-40-350 188-111 fax
info@epages.com
London
ePages Software Ltd.
Hudson House
8 Tavistock Street
London, WC2E 7PP
United Kingdom
+44-203-178 5330 phone
+44-203-031 1224 fax
info@epages.co.uk
Barcelona
ePages Southern Europe S.L.
Entenza 332-334, 3a2o
08029 Barcelona
Spain
+34-91-453 4355 phone
info@epages.es
San Francisco
ePages Software
268 Bush Street, Suite 4040
San Francisco, CA 94104
USA
+1-415-294 4343 phone
usa@epages.com
epages.com/de
© 2009 ePages Software GmbH.
Alle Rechte und Änderungen vorbehalten. Alle genannten Warenzeichen sind Eigentum der jeweiligen Hersteller.

ePages 5 Technical White Paper

Transcription

Similar documents

die schärf - Delikant Snack Akademie

/// DEBITEL – Imagekampagne

My first SAN – ein Leitfaden

IP Control User Guide V1.6_ger

be.smart Effizienzsteigerungen durch standardisiertes

PDF-Download

- operational services

markeZin - Hochschule Karlsruhe

installieren von soliDWorKs READ ME