Vergabe der SAP R/3 - Technische Universität Wien
Vergabe der SAP R/3 - Technische Universität Wien
Vergabe der SAP R/3 - Technische Universität Wien
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Systematische <strong>Vergabe</strong> von<br />
Benutzerzugriffsberechtigungen<br />
eingereicht von:<br />
Bernd Marx<br />
DIPLOMARBEIT<br />
zur Erlangung des akademischen Grades<br />
Magister rerum socialium oeconomicarumque<br />
Magister <strong>der</strong> Sozial- und Wirtschaftswissenschaften<br />
(Mag. rer. soc. oec)<br />
Fakultät für Wirtschaftswissenschaften und Informatik,<br />
<strong>Universität</strong> <strong>Wien</strong><br />
Fakultät für <strong>Technische</strong> Naturwissenschaften und Informatik,<br />
<strong>Technische</strong> <strong>Universität</strong> <strong>Wien</strong><br />
Studienrichtung: Wirtschaftsinformatik<br />
Begutachter:<br />
a. Prof. Dr. Jürgen Dorn<br />
<strong>Wien</strong>, im Mai 2002
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Abstrakt<br />
Der ständig zunehmende Einsatz von elektronischer Datenverarbeitung und die Anbindung<br />
von EDV-Systemen an Netzwerkarchitekturen im Berufs- und Privatleben bergen<br />
viele Gefahren. Zwei wichtige Instrumente, um ein möglichst hohes Maß an Datenschutz<br />
und Datensicherheit erreichen zu können, sind die Zugangskontrolle und <strong>der</strong> Zugriffsschutz.<br />
Die vorliegende Arbeit untersucht verschiedene Verfahren <strong>der</strong> Zugangs- und<br />
Zugriffskontrolle und beleuchtet in diesem Zusammenhang beispielhaft auch Betriebssysteme<br />
und Standardsoftware. Es werden die Eigenschaften und Vor- und Nachteile <strong>der</strong><br />
jeweiligen Techniken behandelt und anschließend wird ein Modellansatz für die zentralisierte<br />
und systematische <strong>Vergabe</strong> aller Zugriffsberechtigungen innerhalb eines Betriebes<br />
erstellt. Danach wird die <strong>Vergabe</strong> <strong>der</strong> Benutzerzugriffsberechtigungen in <strong>der</strong> Standardsoftware<br />
<strong>SAP</strong> R/3 in <strong>der</strong> Hella Fahrzeugteile Austria GmbH & Co KG beschrieben.<br />
2
Inhaltsverzeichnis<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
1 EINLEITUNG ................................................................................................................................ 5<br />
1.1 MOTIVATION ZUR WAHL DER THEMENSTELLUNG................................................................ 5<br />
1.2 ERKENNTNISZIELE UND ERKENNTNISOBJEKT ....................................................................... 6<br />
1.3 GLIEDERUNG UND VORGEHEN ZUR ZIELERREICHUNG ......................................................... 7<br />
2 DAS RISIKO „INFORMATIONSTECHNOLOGIE“............................................................ 9<br />
2.1 DATENSCHUTZ UND DATENSICHERHEIT ................................................................................ 9<br />
2.1.1 Begriffsbestimmungen..................................................................................................... 9<br />
2.1.2 Gesetzliche Aspekte zu Datenschutz und Datensicherheit.......................................... 10<br />
2.2 GEFAHREN BEIM EINSATZ VON PCS UND NETZWERKTECHNOLOGIEN IN UNTERNEHMEN ..<br />
................................................................................................................................................ 12<br />
2.2.1 Gefahrenquellen ............................................................................................................ 13<br />
2.2.2 Gefährdungsarten.......................................................................................................... 15<br />
2.2.3 Computeranomalien...................................................................................................... 16<br />
2.3 MAßNAHMEN ZUR GEFAHRENABWEHR UND GEFAHRENVERMEIDUNG............................. 17<br />
2.3.1 Hard- und softwaretechnische Maßnahmen................................................................ 17<br />
2.3.2 Bauliche und organisatorische Maßnahmen............................................................... 17<br />
3 ZUGANGSKONTROLLE UND ZUGRIFFSSCHUTZ ........................................................ 19<br />
3.1 BEGRIFFSABGRENZUNGEN .................................................................................................... 19<br />
3.1.1 Zugangskontrolle........................................................................................................... 19<br />
3.1.2 Zugriffskontrolle............................................................................................................ 19<br />
3.2 PASSWORT-MANAGEMENT ................................................................................................... 20<br />
3.2.1 Die Funktionsweise von Passwortsystemen ................................................................ 20<br />
3.2.2 Eigenschaften von Passwörtern ................................................................................... 21<br />
3.2.3 Vorteile von Passwortsystemen .................................................................................... 21<br />
3.2.4 Nachteile von Passwortsystemen ................................................................................. 21<br />
3.3 BIOMETRISCHE METHODEN .................................................................................................. 22<br />
3.3.1 Begriffserklärung .......................................................................................................... 22<br />
3.3.2 Funktionsweise biometrischer Methoden .................................................................... 22<br />
3.3.3 Verfahren biometrischer Identifikation bzw. Verifikation.......................................... 24<br />
3.3.4 Biometrie und Datenschutz........................................................................................... 26<br />
3.3.5 Vorteile von biometrischen Authentisierungsverfahren ............................................. 27<br />
3.3.6 Nachteile von biometrischen Authentisierungsverfahren........................................... 28<br />
3.4 SMARTCARDS ........................................................................................................................ 28<br />
3.4.1 Charakteristik und Funktionsweise von SmartCards.................................................. 28<br />
3.4.2 Vorteile von SmartCards .............................................................................................. 29<br />
3.4.3 Nachteile von SmartCards............................................................................................ 29<br />
3.5 BEISPIELHAFTE BETRACHTUNG VON BETRIEBSSYSTEMEN UND STANDARDSOFTWARE.. 29<br />
3.5.1 UNIX .............................................................................................................................. 29<br />
3.5.2 Linux............................................................................................................................... 31<br />
3.5.3 Windows 2000 ............................................................................................................... 31<br />
3.5.4 Lotus Notes .................................................................................................................... 32<br />
4 MODELLANSATZ: SYSTEMATISCHE VERGABE VON<br />
BENUTZERZUGRIFFSBERECHTIGUNGEN............................................................................. 34<br />
4.1 ZIEL UND VORGEHEN ............................................................................................................ 34<br />
4.2 DIE FÜNF SCHRITTE DES MODELLS ...................................................................................... 35<br />
4.2.1 Schritt 1: Modellierung <strong>der</strong> Geschäftsprozesse .......................................................... 35<br />
3
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
4.2.2 Schritt 2: Ableitung <strong>der</strong> Informationsprozesse............................................................ 37<br />
4.2.3 Schritt 3: Bilden von Berechtigungsgruppen............................................................... 39<br />
4.2.4 Schritt 4: Erzeugen von Benutzergruppen................................................................... 41<br />
4.2.5 Schritt 5: Verknüpfen von Berechtigungsgruppen und Benutzergruppen ................. 43<br />
4.3 DAS GESAMTMODELL ........................................................................................................... 44<br />
5 PROJEKT: VERGABE DER <strong>SAP</strong> R/3-BENUTZERBERECHTIGUNGEN IN DER<br />
HELLA FAHRZEUGTEILE AUSTRIA GMBH & CO KG........................................................ 46<br />
5.1 DAS UNTERNEHMEN.............................................................................................................. 46<br />
5.1.1 Geschichte und Tätigkeitsfeld....................................................................................... 46<br />
5.1.2 Eingesetzte Hardware................................................................................................... 46<br />
5.1.3 Eingesetzte Software ..................................................................................................... 47<br />
5.2 <strong>SAP</strong> R/3.................................................................................................................................. 47<br />
5.2.1 Allgemeines.................................................................................................................... 47<br />
5.2.2 Datenschutz und Sicherheit in <strong>SAP</strong> R/3....................................................................... 49<br />
5.2.3 Einführung in das Berechtigungskonzept von <strong>SAP</strong> R/3 .............................................. 49<br />
5.3 DAS PROJEKT ......................................................................................................................... 50<br />
5.3.1 Ausgangssituation ......................................................................................................... 50<br />
5.3.2 Aufgabenstellung........................................................................................................... 51<br />
5.3.3 Planung.......................................................................................................................... 51<br />
5.3.4 Implementierung............................................................................................................ 52<br />
5.3.5 Testphase ....................................................................................................................... 59<br />
5.3.6 Transport <strong>der</strong> neuen Berechtigungszuordnungen in das <strong>SAP</strong>-Produktivsystem....... 63<br />
5.3.7 Schwierigkeiten und Son<strong>der</strong>fälle im Projekt ............................................................... 64<br />
6 RESÜMEE .................................................................................................................................... 66<br />
6.1 DATENSCHUTZ, ZUGANGSKONTROLLE UND ZUGRIFFSSCHUTZ......................................... 66<br />
6.2 MODELLANSATZ VERSUS <strong>SAP</strong> R/3-PROJEKT ...................................................................... 67<br />
ANHANG............................................................................................................................................... 69<br />
LITERATURVERZEICHNIS ................................................................................................................... 69<br />
4
1 Einleitung<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
1.1 Motivation zur Wahl <strong>der</strong> Themenstellung<br />
Die Nutzung mo<strong>der</strong>ner Informationstechnologie, vor allem in Betrieben unterschiedlicher<br />
Art, in denen ein Arbeiten ohne das Hilfsmittel Computer heute kaum noch vorstellbar ist,<br />
bringt eine Reihe von Vorteilen mit sich, wie z. B. ein Eindämmen <strong>der</strong> anfallenden Papierflut<br />
in den Büros, das rasche Auffinden von Daten und den schnellen Zugriff auf benötigte<br />
Informationen, eine damit einhergehende Effizienzsteigerung, und ähnliches. Neben den<br />
Vorteilen treten aber auch einige Nachteile zutage, die nicht übersehen werden sollten.<br />
Eine <strong>der</strong> größten Schwierigkeiten, die aus dem Einsatz von EDV-Systemen und <strong>der</strong>en<br />
Anbindung an verschiedene Netzwerke, wie etwa das Internet, resultieren, ist <strong>der</strong> Schutz<br />
<strong>der</strong> enormen Menge an Daten, die durch die tägliche Arbeit anfallen. Es gilt, sowohl personenbezogene<br />
Daten, wie z. B. Mitarbeiterstammdaten, Kundendaten, usw., als auch<br />
betriebliche Daten, wie Umsatzzahlen, Buchhaltungsbelege, Forschungsdaten, usw. vor<br />
ungerechtfertigten Zugriffen, vor kriminellen Angriffen, usw. zu schützen. Die Bedeutung,<br />
die dem Datenschutz zukommt, lässt sich daran erkennen, welche Auswirkungen unzureichende<br />
Datenschutz- und Datensicherheitsmaßnahmen für ein Unternehmen zur Folge<br />
haben können. Sollte teuer entwickeltes KnowHow in die Hände <strong>der</strong> Konkurrenz gelangen,<br />
dann wäre möglicherweise ein Wettbewerbsvorteil dahin, und dadurch könnte im<br />
Extremfall sogar <strong>der</strong> Bestand des gesamten Unternehmens gefährdet sein. Das impliziert<br />
natürlich auch die damit einhergehende Bedrohung <strong>der</strong> Arbeitsplätze dieses Betriebes.<br />
Auch die von sogenannten Hackern verursachten Schäden, die von einfachen Scherzen<br />
über die Bereicherung an fremdem Kapital bis hin zur Zerstörung ganzer Datenbestände<br />
reichen, haben nicht selten ruinöse Folgen. Aber nicht nur Außenstehende von Unternehmen<br />
stellen eine potentielle Gefahr für die Daten dar. Es sind auch die Mitarbeiter und<br />
die ehemaligen Mitarbeiter zu beachten, wenn es um das Thema Datenschutz geht.<br />
Die angeführten Sachverhalte führen zu <strong>der</strong> Fragestellung: Kann den drohenden Gefahren<br />
mit entsprechenden Maßnahmen, wie etwa mit Methoden <strong>der</strong> Zugangs- und<br />
Zugriffskontrolle, begegnet werden und bieten die eingesetzten Systeme auch die jeweils<br />
erfor<strong>der</strong>liche Sicherheit?<br />
Es sind verschiedene Techniken und Verfahren im praktischen Einsatz, um den Zugang<br />
zu Systemen und den Zugriff auf Datenbestände ausschließlich autorisierten Personen zu<br />
ermöglichen. Eine den jeweiligen Erfor<strong>der</strong>nissen entsprechende Zugangs- und Zugriffskontrolle<br />
zu implementieren, stellt eine wichtige Aufgabe für jedes Unternehmen dar. Um<br />
ein möglichst hohes Maß an Datenschutz und Datensicherheit zu erreichen, ist <strong>der</strong> Einsatz<br />
von geeigneter Hardware und Software erfor<strong>der</strong>lich. Speziell im Bereich <strong>der</strong> Software<br />
ist zu beachten, dass unterschiedliche Betriebssysteme und Standardsoftwareprodukte<br />
das Problem des Datenschutzes auf unterschiedliche Weise lösen. Der Faktor Sicherheit<br />
sagt vor<strong>der</strong>gründig meist nichts über die eigentliche Funktionalität des betreffenden Produktes<br />
aus, was eventuell dazu verleiten mag, den Aspekt <strong>der</strong> Zugangs- und Zugriffskontrolle<br />
im Zuge <strong>der</strong> Anschaffung von Software und Hardware zu vernachlässigen. Die<br />
Folgen eines <strong>der</strong>artigen Fehlers zeigen sich generell nicht sofort, doch sollte sich herausstellen,<br />
dass die eingesetzte Soft- und Hardware in bezug auf Datenschutz eklatante<br />
Mängel aufweist, dann ist es meist schon zu spät, da die aufgetretenen Schäden entwe<strong>der</strong><br />
gar nicht, nicht zur Gänze o<strong>der</strong> zumindest nicht ohne finanzielle Einbussen behoben<br />
werden können.<br />
5
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Um die Gefahr des Eintretens solcher Schäden zu minimieren, ist es unerlässlich, bei <strong>der</strong><br />
Auswahl <strong>der</strong> Produkte beson<strong>der</strong>s darauf zu achten, wie das Problem des Datenschutzes<br />
und <strong>der</strong> Datensicherheit gehandhabt wird, und ob sie das angestrebte Maß an Sicherheit<br />
auch bieten können.<br />
1.2 Erkenntnisziele und Erkenntnisobjekt<br />
In <strong>der</strong> vorliegenden Arbeit werden Zielsetzungen verfolgt, die einen Einblick in die Komplexität<br />
und Wichtigkeit von Datenschutz und Datensicherheit ermöglichen sollen, mit<br />
Schwerpunkt auf die Kontrolle <strong>der</strong> Zugangs- und Zugriffsberechtigungen. Es werden bestehende<br />
Methoden <strong>der</strong> Zugriffssteuerung beschrieben und <strong>der</strong>en Vor- und Nachteile<br />
aufgezeigt. Es wird auch beispielhaft darauf eingegangen, wie unterschiedliche Betriebsysteme<br />
und Standardsoftwareprodukte das Problem <strong>der</strong> Zugangs- und Zugriffskontrolle<br />
lösen bzw. welche Verfahren zur Zugangs- und Zugriffskontrolle eingesetzt werden. Im<br />
Zuge dieser Untersuchungen soll die Arbeit sowohl eine wissenschaftliche als auch eine<br />
praktische Funktion erfüllen:<br />
• Wissenschaftliche Funktion:<br />
Es soll eine inhaltliche Beschreibung für ein Modell erstellt werden, das eine<br />
effiziente und systematische Zugriffskontrolle für das gesamte<br />
Informationssystem innerhalb eines Unternehmens ermöglichen soll. Der<br />
Modellansatz soll des weiteren auch die <strong>Vergabe</strong> sämtlicher Zugriffsberechtigungen<br />
durch eine einzige zentrale Stelle erlauben. Schließlich soll<br />
noch ein Vergleich des entstandenen Modellansatzes mit einem real<br />
durchgeführten Projekt stattfinden.<br />
• Praktische Funktion:<br />
Anhand <strong>der</strong> Standardsoftware <strong>SAP</strong> R/3 wird <strong>der</strong> Weg von <strong>der</strong> Planung über<br />
die Entwicklung bis hin zum Einsatz eines Konzeptes für die <strong>Vergabe</strong> von<br />
Benutzerzugriffsberechtigungen beschrieben. Das entsprechende Projekt<br />
wird in dem Produktions- und Handelsunternehmen Hella Fahrzeugteile<br />
Austria GmbH & Co KG, A-7503 Großpetersdorf, durchgeführt, und soll unter<br />
an<strong>der</strong>em auch die Funktionsweise und die administrativen<br />
Eingriffsmöglichkeiten darstellen, die <strong>SAP</strong> R/3 als weltweit marktführen<strong>der</strong><br />
Anbieter von betriebswirtschaftlicher Anwendungssoftware betreffend des<br />
Einrichtens <strong>der</strong> Benutzerzugriffsberechtigungen bietet. Es sollen aber auch<br />
Beson<strong>der</strong>heiten und Schwierigkeiten jeglicher Art aufgezeigt werden, die im<br />
Zuge eines <strong>der</strong>artigen Projektes in einem Betrieb auftreten können.<br />
Erkenntnisobjekt <strong>der</strong> vorliegenden Arbeit ist das soziotechnische System Unternehmen,<br />
mit Fokus auf Mittel- und Grossbetriebe. Obwohl schon sehr viele Privathaushalte mit PCs<br />
ausgestattet sind und die Zahl <strong>der</strong> privat genutzten Computer ständig im Wachstum begriffen<br />
ist, ist das Problem <strong>der</strong> Zugangs- und Zugriffskontrolle in erster Linie für<br />
Unternehmen relevant, da hier <strong>der</strong> wirtschaftliche Schaden im Fall von Sicherheitsdefiziten<br />
ungleich große Ausmaße annehmen kann. Handelt es sich bei den Nutzern von EDV-<br />
Systemen um Betriebe, dann steigt die Wichtigkeit einer geeigneten Zugangs- und<br />
Zugriffskontrolle mit dem Vorhandensein von technischem Know-How und mit zunehmen<strong>der</strong><br />
Betriebsgröße, denn je größer die Menge und die Sensitivität <strong>der</strong> Daten sind, desto<br />
umfangreicher kann sich auch ein potentieller Schadensfall auswirken. Das heißt aber<br />
nicht, dass Kleinunternehmen von dem Gefahrenpotential Informationstechnologie nicht<br />
betroffen sind.<br />
6
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Für diese Unternehmen sind die im System befindlichen und archivierten Daten ebenso<br />
wichtig für die Sicherung ihrer Existenz wie für Mittel- und Großunternehmen, allerdings<br />
mit dem Unterschied, dass beim Auftreten eines Schadensfalles meist nur wenige Arbeitsplätze<br />
gefährdet sind und sich die Höhe des wirtschaftlichen Schadens einigermaßen<br />
in Grenzen hält.<br />
1.3 Glie<strong>der</strong>ung und Vorgehen zur Zielerreichung<br />
Der Aufbau <strong>der</strong> vorliegenden Arbeit stellt sich im Überblick wie folgt dar:<br />
Einleitung<br />
• Motivation zur Wahl <strong>der</strong> Themenstellung<br />
• Definition <strong>der</strong> Erkenntnisziele<br />
• Glie<strong>der</strong>ung und Vorgehen zur Zielerreichung<br />
Das Risiko „Informationstechnologie“<br />
• Datenschutz und Datensicherheit<br />
• Gefahren beim Einsatz von PCs und Netzwerktechnologien in Unternehmen<br />
• Maßnahmen zur Gefahrenabwehr und Gefahrenvermeidung<br />
Zugangskontrolle und Zugriffsschutz<br />
• Begriffsabgrenzungen<br />
• Passwort-Management<br />
• Biometrische Methoden<br />
• SmartCards<br />
• Beispielhafte Betrachtung von Betriebssystemen und Standardsoftware<br />
MODELLANSATZ: Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
• Ziel und Vorgehen<br />
• Die 5 Schritte des Modells<br />
• Das Gesamtmodell<br />
PROJEKT: <strong>Vergabe</strong> <strong>der</strong> <strong>SAP</strong> R/3-Benutzerzugriffsberechtigungen in <strong>der</strong> Hella<br />
Fahrzeugteile Austria GmbH & Co KG<br />
• Das Unternehmen<br />
• <strong>SAP</strong> R/3<br />
• Das Projekt<br />
Resümee<br />
• Datenschutz, Zugangskontrolle und Zugriffsschutz<br />
• Modellansatz versus <strong>SAP</strong> R/3-Projekt<br />
Abb. 1: Aufbau <strong>der</strong> vorliegenden Arbeit<br />
7
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Anfangs sollen Begriffsbestimmungen die Bedeutung, Unterschiede und Zusammenhänge<br />
<strong>der</strong> Begriffe Datenschutz und Datensicherheit erkennen lassen. Im Anschluss daran<br />
soll ein kurzer Blick auf die gesetzlichen Bestimmungen zum Thema Datenschutz verdeutlichen,<br />
dass ein Unternehmen von Seiten des Gesetzgebers, also auch ohne das<br />
Vorhandensein eigenen Interesses, dazu verpflichtet ist, ein bestimmtes Maß an Datenschutz<br />
zu gewährleisten. Danach wird versucht, einen Überblick über die Vielfalt <strong>der</strong><br />
drohenden Gefahren zu schaffen, denen ein Unternehmen durch den Einsatz von Computern<br />
und Netzwerktechnologien ausgesetzt ist. Anschließend werden beispielhaft<br />
Sicherheitsmassnahmen angeführt, die eingesetzt werden, um potentiellen Gefahren erfolgreich<br />
begegnen zu können und dadurch das Risiko von wirtschaftlichen Schäden zu<br />
minimieren.<br />
Von den möglichen Sicherheitsmassnahmen, die einem Unternehmen einsetzen kann,<br />
wird dann <strong>der</strong> Bereich <strong>der</strong> Zugangs- und Zugriffskontrolle nach einer kurzen, begrifflichen<br />
Abgrenzung einer genaueren Betrachtung unterzogen. Dabei werden sowohl aktuell eingesetzte<br />
Methoden als auch neuere technische Entwicklungen beschrieben. Es wird die<br />
Funktionalität verschiedener Verfahren <strong>der</strong> Zugangs- und Zugriffskontrolle dargestellt, und<br />
es wird auch versucht, die Vor- und Nachteile <strong>der</strong> unterschiedlichen Methoden aufzuzeigen.<br />
Im Anschluss daran wird versucht, einen Modellansatz für die Einführung einer<br />
möglichst effizienten und effektiven Zugriffskontrolle zu erstellen, <strong>der</strong> durch eine Steigerung<br />
des Zugriffsschutzes den Datenschutz und die Datensicherheit in einem<br />
Unternehmen verbessern soll.<br />
Im nächsten Schritt wird anknüpfend an das Thema Zugriffskontrolle die Planung und<br />
Einführung eines Konzepts <strong>der</strong> <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen für das Unternehmen<br />
Hella Fahrzeugteile Austria GmbH & Co KG in <strong>der</strong> betrieblichen<br />
Standardsoftware <strong>SAP</strong> R/3 beschrieben. Einleitend wird dabei das betreffende Unternehmen<br />
vorgestellt, es wird die Ausgangssituation im Unternehmen, vor allem die <strong>SAP</strong> R/3-<br />
Benutzerberechtigungen betreffend, erläutert, und anschließend wird die Aufgabenstellung<br />
seitens des Betriebes inklusive etwaiger Vorgaben dargestellt. Danach wird<br />
beschrieben, in welcher Art und Weise Benutzerberechtigungen in <strong>SAP</strong> R/3 vergeben<br />
werden können, und es werden eventuelle Einschränkungen durch die Software und auch<br />
Än<strong>der</strong>ungs- und Eingriffsmöglichkeiten durch Administratoren aufgezeigt. Es folgen die<br />
Beschreibungen <strong>der</strong> verschieden Projektphasen, das sind im groben die Planung, Implementierung,<br />
Tests und die Inbetriebnahme des Berechtigungskonzepts. Im Zuge dessen<br />
werden auch Schwierigkeiten abgehandelt, die im Laufe des Projekts auftreten.<br />
Der erste Teil <strong>der</strong> Arbeit soll also eine Einführung in das Gebiet „Computer und Datensicherheit“,<br />
mit beson<strong>der</strong>em Augenmerk auf das Teilgebiet <strong>der</strong> Zugriffskontrolle, darstellen,<br />
gefolgt von <strong>der</strong> Erstellung eines Modellansatzes zum ganzheitlichen Zugriffsschutz. Der<br />
praktische Teil soll hingegen ein Projekt beschreiben, dessen Umsetzung einen Teil des<br />
anzustrebenden und auch gesetzlich vorgeschriebenen Datenschutzes innerhalb eines<br />
Unternehmens gewährleisten soll. Durch diese Aufteilung <strong>der</strong> Arbeit in einen theoretischwissenschaftlichen<br />
und einen praktischen Teil ergeben sich zwei unterschiedliche Tätigkeitsfel<strong>der</strong>:<br />
während die Ergebnisse des ersten Teiles vorwiegend aus <strong>der</strong> Recherche in<br />
Literatur, Internet, und dgl. resultieren, handelt es sich im praktischen Teil um eine Projektbeschreibung,<br />
wofür lediglich die <strong>SAP</strong> R/3-Dokumentation als Unterlage zur<br />
Verfügung steht.<br />
8
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
2 Das Risiko „Informationstechnologie“<br />
2.1 Datenschutz und Datensicherheit<br />
2.1.1 Begriffsbestimmungen<br />
2.1.1.1 Datenschutz<br />
Unter Datenschutz versteht man in erster Linie, den einzelnen vor möglichen Gefährdungen<br />
o<strong>der</strong> Beeinträchtigungen seines Rechts auf informationelle Selbstbestimmung, die<br />
sich aus <strong>der</strong> Informationsverarbeitung ergeben können, zu schützen [KüSc97a, 11].<br />
Der Datenschutz soll dabei einerseits die Erhebung personenbezogener Daten auf das<br />
erfor<strong>der</strong>liche Mindestmass begrenzen, und an<strong>der</strong>erseits gilt es, den Missbrauch bei <strong>der</strong><br />
Verarbeitung solcher Daten zu verhin<strong>der</strong>n.<br />
Unter Datenschutz im engeren Sinn ist die Aufgabe zu verstehen, den einzelnen davor zu<br />
schützen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinem<br />
Persönlichkeitsrecht beeinträchtigt wird. Im weiteren Sinn wird darunter aber auch <strong>der</strong><br />
Schutz aller schutzwürdigen Daten vor jeglichem Missbrauch verstanden.<br />
Die vorliegende Arbeit behandelt nicht nur den Schutz von personenbezogenen Daten,<br />
son<strong>der</strong>n den Schutz sämtlicher in einem Unternehmen anfallen<strong>der</strong> Daten, die vor jeglichem<br />
Missbrauch und sonstigen Gefahren geschützt werden sollen.<br />
2.1.1.2 Datensicherheit<br />
Unter Datensicherheit versteht man den Zustand eines Systems <strong>der</strong> Informationstechnik,<br />
in dem die Risiken, die beim Einsatz dieses Systems aufgrund von Bedrohungen vorhanden<br />
sind, durch angemessene Maßnahmen auf ein tragbares Maß eingeschränkt sind.<br />
Häufig spricht man in diesem Zusammenhang nicht nur allgemein von Bedrohungen,<br />
son<strong>der</strong>n definiert die Datensicherheit etwas spezifischer als “...Schutz vor absichtlichen<br />
Manipulationsversuchen, Bedienungsfehlern, katastrophenbedingten Ausfällen und technischem<br />
Versagen“ [Kers91, 9].<br />
Der Schutz bezieht sich auf Programme, Computer und Netzwerke, mit denen personenbezogene<br />
Daten verarbeitet, o<strong>der</strong> auf denen solche Daten gespeichert o<strong>der</strong> transportiert<br />
werden.<br />
Datensicherheit wird häufig auch als ein älterer Begriff für die Informationssicherheit verwendet,<br />
die sich jedoch schwerpunktmäßig nur auf die Sicherung <strong>der</strong> Daten konzentriert.<br />
9
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
2.1.2 Gesetzliche Aspekte zu Datenschutz und Datensicherheit<br />
2.1.2.1 Rechtsstruktur in Österreich<br />
Das österreichische Datenschutzgesetz (ÖDSG), das bereits im Jahr 1978 in seiner ersten<br />
Fassung eingeführt wurde, genügte in einigen Punkten nicht <strong>der</strong> EU-Richtlinie zum<br />
Datenschutz vom 24. Oktober 1995, was dazu führte, dass mit 1. Januar 2000 ein neues<br />
Datenschutzgesetz, und zwar das Bundesgesetz über den Schutz personenbezogener<br />
Daten (Datenschutzgesetz 2000 – DSG) in Österreich rechtskräftig wurde. Diese neueste<br />
Fassung des Datenschutzgesetzes wurde zur Gänze neu formuliert und lehnt sich eng an<br />
die oben erwähnte EU-Richtlinie an.<br />
Der Aufbau des Datenschutzgesetzes 2000 lässt sich im Überblick folgen<strong>der</strong>maßen darstellen:<br />
Artikel 1 Verfassungsbestimmung<br />
§1 Grundrecht auf Datenschutz<br />
§2 Zuständigkeit<br />
§3 Räumlicher Anwendungsbereich<br />
Artikel 2<br />
1. Abschnitt §4 – 5 Allgemeines<br />
2. Abschnitt §6 – 13 Verwendung von Daten<br />
3. Abschnitt §14 – 15 Datensicherheit<br />
4. Abschnitt §16 – 25 Publizität <strong>der</strong> Datenverarbeitungen<br />
5. Abschnitt §26 – 29 Die Rechte des Betroffenen<br />
6. Abschnitt §30 – 34 Rechtsschutz<br />
7. Abschnitt §35 – 44 Kontrollorgane<br />
8. Abschnitt §45 – 48 Beson<strong>der</strong>e Verwendungszwecke von Daten<br />
9. Abschnitt §49 – 50 Beson<strong>der</strong>e Verwendungsarten von Daten<br />
10. Abschnitt §51 – 52 Strafbestimmungen<br />
11. Abschnitt §53 – 64 Übergangs- und Schlussbestimmungen<br />
Abb. 2: Aufbau des Österreichisches Datenschutzgesetzes 2000<br />
§1 Abs.1 des DSG 2000 lautet wie folgt:<br />
„Je<strong>der</strong>mann hat, insbeson<strong>der</strong>e auch im Hinblick auf die Achtung seines Privat- und Familienlebens,<br />
Anspruch auf Geheimhaltung <strong>der</strong> ihn betreffenden personenbezogenen Daten,<br />
soweit ein schutzwürdiges Interesse daran besteht. Das Bestehen eines solchen Interesses<br />
ist ausgeschlossen, wenn Daten infolge ihrer allgemeinen Verfügbarkeit o<strong>der</strong> wegen<br />
ihrer mangelnden Rückführbarkeit auf den Betroffenen einem Geheimhaltungsanspruch<br />
nicht zugänglich sind.“<br />
„Durch die Benützung des Wortes „Je<strong>der</strong>mann“ ist das Grundrecht als Menschenrecht<br />
verankert [Dohr96a, 85]“, was besagt, dass das DSG für je<strong>der</strong>mann gleichermaßen gültig<br />
ist, und nicht nur für Österreichische Staatsbürger. Das Grundrecht auf Datenschutz stellt<br />
ein sog. Grundrecht mit Drittwirkung dar, das heißt, es gilt auch im öffentlichen Bereich,<br />
und es begründet damit nicht nur eine Garantie des Staates gegenüber den Bürgern,<br />
son<strong>der</strong>n es regelt auch das Rechtsverhältnis zwischen den Bürgern, also zu Dritten.<br />
10
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Die gesetzlich vorgesehenen Maßnahmen für die Datensicherheit sind in den §§ 14 und<br />
15 geregelt. Pflüger, <strong>der</strong> in seinem Vorlesungsskriptum zu Datenschutz und Datensicherheit<br />
das Österreichische Datenschutzgesetz 2000 erläutert und auch dessen gesamten<br />
Wortlaut wie<strong>der</strong>gibt, erwähnt im Zusammenhang mit <strong>der</strong> Datensicherheit unter an<strong>der</strong>em,<br />
dass Zutrittsberechtigungen für Räumlichkeiten, Zugriffsberechtigungen auf Daten und<br />
Programme o<strong>der</strong> auch Belehrungen <strong>der</strong> Mitarbeiter über Gesetze und Datensicherheitsvorschriften<br />
zu erlassen sind [Pflü00, 12]. Laut Gesetzgeber müssen Maßnahmen zur<br />
Gewährleistung <strong>der</strong> Datensicherheit getroffen werden, und es ist sicherzustellen, dass die<br />
Verwendung <strong>der</strong> Daten ordnungsgemäß erfolgt und dass die Daten von Unbefugten nicht<br />
eingesehen werden können. Es sind auch Sicherheitsvorschriften zu erlassen und diese<br />
sind so zur Verfügung zu halten, dass sich die Arbeitnehmer je<strong>der</strong>zeit über die für sie geltenden<br />
Regelungen informieren können. Der Arbeitgeber muss für die entsprechende<br />
Dokumentation und Information sorgen.<br />
2.1.2.2 Rechtsstruktur in <strong>der</strong> EU<br />
Am 24. Oktober 1995 trat die EU-Datenschutzrichtlinie des Europäischen Parlaments und<br />
des Rates zum Schutz natürlicher Personen bei <strong>der</strong> Verarbeitung personenbezogener<br />
Daten und zum freien Datenverkehr in Kraft. Diese Datenschutzrichtlinie ist für die einzelnen<br />
Mitgliedsstaaten <strong>der</strong> Europäischen Union (EU) lediglich hinsichtlich des zu<br />
erreichenden Zieles verbindlich. Die Wahl <strong>der</strong> Form und Mittel, die zum Erreichen dieses<br />
Zieles führen, bleibt dabei den jeweiligen innerstaatlichen Stellen überlassen, jedoch sind<br />
die Gesetze in den Mitgliedsstaaten innerhalb einer Frist von 3 Jahren entsprechend anzupassen.<br />
Das Ziel dieser „Allgemeinen Datenschutzrichtlinie“ soll es sein, in allen Mitgliedsstaaten<br />
<strong>der</strong> EU ein gleich hohes Schutzniveau einzuführen, um die Hemmnisse für den Austausch<br />
von Daten abzubauen, <strong>der</strong> für das Funktionieren des Binnenmarktes unerlässlich ist. Die<br />
Verwirklichung des europäischen Binnenmarktes setzt den freien Verkehr von Waren,<br />
Dienstleistungen, Kapital und Personen voraus, was auch den transnationalen Datenverkehr<br />
unverzichtbar macht [Dohr96b, 146], und dazu müssen die in <strong>der</strong> Richtlinie<br />
genannten Grundsätze von allen Mitgliedsstaaten garantiert werden.<br />
Die Hauptgrundsätze <strong>der</strong> EU-Datenschutzrichtlinie beziehen sich auf<br />
• die Qualität <strong>der</strong> Daten,<br />
• die Zulässigkeit <strong>der</strong> Verarbeitung von Daten,<br />
• beson<strong>der</strong>e Kategorien <strong>der</strong> Verarbeitung,<br />
• die Information <strong>der</strong> betroffenen Person,<br />
• das Auskunftsrecht <strong>der</strong> betroffenen Person,<br />
• das Wi<strong>der</strong>spruchsrecht <strong>der</strong> betroffenen Person,<br />
• Vertraulichkeit und Sicherheit <strong>der</strong> Verarbeitung und<br />
• die Meldung.<br />
Die Richtlinie ist laut Artikel 3, Abs. 1, „auf die ganz o<strong>der</strong> teilweise automatisierte Verarbeitung<br />
personenbezogener Daten und die nichtautomatisierte Verarbeitung<br />
personenbezogener Daten, die in Dateien gespeichert sind o<strong>der</strong> gespeichert werden sollen“,<br />
anzuwenden. Alle Bestimmungen <strong>der</strong> Richtlinie gelten grundsätzlich sowohl für den<br />
öffentlichen als auch für den privaten Bereich.<br />
11
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Da nach erfolgter Anpassung <strong>der</strong> jeweiligen Gesetze an diese Richtlinie je<strong>der</strong> Mitgliedsstaat<br />
<strong>der</strong> EU bei <strong>der</strong> Verarbeitung personenbezogener Daten den gleichen, hohen Schutz<br />
genießt, können die Mitgliedsstaaten die Freizügigkeit <strong>der</strong> betreffenden Daten in <strong>der</strong> Gemeinschaft<br />
nicht mehr mit <strong>der</strong> Begründung des Schutzes einer o<strong>der</strong> mehrerer Personen<br />
einschränken. Dadurch sollte das Thema Datenschutz als Hemmnis für die Umsetzung<br />
des europäischen Binnenmarktes entfallen.<br />
Die Europäische Kommission stellte überdies am 12. Juli 2000 einen neuen Entwurf für<br />
eine EU-Richtlinie über die Verarbeitung personenbezogener Daten und den Schutz <strong>der</strong><br />
Privatsphäre in <strong>der</strong> elektronischen Kommunikation vor.<br />
„Der Vorschlag soll den Schutz <strong>der</strong> Privatsphäre verbessern, enthält aber zugleich eine<br />
Art Generalausnahme für die „gesetzlich ermächtigten Behörden“ – Strafverfolgungsbehörden<br />
und Geheimdienste. Die neue Richtlinie soll die vom Europäischen Parlament und<br />
dem Rat am 15. Dezember 1997 verabschiedete Richtlinie 97/66/EG über die Verarbeitung<br />
personenbezogener Daten und den Schutz <strong>der</strong> Privatsphäre im Bereich <strong>der</strong><br />
Telekommunikation ersetzen [VaBu00].“<br />
Die Europäische Kommission verfolgt dabei das Ziel, die neue Gesetzgebung bis Anfang<br />
2002 unterzubringen. Die Institutionen <strong>der</strong> Europäischen Union beschäftigen sich <strong>der</strong>zeit<br />
unter an<strong>der</strong>em noch mit einer Richtlinie über die Genehmigung elektronischer Kommunikationsnetze<br />
und –dienste und mit einer Rahmenrichtlinie dafür. Das lässt schon<br />
erkennen, dass sich im Bereich <strong>der</strong> gesetzlichen Vorschriften bezüglich Datenschutz und<br />
Datensicherheit ständig Verän<strong>der</strong>ungen ergeben, die es hinsichtlich des Einsatzes von<br />
EDV-Systemen in Unternehmen zu beobachten und zu befolgen gilt.<br />
2.2 Gefahren beim Einsatz von PCs und Netzwerktechnologien<br />
in Unternehmen<br />
Der fortschreitende Bedarf an Informationstechnologie inklusive <strong>der</strong> verschiedensten<br />
Netzwerktechnologien bringt neben häufig angestrebten Rationalisierungseffekten und<br />
an<strong>der</strong>en Vorteilen zunehmend sicherheitstechnische Probleme und Risiken mit sich. Der<br />
Schutz <strong>der</strong> Daten, Programme, Hardware, usw. wird zu einer immer wichtigeren Aufgabe<br />
für Betriebe, von denen auch heutzutage noch viele die drohenden Gefahren und damit<br />
verbundenen Konsequenzen, die als Folge unzureichen<strong>der</strong> Datenschutz- und Datensicherheitsmassnahmen<br />
auftreten können, nicht o<strong>der</strong> zumindest nicht im ausreichendem<br />
Masse beachten.<br />
Die Bedrohungen bezüglich Daten, Software und Hardware, denen ein Unternehmen<br />
ausgesetzt ist und die es so weit wie möglich abzuwenden gilt, sind sehr zahlreich. Die<br />
folgende Behandlung dieser Gefahren stellt keinen Anspruch auf Vollständigkeit. Es wird<br />
lediglich versucht, durch beispielhafte Erklärungen einen Überblick über die Vielfältigkeit<br />
und Komplexität <strong>der</strong> potentiellen Gefahren zu schaffen. Dabei werden nicht nur Gefahren<br />
behandelt, die in direktem Zusammenhang mit dem Datenschutz stehen. Es wird versucht,<br />
überblicksartig die weitreichende Bandbreite aller Bedrohungen darzustellen,<br />
denen ein Unternehmen im Zuge des EDV-Einsatzes ausgesetzt ist.<br />
Die potentiellen Gefahren werden dabei anhand ihrer Einteilung nach den Kriterien entsprechend<br />
<strong>der</strong> nachfolgenden Tabelle betrachtet [PiFl96]:<br />
12
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Gefahrenquellen Gefährdungsarten Computeranomalien<br />
- Katastrophen und<br />
natürliche Schäden<br />
- Mangelhafte Planung<br />
und Organisation<br />
- Menschliches Versagen<br />
- Kriminelle Handlungen<br />
- Arbeitsorganisatorische<br />
Gefährdungen<br />
- <strong>Technische</strong> Gefährdungen<br />
- Wirtschaftliche und<br />
sonstige Gefährdungen<br />
Abb. 3: Gefahreneinteilung anhand unterschiedlicher Kriterien<br />
2.2.1 Gefahrenquellen<br />
2.2.1.1 Katastrophen und natürliche Schäden<br />
Dazu gehören unter an<strong>der</strong>em die folgenden Gefahren:<br />
- Wanze<br />
- Trojanisches Pferd<br />
- Wurm<br />
- Computervirus<br />
- Logische Bombe<br />
- Hintertür<br />
- Schläfer<br />
- Krebs<br />
• Feuer (z. B. Kabelbrände, brennende Papierkörbe, usw.)<br />
• Explosionen<br />
• Löschschäden (Diese können beispielsweise durch die falsche Handhabung von<br />
Löschgeräten o<strong>der</strong> durch ungeeignete Feuerlöscher verursacht werden.)<br />
• Naturkatastrophen (z. B. Überschwemmungen, Erdbeben)<br />
• Umweltgefahren (z. B. hohe Luftfeuchtigkeit, große Hitze o<strong>der</strong> Kälte, starke Sonneneinstrahlung,<br />
u. ä.)<br />
• Stromausfall<br />
• Magnetische Fel<strong>der</strong> (Diese können etwa durch Transformatoren, Motoren, Lastenmagnete<br />
o<strong>der</strong> Induktionsöfen hervorgerufen werden.)<br />
Viele <strong>der</strong> oben genannten Beispiele werden häufig zu dem Begriff „Höhere Gewalt“ zusammengefasst,<br />
worunter man jene Katastrophen versteht, <strong>der</strong>en Eintreten <strong>der</strong> Mensch<br />
nicht direkte beeinflussen kann. Dazu gehören Erdbeben, Blitzschlag, Hochwasser, usw.<br />
2.2.1.2 Mangelhafte Planung und Organisation<br />
Verlust <strong>der</strong> Beweglichkeit<br />
Basiert <strong>der</strong> EDV-Einsatz in einem Betrieb auf mangelhafter Planung, so kann das zu einer<br />
Behin<strong>der</strong>ung des betrieblichen Ablaufs führen.<br />
Abhängigkeit von Spezialisten<br />
Wird für einen EDV-Anwen<strong>der</strong> ein individuelles Programm entwickelt, und zwar unabhängig<br />
davon, ob dies auf speziellen Wunsch des Anwen<strong>der</strong>s o<strong>der</strong> auf Anraten des<br />
Softwareherstellers geschieht, dann entsteht daraus oft eine zu starke Abhängigkeit von<br />
einer bestimmten Person o<strong>der</strong> von einem einzelnen Softwareunternehmen. Treten in einem<br />
solchen Fall Probleme auf, dann ist man <strong>der</strong> Person bzw. dem Unternehmen zumeist<br />
hilflos ausgeliefert. Die schlimmsten Folgen aus einem <strong>der</strong>artigen Sachverhalt entstehen<br />
dann, wenn die betreffende Softwarefirma ihre Tätigkeit einstellt.<br />
Fehlerhafte Programme und Systeme<br />
Viele EDV-Anwen<strong>der</strong> erwerben sog. Billigsysteme, <strong>der</strong>en Systemzukunft nur schwer einschätzbar<br />
ist, um Kosten zu sparen, setzen sich damit aber häufig <strong>der</strong> Gefahr von<br />
mangelhafter Unterstützung bei <strong>der</strong> Wartung und bei anfallenden Servicetätigkeiten aus.<br />
13
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Unzureichende Kontrolle<br />
Wenn bei <strong>der</strong> Planung und Durchführung eines EDV-Projektes ein entsprechendes Kontrollinstrument<br />
fehlt, dann besteht häufig die Gefahr einer Termin- bzw.<br />
Kostenüberschreitung.<br />
Fehlende Investitionen<br />
Werden im Budgetplan für EDV-Projekte die Kosten für Wartung, Service, Aus- und Weiterbildung,<br />
Störungen, usw. nicht o<strong>der</strong> nicht ausreichend berücksichtigt, so kann es dazu<br />
kommen, dass zu einem späteren Zeitpunkt enorme Folgekosten auftreten, die in Extremfällen<br />
das betreffende Unternehmen in ernsthafte, finanzielle Schwierigkeiten bringen<br />
können.<br />
2.2.1.3 Menschliches Versagen<br />
Hierzu gehören alle Gefahren, die unmittelbar von menschlichen EDV-Anwen<strong>der</strong>Innen<br />
ausgehen. Einige Beispiele dafür sind:<br />
Unsachgemäße Handhabung von EDV-Systemen<br />
Hierunter fällt z. B. die fachliche Überfor<strong>der</strong>ung, die in so manchen Fällen während des<br />
EDV-Einsatzes zu Tage tritt, und wovon häufig, jedoch nicht ausschließlich, ältere Mitarbeiter<br />
betroffen sind. Das Auftreten von EDV-bedingter Überfor<strong>der</strong>ung lässt sich sehr oft<br />
daran erkennen, dass passiver Wi<strong>der</strong>stand geleistet wird o<strong>der</strong> dass das alte System parallel,<br />
jedoch versteckt, weiterbetrieben wird.<br />
Unqualifizierte Bedienung <strong>der</strong> EDV-Anlage durch Fremdpersonal<br />
Werden personelle Engpässe durch den temporären Einsatz von Fremdpersonal überbrückt,<br />
dann besteht die Gefahr von Fehlbedienungen, da das Fremdpersonal mit dem<br />
betriebsspezifischen EDV-System zumeist nicht vertraut ist.<br />
Operator-Fehler<br />
Der EDV-Operator bzw. EDV-Administrator ist für die Systembetreuung zuständig. Er<br />
muss dafür sorgen, dass das EDV-System ordnungsgemäß funktioniert. Etwaige Fehler<br />
des EDV-Operators können zum Verlust von Daten o<strong>der</strong> Programmen führen, und im<br />
schlimmsten Fall können auch Hardware- und Softwarezusammenbrüche eintreten.<br />
2.2.1.4 Kriminelle Handlungen<br />
Beispiele für kriminelle Handlungen sind:<br />
• Sabotage<br />
• Vandalismus<br />
• Diebstahl<br />
- Nutzung <strong>der</strong> EDV-Anlage durch unberechtigte Außenstehende<br />
- Diebstahl von Programmen beispielsweise durch Kopieren<br />
- Erstellung von Programmen für Kollegen o<strong>der</strong> gegen Bezahlung für Dritte<br />
auf Kosten des Unternehmens<br />
• Unterschlagung<br />
• Betrug<br />
14
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
• Spionage: Von <strong>der</strong> Gefahr <strong>der</strong> Spionage sind in erster Linie High-Tech-Firmen bedroht,<br />
die wichtige Labordaten o<strong>der</strong> Konstruktionen im EDV-System gespeichert<br />
haben. Bei einem Datendiebstahl durch Spionage kann ein vorhandener Technologievorsprung<br />
mit einem Schlag zunichte gemacht werden.<br />
• Manipulation (z. B. das Än<strong>der</strong>n von Datenbeständen o<strong>der</strong> Programmen)<br />
Ehemalige Mitarbeiter werden häufig als Sicherheitslücke vernachlässigt, können aber<br />
sehr oft ein hohes Sicherheitsrisiko für den ehemaligen Arbeitgeber darstellen [Szel01].<br />
2.2.2 Gefährdungsarten<br />
2.2.2.1 Arbeitsorganisatorische Gefährdungen<br />
Zu den arbeitsorganisatorischen Gefährdungen gehören <strong>der</strong> unberechtigte Zugang zu<br />
Räumlichkeiten und Systemen, die unzulässige Nutzung von Hard- und Software, Gefährdungen<br />
durch eine unzureichende Kontrolle und die unzulässige Datenweitergabe.<br />
Die Gefahr eines unberechtigten Zugangs ist beispielsweise gegeben, wenn kein Zugangsnachweis<br />
erbracht werden muss o<strong>der</strong> wenn Datenträger häufig ungeschützt an frei<br />
zugänglichen Orten aufbewahrt werden.<br />
Bei einer mangelhaften Identifikation <strong>der</strong> Person gegenüber dem System o<strong>der</strong> wenn die<br />
unzulässige private Nutzung von Teilen des EDV-Systems leicht möglich ist, dann spricht<br />
man von einer Gefährdung durch unzulässige Nutzung.<br />
Von <strong>der</strong> Gefahr <strong>der</strong> unzureichen<strong>der</strong> Kontrolle spricht man etwa bei mangeln<strong>der</strong> Programm-<br />
und Softwaresystemwartung o<strong>der</strong> bei einer gegebenen Abhängigkeit vom<br />
Programmhersteller.<br />
Eine unzulässige Datenweitergabe wird z. B. durch eine unzureichende Funktionstrennung<br />
o<strong>der</strong> durch die einfache Möglichkeit <strong>der</strong> Datenweitergabe mittels Disketten,<br />
Ausdrucken, usw. ermöglicht.<br />
2.2.2.2 <strong>Technische</strong> Gefährdungen<br />
Unzureichende Protokollierung, unzulässigen Zugriff und Mehrfachspeicherung bilden<br />
gemeinsam die Gruppe <strong>der</strong> technischen Gefährdungen.<br />
Die Gefahr <strong>der</strong> unzureichenden Protokollierung tritt z. B. dann auf, wenn die automatische<br />
Protokollierung aller Systemaktivitäten fehlt o<strong>der</strong> wenn die Eingaben <strong>der</strong> Anwen<strong>der</strong> nicht<br />
mitprotokolliert werden.<br />
Eine Gefährdung durch unzulässigen Zugriff entsteht durch mangelnde Zugriffsbeschränkungen,<br />
durch eine fehlende Zugriffsprotokollierung o<strong>der</strong> auch durch die ständige<br />
Verfügbarkeit von Daten und Programmen auf <strong>der</strong> Festplatte.<br />
Die Gefahr <strong>der</strong> Mehrfachspeicherung ist beispielsweise dann gegeben, wenn aufgrund<br />
<strong>der</strong> Eigenverantwortlichkeit <strong>der</strong> Anwen<strong>der</strong> <strong>der</strong> Datenbestand unkontrolliert wächst.<br />
2.2.2.3 Wirtschaftliche und sonstige Gefährdungen<br />
In die Gruppe <strong>der</strong> wirtschaftlichen und sonstigen Gefährdungen fallen schließlich die unkontrollierte<br />
Beschaffung, die Nichterfüllung datenschutzrechtlicher Anfor<strong>der</strong>ungen, <strong>der</strong><br />
Verlust durch höhere Gewalt, Verluste durch verbrecherische Handlungen sowie Verluste<br />
durch Unachtsamkeit, mangelndes Problembewusstsein und mangelnde Maßnahmenakzeptanz.<br />
15
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Die Gefahr <strong>der</strong> unkontrollierten Beschaffung entsteht durch das Fehlen von geeigneten<br />
Kontrollmechanismen beim Ankauf von Hard- und Software o<strong>der</strong> generell durch die Beschaffung<br />
von wirtschaftlich ineffizienten o<strong>der</strong> inkompatiblen Systemen.<br />
Die Gefahr, durch verbrecherische Handlungen Verluste hinnehmen zu müssen, basiert<br />
auf vorsätzlicher Gewalt, Manipulation o<strong>der</strong> Diebstahl.<br />
Verluste durch Unachtsamkeit werden häufig durch fehlerhafte Bedienung o<strong>der</strong> Nachlässigkeit<br />
hervorgerufen.<br />
Mangelndes Datenschutzbewusstsein, eine unzureichende Ausbildung des Personals, die<br />
fehlende Akzeptanz und das Nichteinhalten <strong>der</strong> Datenschutzmaßnahmen durch das Personal,<br />
usw. führen schließlich zur Bedrohung durch mangelndes Problembewusstsein und<br />
mangelnde Maßnahmenakzeptanz.<br />
2.2.3 Computeranomalien<br />
Computeranomalien bezeichnen eine Reihe von Programmen o<strong>der</strong> Programmteilen, die<br />
mit <strong>der</strong> Absicht entworfen und in Umlauf gebracht werden, verschiedenartige Softwaremanipulationen<br />
durchzuführen.<br />
Wanze<br />
Eine Wanze ist ein Programmfehler, <strong>der</strong> z. B. durch eine falsch programmierte Programmroutine<br />
entsteht und unter bestimmten Bedingungen Daten verfälscht o<strong>der</strong> zerstört.<br />
Trojanisches Pferd<br />
Ein trojanisches Pferd führt auf Benutzerebene alle gewünschten Funktionen in erwarteter<br />
Weise aus, besitzt darüber hinaus aber eine verborgene Funktionalität, die während des<br />
normalen Programmablaufs in Erscheinung tritt, und die für den Manipulanten die Möglichkeit<br />
zu unerlaubtem Handeln bietet.<br />
Wurm<br />
Ein Wurm ist ein eigenständig lauffähiges Programm, das in <strong>der</strong> Lage ist, sich über ein<br />
Netzwerk in an<strong>der</strong>e Rechner zu vervielfältigen. Ein Wurm kann Viren o<strong>der</strong> trojanische<br />
Pferde enthalten, die dann auf fremden Rechnern aktiv werden.<br />
Computervirus<br />
Beim Computervirus handelt es sich um die wohl bekannteste Form einer Computeranomalie,<br />
was darauf zurückzuführen ist, dass Computerviren auch immer wie<strong>der</strong> in den<br />
Medien auftauchen, weil durch sie häufig enorme wirtschaftliche Schäden entstehen. Ein<br />
Computervirus ist im Gegensatz zum Wurm kein eigenständiges Programm. Er besteht<br />
aus einer Befehlsfolge und benötigt ein sog. Wirtsprogramm, um seine verborgene Funktion<br />
zu entfalten. Wird nun diese Befehlsfolge ausgeführt, dann wird <strong>der</strong> Virus in eine o<strong>der</strong><br />
mehrere, bis dahin nicht infizierte, Datei bzw. Dateien kopiert, o<strong>der</strong> es werden Mutationen<br />
in einem Speicherbereich hervorgerufen. Als zusätzliche Funktion kann <strong>der</strong> Computervirus<br />
z. B. einen Schadenteil enthalten, <strong>der</strong> beim Eintreten eines bestimmten Ereignisses<br />
(nach Erreichen eines bestimmten Datums, Start einer speziellen Anwendung, usw.) aktiviert<br />
wird. Die Funktionalität des Schadenteils besteht häufig darin, dass die Festplatte<br />
formatiert wird und dadurch alle Daten auf dem betreffenden Computer zerstört werden,<br />
was auch die bereits erwähnten, hohen Schadensausmasse erklärt.<br />
16
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Logische Bombe<br />
Eine logische Bombe ist ein lauffähiges Programm, das die gewünschte Funktion solange<br />
korrekt ausführt, bis eine vorgegebene Bedingung des Manipulanten erfüllt ist, die eine<br />
Fehlfunktion mit bestimmten Folgen (Löschen des Speicherinhalts, Zerstörung von Programmen,<br />
usw.) auslöst.<br />
Hintertür<br />
Eine Hintertür ermöglicht den nichtautorisierten Zugang zu einem EDV-System. Zugangs-<br />
und Berechtigungsprüfungen werden damit umgangen und unzulässige Privilegien können<br />
dadurch angeeignet werden. Die Hintertür kann z. B. durch die Eingabe einer<br />
speziellen Zeichenfolge aktiviert werden.<br />
Schläfer<br />
Schläfer sind Teile eines Programms, die erst zu einem späteren Zeitpunkt wirksam werden,<br />
und dann einen Datenverlust o<strong>der</strong> gezielte Fehlfunktionen auslösen.<br />
Krebs<br />
Ein Krebs modifiziert vorhandene Programme o<strong>der</strong> Datenbestände in stetig wachsendem<br />
Ausmaß.<br />
2.3 Maßnahmen zur Gefahrenabwehr und Gefahrenvermeidung<br />
Wie das vorangegangene Kapitel deutlich erkennen lässt, ist die Liste <strong>der</strong> potentiellen<br />
Gefahren für die NutzerInnen von EDV-Systemen sehr lang, und dieser Umstand stellt<br />
entsprechend große Anfor<strong>der</strong>ungen an die verantwortlichen Personen jener Betriebe, in<br />
denen Informationstechnologie zum Einsatz kommt. Hier sollte es in jedem Fall ein Ziel<br />
sein, ein EDV-System mit jenen Voraussetzungen auszustatten, mit denen ein möglichst<br />
hohes Maß an Sicherheit erreicht werden kann.<br />
Nachfolgend werden einige Sicherheitsmaßnahmen angeführt, die in <strong>der</strong> Praxis bereits<br />
zum Einsatz kommen, um den Datenschutz und die Datensicherheit zu erhöhen. Dabei<br />
wird zwischen hard- und softwaretechnischen Maßnahmen einerseits und baulichen und<br />
organisatorischen Maßnahmen an<strong>der</strong>erseits unterschieden.<br />
2.3.1 Hard- und softwaretechnische Maßnahmen<br />
• Service- und Wartungsverträge mit möglichst kurzen Reaktionszeiten seitens <strong>der</strong><br />
Hersteller<br />
• Erstellen von Programmen in Teamarbeit und nicht durch Einzelpersonen<br />
• Firewall (zum Schutz vor Angriffen über Netzverbindungen)<br />
• Proxy-Server (zum Schutz vor böswilligen Programmen bzw. Programmteilen)<br />
• VPN (Virtual Private Network): Dabei handelt es sich um ein beson<strong>der</strong>s<br />
geschütztes Netzwerk, das sich allerdings öffentlicher<br />
Kommunikationseinrichtungen bedient.<br />
• Virensuchprogramme: Das sind spezielle Programme, die EDV-Systeme nach<br />
bekannten Viren durchsuchen, und diese gegebenenfalls isolieren o<strong>der</strong> löschen.<br />
2.3.2 Bauliche und organisatorische Maßnahmen<br />
17
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
• Feuermel<strong>der</strong><br />
• Alarmanlagen<br />
• EDV-gerechtes Löschsystem<br />
• Absicherung <strong>der</strong> EDV-Anlage mit Thermoschutz und FI-Schutz<br />
• Automatisches Pumpenkonzept<br />
• Kein unbeaufsichtigtes Arbeiten von Fremdpersonen einschließlich nichtautorisierter<br />
Personen in EDV-Räumen (Zugangskontrolle)<br />
• Beauftragung einer verantwortlichen Person, die EDV-sicherheitstechnische Belange<br />
wahrnimmt. Dieser Sicherheitsbeauftragte überwacht jedes EDV-Projekt und<br />
den laufenden EDV-Einsatz in Hinsicht auf Datenschutz und Datensicherheit.<br />
• Ausstattung <strong>der</strong> Hard- und Software mit geeignetem Zugriffsschutz<br />
18
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
3 Zugangskontrolle und Zugriffsschutz<br />
3.1 Begriffsabgrenzungen<br />
3.1.1 Zugangskontrolle<br />
Das primäre Ziel einer Zugangskontrolle ist die Sicherstellung, dass nur berechtigte Personen<br />
bestimmte Bereiche eines Unternehmens betreten dürfen. In Hinblick auf<br />
Datenschutz und Datensicherheit sind das jene Räumlichkeiten, in denen mit geheimen<br />
o<strong>der</strong> vertraulichen Daten gearbeitet wird.<br />
Die Zugangskontrolle identifiziert die BenutzerInnen anhand <strong>der</strong> jeweils eingesetzten Methode,<br />
also aufgrund des eingegebenen Passworts, auf <strong>der</strong> Basis bestimmter<br />
Körpermerkmale o<strong>der</strong> durch die Daten auf einer Chipkarte bzw. Magnetkarte. Nach erfolgter<br />
und erfolgreicher Identifizierung erlaubt die Zugangskontrolle gemäß vorher definierten<br />
Rechten den Zutritt zu den entsprechenden Räumlichkeiten.<br />
Der Vorgang <strong>der</strong> Zugangskontrolle setzt sich aus den Schritten Identifikation, Authentisierung<br />
und Protokollierung zusammen [Petz96].<br />
Die Identifikation besteht in <strong>der</strong> Verknüpfung einer Person mit <strong>der</strong>en Identität o<strong>der</strong> Pseudoidentität.<br />
Die Authentisierung als wesentlicher Schritt <strong>der</strong> Zugangskontrolle prüft, ob die<br />
vorgegebene Identität eindeutig zu einer Person gehört. Diese Prüfung kann durch verschiedene<br />
Authentisierungsmechanismen verifiziert werden. Sie kann entwe<strong>der</strong> durch<br />
Wissen erfolgen, d. h. durch die Abfrage einer nur <strong>der</strong> jeweiligen Person bekannten Information<br />
(Passwort). Eine weitere Möglichkeit ist die Authentisierung durch Besitz, die<br />
durch den Einsatz von Chipkarten o<strong>der</strong> Magnetkarten realisiert wird. Die dritte Möglichkeit<br />
besteht schließlich darin, den erfor<strong>der</strong>lichen Authentifizierungsnachweis durch auszeichnende<br />
physiologische o<strong>der</strong> verhaltenstypische Charakteristika <strong>der</strong> Person zu erbringen.<br />
Die Protokollierung als letzter Schritt <strong>der</strong> Zugangskontrolle übernimmt die Aufgabe, alle<br />
Zutritte mit <strong>der</strong> Kennung <strong>der</strong> Person, <strong>der</strong> Zutrittszeit und <strong>der</strong> Verweildauer aufzuzeichnen.<br />
Die Zugangskontrolle bezieht sich sowohl auf unbefugte Angehörige des jeweiligen Unternehmens<br />
als auch auf betriebsfremde Personen und Besucher. Es gibt hier speziell<br />
zwei Möglichkeiten, um einem Besucher von vornherein die Chance zu verwehren, vertrauliche<br />
Daten bewusst o<strong>der</strong> unbewusst auszuspähen:<br />
1. Die Einrichtung von Besucherzonen o<strong>der</strong> Besucherzimmern<br />
2. Der Besucher darf nicht alleine gelassen werden!<br />
3.1.2 Zugriffskontrolle<br />
Die Zugriffskontrolle auf ein System beruht auf einer Menge von Zugriffsregeln, die festlegen,<br />
wer auf welches Objekt zugreifen kann. Sie erlaubt dadurch den Zugriff auf Daten<br />
und Programme, die sich auf einem Rechner o<strong>der</strong> in einem EDV-System befinden, und ist<br />
damit ein wichtiges Instrument für einen Systemadministrator o<strong>der</strong> Netzwerkverwalter, um<br />
zu regeln, welche Personen auf welche Dateien zugreifen können und welche Personen<br />
welche Programme ausführen können.<br />
19
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Die Zugriffskontrolle schließt dabei chronologisch an die Zugangskontrolle an. Durch die<br />
technisch bereits sehr fortgeschrittenen Netzwerksysteme, wie das Internet, das weltweit<br />
unzähligen Betrieben und Privatpersonen zur Verfügung steht, wird <strong>der</strong> Stellenwert <strong>der</strong><br />
Zugriffskontrolle immer wichtiger, da die persönliche Anwesenheit häufig nicht mehr erfor<strong>der</strong>lich<br />
ist, um an wichtige Daten gelangen zu können. Diesem Umstand folgend und<br />
aufgrund <strong>der</strong> Tatsache, dass bei <strong>der</strong> Zugangskontrolle und beim Zugriffsschutz häufig auf<br />
dieselben o<strong>der</strong> ähnliche Schutzmechanismen zurückgegriffen wird, beziehen sich die<br />
nachfolgenden Abschnitte <strong>der</strong> vorliegenden Arbeit nicht nur auf den Zugriffsschutz, son<strong>der</strong>n<br />
auch auf die Zugangskontrolle.<br />
3.2 Passwort-Management<br />
3.2.1 Die Funktionsweise von Passwortsystemen<br />
Die in <strong>der</strong> Praxis mit Abstand am häufigsten eingesetzte Sicherheitsmaßnahme im EDV-<br />
Bereich ist <strong>der</strong> Passwortschutz, <strong>der</strong> zum Schutz von Rechnern und Programmen, aber<br />
auch bei Geldausgabeautomaten o<strong>der</strong> Türöffnern eingesetzt wird.<br />
Das Passwort „... ist ein individuelles Kennwort, mit dem sich ein Anwen<strong>der</strong> dem System<br />
gegenüber (Rechner, Programm) als zugriffsberechtigt ausweist [Adam95, 85].“<br />
Es ist eine Zeichenfolge und wird in <strong>der</strong> Regel vom Anwen<strong>der</strong> selbst vergeben, kann in<br />
Ausnahmefällen jedoch auch vom jeweiligen Vorgesetzten o<strong>der</strong> vom zuständigen Systemadministrator<br />
vergeben werden.<br />
Bevor ein mit Passwortschutz versehenes Programm o<strong>der</strong> Computersystem gestartet<br />
werden kann, muss <strong>der</strong> Anwen<strong>der</strong> für gewöhnlich seine Benutzerkennung bzw. seinen<br />
Namen und ein Passwort eingeben. Die Eingabe einer Benutzerkennung ist nicht bei allen<br />
Passwortsystemen erfor<strong>der</strong>lich. Die meisten <strong>der</strong> verwendeten Passwortsysteme erlauben<br />
nur die Eingabe einer geringen Anzahl von fehlerhaften Passwörtern und sperren nach<br />
dem letztmöglichen Versuch die Anwendung, wodurch keine weitere Eingabe erlaubt wird.<br />
Erst <strong>der</strong> Systemadministrator, o<strong>der</strong> auch <strong>der</strong> EDV-Leiter, kann nach Prüfung <strong>der</strong> gegebenen<br />
Umstände das gesperrte Programm für den betreffenden Benutzer wie<strong>der</strong> freigeben.<br />
Hat <strong>der</strong> Benutzer sein bestehendes Passwort vergessen, dann wird im Zuge <strong>der</strong> Freischaltung<br />
ein neues Passwort vergeben. Bei vielen Systemen wird dem<br />
Systemadministrator schon die Möglichkeit eingeräumt, die Anzahl <strong>der</strong> möglichen Fehleingaben<br />
selbst festzulegen.<br />
Ein Passwortsystem führt oft ein sogenanntes Logbuch, in dem je<strong>der</strong> Zugriff mit Datum,<br />
Zeitangabe und <strong>der</strong> Benutzerkennung <strong>der</strong> zugreifenden Person gespeichert wird. Werden<br />
die Daten des jeweils letzten Zugangs außerdem bei je<strong>der</strong> neuerlichen Anmeldung am<br />
Bildschirm angezeigt, dann ist <strong>der</strong> betreffende Anwen<strong>der</strong> (o<strong>der</strong> <strong>der</strong> Systemadministrator)<br />
in <strong>der</strong> Lage, sehr leicht zu erkennen, ob sich jemand unberechtigt auf dem Rechner zu<br />
schaffen gemacht hat.<br />
Ein Passwort sollte in bestimmten, unregelmäßigen Abständen geän<strong>der</strong>t werden. In einigen<br />
Systemen kann <strong>der</strong> Systemadministrator auch bestimmte Intervalle festlegen, nach<br />
<strong>der</strong>en Ablauf die vergebenen Passwörter geän<strong>der</strong>t werden müssen. Ist <strong>der</strong> Zeitpunkt <strong>der</strong><br />
Än<strong>der</strong>ung gekommen, dann wird <strong>der</strong> Anwen<strong>der</strong> vom System dazu aufgefor<strong>der</strong>t, ein neues<br />
Passwort zu vergeben.<br />
20
3.2.2 Eigenschaften von Passwörtern<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Um den Zugriffsschutz, <strong>der</strong> durch den Einsatz eines Passwortsystems angestrebt wird,<br />
realisieren zu können, ist er erfor<strong>der</strong>lich, dass sowohl die Passwörter selbst als auch das<br />
Passwortsystem einige Eigenschaften erfüllen. Als wichtigste dieser Eigenschaften können<br />
die folgenden genannt werden:<br />
1. Ein Passwort soll lang sein, sehr häufig wird eine Mindestlänge von sechs o<strong>der</strong><br />
sieben Zeichen empfohlen bzw. festgelegt.<br />
2. Das Passwort soll aus einer Kombination aus Buchstaben, Ziffern und Son<strong>der</strong>zeichen<br />
bestehen und als solche keine Bedeutung aufweisen. Es soll also vermieden<br />
werden, herkömmliche Wörter des Sprachgebrauchs als Passwörter einzusetzen.<br />
3. Das Passwort soll je<strong>der</strong>zeit än<strong>der</strong>bar sein und auch regelmäßig geän<strong>der</strong>t werden.<br />
4. Es soll von den Anwen<strong>der</strong>Innen nirgends notiert werden.<br />
5. Das Passwort soll in Gegenwart an<strong>der</strong>er Personen immer geschützt in das Eingabegerät<br />
eingegeben werden.<br />
6. Die Anzahl möglicher Fehlversuche soll auf n Versuche begrenzt und <strong>der</strong> betreffende<br />
Benutzer nach n erfolglosen Anmeldeversuchen gesperrt werden.<br />
7. Das Passwort soll geschützt zur prüfenden Stelle übertragen werden, und auch<br />
die Überprüfung und Speicherung sollen durch einen Schutzmechanismus (z. B.<br />
Verschlüsselung) abgesichert werden.<br />
Der Sicherheitsbeauftragte bzw. <strong>der</strong> Systemadministrator eines Unternehmens sollte einerseits<br />
selbst bei <strong>der</strong> Einführung eines Passwortsystems die angeführten Eigenschaften<br />
beachten und an<strong>der</strong>erseits alle SystembenutzerInnen dahingehend anweisen, ihre Passwörter<br />
entsprechend <strong>der</strong> gefor<strong>der</strong>ten Eigenschaften zu wählen und auch in ihrer täglichen<br />
Arbeit mit Daten und Passwörtern auf die nötige Sorgfalt zu achten.<br />
3.2.3 Vorteile von Passwortsystemen<br />
Der Passwortschutz als sehr häufig eingesetzte Methode <strong>der</strong> Zugriffskontrolle bietet u. a.<br />
folgende Vorteile:<br />
1. Ein Passwortsystem ist die mit Abstand kostengünstigste und am einfachsten zu<br />
realisierende aller bestehenden Systeme <strong>der</strong> Zugriffskontrolle.<br />
2. Die Anwen<strong>der</strong> sind meist mit dem Umgang mit Passwörtern vertraut. Häufig ist nur<br />
eine kurze Einweisung nötig, und es bedarf keiner speziellen Kenntnisse, um mit<br />
einem Passwortsystem arbeiten zu können.<br />
3. Der Passwortschutz ist eine sehr weit verbreitete Methode <strong>der</strong> Zugriffskontrolle,<br />
woraus <strong>der</strong> Vorteil resultiert, dass es dafür sehr viele Anbieter und Standards gibt,<br />
und dass außerdem sehr viele Erfahrungen mit <strong>der</strong>artigen Systemen vorliegen.<br />
4. Passwortsysteme sind in <strong>der</strong> Regel sehr einfach zu administrieren. Dieser Vorteil<br />
verwandelt sich aber sehr schnell ins Gegenteil, wenn ein Betriebssystem o<strong>der</strong> eine<br />
Standardanwendung eingesetzt wird, <strong>der</strong>en Passwortsystem aufgrund hoher<br />
Komplexität, Kompliziertheit o<strong>der</strong> Undurchschaubarkeit nur mit hohem Aufwand<br />
administrierbar ist.<br />
3.2.4 Nachteile von Passwortsystemen<br />
Den erwähnten Vorteilen von Passwortsystemen können die folgenden Nachteile gegenübergestellt<br />
werden:<br />
21
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
1. Die EDV-Anwen<strong>der</strong> müssen sich das gewählte Passwort merken. Dazu kommt<br />
noch, dass sich ein Anwen<strong>der</strong> nicht nur eines, son<strong>der</strong>n meist mehrere, verschiedene<br />
Passwörter merken muss, wenn zum Beispiel ein Netzwerk und<br />
verschiedene Anwendungsprogramme mit unterschiedlichen Passwortsystemen<br />
geschützt sind und <strong>der</strong> Anwen<strong>der</strong> verschiedene Passwörter vergibt, um ein möglichst<br />
hohes Maß an Zugriffsschutz zu erreichen. Außerdem erfor<strong>der</strong>t die<br />
technisierte Welt von heute vielerorts auch im Privatleben den Gebrauch von verschiedenen<br />
Passwörtern, Pincodes und dgl. Der Umstand, sich gleichzeitig<br />
mehrere Passwörter merken zu müssen, führt in <strong>der</strong> Praxis häufig dazu, dass Anwen<strong>der</strong><br />
für verschiedene Programme dasselbe Passwort vergeben o<strong>der</strong> einfache<br />
Begriffe als Passwörter wählen, die sie sich dann leichter merken können. Es<br />
kommt auch immer wie<strong>der</strong> vor, dass Anwen<strong>der</strong> ihre Passwörter notieren, was natürlich<br />
eine zusätzliche Sicherheitslücke bedeutet.<br />
2. Ein EDV-Anwen<strong>der</strong> kann sein Passwort sehr leicht an eine unautorisierte Person<br />
weitergeben.<br />
3. Das Passwort kann unter bestimmten Umständen herausgefunden werden. Vor allem,<br />
wenn die Anzahl möglicher Falschanmeldungen nicht nach oben begrenzt ist,<br />
besteht die Gefahr, dass durch Probieren, durch genaues Beobachten während<br />
<strong>der</strong> Eingabe o<strong>der</strong> mit Hilfe eines Passwortsuchprogramms das Passwort herausgefunden<br />
wird. Weitere Möglichkeiten, um an Passwörter zu gelangen, sind das<br />
Abhören <strong>der</strong> Übertragungsleitung o<strong>der</strong> das Auslesen <strong>der</strong> Datei, in <strong>der</strong> das Passwort<br />
gespeichert ist.<br />
3.3 Biometrische Methoden<br />
3.3.1 Begriffserklärung<br />
Unter Biometrie versteht man laut Lexikon die „Lehre <strong>der</strong> Anwendung mathematischer,<br />
statistischer Methoden auf die Mess- und Zahlenverhältnisse <strong>der</strong> Lebewesen und ihrer<br />
Einzelteile“.<br />
Bezogen auf die EDV, und hier in erster Linie auf Systeme <strong>der</strong> Zugangs- und Zugriffskontrolle,<br />
steht die Biometrie für „... ein Synonym für den Identitätsnachweis von Personen<br />
unter Verwendung ihrer individuellen, körperlichen Merkmale [Ruef00]“. Diese Definition<br />
kann um den Aspekt <strong>der</strong> Verwendung von spezifischen Verhaltensweisen einzelner Personen<br />
ergänzt werden, denn es gibt auch biometrische Methoden, die nicht nur punktuelle<br />
Merkmale, son<strong>der</strong>n auch das Verhalten von Personen erkennen und für die Authentisierung<br />
verwenden.<br />
3.3.2 Funktionsweise biometrischer Methoden<br />
3.3.2.1 Grundsätzlicher Ablauf<br />
Ein biometrisches System zur Zugangs- und Zugriffssteuerung von Räumlichkeiten, EDV-<br />
Systemen, Anwendungen, usw. funktioniert auf die folgende Art und Weise:<br />
Wenn sich eine Person am System identifiziert bzw. versucht, sich zu identifizieren, dann<br />
werden zunächst die <strong>der</strong> eingesetzten, biometrischen Methode entsprechenden, biometrischen<br />
Merkmale <strong>der</strong> Person aktuell erhoben. Diese Merkmale werden dann in<br />
komprimierte Datensätze umgewandelt.<br />
22
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Die entstandenen Datensätze, die die Musterinformationen <strong>der</strong> Originaldaten enthalten,<br />
werden anschließend mit Referenzdatensätzen <strong>der</strong> betreffenden Person verglichen, und<br />
bei entsprechen<strong>der</strong> Übereinstimmung wird <strong>der</strong> Zugang bzw. <strong>der</strong> Zugriff durch das System<br />
gewährt.<br />
Die oben erwähnten Referenzdaten müssen in <strong>der</strong> sog. „Einlernphase“ für alle Benutzer<br />
erfasst werden, um bei späteren Anmeldeversuchen für den erfor<strong>der</strong>lichen Vergleich zur<br />
Verfügung zu stehen. In <strong>der</strong> Einlernphase werden die biometrischen Daten <strong>der</strong> Benutzer<br />
meist mehrfach mit Hilfe von Sensoren erfasst, digitalisiert und schließlich in komprimierte<br />
Referenzdatensätze umgewandelt. Das Einlernen kann einmalig vor <strong>der</strong> Nutzung stattfinden,<br />
es gibt aber auch Systeme, die adaptiv arbeiten, d. h. auch bei sich än<strong>der</strong>nden<br />
Merkmalen, z. B. durch den Alterungsprozess, bleibt die Funktionalität <strong>der</strong> biometrischen<br />
Verfahren erhalten, ohne neuerlich einlernen zu müssen.<br />
Bei den biometrischen Verfahren wird zwischen <strong>der</strong> Verifikation und <strong>der</strong> Identifikation unterschieden:<br />
- Bei <strong>der</strong> Verifikation werden die Eingangsdaten mit den Referenzdaten jener Person<br />
verglichen, für die sicher <strong>der</strong> Nutzer ausgibt, um dessen Identität zu<br />
bestätigen.<br />
- Bei <strong>der</strong> Identifikation wird durch einen 1:n-Vergleich <strong>der</strong> Eingangsdaten mit den<br />
gespeicherten Referenzdaten vieler Benutzer versucht, die Identität einer bestimmten<br />
Person festzustellen.<br />
3.3.2.2 Fehlertoleranz<br />
Die Fehlertoleranz bezeichnet die maximale Differenz zwischen den aktuell festgestellten,<br />
biometrischen Daten und den zugehörigen Referenzdaten, bei <strong>der</strong> die sich anmeldende<br />
Person noch als solche erkannt wird. Innerhalb dieser Toleranz wird einer Person also <strong>der</strong><br />
gewünschte Zugang bzw. Zugriff gewährt.<br />
Die Festlegung einer bestimmten Fehlertoleranz ist wichtig, weil dadurch die Erkennungsrate<br />
des Verfahrens bestimmt wird. Die Erkennungsrate sagt aus, wie viele <strong>der</strong><br />
gespeicherten Benutzer als solche erkannt werden. Ist die gewählte Toleranz zu klein,<br />
dann werden auch berechtigte Benutzer abgewiesen, was sich negativ auf die Akzeptanz<br />
des Systems auswirken kann. Ist die Fehlertoleranz zu groß, dann wird möglicherweise<br />
einem unberechtigten Benutzer Zugang o<strong>der</strong> Zugriff gewährt, was dazu führt, dass die<br />
Zuverlässigkeit des Systems in Frage gestellt wird.<br />
Als Maß für die Leistungsfähigkeit eines biometrischen Verfahrens kann die Gleichfehlerrate<br />
herangezogen werden, bei <strong>der</strong> die Zahl <strong>der</strong> fälschlich abgewiesenen Personen mit<br />
<strong>der</strong> Zahl <strong>der</strong> fälschlich akzeptierten Personen übereinstimmt. Diese Gleichfehlerrate fiel<br />
bei praktischen Erprobungen des Fingerabdruckverfahrens im Promillebereich aus, bei<br />
an<strong>der</strong>en Verfahren sollen sogar schon Ergebnisse mit <strong>der</strong> Gleichfehlerrate Null erzielt<br />
worden sein.<br />
3.3.2.3 Referenzdatenverwaltung<br />
Der Grad <strong>der</strong> Datensicherheit, die bei biometrischen Verfahren erreicht werden kann,<br />
hängt in hohem Maß vom Schutz <strong>der</strong> Referenzdaten und Vergleichsmechanismen ab. Als<br />
Speicherort für die biometrischen Referenzdatensätze fungieren entwe<strong>der</strong> das Lesegerät<br />
selbst als lokaler Speicher, ein zentraler Speicherort im Netzwerk o<strong>der</strong> eine Chip- bzw.<br />
Magnetkarte [ScWe00].<br />
23
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Werden alle Referenzdaten lokal im Lesegerät gespeichert, dann bietet das Vorteile bezüglich<br />
<strong>der</strong> Geschwindigkeit, bringt allerdings auch einige Nachteile und Gefahren mit<br />
sich. Ein wichtiger dieser Nachteile ist die eingeschränkte, lokale Einsetzbarkeit. Beim<br />
Einsatz mehrerer <strong>der</strong>artiger Geräte und einem anfallenden Update erhöht sich zudem <strong>der</strong><br />
Wartungsaufwand erheblich, da das Update bei allen Geräten einzeln durchgeführt werden<br />
muss. Außerdem birgt die Form <strong>der</strong> lokalen Speicherung die Gefahr, bei Defekten<br />
o<strong>der</strong> Diebstählen alle Daten zu verlieren.<br />
Bei <strong>der</strong> zentralen Speicherung werden alle Referenzdaten auf einem Server gespeichert,<br />
auf den alle eingesetzten Geräte zugreifen können, was auch den laufenden Wartungsaufwand<br />
minimiert. Der Verlust eines Lesegerätes würde zudem ein deutlich geringeres<br />
Schadensausmaß bedeuten als im Fall eines Gerätes mit lokal gespeicherten Referenzdaten.<br />
Bei <strong>der</strong> zentralen Speicherung muss jedoch ein sehr hohes Maß an<br />
Datensicherheit gewährleistet werden. Das betrifft sowohl den Server selbst als auch das<br />
Netzwerk, über das die Referenzdaten vom Server in das Lesegerät, o<strong>der</strong> umgekehrt,<br />
transportiert werden.<br />
Bei <strong>der</strong> dritten Möglichkeit <strong>der</strong> Referenzdatenspeicherung werden diese auf einer Chipkarte<br />
o<strong>der</strong> einer Magnetkarte gespeichert. Je<strong>der</strong> Benutzer verwendet die Chipkarte mit<br />
seinen Referenzdaten dazu, seine Identität nachzuweisen. Diese Vorgehensweise bietet<br />
den Vorteil, dass die Möglichkeit zur Verifizierung nicht auf lokale Netze beschränkt ist, da<br />
alle Personen ihre persönlichen Gegenmuster überall hin mitnehmen können, und für die<br />
Art <strong>der</strong> Speicherung sind auch keine beson<strong>der</strong>en Datenschutzmaßnahmen erfor<strong>der</strong>lich.<br />
Negative Auswirkungen könnte diese Methode unter Umständen auf die Akzeptanz durch<br />
die Anwen<strong>der</strong>Innen haben, da sie für jede Anmeldung ihre Chipkarte benötigen, was aus<br />
Sicht <strong>der</strong> Benutzerfreundlichkeit häufig als nachteilig empfunden wird. Die Chipkarte ist<br />
auch je<strong>der</strong>zeit dem Verlust durch Verlieren, Verlegen o<strong>der</strong> Diebstahl ausgesetzt. Der Einsatz<br />
dieser Art <strong>der</strong> Referenzdatenspeicherung setzt daher eine entsprechende Sorgfalt<br />
und Disziplin bei den Anwen<strong>der</strong>Innen voraus.<br />
3.3.3 Verfahren biometrischer Identifikation bzw. Verifikation<br />
Nachfolgend werden verschiedene Verfahren <strong>der</strong> Biometrie erläutert, und es wird versucht,<br />
die wichtigsten Vor- und Nachteile <strong>der</strong> jeweiligen Methode herauszustreichen.<br />
3.3.3.1 Fingerabdruckverfahren<br />
Das Fingerabdruckverfahren basiert auf <strong>der</strong> Tatsache, dass kein Fingerabdruck einem<br />
an<strong>der</strong>en gleicht. Zum Erfassen <strong>der</strong> Fingerabdrücke werden zwei unterschiedliche Methoden<br />
eingesetzt. Während bei <strong>der</strong> optischen Variante die Fingerspitzen von Scannern<br />
aufgenommen werden, wird bei <strong>der</strong> kapazitiven Variante die Haut in einem elektrischen<br />
Verfahren durch Sensoren vermessen, wobei die Fingerabdrücke nicht als ganzes gespeichert<br />
werden, son<strong>der</strong>n eine Reduktion auf ihre wesentlichen Merkmale stattfindet.<br />
Wesentliche Merkmale sind etwa die Position und Richtung <strong>der</strong> Linien sowie <strong>der</strong>en Enden<br />
und Verzweigungen.<br />
Die Vorteile des Fingerabdruckverfahrens liegen in <strong>der</strong> hohen Fälschungssicherheit und in<br />
niedrigen Anschaffungskosten des Systems verglichen mit an<strong>der</strong>en biometrischen Systemen.<br />
Als weiterer Vorteil kann die Benutzerfreundlichkeit genannt werden.<br />
24
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Die geringe Benutzerakzeptanz, die aus <strong>der</strong> Kenntnis über den Einsatz von Fingerabdruck-Systemen<br />
durch die Exekutive bei <strong>der</strong> Suche nach Verbrechern resultiert, stellt<br />
einen <strong>der</strong> größten Nachteile solcher Systeme dar, da Benutzer dadurch sehr schnell ihre<br />
Persönlichkeitsrechte gefährdet sehen.<br />
3.3.3.2 Gesichtsgeometrie<br />
Bei dieser Methode werden die charakteristischen Merkmale <strong>der</strong> Gesichtszüge zur Identifikation<br />
herangezogen. Die Gesichter <strong>der</strong> Benutzer werden mittels Videokamera<br />
aufgezeichnet und das Ergebnis danach entsprechend ausgewertet.<br />
Als Vorteil für dieses System kann dessen berührungsfreie Durchführung genannt werden.<br />
Als nachteilig erweist sich jedoch <strong>der</strong> Umstand, dass <strong>der</strong>artige Systeme auch zur Identifizierung<br />
von Personen in <strong>der</strong> Öffentlichkeit eingesetzt werden, was datenschutzrechtlich<br />
zu Problemen führen kann, und folglich auch die Akzeptanz durch die Benutzer hemmt.<br />
Außerdem sind für Gesichtsgeometrieverfahren umfangreiche Datensätze und sehr<br />
schnelle, also auch dementsprechend kostenintensive Computersysteme erfor<strong>der</strong>lich.<br />
3.3.3.3 Handgeometrie<br />
Hier werden mit Hilfe eines geeigneten Abtastgerätes entwe<strong>der</strong> die genauen Masse <strong>der</strong><br />
Hand registriert, o<strong>der</strong> es werden Systeme eingesetzt, die ein Venenbild <strong>der</strong> Hand liefern.<br />
Ein Vorteil dieser Technologie ist, dass sie schon seit mehr als zehn Jahren im Einsatz ist,<br />
und man daher auf entsprechende Erfahrungen zurückgreifen kann.<br />
Ein nachteiliger Aspekt ist aber, dass dieses Verfahren nicht hun<strong>der</strong>tprozentig sicher ist,<br />
obwohl keine Hand einer an<strong>der</strong>en gleicht. So können zum Beispiel die Länge und ev. die<br />
Lackierung von Fingernägeln ein Problem für den eingesetzten Scanner darstellen.<br />
3.3.3.4 Netzhautabtastung<br />
Bei dieser Methode <strong>der</strong> biometrischen Authentisierung wird die Netzhaut (Iris) des<br />
menschlichen Auges mit einem ungefährlichen Laserstrahl abgetastet. Dabei wird die<br />
A<strong>der</strong>nstruktur des Augenhintergrundes aufgezeichnet, die dann zur Identifikation <strong>der</strong><br />
betreffenden Person dient. Die A<strong>der</strong>nstruktur verän<strong>der</strong>t sich nur durch schwere Augenverletzungen<br />
und ist deshalb ein sehr zuverlässiges Merkmal für die biometrische<br />
Authentifizierung.<br />
Aufgrund <strong>der</strong> Größe (Datenmenge) vorläufig weggelassen!<br />
Abb. 4: Netzhaut des menschlichen Auges<br />
Der wichtigste Vorteil <strong>der</strong> Netzhautabtastung besteht in <strong>der</strong> extrem niedrigen Fehlerrate.<br />
Durch die Einzigartigkeit und Stabilität <strong>der</strong> A<strong>der</strong>nstruktur des Augenhintergrundes, und<br />
durch die Schnelligkeit <strong>der</strong> Abtastung gehört dieses System zu den besten Authentifizierungsmethoden.<br />
25
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Ein Nachteil des Verfahrens resultiert aus dem Umstand, dass Personen häufig mit Skepsis<br />
und Hemmnissen reagieren, wenn ihre Augen mit einem Laser abgetastet werden<br />
sollen. Zusätzlich wird von verschiedenen Stellen die medizinische Unbedenklichkeit <strong>der</strong><br />
Irisabtastung immer wie<strong>der</strong> angezweifelt.<br />
3.3.3.5 Unterschriftenerkennung<br />
Bei <strong>der</strong> Unterschriftenerkennung werden die Dynamik des Schreibvorgangs, die Unterschiede<br />
in <strong>der</strong> Kraftanwendung und von manchen Systemen auch die Geschwindigkeit<br />
und Beschleunigung des Schreibstiftes während des Schreibvorgangs ausgewertet.<br />
Die Vorteile dieses Verfahrens sind in <strong>der</strong> hohen Akzeptanz durch die Benutzer und in <strong>der</strong><br />
hohen Fälschungssicherheit durch die Auswertung <strong>der</strong> individuellen Feinmotorik zu finden.<br />
Als nachteilig könnte <strong>der</strong> erfor<strong>der</strong>liche, im Vergleich zu an<strong>der</strong>en biometrischen Systemen,<br />
höhere Zeitaufwand empfunden werden.<br />
3.3.3.6 Stimmerkennung<br />
Bei <strong>der</strong> Stimmerkennung kann man je nach den gemessenen Merkmalen zwei verschiedene<br />
Formen <strong>der</strong> Identifikation unterscheiden. Bei <strong>der</strong> Stimmanalyse werden die<br />
unterschiedlichen Kombinationen von Frequenzbereichen in <strong>der</strong> menschlichen Stimme<br />
aufgezeichnet und verglichen, während bei <strong>der</strong> Sprachmustererkennung Sprachmerkmale,<br />
wie etwa die Sprachdynamik, ausgewertet werden.<br />
Die Stimmenanalyse zeichnet sich durch eine sehr hohe Erkennungsrate aus. Der größte<br />
Vorteil <strong>der</strong> Sprachmustererkennung ist sicherlich die Möglichkeit <strong>der</strong> Identifikation über<br />
Telefonleitungen.<br />
Ein erheblicher sicherheitstechnischer Nachteil ergibt sich daraus, dass gesprochene<br />
Wörter auch mit Hilfe eines Recor<strong>der</strong>s aufgenommen und wie<strong>der</strong>gegeben werden können.<br />
Diese Gefahr kann jedoch umgangen werden, wenn <strong>der</strong> Benutzer vom Computer<br />
jeweils zufällig vorgegebene Wörter nachsprechen muss.<br />
3.3.3.7 PsyLock<br />
Bei diesem Verfahren dient das individuelle Anschlagverhalten auf einer Tastatur als Erkennungsmerkmal.<br />
Der wichtigste Vorteil dieser Variante liegt sicherlich in <strong>der</strong> hohen Akzeptanz durch die<br />
Benutzer.<br />
Als Nachteil kann <strong>der</strong> vergleichsweise hohe Aufwand für die Erstmustererstellung genannt<br />
werden.<br />
3.3.4 Biometrie und Datenschutz<br />
Biometrische Authentifizierungsmethoden beinhalten das nicht unerhebliche Problem,<br />
dass die erhobenen, biometrischen Daten als personenbezogene Daten dem Datenschutzgesetz<br />
unterliegen.<br />
26
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Viele Sensoren, die zur biometrischen Personenidentifikation eingesetzt werden, können<br />
viel mehr Informationen aufnehmen, als sie für die eigentliche Identifikation benötigen. Auf<br />
diese Art könnten Informationen über Krankheiten, Drogenkonsum o<strong>der</strong> ähnliches gewonnen<br />
und ausgewertet werden [Köhn99]. Nicht nur deswegen ist es enorm wichtig,<br />
dass biometrische Verfahren, die zur Authentifizierung von Personen eingesetzt werden,<br />
den For<strong>der</strong>ungen des Datenschutzgesetzes gerecht werden.<br />
Ein biometrisches Verfahren sollte so gewählt werden, dass die biometrischen Eingangs-<br />
und Referenzdaten keine Informationen enthalten, die über das für die Identifikation notwendige<br />
Maß hinausgehen. Die verwendeten Daten dürfen keine Hinweise auf<br />
Veranlagungen, den gesundheitlichen Zustand o<strong>der</strong> das Verhalten <strong>der</strong> Benutzer liefern.<br />
Es darf auch nicht möglich sein, von den gespeicherten Referenzdaten Rückschlüsse auf<br />
die Personen o<strong>der</strong> ihre biometrischen Merkmale zu ziehen. Außerdem muss die Möglichkeit<br />
unterbunden werden, mit Hilfe <strong>der</strong> Referenzdaten Aktionen <strong>der</strong> Benutzer vortäuschen<br />
zu können. Ein Beispiel hierfür wäre das erfolgreiche Einbringen von falschen Fingerabdrücken.<br />
Biometrische Merkmale lassen sich anhand <strong>der</strong> beiden folgenden Kriterien differenzieren:<br />
- Dauerhaftigkeit: Es gibt Merkmale, die ein Leben lang an eine Person gebunden<br />
sind, wie beispielsweise das Erbmaterial. An<strong>der</strong>e Merkmale können sich im Laufe<br />
<strong>der</strong> Zeit durch Alterung, Wachstumsprozesse o<strong>der</strong> Krankheiten verän<strong>der</strong>n. Aus<br />
Datenschutzsicht sollten Verfahren bevorzugt werden, die sich jener Merkmale<br />
bedienen, die keinen langfristigen o<strong>der</strong> sogar lebenslangen Personenbezug und<br />
damit eine entsprechend lange Sensibilität <strong>der</strong> Daten mit sich bringen.<br />
- Das zweite Unterscheidungskriterium besteht in <strong>der</strong> Frage, ob das biometrische<br />
Verfahren eine bewusste Entscheidung o<strong>der</strong> Mithilfe <strong>der</strong> Person erfor<strong>der</strong>lich<br />
macht, wozu unter an<strong>der</strong>em das Tätigen einer Unterschrift o<strong>der</strong> das Sprechen eines<br />
bestimmten Textes zählen, o<strong>der</strong> ob das Verfahren auch unbemerkt ablaufen<br />
kann, was im Falle <strong>der</strong> Gesichtserkennung zutreffen würde. Hier sollte jenen Verfahren<br />
<strong>der</strong> Vorrang gegeben werden, die eine bewusste Entscheidung o<strong>der</strong><br />
Mithilfe des Benutzers erfor<strong>der</strong>n.<br />
Während des Einsatzes eines biometrischen Authentifizierungsverfahrens sollte auch das<br />
Anlegen großer Datensammlungen, wie etwa bei <strong>der</strong> zentralen Speicherung <strong>der</strong> Referenzdaten,<br />
vermieden werden. Es muss sehr sorgfältig auf die Wahl eines sicheren<br />
Lagerortes für die Referenzdaten geachtet werden. Die beste Lösung in diesem Zusammenhang<br />
wäre sicherlich, den Benutzern die ausschließliche Kontrolle über ihre<br />
Referenzdaten zu überlassen, was durch die Speicherung <strong>der</strong> verschlüsselten Referenzdaten<br />
auf Chipkarten o<strong>der</strong> sog. SmartCards möglich wäre [PrKö99].<br />
Für die Übertragung von biometrischen Daten sollten unbedingt Verschlüsselungstechniken<br />
eingesetzt werden, und es sollte auch eine zuverlässige und manipulationssichere<br />
Protokollierung von Referenzdaten, erfolgreichen Authentifizierungen und erfolglosen Authentifizierungsversuchen<br />
stattfinden. Wichtig sind zudem die Transparenz des<br />
eingesetzten Verfahrens und <strong>der</strong> Sicherheitsmechanismen.<br />
3.3.5 Vorteile von biometrischen Authentisierungsverfahren<br />
Zusammengefasst können die folgenden Vorteile von biometrischen Verfahren genannt<br />
werden:<br />
27
1. Hohe Erkennungssicherheit<br />
1. Fast absolute Verlustsicherheit<br />
2. Minimales Fälschungsrisiko<br />
3. Einfachheit <strong>der</strong> Benutzung<br />
4. Keine Möglichkeit <strong>der</strong> Weitergabe<br />
5. Sehr vielfältige Einsatzmöglichkeiten<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
3.3.6 Nachteile von biometrischen Authentisierungsverfahren<br />
Als nachteilig erweisen sich die folgenden Punkte:<br />
1. Hohe Anschaffungskosten<br />
2. Gefahr <strong>der</strong> Verletzung des Persönlichkeitsschutzes<br />
3. Eventuell hygienische Bedenken bei berührungsabhängigen Systemen<br />
4. Fehlende Standards<br />
5. Viele unterschiedliche Produkte<br />
3.4 SmartCards<br />
3.4.1 Charakteristik und Funktionsweise von SmartCards<br />
Breitere Anwendungsmöglichkeiten als biometrische Verfahren zur Authentifizierung bieten<br />
<strong>der</strong>zeit die sog. SmartCards, da sie die Eigenschaft <strong>der</strong> Portabilität mit höchsten<br />
Sicherheitseigenschaften verbinden.<br />
Sie haben in <strong>der</strong> Regel die Größe einer Standard-EC-Karte (86 x 54 x 0,76 mm), besitzen<br />
jedoch im Unterschied zu Magnetstreifenkarten einen Chip zur Informationsspeicherung.<br />
Dieser Chip enthält den kryptografischen Schlüssel und daduch werden die individuellen<br />
Daten ihres Eigentümers sicher auf <strong>der</strong> SmartCard gespeichert.<br />
Die SmartCard eignet sich beson<strong>der</strong>s dazu, die privaten Schlüssel, die Bestandteil vieler<br />
Verschlüsselungsverfahren sind, wie auch spezielle Zertifikate zu speichern.<br />
Sie ist nicht nur für den Anwen<strong>der</strong> praktisch, <strong>der</strong> die auf <strong>der</strong> Karte gespeicherten Informationen<br />
immer mit sich führt, son<strong>der</strong>n erleichtert umgekehrt auch wesentlich die<br />
Schlüsselverteilung. Damit ist die Chipkarte für alle offenen Netze einsatzfähig.<br />
Durch ihre erwähnten Eigenschaften werden die SmartCards häufig in das Sicherheitskonzept<br />
eines Unternehmensnetzes integriert. In PCs fest eingebaute SmartCard-Leser<br />
machen hohe Sicherheit für den Anwen<strong>der</strong> zur Selbstverständlichkeit. Zusätzlichen Komfort<br />
für den Anwen<strong>der</strong> bringt die SmartCard auch, da Benutzerkennung und Details zur<br />
Anmeldung wie Domain-Name auf <strong>der</strong> Karte gespeichert sind. Zusätzlich können auf <strong>der</strong><br />
Chipkarte auch applikationsspezifische Passwörter, die <strong>der</strong> jeweilige Host verlangt, etwa<br />
für Lotus Notes o<strong>der</strong> <strong>SAP</strong> R/3, gespeichert werden [Geig00].<br />
Eventuell vorhandene Schwachstellen eines bestehenden Systems lassen sich durch sog.<br />
Krypto-SmartCards umgehen, mit <strong>der</strong>en Hilfe eine Authentisierung durch kryptographische<br />
Protokolle zwischen Workstation und Host vollzogen werden kann. Das ist sinnvoll,<br />
da ohne Verschlüsselung die durch das Anmeldeprotokoll übertragenen Passwörter zu<br />
einfach rekonstruierbar wären. Soll darüber hinaus eine sichere Authentisierung für Telearbeiter<br />
o<strong>der</strong> Mitarbeiter im Aussendienst erreicht werden, so ist zu beachten, dass die<br />
Verbindung zum Firmennetz durch kryptographische Verfahren zu sichern ist.<br />
28
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Um einem möglichen Missbrauch von SmartCards vorzubeugen, sind diese typischerweise<br />
mit einer PIN geschützt, was die SmartCard zu einem Authentifizierungsverfahren<br />
macht, das Wissen und Besitz kombiniert.<br />
3.4.2 Vorteile von SmartCards<br />
Die Vorteile <strong>der</strong> SmartCard sind:<br />
- Verschlüsselungsmöglichkeit <strong>der</strong> gespeicherten Daten<br />
- Vielfältige und systemübergreifende Einsatzmöglichkeiten<br />
- Passwortschutz <strong>der</strong> Karte zur Erhöhung <strong>der</strong> Sicherheit<br />
- Portabilität<br />
- Einfachheit <strong>der</strong> Benutzung<br />
3.4.3 Nachteile von SmartCards<br />
Als nachteilig können genannt werden:<br />
- Möglichkeit <strong>der</strong> Weitergabe<br />
- Eingeschränktes Verlustrisiko (durch Passwortschutz)<br />
3.5 Beispielhafte Betrachtung von Betriebssystemen und<br />
Standardsoftware<br />
In diesem Abschnitt werden die Betriebssysteme UNIX, Linux und Windows 2000 und die<br />
Standardsoftware Lotus Notes in Hinblick auf Daten- und Zugriffsschutz untersucht. Die<br />
Erläuterungen zur Applikationssoftware <strong>SAP</strong> R/3 bezüglich <strong>der</strong> Zugriffskontrolle erfolgen<br />
im Rahmen <strong>der</strong> Projektbeschreibung an späterer Stelle.<br />
3.5.1 UNIX<br />
UNIX ist ein Betriebssystem, das sich in den letzten Jahren bzw. Jahrzehnten als ein<br />
hardware- und herstellerunabhängiges Betriebssystem immer stärker durchsetzen konnte.<br />
Es gilt als das offene Betriebssystem schlechthin und wurde speziell unter dem Aspekt<br />
<strong>der</strong> Sicherheit immer wie<strong>der</strong> als vorbildlich bezeichnet. Ob dem wirklich so ist, und ob<br />
UNIX speziell auf dem Gebiet <strong>der</strong> Zugriffskontrolle ein Höchstmass an Schutz zur Verfügung<br />
stellt, soll hier näher betrachtet werden.<br />
Das Betriebssystem unterscheidet drei verschiedene Arten von Benutzern, nämlich den<br />
Eigentümer <strong>der</strong> jeweiligen Datei, Benutzergruppen und sämtliche an<strong>der</strong>en Benutzer. Außer<br />
diesen drei Benutzerarten gibt es nur noch den sog. Super-User, <strong>der</strong> für<br />
administrative Zwecke vorgesehen ist, und für den die regulären Zugriffsmechanismen<br />
nicht wirksam sind. Das UNIX-Zugriffsschutzkonzept bietet die Grundvoraussetzungen für<br />
eine effektive <strong>Vergabe</strong> von Benutzerberechtigungen, indem Lese-, Schreib- und Ausführungsberechtigungen<br />
je<strong>der</strong> einzelnen Datei für <strong>der</strong>en Eigentümer, für eine ihr zugeordnete<br />
Benutzergruppe sowie für alle an<strong>der</strong>en Benutzer unabhängig voneinan<strong>der</strong> vergeben werden<br />
können [KüSc97b, 122].<br />
29
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
An<strong>der</strong>e Rechte, wie etwa das Löschrecht o<strong>der</strong> das Recht, etwas an eine Datei anfügen zu<br />
können, werden durch das Betriebssystem nicht unterstützt. UNIX bietet auch wenig Flexibilität<br />
bei <strong>der</strong> Verwaltung von verschiedenen Benutzergruppen mit unterschiedlichen<br />
Rechten an gemeinsam benutzten Dateien. Neuere UNIX-Systeme bieten zwar die Möglichkeit,<br />
Benutzern die gleichzeitige Mitgliedschaft in mehreren Gruppen zu erlauben, was<br />
dieses Problem allerdings auch nicht löst. Soll eine Datei unter UNIX vor unbefugten Manipulationen<br />
sicher sein, dann erfor<strong>der</strong>t das, dass nicht nur die betreffende Datei, son<strong>der</strong>n<br />
auch das übergeordnete Verzeichnis <strong>der</strong>artig geschützt ist. Man muss also auch ein beson<strong>der</strong>es<br />
Augenmerk auf die Verzeichnisrechte legen.<br />
Auch die Protokollierung unter UNIX weist einige Mängel auf. Es werden lediglich erfolgreiche<br />
und fehlgeschlagene Benutzeranmeldungen sowie gelungene und misslungene<br />
Versuche, Super-User-Status zu erhalten, aufgezeichnet. An<strong>der</strong>e Protokollierungen, wie<br />
das Aufzeichnen von Dateizugriffen, Programmaufrufen, Datenübertragungen, usw. werden<br />
durch das Betriebssystem nicht unterstützt, son<strong>der</strong>n müssen auf <strong>der</strong><br />
Anwendungsebene durchgeführt werden.<br />
Die häufig kritisierten, uneingeschränkten Rechte des bereits erwähnten Super-Users<br />
können durch bestimmte Maßnahmen eingeschränkt werden. Durch Verwendung von<br />
Menüsystemen für die Systemverwaltung kann man gewährleisten, dass <strong>der</strong> Super-User<br />
nicht direkt auf <strong>der</strong> Ebene des Betriebssystems arbeitet, son<strong>der</strong>n mittels festgelegter<br />
Funktionen, die entsprechend <strong>der</strong> jeweiligen Anfor<strong>der</strong>ungen vergeben werden können,<br />
auf diese zugreift. Derartige Menüsysteme gehören allerdings nicht zum UNIX-Standard.<br />
Zur organisatorischen Kontrolle des Super-Users kann auch eine geteilte <strong>Vergabe</strong> des<br />
Super-User-Passworts erfolgen, womit das Vier-Augen-Prinzip realisiert werden kann,<br />
o<strong>der</strong> das Arbeiten als Super-User könnte auch an die Bedingung geknüpft werden, dass<br />
sich vor dessen Anmeldung ein Kontrollbenutzer am System angemeldet hat. Benutzer<br />
können ihre Daten vor dem Zugriff des Super-Users schützen, indem sie diese unter Zuhilfenahme<br />
geeigneter Mechanismen verschlüsseln.<br />
Die lokale Authentisierung <strong>der</strong> UNIX-Benutzer erfolgt mittels Eingabe <strong>der</strong> Benutzerkennung<br />
und zugehörigem Passwort. Die Passwörter werden verschlüsselt im System<br />
gespeichert, wodurch es selbst dem Super-User nicht möglich ist, die Passwörter <strong>der</strong> Benutzer<br />
in Erfahrung zu bringen. Es besteht aber die Gefahr, dass verschlüsselt<br />
gespeicherte Passwörter durch systematische Verfahren bzw. systematisches Probieren<br />
entschlüsselt werden [KeKr91, 62]. Deshalb ist es notwendig, die Dateien mit den verschlüsselten<br />
Passwörtern vor dem lesenden Zugriff gewöhnlicher Benutzer zu schützen.<br />
Zusätzlich sollte die Passwortgültigkeitsdauer begrenzt werden.<br />
In bezug auf böswillige Programme, wie Viren, ist zu sagen, dass hier speziell <strong>der</strong> Super-<br />
User angehalten ist, nur jene Programme auszuführen, die sicher sind und Super-User-<br />
Berechtigung benötigen, da <strong>der</strong> Super-User bekanntlich alle Zugriffskontrollen umgeht.<br />
Generell bieten UNIX-Systeme aber wenig Angriffspunkte für Viren und ähnliche Computeranomalien.<br />
Trotz o<strong>der</strong> gerade wegen <strong>der</strong> aufgezählten Schwächen ist das Sicherheitskonzept von<br />
UNIX leicht zu verstehen und die grundlegende Benutzeradministration und Rechteverwaltung<br />
<strong>der</strong> einzelnen Benutzer einfach und übersichtlich. Der Einsatz von UNIX erfor<strong>der</strong>t<br />
allerdings Personen, die Erfahrung im Umgang mit UNIX haben, was in erster Linie den<br />
Super-User, aber auch alle an<strong>der</strong>en BenutzerInnen betrifft. Sind geübte BenutzerInnen<br />
vorhanden, und reichen die in UNIX vorhandenen Möglichkeiten <strong>der</strong> Benutzerrechteverwaltung<br />
aus, dann ist UNIX sicherlich eine gute Wahl, auch in Hinsicht auf Datenschutz<br />
und Zugriffskontrolle.<br />
30
3.5.2 Linux<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Linux ist ein Betriebssystem, das in den letzten Jahren immer mehr Anhänger gefunden<br />
hat. Es setzt in bezug auf Zugriffsberechtigungen das Modell des Betriebssystems UNIX<br />
um und unterstützt hauptsächlich die Zugriffsarten „lesen“, „schreiben“ und „ausführen“<br />
[Magn99]. Darüber hinaus bietet Linux aber eine Reihe von Verfeinerungsmöglichkeiten<br />
dieser Zugriffsarten, wie beispielsweise Attribute für sicheres Löschen, Unverän<strong>der</strong>lichkeit,<br />
u. ä. Ein weiterer Vorteil von Linux gegenüber UNIX ist, dass die meisten<br />
implementierten Übertragungsprotokolle unter Linux offene Standards darstellen, was<br />
wichtig für die Nachvollziehbarkeit vertraulicher Datenübertragungen ist. Der Zugang zum<br />
System erfolgt auch unter Linux mittels Passwörtern. Linux bietet hier schon lange die<br />
Möglichkeit, die verschlüsselten Passwörter mit einer größeren Länge zu versehen und an<br />
einer nichtöffentlichen Stelle im System zu speichern, um <strong>der</strong> Gefahr entgegenzuwirken,<br />
das Passwort durch Ausprobieren herausfinden zu können.<br />
Abschließend kann festgehalten werden, dass unter Linux, äquivalent zu UNIX, durch<br />
einen erfahrenen Systemadministrator eine für die meisten Anfor<strong>der</strong>ungen hinreichende<br />
Vertraulichkeit <strong>der</strong> Daten erreicht werden kann.<br />
3.5.3 Windows 2000<br />
Die Windows-Betriebssysteme des amerikanischen Softwareherstellers Microsoft sind die<br />
bekanntesten aller angebotenen Betriebssysteme. Windows 2000 ist als Nachfolger des<br />
Betriebssystems Windows NT ein multitaskingfähiges Netzwerkbetriebssystem, das wie<br />
sein Vorgänger über eine auf den Mehrbenutzerbetrieb ausgelegte Systemarchitektur<br />
verfügt. Windows 2000 bietet eine Reihe von Sicherheitsmaßnahmen, die in das System<br />
integriert sind, und die Möglichkeit dafür bieten sollen, sowohl unvernetzte als auch vernetzte<br />
Arbeitsplatzrechner mit einem hohen Maß an Sicherheit auszustatten.<br />
Für jeden Benutzer von Windows 2000 muss ein Benutzerkonto eingerichtet werden, das<br />
sich aus einem eindeutigen Benutzernamen und einem Passwort zusammensetzt. Durch<br />
das zusätzliche Einrichten von Gruppenkonten lassen sich Benutzerberechtigungen effizient<br />
den einzelnen Benutzern zuweisen. Vom Betriebssystem werden vier<br />
Standardgruppen für Administratoren, Hauptbenutzer, Benutzer und Sicherungsoperatoren<br />
zur Verfügung gestellt, die über entsprechende Berechtigungen verfügen. Windows<br />
2000 ermöglicht durch die Verwendung des NT-spezifischen Dateiformats NTFS eine<br />
grundsätzlich sichere Dateiorganisation. Werden NTFS-Laufwerke eingesetzt, dann können<br />
Zugriffsberechtigungen für Ordner o<strong>der</strong> Dateien an Benutzer o<strong>der</strong> Benutzergruppen<br />
vergeben werden. Außerdem haben BenutzerInnen die Möglichkeit, ihre Ordner und Dateien<br />
zu verschlüsseln. Deswegen sollte beim Einrichten von Windows 2000 immer das<br />
Dateisystem NTFS gewählt werden.<br />
Die Passwörter unter Windows 2000 werden auf eine festlegbare Mindestlänge geprüft,<br />
und <strong>der</strong>en Gültigkeitsdauer lässt sich zeitlich begrenzen. Neue Passwörter werden auch<br />
mit zurückliegenden Passwörtern verglichen, zu einfache Passwörter werden jedoch nicht<br />
ausgeschlossen. Im Gegensatz zum Vorgänger Windows NT bietet Windows 2000 die<br />
Möglichkeit zur Beschränkung <strong>der</strong> Anzahl von Fehlversuchen bei <strong>der</strong> Anmeldung. Abgewiesene<br />
und erfolgreiche Zugriffe auf Objekte werden protokolliert, wobei die<br />
Protokollierung eingeschränkt werden kann. Auch Än<strong>der</strong>ungen des Systemzustands können<br />
protokolliert werden. Zum Schutz <strong>der</strong> Daten bei temporärer physischer Abwesenheit<br />
kann ein passwortgeschützter Bildschirmschoner aktiviert werden.<br />
31
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Beim Einsatz von Windows 2000 im Netzbetrieb werden sämtliche Än<strong>der</strong>ungen von Namen<br />
und Benutzerrechten vom sog. Domain-Controller verwaltet. Alle an<strong>der</strong>en Server in<br />
<strong>der</strong> entsprechenden Domäne werden mit dem Domain-Controller abgeglichen. Das ermöglicht<br />
den Zusammenschluss mehrerer Server zu einer einzelnen Domäne, die eine<br />
zentrale Benutzeranmeldung und eine zentrale Administration erlaubt. Ein Vorteil des<br />
Domänen-Konzepts ist, dass umfangreiche Netzwerke in unterschiedliche Domänen aufgeteilt<br />
werden können, wobei jede Domäne eine eigenständige Sicherheitsstrategie<br />
verfolgen kann. Ein Benutzer kann auf eine fremde Domäne nur dann zugreifen, wenn er<br />
in dieser als berechtigter Benutzer registriert ist.<br />
Als Schwachstellen von Windows 2000 gelten z. B. Disketten- und CD-ROM-Laufwerke,<br />
da es bereits Programme gibt, die es auch unter MS-DOS ermöglichen, NTFS-formatierte<br />
Datenträger zu lesen. Eine weitere Schwachstelle ist die fehlende Möglichkeit <strong>der</strong> Schnittstellenkontrolle.<br />
Die größten Schwächen zeigt das Windows-Betriebssystem aber immer<br />
wie<strong>der</strong> in Verbindung mit böswilligen Programmen, wie etwa Viren. Das Microsoft-<br />
Kommunikationstool Outlook dient häufig zur ,teilweise automatisierten, Übertragung von<br />
böswilligen Programmen o<strong>der</strong> E-Mails, die <strong>der</strong>artige Programme enthalten. Vor solchen<br />
Attacken muss man sich dann mit Hilfe an<strong>der</strong>er Programme, durch entsprechende Netzwerkstrukturen,<br />
durch ein sicherheitsbewusstes Verhalten <strong>der</strong> BenutzerInnen, usw.<br />
schützen.<br />
Trotz <strong>der</strong> angeführten Schwächen ist Windows 2000 angesichts <strong>der</strong> Flexibilität im Umgang<br />
mit Zugriffsberechtigungen, <strong>der</strong> relativ einfachen Administration <strong>der</strong> Benutzer und<br />
ihrer Rechte, und sicherlich auch aufgrund <strong>der</strong> Bekanntheit und Benutzerfreundlichkeit ein<br />
häufig eingesetztes Betriebssystem.<br />
3.5.4 Lotus Notes<br />
Lotus Notes ist eine Anwendungssoftware zur Unterstützung <strong>der</strong> Bürokommunikation, die<br />
vor allem für die E-Mail-Kommunikation eingesetzt wird. Es handelt sich dabei um ein<br />
System, das auf <strong>der</strong> Client-Server-Architektur basiert und aus mindestens einem Domino<br />
Server, das ist <strong>der</strong> Applikationsserver, und mehreren Client-Systemen besteht. Auf eine<br />
Notes-Datenbank kann von einem Notes-Client aus zugegriffen werden. Aufgrund <strong>der</strong><br />
zunehmenden Verwendung von Internet-Technologien in Unternehmensnetzwerken wurde<br />
durch die jüngsten Versionen von Lotus Notes eine konsequente Öffnung in Richtung<br />
Internet betrieben. Aus diesem Grund kann auch ein Web-Browser zum Zugriff auf eine<br />
Notes-Datenbank genutzt werden.<br />
Die Authentifizierung von Notes-Benutzern wird mit Hilfe eines Public-Key-Verfahrens,<br />
wobei es sich um einen Verschlüsselungsmechanismus handelt, bei dem ein öffentlicher,<br />
also allgemein bekannter Schlüssel, verwendet wird, durchgeführt. Die Notes-Zertifikate<br />
und Schlüssel werden in <strong>der</strong> sog. Notes-ID gespeichert. Um auf die in <strong>der</strong> Notes-ID gespeicherten<br />
Informationen zugreifen zu können, muss <strong>der</strong> Benutzer das Notes-ID-<br />
Passwort angeben, da die Daten mit dem Passwort verschlüsselt in <strong>der</strong> Notes-ID abgelegt<br />
sind. Der Benutzer authentifiziert sich mit dem Passwort also gegenüber <strong>der</strong> Notes-ID,<br />
<strong>der</strong>en Daten dann vom Notes-Client genutzt werden, um den Benutzer gegenüber dem<br />
Notes-Server zu authentifizieren. Weitere Schutzmechanismen von Lotus Notes sind eine<br />
auf Zugriffslisten basierende Zugriffskontrolle und unterschiedliche Verfahren und Mechanismen,<br />
um die Vertraulichkeit von Daten zu gewährleisten, wie etwa verschiedene<br />
kryptographische Verfahren.<br />
32
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Die Internet-Schnittstelle <strong>der</strong> Software setzt auf etablierte Standards, sodass die einfache<br />
Integration und Erweiterbarkeit erreicht wird.<br />
Fünfrocken kommt in seiner Untersuchung zu dem Schluss, dass <strong>der</strong> direkte, externe<br />
Web-Zugriff auf das produktive Notes-System im internen Netz über das Internet aus Sicherheitsgründen<br />
nicht empfehlenswert sei, und er geht sogar soweit, dringend von<br />
<strong>der</strong>artigen Nutzungen abzuraten [Fünf01]. Bezogen auf die betriebsinterne Kommunikation<br />
kann Lotus Notes jedoch als durchaus sicher bezeichnet werden, speziell was die<br />
Benutzerzugriffe betrifft. In Verbindung mit <strong>der</strong> externen Kommunikation bleibt das von<br />
Windows bekannte Problem <strong>der</strong> böswilligen Programme, wogegen man sich auch hier<br />
geson<strong>der</strong>t schützen muss.<br />
33
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
4 MODELLANSATZ: Systematische <strong>Vergabe</strong> von<br />
Benutzerzugriffsberechtigungen<br />
4.1 Ziel und Vorgehen<br />
Die Zugriffskontrolle nimmt innerhalb eines Unternehmens eine wichtige Rolle im Zusammenhang<br />
mit den Faktoren Datenschutz und Datensicherheit ein. In jedem Unternehmen<br />
müssen den MitarbeiterInnen die nötigen Berechtigungen für die betrieblich genutzten<br />
Informationssysteme erteilt werden. Da in einem Betrieb meist mehrere unterschiedliche<br />
Informationssysteme, wie z. B. Betriebssysteme, betriebliche Standardsoftware, Kommunikationsapplikationen,<br />
usw. zum Einsatz kommen, entsteht häufig die Notwendigkeit, für<br />
die verschiedenen Systeme indiviuell die Zugriffsberechtigungen zu erteilen.<br />
Mit dem nachfolgend schrittweise erstellten und erläuterten Modell wird versucht, eine<br />
Möglichkeit darzustellen, um die erfor<strong>der</strong>lichen Benutzerzugriffsberechtigungen innerhalb<br />
eines Unternehmens effizient vergeben und zudem gewährleisten zu können, dass die<br />
Zugriffe auf sämtliche Informationssysteme eines Unternehmens unter Zugrundelegung<br />
dieses einen Modells verwaltet werden können.<br />
Der Modellansatz setzt sich aus den folgenden fünf Schritten zusammen, die im Anschluss<br />
detailliert behandelt werden:<br />
Schritt 1 Modellierung <strong>der</strong> Geschäftsprozesse<br />
Schritt 2 Ableitung <strong>der</strong> Informationsprozesse<br />
Schritt 3 Bilden von Berechtigungsgruppen<br />
Schritt 4 Erzeugen von Benutzergruppen<br />
Schritt 5 Verknüpfen von Berechtigungsgruppen und Benutzergruppen<br />
Abb. 5: Die fünf Schritte des Modellansatzes<br />
Die Einrichtung <strong>der</strong> Benutzerzugriffsberechtigungen innerhalb eines Unternehmens gemäß<br />
dem vorliegenden Modellansatz soll die in <strong>der</strong> folgenden Abbildung dargestellten<br />
Eigenschaften einer betrieblichen Zugriffskontrolle sicherstellen:<br />
34
SystemübergreifendeEinsetzbarkeit<br />
Abb. 6: Angestrebte Eigenschaften des Zugriffsschutzes<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Systematisches<br />
Vorgehen<br />
Zugriffskontrolle <br />
Wartungsfreundlichkeit<br />
Systematisches Vorgehen<br />
Ein systematisches Vorgehen bei <strong>der</strong> <strong>Vergabe</strong> <strong>der</strong> Benutzerzugriffsberechtigungen samt<br />
einer durchgehenden Dokumentation soll die einfache Nachvollziehbarkeit des Zugriffsschutzes<br />
ermöglichen, und auch die Voraussetzungen für die beiden Eigenschaften<br />
Vollständigkeit und Wartungsfreundlichkeit schaffen.<br />
Vollständigkeit<br />
Durch eine vollständige und umfassende <strong>Vergabe</strong> sämtlicher erfor<strong>der</strong>licher Zugriffsberechtigungen<br />
sollen langwierige Nacharbeiten und häufige Ergänzungen vermieden<br />
werden.<br />
Wartungsfreundlichkeit<br />
Eine entsprechende Wartungsfreundlichkeit <strong>der</strong> Zugriffskontrolle ist notwendig, um anfallende<br />
Än<strong>der</strong>ungen des Systems mit geringem Aufwand bewerkstelligen zu können.<br />
Systemübergreifende Einsetzbarkeit<br />
Der Modellansatz und <strong>der</strong> damit entwickelte Zugriffsschutz sollen sämtliche Softwarekomponenten<br />
eines Unternehmens abdecken.<br />
4.2 Die fünf Schritte des Modells<br />
Vollständigkeit<br />
4.2.1 Schritt 1: Modellierung <strong>der</strong> Geschäftsprozesse<br />
Um alle notwendigen Zugriffsberechtigungen für sämtliche Bereiche eines Unternehmens<br />
lückenlos erfassen zu können, werden die Geschäftsprozesse des Qualitätsmanagements<br />
als Grundlage für den Modellansatz herangezogen. Nachfolgend wird beispielhaft ein Geschäftsprozess<br />
dargestellt, <strong>der</strong> u. a. als Basis für die <strong>Vergabe</strong> <strong>der</strong> Zugriffsberechtigungen<br />
dienen soll.<br />
35
Bestellung<br />
schreiben<br />
Auftrag prüfen<br />
Fertigung<br />
planen<br />
Fertigungsplan<br />
Kunde<br />
Kundenbestellung<br />
Vertrieb<br />
Kunde<br />
Artikel<br />
Fertigung<br />
Arbeitsplan<br />
Fertigung<br />
Qualitätssicherung <br />
Qualitätsberichte<br />
Versand<br />
Abb. 7: Geschäftsprozess „Bearbeitung eines Kundenauftrags“<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Artikel fertigen<br />
Artikel versenden<br />
Ware annehmen<br />
Lieferant<br />
Auftrag abwickeln<br />
Bestellung<br />
schreiben<br />
Lieferant<br />
Zahlung<br />
FIBU<br />
Lieferantenbestellung<br />
Einkauf Lieferant<br />
Versandauftrag Artikellieferung<br />
Kunde<br />
Kunde<br />
Artikel prüfen<br />
Bezahlen<br />
Kundenzahlung<br />
Arbeitsplan<br />
Artikel Auftragsdokumente<br />
Artikel<br />
Geld annehmen <br />
Auftragsdokumente<br />
Geld annehmen<br />
Bezahlen<br />
Kunde<br />
FIBU<br />
36
Funktion<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Organisationseinheit<br />
Leistung<br />
Umfelddaten<br />
Logischer „UND“-Konnektor<br />
Funktionsfluss<br />
Organisationsfluss<br />
Informationsfluss<br />
Informationsdienstleistungsfluss<br />
Sachleistungsfluss<br />
Abb. 8: Legende zum Geschäftsprozess „Bearbeitung eines Kundenauftrags<br />
Die modellierten Geschäftsprozesse eines Unternehmens müssen einen hohen Detaillierungsgrad<br />
aufweisen, damit sie als Grundlage für die <strong>Vergabe</strong> <strong>der</strong> Zugriffsberechtigungen<br />
dienen können. Es müssen alle Prozesse eines Betriebes auf allen Ebenen und in allen<br />
Bereichen detailliert dargestellt werden.<br />
4.2.2 Schritt 2: Ableitung <strong>der</strong> Informationsprozesse<br />
Im nächsten Schritt des Modellansatzes werden aus allen Geschäftsprozessen die entsprechenden<br />
Informationsprozesse abgeleitet, um dadurch die auftretenden<br />
Informationsflüsse und die Informationsobjekte, die durch das Ausführen <strong>der</strong> verschiedenen<br />
Funktionen benötigt werden, zu veranschaulichen. Die Informationsprozesse<br />
enthalten dabei nicht die einzelnen Zugriffsberechtigungen auf Informationsobjekte, usw.,<br />
da dies die Überschaubarkeit <strong>der</strong> Prozesse wohl nahezu unmöglich würde. Die Informationsprozesse<br />
sollen in erster Linie als Hilfestellung für die weitere Vorgehensweise im<br />
Modell dienen.<br />
Der Informationsprozess zum dargestellten Geschäftsprozess einer Kundenauftragsbearbeitung<br />
könnte dann folgen<strong>der</strong>maßen aussehen:<br />
37
Kundenbestellung<br />
Bestellung<br />
schreiben<br />
Bestell-<br />
daten<br />
Kundenauftrag<br />
Auftrag<br />
prüfen<br />
Auftrags-<br />
daten<br />
Fertigungsplan<br />
Fertigung<br />
planen<br />
Bonität<br />
Lagerbestand<br />
Materialbedarf<br />
Bestelldaten<br />
Arbeitsgang-<br />
daten Fertigungsdaten<br />
Arbeitsplan<br />
Kundenzahlung<br />
Fertigungs-<br />
daten<br />
Auftragsdokumente<br />
Zahlungsdaten<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Fertigungsdaten<br />
Rechnungs-<br />
betrag<br />
Abb. 9: Informationsprozess zur „Bearbeitung eines Kundenauftrags“<br />
Name<br />
Funktion<br />
Name<br />
Kunde<br />
Artikel<br />
Lieferantenbestell.<br />
Bestellung<br />
schreiben<br />
Materialdaten<br />
Lieferantendaten<br />
Informationsdienstleistungsobjekt<br />
Sonstiges Informationsobjekt<br />
Informationsfluss<br />
Versandauftrag<br />
Artikel<br />
versenden<br />
Kundenkonto<br />
Abb. 10: Legende zum Informationsprozess „Kundenauftragsbearbeitung“<br />
Prüfdaten<br />
Material<br />
Lieferant<br />
Qualitätsberichte<br />
Artikel<br />
prüfen<br />
38
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
In den Informationsprozessen werden zwar die Informationsobjekte und die Informationsflüsse<br />
zwischen den einzelnen Funktionen <strong>der</strong> Geschäftsprozesse sichtbar, sie enthalten<br />
jedoch noch keine Informationen über die jeweils benötigten Zugriffsberechtigungen. Die<br />
Berechtigungen, die erfor<strong>der</strong>lich sind, um auf die benötigten Informationsobjekte zugreifen<br />
und Operationen auf ihnen ausführen zu können, werden deshalb im nächsten Schritt<br />
erfasst.<br />
4.2.3 Schritt 3: Bilden von Berechtigungsgruppen<br />
Hier werden für jede Funktion eines jeden Geschäftsprozesses alle Zugriffsberechtigungen,<br />
die man benötigt, um die betreffende Funktion ausführen zu können, in einer Tabelle,<br />
o<strong>der</strong> noch besser in einer eigens dafür angelegten Datenbank, erfasst. Das Anlegen einer<br />
Datenbank soll eine hohe Wartungsfreundlichkeit <strong>der</strong> Berechtigungsgruppen und ihrer<br />
Inhalte ermöglichen. Die Zugriffsberechtigungen werden in Form von Transaktionen, Berichten,<br />
Datenbankzugriffen, u. dgl. und nach den eingesetzten Softwareprodukten<br />
(Standardsoftware-Applikationen, Betriebssystemebene, usw.) festgehalten. Bei Bedarf<br />
sind pro Berechtigung auch allenfalls erfor<strong>der</strong>liche Zugriffsbeschränkungen durch Attribute,<br />
wie lesen, schreiben, löschen, än<strong>der</strong>n, usw., in die Liste <strong>der</strong> Zugriffsberechtigungen<br />
aufzunehmen.<br />
Die Summe <strong>der</strong> Zugriffsberechtigungen samt zugehöriger Attribute ergibt pro Funktion<br />
eine Berechtigungsgruppe, woraus folgende Darstellung resultiert:<br />
z1 z2 ....... zn<br />
Abb. 11: Von <strong>der</strong> Funktion zur Berechtigungsgruppe<br />
Es gilt folgendes:<br />
Funktion<br />
Berechtigungsgruppe<br />
- F = Summe <strong>der</strong> Funktionen<br />
- B = Summe <strong>der</strong> Berechtigungsgruppen<br />
- Z = Summe <strong>der</strong> Zugriffsberechtigungen<br />
- A = Summe <strong>der</strong> Attribute<br />
39
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Für eine Funktion f!F und eine Berechtigungsgruppe b!B gilt dann weiters:<br />
- f ! b<br />
- b = {z1, z2, ..., zn} wobei gilt: z!Z und b " 0; eine Berechtigungsgruppe muss<br />
mindestens eine Zugriffsberechtigung enthalten;<br />
- zn = { zn # (a1 – an)} für alle z!Z und a!A<br />
Um zwischen den Zugriffsberechtigungen für die verschiedenen Softwareprodukte unterscheiden<br />
zu können, wird folgendes vereinbart:<br />
- Z = Summe <strong>der</strong> Zugriffsberechtigungen z <strong>der</strong> Software $,<br />
- Y = Summe <strong>der</strong> Zugriffsberechtigungen y <strong>der</strong> Software %,<br />
- X = Summe <strong>der</strong> Zugriffsberechtigungen x <strong>der</strong> Software &, usw.<br />
Eine mögliche Ausnahme zur Bildung <strong>der</strong> Berechtigungsgruppen besteht dann, wenn es<br />
die individuelle, betriebliche Organisation erfor<strong>der</strong>lich macht, dass auch einzelne Berechtigungsgruppen<br />
benötigt werden, die nicht direkt aus Funktionen ableitbar sind. Darunter<br />
könnten beispielsweise Berechtigungsgruppen für die Geschäftsleitung fallen, sofern diese<br />
nicht durch die Geschäftsprozesse abgedeckt sind. Diese Berechtigungsgruppen<br />
werden dann geson<strong>der</strong>t, also ohne zugrundeliegende Funktion, erstellt und mit den entsprechenden<br />
Zugriffsberechtigungen ausgestattet. In die Reihe <strong>der</strong> Son<strong>der</strong>fälle kann<br />
zusätzlich noch eine Berechtigungsgruppe aufgenommen werden, die später allen Benutzern<br />
bzw. Mitarbeitern zur Verfügung stehen soll. In eine <strong>der</strong>artige Berechtigungsgruppe<br />
werden beispielsweise Zugriffsrechte auf Informationsdatenbanken u. ä. aufgenommen.<br />
Um das mit Hilfe einer Geschäftsprozess- und davon abgeleiteter Informationsprozessmodellierung<br />
vorgestellte Beispiel weiter fortzusetzen, sind anschließend einige<br />
Berechtigungsgruppen, die aus den Funktionen des Informationsprozesses abgeleitet<br />
werden können, angeführt. Zu je<strong>der</strong> Berechtigungsgruppe sind dabei einige Beispiele <strong>der</strong><br />
enthaltenen Zugriffsberechtigungen angeführt:<br />
Berechtigungsgruppe Inhalt <strong>der</strong> Berechtigungsgruppe<br />
Auftragsprüfung<br />
Fertigungsplanung<br />
Lieferantenbestellung<br />
Artikelprüfung<br />
Artikelversand<br />
Leseberechtigungen für Bestelldaten und Kundenstammdaten,<br />
Zugriff auf Lager- und<br />
Materialbestände,...<br />
Leseberechtigungen für Auftragsdaten und Daten<br />
zu Lieferantenbestellungen, Rechte zum<br />
Erstellen von Arbeitsplänen, Stücklisten und<br />
Auftragsdokumenten,...<br />
Zugriffsrechte auf Materialdaten, Leseberechtigung<br />
für Lagerbestände, Zugriff auf<br />
Lieferantenstammdaten,...<br />
Leserechte für Fertigungsdaten, Berechtigungen<br />
zum Erstellen und Verän<strong>der</strong>n von Qualitätsbe-<br />
richten,...<br />
Leserechte für Fertigungsdaten, Rechte zum<br />
Erstellen <strong>der</strong> Versandpapiere,...<br />
Abb. 12: Berechtigungsgruppen zum Informationsprozess „Kundenauftragsbearbeitung“<br />
40
4.2.4 Schritt 4: Erzeugen von Benutzergruppen<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
In diesem Arbeitsschritt gilt es, auf <strong>der</strong> Basis des betrieblichen Organisationsdiagramms<br />
Benutzergruppen zu bilden, damit den Mitarbeitern des Unternehmens die benötigten<br />
Zugriffsberechtigungen nicht einzeln zugewiesen werden müssen. Sie sollen demnach<br />
durch Zuweisung zu einer o<strong>der</strong> mehrerer Benutzergruppen die entsprechenden Berechtigungen<br />
erhalten.<br />
Ein einfaches Beispiel für ein betriebliches Organisationsdiagramm kann z. B. folgen<strong>der</strong>maßen<br />
aussehen:<br />
Finanzbuchhaltung <br />
Personalverrechnung<br />
EDV-Abteilung<br />
Abb. 13: Organisationsdiagramm<br />
Einkauf<br />
Vertrieb<br />
Material- und<br />
Lagerwirtschaft<br />
Geschäftsleitung<br />
Produktion Qualitätssicherung <br />
Fertigungsplanung<br />
Controlling Versand<br />
Fertigungssteuerung<br />
Marketing<br />
Montage<br />
Forschung &<br />
Entwicklung<br />
Instandhaltung<br />
Das betriebliche Organisationsdiagramm eignet sich umso besser für die Erzeugung von<br />
Benutzergruppen, je funktionaler, d. h. den funktionalen Abteilungen des Unternehmens<br />
entsprechend, es abgebildet ist.<br />
Aus den vorliegenden Abteilungen werden nun Benutzergruppen abgeleitet. In die entstanden<br />
Benutzergruppen werden dann die MitarbeiterInnen des Unternehmens<br />
eingetragen. Dabei ist es möglich, dass ein Mitarbeiter in mehrere Benutzergruppen eingetragen<br />
wird.<br />
41
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Die beschriebene Bildung von Benutzergruppen lässt sich folgen<strong>der</strong>maßen veranschaulichen:<br />
Dabei gilt:<br />
p1 p2 ............ pn<br />
Abb. 14: Von <strong>der</strong> Abteilung zur Benutzergruppe<br />
- D = Summe <strong>der</strong> Abteilungen<br />
- U = Summe <strong>der</strong> Benutzergruppen<br />
- P = Summe <strong>der</strong> Personen (MitarbeiterInnen)<br />
Für eine Abteilung d!D und eine Benutzergruppe u!U gilt weiters:<br />
- d ! u1, u2,..., un<br />
- u = { p1, p2,..., pn}; p!P<br />
Abteilung<br />
Benutzergruppe<br />
Auf <strong>der</strong> Basis einer Abteilung d können im Bedarfsfall auch mehrere, unterschiedliche<br />
Benutzergruppen gebildet werden. Dieser Fall kann eintreten, wenn innerhalb einer funktionalen<br />
Abteilung mehrere Gruppen existieren, zwischen denen eine strikte<br />
Aufgabentrennung besteht. Ein Beispiel für eine <strong>der</strong>artige Abteilung ist in vielen Fällen in<br />
<strong>der</strong> Finanzbuchhaltung zu finden, in <strong>der</strong> häufig zwischen Debitoren-SachbearbeiterInnen,<br />
Kreditoren-SachbearbeiterInnen, AnlagenbuchhalterInnen, usw. unterschieden wird.<br />
Aus dem o. a. Beispiel für ein betriebliches Organisationsdiagramm gehen u. a. die folgenden<br />
Benutzergruppen hervor:<br />
- Vertrieb<br />
- Fertigungsplanung<br />
- Einkauf<br />
- Versand<br />
- Qualitätssicherung, usw.<br />
42
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
4.2.5 Schritt 5: Verknüpfen von Berechtigungsgruppen und Benutzergruppen<br />
Im letzten Schritt muss schließlich noch dafür gesorgt werden, dass den definierten Benutzergruppen<br />
die nötigen Zugriffsberechtigungen zugeordnet werden. Die<br />
Benutzergruppen werden zu diesem Zweck mit den entsprechenden Berechtigungsgruppen<br />
in Beziehung gebracht. Zum Erfassen und Darstellen <strong>der</strong> erfor<strong>der</strong>lichen Zuweisungen<br />
zwischen Berechtigungsgruppen und Benutzergruppen eignet sich die Matrixdarstellung.<br />
Dabei werden, wie aus <strong>der</strong> folgenden Abbildung ersichtlich, zeilenweise die Berechtigungsgruppen<br />
und spaltenweise die Benutzergruppen eingetragen.<br />
Benutzer-<br />
gruppen<br />
Berechtigungsgruppen<br />
Vertrieb<br />
Fertigungsplanung<br />
Einkauf<br />
Versand<br />
Qualitätssicherung<br />
Auftragsprüfung x x<br />
Fertigungsplanung x<br />
Lieferantenbestellung x<br />
Artikelprüfung x<br />
Artikelversand x<br />
b6<br />
b7<br />
b8<br />
b9<br />
b10<br />
b11<br />
b12<br />
b13<br />
Abb. 15: Matrixdarstellung <strong>der</strong> Zuweisung von Berechtigungs- und Benutzergruppen<br />
Danach werden alle Zuordnungen zwischen Berechtigungsgruppen und Benutzergruppen<br />
durch das Setzen eines bestimmten Merkmals (hier: x) an <strong>der</strong> entsprechenden Position in<br />
<strong>der</strong> Matrix gekennzeichnet. Die in <strong>der</strong> dargestellten Matrix enthaltenen Berechtigungs-<br />
und Benutzergruppen entstammen dem durchgehenden Beispiel <strong>der</strong> „Kundenauftragsbearbeitung“.<br />
Anhand <strong>der</strong> so entstandenen, zusammengefassten Darstellung <strong>der</strong> Zuordnungen zwischen<br />
Berechtigungs- und Benutzergruppen können diese während <strong>der</strong> praktischen<br />
Modellumsetzung in den einzelnen Softwareapplikationen vorgenommen werden.<br />
u6<br />
u7<br />
u8<br />
u9<br />
u10<br />
43
4.3 Das Gesamtmodell<br />
Der gesamte Modellansatz sieht folgen<strong>der</strong>maßen aus:<br />
Funktion<br />
Berechtigungsgruppe<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Abteilung<br />
Benutzergruppe<br />
z1 z2 .......... zn p1 p2 .......... pn<br />
z1 - zn: Zugriffsberechtigungen inklusive Attribute<br />
p1 - pn: Personen (= MitarbeiterInnen)<br />
Abb. 16: Modellansatz zur systematischen <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Das entstandene Modell setzt sich aus den beiden Darstellungen für die Erzeugung <strong>der</strong><br />
Berechtigungsgruppen einerseits und für das Anlegen <strong>der</strong> Benutzergruppen an<strong>der</strong>erseits<br />
sowie aus <strong>der</strong>en gegenseitige Zuweisung zusammen.<br />
Der gestrichelte Rahmen, <strong>der</strong> in <strong>der</strong> Modelldarstellung Berechtigungsgruppe und Benutzergruppe<br />
einschließt, bezieht sich dabei bereits auf die modellbasierte Zuweisung <strong>der</strong><br />
Zugriffsberechtigungen in den einzelnen Softwareapplikationen und Betriebssystemen.<br />
Während es bei <strong>der</strong> Informationssammlung und –aufbereitung im Rahmen <strong>der</strong> <strong>Vergabe</strong><br />
<strong>der</strong> Zugriffsberechtigungen zweckmäßig ist, sowohl Berechtigungsgruppen als auch Benutzergruppen<br />
anzulegen, bieten nicht alle Betriebssysteme und Softwareprodukte die<br />
Möglichkeit, beide Arten von Gruppen zu erzeugen und diese anschließend einan<strong>der</strong> zuzuweisen.<br />
Bietet nun ein System lediglich die Möglichkeit, Zugriffsberechtigungen in einer Berechtigungsgruppe<br />
zu erfassen, dann werden die BenutzerInnen dieses Systems ebenfalls<br />
diesen Berechtigungsgruppen zugewiesen.<br />
Wenn ein System hingegen nur die Erzeugung von Benutzergruppen erlaubt, was auf<br />
viele Betriebssysteme zutrifft, dann werden die einzelnen Zugriffsberechtigungen in den<br />
Benutzergruppen eingerichtet.<br />
44
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Trotz <strong>der</strong> erwähnten Einschränkungen, die durch Software- und Betriebssysteme häufig<br />
bestehen, gewährleistet <strong>der</strong> beschriebene Modellansatz durch die enge Bindung <strong>der</strong><br />
Zugriffsberechtigungen an die betrieblichen Funktionen und durch die Ableitung <strong>der</strong> Benutzergruppen<br />
aus den organisatorischen Einheiten ein hohes Maß an<br />
Nachvollziehbarkeit und Wartungsfreundlichkeit. Zudem werden auch die restlichen, einleitend<br />
angeführten Eigenschaften einer Zugriffskontrolle, nämlich die<br />
systemübergreifende Verwendbarkeit und die Vollständigkeit in <strong>der</strong> Erfassung und Verteilung<br />
<strong>der</strong> Zugriffsberechtigungen weitestgehend durch das Modell sichergestellt.<br />
45
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
5 PROJEKT: <strong>Vergabe</strong> <strong>der</strong> <strong>SAP</strong> R/3-<br />
Benutzerberechtigungen in <strong>der</strong> Hella Fahrzeugteile<br />
Austria GmbH & Co KG<br />
5.1 Das Unternehmen<br />
5.1.1 Geschichte und Tätigkeitsfeld<br />
Die Hella Fahrzeugteile Austria GmbH & Co KG ist ein Produktions- und Handelsbetrieb<br />
in 7503 Großpetersdorf, Fabriksgasse 2, im österreichischen Burgenland. Die Hella Fahrzeugteile<br />
Austria (HFA) ist ein Unternehmen <strong>der</strong> Hella-Gruppe, einer weltweiten<br />
Organisation, die alle Hella-Nie<strong>der</strong>lassungen für Produktion, Forschung und Entwicklung,<br />
Erstausrüstung und Handel sowie alle Handelsgesellschaften beinhaltet und insgesamt<br />
ungefähr 22.000 Mitarbeiter beschäftigt. Die HFA glie<strong>der</strong>t sich in vier Geschäftseinheiten,<br />
in die Geschäftseinheit Großpeterdorf, die Geschäftseinheit <strong>Wien</strong>, die Geschäftseinheit<br />
Verwaltung und die Geschäftseinheit Technik. Mit weltweit über 30 Fertigungsstätten ist<br />
die Unternehmensgruppe ein global operieren<strong>der</strong> Partner <strong>der</strong> Automobilindustrie. Vertriebsgesellschaften<br />
und –partner weltweit beliefern Automobilhersteller und den<br />
Fachhandel rund um den Globus.<br />
Die Unternehmensgruppe Hella erzeugt mo<strong>der</strong>ne und hochwertige Geräte und Systeme<br />
<strong>der</strong> Fahrzeugbeleuchtung. Sowohl <strong>der</strong> nationale und internationale Handelsmarkt, als<br />
auch eine Reihe namhafter Fahrzeughersteller werden von Hella mit Heck- und Signalleuchten,<br />
Arbeitsscheinwerfern, Zusatz-, Nebel- und Fernscheinwerfern sowie mit einem<br />
breiten Zubehör- und Ersatzteilprogramm beliefert.<br />
Die heutige Hella Fahrzeugteile Austria wurde im Jahr 1933 als Fabrik für Metallverarbeitung<br />
in <strong>Wien</strong> gegründet. 1958 erfor<strong>der</strong>te die Expansion des Betriebes eine Verlegung <strong>der</strong><br />
Verwaltung und <strong>der</strong> Produktion nach Großpetersdorf. In einer mo<strong>der</strong>nen Fabrik stehen<br />
heute rund 10.100 m! für Verwaltung, technische Büros, Fertigung und Lager zur Verfügung.<br />
Die Belegschaft des Unternehmens umfasst insgesamt 277 Mitarbeiter (Stand vom<br />
28. Februar 2002). 1995 wurde die HFA nach ISO9001 und 1997 nach QS9000 zertifiziert.<br />
Im Mai 2000 bestätigte <strong>der</strong> TÜV Österreich die erfolgreiche Einführung und<br />
Anwendung eines Umweltmanagementsystems nach EN ISO14001.<br />
Als eines <strong>der</strong> ersten mittelständischen Unternehmen in Österreich führte die HFA im Jahr<br />
1997 <strong>SAP</strong> R/3 für die Unternehmensorganisation ein.<br />
5.1.2 Eingesetzte Hardware<br />
In <strong>der</strong> HFA werden insgesamt elf Windows NT-Server eingesetzt, mit denen die PCs <strong>der</strong><br />
EDV-Anwen<strong>der</strong> über ein Netzwerk verbunden sind o<strong>der</strong> bei Bedarf verbunden werden<br />
können. Ein Server befindet sich in <strong>Wien</strong> und die restlichen zehn Server stehen in Großpetersdorf,<br />
wo auch die gesamte Systemadministration stattfindet. Die Geschäftseinheit<br />
<strong>Wien</strong> ist über eine Standleitung mit Großpetersdorf verbunden. Außer Servern, PCs und<br />
Kommunikationsleitungen kommen u. a. Workstations in <strong>der</strong> technischen Konstruktion,<br />
Drucker und Plotter zum Einsatz.<br />
46
5.1.3 Eingesetzte Software<br />
Die folgenden Softwareprodukte finden in <strong>der</strong> HFA Verwendung:<br />
- <strong>SAP</strong> R/3, Version 4.6B (Frontend-<strong>SAP</strong>GUI 4.6D)<br />
- Lotus Notes, Version 4.6a<br />
- CATIA<br />
- Windows 2000<br />
- Microsoft Office 2000<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Lotus Notes wird für die interne und externe Kommunikation via E-Mail eingesetzt, und<br />
auch für das Abwickeln von Workflows und das betriebsinterne Meldewesen. CATIA wird<br />
in <strong>der</strong> technischen Konstruktion zum Erstellen von Konstruktionszeichnungen verwendet<br />
und läuft auf dem Betriebssystem UNIX. Auf den PCs kommen außer dem<br />
Betriebssystem Windows 2000 vereinzelt auch noch Windows 98 o<strong>der</strong> Windows 95 zum<br />
Einsatz. Zusätzlich zur angeführten Software werden noch eine Anzahl weiterer<br />
Anwendungen, wie etwa Antivirenprogramme, <strong>der</strong> Adobe Acrobat Rea<strong>der</strong>,<br />
Bildbearbeitungssoftware, eine Faxanwendung, usw. verwendet.<br />
Wie bereits erwähnt, wurde <strong>SAP</strong> 1997 in <strong>der</strong> Hella Fahrzeugteile Austria eingeführt. <strong>SAP</strong><br />
R/3 läuft in <strong>der</strong> HFA unter Windows NT und auf einer Oracle Datenbank. Seit 1. Januar<br />
1997 werden die Bausteine für das Finanzwesen und die Personalwirtschaft, und seit 1.<br />
Juni 1997 die Bausteine für Vertrieb, Materialwirtschaft, Produktionsplanung, Controlling<br />
und das Workflow-Management im Betrieb eingesetzt. Das Qualitätsmanagement wird<br />
noch nicht in <strong>SAP</strong> abgewickelt, befindet sich <strong>der</strong>zeit aber in <strong>der</strong> Einführungsphase. Ein<br />
weiterer <strong>SAP</strong>-Baustein, <strong>der</strong> in Zukunft genutzt werden soll, ist jener für die Instandhaltung.<br />
Hier hat die Einführungsphase aber noch nicht begonnen.<br />
In <strong>der</strong> HFA wird mit zwei <strong>SAP</strong>-Systemen gearbeitet. Zum einen ein Testsystem, das Testzwecken<br />
dienen soll, und in dem auch unterschiedliche Programm- bzw.<br />
Einstellungsän<strong>der</strong>ungen vorgenommen werden. Derartige Än<strong>der</strong>ungen müssen dann in<br />
das zweite System, das <strong>SAP</strong>-Produktivsystem, transportiert und im Produktivsystem importiert<br />
werden, um auch dort aktiv zu werden. Das <strong>SAP</strong>-Produktivsystem dient <strong>der</strong><br />
eigentlichen, täglichen Arbeitsabwicklung.<br />
Die Administration von <strong>SAP</strong> R/3 ist in <strong>der</strong> HFA Aufgabe <strong>der</strong> EDV-Abteilung, jedoch mit <strong>der</strong><br />
Ausnahme, dass laufende Anpassungen, das sog. Customizing, nicht durch die EDV-<br />
Abteilung, son<strong>der</strong>n von sog. Keyusern erledigt werden. Die Keyuser sind HFA-<br />
MitarbeiterInnen aus den unterschiedlichen Abteilungen, die Anpassungen für die betreffende<br />
Abteilung und im entsprechenden <strong>SAP</strong>-Baustein vornehmen. In <strong>der</strong> HFA üben<br />
insgesamt zwölf Mitarbeiter, d. s. jeweils ein o<strong>der</strong> zwei Mitarbeiter pro Baustein, die Funktion<br />
eines Keyusers aus.<br />
5.2 <strong>SAP</strong> R/3<br />
5.2.1 Allgemeines<br />
Der Softwarehersteller <strong>SAP</strong> wurde im Jahr 1972 in Walldorf, Deutschland, gegründet und<br />
besitzt mit 36% den größten Marktanteil im Marktsegment <strong>der</strong> betriebswirtschaftlichen<br />
Standardsoftware. <strong>SAP</strong> beschäftigt weltweit über 23.000 Mitarbeiter und erzielte im Jahr<br />
1999 einen Umsatz von 5,1 Mrd. EURO [Jahn01].<br />
47
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
„Grundgedanke bei <strong>der</strong> R/3 Software ist die funktionale Abdeckung aller wesentlichen<br />
Unternehmensanfor<strong>der</strong>ungen sowie die umfassende Integration betriebswirtschaftlicher<br />
Informationsverarbeitung [Dorn99, 125].“<br />
Abb. 5 zeigt den Startbildschirm <strong>der</strong> Frontend-Version 4.6D von <strong>SAP</strong> R/3 mit dem <strong>SAP</strong>-<br />
Menü im linken, oberen Bereich. Ganz oben befindet sich eine Menüzeile, über die, je<br />
nach aktuell aktiver Anwendung, verschiedene Funktionen aufgerufen werden können.<br />
Darunter finden sich zwei Zeilen mit Buttons, mit denen ebenfalls eine Reihe von Funktionen<br />
angewählt werden können. Zwischen den beiden Buttonreihen wird <strong>der</strong> Name <strong>der</strong><br />
jeweils aktuellen Transaktion angezeigt. Als Transaktionen werden die von <strong>SAP</strong> R/3 zur<br />
Verfügung gestellten Funktionen bezeichnet. Dazu gehören z. B. Transaktionen für die<br />
Auftragsanzeige, für die Buchung von Belegen und unzählige an<strong>der</strong>e. Zu je<strong>der</strong> Transaktion<br />
existiert ein Kürzel, <strong>der</strong> sog. Transaktionscode, <strong>der</strong> in <strong>der</strong> Regel aus vier o<strong>der</strong> fünf<br />
Zeichen besteht. Die Transaktionen können direkt durch Eingabe des Transaktionscodes<br />
in <strong>der</strong> Befehlszeile, die sich links in <strong>der</strong> ersten Buttonreihe befindet, aufgerufen werden,<br />
o<strong>der</strong> durch Doppelklicken auf die entsprechende Transaktion im <strong>SAP</strong>-Menü, das über<br />
viele Ebenen in Untermenüs verzweigt. Zusätzlich zu den Transaktionen gibt es in <strong>SAP</strong><br />
R/3 noch die Möglichkeit <strong>der</strong> Ausführung von sog. Reports, worunter eine Vielzahl zur<br />
Verfügung stehen<strong>der</strong> Berichte aus den unterschiedlichsten <strong>SAP</strong>-Bausteinen zu verstehen<br />
ist. <strong>SAP</strong> R/3 bietet verschiedene Bausteine für die unterschiedlichen Bereiche eines Unternehmens,<br />
wie beispielsweise die Finanzbuchhaltung, die Materialwirtschaft, usw. Diese<br />
Module mit den <strong>SAP</strong> Standardeinstellungen können durch entsprechendes Customizing<br />
an die individuellen, betrieblichen Gegebenheiten angepasst werden.<br />
Abb. 17: <strong>SAP</strong> R/3 Startbildschirm (Frontend-Version 4.6D)<br />
Das R/3-System stellt eine sog. Client-Server-Architektur dar und bietet die Möglichkeit,<br />
das System anhand einer dreistufigen Rechnerhierarchie zu verteilen. Ein zentraler<br />
Rechner fungiert dabei als Datenbankserver, auf dem jene Prozesse laufen, die das Datenbankservice<br />
darstellen. Zusätzlich ist dieser Rechner verantwortlich für die<br />
Durchführung von Datenbankän<strong>der</strong>ungen. Die eigentliche Anwendungslogik wird auf den<br />
48
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Anwendungs- o<strong>der</strong> Applikationsservern abgearbeitet. Mehrere solcher Applikationsserver<br />
können mit einem Datenbankserver verbunden sein. An jeden Applikationsserver lassen<br />
sich wie<strong>der</strong>um mehrere <strong>SAP</strong>-Frontends verbinden. Frontends sind Workstations o<strong>der</strong><br />
PCs, an denen die Benutzer arbeiten, und an denen alle Präsentationsaufgaben abgewickelt<br />
werden.<br />
5.2.2 Datenschutz und Sicherheit in <strong>SAP</strong> R/3<br />
Mit <strong>SAP</strong> R/3 werden zum Teil hochsensible personenbezogene Daten verarbeitet. Das<br />
System wird in vielen Staaten weltweit eingesetzt und muss unterschiedliche nationale<br />
Gesetze abbilden, insbeson<strong>der</strong>e im Bereich <strong>der</strong> Finanzbuchhaltung und Personalwirtschaft.<br />
Demzufolge muss es aber auch den Anfor<strong>der</strong>ungen <strong>der</strong> jeweils gültigen<br />
Datenschutzgesetze gerecht werden.<br />
<strong>SAP</strong> R/3 bietet einige Sicherheitsmechanismen für die Vertraulichkeit und Integrität <strong>der</strong><br />
Daten an, wie z. B. Authentisierung, Berechtigungskonzept, Protokollierung, Datenkomprimierung<br />
und Verschlüsselung, und zudem wird auch die sichere Einbindung in<br />
unterschiedliche Betriebssysteme, Datenbanken und Netzwerke ermöglicht.<br />
Die Authentisierung einer Person gegenüber dem System erfolgt durch eine Benutzerkennung<br />
und ein Passwort. Für jede Benutzerkennung kann ein Gültigkeitszeitraum<br />
angegeben werden, und es kann auch eine Mindestlänge für das Passwort im Bereich<br />
von drei bis acht Zeichen definiert werden. Zusätzlich kann <strong>der</strong> Administrator in einer Tabelle<br />
unzulässige Passwörter erfassen, wie z. B. Vornamen o<strong>der</strong> triviale Wörter. Es ist<br />
auch möglich, nach Ablauf einer frei wählbaren Tagesanzahl eine Passwortän<strong>der</strong>ung<br />
zwingend vorzuschreiben. Die Passwörter selbst werden als Hashwerte geschützt gespeichert.<br />
Es ist auch möglich, die Anzahl <strong>der</strong> fehlgeschlagenen Anmeldeversuche zu<br />
begrenzen und den Benutzer nach Erreichen <strong>der</strong> festgesetzten Grenze zu sperren. Die<br />
Benutzersperre kann durch den Systemadministrator wie<strong>der</strong> aufgehoben werden. Erfolglose<br />
Anmeldeversuche und Benutzersperren werden aufgezeichnet und es sind noch<br />
weitere, vielfältige Protokollierungen möglich. Außerdem kann eine Inaktivitätsdauer in<br />
Sekunden angegeben werden, nach <strong>der</strong>en Ablauf <strong>der</strong> entsprechende Benutzer automatisch<br />
vom System abgemeldet wird.<br />
Mit Hilfe <strong>der</strong> genannten Maßnahmen schafft <strong>SAP</strong> R/3 die Voraussetzungen, um das System<br />
den Sicherheitserfor<strong>der</strong>nissen eines Unternehmens anzupassen.<br />
5.2.3 Einführung in das Berechtigungskonzept von <strong>SAP</strong> R/3<br />
Mit Hilfe des R/3-Berechtigungskonzepts wird Einzelpersonen bzw. Mitarbeitergruppen<br />
die Ausführung von Transaktionen und Programmen erlaubt. Um eine Operation im <strong>SAP</strong>-<br />
System durchführen zu können, sind unter Umständen mehrere Berechtigungen erfor<strong>der</strong>lich,<br />
und die daraus resultierenden Zusammenhänge können sehr komplex werden. Um<br />
trotzdem ein überschaubares Verfahren anbieten zu können, das leicht zu handhaben ist,<br />
wurde das <strong>SAP</strong>-Berechtigungskonzept auf <strong>der</strong> Basis von Berechtigungsobjekten realisiert.<br />
Mehrere zu schützende Systemelemente bilden dabei ein Berechtigungsobjekt.<br />
Berechtigungsobjekte ermöglichen komplexe, an mehrere Bedingungen gebundene Prüfungen<br />
einer Berechtigung, die einem Benutzer erlaubt, eine Aktion durchzuführen. Ein<br />
Berechtigungsobjekt kann bis zu 10 Berechtigungsfel<strong>der</strong> umfassen, die in UND-<br />
Verknüpfung geprüft werden. Eine Berechtigung ist eine Kombination zulässiger Werte<br />
zu jedem Berechtigungsfeld eines Berechtigungsobjekts.<br />
49
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Jede Berechtigung bezieht sich auf genau ein Berechtigungsobjekt und definiert für jedes<br />
Berechtigungsfeld dieses Berechtigungsobjekts die erlaubte Wertemenge.<br />
Um einem Benutzer bestimmte Berechtigungen zu erteilen, müssen diese in seinen Benutzerstammsatz<br />
eingetragen werden. Der Benutzerstammsatz dient auch zur Anmeldung<br />
an das <strong>SAP</strong>-System. Da <strong>der</strong> Pflegeaufwand zu groß wäre, wenn einzelne Berechtigungen<br />
in den Benutzerstammsatz eingetragen würden, können Berechtigungen zu Berechtigungsprofilen<br />
zusammengefasst werden. Än<strong>der</strong>ungen an Zugriffsrechten werden in<br />
diesem Fall für alle Benutzer wirksam, in <strong>der</strong>en Benutzerstammsatz sich das entsprechende<br />
Profil befindet.<br />
Person Zugriffsberechtigungen<br />
Abb. 18: Berechtigungsvergabe in <strong>SAP</strong> R/3<br />
Berechtigungsprofile können sowohl manuell als auch automatisch erzeugt werden. Will<br />
man ein Profil automatisch erzeugen, dann muss zunächst eine Aktivitätsgruppe angelegt<br />
werden. In dieser Aktivitätsgruppe werden Transaktionen, Berichte und Web-Adressen<br />
in einem Benutzermenü zusammengefasst. Das Benutzermenü enthält die Aktivitäten, die<br />
eine Gruppe von Anwen<strong>der</strong>n für ihr Arbeitsumfeld benötigt. Zu einer Aktivitätsgruppe können<br />
automatisch Berechtigungen erzeugt werden, wobei die Feldinhalte <strong>der</strong><br />
Berechtigungsobjekte von <strong>SAP</strong> weitgehend voreingestellt sind. Die voreingestellten Werte<br />
können nachbearbeitet und leere Fel<strong>der</strong> ergänzt werden. Schließlich kann daraus mit Hilfe<br />
des Profilgenerators automatisch ein Berechtigungsprofil erzeugt werden, das dann<br />
bestimmten Benutzern zugeordnet werden kann.<br />
Im Laufe <strong>der</strong> anschließenden Projektbeschreibung wird auf genannte Komponenten, wie<br />
Aktivitätsgruppe, Berechtigungsprofil, Profilgenerator, usw., ausführlicher eingegangen.<br />
5.3 Das Projekt<br />
Benutzerstamm-<br />
satz<br />
5.3.1 Ausgangssituation<br />
Berechtigungsprofil<br />
(Aktivitätsgruppe)<br />
Bei <strong>der</strong> Einführung von <strong>SAP</strong> R/3 in <strong>der</strong> HFA wurde ein Teil <strong>der</strong> von <strong>SAP</strong> standardmäßig<br />
zur Verfügung gestellten Aktivitätsgruppen, die als Benutzerrollen bezeichnet werden, an<br />
die <strong>SAP</strong>-Benutzer zugewiesen. Im <strong>SAP</strong>-Standard finden sich mehr als 150 vordefinierte<br />
Benutzerrollen aus allen Anwendungsbereichen. Durch die Zuweisung <strong>der</strong> vordefinierten<br />
Benutzerrollen an die BenutzerInnen sollten diese bei <strong>der</strong> Anmeldung automatisch die für<br />
ihre tägliche Arbeit typischen Benutzermenüs erhalten sowie die Berechtigungen, die sie<br />
für diese Arbeit benötigen.<br />
Im Laufe <strong>der</strong> Zeit stellte sich jedoch heraus, dass die Benutzerrollen von <strong>SAP</strong> nur bedingt<br />
zum Einsatz in <strong>der</strong> HFA taugten, da immer wie<strong>der</strong> Berechtigungen benötigt wurden, die in<br />
den Standardprofilen nicht vorhanden waren.<br />
50
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Auf <strong>der</strong> an<strong>der</strong>en Seite zeigte sich, dass einige Zugriffsberechtigungen aus sensitiven Bereichen,<br />
wie etwa <strong>der</strong> Gehaltsverrechnung o<strong>der</strong> <strong>der</strong> Finanzbuchhaltung, in jenen<br />
Berechtigungsprofilen enthalten waren, die nicht den genannten Abteilungen zugeordnet<br />
wurden. Deshalb wurde begonnen, eigene Aktivitätsgruppen anzulegen und diese den<br />
BenutzerInnen zuzuordnen, wegen des dafür erfor<strong>der</strong>lichen, hohen Zeitaufwands wurde<br />
bislang aber kein umfassendes Projekt bezüglich <strong>der</strong> <strong>SAP</strong>-Zugriffsberechtigungen durchgeführt.<br />
Es mussten laufend neue Aktivitätsgruppen angelegt bzw. bestehende<br />
Aktivitätsgruppen um einzelne Transaktionen ergänzt werden.<br />
Schließlich wies auch eine unternehmensgruppeninterne Revision durch ein renommiertes<br />
Beratungsunternehmen darauf hin, dass die bestehende Berechtigungsvergabe in<br />
<strong>SAP</strong> einige Lücken aufwies, die so schnell wie möglich beseitigt werden sollten. Diese<br />
Beanstandung <strong>der</strong> Revision kann durchaus als endgültiger Auslöser dafür gesehen werden,<br />
dass innerhalb <strong>der</strong> HFA beschlossen wurde, ein Projekt durchzuführen, um <strong>SAP</strong>-<br />
Benutzerzugriffsberechtigungen zur Gänze neu zu vergeben.<br />
5.3.2 Aufgabenstellung<br />
Die Aufgabenstellung für das <strong>SAP</strong>-Berechtigungsprojekt wurde folgen<strong>der</strong>maßen formuliert:<br />
Sämtliche Benutzerberechtigungen in <strong>SAP</strong> sollten neu vergeben werden. Dabei sollten<br />
auch bestehende Aktivitätsgruppen berücksichtigt werden. Diese sollten auf ihre Eignung<br />
zur Weiterverwendbarkeit untersucht werden und bei entsprechen<strong>der</strong>, positiver Bewertung<br />
sollten sie überarbeitet und an die neuen Erfor<strong>der</strong>nisse angepasst werden. Außer<br />
<strong>der</strong> Neuvergabe <strong>der</strong> Berechtigungen sollte nach Projektabschluss auch gewährleistet<br />
sein, dass das entstandene Berechtigungskonzept einfach zu warten, und bei auftreten<strong>der</strong><br />
Notwendigkeit mit möglichst geringem Aufwand um einzelne Berechtigungen,<br />
Aktivitätsgruppen, usw. ergänzt werden konnte. Auch bei zukünftigen Personaleinstellungen<br />
und Austritten sollte das einfache und systematische Vergeben bzw. Löschen <strong>der</strong><br />
benötigten Benutzerzugriffsberechtigungen in <strong>SAP</strong> R/3 möglich sein.<br />
5.3.3 Planung<br />
Nachdem feststand, welche Ziele mit dem Projekt verfolgt werden sollten, wurden die einzelnen<br />
Schritte des Projekts und das genaue Vorgehen beim Vergeben <strong>der</strong> <strong>SAP</strong>-<br />
Zugriffsberechtigungen festgelegt. Man einigte sich darauf, mit Hilfe des Profilgenerators<br />
Aktivitätsgruppen anzulegen, die Transaktionen und Reports entsprechend <strong>der</strong> Angaben<br />
<strong>der</strong> Keyuser enthalten sollten. Den Keyusern wurde eine wichtige Aufgabe innerhalb des<br />
Projekts zugeteilt, denn sie sollten sowohl die nötigen Transaktionen und Reports für die<br />
<strong>SAP</strong>-Benutzer liefern, als auch <strong>der</strong> Großteil <strong>der</strong> während des Projekts anfallenden Tests<br />
durchführen. Zudem sollte durch diese Aufgabenverteilung auch eine entsprechende Verteilung<br />
<strong>der</strong> Projektverantwortung realisiert werden. Der EDV-Mitarbeiter, dem die<br />
Durchführung des Projekts übertragen wurde, in <strong>der</strong> Folge als Projektleiter bezeichnet,<br />
wurde bei seiner Projektarbeit vom EDV-Leiter unterstützt und hatte dafür Sorge zu tragen,<br />
dass Termine eingehalten und die notwendigen Treffen arrangiert und durchgeführt<br />
wurden, und außerdem für die Implementierung und Integrierung des Projekts in das<br />
<strong>SAP</strong>-System. Den Keyusern oblag die Verantwortung dafür, dass den <strong>SAP</strong>-<br />
BenutzerInnen nur jene Berechtigungen zugewiesen wurden, die sie für ihre tägliche Arbeit<br />
benötigten.<br />
51
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Zwecks Vereinfachung <strong>der</strong> zukünftigen Pflege <strong>der</strong> Zugriffsberechtigungen wurde vereinbart,<br />
dass die Aktivitätsgruppen und Berechtigungsprofile nicht den <strong>SAP</strong>-Benutzern direkt<br />
zugeordnet werden sollten, son<strong>der</strong>n indirekt über die entsprechenden Organisationseinheiten,<br />
Stellen o<strong>der</strong> Planstellen. Da das Organisationsdiagramm <strong>der</strong> HFA in <strong>SAP</strong> R/3<br />
nicht abgebildet war, entstand so die zusätzliche Notwendigkeit, auch diese Aufgabe im<br />
Zuge des Projekts durchzuführen, und sie sollte vom Projektleiter wahrgenommen werden.<br />
Der geplante Ablauf <strong>der</strong> Berechtigungsvergabe im Projekt lässt sich folgen<strong>der</strong>maßen darstellen:<br />
ZUGRIFFSBERECHTIGUNGEN<br />
AKTIVITÄTSGRUPPE / BERECHTIGUNGSPROFIL<br />
ORGANISATIONSEINHEIT / STELLE / PLANSTELLE<br />
INHABER / BENUTZERSTAMMSATZ<br />
Abb. 19: Berechtigungsvergabe im <strong>SAP</strong> R/3-Projekt<br />
Aufgrund <strong>der</strong> Beteiligung <strong>der</strong> Keyuser wurde im Zuge <strong>der</strong> Projektplanung kein detaillierter<br />
Zeitplan erstellt, da durch die relativ große Anzahl <strong>der</strong> am Projekt beteiligten Personen ein<br />
hohes Maß an Flexibilität gewährleistet sein musste. Somit wurde vorab lediglich ein Zeitrahmen<br />
von sechs Monaten festgelegt, innerhalb dessen das gesamte Projekt<br />
abgewickelt werden sollte.<br />
5.3.4 Implementierung<br />
5.3.4.1 Evaluierung und Anlegen <strong>der</strong> erfor<strong>der</strong>lichen Stellen und<br />
Aktivitätsgruppen<br />
In diesem Teil des Projekts hatten die Keyuser zu evaluieren, welche Stellen und wie viele<br />
davon abgeleiteter Planstellen je Abteilung bzw. <strong>SAP</strong>-Modul benötigt würden, und dies<br />
dem Projektleiter mitzuteilen. Außerdem mussten die Keyuser den Projektleiter darüber<br />
informieren, welche Aktivitätsgruppen sie einerseits für die eigenen Mitarbeiter und an<strong>der</strong>erseits<br />
für Mitarbeiter aus an<strong>der</strong>en Abteilungen benötigten. Zu je<strong>der</strong> angefor<strong>der</strong>ten<br />
Aktivitätsgruppe wurde <strong>der</strong> EDV auch mitgeteilt, welchen MitarbeiterInnen diese später<br />
zur Verfügung gestellt werden sollte. Für die Namen <strong>der</strong> neuen Aktivitätsgruppen wurde<br />
das folgende Format gewählt:<br />
HFA_A.Name<br />
HFA am Beginn jedes Names sollte darauf hinweisen, dass es sich bei <strong>der</strong> betreffenden<br />
Aktivitätsgruppe um eine von <strong>der</strong> HFA erzeugte und nicht um eine von <strong>der</strong> <strong>SAP</strong> vordefinierte<br />
Aktivitätsgruppe handelt.<br />
52
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Nach einem Unterstrich sollte ein Großbuchstabe Aufschluss darüber geben, welche Abteilung<br />
für die Erstellung <strong>der</strong> betreffenden Aktivitätsgruppe verantwortlich war bzw. aus<br />
welchem <strong>SAP</strong>-Baustein die Transaktionen innerhalb <strong>der</strong> Aktivitätsgruppe stammten. Folgende<br />
Großbuchstaben waren dabei möglich:<br />
- C: Produktionsplanung und –steuerung<br />
- F: Finanzbuchhaltung<br />
- K: Controlling<br />
- M: Materialwirtschaft<br />
- P: Personalwirtschaft<br />
- Q: Qualitätsmanagement<br />
- S: System<br />
- V: Vertrieb<br />
Der Name nach dem Punkt sollte schließlich noch auf den Inhalt <strong>der</strong> Transaktionen o<strong>der</strong><br />
auf die Mitarbeitergruppe, <strong>der</strong> die Aktivitätsgruppe zugeordnet werden sollte, hinweisen.<br />
Ein Beispiel für den Namen einer Aktivitätsgruppe ist HFA_C.USER. Diese Aktivitäsgruppe<br />
entstammt <strong>der</strong> Abteilung Produktionsplanung und –steuerung und enthält<br />
Transaktionsberechtigungen für die Sachbearbeiter dieser Abteilung. In bezug auf die<br />
beschriebene Namenskonvention gab es zwei Ausnahmen zu beachten. Die Aktivitätsgruppen<br />
<strong>der</strong> Abteilung Einkauf begannen mit HFA_M.EK, gefolgt von einem Unterstrich<br />
und dem Namen zur näheren Bezeichnung, da <strong>der</strong> Einkauf im <strong>SAP</strong>-Modul Materialwirtschaft<br />
enthalten ist, und die Aktivitätsgruppen mit <strong>der</strong> Kennzeichnung S enthielten<br />
Systemberechtigungen, wie beispielsweise die Berechtigung zum Ausdrucken von Dokumenten,<br />
usw., und wurden von <strong>der</strong> EDV vergeben. Insgesamt entstanden zusammen mit<br />
den überarbeiteten mehr als 130 neue Aktivitätsgruppen. Beispielhaft sind an dieser Stelle<br />
die Aktivitätsgruppen des Vertriebes angeführt:<br />
Aktivitätsgruppe Kurzbeschreibung Profilname<br />
HFA_V.ANZEIGE Anzeige Verkauf V:ANZEIGE_<br />
HFA_V.FIBU FIBU (Verkauf) V:FIBU____<br />
HFA_V.INTRASTAT Intrastat-Meldung (Verkauf) V:INTRASTA<br />
HFA_V.KEYUSER Keyuser Verkauf V:KEYUSER_1<br />
HFA_V.TECHNIK Technik (Vertrieb) V:TECHNIK_<br />
HFA_V.USER Sachbearbeiter Verkauf V:USER____1<br />
Abb. 20: Aktivitätsgruppen aus <strong>der</strong> Abteilung „Vertrieb“<br />
Die Keyuser mussten in dieser Projektphase aber nicht nur dafür sorgen, dass die erfor<strong>der</strong>lichen<br />
Aktivitätsgruppen für ihre Mitarbeiter angelegt wurden, son<strong>der</strong>n auch für das<br />
Einrichten von Aktivitätsgruppen, die Mitarbeitern aus an<strong>der</strong>en Abteilungen zur Verfügung<br />
gestellt werden sollten.<br />
Der <strong>SAP</strong>-Administrator hat anhand <strong>der</strong> Anfor<strong>der</strong>ungen <strong>der</strong> Keyuser die benötigten Aktivitätsgruppen<br />
mit Hilfe des Profilgenerators angelegt. Dabei wurden noch keine<br />
Transaktionen und Reports in den neuen Aktivitätsgruppen erfasst.<br />
53
Abb. 21: Profilgenerator<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Der Profilgenerator kann über das <strong>SAP</strong>-Menü Werkzeuge ! Administration ! Benutzerpflege<br />
! Aktivitätsgruppen (Benutzerrollen) o<strong>der</strong> durch direktes Aufrufen <strong>der</strong> Transaktion<br />
PFCG gestartet werden. Im Feld „Aktivitätsgruppe“ kann ein Name einer Aktivitätsgruppe<br />
eingegeben werden und durch Drücken des entsprechenden Buttons kann die Aktivitätsgruppe<br />
angezeigt, geän<strong>der</strong>t o<strong>der</strong> angelegt werden. Über den kleinen Button, <strong>der</strong> sich<br />
rechts, unmittelbar neben dem Eingabefeld befindet, kann eine Suchfunktion aufgerufen<br />
werden. Will man das Organisationsdiagramm in die Pflege <strong>der</strong> Aktivitätsgruppen bzw. in<br />
die <strong>Vergabe</strong> <strong>der</strong> Berechtigungen mit einbeziehen, dann muss in <strong>der</strong> Sichtauswahl die Gesamtsicht<br />
gewählt werden. Mittels <strong>der</strong> Typauswahl ist es möglich, auch<br />
Sammelaktivitätsgruppen anzulegen, in denen mehrere Aktivitätsgruppen zusammengefasst<br />
werden können. Im Zuge des HFA-Berechtigungsprojekts wurden jedoch keine<br />
Sammelaktivitätsgruppen angelegt, weshalb an dieser Stelle auch nicht näher auf diese<br />
Funktion eingegangen werden soll.<br />
5.3.4.2 Erfassen <strong>der</strong> Transaktionen und Reports<br />
Für das Erfassen <strong>der</strong> Transaktionen und Reports in den neuen Aktivitätsgruppen wurde<br />
denjenigen Keyusern, die auch die Erstellung <strong>der</strong> Aktivitätsgruppen veranlassten, die<br />
temporäre Berechtigung für den Profilgenerator in <strong>SAP</strong> R/3 erteilt. Dadurch wurde ihnen<br />
die Möglichkeit eingeräumt, selbst selbst die benötigten Transaktionen und Reports in ihre<br />
Aktivitätsgruppen einzufügen. Die betroffenen Keyuser wurden durch eine kurze Einweisung<br />
mit dem Teil des Profilgenerators vertraut gemacht, <strong>der</strong> für sie relevant war. Sie<br />
sollten die nötigen Transaktionen und Reports aus dem <strong>SAP</strong>-Menü in die aktuelle Aktivitätsgruppe<br />
aufnehmen. Aus dem <strong>SAP</strong>-Menü konnten die Keyuser ganze Menüzweige<br />
inklusive aller untergeordneten Knoten und Transaktionen durch Anklicken des betreffenden<br />
Menüzweiges in die Aktivitätsgruppe aufnehmen. Durch Expandieren <strong>der</strong><br />
Menüzweige hatten sie aber auch die Möglichkeit, untergeordnete Knoten o<strong>der</strong> einzelne<br />
Transaktionen bzw. Reports in die Aktivitätsgruppe aufzunehmen.<br />
54
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Weitere Möglichkeiten, Transaktionen in eine Aktivitätsgruppe einzufügen, sind das Kopieren<br />
aus einer bereits bestehenden Aktivitätsgruppe, die Übernahme aus vorhandenen<br />
Bereichsmenüs o<strong>der</strong> die einzelne Aufnahme von Transaktionen, Reports o<strong>der</strong>, falls erfor<strong>der</strong>lich,<br />
auch Web-Adressen. In <strong>der</strong> nachfolgenden Abbildung sind die Buttons ersichtlich,<br />
über die man die Aktivitätsgruppe, wie beschrieben, um Transaktionen, Reports und Web-<br />
Adressen ergänzen kann.<br />
Abb 22: Transaktionserfassung im Profilgenerator<br />
Der Keyuser <strong>der</strong> Qualitätssicherung war von <strong>der</strong> Aufgabe <strong>der</strong> Transaktionserfassung ausgenommen,<br />
da <strong>der</strong> <strong>SAP</strong>-Baustein für die Qualitätssicherung zum Zeitpunkt des<br />
Berechtigungsprojekts in <strong>der</strong> HFA eingeführt wurde. Aus diesem Grund wurden die erfor<strong>der</strong>lichen<br />
Aktivitätsgruppen und Transaktionen vom Keyuser und einem <strong>SAP</strong>-Berater im<br />
Zuge <strong>der</strong> Einführung erfasst und <strong>der</strong> EDV mitgeteilt. Die Transaktionen wurden dann<br />
durch direktes Erfassen <strong>der</strong> Transaktionscodes in die Aktivitätsgruppen <strong>der</strong> Qualitätssicherung<br />
übernommen.<br />
Eine weitere Ausnahme in diesem Projektabschnitt bildeten jene Berichte, die <strong>der</strong> EDV in<br />
Form einer Liste von <strong>der</strong> Personalwirtschaft übermittelt wurden. Dabei handelte es sich<br />
um Berichte, die nicht als Reports direkt übernommen werden konnten, son<strong>der</strong>n die in<br />
dem Berechtigungsobjekt S_PROGRAM (ABAP: Programmablaufprüfungen) innerhalb<br />
<strong>der</strong> Aktivitätsgruppen für den Keyuser und den User <strong>der</strong> Personalwirtschaft zu erfassen<br />
waren.<br />
55
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
5.3.4.3 Überarbeitung <strong>der</strong> neuen und übernommenen Aktivitätsgruppen<br />
Die Aktivitätsgruppen, die bei Projektbeginn bereits existierten und übernommen werden<br />
sollten, wurden überarbeitet und das Namensformat wurde durch Kopieren <strong>der</strong> Aktivitätsgruppen<br />
an das neue Format angepasst. Es handelt sich dabei um Aktivitätsgruppen, die<br />
seit <strong>der</strong> Einführung von <strong>SAP</strong> R/3 in <strong>der</strong> HFA sukzessive und jeweils unter Einbeziehung<br />
<strong>der</strong> zuständigen Keyuser von <strong>der</strong> EDV erstellt worden sind und die aufgrund ihres bewährten<br />
Einsatzes in <strong>der</strong> Vergangenheit erhalten bleiben sollten, um den Projektaufwand<br />
dadurch zu verringern. Zu den überarbeiteten Aktivitätsgruppen gehören u. a. die BAB-<br />
Aktivitätsgruppen, die Zeitkonto- und Reisekosten-Aktivitätsgruppen und die meisten System-Aktivitätsgruppen.<br />
Die Überarbeitung <strong>der</strong> alten Aktivitätsgruppen wurde von <strong>der</strong> EDV seit Beginn des Projekts<br />
durchgeführt, während die neuen Aktivitätsgruppen erst überarbeitet werden<br />
konnten, sobald die Keyuser alle erfor<strong>der</strong>lichen Transaktionen erfasst hatten. Da die Keyuser<br />
zu unterschiedlichen Zeitpunkten ihre Transaktionserfassungen abschlossen,<br />
wurden die neuen Aktivitätsgruppen nicht ab einem bestimmten Zeitpunkt überarbeitet,<br />
son<strong>der</strong>n laufend nach entsprechen<strong>der</strong> Benachrichtigung durch die Keyuser.<br />
Bei <strong>der</strong> Überarbeitung <strong>der</strong> bestehenden und neuen Aktivitätsgruppen wurden die Berechtigungsobjekte<br />
und die zugehörigen Berechtigungsfel<strong>der</strong> in je<strong>der</strong> Aktivitätsgruppe<br />
gepflegt. Abbildung 23 zeigt einige Berechtigungsobjekte und –fel<strong>der</strong> <strong>der</strong> Aktivitätsgruppe<br />
HFA_C.ANZEIGE. Es ist auch das Ampelsystem ersichtlich, das auf verschiedenen Ebenen<br />
mit roten, gelben und grünen Ampelsignalen den aktuellen Pflegezustand <strong>der</strong><br />
Aktivitätsgruppe darstellt. Im Zuge <strong>der</strong> Überarbeitung wurden überflüssige Berechtigungsobjekte<br />
inaktiviert, fehlende Berechtigungswerte eingetragen, usw. Über den Button<br />
Orgebenen wurden Organisationsebenen, wie Werke, Buchungskreise, Geschäftsbereiche,<br />
u. ä. gepflegt, die dann in allen Berechtigungsobjekten, in denen ein entsprechendes<br />
Berechtigungsfeld enthalten ist, automatisch eingetragen wurden. Hatte die EDV keine<br />
o<strong>der</strong> mangelnde Informationen über einzutragende Werte in bestimmte Fel<strong>der</strong>, dann wurde<br />
ein Dummy-Wert eingetragen, um nicht das gesamte Berechtigungsobjekt deaktivieren<br />
zu müssen.<br />
Nach dem Abschluss <strong>der</strong> Überarbeitung je<strong>der</strong> Aktivitätsgruppe wurde durch Betätigen des<br />
entsprechendes vierten Buttons von links in <strong>der</strong> unteren Buttonreihe sofort das Berechtigungsprofil<br />
aus <strong>der</strong> Aktivitätsgruppe generiert. Wie bei den Aktivitätsgruppen wurde auch<br />
bei den Berechtigungsprofilen ein einheitliches Namensformat eingehalten. Aus <strong>der</strong> Aktivitätsgruppe<br />
HFA_C.ANZEIGE entstand beispielsweise durch eine Ableitung aus dem<br />
Namen das Profil C:ANZEIGE_. Nach dem Buchstaben, <strong>der</strong> die Abteilung kennzeichnet,<br />
aus <strong>der</strong> die Aktivitätsgruppe entstammt, ersetzt bei den Profilnamen ein Doppelpunkt den<br />
Punkt. Bei weniger als acht Zeichen nach dem Doppelpunkt wurde <strong>der</strong> Name durch Unterstriche<br />
auf die Länge von acht Zeichen ergänzt. Je nach <strong>der</strong> Größe <strong>der</strong><br />
Aktivitätsgruppe generiert das <strong>SAP</strong>-System auch mehrere Berechtigungsprofile aus einer<br />
Aktivitätsgruppe. In diesem Fall wird an das zweite Profil eine 1, an das dritte Profil eine 2,<br />
usw. angehängt.<br />
56
Abb. 23: Berechtigungsobjekte und –fel<strong>der</strong> einer Aktivitätsgruppe<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Die Überarbeitung sämtlicher Aktivitätsgruppen inklusive <strong>der</strong> Erstellung <strong>der</strong> Berechtigungsprofile<br />
war am 16. Oktober 2001 abgeschlossen.<br />
5.3.4.4 Abbilden des Organisationsdiagramms in <strong>SAP</strong> R/3<br />
Parallel zu den beiden ersten Schritten im Projekt wurde das bis dahin ungepflegte Organisationsmanagement<br />
im <strong>SAP</strong>-System angelegt. Dabei wurden in enger Anlehnung an<br />
das Organisationsdiagramm <strong>der</strong> HFA alle MitarbeiterInnen berücksichtigt, die über einen<br />
eigenen <strong>SAP</strong>-Benutzer Zugriff auf <strong>SAP</strong>-Anwendungen erhalten sollten.<br />
Dabei war es zunächst nötig, mittels <strong>der</strong> Transaktion PPOME (Organisation und Besetzung<br />
än<strong>der</strong>n), die auch über den Menüpfad Personal ! Organisationsmanagement !<br />
Aufbauorganisation ! Organisation und Besetzung ! Än<strong>der</strong>n erreichbar ist, die erfor<strong>der</strong>lichen<br />
Organisationseinheiten <strong>der</strong> HFA anzulegen.<br />
Abb. 9 zeigt die Transaktion PPOME und einen Teil des erfassten Organisationsmanagements.<br />
Nach dem Anlegen sämtlicher Organisationseinheiten wurden die erfor<strong>der</strong>lichen<br />
Stellen eingerichtet und in weiterer Folge auch die benötigten Planstellen. Man erkennt<br />
die Planstellen in <strong>der</strong> Abbildung an dem Personensymbol, wobei die mit einem Hut gekennzeichneten<br />
Symbole auf eine Leitungsfunktion hinweisen.<br />
57
Abb. 24: Organisationsmanagement<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Da das Organisationsmanagement in <strong>SAP</strong> ein vollständiges, funktionales Abbild <strong>der</strong> HFA-<br />
Organisation darstellen mußte, um für eine effiziente Berechtigungsvergabe verwendet<br />
werden zu können, wurde das HFA-Organisationsdiagramm nicht hun<strong>der</strong>tprozentig übernommen.<br />
Im Organisationsdiagramm <strong>der</strong> HFA werden in erster Linie Geschäftseinheiten<br />
mit <strong>der</strong>en Abteilungen und den Namen <strong>der</strong> jeweiligen Kostenstellenverantwortlichen dargestellt.<br />
Die verschiedenen Sachbearbeiterstellen mussten also hinzugefügt werden.<br />
Außerdem musste eine neue Organisationseinheit für die Telefonzentrale berücksichtigt<br />
werden, die im Organisationsdiagramm <strong>der</strong> HFA nicht explizit aufscheint.<br />
Nachdem alle Organisationseinheiten, Stellen und Planstellen über das Organisationsmanagement<br />
in <strong>SAP</strong> R/3 angelegt waren, mussten noch allen Planstellen die<br />
entsprechenden InhaberInnen zugeordnet werden. Diese Zuordnung erfolgte <strong>der</strong> Einfachheit<br />
halber nicht in <strong>der</strong> Transaktion PPOME, son<strong>der</strong>n in <strong>der</strong> Transaktion PPOM_OLD, die<br />
eine etwas ältere Version <strong>der</strong> Transaktion PPOME zur Pflege des Organisationsmanagements<br />
darstellt. Zu dieser Transaktion gelangt man auch man über den Menüpfad<br />
Personal ! Organisationsmanagement ! Expertenmodus ! Einfache Pflege ! Än<strong>der</strong>n.<br />
Um die Zuordnung <strong>der</strong> Inhaber zu den Planstellen durchführen zu können, war es zunächst<br />
notwendig, dass in den Personalstammdaten <strong>der</strong> betreffenden Personen ein<br />
bestimmtes Feld gepflegt war, über das die Verknüpfung zwischen <strong>SAP</strong>-Benutzer und<br />
Person hergestellt wird. Bei den Personen, bei denen dieses Feld noch nicht gepflegt war,<br />
wurde es durch die Personalabteilung nachgepflegt.<br />
Ein Spezialfall, <strong>der</strong> im Zuge des Erstellens des Organisationsmanagements behandelt<br />
werden musste, trat durch den Umstand auf, dass zwei <strong>SAP</strong>-Benutzer berücksichtigt werden<br />
mussten, die für das Ausdrucken <strong>der</strong> Warenbegleitkarten vorgesehen waren. Diese<br />
beiden Benutzer, BKARTE und OBFL, sollten ausschließlich über die Berechtigung zum<br />
Begleitkartendruck verfügen, da mehrere Personen aus den Abteilungen Oberflächenbearbeitung<br />
und Kunststoffverarbeitung mit diesen Benutzern arbeiten müssten.<br />
58
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Um diese Benutzer in das Berechtigungsprojekt integrieren zu können, war es erfor<strong>der</strong>lich,<br />
sie an zwei Mitarbeiter aus den jeweiligen Abteilungen zu koppeln, die eigentlich<br />
keine <strong>SAP</strong>-Anwen<strong>der</strong> sind. Die entsprechenden Verknüpfungen wurden wie<strong>der</strong>um durch<br />
die Personalabteilung durchgeführt, und anschließend wurden die beiden Mitarbeiter im<br />
Organisationsmanagement erfasst. Die Stellen bzw. Planstellen dieser Mitarbeiter wurden<br />
durch den Zusatz Begleitkarte gekennzeichnet.<br />
5.3.4.5 Kontrolle aller Aktivitätsgruppen<br />
In dieser Phase des Projekts hatten die Keyuser sämtliche Aktivitätsgruppen dahingehend<br />
zu überprüfen, ob sich darin kritische Transaktionen aus ihrem jeweiligen Verantwortungsbereich<br />
befanden. Die Keyuser konnten sich zu diesem Zweck alle ausführbaren<br />
Transaktionen eines Berechtigungsprofils mit Hilfe <strong>der</strong> <strong>SAP</strong>-Transaktion<br />
S_BCE_68001427 anzeigen lassen. Diese Transaktion ist auch über den Menüpfad<br />
Werkzeuge ! Administration ! Benutzerpflege ! Infosystem ! Transaktionen !<br />
Transaktionen für Benutzer, mit Profil o<strong>der</strong> Berechtigung ! ausführbar mit Profil aufrufbar.<br />
Da nur die Anzeige <strong>der</strong> ausführbaren Transaktionen pro Berechtigungsprofil, und<br />
nicht pro Aktivitätsgruppe, möglich ist, wurde den Keyusern vom Projektleiter eine Liste<br />
<strong>der</strong> zu kontrollierenden Aktivitätsgruppen zur Verfügung gestellt, in <strong>der</strong> zu je<strong>der</strong> Aktivitätsgruppe<br />
auch <strong>der</strong> Name des Profils angeführt war. Bei mehreren vorhandenen Profilen pro<br />
Aktivitätsgruppe wurde <strong>der</strong> Name jenes Profils angeführt, das zur Anzeige <strong>der</strong> Transaktionen<br />
verwendet werden kann. Das war im Normalfall jenes Profil mit <strong>der</strong> höchsten<br />
Endnummer.<br />
Die Keyuser teilten in dieser Projektphase dem Projektleiter mit, welche Transaktionen<br />
aus welchen Aktivitätsgruppen entfernt werden sollten. Nach den erfolgten Korrekturen<br />
durch den Projektleiter wurden die Aktivitätsgruppen jeweils neu generiert, also neue Berechtigungsprofile<br />
ohne die beanstandeten, kritischen Transaktionen erzeugt.<br />
5.3.5 Testphase<br />
5.3.5.1 Test <strong>der</strong> neuen Aktivitätsgruppen<br />
Nach dem Ende <strong>der</strong> Kontrollen <strong>der</strong> Aktivitätsgruppen durch die Keyuser wurden im <strong>SAP</strong>-<br />
Testsystem Testbenutzer für die neuen Aktivitätsgruppen angelegt. Die Keyuser sollten<br />
mit Hilfe dieser Testbenutzer die Funktionalität ihrer Aktivitätsgruppen testen. Am 13. November<br />
2001 erhielten alle Keyuser, die für das Anlegen neuer Aktivitätsgruppen<br />
verantwortlich waren, eine Liste <strong>der</strong> für sie eingerichteten Testbenutzer, und das war auch<br />
gleichzeitig <strong>der</strong> Beginn dieser Testphase. Neben den Berechtigungen <strong>der</strong> eigentlichen<br />
Aktivitätsgruppen wurden die Testbenutzer mit allgemeinen Berechtigungen bzw. mit Berechtigungsprofilen,<br />
die in dieser Testphase nicht geson<strong>der</strong>t getestet werden sollten,<br />
ausgestattet. Die nachfolgende Abbildung zeigt beispielhaft die Testbenutzer des Vertriebes:<br />
59
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
VKEY HFA_V.KEYUSER HFA_S.CUSTOMIZING<br />
HFA_F.SK_ALL HFA_S.USER<br />
HFA_F.SK_SD HFA_S.BASIS_EDI<br />
HFA_P.REISE_ERF HFA_S.ARCHIV_SD<br />
HFA_P.ZEITKONTO HFA_S.SYSTEM_SD<br />
VUSER HFA_V.USER HFA_S.USER<br />
HFA_F.SK_ALL HFA_S.BASIS_EDI<br />
HFA_F.SK_SD<br />
HFA_P.REISE_ERF<br />
HFA_P.ZEITKONTO<br />
VANZ HFA_V.ANZEIGE HFA_S.USER<br />
HFA_F.SK_ALL<br />
VFIBU HFA_V.FIBU HFA_S.USER<br />
HFA_F.SK_ALL<br />
VINTRA HFA_V.INTRASTAT HFA_S.USER<br />
HFA_F.SK_ALL<br />
Abb. 25: Vertriebs-Testbenutzer samt enthaltener Aktivitätsgruppen<br />
Den Keyusern wurde es überlassen, ihre Aktivitätsgruppen zur Gänze selbst zu testen<br />
o<strong>der</strong> einzelne davon von ihren Kollegen testen zu lassen. Traten während dieser Testphase<br />
Berechtigungsprobleme bei den Testbenutzern auf, dann wurden diese Probleme<br />
durch den Projektleiter behoben, indem fehlende Berechtigungswerte eingetragen o<strong>der</strong><br />
neue Berechtigungsobjekte in die Aktivitätsgruppe aufgenommen wurden. Wurden die<br />
Testbenutzer vom System auf eine fehlende Berechtigung hingewiesen, dann konnten sie<br />
sich über den Pfad System ! Hilfsmittel ! Anz. Berecht.prüfung in <strong>der</strong> Menüzeile Details<br />
zur letzten Berechtigungsprüfung anzeigen lassen. Mit Hilfe dieser Informationen konnte<br />
<strong>der</strong> Projektleiter die erfor<strong>der</strong>lichen Einträge in die betreffende Aktivitätsgruppe durchführen.<br />
Führte die Korrektur aufgrund <strong>der</strong> Anzeige <strong>der</strong> letzten Berechtigungsprüfung nicht<br />
zum angestrebten Erfolg, dann bediente man sich <strong>der</strong> Möglichkeit, mit dem Systemtrace<br />
von <strong>SAP</strong> R/3 alle Berechtigungsprüfungen aufzuzeichnen. Der Systemtrace von <strong>SAP</strong><br />
stellt ein umfassendes Protokollierungstool dar und kann durch den Transaktionscode<br />
ST01 aufgerufen und entsprechend <strong>der</strong> jeweiligen Anfor<strong>der</strong>ungen konfiguriert werden.<br />
Mit Hilfe <strong>der</strong> beiden erwähnten Protokollfunktionen hinsichtlich <strong>der</strong> Berechtigungsprüfungen<br />
wurden alle Berechtigungsprobleme, die bei den Testbenutzern im Laufe <strong>der</strong><br />
Testphase auftraten, durch den Projektleiter bereinigt.<br />
In <strong>der</strong> ersten Testphase wurde vorrangig darauf Wert gelegt, die geläufigsten, d. h. im<br />
Tagesgeschäft am häufigsten benötigten Transaktionen in den neuen Aktivitätsgruppen<br />
zu testen. Das sollte den Testaufwand in <strong>der</strong> zweiten Testphase, in <strong>der</strong> alle <strong>SAP</strong>-Benutzer<br />
ihre Berechtigungen prüfen könnten, verringern. Einige Keyuser nutzten diese Testphase<br />
aber bereits dazu, um umfangreiche Tests durchzuführen, damit sich für sie <strong>der</strong> Arbeitsaufwand<br />
in <strong>der</strong> nächsten Testphase verringern sollte. An<strong>der</strong>e wie<strong>der</strong>um testeten hier<br />
nur sehr oberflächlich, da sie genauere Tests erst in <strong>der</strong> nächsten Testphase durchführen<br />
wollten. Die Entscheidung, in welcher Testphase die detaillierteren Tests durchgeführt<br />
werden sollten, wurde seitens <strong>der</strong> EDV den Keyusern überlassen, wodurch diesen ein<br />
gewisser Handlungs- und Entscheidungsspielraum eingeräumt wurde. Beispielsweise<br />
wurden dem Wunsch <strong>der</strong> Finanzbuchhaltung entsprechend <strong>der</strong>en Testbenutzern bereits<br />
in dieser ersten Testphase Aktivitätsgruppen an<strong>der</strong>er Abteilungen zugeordnet, damit hier<br />
schon detailliertere Tests durchgeführt werden konnten.<br />
Das offizielle Ende dieser Testphase war <strong>der</strong> 05. Dezember 2001.<br />
60
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
5.3.5.2 <strong>Vergabe</strong> <strong>der</strong> neuen Berechtigungen im Testsystem<br />
Nach dem Ende <strong>der</strong> ersten Testphase und bevor die zweite Testphase begonnen werden<br />
konnte, war es notwendig, alle bestehenden Berechtigungen im Testsystem zu löschen<br />
und anschließend die neuen Aktivitätsgruppen bzw. Berechtigungsprofile indirekt über<br />
Organisationseinheiten, Stellen und Planstellen den <strong>SAP</strong>-BenutzerInnen zuzuordnen.<br />
Zunächst wurden im Testsystem die Testbenutzer aus <strong>der</strong> vorangegangenen Testphase<br />
gelöscht. Danach wurde <strong>der</strong> Benutzer HELP angelegt, <strong>der</strong> von den bevorstehenden Än<strong>der</strong>ungen<br />
im Testsystem nicht betroffen sein würde und deshalb unentbehrlich war, da<br />
nach dem Löschen aller Berechtigungen im Testsystem für kurze Zeit kein Mitarbeiter <strong>der</strong><br />
HFA Berechtigungen im <strong>SAP</strong> haben sollte. Der Benutzer HELP gewährleistete also ein<br />
Weiterarbeiten im <strong>SAP</strong>-Testsystem und diente in erster Linie dazu, die neuen Berechtigungen<br />
zuordnen zu können.<br />
Das Löschen <strong>der</strong> bestehenden Berechtigungszuordnungen erfolgte im Benutzerstamm, in<br />
den sowohl die Aktivitätsgruppen als auch die Berechtigungsprofile bei einer Benutzerzuordnung<br />
über den Profilgenerator eingetragen werden. Um keine <strong>SAP</strong>-BenutzerInnen<br />
vergessen zu können, wurden anhand einer vollständigen Liste <strong>der</strong> BenutzerInnen bei<br />
allen BenutzerInnen sämtliche Aktivitätsgruppen aus den Benutzerstämmen gelöscht. Mit<br />
dem Entfernen <strong>der</strong> Aktivitätsgruppen wurden automatisch alle zugehörigen Berechtigungsprofile<br />
aus den Benutzerstämmen entfernt. Die nachfolgende Abbildung zeigt einen<br />
Benutzerstamm, dem eine Aktivitätsgruppe zugeordnet ist. Im Än<strong>der</strong>ungsmodus kann<br />
diese Aktivitätsgruppe durch Markieren <strong>der</strong> betreffenden Zeile und anschließendes Betätigen<br />
des linken <strong>der</strong> drei Buttons innerhalb des Registers gelöscht werden.<br />
Abb. 26: Benutzerpflege - Aktivitätsgruppen<br />
61
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Nach dem erfolgreichen Löschen aller bestehenden Berechtigungszuordnungen im Testsystem<br />
wurden die neuen Aktivitätsgruppen, wie<strong>der</strong>um anhand einer vollständigen Liste,<br />
über das Organisationsmanagement indirekt den <strong>SAP</strong>-Benutzern zugeordnet. Jede Aktivitätsgruppe<br />
wurde entsprechend <strong>der</strong> jeweiligen Anfor<strong>der</strong>ungen einzeln an Organisationseinheiten,<br />
Stellen o<strong>der</strong> Planstellen zugeordnet, was zur Folge hatte, dass die InhaberInnen<br />
<strong>der</strong> Planstellen in diese Aktivitätsgruppe als zugeordnete BenutzerInnen eingetragen<br />
wurden. Es war auch vereinzelt <strong>der</strong> Fall, dass einer Aktivitätsgruppe sowohl ganze Organisationseinheiten,<br />
als auch einzelne Stellen bzw. Planstellen zuzuordnen waren.<br />
Die Zuordnung erfolgte durch das Anwählen des Buttons Benutzer, dessen Ampel bis dahin<br />
den Status rot zeigte, da noch keine Benutzer gepflegt wurden. Über den Button<br />
Org.Management konnten neue Zuordnungen angelegt werden. Hier konnten auch bestehende,<br />
indirekte Benutzerzuordnungen wie<strong>der</strong> entfernt werden. Ein Löschen von<br />
indirekten Benutzerzuordnungen in <strong>der</strong> Aktivitätsgruppe ist allerdings nicht möglich. Diese<br />
Möglichkeit besteht nur, wenn die Benutzer durch Erfassen in <strong>der</strong> Benutzerliste direkt <strong>der</strong><br />
Aktivitätsgruppe zugeordnet wurden. Direkte und indirekte Benutzerzuordnungen in einer<br />
Aktivitätsgruppe können daran unterschieden werden, dass indirekt zugeordnete Benutzer<br />
grau, direkt zugeordnete Benutzer hingegen weiß hinterlegt sind. Will man in R/3 eine<br />
neue, indirekte Benutzerzuordnung über das Organisationsmanagement erzeugen, so erscheint<br />
nach Betätigen des entsprechenden Buttons ein Auswahlfenster mit den möglichen<br />
organisatorischen Einheiten. Nach erfolgter Wahl <strong>der</strong> gewünschten Einheit kann<br />
man aus einer Liste mit allen bestehenden Einträgen, also allen zuvor angelegten Stellen,<br />
Planstellen, usw., jene auswählen, die <strong>der</strong> Aktivitätsgruppe zugeordnet werden sollen.<br />
Abb. 11 zeigt das Register Benutzer innerhalb einer Aktivitätsgruppe. Man erkennt auch<br />
den Button Org.Management, über den indirekte Zuordnungen vorgenommen werden<br />
können. In den freien Fel<strong>der</strong>n darunter stehen nach einer erfolgten Zuordnung zeilenweise<br />
die einzelnen Benutzer, das sind in diesem Fall die Inhaber <strong>der</strong> zugeordneten<br />
Planstellen, wobei diese, wie bereits erwähnt, grau hinterlegt dargestellt werden.<br />
Abb. 27: Aktivitätsgruppe – Benutzerzuordnung<br />
62
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Nach dem Erzeugen <strong>der</strong> indirekten Benutzerzuordnungen wurden diese sofort in einem<br />
Transportauftrag erfasst. Mit <strong>der</strong> Hilfe von Transportaufträgen können Än<strong>der</strong>ungen, die im<br />
Testsystem durchgeführt werden, und zum Teil auch nur in diesem System möglich sind,<br />
in das Produktivsystem transportiert und dort anschließend importiert werden. Dadurch<br />
muss man Än<strong>der</strong>ungen nur in einem System vornehmen und kann sie nach erfolgreichem<br />
Testen direkt in das Produktivsystem übernehmen. Beim Erfassen <strong>der</strong> Benutzerzuordnungen<br />
in <strong>der</strong> ersten Aktivitätsgruppe wurde ein neuer Transportauftrag für die indirekten<br />
Zuordnungen erzeugt. In diesem Transportauftrag wurden dann sämtliche Benutzerzuordnungen<br />
für alle Aktivitätsgruppen des laufenden Projekts erfasst.<br />
5.3.5.3 Test <strong>der</strong> neuen Berechtigungszuordnungen<br />
Am 18. Dezember 2001 wurden alle <strong>SAP</strong>-BenutzerInnen <strong>der</strong> HFA darüber informiert, dass<br />
die Benutzerberechtigungen im Testsystem zur Gänze neu vergeben wurden, und gleichzeitig<br />
wurden sie aufgefor<strong>der</strong>t, entsprechende Tests durchzuführen. Zuvor wurden alle<br />
Benutzer im Testsystem freigeschalten. Das war erfor<strong>der</strong>lich, da die meisten BenutzerInnen<br />
im Testsystem für gewöhnlich gesperrt sind, da für gewöhnlich nur die Keyuser und<br />
Systemadministratoren Än<strong>der</strong>ungen und Tests im Testsystem durchführen. Als voraussichtliches<br />
Ende dieser 2. Testphase wurde <strong>der</strong> 18. Januar 2002 bekannt gegeben.<br />
Wie bereits in <strong>der</strong> ersten Testphase, wurden auch in dieser Testphase laufend Korrekturen<br />
in den Aktivitätsgruppen durchgeführt. Je<strong>der</strong> einzelne Benutzer sollte durch diese<br />
Testphase gewährleisten, dass sein <strong>SAP</strong>-Benutzer die für die tägliche Arbeit erfor<strong>der</strong>lichen<br />
Berechtigungen besitzt. Dadurch sollten gröbere Probleme mit dem neuen<br />
Berechtigungskonzept im Produktivsystem von vornherein vermieden werden.<br />
Die Testphase endete schließlich am 25. Januar 2002. Die Keyuser wurden darüber informiert,<br />
dass am 26. Januar 2002 die neuen Berechtigungszuordnungen in das<br />
Produktivsystem transportiert werden sollten und deswegen die Testphase für beendet<br />
erklärt war.<br />
5.3.6 Transport <strong>der</strong> neuen Berechtigungszuordnungen in das<br />
<strong>SAP</strong>-Produktivsystem<br />
Am Samstag, den 26. Januar 2002, wurde das neue Berechtigungskonzept nach den abgeschlossenen<br />
Tests schließlich in das Produktivsystem transportiert. Diese Tätigkeit<br />
musste an einem arbeitsfreien Tag durchgeführt werden, da sämtliche <strong>SAP</strong>-<br />
BenutzerInnen durch die Umstellung <strong>der</strong> Berechtigungszuordnungen eine zeitlang nicht<br />
im <strong>SAP</strong> arbeiten konnten.<br />
Alle Aktivitätsgruppen, die Bestandteil des neuen Berechtigungskonzepts waren, wurden<br />
zunächst in einem Transportauftrag erfasst, anschließend in das Produktivsystem transportiert<br />
und von dort importiert. Der Transport <strong>der</strong> Aktivitätsgruppen wurde zwar schon<br />
Anfang Dezember 2001 durchgeführt (siehe nächster Abschnitt), es sollte aber sichergestellt<br />
werden, dass alle späteren Än<strong>der</strong>ungen in den Aktivitätsgruppen auch im<br />
Produktivsystem berücksichtigt waren. Anschließend wurde im Produktivsystem <strong>der</strong> Benutzer<br />
HELP angelegt, <strong>der</strong>, wie bereits im Testsystem, ein Weiterarbeiten im <strong>SAP</strong>-System<br />
nach dem Löschen <strong>der</strong> alten Berechtigungen sicherstellen sollte. Danach wurden in allen<br />
Benutzerstammsätzen sämtliche Aktivitätsgruppen und Berechtigungsprofile, und damit<br />
alle <strong>SAP</strong>-Benutzerberechtigungen, gelöscht.<br />
63
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Nach erfolgreichem Löschen aller bestehenden Benutzerzuordnungen im Produktivsystem<br />
wurde <strong>der</strong> Transportauftrag, <strong>der</strong> im Testsystem erstellt wurde und die indirekten<br />
Benutzerzuordnungen <strong>der</strong> neuen Aktivitätsgruppen enthielt, vom Testsystem exportiert<br />
und im Produktivsystem importiert. Nun mussten noch in je<strong>der</strong> <strong>der</strong> Aktivitätsgruppen sowohl<br />
ein Abgleich <strong>der</strong> indirekten Benutzerzuordnungen als auch ein vollständiger<br />
Benutzerabgleich durchgeführt werden. Danach waren einerseits alle Benutzer in den<br />
entsprechenden Aktivitätsgruppen und an<strong>der</strong>erseits alle Aktivitätsgruppen und zugehörigen<br />
Berechtigungsprofile in den entsprechenden Benutzerstammsätzen eingetragen.<br />
Nun befanden sich alle neuen Aktivitätsgruppen und Benutzerzuordnungen im Produktivsystem.<br />
Das neue Berechtigungskonzept war somit aktiv und das Berechtigungsprojekt<br />
damit, bis auf eventuell erfor<strong>der</strong>liche Nacharbeiten, abgeschlossen. Die <strong>SAP</strong>-<br />
BenutzerInnen <strong>der</strong> HFA wurden per E-mail darüber informiert, dass die Berechtigungen<br />
im <strong>SAP</strong>-Produktivsystem jetzt neu vergeben waren, und sie wurden gleichzeitig gebeten,<br />
auftretende Probleme im Zusammenhang mit <strong>SAP</strong>-Berechtigungen sofort <strong>der</strong> EDV-<br />
Abteilung mitzuteilen.<br />
5.3.7 Schwierigkeiten und Son<strong>der</strong>fälle im Projekt<br />
Während des Projekts traten einige Probleme auf, die es zu lösen gab, und es gab auch<br />
einige Son<strong>der</strong>fälle, die einer speziellen Behandlung bedurften. Der Son<strong>der</strong>fall mit den<br />
Warenbegleitkarten wurde bereits im Zuge <strong>der</strong> Beschreibung <strong>der</strong> Abbildung des Organisationsdiagramms<br />
erörtert. Weitere Schwierigkeiten und Son<strong>der</strong>fälle werden nachfolgend<br />
kurz beschrieben:<br />
1. Das erste Problem ergab sich aus <strong>der</strong> Tatsache, dass alle Keyuser <strong>der</strong> HFA am Projekt<br />
beteiligt werden sollten und das Projekt im Sommer, also in <strong>der</strong> Urlaubssaison,<br />
gestartet wurde. Durch ein großzügiges Bemessen <strong>der</strong> Zeitspannen zwischen den<br />
einzelnen Projektphasen konnte dem Umstand, dass zu fast keinem Zeitpunkt während<br />
<strong>der</strong> ersten Projektphasen alle Keyuser im Betrieb anwesend waren, aber<br />
erfolgreich begegnet werden.<br />
2. Eine weitere Schwierigkeit war, dass nicht alle Keyuser erfreut waren, an dem Projekt<br />
mitarbeiten zu müssen. Bei einigen war durchaus Überzeugungskraft und Motivationsarbeit<br />
nötig, um sie von <strong>der</strong> Wichtigkeit des Projekts zu überzeugen und ihnen<br />
klarzumachen, dass das Projekt ohne ihre Hilfe nicht ordnungsgemäß durchgeführt<br />
werden könnte.<br />
3. Einen Son<strong>der</strong>fall bei <strong>der</strong> Erfassung <strong>der</strong> Transaktionen in den Aktivitätsgruppen stellten<br />
manuell erstellte Transaktionen dar. Dabei handelt es sich um Transaktionen, die in<br />
<strong>der</strong> HFA erstellt wurden. Solche Transaktionen beginnen mit einem Z, damit sie eindeutig<br />
von <strong>SAP</strong>-Standardtransaktionen unterschieden werden können. Die manuell<br />
erstellten Transaktionen wurden nach Rücksprache mit jenen Mitarbeitern, die diese<br />
erzeugt hatten, in die entsprechenden Aktivitätsgruppen eingefügt.<br />
64
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
4. Nach dem Erfassen <strong>der</strong> Transaktionen durch die Keyuser stellte sich heraus, dass in<br />
den Aktivitätsgruppen des Einkaufs zu viele Transaktionen enthalten waren, die nicht<br />
benötigt wurden. Dies resultierte daraus, dass durch das Auswählen von Menüs sehr<br />
viele Untermenüs, und damit unzählige Transaktionen, in die entsprechenden Aktivitätsgruppen<br />
aufgenommen wurden. Nach Rücksprache mit dem verantwortlichen<br />
Keyuser erklärte sich dieser bereit, eine Liste mit den erfor<strong>der</strong>lichen Transaktionen zu<br />
erstellen. Diese Transaktionen wurden dann in die Aktivitätsgruppen<br />
HFA_V.KEYUSER und HFA_V.USER eingefügt, nachdem alle zuvor erfassten Transaktionen<br />
gelöscht waren.<br />
5. Es traten auch Son<strong>der</strong>fälle im Zusammenhang mit <strong>SAP</strong>-Benutzern auf. Es sind z. B.<br />
einige Benutzer für <strong>SAP</strong>-Berater eingerichtet, für die eine eigene Aktivitätsgruppe erstellt<br />
wurde. Diese Aktivitätsgruppe konnte natürlich nicht über das<br />
Organisationsmanagement zugeordnet werden. Sie wurde deshalb nach Abschluss<br />
des Projekts direkt an die entsprechenden Benutzer zugeordnet. Ein weiterer Son<strong>der</strong>fall<br />
war, dass von zwei Benutzern noch kein Personalstamm im Testsystem existierte.<br />
Das resultierte daraus, dass bei einem Neueintritt <strong>der</strong> Personalstamm nur im Produktivsystem<br />
angelegt wird. In <strong>der</strong> Regel wird dann zweimal jährlich eine sog.<br />
Mandantenkopie durchgeführt, mit <strong>der</strong> die Daten des Testsystems durch die Daten<br />
des Produktivsystems ersetzt werden. Nach einer solchen Mandantenkopie haben das<br />
Test- und das Produktivsystem also den gleichen Stand. Bis zur nächsten Mandantenkopie<br />
konnten die zwei betroffenen Benutzer also nicht in das<br />
Organisationsmanagement aufgenommen werden.<br />
6. Anfang Dezember 2001 musste das Projekt für eine kurze Zeitspanne an<strong>der</strong>en Arbeiten,<br />
die im <strong>SAP</strong>-System anfielen, weichen. Am 1. Dezember 2001 wurden sog.<br />
Support Packages in <strong>SAP</strong> R/3 eingespielt. Dabei handelt es sich um Korrekturprogramme,<br />
die aufgetretene Fehler in den verschiedensten <strong>SAP</strong>-Anwendungen<br />
beheben. Außerdem wurden mit den HR-Packages wichtige Än<strong>der</strong>ungen, die sich einerseits<br />
aufgrund <strong>der</strong> EURO-Umstellung und an<strong>der</strong>erseits durch gesetzliche<br />
Än<strong>der</strong>ungen, die die Entgeltabrechnung betreffen, ergaben, in das System eingespielt.<br />
Am 8. Dezember 2001 wurde dann die bereits erwähnte Mandantenkopie durchgeführt.<br />
Das Personalmanagement benötigte zum Testen <strong>der</strong> EURO-Umstellung einen<br />
aktuellen Datenbestand im Testsystem, weshalb die ursprünglich für Jänner 2002 geplante<br />
Mandantenkopie in den Dezember vorverlegt wurde.<br />
7. Durch das Vorverlegen <strong>der</strong> Mandantenkopie mussten vor dem Kopieren des Produktivsystems<br />
das Organisationsmanagement und sämtliche neuen und überarbeiteten<br />
Aktivitätsgruppen vom Testsystem in das Produktivsystem transportiert werden, da<br />
ansonsten nach <strong>der</strong> Mandantenkopie die ganze, bis dahin durchgeführt, Projektarbeit<br />
verloren gewesen wäre.<br />
8. Im Laufe <strong>der</strong> verschiedenen Kontroll- und Testphasen mussten auch einige neue Aktivitätsgruppen<br />
angelegt werden, die am Beginn des Projekts aus verschiedenen<br />
Gründen noch nicht berücksichtigt wurden. So vergaß man z. B. auf Aktivitätsgruppen<br />
für solche Tätigkeiten, die nur ein- o<strong>der</strong> zweimal jährlich durchgeführt werden mussten.<br />
Darunter fällt etwa die einmal pro Jahr durchzuführende Planung des nächsten<br />
Geschäftsjahres.<br />
Die angeführten Schwierigkeiten und Son<strong>der</strong>fälle konnten schließlich alle zufriedenstellend<br />
gelöst bzw. behandelt werden, wodurch ein erfolgreicher Abschluss des gesamten<br />
Projekts möglich war.<br />
65
6 Resümee<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
6.1 Datenschutz, Zugangskontrolle und Zugriffsschutz<br />
Der Datenschutz und die Absicherung elektronischer Datenbestände gegen jegliche Art<br />
von Gefahren stellt eine immer größere Herausfor<strong>der</strong>ung für alle Unternehmen dar, die<br />
mit entsprechenden Daten arbeiten. Waren früher in erster Linie Betriebe mit hohem Forschungs-<br />
und Know-How-Anteil davon betroffen, viel Wert auf Schutzvorkehrungen zu<br />
legen, so sind in <strong>der</strong> heutigen, wirtschaftlich schnelllebigen und hochtechnisierten Welt<br />
nahezu alle Unternehmen darauf angewiesen, entsprechende Sicherheitsvorkehrungen<br />
zu treffen. Kein Betrieb kann heutzutage auf den Einsatz von mo<strong>der</strong>ner Informationstechnologie<br />
verzichten, egal ob in <strong>der</strong> Produktion, in <strong>der</strong> Verwaltung o<strong>der</strong> in den restlichen<br />
betrieblichen Bereichen. Ein Arbeiten ohne den Einsatz von EDV ist kaum noch vorstellbar.<br />
Damit einhergehende Gefahren verursachen jährlich Schäden in Milliardenhöhe, und<br />
sind nicht selten mitverantwortlich für den wirtschaftlichen Untergang ganzer Unternehmen.<br />
Dabei drohen nicht nur kriminelle Handlungen und Datendiebstahl, son<strong>der</strong>n eine<br />
Vielzahl von Gefahren unterschiedlichen Ursprungs.<br />
Das IT-Sicherheitskonzept eines Unternehmens sollte sich aus dessen allgemeinen Sicherheitskonzept<br />
ableiten und jedes Unternehmen sollte sich zunächst mit <strong>der</strong> Frage<br />
beschäftigen, was Sicherheit für das Unternehmen selbst bedeutet [Grub02, 26].<br />
Viele Hardware- und Softwarehersteller haben den hohen Stellenwert, den die Sicherheit<br />
in Zusammenhang mit dem EDV-Einsatz einnimmt, längst erkannt und bieten seit einigen<br />
Jahren spezielle Lösungen an, um EDV-Systeme gegen die drohenden Gefahren zu<br />
schützen. Für Unternehmen gilt es nun, im Zuge <strong>der</strong> Anschaffung von EDV-Systemen<br />
großen Wert auf die durch das System gebotene Sicherheit zu legen, wobei <strong>der</strong> Faktor<br />
Sicherheit nicht nur als zusätzliche Eigenschaft, son<strong>der</strong>n als eine zentrale Funktion betrachtet<br />
werden sollte, damit ihr auch die nötige Aufmerksamkeit entgegengebracht wird.<br />
Sämtliche Maßnahmen, die nötig sind, um ein ausreichend sicheres EDV-System in ein<br />
Unternehmen zu integrieren, müssen genau geplant und konsequent umgesetzt werden,<br />
damit sowohl den For<strong>der</strong>ungen des Datenschutzgesetzes als auch den speziellen Sicherheitsanfor<strong>der</strong>ungen<br />
des jeweiligen Unternehmens entsprochen werden kann. Schon die<br />
kleinste Schwachstelle im System kann genügen, um das gesamte Sicherheitskonzept<br />
und dessen Wirksamkeit zu gefährden. Sicherheit sollte zu einem fixen und allgegenwärtigen<br />
Faktor in sämtlichen, betrieblichen Prozessen werden. Allen MitarbeiterInnen sollte<br />
durch Schulungen und Einweisungen die Wichtigkeit des Datenschutzes und <strong>der</strong> Datensicherheit<br />
bewusst gemacht werden. In diesem Zusammenhang muss auch großer Wert<br />
auf die angewendeten Systeme <strong>der</strong> Zugangs- und Zugriffssteuerung gelegt werden. Es ist<br />
zu prüfen, ob hier ein ausreichen<strong>der</strong> Schutz vorhanden ist bzw. ob durch den Einsatz<br />
neuerer Technologien ein vielleicht sogar um ein Vielfaches höherer Schutz erreicht werden<br />
kann.<br />
Erst wenn alle erfor<strong>der</strong>lichen baulichen und organisatorischen Maßnahmen getroffen sind,<br />
die entsprechende Hardware und Software installiert sind und sich alle Beteiligten den<br />
Sicherheitsanfor<strong>der</strong>ungen gemäß verhalten, können die drohenden Risiken auf ein akzeptables<br />
Mindestmaß gesenkt werden. Diese Minimierung des Risikos sollte in allen<br />
Unternehmen mit Nachdruck verfolgt werden, um dadurch einen reibungslosen Betriebsablauf<br />
gewährleisten zu können.<br />
66
6.2 Modellansatz versus <strong>SAP</strong> R/3-Projekt<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Das in <strong>der</strong> Hella Fahrzeugteile Austria GmbH & Co KG durchgeführte Projekt zur <strong>Vergabe</strong><br />
<strong>der</strong> Zugriffsberechtigungen in <strong>der</strong> betrieblichen Standardsoftware <strong>SAP</strong> R/3 verwirklichte,<br />
teilweise leicht modifiziert, einen Teil <strong>der</strong> Punkte jenes Modellansatzes, <strong>der</strong> eine möglichst<br />
effiziente und effektive Zuordnung von Benutzerzugriffsberechtigungen gewährleisten soll.<br />
An<strong>der</strong>e, zum Teil sehr wichtige Schritte des Modells, wurden durch das Projekt jedoch<br />
nicht behandelt. Abbildung 28 zeigt den Vergleich zwischen dem erstellten Modellansatz<br />
und dem R/3-Projekt gemessen an den einzelnen Schritten des Modells:<br />
MODELLANSATZ <strong>SAP</strong> R/3-PROJEKT<br />
Geschäftsprozesse NICHT BEARBEITET<br />
Informationsprozesse NICHT BEARBEITET<br />
Berechtigungsgruppen Aktivitätsgruppen<br />
Benutzergruppen Organisationseinheiten<br />
Zuweisung <strong>der</strong> Gruppen KONFORM<br />
Abb. 28: Vergleich zwischen Modell und Projekt<br />
Die Zugriffsberechtigungen, die im Zuge des Projekts bearbeitet wurden, wurden nicht auf<br />
<strong>der</strong> Basis von Geschäfts- und Informationsprozessen vergeben, son<strong>der</strong>n durch eine Reihe<br />
von Personen, die auch dafür verantwortlich waren, dass die benötigten<br />
Berechtigungsgruppen (Aktivitätsgruppen) erzeugt wurden. Durch diese Vorgehensweise<br />
verringerte sich zwar <strong>der</strong> Arbeitsaufwand des Projekthauptverantwortlichen, und er gab<br />
damit auch einen Teil <strong>der</strong> Verantwortung weiter, aber diese Art <strong>der</strong> Abwicklung birgt auch<br />
einige negative Aspekte. So kann <strong>der</strong> Projektleiter nicht alleine dafür sorgen, dass alle<br />
benötigten, jedoch keine darüber hinaus gehenden Zugriffsberechtigungen in den entsprechenden<br />
Aktivitätsgruppen enthalten sind. Es mangelt also sowohl an zentraler<br />
Verantwortung als auch an zentraler Kontrolle. Beide Faktoren sind beson<strong>der</strong>s in Bereichen<br />
<strong>der</strong> Sicherheit und des Datenschutzes enorm wichtig und dürfen daher nicht<br />
vernachlässigt o<strong>der</strong> sorglos abgegeben werden.<br />
Die durch das Modell vorgesehene Bildung von Berechtigungsgruppen wurde im R/3-<br />
Projekt durch das Erzeugen von Aktivitätsgruppen verwirklicht. Die Keyuser des Unternehmens<br />
statteten die Aktivitätsgruppen mit Zugriffsberechtigungen und allenfalls<br />
erfor<strong>der</strong>lichen Attributseinschränkungen aus. Dieser Projektschritt wurde jedoch nicht detailliert<br />
dokumentiert, da die Keyuser die Zugriffsberechtigungen direkt im R/3-System<br />
erfassten, ohne vorher entsprechende Unterlagen über die Aktivitätsgruppen und <strong>der</strong>en<br />
Inhalt angefertigt zu haben.<br />
Das Erzeugen von Benutzergruppen wird vom R/3-System zwar unterstützt, jedoch nicht<br />
die Möglichkeit, Berechtigungen an diese Benutzergruppen zuzuweisen. Aus diesem<br />
Grund wurden im Zuge <strong>der</strong> Projektabwicklung keine Benutzergruppen angelegt.<br />
67
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
Die Berechtigungen wurden bekanntlich über Organisationseinheiten, Stellen und Planstellen<br />
an die BenutzerInnen zugeordnet, was dem Konzept <strong>der</strong> Benutzergruppen<br />
einerseits zwar sehr nahe kommt, an<strong>der</strong>erseits kommt es durch die gleichzeitige Berechtigungszuweisung<br />
an Planstellen und Stellen bzw. Organisationseinheiten aber zu einer<br />
simultanen Gruppen – und Einzelvergabe, was sich u. a. negativ auf die Einheitlichkeit<br />
des Berechtigungssystems auswirkt.<br />
Der letzte Punkt des Modellansatzes fand schließlich auch im <strong>SAP</strong>-Projekt Anwendung.<br />
Dort wurden die Aktivitätsgruppen an Organisationseinheiten, Stellen und Planstellen zugewiesen,<br />
und dadurch die BenutzerInnen mit Zugriffsberechtigungen ausgestattet.<br />
Basierend auf dem angestellten Vergleich zwischen Modellansatz und Projekt wird nun<br />
noch kurz die folgende Fragestellung untersucht: Welche Verbesserungen bzw. Einbussen<br />
könnten in <strong>der</strong> Hella Fahrzeugteile Austria entstehen, wenn man die Gesamtheit <strong>der</strong><br />
Zugriffsberechtigungen auf Basis des vorgestellten Modellansatzes neu vergeben würde?<br />
Folgende Verbesserungen könnten realisiert werden:<br />
• Zentralisierung <strong>der</strong> gesamten Zugriffsschutz-Administration<br />
• <strong>Vergabe</strong> sämtlicher, systemübergreifen<strong>der</strong> Zugriffsberechtigungen auf <strong>der</strong> Basis<br />
eines Modells bzw. einer Datensammlung<br />
• Durchgehende und detaillierte Dokumentation<br />
• Erhöhung <strong>der</strong> Nachvollziehbarkeit und ev. auch <strong>der</strong> Wartungsfreundlichkeit<br />
Demgegenüber stünden u. a.:<br />
• ein ungleich hoher Projektaufwand, da nicht nur die Zugriffsberechtigungen in <strong>SAP</strong><br />
R/3, son<strong>der</strong>n auch in Lotus Notes, Windows 2000 und Windows NT neu vergeben<br />
werden müssten<br />
• Dazu käme noch die Notwendigkeit, Geschäfts- und Informationsprozesse abbilden<br />
zu müssen, da diese nicht in erfor<strong>der</strong>lichem Ausmaß vorhanden sind.<br />
Die Entscheidung, ob in <strong>der</strong> Hella Fahrzeugteile Austria ein neues, umfassendes Projekt<br />
zur <strong>Vergabe</strong> <strong>der</strong> Zugriffsberechtigungen erwogen bzw. durchgeführt wird, wird von verschiedenen<br />
Faktoren abhängen. Wichtige Punkte werden dabei sicherlich <strong>der</strong> Stellenwert<br />
von Datenschutz und Datensicherheit innerhalb des Unternehmens und das Sicherheitsbewusstsein<br />
<strong>der</strong> Entscheidungsträger bilden, gleichzeitig wird jedoch <strong>der</strong> zu erwartende,<br />
hohe Projektaufwand ein sehr wichtiges Entscheidungskriterium darstellen. Und schließlich<br />
wird auch mitentscheidend sein, ob das Ergebnis des R/3-Berechtigungsprojekts<br />
insgesamt als zufriedenstellend gewertet und <strong>der</strong> entstandene Zugriffsschutz als ausreichend<br />
betrachtet wird.<br />
Es bleibt also abzuwarten, ob das bestehende System <strong>der</strong> <strong>Vergabe</strong> <strong>der</strong> Zugriffsberechtigungen<br />
in <strong>der</strong> HFA in Zukunft beibehalten wird, o<strong>der</strong> ob doch die Notwendigkeit entsteht,<br />
die Zugriffsberechtigungen entsprechend des beschriebenen Modellansatzes zur Gänze<br />
neu zu vergeben.<br />
68
Anhang<br />
Literaturverzeichnis<br />
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
[Adam95] Adam, Uwe: Einführung in die Datensicherheit: Probleme und Lösungen.<br />
Vogel, Würzburg 1995.<br />
[Dohr96a] Dohr, Walter: Das österreichische Datenschutzgesetz. In: Fleissner, P.;<br />
Choc, M. (Hrsg.): Datensicherheit und Datenschutz. Studien-Verlag, Innsbruck<br />
<strong>Wien</strong> 1996, S. 83-116.<br />
[Dohr96b] Dohr, Walter: Datenschutz in internationalen Organisationen. In: Fleissner,<br />
P.; Choc, M. (Hrsg.): Datensicherheit und Datenschutz. Studien-Verlag,<br />
Innsbruck <strong>Wien</strong> 1996, S. 139-160.<br />
[Dorn99] Dorn, Jürgen: Informationsmanagement für Wirtschaftsinformatiker. Vorlesungsskriptum,<br />
TU <strong>Wien</strong> 1999.<br />
[Geig00] Geiger, Marcel: Sicherheitsaspekte in Unternehmensnetzwerken.<br />
http://www.utk.ch/archiv/2000/3/seit2933.htm, 2000-09-10, Abruf am<br />
2002-02-19.<br />
[Grub02] Gruber, Siegfried: Beko setzt auf Security. In: Nikoll, H. (Hrsg.): IT & T Business<br />
03/02. it media & consulting, Klosterneuburg 2002.<br />
[Jahn01] Jahns, Angela: <strong>SAP</strong> AG investiert in humanIT.<br />
http://www.humanit.de/de/humanit/pressereleases/0102/<br />
pi_sap_ventures_de.pdf, 2001-02-05, Abruf am 2002-01-12.<br />
[KeKr91] Kersten, Heinrich; Kreutz, Hartwig: Sicherheit unter dem Betriebssystem<br />
Unix. Oldenbourg, München <strong>Wien</strong> 1991.<br />
[Kers91] Kersten, Heinrich: Einführung in die Computersicherheit. Oldenbourg, München<br />
<strong>Wien</strong> 1991.<br />
[Köhn99] Köhntopp, Marit: <strong>Technische</strong> Randbedingungen für einen datenschutzgerechten<br />
Einsatz biometrischer Verfahren. In: Horster, P. (Hrsg.):<br />
Sicherheitsinfrastrukturen. Vieweg, Wiesbaden 1999, S. 177-188.<br />
[KüSc97a] Kühn, Ulrich; Schläger, Uwe: Datenschutz in vernetzten Computersystemen.<br />
Datakontext, Frechen-Königsdorf Köln 1997.<br />
[KüSc97b] Kühn, Ulrich; Schläger, Uwe: Datenschutz in vernetzten Computersystemen.<br />
Datakontext, Frechen-Königsdorf Köln 1997, S. 122-133.<br />
[Magn99] Magnus, Nils: Wie sicher ist Linux? http://www.unix-ag.uni-kl.de/~linux/<br />
Linuxtag99/wie-sicher-ist-linux.html, Abruf am 2001-10-25.<br />
[Pflü00] Pflüger, Jörg: Datenschutz und Datensicherheit, Österreichisches Datenschutzgesetz.<br />
Vorlesungsskriptum 2000.<br />
69
Systematische <strong>Vergabe</strong> von Benutzerzugriffsberechtigungen<br />
[PiFl96] Piller, Ernst; Fleissner, Peter: Gefahren und Gefährdungen. In: Fleissner,<br />
P.; Choc, M. (Hrsg.): Datensicherheit und Datenschutz. Studien-Verlag,<br />
Innsbruck <strong>Wien</strong> 1996, S. 217-240.<br />
[PrKö99] Probst, Thomas; Köhntopp, Marit: Datenschutzgerechter und datenschutzför<strong>der</strong>n<strong>der</strong><br />
Einsatz von biometrischen Verfahren. http://www.rewi.huberlin.de/Datenschutz/DSB/SH/projekte/biometri/<br />
bsibabio.htm, Abruf am 2001-10-25.<br />
[Ruef00] Ruef, Marc: Grundlagen biometrischer Authentifikation.<br />
http://www.utk.ch/archiv/2000/4/seit2628.htm, 2000-12-15, Abruf am 2001-<br />
10-25.<br />
[ScWe00] Schipper, Johannes; Wehr, Markus: Biometrische Methoden.<br />
http://www.infosys.tuwien.ac.at/Teaching/Courses/AK2/vor99/t4, Abruf am<br />
2001-10-20.<br />
[Szel01] Szelgrad, Martin: Kriminelle Kollegen. In: Flatscher, A. (Hrsg.): Telekommunikationsreport.<br />
Report-Verlag, <strong>Wien</strong> Oktober/2001.<br />
[VaBu00] Van Buuren, Jelle: Neue EU-Richtlinie zum Schutz <strong>der</strong> Privatsphäre im<br />
Informationszeitalter vorgeschlagen.<br />
http://www.heise.de/tp/deutsch/inhalt/te/8378/1.html, 2000-07-14, Abruf am<br />
2002-01-14.<br />
[VonA00] Von Ah, Marc: Biometrie: Chancen und Risiken.<br />
http://www.infoweek.ch/archive/a_single.cfm?artikelx=4600, Abruf am<br />
2001-10-25.<br />
70