Читать книгу Der strafprozessuale Zugriff auf Inhaltsdaten in der Cloud - Dirk Meinicke - Страница 19

Grundsätzliche Schwierigkeiten ergeben sich für den Zugriff von Ermittlungsbehörden auf in der Cloud abgelegte Daten mit Blick auf Fragen der Datenlokalität. Es ist gerade kennzeichnend für Cloud Computing – und ein wichtiger Unterschied zu bisherigen IT-Outsourcing Methoden –, dass die für die Datenspeicherung verwendeten Server prinzipiell überall auf der Welt stehen können und dass selbst für den Nutzer nicht immer ohne weiteres feststellbar ist, wo sich die Daten (aktuell) befinden.158 Teilweise werden dem Nutzer unterschiedliche Speicherregionen zur Auswahl angeboten, so z.B. bei den Amazon Web Services die Regionen US Standard, ER (Data Center in Irland), US West (Nord-Kalifornien), sowie Asien-Pazifik (Singapur) und Asien-Pazifik (Tokio).159 Eine weitere für den hier behandelten Kontext relevante Besonderheit besteht darin, dass die Daten nicht notwendig auf einem bestimmten Server gespeichert werden, wo auch immer dieser sich befinden mag, sondern dass auch die Bildung eines weltweit verteilten Clusters möglich ist, bei dem die Daten auf eine nicht genauer definierte Menge kooperierender Rechner verteilt sind.160 Im Falle eines Nutzerzugriffs wird dynamisch entschieden, welche Rechner heranzuziehen sind.161

Aus alldem folgt für die hier behandelten strafprozessualen Fragestellungen: Es wird sich oft schwierig (oder gar nicht) feststellen lassen, wo sich die in einer Cloud gespeicherten Daten im Zeitpunkt eines beabsichtigten Zugriffs durch die Ermittlungsbehörden befinden. Das ist selbst für die Benutzer nicht immer ohne weiteres nachvollziehbar, was im Übrigen vor allem im Unternehmensbereich zu einer teilweise zurückhaltenden Haltung gegenüber Cloud Computing geführt hat.162 Damit ist es – im Regelfall einer Datenlokalität außerhalb des Bundesgebiets – für die Ermittler aber oft bereits gar nicht zu entscheiden, gegenüber welchem Land z.B. ein Rechtshilfeersuchen zu erstatten ist. Bisweilen finden sich die Datenpakete sogar über mehrere Standorte verteilt und sind somit überhaupt nicht an einem einheitlichen Ort als möglicher Gegenstand eines ermittlungsbehördlichen Zugriffs verfügbar. Dieser Umstand wird sich im Laufe der Untersuchung als eine der zentralen faktischen Schwierigkeiten beim Zugriff auf in der Cloud abgelegte Daten erweisen.

Allerdings ist darauf hinzuweisen, dass sich aus derselben technischen Besonderheit – der oft fehlenden Nachvollziehbarkeit der Datenlokalität in der Cloud – auch Nachteile für eine kriminogene Nutzung ergeben können. Insbesondere ist auch die vollständig erfolgte Löschung von Daten oft nicht sicher überprüfbar, da der Nutzer nie ausschließen kann, dass sich trotz eines in der Benutzeroberfläche eingegebenen Löschauftrags irgendwo in der Cloud-Architektur noch eine redundante Kopie der Daten befindet,163 auf die dann trotz der Löschung ein Zugriff der Strafverfolgungsorgane potentiell möglich bleibt. Überhaupt kann die für Cloud Computing typische fehlende Herrschaft des Nutzers über die in der Cloud abgelegten Daten für Kriminelle einen Grund darstellen, von einer Speicherung potentiell belastender Informationen in der Cloud abzusehen. Zudem implementieren die Cloud-Provider unterschiedliche Sicherungskonzepte (siehe bereits oben), in deren Rahmen z.B. Momentaufnahmen eines Datenbestandes gespeichert werden (sog. Snapshots) oder sämtliche Transaktionen anhand von Log-Dateien nachvollziehbar bleiben (sog. Forward Recovery).164 Solche und andere Sicherungsmaßnahmen, die das Vertrauen der „redlichen“ Cloud-Nutzer stärken sollen, können Kriminelle gerade abschrecken.

Die Praxis zeigt allerdings, dass z.B. Webmail-Dienste – die ebenfalls eine Form von SaaS sind – häufig ohne größere Bedenken von Kriminellen verwendet werden. Im Übrigen existieren unterschiedliche Anonymisierungs- und Verschlüsselungsverfahren, durch die Risiken eines Zugriffs Dritter (auch der Mitarbeiter des Cloud-Anbieters) begrenzt werden können.165

122 Vgl. zu den insoweit oft erforderlichen sog. transaktionalen Garantien, durch die gewährleistet ist, dass sich ein Mehrbenutzersystem für jeden einzelnen Nutzer wie ein Einbenutzersystem darstellt vgl. Vossen/Haselmann u.a., Cloud-Computing, S. 52. 123 Zum Vorstehenden Vossen/Haselmann u.a., Cloud-Computing, S. 49. 124 Vossen/Haselmann u.a., Cloud-Computing, S. 53. 125 Vossen/Haselmann u.a., Cloud-Computing, S. 54. 126 Vossen/Haselmann u.a., Cloud-Computing, S. 50. 127 Schorer, in: Hilber, Handbuch, C/1, Rn. 47. 128 Meir-Huber, Cloud Computing, S. 34f. 129 Vossen/Haselmann u.a., Cloud-Computing, S. 50f. und näher S. 55ff. 130 Vossen/Haselmann u.a., Cloud-Computing, S. 13f. 131 Vossen/Haselmann u.a., Cloud-Computing, S. 14f. 132 Näher hierzu Meir-Huber, Cloud Computing, S. 32f. 133 Vossen/Haselmann u.a., Cloud-Computing, S. 53. 134 Vossen/Haselmann u.a., Cloud-Computing, S. 52f. 135 Dazu Vossen/Haselmann u.a., Cloud-Computing, S. 69f. 136 Zu diesem Aspekt siehe Vossen/Haselmann u.a., Cloud-Computing, S. 69. 137 Vossen/Haselmann u.a., Cloud-Computing, S. 70. 138 Vossen/Haselmann u.a., Cloud-Computing, S. 70f. 139 Vossen/Haselmann u.a., Cloud-Computing, S. 71. 140 Vossen/Haselmann u.a., Cloud-Computing, S. 71. 141 Vossen/Haselmann u.a., Cloud-Computing, S. 71. 142 Vossen/Haselmann u.a., Cloud-Computing, S. 71. 143 Vossen/Haselmann u.a., Cloud-Computing, S. 71. 144 Vossen/Haselmann u.a., Cloud-Computing, S. 190. 145 Vossen/Haselmann u.a., Cloud-Computing, S. 71. 146 Vossen/Haselmann u.a., Cloud-Computing, S. 71. 147 Vossen/Haselmann u.a., Cloud-Computing, S. 71. 148 Vossen/Haselmann u.a., Cloud-Computing, S. 71f. mit dem Hinweis auf die Möglichkeit, vollständige Backups aus den partiellen Backups zu synthetisieren. 149 Vossen/Haselmann u.a., Cloud-Computing, S. 72, die von einem „umgekehrten inkrementellen bzw. differenziellen Backup“ sprechen. 150 Vossen/Haselmann u.a., Cloud-Computing, S. 72. 151 Vossen/Haselmann u.a., Cloud-Computing, S. 72. 152 Vossen/Haselmann u.a., Cloud-Computing, S. 72. 153 Näher zu allem Vossen/Haselmann u.a., Cloud-Computing, S. 72f. 154 Vossen/Haselmann u.a., Cloud-Computing, S. 73. 155 Vossen/Haselmann u.a., Cloud-Computing, S. 73. 156 Vossen/Haselmann u.a., Cloud-Computing, S. 73. 157 Hierzu Vossen/Haselmann u.a., Cloud-Computing, S. 75 und 180. Vormals war es üblich, die Sicherheit und Integrität der den einzelnen Mandanten zugeordneten Datenbeständen durch physische Trennung der verwendeten Systeme zu gewährleisten, was sich jedoch als unwirtschaftlich herausgestellt hat. Heute werden dagegen Virtualisierungskonzepte zur Anwendung gebracht, die einen parallelen Betrieb unterschiedlicher Mandanten auf derselben Hardware ermöglichen, vgl. zum Ganzen Schorer, in: Hilber, Handbuch, C/1, Rn. 43ff. 158 Schmidt-Bens, Cloud Computing, S. 3; Metzger/Reitz u.a., Cloud Computing, S. 14; auch Terplan/Voigt, Cloud, S. 191. 159 Vossen/Haselmann u.a., Cloud-Computing, S. 6f., zur Datenlokalität auch, S. 77. 160 Metzger/Reitz u.a., Cloud Computing, S. 50f.; zur Fragmentierung von Daten auch Vossen/Haselmann u.a., Cloud-Computing, S. 178. 161 Metzger/Reitz u.a., Cloud Computing, S. 50f. 162 Vossen/Haselmann u.a., Cloud-Computing, S. 177. 163 Zu diesem Aspekt Vossen/Haselmann u.a., Cloud-Computing, S. 177. 164 Vossen/Haselmann u.a., Cloud-Computing, S. 70f. 165 Vgl. dazu im Überblick Schmidt-Bens, Cloud Computing, S. 73ff.; zu den Grenzen möglicher Verschlüsselungen aber Schorer, in: Hilber, Handbuch, C/1, Rn. 85.