Warum Spiegeln wir Produktiv-Daten ein Mal pro Woche auf einen Testserver?
Im folgenden Dokument erklären wir die Hintergründe und warum diese Maßnahme den Datenschutz sogar deutlich erhöht.
Wie in unserer AVV geregelt, spiegeln wir jeden Sonntag alle Produktiv-Datenbanken auf einen Test-Datenbank-Server, wo sie in der nächsten Woche wieder überschrieben werden.
Maßname
- Jeden Sonntag werden Produktiv-Daten vom Produktiv-Datenbank-Server auf einen Test-Datenbank-Server gespiegelt.
- Diese Test-Datenbanken werden dann jedes Mal überschrieben, so dass die Daten maximal eine Woche aufgehoben werden.
Begründung
Pre-Release-Testing von Updates
- Jeder Kunde hat bei uns eine enorm individuelle Konfiguration. Dokumente, Nutzermasken, Workflows, Auswertungen und Schnittstellen basieren darauf.
- Updates der Software können diese Konfigurationen leicht beschädigen, was zu Einschränkungen beim Kunden bis hin zum Datenverlust führen kann.
- Darum ist es enorm wichtig Updates nicht nur allgemein ausgiebig zu testen, sondern auch zuvor gegen die jeweiligen Konfigurationen der Kunden zu testen.
- Diese Tests erfolgen automatisiert. Nur wenn alle Tests erfolgreich verlaufen, wird das Update veröffentlicht.
- Damit diese Test nicht in der Produktiv-Umgebung ausgeführt werden müssen, verwenden wir die gespiegelten Test-Datenbanken dafür. Damit können wir eine sehr hohe Zuverlässigkeit des Systems garantieren, obwohl es so individuell konfiguriert ist.
Positiv für den Datenschutz:
- Verringerung des Fehlerpotentials.
- Verhinderung von Nicht-Verfügbarkeits-Zeiträumen.
- Verhinderung, dass Updates die Arbeitsfähigkeit der Nutzer*innen beeinträchtigen.
- Verhinderung von Datenverlust.
- Unsere MA würden ohnehin mit den personenbezogenen Daten arbeiten müssen. Diese Maßnahme führt also einen weiteren Sicherheits-Layer ein.
Alternativen:
- Wir würden das Testing im Produktiv-System vornehmen müssen
- Wir würden Testing auf pseudonymisierten Daten durchführen müssen, wodurch nicht alle Fehlerquellen zuverlässig getestet werden können.
Bearbeiten von Support-Aufträgen
- Wir nutzen diese Testdatenbanken auch um Support-Aufträge vorzubereiten, bevor sie in die Live-Datenbank überführt werden.
- Beispielsweise das Anlegen und Bearbeiten von Auswertungen, Dokumenten, Schnittstellen, Workflows und Nutzer-Masken bereiten wir zunächst in der Testumgebung vor.
- Würden wir dies im Produktiv-System vornehmen, könnte es zu Beeinträchtigungen der Nutzer*innen kommen.
- Zum Bearbeiten dieser Aufträge sind oft Klardaten erforderlich, um bspw. das Layout von Dokumenten anzupassen oder Schnittstellen testen (Import & Export) testen zu können
- Erst nach Fertigstellung und Test werden die Änderungen "auf Live" übertragen.
Positiv für den Datenschutz:
- Verringerung des Fehlerpotentials.
- Verhinderung, dass Änderungen die Arbeitsfähigkeit der Nutzer*innen beeinträchtigen.
- Unsere MA würden ohnehin mit den personenbezogenen Daten arbeiten müssen. Diese Maßnahme führt also einen weiteren Sicherheits-Layer ein.
Alternativen:
- Wir würden diese Arbeiten im Produktiv-System vornehmen müssen
- Wir würden diese Arbeiten im pseudonymisierten Daten vornehmen müssen, wodurch manuelle Nacharbeiten notwendig werden könnten und Bearbeitungszeiten steigen.
Bearbeiten von Support-Anfragen
In einigen Support-Fällen ist es wichtig auf nicht-pseudonymisierte Daten zugreifen zu können.
- Besonders, wenn uns Software- oder Konfigurations-Fehler berichtet werden, können wir die Fehlerursache unabhängig vom Produktiv-System durchführen.
- Durch den Zugriff auf die Testumgebung können wir wir Fehler schneller und zuverlässiger finden und beheben.
- Wir wollen so oft es geht vermeiden, dass wir Support auf der produktiven Datenbasis durchführen.
Positiv für den Datenschutz:
- Wir können das Nachstellen von Fehlerursachen außerhalb des Produktiv-System durchführen.
- Wir können Support zum Großteil ohne Zugriff auf die Produktiv-Umgebung durchführen.
- Unsere MA würden ohnehin mit den personenbezogenen Daten arbeiten müssen. Diese Maßnahme führt also einen weiteren Sicherheits-Layer ein.
Alternativen:
- Wir würden diese Arbeiten im Produktiv-System vornehmen müssen
- Wir würden diese Arbeiten im pseudonymisierten Daten vornehmen müssen, dadurch können wir Fehlerursachen oft nicht zuverlässig nachstellen oder laufen Gefahr Daten zu beschädigen.
Bereitstellen einer Testumgebung für die Nutzer*innen
- Wir stellen die gespiegelten Datenbanken auch den Nutzer*innen als Testsystem zur Verfügung.
- Manchmal wollen Nutzer*innen Aktionen oder Funktionen vorher ausprobieren, bevor sie sie “in Echt” verwenden. Dazu sind verhältnismäßig aktuelle Daten nötig.
- Viele Kunden fordern diese Test-Instanzen explizit, genutzt werden sie von allen Kunden.
Positiv für den Datenschutz:
- Auch die Anwender*innen können Funktionen außerhalb der Produktiv-Umgebung testen. Das verhindert den Verlust oder die Beschädigung von Daten und gibt den Anwender*innen Sicherheit.
- Das Bereitstellen der Testumgebung ist automatisiert und alte Datenstände werden automatisch überschrieben.
Alternativen:
- Anwender*innen müssten Funktionen in der Produktiv-Umgebung testen.
- Eventuell geforderte Testdatenbanken werden nicht automatisch aktualisiert und alte Datenstände werden teils sehr lang aufgehoben.
Verringerung des Verwaltungsaufwands und der Kosten
- Die Spiegelung der Live-Daten in das Testsystem erfolgt automatisiert ohne menschliche Interaktion.
- Wir sind also jederzeit sofort handlungsfähig.
- Durch die Automatisierung entstehen für unsere Kunden keine zusätzlichen Kosten. Würden wir für jeden Kunden manuell Testumgebungen errichten müssen, sobald wir sie benötigen, würde dieser manuelle Aufwand die Kosten für unsere Kunden erhöhen, gleichzeitig aber keine Verbesserung des Datenschutzes darstellen.
Positiv für den Datenschutz:
- Durch die Nutzung der Testdatenbanken können wir vermeiden, dass alle unsere Kollegen Zugriff auf die Live-Datenbanken benötigen.
- Wir schützen die Integrität der Live-Daten dadurch auch vor internen Prozessen bei uns ohne unsere Leistungsfähigkeit einzuschränken.
- Die Lebenszeit dieser Test-Datenbanken ist mit einer Woche sehr gering.
- Die Test-Datenbanken sind und physisch von den Produktiv-System getrennt. Eine Vermischung ist ausgeschlossen.
- Unsere MA würden ohnehin mit den personenbezogenen Daten arbeiten müssen. Diese Maßnahme führt also einen weiteren Sicherheits-Layer ein.
Alternativen:
- Wir könnten pro Support-Fall jeweils Datenstände manuell bereitstellen. Das wäre aufwändiger und teurer und bietet keine Vorteile im Datenschutz.
- Die Lebenszeit der manuell erstellten Testdatenbanken wäre nicht garantiert auf eine Woche beschränkt.