Jacob moniert, das Teledienstedatenschutzgesetz (TDDSG) aus dem Jahr 1997 habe zwar seine erste Bewährungsprobe bestanden. Allerdings müsse es unbedingt an die technischen Entwicklungen und an die Erfahrungen mit dem Internet angepasst werden.
Deutschlands oberster Datenschützer denkt dabei vor allem an die Praktiken von Internet-Kaufhäusern.
Diese würden die kaum durchschaubare Gesetzeslage ausnutzen, um Daten in illegitimer Weise gegen den Willen ihrer Kunden weiterzuverarbeiten. Jacob schreibt in seinem "Tätigkeitsbericht 1999 - 2000", die Transparenz auch der Gesetzeslage stoße beim Kauf via Internet da an Grenzen, wo Online- und Offline-Welt sich überschneiden. Was Folgen hat, denn diese beiden Sphären werden juristisch unterschiedlich bewertet.
Bestellt etwa ein Surfer via Internet bei einem virtuellen Kaufhaus, so gilt für die Daten, die während des Online-Handels beim Versenden des Bestellformulars erstellt wurden, das strenge TDDSG. Dieses verbietet die Weitergabe von Nutzungsdaten an Dritte. Die Daten der Bestellung selbst aber, das heißt die Lieferadresse und die Bezeichnung der bestellten Ware etwa, fallen unter das weniger strenge Bundesdatenschutzgesetz (BDSG). Grund: Diese Angaben sind auch für die Abwicklung des Handels außerhalb der Online-Welt erforderlich, für die korrekte Zulieferung beispielsweise.
Das BDSG erlaubt die Weitergabe dieser Daten für Werbezwecke unter der Bedingung, dass der Kunde dem nicht ausdrücklich widerspricht. Und genau hier beginnen die Probleme: Weil nämlich, moniert Jacob, der Verbraucher das "Einkaufen über das Internet als einheitlichen Dienst" ansieht, würde er eine beruhigende Zusicherung von Vertraulichkeit auch auf den gesamten Vorgang beziehen - also von der Online-Bestellung bis zur Auslieferung der gewünschten Ware bei ihm zu Hause. Aber genau diese Zusicherung ist immer nur für den Online-Teil des Handels gemeint.
Der Kunde, der das nicht weiß, sieht keinen Anlass, der weiteren Verwendung seiner Daten zu widersprechen. Der Täuschung folgt dann die Enttäuschung, schreibt Jacob, wenn der Kunde später, etwa bei Zusendung von Direktwerbung durch Dritte, erkennen muss, dass seine Daten doch nicht vertraulich behandelt wurden. "Der damit erzeugte Vertrauensschaden trifft nachher nicht nur die Anbieter, die solche Verfahren praktizieren, sondern den gesamten Bereich des E-Commerce", warnt Jacob.
Hier könne ein Datenschutzaudit abhelfen, das die Redlichkeit der gegenüber dem Kunden abgegebenen Erklärungen nicht am gesetzlichen Minimum misst, sondern am vernünftigen Alltagsverständnis. Vor allem für den E-Commerce werden Gütesiegel angeboten, die dem Verbraucherschutz insgesamt dienen sollen und somit die Einhaltung von Datenschutz-Mindeststandards nur als eine von vielen wünschenswerten "Eigenschaften" eines Online-Shops bestätigen.
Als beispielhaft nennt der oberste deutsche Datenschützer hier etwa die Trusted Site des TÜViT, den geprüften Online-Shop des Europäischen Handelsinstituts und die Trusted Shops des Gerling-Konzerns. Allerdings kritisiert Jacob, dass Datenschutzerklärungen im Sinne einer Privacy Policy immer noch selten sind. Wenn überhaupt, fänden sich solche Hinweise vornehmlich versteckt in den Allgemeinen Geschäftsbedingungen (AGB). Und dann seien sie oft inhaltlich auch nur sehr dürftig oder zu allgemein gehalten. Ebenso selten sei eine Unterrichtung der Nutzer über den Umfang und Zweck der Datenerhebung, -verarbeitung und -nutzung durch Zugangs-Provider.
Jacob geißelt die Untugend von Providern, die entgegen dem Wunsch von Kunden heimlich Daten über diese sammeln und sie mit Hilfe von Cookies und Web-Bugs ausforschen. Dies sei mittlerweile zu einem eigenständigen Gewerbe geworden. Im Ergebnis wachse das Misstrauen der potenziellen Kunden gegen Internet-Geschäfte aller Art. US-amerikanische Anbieter reagieren hierauf mit einem "Marketing by permission". Hierbei wird dem Kunden in einem klaren Verfahren die alleinige Entscheidung eingeräumt, ob und gegebenenfalls wie seine Daten weiterbehandelt werden dürfen.
Richtig bedenklich ist, was Jacob über den Umgang mit personenbezogenen Daten beispielsweise im Gesundheitswesen schreibt. Sogar gegen den unberechtigten Zugang zu hochsensiblen personenbezogenen Daten zum Beispiel zur Gesundheit der Betroffenen gebe es keinen ausreichenden Schutz. Diese würden nicht einmal verschlüsselt. Zwar werden die Informationen auf organisatorisch abgeschotteten Rechnern bearbeitet, dann aber häufig auf einem zentralen Server gesichert, der in einem anderen Bereich oder Gebäude oder gar in einer anderen Liegenschaft steht. Die Daten werden, so Jacob, in aller Regel von einem Anwender-PC über ein LAN oder eine ISDN-Leitung ungeschützt zum Server übertragen. Dort sichert man sie mit anderen, nicht personenbezogenen Daten auf ein und demselben Datenträger.
Bei seinen Recherchen in Unternehmen und Behörden stieß Jacob häufig auf technisch völlig überholte Firewalls. Er zitiert den Fall einer Behörde, die eine stark veraltete Software benutzte, deren Herstellerfirma gar nicht mehr existierte. Firewall-Systeme, fordert der Datenschützer, bedürften einer ständigen Aktualisierung, um den Angriffen aus dem Internet auf Dauer widerstehen zu können. Mit der bloßen Inbetriebnahme eines Firewall-Systems sei es nicht getan. Der finanzielle und personelle Aufwand für solch eine Firewall sei nicht zu unterschätzen.
Spezielles Augenmerk richtete Jacob in seinem Datenschutzbericht auf die SAP und die datenschutzrechtlichen Aspekte des Einsatzes von R/3 im Personalwesen. Diese branchenunabhängige Unternehmenssoftware könne ohne Übertreibung als De-facto-Standard in der Wirtschaft angesehen werden. Dessen Erfolg mache vor allem die Flexibilität aus, mit der R/3 an Betriebs- und Verwaltungsstrukturen angepasst werden könne.
Diese hohe Flexibilität und Skalierbarkeit birgt aber auch die Gefahr der Unübersichtlichkeit, wenn bestimmte Größenordnungen überschritten werden, schreibt Jacob. Das R/3-Berechtigungskonzept erscheine zwar an sich datenschutzrechtlich sinnvoll. Danach bekommt jeder Benutzer exakt die Berechtigungen, die er für seine Aufgaben benötigt. Die aus Sicht des Datenschutzes grundsätzlich zu begrüßenden sehr feinen Rechtestrukturen könnten aber auch bewirken, dass die Transparenz der Rechtevergabe schnell verloren geht und damit eine Revision der Zugriffs- und Benutzerkontrollen im Sinne des Paragraphen 9 BDSG faktisch unmöglich wird.
Selbst mit dem System vertraute Personen wie etwa Administratoren könnten Sicherheitslücken leicht übersehen oder gar unbewusst verursachen. Aus Datenschutz-Perspektive stehe bei der Nutzung von R/3 deshalb ein einwandfreies Berechtigungskonzept im Vordergrund des Interesses. Die Standardversion von SAP R/3 beinhaltet allein etwa 700 Berechtigungsobjekte, daneben können je Benutzerstammsatz nochmals zirka 1300 Berechtigungseinträge vorgenommen werden - ein weites Feld also für Sicherheitslücken.
Immer wieder habe Jacob Fälle konstatieren müssen, in denen überforderte Administratoren zur Gewährleistung eines reibungslosen R/3-Betriebs den Benutzern mehr Rechte zugewiesen hätten, als tatsächlich erforderlich gewesen wären. In solch einer unzulässigen Rechtevergabe sieht der Datenschützer die grundsätzliche Gefahr der Benutzung der SAP-Standardsoftware. Die Ausarbeitung eines guten Berechtigungskonzepts muss daher bereits in der Projektierungsphase vorbereitet werden, "denn wenn seine Erstellung erst mit der Installation des Systems beginnt, sind Fehler fast unvermeidlich". Auch hält Jacob deshalb den Einsatz von Softwarewerkzeugen für dringend erforderlich, die das jeweilige Berechtigungskonzept von R/3-Unternehmenslösungen prüfen und gegebenenfalls revidieren.
Eine Untersuchung der Technologieberatungsstelle beim DGB Landesbezirk Nordrhein-Westfalen, die von der Hans-Böckler-Stiftung herausgegeben wird ("Datenschutz bei SAP R/3"), kommt zu fast identischen Ergebnissen und nennt Risikobeispiele. Würden beispielsweise Daten aus dem R/3-Modul Human Resources (HR) vom produktiven System in ein Testsystem kopiert, schütze das Berechtigungskonzept des produktiven Systems die Daten im Testsystem nicht.
Auch wenn Daten per Download auf einen PC übertragen werden, wirken die SAP-eigenen Berechtigungsprüfungen nicht mehr. Setzt man, heißt es in der Untersuchung, auf einem Windows-95-PC nicht zusätzliche Produkte zur Berechtigungsprüfung ein, existiere überhaupt kein Mechanismus mehr, der die Daten absichert. Und wenn Daten vom SAP-Datenbank-Server auf einen Client übertragen würden, liege im dann fehlenden Schutz ein größeres Problem als in falschen Einstellungen im SAP-eigenen Berechtigungskonzept.
Aufgrund dieser Konstruktion können R/3-Daten leicht missbraucht werden - schon allein deshalb, weil man auch von außerhalb der R/3-Systemebene auf die gespeicherten Daten zugreifen kann. Die Risiken auf den verschiedenen Ebenen seien erheblich. So könnten beispielsweise physikalische Datenträger kopiert werden, indem sie auf einen anderen Rechner oder in ein anderes Rechenzentrum oder auf einen "Testrechner" übertragen werden.
Ein Benutzer könnte auch auf Betriebssystem-Ebene auf die Daten zugreifen, sie kopieren, verändern oder löschen. Ist der Datenbank-Server in ein Netz eingebunden - oder gar ins Internet -, dann könnten die Dateien einfach übertragen werden. Ein Anwender, der auf Betriebssystem-Ebene Zugriff hat, könne darüber hinaus ein Programm ausführen, das die von R/3 angelegten Daten verarbeite. Außerdem ließen sich im Betriebssystem Parameterdateien verändern, so dass die Berechtigungsprüfung in den R/3-Programmen ausgeschaltet werde.
Auf der Ebene des Datenbank-Management-Systems sei ein Anwender mittels der DBMS-Tools in der Lage, eigene Programme zu erstellen, die auf die Daten zugreifen. Da etwa die Oracle-Datenbank auf unterschiedlichen Betriebssystemen läuft, ließen sich die auf einem Unix- oder Windows-NT-Rechner vorhandenen Daten auf ein anderes System transponieren. Im DBMS ist es auch möglich, Programme einzubinden, die dann über die Datenbank auf die R/3-Daten zugreifen. Auf der Ebene des SAP-Systems ist ein Benutzer, der eine Abap-Programmierberechtigung besitzt, in der Lage, auf alle Daten des R/3-Systems zuzugreifen. Aus Sicht der darunter liegenden Ebenen wird er wie ein SAP-Benutzer mit sämtlichen Rechten behandelt. Der in SAP programmierte Mandantenbezug existiert für ihn nicht mehr.
Einen Marktplatz können unterschiedlichste Rechner ansprechen, die über das Intra- oder Internet miteinander verbunden sind und Daten austauschen. Nicht anders verhält es sich mit der Marktplatzkomponente in Mysap.com. Bei diesem SAP-eigenen Marktplatz gibt es die Institution eines Zertifizierungs-Servers. Auf diesem, und nur diesem, wird ein Single-Sign-On für die auf dem Marktplatz aktiven Benutzer betrieben.
Zugang zu diesen Datenbank-Servern haben über ein Intra- oder Internet sowohl einzelne PCs als auch PC-Netze. Und auf all diesen Rechnern können schützenswerte Daten gespeichert sein, die zwischen ihnen ausgetauscht werden. Problematisch ist dabei, dass kein Mechanismus existiert, der für das gesamte heterogene System den Schutz der Daten, also etwa den Zugriffsschutz, einheitlich regeln würde.
Das hat gravierende Konsequenzen: R/3 ist ein Client-Server-System. Der PC, auf dem das Client-Programm "SAP-GUI" geladen ist, arbeitet mit dem Programm des Datenbank-Servers zusammen. Im Grunde stellt der SAP-GUI die vom Server übertragenen Informationen nur grafisch dar. Sie werden auf den PC übertragen und temporär gespeichert. Diese Funktionsweise mag der Grund dafür sein, dass SAP erst ab Release 4 den Download einer Berechtigungsprüfung unterzieht, schreiben die Autoren der TBS-Untersuchung.
Der Benutzer, der mit dem R/3-System arbeiten will, nimmt über mehrere beteiligte Rechner hinweg Verbindung zu dem R/3-Programm auf dem Datenbank-Server auf, das seine Berechtigungen verwaltet. Aber keinem Betriebssystem der beteiligten Rechner muss er sich bekannt machen. In dem Netz werden die beteiligten Rechner als "vertrauenswürdig" behandelt.