Jahresbericht 1998
des Berliner Datenschutzbeauftragten

4.7 Internationaler und Europäischer Datenschutz

	4.8	Organisation und Technik
	4.8.1	Technische und organisatorische Datenschutzfragen bei Standardsoftware-Produkt SAP R/3

Eines der erfolgreichsten Softwareprodukte der Welt ist die integrierte, branchenunabhängige Standardsoftware R/3 des deutschen Softwarehauses SAP. Sie kann alle betriebswirtschaftlichen Anwendungsgebiete (z.B. Rechnungswesen, Logistik oder Personalwirtschaft) abdecken.

Allein in der öffentlichen Verwaltung des Landes ist das Produkt in vielfacher Weise im Einsatz: Als Version R/3 ISH wird es in vielen großen Krankenhäusern und Universitätskliniken für die Personal- und Patientenverwaltung und -abrechnung eingesetzt. Es bildet die Grundlage für die aktuelle Version III der Krankenhausrechnungswesens KRW, welches in den meisten Krankenhäusern bereits im Einsatz ist. Als Version R/3 HR (Human Resources) bildet es die Grundlage für das in Einführung begriffene Integrierte Personalverfahren (IPV) des Landes Berlin. Insbesondere in den öffentlich-rechtlich strukturierten Betrieben des Landes finden sich diverse weitere Anwendungen dieses Produktes. Auch in der Privatwirtschaft des Landes hat das Produkt SAP R/3 in seinen verschiedenen Anwendungsversionen weite Verbreitung gefunden.

Was für Berlin gilt, gilt bundesweit, vermutlich sogar weltweit. Das Produkt SAP R/3 ist die Basis für den Aufstieg der Firma SAP zu einem der erfolgreichsten multinational einflussreichen Unternehmen Deutschlands. Es gibt also für die Informatiker bei den Datenschutzbeauftragten des Bundes und der Länder Gründe genug, sich mit dem außerordentlich komplexen System zu befassen.

Die Software ist modular aufgebaut. Daten, die in einem Modul (z.B. Rechnungswesen) erfasst werden, stehen sofort den anderen Modulen (z.B. Logistik) zur Verfügung. Daten müssen somit nur einmal eingegeben werden und die Zahl der Schnittstellen lässt sich auf ein Minimum reduzieren.

Das Prinzip von R/3 beruht darauf, dass mit ihm ein System von Tabellen einer Datenbank verwaltet wird, die in komplexer Weise miteinander in Beziehung stehen. Diese Datenbank kann eine fast beliebige Standardsoftware sein, wie z.B. Adabas-D, Informix oder Oracle, die lediglich die Datenbankabfragesprache SQL (Standard QUERY Language) unterstützen muss. Als Serverbetriebsystem können verschiedene Plattformen (z.B. Unix-Derivate oder Windows NT) herangezogen werden, sofern sie von SAP dafür zertifiziert worden sind.

Diese Plattformunabhängigkeit und die Flexibilität, mit der R/3-Systeme an Betriebs- bzw. Behördenstrukturen durch sog. "Customizing" angepasst werden können, macht den Erfolg des Produktes aus. In der breiten Öffentlichkeit ist das Produkt wesentlich weniger populär als die Produkte des Konkurrenten Microsoft, weil es dem Heimanwender nur wenig Nutzen bringt und Ressourcen beansprucht, die die Kapazitäten der üblichen Rechner in privaten Haushalten und kleinen Wirtschaftsbetrieben weit überfordern.

Für eine datenschutzrechtliche Betrachtung von R/3 steht die Ausgestaltung des Berechtigungskonzepts im Vordergrund.

Das Berechtigungskonzept im SAP - System ist objektorientiert aufgebaut. Es definiert z.B. als Transaktionen bezeichnete ausführbare Anwendungsprogramme oder einzelne Tabellenfelder als Berechtigungsobjekte und ordnet ihnen Berechtigungen zu (z.B. zur Ausführung eines Programmes oder zum lesenden, ändernden oder löschenden Zugriff auf die Felder). Man kann die Berechtigungsobjekte als Schloss für das System bezeichnen und die Berechtigungen als die Schlüssel ansehen.

Berechtigungsobjekte werden in der R/3-eigenen Programmiersprache ABAP/4 geschrieben. Sie können daher im Zuge der Systemadministration weder ergänzt oder verändert werden.

Zum Öffnen des "Schlosses" Berechtigungsobjekt werden die "Schlüssel", nämlich die Berechtigungen, benötigt. Die Differenzierungsmöglichkeiten durch Berechtigungen hängen von der Art des jeweiligen Berechtigungsobjektes ab. So ist z.B. eine Berechtigung zur Ausführung bei einem nicht ausführbaren Objekt, wie z.B. einem Tabellenfeld, sinnlos. Eine solche Berechtigung macht vielmehr nur bei ausführbaren Objekten Sinn, also bei Programmen, bei R/3 Transaktionen genannt. Welche Berechtigungen für ein Berechtigungsobjekt vergeben werden, wird von einem sog. Berechtigungsadministator festgelegt. Diese Rolle entspricht also der des Schlüsselverwalters.

Den Nutzern werden in Abhängigkeit von ihren am System durchzuführenden Aufgaben Berechtigungen zugewiesen. Zusammengehörende Berechtigungen in Anwendungen können zu "Profilen" zusammengeführt werden. Zur Erhöhung der Übersichtlichkeit können die Profile noch zu "Sammelprofilen" zusammengefasst werden. Die Zugriffsberechtigungen eines Benutzers ergeben sich also aus den ihm zugeordneten Sammelprofilen, Profilen und einzelnen Berechtigungen. Diese persönlich zugeordneten Berechtigungen werden in einen Benutzerstammsatz eingetragen, der alle für das System notwendigen benutzerbezogenen Daten enthält.

Änderungen in Berechtigungen oder Profilen/Sammelprofilen werden erst nach einer neuen Anmeldung des Benutzers wirksam. Änderungen in Berechtigungsobjekten sind sofort wirksam.

Zur Umsetzung des Berechtigungskonzepts bietet das R/3-System die Möglichkeit der Funktionentrennung innerhalb der Systemadministration. Im Idealfall wird zwischen vier Funktionen unterschieden:

• Der/die Anwendungsentwickler/in legt Felder und Objekte an und entwickelt so die Berechtigungsobjekte.
• Der/die Berechtigungsadministrator/in pflegt Berechtigungen bzw. Profile und Sammelprofile.
• Der/die Aktivierungsadministrator/in aktiviert Berechtigungen bzw. Profile und Sammelprofile, kann aber ggf. Änderungen vornehmen, die protokolliert werden. Nur aktivierte Berechtigungen bzw. Profile und Sammelprofile können Nutzern zugeordnet werden.
• Der/die Benutzeradministrator/in ordnet Berechtigungen bzw. Profile und Sammelprofile Benutzern zu und pflegt die Benutzerstammsätze.

Das R/3-Berechtigungskonzept erscheint geeignet, die datenschutzrechtliche Idealvorstellung zu realisieren, dass jeder Benutzer exakt die Berechtigungen bekommt, die er für seine Aufgaben benötigt. Allerdings ist es gerade die außergewöhnliche Komplexität des Konzepts, die seine Schwachstellen ausmacht und die in der Fachöffentlichkeit zur Diskussion über die informationstechnische Sicherheit der verbreiteten Standardsoftware geführt hat.

Wir wollen an dieser Stelle exemplarisch einige Risiken ansprechen, die bei der Verwendung von SAP R/3 bekannt geworden sind.

Der Hamburgische Datenschutzbeauftragte hat bereits früher[176] auf das Hauptproblem des Berechtigungskonzepts hingewiesen. Der hohe Grad an Komplexität führt zu einer Intransparenz, die die Revision eines R/3-Systems nicht nur für außenstehende Prüfer, wie z.B. die Datenschutzbehörden, schwierig macht. Selbst mit dem System vertraute Personen wie etwa die o.g. Administratoren können Sicherheitslücken leicht übersehen oder gar unbewusst verursachen.

Die Ausarbeitung eines guten Berechtigungskonzepts muss bereits in der Projektierungsphase vorbereitet werden, denn wenn seine Erstellung erst mit der Installation des Systems beginnt, dann sind Fehler fast unvermeidlich. Das folgende Beispiel macht dies plausibel:

Die Standardversion von SAP R/3 (Release 4.x) beinhaltet bereits bei Auslieferung ca.700 Berechtigungsobjekte. Der Speicherraum für Berechtigungen im Benutzerstammsatz eines einzelnen Benutzers soll mindestens Raum für 1.300 Berechtigungseinträge bieten. Da ist es kein Wunder, wenn es Fälle gibt, in denen überforderte Administratoren zur Gewährleistung eines reibungslosen Produktivbetriebs einfachen Benutzern zeitweilig eine Generalzugriffsberechtigung auf das gesamte System (SAP_ALL) zugewiesen haben. Dies ist zwar ein Extremfall, aber es besteht grundsätzlich die Gefahr, dass Nutzern mehr als die notwendigen Rechte zugewiesen werden.

Wenn zur Lösung eines bestimmten Problems eine spezielle Berechtigung vergeben wird, ist es standardmäßig nicht möglich auszuschließen, dass unbeabsichtigt Zugriffsrechte in anderen Anwendungen eröffnet. Eine sprechende Prüfung findet durch das System nicht statt.

Es gibt Transaktionen, Tabellenfelder oder Berichte (Reports), die im Berechtigungskonzept nicht als Berechtigungsobjekte definiert sind, damit also kein Schloss besitzen. Ein Schutz muss dann auf Teilstrukturen (Unterprogramme, Teilfelder etc.) wirken, wenn diese ihrerseits Berechtigungsobjekte sind. Anschaulich vergleichbar ist dies mit dem Verschluss von Schränken in einem Raum, weil der Raum selbst nicht verschlossen werden kann.

Ein Beispiel für eine Transaktion, für die keine Berechtigungsprüfungen durchgeführt wird, und die daher von jedem Benutzer ausgeführt werden kann, ist die Transaktion DI02, mit der man sich Dateien und Daten im System ansehen kann, wenn Sicherheitseinstellungen fehlen. Über sie können alternative Wege zu sensiblen Daten eröffnet werden, obwohl die eigentliche Zugriffstransaktion ein Berechtigungsobjekt ist und daher Schutz bietet. Zwar mögen diese Umwege nur wenigen bekannt sein, aber es ist kein Schutzmechanismus, auf die Unkenntnis der Nutzer zu bauen. Anhand dieses Beispieles lässt sich erkennen, dass der Systemadministrator wegen des hohen Komplexitätsgrades von R/3 sehr sorgfältig arbeiten muss.

Für die oben geschilderten Sicherheitsprobleme werden Werkzeuge mit verschiedenen Lösungsansätzen von anderen Herstellern angeboten. Es ist jedoch bei Experten umstritten, ob Aufwand und Nutzen bei diesen Produkten in einem vernünftigen Verhältnis stehen.

Ein großes Sicherheitsproblem bilden die SAP-Standardprofile, die zusammen mit dem System ausgeliefert werden, wenn sie unkontrolliert in das Produktivsystem übernommen werden. Im Allgemeinen geben sie den Benutzern zu viele Rechte. Sie sollten daher nur als Vorlage für selbst zu definierende Profile dienen. Dann erst erschließen sich die Vorteile, weil man die Zugriffsprofile auf den tatsächlichen Bedarf anpassen kann. Außerdem bleibt man unabhängig von den Veränderungen der Standardprofile, die bei Releasewechseln erfolgen, denn die eigenen Profile bleiben dann unverändert.

Bei jedem Releasewechsel ist zu beachten, dass nur eine bearbeitete Version des Standardprofil SAP-NEW im System verbleibt. Jeder Benutzerstammsatz beinhaltet dieses Profil. In der unbearbeiteten Version enthält es alle Berechtigungen für neu hinzugekommene Berechtigungsobjekte. Bei einem Releasewechsel bestünde dann die Gefahr, dass Nutzer zu viele oder sogar Generalzugriffsberechtigungen erhalten.

Ein weiteres Risiko steckt im Kernel des R/3-Systems. Dort wurde der Pseudonutzer SAP* für die Erstinstallation fest implementiert, der uneingeschränkte Zugriffsberechtigungen auf das System hat und nicht gelöscht werden kann. Eine Sicherung gegen unbefugte Nutzung dieses privilegierten Zugangs ist nur möglich, wenn dazu ein Benutzerstammsatz angelegt wird, in dem das Kennwort verändert und alle Berechtigungen gelöscht wurden.

R/3 bietet die Möglichkeit, den Nutzer zu einem periodischen Kennwortwechsel zu zwingen. Dabei können vorher definierte Trivialkennwörter verboten werden. Initialkennwörter, die nur für das erstmalige Anmelden am System vergeben werden, unterliegen diesen Beschränkungen nicht. Dies wäre unkritisch, wenn es im R/3-System nicht möglich wäre, alle Kennungen zu ermitteln, die sich vorher noch nie am System angemeldet haben. Da das Initialkennwort üblicherweise den meisten Benutzern bekannt ist, weil immer das gleiche Verwendung findet, entsteht ein nicht unerhebliches Gefahrenpotential. Hier sollte nach den "Empfehlungen des Berliner Datenschutzbeauftragten für die Vergabe von Passwörtern"[177]; vorgegangen werden.

Ein oft unterschätztes Problem bei der Einrichtung von Benutzerstammsätzen ist die Vergabe von Druckrechten. Im R/3-Standard dürfen Nutzer mit einem beliebigen Ausgabegerät drucken. Wenn dieses Recht nicht eingeschränkt wird, könnten u.U. vertrauliche Daten auf frei zugänglichen Druckern ausgegeben werden.

Das beste Berechtigungskonzept ist wenig wert, wenn es umgangen werden kann. Um eine möglichst große Vielzahl von Plattformen bedienen zu können, setzt SAP auf Standarddatenbank-Softwareprodukten auf. Werden dafür keine besonderen Sicherheitsmaßnahmen getroffen, kann auf die Daten unter Umgehung des Systems R/3 zugegriffen werden. Da R/3 seine Daten unverschlüsselt ablegt, kann auf eine solche Schutzfunktion nicht gebaut werden. Für den Datenbankserver sollten nur zwei lokale Kennungen, eine für die Systemverwaltung und eine für das R/3-System, existieren. Individuelle Kennungen sind zu vermeiden.

Mit der wachsenden Verbreitung der SAP-Software hat der Hersteller dem Datenschutz eine höhere Priorität zugewiesen. So wurde in diesem Jahr erstmalig ein Datenschutzleitfaden herausgegeben, der z.T. ins Detail gehende Hinweise für eine datenschutzgerechte Ausgestaltung gibt[178].

Um den erwähnten Risiken der Unüberschaubarkeit des Berechtigungskonzepts entgegenzutreten, wurde seit dem Release 3.1x ein Profilgenerator zur Erleichterung der Administration eingeführt, der fortlaufend weiterentwickelt wird. Bei den Anwendern stößt dieser aufgrund der noch hohen Fehleranfälligkeit auf ein geteiltes Echo. Es ist zu hoffen, dass SAP in späteren Versionen mit diesem Werkzeug eine ausreichende Transparenz erreicht.

Der sichere Umgang mit R/3-Systemen setzt eine hochwertige Qualifikation und Spezialisierung voraus, die nur durch praktische Erfahrung, Fortbildung und einen stetigen Fluss von Informationen zu Sicherheitshinweisen, Fehlermeldungen etc. aufrechterhalten werden kann. Es sind also in der Berliner öffentlichen Verwaltung ebenso wie in den privaten Anwenderunternehmen alle Qualifikationsanstrengungen zu erbringen, die die sichere Beherrschung solcher Systeme überhaupt erst ermöglichen.