erdfisch

Eingereicht von:

Projektname:

Secure Data Storage

Kategorie:

Lösungen

Hintergrund

Der Secure Data Storage (SDS) wurde entwickelt, um über webbasierte Dienste oder Websites erfasste personenbezogene Informationen in Echtzeit in einen gesicherten, von außen nicht zugänglichen Bereich zu übertragen


Ziele

Erhöhung der Sicherheit beim Erheben von personenbezogenen Daten via Online-Formularen. 


Ergebnisse

Der SDS wird in die Infrastruktur des Kunden als separater Dienst auf einem eigenen Server eingebunden, der nur über eine im internen Servernetzwerk erreichbare IP kontaktiert werden kann. Auf diesem Weg kann die datenerhebende Applikation die über ein Webformular gesammelten personenbezogenen Daten direkt an den SDS übermitteln, wo sie sicher gespeichert werden und dann z.B. durch Drittdienste wie ein CRM weiterverarbeitet werden können. Da die Daten nicht persistent in der Webapplikation gespeichert werden, die für die Datenerhebung zuständig ist, kann auch bei einer Kompromittierung der datenerhebenden Website oder Applikation durch einen Angreifer kein Datenverlust entstehen.


Technische Herausforderungen

Sicherstellung, dass die Datenübertragung belegbar vollständig erfolgt, Failsave-Mechanismen bei Ausfall oder Nicht-Erreichbarkeit des SDS oder seines Servers oder bei einem Übertragungsfehler. Dies wurde wie nachfolgend beschrieben erreicht.

Im umgesetzten Szenario ist die datenerhebende Stelle ein Drupal-Setup. Dieses übermittelt die erfassten Daten an den SDS. Schlägt die Übertragung von Drupal an den SDS fehl, dann wird der Request in eine Queue abgelegt und per Cron (alle 15 Minuten) nochmals ausgeführt. Ab einer definierten Zahl von Fehlversuchen wird der Dienstleister automatisch informiert.

Um die Datenintegrität der übertragenen Daten an den SDS zu gewährleisten, übermittelt Drupal außerdem eine Prüfsumme der Rohdaten. Der SDS berechnet ebenfalls die Prüfsumme der erhaltenen Daten und kann durch einen Vergleich die Vollständigkeit/Integrität der Daten sicherstellen.

Es besteht zudem eine mehrfach redundante Datenvorhaltung, um sicher zu stellen, dass bei jeglicher Störung der Datenübermittlung, die nicht bereits in den bestehenden Failsafe-Mechanismen abgehandelt worden ist, im Ernstfall eine Nachlieferung der Daten an den SDS zumindest in einem begrenzten Zeitraum möglich ist. Daher werden die erfassten Daten in Drupal für einen gewissen Zeitraum zusätzlich noch vorgehalten, hierfür aber verschlüsselt. Für die Verschlüsselung wird AES-256 (Advanced Encryption Standard mit Schlüssellänge von 265 Bit) im Galois/Counter Mode5 verwendet. Da dies ein symmetrisches Verschlüsselungsverfahren ist (d.h. der Schlüssel zum Ver- und Entschlüsseln ist identisch), kommt ein im internen Netzwerk verortender weiterer Dienst namens "Vault" (https://www.vaultproject.io) zum Einsatz. Vault bietet neben einer flexiblen ACL unter anderem ein "encryption-as-a-service" (Transit Secret Backend) über eine API an. Damit kann man den Drupal-Webservern die Berechtigung geben Daten zu verschlüsseln, aber nicht zu entschlüsseln. Dies können die Webserver dann, ohne den eigentlichen Schlüssel zu kennen.

Damit die Live-Datenbank im Laufe der Zeit nicht unnötig viele – wenn auch verschlüsselte – Daten enthält, existiert ein Cron-Job, der jede Nacht Webform-Submissions, die älter als die definierte Zielschwelle sind, als SQL-Dump auf einen Backup- Server kopiert (SSH/SCP) und die Altdaten anschließend aus der Drupal-Datenbank löscht.

Um sicher zu stellen, dass der Datenübertragungsmechanismus durch kontinuierliche Weiterentwicklung am Drupal-Setup nicht beeinflusst wird, ist der komplette Prozess einschließlich der "Notfallwiederherstellung" der verschlüsselten Daten mit automatisierten Tests versehen.

In einer neuen Version des SDS, die 2017 erschienen ist, übernimmt dieser zusätzlich außerdem die Datennormalisierung und das Mapping der erfassten Daten für die Weiterverarbeitung selbiger im internen CRM-System des Kunden.


Erscheinungsdatum

01.07.2017