Im heutigen e-Business sind sie allgegenw├Ąrtig: Web-Formulare, ├╝ber die Benutzer einer Website beispielsweise Kundenkonten anlegen, Online-Bestellungen vornehmen, Abos abschlie├čen oder an Mitmachaktionen wie z.B. Online-Petitionen teilnehmen k├Ânnen.

Hierbei werden in der Regel personenbezogene Daten abgefragt. Neben dem Namen sind das ├╝blicherweise die E-Mail-Adresse, die Postadresse und, falls es sich um einen Online-Kauf handelt, auch Daten wie die Bankverbindung oder die Kreditkartennummer des Nutzers.

Sobald der Nutzer diese Daten an den Anbieter ├╝berantwortet, verl├Ąsst er sich darauf, dass dieser mit den anvertrauten Daten verantwortungsvoll umgeht und entsprechende Vorsorge trifft, dass diese Daten sicher aufbewahrt werden und nicht in die H├Ąnde von Unbefugten gelangen k├Ânnen.

Viele Anbieter von Online-Diensten behandeln personenbezogene Daten nicht mit der notwendigen Sorgfalt

Die Realit├Ąt zeigt jedoch, dass dieses Vertrauen in vielen F├Ąllen nicht gerechtfertigt ist. Viele Anbieter von Online-Diensten legen in Bezug auf den Umgang mit den erhobenen Nutzerdaten eine beunruhigende Sorglosigkeit an den Tag. Sensible Daten wie beispielsweise Bankverbindungen verbleiben nach dem Absenden durch den Nutzer einfach direkt in der Datenbank der Website, aus welcher heraus die Daten erhoben worden sind. Damit besteht immer die Gefahr, dass diese Daten in die H├Ąnde von Dritten gelangen k├Ânnen, wenn es diesen gelingt, eine Website zu kompromittieren. Selbst Websites, die auf dem WCMS Drupal basieren, welches an und f├╝r sich einen sehr hohen Wert auf Sicherheit legt, sind davor nicht sicher. Auch bei Drupal werden mitunter Sicherheitsl├╝cken entdeckt, die ein Angreifer ausnutzen k├Ânnte, um sich unberechtigten Zugang zur Website zu verschaffen. Zwar werden diese Sicherheitsl├╝cken vom hervorragenden Drupal-Security-Team bei Bekanntwerden stets schnell geschlossen - jedoch muss der Betreiber einer Website dann nat├╝rlich auch zeitnah das entsprechende Sicherheits-Update einspielen. Besteht ein Vertrag mit einem Drupal Dienstleister, k├╝mmert dieser sich zeitnah um die notwendigen Ma├čnahmen.

Aber selbst wenn die Website nicht "gehackt" wird ist es fahrl├Ąssig, sensible Daten dauerhaft in der Datenbank vorzuhalten. Denn ├╝blicherweise existieren bei einem komplexen System neben der Live-Umgebung auch noch Kopien, die z.B. f├╝r die Weiterentwicklung oder die Abnahme neuer Features verwendet werden, und dabei meist auch den Datenbestand des Live-Systems ├╝bernehmen. Hier wandern die nutzerbezogenen Daten dann gegebenenfalls auf Drittserver oder sogar auf die lokalen Festplatten von Entwicklern, die am System arbeiten. Somit verliert der Anbieter hier zunehmend die Kontrolle dar├╝ber, wo seine erhobenen Daten sich ├╝berall befinden und muss das unn├Âtige Risiko tragen, dass sensible Daten in falsche H├Ąnde geraten k├Ânnen.

Aus den genannten Gr├╝nden ist es somit grunds├Ątzlich nicht empfehlenswert, besonders kritische personenbezogene Daten dauerhaft in einer von au├čen zug├Ąnglichen Datenbank zu verwahren. Dies gilt insbesondere dann, wenn diese Daten unverschl├╝sselt in der Datenbank abgespeichert werden sollten, was bei den ├╝blichen Mechanismen zur Datenerfassung eher die Regel als die Ausnahme sein d├╝rfte.

Wozu werden die Daten erfasst und was geschieht damit?

Es lohnt sich in diesem Zusammenhang zu rekapitulieren, wozu der Anbieter die gew├╝nschten Daten eigentlich beim Nutzer erhebt. Beispielsweise ist es bei n├Ąherer Betrachtung nicht notwendig, Daten wie z.B. die Bankverbindung eines Kunden dauerhaft in der Datenbank einer Website zu belassen. Informationen wie diese werden einmalig ├╝ber ein Webformular erfasst, z.B. wenn ein Kauf get├Ątigt wird, oder wenn bei regelm├Ą├čigen K├Ąufen eine Einzugserm├Ąchtigung f├╝r ein bestimmtes Konto erteilt werden soll.
Hierbei werden die Daten dann aber normalerweise nur ├╝ber die Website erfasst, um danach z.B. in regelm├Ą├čigen Abst├Ąnden in ein internes CRM importiert zu werden. Dennoch muss es zum Zeitpunkt der ├ťbermittelung der Daten einen Speicherort geben, an welchem die Daten zuverl├Ąssig hinterlegt werden, um einmalig oder bei Bedarf auch mehrfach durch den Anbieter f├╝r den Zweck weiterverarbeitet zu werden, f├╝r den der Kunde ihm die Daten ├╝berlassen hat. Das kann aber aus beschriebenen Gr├╝nden nicht die Datenbank der Website sein, ├╝ber die die Daten erhoben worden sind.

Sensible Daten erfassen und sicher aufbewahren f├╝r mehr Datensicherheit

Aus diesem Grund setzt erdfisch bei Drupal-Projekten, bei denen solch sensible Daten erhoben werden, einen Dienst namens Secure Data Storage (SDS) ein. Dieser l├Ąuft auf einem separaten Server, der von au├čen nicht zug├Ąnglich ist. Der SDS nimmt Formulareingaben, die auf einer Web-Applikation erfolgen, f├╝r definierte Datens├Ątze direkt entgegen und speichert diese.

Ist das Nutzerszenario beispielsweise ein Online-Shop, bei dem ein Besucher eine Bestellung aufgibt und per Lastschrifteinzug zahlen m├Âchte, so wird die im Formular ├╝bermittelte IBAN garnicht erst im Shop selbst gespeichert. Statt dessen wird sie sofort an den SDS ├╝bertragen. Dieser wiederum stellt die Information dem internen CRM des Kunden zur Verf├╝gung, ├╝ber welches die Bestellung verarbeitet wird.

Ebenso ist es denkbar, z.B. im Rahmen von Online-Petitionen nutzerbezogene Daten vom Klarnamen ├╝ber die E-Mail-Adresse bis zur postalischen Adresse zu erfassen und als Teilnahmebeleg zu verwahren oder intern weiter zu verarbeiten. Durch den SDS ist das m├Âglich, ohne dass diese Daten auf der Website, ├╝ber die die Petition angeboten wird, auch nur zwischengespeichert werden m├╝ssen.

Gewappnet f├╝r den Ernstfall

Der SDS-Dienst und die Vorhaltung der Daten ist von der Website selbst getrennt und zudem auf einem eigenen Server verortet, der nicht unter einer URL oder IP von au├čen erreichbar ist. Dadurch wird es einem potentiellen Angreifer sehr viel schwerer gemacht, an die betreffenden Daten zu gelangen. Der SDS wiederum kann innerhalb eines internen und entsprechend gesch├╝tzten Netzwerks die verwalteten Daten anderen Dienste des Anbieters, wie z.B. einem internem CRM, zur Verf├╝gung stellen.

Selbst wenn also der "Worst-Case" eintreten sollte und die Web-Applikation des Anbieters kompromittiert und unter die vollst├Ąndige Kontrolle eines Unbefugten geraten sollte, so ist durch den SDS doch sichergestellt, dass die dorthin ├╝bertragenen Daten f├╝r den Angreifer unzug├Ąnglich bleiben.

Fazit: Das perfekte Gespann f├╝r mehr Datensicherheit

Vollverschl├╝sselung der Web-Applikation mit SSL, ein regelm├Ą├čig gewartetes Drupal als solides Fundament und als eines der sichersten WCMS auf dem Markt, kombiniert mit dem SDS zur Verwahrung besonders sensibler Daten, die ├╝ber das Web erfasst werden - mit dieser Kombination ist ein Web-Anbieter sehr gut aufgestellt, und verringert dadurch das Risiko, Opfer eines Datendiebstahls zu werden, entscheidend.

Profilfoto Fabian Lorenzen

Fabian Lorenzen

Gesch├Ąftsf├╝hrer / Projekt Manager