Homepage > Catalog > Computer Science - Software

Bereitstellung von Microsoft Access-Datenzugriffsseiten mittels Microsoft Windows Server-Technologien

Name: Bereitstellung von Microsoft Access-Datenzugriffsseiten mittels Microsoft Windows Server-Technologien
Price: 47.95 EUR
Availability: InStock
Author: Dipl.-Wirt.-Inf. (FH) Frank Ritter
ISBN: 978-3-640-19329-5

Diploma Thesis, 2006

85 Pages, Grade: 1,3

Dipl.-Wirt.-Inf. (FH) Frank Ritter (Author)

Excerpt

Thematisierung

Die vorliegende wissenschaftliche Ausarbeitung thematisiert den informationstechnischen Fachbereich der seitens Microsoft entwickelten Technologie »Microsoft Access-Datenzugriffsseiten« als Möglichkeit, Datenbankinhalte zentralisiert für Onlinezugriffe bereitzustellen. Diesbezüglich werden administrative Obliegenheiten respektive programmiertechnischer Gesichtspunkte aus Sichtweise der serverseitigen Bereitstellung obiger Technologie fokussiert ausgearbeitet.

Zielsetzung

Es soll dem Leser eine fachliche Einschätzung aus operativer Sichtweise, für die erfolgreiche Realisation einer Datenbankbereitstellung mittels Microsoft Access-Datenzugriffsseiten ermöglicht werden. Um einen erhöhten Realitätsbezug herzustellen, werden für ein exemplarisches Praxissystem die seitens einer deutschen Einzelunternehmung verwendeten Access-Datenzugriffsseiten vorgestellt. Diese verfolgt den Schwerpunkt des »Executive Search«, welcher Dienstleistungen im Rahmen der Besetzung von vakanten Führungspositionen in Unternehmungen umsetzt.

Aufbau der Ausarbeitung

- Mittels einer Einführung werden im ersten Kapitel informationstechnische Grundbegriffe in Bezug auf die Anwendung obiger Technologie charakterisiert.
- Innerhalb der folgenden beiden Kapitel werden administrativ erforderliche Operationen, differenziert in Frontend- sowie Backend-Softwarestruktur ausgearbeitet.
- Die anschließende Einbeziehung beider softwareseitiger Perspektiven wird in Bezug auf deren Kooperation sowie zu berücksichtigenden Sicherheitsaspekten dieser thematisiert.
- Innerhalb des fünften Kapitels werden anhand einer Praxisrealisation der Datenbankbereitstellung mittels Microsoft Access-Datenzugriffsseiten exemplarisch deren Anforderungen sowie praktische Funktions- und Wirkungsweisen innerhalb einer Mehrbenutzerumgebung ausgearbeitet.
- Es werden folglich strategisch, ökonomische Gesichtspunkte für die Anwendung obiger Technologie thematisiert.
- Die Schlussbetrachtung stellt die in sämtlichen vorherigen Kapiteln erarbeiteten Inhalte, in Form einer ergebnisorientierten Aufführung, zusammenfassend dar.

Anmerkungen zur formalen Gestaltung

Um den Lesefluss dieser wissenschaftlichen Ausarbeitung nicht unnötig zu beeinträchtigen, wurden umfangreichere Ausführungen sowie (meist auszugsweise dargestellte) Quelltexte innerhalb des Anhangs (III. Abbildungen / Tabellen / Quelltexte) aufgenommen.

Das vorliegende Dokument wurde in Form eines aktiven PDF-Dokuments verfasst, so dass eine Navigation innerhalb dieses mittels Hyperlinks erfolgen kann. Diese sind optisch von inhaltlich wissenschaftlichen Textbestandteilen mittels hellblaufarbiger, unterstrichener Schriftdarstellung abgegrenzt.

Fachbegriffe werden innerhalb dieser wissenschaftlichen Ausarbeitung ausschließlich wie folgt mittels Kurzform dargestellt, falls diese seitens der Autoren der verwendeten Literatur in explizit dieser abgekürzten, nachfolgend exemplarischen Form ersichtlich sind:

Eigens verwendete Abkürzungen des Verfassers, welche nicht zwangsweise Fachbegriffen entsprechen, werden wie folgt vorgenommen und dienen aufgrund häufiger Verwendung selbiger Begriffe lediglich der Textreduzierung:

Aufgrund dieser einheitlichen Festlegung ist letztere Anwendung innerhalb von Kapitelüberschriften nicht vorzufinden. Zudem sind sämtliche, in abgekürzter Form verwendeten Begriffe obiger beider Festlegungen innerhalb des Abkürzungsverzeichnisses (VIII) separat aufgeführt.

Im Folgenden werden die Architektur respektive Funktionsweise von Datenbank-Managementsystemen, diesen gestellte Anforderungen, sowie in diesem Kontext der Begriff der Datenmodelle aufgezeigt.

1.1 Datenbank-Managementsysteme (DBMS)

DBMS ¹ basieren auf theoretisch entwickelten Datenmodellen (DM), welche komplexe Modellierungskonstrukte zur Verfügung stellen, um ein präzises, virtuelles Abbild realer, unternehmensbezogener Vorgaben divergenter Geschäftsprozesse generieren zu können. Bei dieser abstrahierenden Vorgehensweise wird auf relevante Ausschnitte der Realvorgaben fokussiert, so dass ein exaktes Abbild realer Bereichsvorgaben resultieren kann (als solches bezeichnete »Miniwelt«), um letztlich im Gesamtumfang der Anforderungen an die IT-Infrastruktur ² einer Unternehmung zur Realisierung ökonomischer Zielsetzungen des DBMS positiv beitragen zu können.³ Hierbei gelten nachfolgende Anforderungen an die mittels des DBMS verwaltete(n) Datenbank(en) (DB) ⁴:⁵

- Speicherung logisch verbundener Datenbestände
- Redundanz-Minimierung
- Abfrage-& Änderungsmöglichkeiten (Manipulationen) von Datenbeständen
- Logische Unabhängigkeit der Datenbestände von ihrer physischen Struktur
- Zugriffsschutz
- Integrität ⁶
- Mehrbenutzerzugriff (engl. Concurrency)
- Technische Zuverlässigkeit, Ausfallsicherheit, Kontrollierbarkeit

Die nachfolgende Abbildung 01 (S. 02) veranschaulicht die grundlegende Architektur eines DBMS, dessen Datenbankmanager das Kernstück bildet, indem dieser als zentrale Vermittlungsschnittstelle agiert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 01: DBMS-Architekturübersicht (Quelle: Anlehnung an Kemper, A., Eickler, A. (2004), S. 27)

Die Aufgabenbereiche eines DBMS begrenzen sich nicht auf die ausschließliche Umsetzung der Speicherung sowie Verarbeitung von Dateninhalten, sondern schließen auch die Gewährleistung der Konsistenz dieser ein. Semantische Integritätsbedingungen, welche aus Eigenschaften der modellierten »Miniwelt« abgeleitet werden können, realisieren die Erhaltung der Konsistenz der Dateninhalte bei Systemfehlern, ins Besondere im Einsatz unter Bedingungen von Concurrency sowie den Schutz vor unerlaubten Manipulationsvorgängen. Auch die funktionalen Abhängigkeiten aus der relationalen DB-Entwurfstherorie können zu diesen Bedingungen aufgefasst werden. Eine zentrale, automatische Überprüfung von Integritätsbedingungen ist in Relationalen Datenbanksystemen ⁷ seit ANSI-Standardisierung ⁸ SQL -89⁹ (gefolgt von SQL-92) implementiert, so dass veränderliche oder wachsende Konsistenzanforderungen nur einmalig gegenüber des DBMS in deklarativer Form bekannt gegeben werden, ohne manuelle Veränderungen innerhalb sämtlicher konnektierter Anwendungsprogramme durchführen zu müssen.¹⁰

1.1.1 Datenmodelle (DM)

Aus Anforderungssicht der Datenmodellierung ¹¹ stellen DM (im praktischen Sprachgebrauch oftmals als Datenbankmodelle bezeichnet, um unmissverständlichen Bezug zu Datenbanksystemen herzustellen) bezüglich vorrangig permanent gespeicherter Daten, generische Strukturen sämtlicher Datenobjekte ¹² respektive Beziehungen untereinander sowie anwendbare DB-Operatoren ¹³ und deren Wirkungsweisen dar und beschreiben diese mittels grafischer Notationen meist in Form von Diagrammen respektive textueller Beschreibungen. Es sind zielgerichtet sämtliche relevante Merkmale vollständig und widerspruchsfrei darzustellen, um eine Datenbankanwendung konzeptuell modellieren zu können. DM bestehen aus den Teilbereichen der Datendefinitionssprache (≙Datenbeschreibungssprache, engl. Kurzform »DDL« ¹⁴ ) sowie der Datenmanipulationssprache (≙Datenverarbeitungssprache, engl. Kurzform »DML« ¹⁵ ) und bilden nachfolgende Funktionen ab:¹⁶

- DDL: Beschreibung der Struktur abzuspeichernder Datenobjekte, wobei die
Strukturbeschreibung aller Datenobjekte als Datenbankschema (Metadaten ¹⁷ ) bezeichnet wird
- DML: Anfrage-& Datenmanipulationssprache (Abfragen, Einfügen, Ändern

oder Löschen von Nutzdaten, engl. Query Language)

Zur Modellierung eines DM stehen nachfolgende acht Verfahren (ausgenommen in der Praxis seltener vorzufindender Misch- und Nebenformen), untergliedert in zwei Kategorien (4:4), zur Verfügung:¹⁸

1 Konzeptuelle Entwurfs-Datenmodelle (nachfolgend »KEDM« bezeichnet)

- Entity-Relationship-Modell (ERM) findet häufigste Anwendung, seltener auch in der Praxis als Gegenstand-Beziehungs-Modell« bezeichnet
- Semantisches Datenmodell
- Funktionales Datenmodell
- Objektorientiertes Entwurfsmodell

Obige KEDM eignen sich aufgrund ihrer theorieelastischen Ausprägungen nur bedingt als Implementationsschemata für eine praktische Datenmodellierung, da diese gänzlich deskriptive Modelle darstellen. Aufgrund dieser strukturell unvermeidbaren Vernachlässigung praxisrelevanter Bedingungen wird die logische Ebene eines DBMS von einem der innerhalb nachfolgender Tabelle aufgeführten DM abgebildet.

2 Logische Implementations-Datenmodelle (nachfolgend »LIDM« bezeichnet)

Nachfolgende Tabelle zeigt die Differenzierung von DM für eine logische Implementierung gemäß häufigster praktischer Verwendung (absteigend) nach aktuellem Stand dieser wissenschaftlichen Ausarbeitung innerhalb vier Konzepte:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 01: Differenzierung Logischer Implementations-Datenmodelle (Quelle: Anlehnung an Schicker, E. (2000), S. 57-59)

1.1.2 Client-Server-Datenbankarchitektur

Bei verteilten Datenbanksystemen (nachfolgend »DBS« bezeichnet) übernehmen Sender sowie Empfänger von Datenanfragen beziehungsweise Datenantworten gleichermaßen Server- sowie Client-Funktionalitäten, so dass diese DBS-Architektur in Peer-to-Peer-Netzwerken ²⁹ Verwendung findet. (Auf Netzwerktopologien ³⁰ wird innerhalb dieser wissenschaftlichen Ausarbeitung aus Gründen der Anforderungen an die Gesamtkomplexität nicht eingegangen, jedoch ist das Verständnis dieses Fachbereichs für den weiteren Verlauf relevant.) Nachfolgende Abbildung verdeutlicht die grundlegenden, architektonischen Unterschiede von verteilten DBS gegenüber zentralisierten Lösungen in Form einer Client-Server-Datenbankarchitektur (nachfolgend »CSDA« bezeichnet):

Abb. 02: Zentrale versus verteilte Datenbanksysteme (Quelle: Anlehnung an Schicker, E. (2000), S. 53)

CSDA sind historisch durch den ökonomischen Gedanken, kostenintensive Ressourcen wie beispielsweise Massenspeichersysteme sowie Prozessorleistung zentralisiert zur Verfügung zu stellen, entstanden. Von anfänglich zentralisierten Dateiservern (Fileserver-Lösungen der Firma Novell) wurde dieser Gedanke ebenso für die Haltung und Verarbeitung von Massendaten zu Datenbank-Serversystemen für die Umgebung einer CSDA entwickelt, welche maßgebend nachfolgende vier Kriterien erfüllen sollen – diese jedoch mit steigendem Anwendungsumfang in der Praxis zunehmend schwieriger realisierbar werden.

Abbildung in dieser Leseprobe nicht enthalten

Eine CSDA besteht aus den beiden logischen Komponenten der Clients (Dienste-Nutzer) sowie einem oder mehrerer Server (Dienst(e)-Anbieter), wobei diese Rollen letztlich nur durch Ihre jeweils ausgeübten, per Software spezifizierten Funktionen definierbar sind, so dass beispielsweise ein Serversystem als Client operiert, indem dieser Datenbestände eines weiteren Servers abfragen kann, um eine Clientanfrage vollständig beantworten zu können. Eine Einteilung von Hardwaresystemen in die Begriffsdefinitionen des Frontends ³⁴ (clientseitig) sowie Backends ³⁵ (serverseitig) ist durchaus in der Praxis gebräuchlich, vernachlässigt jedoch, dass beide obige Begriffe ausschließlich im Kontext mit Software-Komponenten stehen und keinerlei Hardwarebezug aufweisen.³⁶

1.1.3 Verteilungsebenen eines Datenbanksystems

Es werden mittels nachfolgender Tabelle fünf Verteilungsebenen eines DBS differenziert, um dessen divergente Funktionalitäten, welche mittels eines DBMS zu einer ganzheitlichen Struktur vereint werden, aufzuzeigen:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 02: Verteilungsebenen eines Datenbanksystems (Quelle: Anlehnung an Brackly, G. (2006), S. 119)

Die am häufigsten in Unternehmungen anzutreffende Form ist, dass Präsentations- sowie Steuerungsebene (P+S) explizit clientseitig übernommen werden, wobei je nach Einsatzszenario zudem die Ebene der Anwendungslogik (A) sowie seltener Bestandteile der Datenverwaltungsebene (G) zu den clientseitigen Aufgabenfeldern zählen (Maximaltätigkeitsfeld der Clients = P+S+A+G), hingegen die gesamte Datenhaltung sowie -verwaltung (D+G) explizit serverseitig mittels des DBMS übernommen werden, welches zudem meist Bestandteile von Aufgabenfeldern der Ebene der Anwendungslogik realisiert (Maximaltätigkeitsfeld des serverseitigen DBMS = D+G+A). Die Ebenen der Anwendungslogik (A) sowie Datenverwaltung (G) können theoretisch ebenso geteilt von Client-Applikationen sowie Serverdiensten (beispielsweise so genannte »Stored Procedures« ³⁹ ) realisiert werden. Zugleich kann die Ebene der Datenhaltung (D) über mehrere DB-Server verteilt werden, welche als so genannte »Verteilte Datenbanken« (siehe Kap. 1.1.2, S. 06) zu charakterisieren sind, so dass diese jeweils bei Anfragen als Server und/oder als Client in Bezug auf im Clusterverbund zusätzlich eingebundene Server agieren.⁴⁰

1.1.4 Three Tier-Architekturmodell für Microsoft Access-Datenzugriffsseiten

Eine zweischichtige DB-Anwendungsarchitektur (nachfolgend »2T-Architektur« bezeichnet, engl. »Two Tier Architecture«) ist eine CSDA, die softwareseitig als zweischichtiges System aufgebaut ist, so dass die Rechenkapazität signifikant auf sämtliche Clients (sog. Fat-Clients ⁴¹ ) ausgelagert wird, um die Ressourcen des / der Server(s) zu entlasten, so dass serverseitig ausschließlich die DB-Applikation

bereitgestellt wird und sämtliche Clients die gesamte Logik sowie Darstellung der Benutzerschnittstelle ausführen.

Dieser eingeschränkten Anwendungsarchitektur entgegen, stellt die Multi-Tier-Architektur (mehrschichtige Architektur, engl. »Multitier Architecture«) eine Weiterentwicklung dar, so dass die DB-Applikation in mehrere diskrete Komponenten aufgeteilt werden kann. Meist erfolgt diese Differenzierung in die so genannte Dreischichtenarchitektur (nachfolgend »3T-Architektur« bezeichnet, engl. »Three Tier Architecture«), bei welcher eine Einteilung in Datenbank, Anwendungslogik und Präsentation (Web-Oberfläche oder Client-Applikation) erfolgt, wobei jede dieser Komponenten auf separaten Servern operieren kann.

Bei der 3T-Architektur agiert indessen das Thin-Client -Konzept⁴², so dass ein Client seine Daten möglichst vollständig von einem Server bezieht, um dessen Ressourcen für eine Vielzahl an Clientanfragen freizugeben. Dem zu folge existiert bei dieser dreischichtigen Architektur eine zusätzliche Logikschicht, welche die Datenverarbeitung vornimmt.⁴³

Aufgrund des theoretisch beliebig weiter fortsetzbaren Aufteilungsprinzips, ins Besondere in Bezug auf Bestandteile der Logikschicht (siehe nachfolgende Tabelle), wird diese Anwendungsarchitektur ebenso als »n-schichtige Architektur« bezeichnet. Nachfolgende Tabelle stellt das Reihen-/ Schichtkonzept der 3T-Architektur sowie dessen Obliegenheiten dar:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 03: Three Tier-Architekturmodell (Quelle: Anlehnung an Wikipedia (2006a), o.S.; Mills, R. (2001), S. 303)

Mehrschichtige Systemarchitekturen wie die obige dreischichtige Architektur eignen sich ins Besondere für eine Skalierung, da die einzelnen Schichten logisch voneinander getrennt sind. So kann beispielsweise die Datenschicht auf einem zentralen Datenbank-Server operieren, die Logikschicht auf Workgroup-Servern und letztlich befindet sich die Präsentationsschicht auf der jeweiligen Workstation

des clientseitigen Benutzers. Diese Form äußert ebenso vorteilige Eigenschaften während Entwicklungs- sowie Wartungsphasen, da einzelne Schichten separat austauschbar sind, ohne Veränderungen anderer Schichten herbeiführen zu müssen.

Die nachfolgende Abbildung 03 (S. 10) veranschaulicht die Differenz von 2T- gegenüber 3T-Schichtarchitekturen, hingegen wird innerhalb Abbildung 04 (S. 10) diese Architektur (3T) im Hinblick eines DB-Onlineeinsatzes mittels Microsoft Access-Datenzugriffsseiten (DAP) dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 03: Two Tier-/ Three Tier-Schichtarchitektur (Quelle: Entnahme aus Wikipedia (2006c), o.S.)

Abbildung in dieser Leseprobe nicht enthalten

Abb. 04: Three Tier-Architektur für Microsoft DAP-Onlinezugriff (Quelle: Anlehnung an HelpdeskTools (2006), o.S.)

1.2 Begriffsdefinitionen

Im Folgenden wird nach erfolgter Einführung in allgemeine Thematiken von DBS auf Microsoft Access-Datenzugriffsseiten fokussiert und beginnend deren Bedeutung aufgezeigt.

1.2.1 Data Access Pages (DAP) als Bestandteil von Microsoft Access

DAP (dt. Datenzugriffsseiten) ermöglichen die Interaktion mittels Webbrowser ⁴⁴ mit Microsoft Access-Datenbanken (nachfolgend »MSADB« bezeichnet), ohne dass eine serverseitige Scriptsprache (beispielsweise finden Microsofts Scriptsprachen ASP ⁴⁵ / ASP.NET ⁴⁶ unter anderem für diese Zwecke Verwendung) angewandt werden muss.⁴⁷ Diese Form des DB-Zugriffs ermöglicht die Realisierung der Nutzung eines global zugänglichen Microsoft Access-Projekts als DBS, so dass Clients via Intranet ⁴⁸ (LAN ⁴⁹ oder VPN -Verbindung^⁵⁰ über Interneteinwahl) oder unter sicherheitsbezogenen Zusatzbedingungen (siehe Kap. 3.2, S. 33) auch per unmittelbarer Internetverbindung Zugriff auf das DBS gewährleistet werden kann, technisch so umgesetzt, als wären diese lokal mit den jeweiligen Quellen der MSADB verbunden.

Bei DAP handelt es sich um HTML-Seiten, welche mit Hilfe eingelagerter ActiveX-Controls (siehe Kap. 1.2.2, S. 16) in der Lage sind, eine vollständige Eingabemaske respektive Datensatznavigator sowie Tabellenansicht webbrowser-optimiert bereitzustellen, wobei diese Seiten nicht innerhalb der DB-Struktur, sondern als externe HTM(L)-Dateien gespeichert werden. Zusätzliche Verbindungsinformationen werden als XML ⁵¹ -Quelltext in die jeweilige HTM(L)-Seite integriert, so dass innerhalb der MSADB (MDB ⁵² -/ ADP ⁵³ -Dateiformat) lediglich grundsätzlich lokale Pfadangaben im Sinne von Daten- Verknüpfungsinformationen ⁵⁴ zu einer beliebigen Anzahl an DAP inklusiv abgespeichert werden.⁵⁵

Nachfolgende Abbildung 05 (S. 12) zeigt den DAP-Aufruf (Intranetlösung in firmeninternem LAN) mittels des Webbrowsers Microsoft Internet Explorer 6.0 SP2 (versionsunabhängig nachfolgend »MSIE« bezeichnet):

Abbildung in dieser Leseprobe nicht enthalten

Abb. 05: Screenshot – DAP-Aufruf der Grundstruktur respektive Datensatznavigator mittels Microsoft Internet Explorer (Intranetzugriff)

1.2.1.1 Funktionsumfang

Neben dem im vorherigen Kapitel 1.2.1 (S. 11) aufgezeigten, grundsätzlichen MSADB-Zugriff mittels DAP erstrecken sich deren funktionale Einsatzmöglichkeiten über Datensatz-Abfrage- sowie -Manipulationsfunktionalitäten (SQL-Syntax: »SELECT«, »INSERT«, »UPDATE«, »DELETE«) hinaus auf clientseitig dargestellte Mehrfachgruppierungen (SQL-Syntax: »GROUP BY«), Berechnungen sowie Sortier- und Filterkriterien für SQL-Operationen. Vorteilig äußert sich am DAP-Dateiformat (grundsätzlich ».htm« / ».html«), dass sämtliche Funktionalitäten der Hypertextsprache HTML in das DAP-Projekt integriert werden können, so dass beispielsweise innerhalb dieses zusätzliche Hyperlinks ⁵⁶, Grafiken, Befehlsschaltfächen (beispielsweise Buttons, Input Fields, Check Boxes etc.), statische Tabellen bis hinzu aktiven Elementen, welche mittels Scriptsprachen in der Praxis meist innerhalb von Framesets ⁵⁷ oder so genannten Inline Frames ⁵⁸ integriert, den Funktionsumfang sowie zudem Aspekte der Usability ⁵⁹ der DAP gesamtheitlich im Sinne einer globalen Website ⁶⁰ komplettieren.

Zu berücksichtigende Einschränkungen dieser technologischen Entwicklung werden in Kapitel 1.2.1.3 (S. 14), sowie technische Ausführungen bezüglich DAP-Funktionsweisen in Kapitel 2.1 (S. 19) thematisiert.

Ebenso erlauben DAP uneingeschränkt die Anbindung an das für Großdatenbanken konzipierte DBMS »Microsoft SQL Server« ⁶¹ mittels selbiger DAP-Technologien.⁶²

1.2.1.2 Historie

Mit der Einführung von Microsoft Access 2000 als Bestandteil der Microsoft Office 2000-Versionsreihe ⁶³, wurden Microsoft Access DAP erstmalig eingeführt. Zuvor wurden, innerhalb nachfolgender Tabelle aufgeführte Möglichkeiten zum Zugriff und/oder der Interaktion mit MSADB mittels Webbrowser unterstützt:⁶⁴

Abbildung in dieser Leseprobe nicht enthalten

Tab. 04: Microsoft Access Datenbankzugriffs-/ Interaktionsmöglichkeiten (<Version 2000) (Quelle: Anlehnung an o.V. (2004a), S. 294)

Für die Realisierung von DAP-Projekten empfiehlt sich gemäß aktuellem Stand dieser wissenschaftlichen Ausarbeitung die clientseitige, einheitliche Nutzung des DBS »Microsoft Access 2003« zur MSADB-Verwaltung respektive dazugehöriger DAP. Für explizit ausschließlich lesenden Zugriff, um somit keinerlei Änderungen innerhalb der MSADB-Strukturen durchzuführen, können ebenso die Softwareversionen 2000 / 2002 (letztere beinhaltet DAP-Weiterentwicklungen) obiges DBS verwendet werden. Vorherig veröffentlichte DBS-Softwareversionen (Microsoft Access 95 / 97) sind auf Zugriffsverfahren obiger Tabelle (Tab. 04, S. 14) angewiesen, so dass sich ein Versionsupdate in der Praxis meist als unverzichtbar herausstellt.⁶⁷

1.2.1.3 Technische Client-Voraussetzungen & -Kompatibilität

Für die DAP-Nutzung wird clientseitig der Webbrowser »Microsoft Internet Explorer« (ab Version 5.0) vorausgesetzt, so dass bei Verwendung alternativer Webbrowser ein Hinweis zur vorliegenden Inkompatibilität erscheint sowie ein Download-Link der kostenfreien, aktuellen MSIE-Version (Version 6.0 vor Einführung von 7.0, derzeit 7.0 Beta 3 / engl.) angeboten wird.⁶⁸ Die innerhalb Microsoft Office enthaltene DBS-Komponente »Microsoft Access« wird für den DAP-Zugriff nicht zwangsweise benötigt – dennoch sind sämtliche im Webbrowser des Clients dargestellten DB-Formulare in ihrem visuellen Erscheinungsbild sowie im gesamten Funktionsumfang exakt lokal verwendeten Microsoft Access-Formularen ^⁶⁹, welche integriert in einer MSADB mittels Microsoft Access geöffnet werden, angeglichen. Eingeschränkt wird das DAP- Zugriffsverfahren jedoch, falls clientseitig keine Lizenz von Microsoft Office 2000 / XP / 2003 respektive Microsoft Access des gleichen Versionsumfangs verfügbar ist, da das hierfür kostenfrei von Microsoft zur Verfügung gestellte Softwarepaket mit der Bezeichnung »Microsoft Office Web Components« (siehe Kap. 1.2.3, S. 17) ausschließlich lesenden Datenzugriff innerhalb von DAP-Projekten erlaubt. Der somit mögliche Verzicht auf obige lizenzierpflichtige Softwarekomponente vergrößert einerseits deutlich den clientseitigen Handlungsfreiraum ins Besondere innerhalb einer gesicherten Internet-Zugriffsumgebung, ist allerdings je nach praktischem Einsatzszenario oftmals gleichermaßen aufgrund der eingeschränkten Zugriffsattribute »Read Only / Share« (Lese- / Mehrbenutzerzugriff sind zugelassen) reduziert.

Weitere softwaretechnische Voraussetzungen für die einwandfreie DAP-Nutzung sind die clientseitigen »Remote Data Services (RDS)«, welche standardmäßig innerhalb MSIE seit Version 4.0 integriert sind sowie der »Microsoft Jet OLE DB Provider« ab Version 4.0 (siehe Kap. 3.3, S. 40), welcher mittels den kostenfreien Datenzugriffs-Softwarekomponenten »MDAC« ⁷⁰ von Microsoft nachinstalliert werden kann und zudem bereits ab Betriebssystemversion Microsoft Windows 2000 (MDAC 2.5) integriert ist. Hingegen wird für die DAP-Verbindung zum DBMS des Microsoft SQL Servers die DB-Softwarekomponente »Microsoft OLE DB Provider« benötigt, auf welche allerdings innerhalb dieser wissenschaftlichen Ausarbeitung, welche Microsoft Access DAP thematisiert, nicht näher eingegangen wird.

Im Falle einer existierenden Microsoft Office (2000 / XP / 2003)-Lizenz bedarf es keiner manuellen Installation obiger Datenbankkomponenten, da diese integrierter Bestandteil dieses Softwarepakets sind.⁷¹ Die DAP-Nutzung setzt aufgrund der Softwareanforderungen aktueller MSIE-Versionen das Betriebssystem »Microsoft Windows« voraus.

1.2.2 ActiveX Data Objects (ADO) / Data Access Objects (DAO)

Das seitens Microsoft im Jahr 1996 entwickelte Softwarekomponenten-Modell mit der Bezeichnung »ActiveX« wurde für die Nutzung Aktiver Inhalte ^⁷² konzipiert und erweitert die so genannten COM -Standards⁷³ von Microsoft, so dass innerhalb sämtlicher Microsoft Office-Softwarekomponenten standardmäßig zur Verfügung stehende Objekte der visuellen Benutzerschnittstelle (so genannte Standardsteuerelemente) um Interaktionsfähigkeiten (beispielsweise ActiveX-integriertes, so genanntes »Kalender-Steuerelement« mit Dateinamen »MSCal.ocx«) ergänzt werden.⁷⁴ Dieses Erweiterungsmodell ist seit der Vertriebseinstellung des MSIE für Macintosh-Systeme ⁷⁵ >, seit dessen letzter Auslieferung im Juli 2003 (Version 5.1.7 für Mac OS 9.x) derzeit ausschließlich für das Betriebssystem »Microsoft Windows« verfügbar.⁷⁶

Innerhalb dieser wissenschaftlichen Ausarbeitung wird die ActiveX-Komponente namens »ActiveX Data Objects« (ADO) thematisiert, welche als Datenbankschnittstelle für den DAP-Verbindungsaufbau zur MSADB einen unverzichtbaren Bestandteil darstellt.

ADO verfügt nicht nur über Verbindungsmöglichkeiten zu relationalen DBS wie MSADB, sondern ermöglicht ebenso den Zugriff auf beliebige Datenformate mittels eines einheitlichen Modells.⁷⁷ Dieses Modell realisi BS-Verbindungen durch die Nutzung des innerhalb seit ADO-Version 2.0 neuartig entwickelten OLE DB-Providers, welcher innerhalb des Kapitels 3.3 (S. 40) in Aufbau sowie Funktionsweise thematisiert wird. Selbiges Kapitel thematisiert ebenfalls die zugehörigen Komponenten seitens ADO.⁷⁸

ADO wird mittels des Betriebssystems (OS) Microsoft Windows 2000 (5.0)/em> ⁷⁹ sowie sämtlichen, nachfolgenden Versionen der OS-Produktreihe »Windows« ⁸⁰ (innerhalb nachfolgender Kapitel werden diese Microsoft OS-Versionen vereint »Win2K/XP/2003/Vista« bezeichnet) von Microsoft mittels der Softwarekomponente

MDAC integriert vertrieben. Alternativ kann das MDAC-Softwarepaket ⁸¹ innerhalb des Bereichs »Microsoft Data Access and Storage Developer Center« online beim Hersteller kostenfrei bezogen werden und grundsätzlich ebenso unter vorherig veröffentlichten Microsoft Windows-Versionen ⁸² installiert werden.⁸³

Mittels Abbildung 16 (S. 43) wird die Eingliederung seitens ADO innerhalb Microsofts Datenprovider-Komponenten veranschaulicht.

Microsofts »Data Access Objects« (DAO) hingegen stellen die Vorgängerkomponenten von ADO dar und realisierten bis zu deren Markteinführung sämtliche Funktionalitäten des DB-Verbindungsaufbaus, wobei diese ins Besondere eine geringere Performance aufwiesen, da ODBC ⁸⁴ als DB-Schnittstelle gegenüber OLE DB bislang unverzichtbar war.⁸⁵

Zudem waren DAO an ein bestimmtes Datenformat gebunden und ermöglichten somit gegenüber ADO keinen Zugriff auf beliebige Datenformate.⁸⁶

1.2.3 Office Web Components (OWC)

Das Softwarepaket »OWC« von Microsoft ist gegenwärtig in Version 11 gemäß obiger, zusammenfassender Versionsspezifikation für »Win2K/XP/2003/Vista« der Microsoft Windows-OS-Reihe verfügbar und ermöglicht (unter Berücksichtigung der in Kap. 1.2.1.3 (S. 14) aufgeführten Lizenzbedingungen) die Interaktion mit Microsoft Office-Dateninhalten (Version 2000 / XP / 2003) mittels des Webbrowsers MSIE⁸⁷.

Die OWC basieren auf ActiveX-Steuerkomponenten (siehe Kap. 1.2.2, S. 16) und ermöglichen somit Zusatzfeatures wie beispielsweise benutzersensitive Sortier-& Filterfunktionalitäten sowie Datenkalkulationen bezüglich MSADB-Zugriffen in Form interaktiver Menüstrukturen innerhalb des MSIE bereitzustellen.⁸⁸ Darüber hinaus stehen mittels OWC weitere, aktive Strukturen zur Benutzerinteraktion zur

Verfügung, um Microsoft Office-Dokumente anderer Anwendungen dieses Softwarepakets für eine Onlineintegration nutzen zu können.

In Anhang 1.2.3/1 (III. Tabellen)⁸⁹ werden sämtliche innerhalb der OWC integrierten ActiveX-Steuerkomponenten tabellarisch aufgezeigt, wobei jede dieser ein eigenständiges Objektmodell abbildet, so dass dieses mittels VBA ⁹⁰ in einer Microsoft Office-Umgebung oder mittels VBScript ⁹¹ / JScript für eine Website optimiert, programmierbar sind.⁹² Durch die Verwendung von VBA lassen sich automatisierte Routinen für den Zugriff auf eine MSADB entwickeln, so dass mittels des nachfolgenden, auszugsweise dargestellten VBA-Quelltextes beispielsweise eine MSADB-Verbindung mittels der ADO-Komponente »OLE DB« (siehe Kap. 3.3, S. 40) herstellt und diese abschließend beendet wird. In Bezug auf DAP-Projekte wird anhand dieses exemplarischen Quelltextes die ADO-Verbindungszeichenfolge (engl. Connection String) ⁹³ des MSADB-Zugriffs ersichtlich, welche ebenso innerhalb des Quelltextes der DAP respektive erweiterter Verbindungsparameter spezifiziert ist (siehe Quelltext 02, S. 24).

Abbildung in dieser Leseprobe nicht enthalten

Quelltext 01: MSADB-ADO-Verbindung mittels VBA (Quelle: Anlehnung an Held, B. (2005), S. 203f.)

Innerhalb dieses Kapitels wird (falls nicht anderweitig erläutert, grundsätzlich in Bezug auf das angewandte Praxisbeispiel dieser wissenschaftlichen Ausarbeitung) der strukturelle Softwareaufbau eines Microsoft Access DBS im Hinblick auf eine DAP-Nutzung, respektive optionaler Gesichtspunkte bezüglich MSADB-Sicherheitkonzepten des DAP-Frontends, strukturiert innerhalb drei Unterkapitel, welche jeweils als Bindeglied zwischen Frontend-& Backend-Softwarestruktur betrachtet werden können, thematisiert. Der strukturelle Aufbau einer für DAP-Zugriff verwendeten MSADB wurde nicht innerhalb des Kapitels 3 (Backend-Softwarestruktur) thematisiert, da innerhalb der vorliegenden wissenschaftlichen Ausarbeitung die DAP-Bereitstellung fokussiert thematisiert wird, so dass die Entwicklungsumgebung der MSADB respektive sämtlicher dazugehöriger DAP clientseitig erfolgen kann, um das fertig gestellte Gesamtprojekt anschließend mittels eines Webservers (siehe Kap. 3.2, S. 33) veröffentlichen zu können.

2.1 DAP-Struktur

Nachfolgend werden notwendige (innerhalb Kap. 2.1.1 bis Kap. 2.1.2.1) sowie optionale (innerhalb Kap. 2.1.2.2) Bestandteile, um eine einwandfreie MSADB-Anbindung mittels DAP realisieren zu können, aufgezeigt.

2.1.1 Access-Datenbankstruktur

Die Struktur der für die DAP verwendeten MSADB weist in ihrer ursprünglichen Form sämtliche Bestandteile respektive Funktionalitäten einer lokalen Microsoft Access-Datenbankanwendung auf – dies wie nachfolgend abgebildet in den meisten praktischen Anwendungsszenarien in Form eines relationalen DBS:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 06: Screenshot – Relationenmodell des Beispiel-DBS »ExecutiveSearch-DB.mdb«

Das Relationenmodell innerhalb obiger Abbildung verdeutlicht den funktionalen Zusammenhang der einzelnen MSADB-Tabellen mit den Namensgebungen »Kunden«, »Projekte«, »Kandidaten« sowie »Projekte_Kandidaten-Zuordnung« im Sinne einer Verknüpfungstabelle zwischen letzteren beiden DB-Tabellen. Diese werden mittels Drag & Drop-Funktionalität innerhalb der Ansicht des Relationenmodells gemäß nachfolgender Abbildung nach erfolgter Erstellung von mehr als einer DB-Tabelle wie folgt realisiert:⁹⁴

Abbildung in dieser Leseprobe nicht enthalten

Abb. 07: Screenshots – Erstellung von Relationsregelungen mittels Microsoft Access 2003

Bei der Realisierung der Online-Bereitstellung von MSADB mittels DAP können sämtliche lokal verwendete Microsoft Access-Formulare durch die DAP-Einbindung abgelöst werden. Die eigentliche DAP-Erstellung (beginnend innerhalb lokaler Entwicklungsumgebung) wird innerhalb des nachfolgenden Kapitels thematisiert.

2.1.2 DAP-Erstellung innerhalb lokaler Entwicklungsumgebung

Microsoft Access ⁹⁵ bietet einen automatisierten Assistenten zur vereinfachten DAP-Erstellung an, welcher jedoch aufgrund seiner vergleichsweise gering strukturierbaren Möglichkeiten der resultierenden DAP an dieser Stelle nicht näher erläutert wird. Stattdessen wird gemäß nachfolgender Abbildung eine neue DAP in der Entwurfsansicht ⁹⁶ erzeugt:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 08: Screenshot – DAP-Erstellung innerhalb lokaler Entwicklungsumgebung

Im sich darauf folglich öffnenden Microsoft Access-Fenster (siehe Abb. 09, S. 22) können im rechten Frame dargestellte DB-Tabellen sowie -Abfragen komplett mittels eines Layout-Assistenten oder auszugsweise in Form separater DB-Felder per Drag & Drop-Funktionalität an die gewünschte Position der im linken Frame befindlichen DAP positioniert werden, wobei ein Rasterhintergrund als Visualisierungshilfe dient.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 09: Screenshot – Feldimport sowie Positionierung von DB-Elementen innerhalb DAP

Im rechten Bearbeitungsframe »Feldliste« innerhalb obiger Abbildung wird zu Beginn der lokale, absolute Datenbankpfad spezifiziert sowie der Status der MSADB-Konnektivität dargestellt. Zudem können sämtliche innerhalb der DAP gemäß obigen beiden Vorgehensweisen integrierten DB-Objekte manuell konfiguriert werden⁹⁷, so dass das gesamte Layout mittels CSS ⁹⁸, die DB-Feldzuordnung sowie Client-Navigationsoptionen dieser an existierende, meist mittels HTML-Frames übergelagerte Websites im Sinne der Corporate Identity (CI) ⁹⁹ der jeweiligen Unternehmung angepasst werden können. Eine Bildschirmaufnahme (nachfolgend gemäß engl. Sprachgebrauch »Screenshot« bezeichnet) der Konfiguration möglicher DAP-Elementeigenschaften ist in Anhang 2.1.2/1 (III. Abbildungen) aufgeführt, wobei Wertebereiche von Parameterfeldern größerer Bedeutsamkeit gelbfarbig hinterlegt dargestellt sind.

Nach erfolgter Speicherung ¹⁰⁰ der neu erstellten DAP im HTML-/ ASP-Dateiformat kann diese vom Ausgangsclientsystem uneingeschränkt verwendet werden, in dem die zuvor gespeicherte DAP im Webbrowser unter Verwendung lokaler, absoluter Pfadangaben geöffnet wird. Für eine DAP-Bereitstellung im Sinne einer Onlineintegration mittels eines Webservers sind weitere verbindungsspezifisch durchzuführende Maßnahmen innerhalb der MSADB-Struktur notwendig, welche in Kapitel 5.2 (S. 51) aufgezeigt werden.

Bereits Abbildung 05 (S. 12) visualisierte den DAP-Aufruf via Intranet mittels des Webbrowsers MSIE (Version 6.0 SP2) in Form der Grundstruktur respektive Datensatznavigator.

Zusätzlich bietet Microsoft Access die Möglichkeit, innerhalb der jeweiligen MSADB zuvor integrierte DAP innerhalb dieser Microsoft Office-Softwarekomponente selbst zu öffnen, um beispielsweise ausschließlich vom lokalen System der ursprünglich ausgehenden MSADB- sowie DAP-Erstellung Datensätze komfortabel editieren zu können oder selbige ohne Zugriff mittels Webbrowser zu öffnen, um Funktionsweisen während der Entwicklungsphase überprüfen zu können.

2.1.2.1 HTML-Datenbestandteil für ADO-Datenbankzugriff

Wird die zuvor mittels der Entwurfsansicht von Microsoft Access erstellte DAP von einem Texteditor geöffnet (Zeichensatz »ANSI« ¹⁰¹ empfohlen), werden die für die DB-Anbindung benötigten ActiveX-Komponenten im Quelltext dieser Datei ersichtlich. Nachfolgender Quelltext verdeutlicht exemplarisch sowie in auszugsweise dargestellter Form die Bestandteile des so genannten »Connection Strings« (dt. Verbindungszeichenfolge, gelbfarbig hinterlegt) innerhalb einer DAP:

Abbildung in dieser Leseprobe nicht enthalten

Quelltext 02: DAP Connection String

DAP-Elemente übergeordneter Bedeutung wurden innerhalb des obigen Quelltextes mittels Fettschrift hervorgehoben. Um zusammengehörige Quelltext-Bestandteile besser ersichtlich darzustellen, wurden neben Syntaxhervorhebungen (engl. Syntax Highlighting) diese ebenfalls in Fettschrift vermerkt. Auf die Einordnung des Connection Strings in Bezug auf ADO-Objekte wird innerhalb des Kapitels 3.3 (S. 40) präziser eingegangen, da diesen Verbindungsparametern für eine DAP-Onlinebereitstellung eine vorrangige Bedeutung zugeteilt ist.

2.1.2.2 ODC-Verbindungsdatei für »Connection String«

Zur nachträglichen Änderung von Datenverbindungsinformationen innerhalb einer Vielzahl von DAP muss unter Verwendung von Microsoft Access-Version 2000 der jeweilige Connection String jeder HTM(L)-Datei separat editiert werden. Seit Microsoft Access-Version 2002 kann eine theoretisch beliebige DAP-Anzahl auf eine Verbindungsdatei referenziert werden, so dass für den späteren Webserver-Upload der MSADB respektive sämtlicher DAP zu aktualisierende Verbindungsinformationen bezüglich des MSADB-Serververzeichnisses lediglich einmalig innerhalb dieser Verbindungsdatei aktualisiert werden müssen oder eine existierende Verbindungsdatei durch eine neue, aktualisierte Version ersetzt wird.

Der Einsatz dieser »Office Data(base) Connection-Dateien« erweist sich als besonders komfortabel, falls das gesamte MSADB-Projekt zahlreiche DAP beinhaltet. ODC-Dateien enthalten Verbindungsinformationen, Schlüsselwörter sowie Beschreibungen für Datenverbindungen und sind gemäß des nachfolgenden, exemplarischen Quelltextes strukturiert:¹⁰³

Abbildung in dieser Leseprobe nicht enthalten

Quelltext 03: ODC-Verbindungsdatei

Innerhalb Microsoft Access-Version 2003 kann die Erstellung von ODC-Verbindungsdateien ¹⁰⁴ mittels eines Assistenten erfolgen, welcher sämtliche anzupassende Verbindungskonstrukte des MSADB-Datenproviders »Microsoft Jet 4.0 OLE DB« (siehe Kap. 3.3, S. 40) für DAP-Zugriffe benutzergeführt zur Verfügung stellt.¹⁰⁵

2.2 Access-Arbeitsgruppensicherheit

Die clientseitig konzipierten Sicherheitsmechanismen wie DB-Verschlüsselung und Vergabe von Zugriffsberechtigungen innerhalb einer MSADB-Mehrbenutzerumgebung (engl. »Multi User Environment«) werden im Folgenden thematisiert, um diese anschließend mittels DAP-Zugriff online veröffentlichen zu können, jedoch für sämtliche DB-Benutzer keinesfalls nicht erforderliche oder selbst fehlerhafte Einschränkungen hervorzurufen. Auf Sicherheitseigenschaften der Backend-Softwarestruktur wird innerhalb der Kapitel 3.2.1 (S. 34) sowie Kapitel 3.2.2 (S. 37) eingegangen.

Die Verschlüsselung (≙Kodierung, engl. Encoding) des gesamten Inhalts einer MSADB (ausgenommen extern im HTML-Format und somit in Form von Binärdaten vorliegende DAP) erfolgt innerhalb der Benutzeroberfläche ¹⁰⁶ von Microsoft Access, so dass die ursprünglich ebenfalls innerhalb Binärdaten eingebetteten DB-Inhalte verschlüsselt werden. Zu beachten ist, dass dieser Mechanismus weder das Öffnen respektive Manipulieren der DB-Inhalte einschränkt und bei der Durchführung der DB-Verschlüsselung ¹⁰⁷ die existierende MSADB innerhalb einer neuen, fortan verschlüsselten MDB-Datei abgespeichert werden muss.¹⁰⁸ Zusätzlich wird die MSADB mittels des obigen Verschlüsselungsvorgangs in komprimierter Form abgespeichert, wobei ein deutlich geringerer Komprimierungsfaktor gegenüber der Durchführung einer manuellen DB-Komprimierung ¹⁰⁹ vorliegt.

Die DB-Entschlüsselung (≙Dekodierung, engl. Decoding) erfolgt mittels gleicher Benutzerschaltflächen von Microsoft Access für die Durchführung obiger DB-Verschlüsselung.

Innerhalb des Anhangs 2.2/1 (III. Quelltexte) sowie Anhangs 2.2/2 (III. Quelltexte) wird mittels Einsicht in den MSADB-Quelltext (MDB-Datei) die Differenzierung der Dateninhalte mit sowie ohne angewandter Verschlüsselungstechnologie verdeutlicht.

Um Datenschutz sowie Datensicherheit einer MSADB zu gewährleisten, muss der unbefugte sowie unzulässige Zugriff ¹¹⁰ auf Datenbestände und Objekte eingeschränkt werden, wobei Microsoft Access für dieses Vorhaben sowohl die Möglichkeit, den Zugriff auf die eigentliche DB als auch auf einzelne Objekte durch die Vergabe differenzierter Zugriffsberechtigungen einzuschränken, bereithält.¹¹¹ Ein globaler Kennwortschutz ¹¹² gemäß den in Microsoft Access (2003) definierten Kennwortspezifikationen ¹¹³ für die gesamte MSADB bietet innerhalb kleinerer Zugriffsumgebungen eine elementare Möglichkeit, unerlaubte Zugriffe auf diese zu unterbinden.¹¹⁴ Jeglicher Zugriff auf Dateninhalte der MSADB (respektive DAP-Zugriff) ist somit erst nach erfolgter Authentifizierung möglich, wobei sämtliche DB-Benutzer auf die Nutzung des gleichen Passworts angewiesen sind und keinerlei Einschränkungen auf Objekt- oder Datensatzebene erzielt werden. Diese sicherheitskritischen Einschränkungen werden zudem aufgrund der freien Verfügbarkeit von Utilities, welche in der Lage sind, gegebenenfalls vergessene MSADB-Globalkennwörter wiederherzustellen, intensiviert, können jedoch durch die Anwendung von Arbeitsgruppenberechtigungen aufgehoben werden.

Zunächst muss für diese Erweiterung der Flexibilität der Benutzerrestriktionen eine neue, so genannte Arbeitsgruppeninformationsdatei ¹¹⁵ (nachfolgend »AGI« bezeichnet) innerhalb Microsoft Access erstellt werden.¹¹⁶ Informationen über existierende Benutzer sowie Benutzergruppen respektive Passwörter werden innerhalb dieser Datei abgelegt, welche Rechte diesen Nutzer(n) /-gruppen gegenüber einzelnen DB-Objekten zugeteilt sind, wird innerhalb der eigentlichen MSADB (MDB-Datei) hinterlegt.¹¹⁷ Nachfolgende Screenshots veranschaulichen auszugsweise (Benutzerschritte 7-8 von 8; siehe Anhang 2.2/3, III. Abbildungen) den benutzergeführten Vorgang des Benutzerdatensicherheits-Assistenten ¹¹⁸, welcher mittels Einsatz von durchgängig detaillierten Funktionserläuterungen zur AGI-Erstellung bereitgestellt wird und somit die Einrichtung einer Microsoft Access-Arbeitsgruppe ermöglicht. Alternativ kann für diesen Vorgang der Arbeitsgruppenadministrator ¹¹⁹ innerhalb Microsoft Access verwendet werden, welcher es ebenso neben der Erstellung einer neuen AGI ermöglicht, einer existierenden als Benutzer oder Administrator beizutreten.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 10: Screenshots – Microsoft Access Benutzerdatensicherheits-Assistent

Resultierende Zugriffsbeschränkungen fordern nach erfolgter Einrichtung der Microsoft Access-Arbeitsgruppe sämtliche Benutzer für MSADB-Zugriff zur Authentifizierung auf. Zudem ist der Zugriff auf die MDB-Datei selbst bei absolut gewährten, lokal zugewiesenen Dateisystemberechtigungen über dieses ohne Authentifizierung fortan nicht mehr möglich, da beim unmittelbaren Aufruf der MSADB versucht wird, das Einlesen der AGI zu umgehen. Diese Auswirkungen verdeutlichen die im Anhang 2.2/4 (III. Abbildungen) aufgeführten Screenshots. Um diesen Missbrauchsvorgang auszuschließen und die zugriffsgeschützte MSADB mittels Authentifizierung jedoch zugleich lokal nutzen zu können, wird seitens Microsoft Access nach erfolgter AGI-Erstellung eine MSADB-Verknüpfungert DBS-Verbindungen durch die Nutzung des innerhalb seit ADO-Version 2.0 neuartig entwickelten OLE DB-Providers, welcher innerhalb des Kapitels 3.3 (S. 40) in Aufbau sowie Funktionsweise thematisiert wird. Selbiges Kapitel thematisiert ebenfalls die zugehörigen Komponenten seitens ADO.⁷⁸

ADO wird mittels des Betriebssystems (OS) Microsoft Windows 2000 (5.0) ⁷⁹ sowie sämtlichen, nachfolgenden Versionen der OS-Produktreihe »Windows« ⁸⁰ (innerhalb nachfolgender Kapitel werden diese Microsoft OS-Versionen vereint »Win2K/XP/2003/Vista« bezeichnet) von Microsoft mittels der Softwarekomponente MDAC integriert vertrieben. Alternativ kann das MDAC-Softwarepaket ⁸¹ innerhalb des Bereichs »Microsoft Data Access and Storage Developer Center« online beim Hersteller kostenfrei bezogen werden und grundsätzlich ebenso unter vorherig veröffentlichten Microsoft Windows-Versionen ⁸² installiert werden.⁸³

Mittels Abbildung 16 (S. 43) wird die Eingliederung seitens ADO innerhalb Microsofts Datenprovider-Komponenten veranschaulicht.

Zudem waren DAO an ein bestimmtes Datenformat gebunden und ermöglichten somit gegenüber ADO keinen Zugriff auf beliebige Datenformate.⁸⁶

1.2.3 Office Web Components (OWC)

Abbildung in dieser Leseprobe nicht enthalten

Quelltext 01: MSADB-ADO-Verbindung mittels VBA (Quelle: Anlehnung an Held, B. (2005), S. 203f.)

2.1 DAP-Struktur

2.1.1 Access-Datenbankstruktur

Abbildung in dieser Leseprobe nicht enthalten

Abb. 06: Screenshot – Relationenmodell des Beispiel-DBS »ExecutiveSearch-DB.mdb«

Abbildung in dieser Leseprobe nicht enthalten

Abb. 07: Screenshots – Erstellung von Relationsregelungen mittels Microsoft Access 2003

2.1.2 DAP-Erstellung innerhalb lokaler Entwicklungsumgebung

Abbildung in dieser Leseprobe nicht enthalten

Abb. 08: Screenshot – DAP-Erstellung innerhalb lokaler Entwicklungsumgebung

Abbildung in dieser Leseprobe nicht enthalten

Abb. 09: Screenshot – Feldimport sowie Positionierung von DB-Elementen innerhalb DAP

Bereits Abbildung 05 (S. 12) visualisierte den DAP-Aufruf via Intranet mittels des Webbrowsers MSIE (Version 6.0 SP2) in Form der Grundstruktur respektive Datensatznavigator.

2.1.2.1 HTML-Datenbestandteil für ADO-Datenbankzugriff

Abbildung in dieser Leseprobe nicht enthalten

Quelltext 02: DAP Connection String

2.1.2.2 ODC-Verbindungsdatei für »Connection String«

Abbildung in dieser Leseprobe nicht enthalten

Quelltext 03: ODC-Verbindungsdatei

2.2 Access-Arbeitsgruppensicherheit

Die DB-Entschlüsselung (≙Dekodierung, engl. Decoding) erfolgt mittels gleicher Benutzerschaltflächen von Microsoft Access für die Durchführung obiger DB-Verschlüsselung.

Ein globaler Kennwortschutz ¹¹² gemäß den in Microsoft Access (2003) definierten Kennwortspezifikationen ¹¹³ für die gesamte MSADB bietet innerhalb kleinerer Zugriffsumgebungen eine elementare Möglichkeit, unerlaubte Zugriffe auf diese zu unterbinden.¹¹⁴ Jeglicher Zugriff auf Dateninhalte der MSADB (respektive DAP-Zugriff) ist somit erst nach erfolgter Authentifizierung möglich, wobei sämtliche DB-Benutzer auf die Nutzung des gleichen Passworts angewiesen sind und keinerlei Einschränkungen auf Objekt- oder Datensatzebene erzielt werden. Diese sicherheitskritischen Einschränkungen werden zudem aufgrund der freien Verfügbarkeit von Utilities, welche in der Lage sind, gegebenenfalls vergessene MSADB-Globalkennwörter wiederherzustellen, intensiviert, können jedoch durch die Anwendung von Arbeitsgruppenberechtigungen aufgehoben werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 10: Screenshots – Microsoft Access Benutzerdatensicherheits-Assistent

gewährten, lokal zugewiesenen Dateisystemberechtigungen über dieses ohne Authentifizierung fortan nicht mehr möglich, da beim unmittelbaren Aufruf der MSADB versucht wird, das Einlesen der AGI zu umgehen. Diese Auswirkungen verdeutlichen die im Anhang 2.2/4 (III. Abbildungen) aufgeführten Screenshots. Um diesen Missbrauchsvorgang auszuschließen und die zugriffsgeschützte MSADB mittels Authentifizierung jedoch zugleich lokal nutzen zu können, wird seitens Microsoft Access nach erfolgter AGI-Erstellung eine MSADB-Verknüpfung ¹²⁰ automatisch angelegt, welche nachfolgende Verknüpfungsstruktur aufweist:

Abbildung in dieser Leseprobe nicht enthalten

Quelltext 04: MSADB-Verknüpfung nach erfolgter AGI-Erstellung

Innerhalb vorheriger Microsoft Access-Softwareversionen in Bezug auf Version 2003 war der Einsatz des Arbeitsgruppen-Administrators ¹²¹ zur AGI-Erstellung erforderlich, so dass auf die zu verwaltende MSADB während dieses Vorgangs keine Zugriffe erfolgen durften und diese geschlossen werden musste.¹²²

Um Datensatz-/ Benutzerkollisionen aufgrund zeitgleich durchgeführter Manipulationsvorgänge, welche als so genannte konkurrierende Benutzerzugriffe bezeichnet werden, auszuschließen, müssen vor einer Onlinebereitstellung der MSADB mittels DAP zusätzlich globale Zugriffsrestriktionen in Form von Datensatzsperrungen ¹²³ vorgenommen werden.¹²⁴

Über obige Sicherheitsmechanismen hinaus existiert innerhalb Microsoft Access die Möglichkeit der Erstellung von MDE -Dateien¹²⁵, welche den gesamten Programmcode respektive gegebenenfalls eingebundener VBA-Module ¹²⁶ schützen, indem ein MSADB-Duplikat (Dateiendung ».mde«) erstellt wird, welchem sämtlicher Quelltext mittels Kompilierung zuvor entnommen wurde.¹²⁷ Da dieses Verfahren ausschließlich geeignet ist, eine MSADB auf Massenspeichermedien (in der Regel optischen Datenträgern) zu veröffentlichen, ist diese Form des DB-Schutzmechanismus nicht Bestandteil von Thematisierungen dieser wissenschaftlichen Ausarbeitung.

2.3 Webbrowser-Erweiterung um OWC

Das dritte Bindeglied (3/3) zwischen Frontend-& Backendsoftware für die einwandfreie Realisation des DAP-Onlinezugriffs bilden die clientseitig erforderlichen, in Kapitel 1.2.3 (S. 17) thematisierten, Microsoft OWC im Sinne eines webbrowser-seitigen Add-Ons ¹²⁸. Diese sind anschließend nach den praktischen Vorgehensweisen sämtlicher Thematiken vorheriger Unterkapitel des aktuellen Hauptkapitels 2 (Frontend-Softwarestruktur) zur DAP-Entwicklung unter den in Kapitel 1.2.3 (S. 17) aufgeführten Voraussetzungen sowie Bedingungen unter Umständen auf sämtlichen Clientsystemen zu installieren, welche DAP-Onlinezugriff erhalten sollen.

Innerhalb dieses Kapitels werden nach vorheriger Realisation des DAP-Frontends in Kapitel 2.1.2 (S. 21) die für eine DAP-Onlinebereitstellung serverseitig notwendigen Komponenten ausgearbeitet.

3.1 Microsoft Windows Server-OS

Als serverseitige Softwarebasis der DAP-Bereitstellung dient das für dieses Vorhaben erforderliche OS »Microsoft Windows«, welches in Bezug auf sicherheitskritische Merkmale im praktischen, produktiven Einsatz in einer Server-Softwarereihe ¹²⁹ ausgeführt werden sollte. Aufgrund quantitativer Restriktionen dieser wissenschaftlichen Ausarbeitung wird innerhalb dieser nicht auf Hardwarebestandteile des Backends eingegangen, welche den Anforderungen der in Kapitel 1.1.2 (S. 06) aufgeführten Kriterien gerecht werden müssen.

Als empfehlenswerte Konfiguration hat sich in der Praxis eine Serverformation erwiesen, bei welcher der Webserver, die MSADB respektive dazugehöriger DAP für Clientzugriffe bereitstellend, in eine Microsoft Windows-Domäne ¹³⁰ (engl. Domain) eingebunden ist, so dass dieser ins Besondere aus Gründen nachlassender Bereitstellungsperformance selbst keine Domainfunktionalitäten eines Domaincontrollers ¹³¹ wahrnimmt. Mittels der Verwendung von Microsoft Windows 2000 / 2003 als Server-OS bildet der integrierte Active Directory Service (ADS) ¹³² eine hierarchische Strukturierung der gesamten Organisationsstrukturen als Domainbestandteile ab und gewährleistet die Benutzerkontenspeicherung innerhalb der Windows-Domäne, welche für eine HTTP-Authentifizierung mittels Webserver ¹³³ in Bezug auf bereitgestellte DAP notwendig ist.¹³⁴ Die logische ADS-Organisationsstruktur ist meist an die strukturellen Gegebenheiten in Bezug auf IT-Ressourcen der jeweiligen Unternehmung angelehnt, so dass eine Gliederung zusammengehöriger Elemente innerhalb so genannter »Organisatorischer Einheiten« (engl. »Organizational Units« ¹³⁵, allg. Kurzform »OU«) erfolgt.¹³⁶ Nachfolgende Abbildung veranschaulicht eine exemplarische ADS-Organisationsstruktur mittels OU:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 11: Microsoft Windows ADS-Organisationsstruktur mittels Organizational Units

(Quelle: Anlehnung an Bünning, U., Krause, J. (2003), S. 338)

Aufgrund in obiger Abbildung dargestellter, aufgeteilter Funktionalitäten der Serverdienste wird der die MSADB sowie DAP bereitstellende Webserver in Form eines Mitgliedsservers (engl. Member Server) in die Windows-Domäne sowie des mittels des/der Domaincontroller(s) verwalteten ADS eingebunden.¹³⁷

Ein Screenshot der MMC-Administrationsoberfläche der ADS-Verwaltung eines Microsoft Windows 2000 Advanced Server Clusters ist in Anhang 3.1/1 (III. Abbildungen) abgebildet.

Das letzte serverseitige Kriterium bezüglich des OS-Einsatzes bildet das verwendete Dateisystem, für welches in Bezug auf sämtliche Server-Festplattenlaufwerke ausschließlich die Technologie »NTFS« ¹³⁸ gewählt werden sollte, um Authentifizierungsmechanismen (siehe Kap. 3.2.2.1, S. 37) des ADS für eine zugriffsgeschützte DAP-Bereitstellung gewährleisten zu können. Zudem benötigt der verwendete Webserver »Microsoft Internet Information Services« (IIS, siehe nachfolgendes Kap. 3.2 innerhalb aktueller Seite) das NTFS-Dateisystem um interne, gesicherte Anmeldeprozeduren durchführen zu können.

3.2 IIS-Webserver-Konfiguration

Der innerhalb der Microsoft Windows 2000-Serverfamilie (IIS-Version 5.0) sowie in sämtlichen Microsoft Windows Server 2003-Varianten (IIS-Version 6.0) integrierte Webserver erfüllt standardmäßig sämtliche Anforderungen für eine DAP-Bereitstellung.¹³⁹ Nach erfolgtem Upload des gesamten MSADB-Projekts respektive dazugehöriger DAP in ein vom Webserver mittels NTFS-Dateisystem erreichbares Serververzeichnis sind allerdings weitere Webserver-Konfigurationsvorgänge für die DAP-Onlinebereitstellung notwendig. Zur Sicherheitsmaximierung ist es empfehlenswert, die MSADB innerhalb eines anderen Verzeichnisses als die mittels des Webservers unmittelbar bereitgestellten DAP zu hinterlegen, um auf NTFS-Dateisystemebene zusätzliche Zugriffsbeschränkungen durchführen zu können. Im Folgenden werden die für dieses Vorhaben notwendigen Konfigurationsschritte exemplarisch anhand von IIS 5.0 innerhalb eines Microsoft Windows 2000 Advanced Server Clusters aufgezeigt:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 05: IIS-Konfigurationsschritte für DAP-Bereitstellung (Quelle: Anlehnung an Microsoft-Support (2006),

o.S.; Papa, J. et al. (1999), S. 516f.)

3.2.1 SSL-Datenübertragung (HTTPS)

Secure Sockets Layer (SSL) stellt seit dessen Entwicklung im Jahr 1994 ein Internetprotokoll für die sitzungsbasierte Verschlüsselung sowie Authentifizierung dar und stellt einen sicheren Datenkanal zwischen zwei Datenendpunkten – in der Regel Client- und Serversystemen – her, um das Abhören, Manipulieren sowie Fälschen von Datenpaketen elektronischer Nachrichtenübermittlungen innerhalb Client-Server-Architekturumgebungen zu unterbinden. SSL arbeitet (als aktuelle Version SSLv3 seit 1995) auf der Transportschicht des OSI-Referenzmodells ¹⁴² und ist vom verwendeten Anwendungsprotokoll ¹⁴³ unabhängig, so dass diese transparent oberhalb von SSL verwendet werden können, wobei sich die Inhalte dieser wissenschaftlichen Ausarbeitung für das ausgewählte DAP-Praxisbeispiel auf das HTTP-Protokoll konzentrieren, welches mittels SSL-Verschlüsselungstechnologien als so genanntes HTTPS-Protokoll (HyperText Transfer Protocol Secure) operiert.¹⁴⁴

Die Client- sowie Serversysteme können in Bezug auf SSL-Verwendung unter zwei Gesichtspunkten betrachtet werden; deren Zuständen (engl. States) sowie den Übergängen zwischen diesen (engl. State Transitions). Der Zustand eines Systems beschreibt dieses zu einem bestimmten Zeitpunkt, hingegen stellen Übergänge Prozesse dar, welche das System in unterschiedliche Zustände versetzen. Die Kombination aller möglichen Zustände sowie Übergänge für ein bestimmtes Objekt wird als »Automat« (engl. State Machine) bezeichnet, so dass SSL über zwei (jeweils client- sowie serverseitig) dieser verfügt. Jeder dieser Datenendpunkte muss die entsprechende Protokollvariante implementieren, um die Interaktion

zwischen den Automaten, welche als so genanntes »Handshake« bezeichnet wird, absolvieren zu können. Das SSL-Handshake-Protokoll ist für die client- sowie serverseitige Koordination der Automaten und somit des SSL-Sitzungsstatus zuständig, so dass eine SSL-Sitzung selbst mehrere sichere Verbindungen umfassen kann und die Teilnehmer mehrere Sitzungen parallel ausführen können.¹⁴⁵ Der Client-Server-Anfragenverlauf für die Initiierung einer mittels SSL gesicherten Datenverbindung ist innerhalb des Anhangs 3.2.1/1 (III. Abbildungen) gemäß englischsprachiger Originalquelle dargestellt, wobei auf weitere Einzelheiten bezüglich SSL-Spezifikationen aufgrund quantitativer Restriktionen dieser wissenschaftlichen Ausarbeitung an dieser Stelle nicht detaillierter eingegangen wird.

Zur übertragungsgesicherten DAP-Bereitstellung muss serverseitig ein SSL-Zertifikat ¹⁴⁶ ausgestellt werden¹⁴⁷, welches nach anschließender Autorisierung eines Zertifikatservers mittels IIS innerhalb der jeweiligen Website integriert wird. Falls die DAP-Bereitstellung innerhalb einer Unternehmung erfolgt, empfiehlt sich die Nutzung der im Server-OS der Microsoft Windows 2000-Serverfamilie sowie in sämtlichen Microsoft Windows Server 2003-Varianten mitgelieferten Zertifikatsdienste ¹⁴⁸ – andernfalls ist ein SSL-Zertifikat einer öffentlichen Zertifizierungsstelle kostenpflichtig zu beziehen oder ein unternehmensintern erstelltes SSL-Zertifikat von dieser zu autorisieren. Da sich das für diese wissenschaftliche Ausarbeitung ausgewählte Praxisbeispiel auf einen unternehmensinternen DAP-Zugriff bezieht sowie zudem uneingeschränkte Clientzugriffe in der Praxis aufgrund inkompatibler Client-Softwaresysteme heterogener Anbieterstrukturen nicht empfehlenswert sind, wird im Folgenden die Nutzung der Microsoft Zertifikatsdienste thematisiert. Nach erfolgter Erstellung des SSL-Zertifikats mittels des IIS-Zertifikats-Assistenten kann dieses unmittelbar von den Microsoft Zertifikatsdiensten autorisiert werden, ohne es an eine öffentliche Zertifizierungsstelle senden zu müssen. Das somit ausgestellte SSL-Zertifikat muss jedoch von sämtlichen Webbrowser-Clients, welche nicht innerhalb der Windows-Domänenstruktur eingebunden sind (einmalig) manuell akzeptiert sowie importiert

werden. Da es sich für empfehlenswert erweist, für den DAP-Zugriff ausschließlich in die unternehmenseigene Windows-Domäne eingebundene Clientsysteme einzusetzen, stellt obige Eigenschaft der Microsoft Zertifikatsdienste keinerlei Einschränkung dar. Bei der Zertifikaterstellung sind ein eindeutiger Zertifikatname (meist angelehnt an Website-Namen sowie deren Portverwendung), ein gemeinsamer Name (voll gekennzeichneter DNS -Name¹⁴⁹ ) sowie die zu verwendende Bitlänge (empfehlenswert ab 512) des Verschlüsselungsalgorithmus festzulegen.

Innerhalb des Anhangs 3.2.1/2 (III. Abbildungen) ist ein Screenshot der webbrowser-basierten Nutzung der Microsoft Zertifikatsdienste unter Microsoft Windows 2000 Server abgebildet.

Nach erfolgter Zertifikatseinbindung innerhalb des IIS kann optional der unverschlüsselte Zugriff mittels HTTP unterbunden werden, indem nachfolgende, restriktive Sicherheitsoptionen ¹⁵⁰ innerhalb dessen Verwaltungsoberfläche aktiviert werden.¹⁵¹

Abbildung in dieser Leseprobe nicht enthalten

Abb. 12: Screenshot – IIS-Zugriffsunterbindung für ungesicherte HTTP-Zugriffe

3.2.2 HTTP-Authentifizierung

Die Benutzerauthentifizierung mittels des Internetprotokolls HTTP bildet die Basis für eine sichere DAP-Bereitstellung und wird seitens Microsoft IIS grundsätzlich in Form serverseitig lokaler oder ADS-integrierter Benutzerkonten unterstützt. Letztere Form der Implementierung, welche in Bezug auf das in dieser wissenschaftlichen Ausarbeitung verwendete Praxisbeispiel Anwendung findet, wird im nachfolgenden Unterkapitel 3.2.2.1 thematisiert.

3.2.2.1 ADS-integrierte Authentifizierung

Nach erfolgter Erstellung der für den DAP-Zugriff vorgesehenen Benutzer innerhalb der MMC-Administrationsoberfläche der ADS-Verwaltung ¹⁵² können mittels Vergabe von serverseitigen NTFS-Berechtigungen Restriktionen für einzelne Verzeichnisse oder Dateien erzielt werden¹⁵³, welche mittels des linksseitig dargestellten Screenshots nachfolgender Abbildung veranschaulicht werden. Für das verwendete Praxisbeispiel bietet es sich an, das gesamte MSADB-Verzeichnis respektive beinhaltender DAP auf Dateisystemebene mittels NTFS vor unerlaubtem Zugriff zu schützen. Zudem ist für dieses Vorhaben mittels Microsoft IIS ausschließlich die Authentifizierungsmethode »Integrierte Windows-Authentifizierung« ¹⁵⁴ zu aktivieren, welche zusätzlich den Grundsätzen des »Single Sign-On« (SSO) ¹⁵⁵ gerecht wird.¹⁵⁶

Alternativ kann der HTTP-Zugriff gegenüber IIS mittels Festlegung von Client-IP-Adressen /-bereichen sowie der Spezifikation von Domänennamen eingeschränkt werden.¹⁵⁷ Aufgrund der, für das innerhalb dieser wissenschaftlichen Ausarbeitung angewandte Praxisbeispiel, ausgewählten ADS-integrierten Authentifizierung, welche sich daher begründet, dass nicht gezwungenermaßen jeder domänenzugehörige Benutzer DAP-Zugriff erhalten soll, werden obige alternative Einschränkungen der Authentifizierung an dieser Stelle nicht thematisiert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 13: Screenshots – NTFS-Berechtigungen des Server-OS & IIS-Authentifizierungsmethoden

3.2.2.2 Htaccess-Authentifizierung

Der innerhalb Unix-Systemen ¹⁵⁸ geläufige Mechanismus für die Realisierung eines HTTP-Passwortschutzes mit der Bezeichnung »htaccess« ist standardmäßig seitens Microsoft IIS nicht implementiert und muss bei Bedarf als IIS-Zusatzmodul (es existieren kostenfreie ISAPI -Filter¹⁵⁹ ) eingebunden werden. Mittels entsprechender Zusatzmodule kann auf obige Vorgehensweise der ADS-Benutzerverwaltung komplett verzichtet werden, da sämtliche Benutzerinformationen mittels (unverschlüsselter) Dateien innerhalb der jeweils zu schützenden Verzeichnisse hinterlegt werden. Diese Eigenschaften stellen jedoch sicherheitsbedenkliche Kriterien bezüglich der DAP-Bereitstellung und dessen Authentifizierungsmethode dar, so dass eine Htaccess-Authentifizierung ausschließlich innerhalb lokaler DAP-Zugriffe (Intranet) eingesetzt werden sollte. In diesem Falle kann innerhalb Microsoft IIS die Authentifizierungsmethode »Integrierte Windows-Authentifizierung« nicht angewandt werden, so dass anonyme Anmeldungen gegenüber sämtlichen zu schützenden Websites des Webservers zugelassen werden müssen, welche mittels eines Htaccess-ISAPI-Filters geschützt werden. Bei einem möglichen Ausfall aufgrund einer

softwareseitigen Fehlfunktion dieses ISAPI-Filters würden somit sämtliche zu schützende Verzeichnisse fortan uneingeschränkt veröffentlicht werden. Nachfolgende Abbildung veranschaulicht die Integration von ISAPI-Filtern als Anwendungserweiterungen innerhalb der Microsoft IIS-Architektur sowie dessen Anwendungs-Isolationsmodus, welcher seit Diensteversion 5.0 zur Systemsicherheit beiträgt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 14: IIS-Architektur zur Anwendungsisolation (Quelle: Anlehnung an o.V. (2004b), S. 302)

Da für das innerhalb dieser wissenschaftlichen Ausarbeitung verwendete Praxisbeispiel sämtliche Clientsysteme in eine Microsoft Windows-Domäne eingebunden sind sowie diese (innerhalb OU gegliedert) respektive deren Benutzer (innerhalb Benutzergruppen gegliedert) als ADS-Objekte verwaltet werden, sind somit sämtliche Benutzerkonten bereits vorhanden, so dass der sicherheitskritische Einsatz von Htaccess-ISAPI-Filtern nicht erforderlich ist. Eine exemplarische Konfiguration eines innerhalb IIS zusätzlich installierten Htaccess-ISAPI-Filters wird in Anhang 3.2.2.2/1 (III. Abbildungen) dargestellt.

3.3 ADO-& OLE DB-Providerarchitektur

Die innerhalb des Kapitels 1.2.2 (S. 16) in dessen grundsätzlichem Kontext gegenüber einer DAP-Bereitstellung thematisierten ADO sind in ein übergeordnetes ADO-Datenzugriffsmodell eingegliedert, welches neben diesen über zwei weitere ADO-Bibliotheken verfügt, so dass sich dieses Zugriffsmodell in nachfolgende drei Komponenten differenziert:¹⁶⁰

Abbildung in dieser Leseprobe nicht enthalten

ADO gliedert sich wiederum in maßgeblich drei Objektsammlungen, welche innerhalb nachfolgender Tabelle aufgeführt sind:¹⁶¹

Abbildung in dieser Leseprobe nicht enthalten

Tab. 06: ADO-Objektbestandteile (Quelle: Anlehnung an Wikipedia (2006b), o.S.; Krause, J. (2001), S. 38)

Für die einwandfreie Nutzung von ADO-Funktionalitäten ist eine Bezugnahme auf »OLE DB« notwendig, da diese Schicht für den Datenquellen-Verbindungsaufbau zuständig ist. Aufgrund der Vielfalt von Möglichkeiten divergenter Datenquellenbezüge wurde seitens Microsoft der Begriff des »Providers« mittels OLE DB eingeführt, so dass entsprechend der Datenempfänger gegenüber des OLE DB-Providers als »Consumer« bezeichnet wird. Somit ist vergleichsweise zu ODBC ein Austausch des Datenproviders ohne Vornehmen von Änderungen am DB-Quelltext unter der Voraussetzung, dass keine speziellen, vom jeweiligen

Datenprovider abhängigen Merkmale angewandt wurden, sichergestellt. Zudem erleichtert die Nutzung des OLE DB-Providers neben dieser Universalität den Zugriff auf Datenquellen, so dass dieser auch eingesetzt wird, falls kein DBMS-Wechsel vorgenommen werden soll.¹⁶² Der mittels ADO stattfindende DAP-Zugriff gegenüber einer MSADB als Datenquelle wird durch Anwendung des innerhalb OLE DB integrierten Standardproviders »Jet OLE DB 4.0« vorgenommen. Auf weitere enthaltene OLE DB-Standardprovider wird an dieser Stelle aufgrund der MSADB-Fokussierung innerhalb dieser wissenschaftlichen Ausarbeitung nicht näher eingegangen.

So genannte Datenlinkdateien zu sämtlichen seitens des OLE DB-Providers unterstützten Datenquellen können anhand einer im Dateisystem neu erstellten Datei mit dazugehöriger Dateiendung ».udl« (engl. Universal Data Link) erstellt werden und speichern sämtliche Verbindungsinformationen des Datenproviders.¹⁶³ Im Gegensatz zu den innerhalb des Kapitels 2.1.2.2 thematisierten ODC-Verbindungsdateien basieren diese auf einem seitens Microsoft für die allgemeine Spezifizierung von Verbindungszeichenfolgen entwickelten Standarddateiformat.¹⁶⁴

Nachfolgende zwei Screenshots (Abb. 15, S. 42) veranschaulichen die Auswahlmöglichkeiten des OLE DB-Providers (#1) sowie die zuständigen Parameter des Connection Strings (#2) für den Verbindungsaufbau zum vorherig definierten Datenprovider nach Öffnen des Eigenschaften-Dialogs der neu erstellten UDL-Datei mittels Microsoft Explorer.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 15: Screenshots – UDL-Datenlinkdateien des OLE DB-Providers

Mittels Einsicht der Datei »Test_DataSource.udl« wird die Struktur für OLE DB-Verbindungsinformationen des Datenproviders der soeben erstellten Datenlinkdatei deutlich, welche der Formatierung des nachfolgenden Quelltextes entspricht:

Abbildung in dieser Leseprobe nicht enthalten

Quelltext 05: UDL-Datenlinkdatei des OLE DB-Providers

Die Einordnung von ADO zwischen OLE DB sowie der Anwendungsschicht zur MSADB-Interaktion mittels höherer Programmiersprachen wird anhand nachfolgender Abbildung 16 (S. 43) aufgezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 16: ADO- / OLE DB-Providerarchitektur (Quelle: Anlehnung an Krause, J. (2001), S. 33)

3.4 Remote Data Services (RDS)

Die bereits in Kapitel 1.2.1.3 (S. 14) thematisierten MDAC beinhalten innerhalb den vorherig aufgeführten ADO die so genannten »Remote Data Services« (anfänglich RDS-Version 2.0) als ADO-Feature seit Auslieferung von MDAC-Version 2.0 im Jahr 1999. RDS ermöglicht es, Informationen von Server-Datenprovidern an Clients zu senden und diese so genannten ADO- Recordsets ¹⁶⁵ nach clientseitiger Manipulation wieder aufzunehmen, ohne für diese Transaktionen eine permanente Datenverbindung aufrechterhalten zu müssen. Diese Technologie ermöglicht die zentrale Bereitstellung von DBS-Inhalten mittels DAP, um diese sowie weitere datenbankgestützte Web-Applikationen, durch Kombination von clientseitigem Daten-Caching (engl. Client Buffering) sowie der eigentlichen Daten-Manipulation, einzusetzen. Eine Reduktion der resultierenden DB-Gesamtanfragen (engl. Database Requests) gegenüber des Webservers (MSADB-Hoster) ist folglich gegeben, so dass bei konstanter Übermittlungsbandbreite die Ausführung einer größeren Anzahl zeitgleich agierender DB-Transaktionen ermöglicht wird.¹⁶⁶ Als weiteres, positives Merkmal der Nutzung von RDS zeichnet sich die Tatsache aus, dass Informationen des Server-DBS nach vollständiger Client-Übermittlung abgerufen werden können, hingegen diese bei Nutzung einer serverseitigen Scriptsprache mittels Webbrowser-Aufruf ausschließlich aufeinander folgend geladen werden können und somit nach möglicherweise unvollständiger, clientseitiger Datenanzeige Fehlentscheidungen des Benutzers resultieren.¹⁶⁷

3.4.1 Funktionsweise & softwareseitige Voraussetzungen

RDS differenziert sich in client- sowie serverseitige Komponenten, da beide dieser Datenendpunkte für den DAP-Zugriff (clientseitig) sowie die DAP-Bereitstellung (serverseitig) auf RDS angewiesen sind. Die clientseitig ausgeführte RDS-Komponente wurde innerhalb des Kapitels 1.2.1.3 (S. 14) im Hinblick auf clientseitige DAP-Anforderungen thematisiert. Da die serverseitige RDS-Komponente für die DAP-Bereitstellung im Gegensatz zu dieser einer weiteren, manuellen Konfiguration bedarf, wird innerhalb des nachfolgenden Unterkapitels 3.4.2 (S. 45) ausschließlich auf die serverseitige RDS-Konfiguration eingegangen. Nachfolgende Abbildung veranschaulicht die schematische Funktionsweise der Server-Komponenten seitens RDS:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 17: Schematische RDS-Funktionsweise (serverseitig) (Quelle: Anlehnung an Microsoft (2006a), o.S.;

Wikipedia (2006d), o.S.)

Die serverseitigen Software-Voraussetzungen für die RDS-Nutzung sind unmittelbar an selbige der Datenzugriffs-Softwarekomponenten »MDAC«, welche in Kapitel 1.2.1.3 (S. 14) thematisiert wurden, gebunden, da mittels diesen RDS als integrierter Bestandteil seitens ADO zur Verfügung gestellt wird.

3.4.2 RDS-Serverkonfiguration

Die Konfiguration von RDS wird nachfolgend exemplarisch im Hinblick auf eine DAP-Bereitstellung für sämtliche enthaltene Varianten der Server-OS-Versionen »Microsoft Windows 2000-Serverfamilie« sowie »Microsoft Windows Server 2003-Versionsreihe« aufgezeigt.

Auf dem mittels IIS die DAP bereitstellenden Webserver muss die Konfigurationsdatei »msdfmap.ini« ¹⁶⁸ bezüglich RDS-Zugriffsparametern editiert werden.¹⁶⁹ Der auszugsweise aufgezeigte Quelltext dieser Datei in Anhang 3.4.2/1 (III. Quelltexte) veranschaulicht diese DB-Zugriffsparameter sowie deren Konfigurationsmöglichkeiten.

4.1 Kollektive Wirkungsweise von Client-/ Server-RDS

RDS gliedert sich gemäß Verwendung in Bezug auf DAP-Zugriffe in nachfolgende drei Objektmodelle, deren client-¹ sowie serverseitiges² Zusammenwirken mittels Abbildung 18 (innerhalb aktueller Seite) aufgezeigt wird.¹⁷⁰

Abbildung in dieser Leseprobe nicht enthalten

Abb. 18: Zusammenwirkung client-/ serverseitiger RDS-Komponenten

(Quelle: Anlehnung an Papa, J. et al. (1999), S. 235)

4.2 HTTP-/ HTTPS-Anfragenverlauf an DAP

Nachfolgende Abbildung verdeutlicht den gesamten Ablauf einer clientseitigen DAP-Anfrage gegenüber eines Webservers, welcher die MSADB unmittelbar bereitstellt und mittels des OLE DB-Providers auf diese zugreift. Da von einer Onlinenutzung über das Internet ausgegangen wird, ist dieser Anfragenverlauf beginnend einer DNS-Anfrage abgebildet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 19: DAP-Anfragenverlauf (HTTP / HTTPS)

4.3 Sicherheitsaspekte der Kooperation

Anhand vorheriger Abbildung 19 (S. 47) wird ersichtlich, dass die gesamte DAP-Kommunikation verbleibenden, technischen Sicherheitsrisiken HTTP(S)-basierter Punkt-zu-Punkt-Verbindungen unterliegt. Dies zeichnet sich ins Besondere durch Spoofing -Attacken¹⁷¹ aus, welche meist gegenüber DNS die Zuordnung zwischen Servernamen und deren dazugehörigen IP-Adressen fälschen (sog. DNS-Spoofing), so dass eine fehlerhafte IP-/ Namensauflösung resultieren kann. Somit können clientseitig verwendete Authentifizierungsdaten seitens des »imitierten« Webservers protokolliert werden.

Mit Hilfe zustandsgesteuerter Datenfilterung innerhalb verwendeter, vorzugsweise hardwareseitiger Firewalls ¹⁷² (engl. »Stateful Inspection Firewalls«) werden Angriffsformen von Spoofing-Attacken eliminiert, da zusätzlich zu angewandten Filterungsmechanismen von Datenpaketen (engl. »Packet Filtering«) der Verbindungsstatus anhand geeigneter Kenndaten wie beispielsweise IP-Adressen und verwandter Ports überwacht wird, so dass neue Datenpakete einem zusammengehörigen, logischen Datenstrom zugeordnet werden können, um über eine mögliche Datenstromsperrung zu entscheiden.¹⁷³ Die Online-Bereitstellung einer MSADB mittels DAP-Einsatz kann mit größtmöglichen Sicherheitsmerkmalen betrieben werden, wenn ins Besondere die in Kapitel 2.2 (S. 25) aufgeführte Access-Arbeitsgruppensicherheit sowie die innerhalb des Kapitels 3.2 (S. 33) serverseitig notwendigen Datenverschlüsselungs- sowie Authentifizierungsmechanismen konsequent umgesetzt werden. Beispielsweise notwendige Veränderungen in Bezug auf DB-Benutzerrestriktionen sind somit innerhalb der Access-AGI möglichst zeitnah umzusetzen. Die jedoch am stärksten zu gewichtenden Sicherheitsmaßnahmen werden serverseitig getroffen, so dass eine MSADB-Verschlüsselung sowie der Kennwortschutz mittels AGI vergleichsweise nur marginalen Datenschutz vor unberechtigtem Zugriff darstellen.

Um das Risiko eines Softwareausfalls serverseitiger Authentifizierungsmechanismen zu minimieren, empfiehlt es sich aufgrund obiger Tatsache eindringlich, sämtliche Serverfunktionalitäten auf minimale Tätigkeitsfelder von Grund auf auszulegen oder bereits ausgeführte entsprechend zu reduzieren, so dass separate Serversysteme für jeweils, bestmöglich maximal eine Bestimmung aufkommen, um möglicherweise unnötig agierende Serverdienste zu deaktivieren, respektive deren zuvor geöffnete Serverports anhand von Firewall-Restriktionen schließen zu können.¹⁷⁴ Auf Konzeptionen sowie Systematiken hardware- sowie softwareseitiger Firewallsysteme wird innerhalb dieser wissenschaftlichen Ausarbeitung aufgrund quantitativer Anforderungen nicht detaillierter eingegangen.

5.1 Zielgrad & Voraussetzungen

Es liegt die Zielsetzung vor, das innerhalb des Vorworts dieser wissenschaftlichen Ausarbeitung definierte Praxisbeispiel funktionsfähig sowie unter Berücksichtigung sämtlicher, innerhalb obiger Kapitel ausgeführter sicherheitskritischer Gesichtspunkte umzusetzen, so dass sich diese exemplarische Vorgehensweise zur DAP-Bereitstellung im Unternehmenseinsatz als praktikabel erweist.

Abbildung in dieser Leseprobe nicht enthalten

Die für die Umsetzung der exemplarischen MSADB-Bereitstellung mittels DAP verwandten Clientsoftware- sowie Serverhardware-/ Softwarekomponenten sind nachfolgend aufgeführt, um generell für eine DAP-Bereitstellung erforderliche Client-/ Serverkomponenten ganzheitlich aufzuzeigen sowie den unmittelbaren Bezug auf die praktisch umgesetzte, exemplarische DAP-Lösung zu verdeutlichen. Auf serverseitige Hardwarekomponenten wird an dieser Stelle nicht fokussiert, da diese mittels universeller Serversysteme gemäß x86-Architektur ¹⁷⁵, basierend auf hybriden CISC/RISC -Prozessoren¹⁷⁶, betrieben werden können. Ebenso sind clientseitige Hardware-Spezifikationen nicht einzugrenzen, da divergente Hardware eingesetzt werden kann, welche den Systemanforderungen der verwendeten Clientsoftware gerecht werden muss.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 20: Clientsoftware-& Serverhardware-/ Softwarekomponenten für exemplarische DAP-

Bereitstellungslösung

5.2 Three Tier-Integration für DAP-Onlinezugriff

Nach erfolgter DAP-Erstellung innerhalb einer lokalen Entwicklungsumgebung (siehe Kap. 2.1.2, S. 21) sind weitere Konfigurationsschritte innerhalb des MSADB-Projektes durchzuführen, so dass ein DAP-Onlinezugriff mittels Webbrowser erfolgen kann. Bislang sind sämtliche MSADB-Parameter standardmäßig seitens Microsoft Access für die lokale MSADB-Nutzung oder für einen lokalen DAP-Zugriff auf diese konfiguriert. Mittels Anpassung nachfolgender Parameter wird nach dem Öffnen der jeweiligen DAP in der Entwurfsansicht festgelegt, dass die MSADB seitens eines Providers für DAP-Zugriffe bereitgestellt wird.¹⁷⁷

Abb. 21: Screenshot – 3T-Integrationsparameter für Microsoft Access DAP

Dem Parameter »UseRemoteProvider« wird für die DAP-Onlinebereitstellung der Wert »Wahr« zugewiesen, hingegen der optionale Parameter »UseXMLData« von der Verwendung externer XML-Daten abhängig ist. Für das angewandte Praxisbeispiel dieser wissenschaftlichen Ausarbeitung werden keine XML-Daten verwendet, so dass dieser Parameter der standardmäßigen Wertzuweisung »Falsch« entspricht.

Nach dem innerhalb des Kapitels 3.2 (S. 33) aufgeführten MSADB-Upload respektive dazugehöriger DAP auf den Webserver sind sämtliche bislang lokal definierte DAP-Pfadangaben innerhalb der MSADB zu aktualisieren, so dass diese Verknüpfungen auf den (meist clientseitigen) DAP-Verwaltungssystemen einwandfrei auf die DAP des Webservers verweisen. Es können, ausgehend von einer DAP-Bereitstellung über das Internet, UNC -Netzwerkfreigaben¹⁷⁸ innerhalb eines LAN mittels VPN-Verbindung oder FTP -/¹⁷⁹ WebDAV -Verbindungen¹⁸⁰ als Ressourcen genutzt werden. Je nach Datenbandbreite des zur Verfügung stehenden Übertragungsmediums sowie der MDB-Dateigröße erweist es sich in der Praxis durchaus als sinnvoll, sämtliche Aktualisierungen der DAP-Onlineverknüpfungen vor dem Upload dieser Datei vorzunehmen, so dass vorerst lediglich sämtliche innerhalb der MSADB referenzierte DAP auf dem Webserver verfügbar sind. Innerhalb dieser wissenschaftlichen Ausarbeitung wurde sich gegen letzteres Verfahren entschieden, da dessen Anwendung nur aufgrund obiger, beider Betrachtungen sinnvoll erscheint und zudem nicht mit einer logischen Struktur zur Online-Implementierung nach lokaler DAP-Entwicklung einhergeht.

5.3 Praxistests

Die für diese wissenschaftliche Ausarbeitung durchgeführten Praxistests wurden in Form von HTTP(S)-Zugriffen mittels Webbrowser heterogener Client-Softwaresysteme gegenüber des innerhalb Kapitel 5.1 (S. 50) definierten Serversystems durchgeführt. Die gesamten DAP-Testzugriffe werden innerhalb drei Kategorien, gemäß jeweiliger Bezeichnung nachfolgender Unterkapitel, differenziert thematisiert.

5.3.1 Sicherheitseigenschaften

Es resultierten während des exemplarisch durchgeführten Webbrowser-Zugriffs nach erfolgter Umsetzung sämtlicher, innerhalb vorheriger Kapitel thematisierter Sicherheitsfeatures, die innerhalb nachfolgender Tabelle aufgeführten DAP-Zugriffsrestriktionen.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 07: Resultierende DAP-Zugriffsrestriktionen mittels Praxistest (DAP-Onlinezugriff)

5.3.2 Daten-Funktionstests & Performance der DAP-Anbindung

Während des Vorgangs zur MSADB-Verbindungsherstellung mittels der serverseitigen ADO-Komponente des OLE DB-Providers nach erstmaligem DAP-Aufruf wird seitens des Webbrowsers der Benutzerhinweis »Datenbindung...« innerhalb der Statuszeile ausgegeben, wobei dieser Vorgang für eine exemplarische Anzahl von 3760 angefragten Datensätzen (Tupel) mit jeweils 18 Feldern (Attributen) eine Bearbeitungszeit von gemessenen ~6.200 Millisekunden via SSL-gesicherter Verbindung beanspruchte. Diese notwendige Ladezeit vor möglicher Verwendung der MSADB mittels DAP ist zudem durch die Übertragung der DB-Dateninhalte seitens Server- gegenüber Client-RDS begründet und ist in erster Linie von den beiden Faktoren »Client-/ Server-Bandbreite der Internetanbindung« sowie maßgeblich »serverseitiger CPU-Rechenleistung« abhängig.

Zusätzlich beanspruchte Rechenleistung für Verschlüsselungsberechnungen (engl. »Cryptographic Computations«) erhöht in diesem Falle die Reaktionszeiten für übertragungsgesicherte DAP-Zugriffe.¹⁸²

Für das angewandte Praxisbeispiel wies der Webserver eine SDSL-Anbindung (4096/4096 kBit/s) sowie angeschlossene Clients eine ADSL-Anbindung (6048/576 kBit/s) auf, so dass der RDS-Transfer nach erstmaligem DAP-Aufruf mit einer theoretischen Übertragungsgeschwindigkeit von 4096 kBit/s erfolgte. DB-Manipulationsvorgänge konnten hingegen nur mit einer theoretischen Übertragungsgeschwindigkeit von 576 kBit/s ausgeführt werden. Nachfolgende

Tabelle stellt die Anbindungsgeschwindigkeiten verschiedenartiger Internetanbindungen in Abhängigkeit der abgefragten DB-Tupel dar. In der Praxis erweist es sich in Bezug auf DAP-Mehrbenutzerzugriffe als kollektiv leistungsmindernd, DB-Tupel ohne angewandte Gruppierungsebenen uneingeschränkt – und somit sämtliche DB-Dateninhalte der jeweiligen Tabelle – abzurufen.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 08: Zeitmessungen für MSADB-Tupelanfragen mittels DAP (SSL-Verbindung)

Benchmark-Ergebnisse externer Utilities bezüglich ADO-/ OLE DB-Verbindungsgeschwindigkeiten werden an dieser Stelle nicht thematisiert, da diese prinzipiell die gesamte client- sowie serverseitige RDS-Kommunikation von DAP-Anfragen unberücksichtigt belassen sowie zudem diese Thematisierung im Kontext alternativer DB-Verbindungsverfahren erfolgen muss, um eine Vergleichsanalyse auswerten zu können.

Das Anlegen neuer Datensätze (SQL-Syntax »INSERT INTO«), die Editierung und anschließende Datensatzspeicherung (SQL-Syntax »UPDATE«) sowie komplette Löschungen dieser (SQL-Syntax »DELETE FROM«) konnten einwandfrei ausgeführt werden. Während dieser Vorgänge zeigte sich, dass die Veränderung von Dateninhalten ausschließlich clientseitige Ressourcen in Anspruch nahm, so dass erst nach Befehlsausführung zu Speicherungs-/ Aktualisierungs- oder Löschvorgängen erneut eine Webserver-Verbindung mittels RDS hergestellt wurde.

Bei dem Versuch, ungültige Wertzuweisungen bezüglich der definierten DB-Felddatentypen mittels DAP-Onlinezugriff vorzunehmen, wird die Speicherung des

jeweiligen DB-Tupels mit Benutzerhinweis auf einen aufgetretenen Typkonvertierungsfehler adäquat abgelehnt.

Nach versuchter Beendigung des Webbrowsers ohne Speicherung zuvor geänderter DB-Feldinhalte erscheint ein Hinweis in Form einer JavaScript-Warnmeldung (JS Alert: »Geänderte Daten wurden noch nicht gespeichert…«), so dass seitens des DAP-Benutzers eine Auswahl über die weitere Vorgehensweise getroffen werden kann. Hingegen wird bei Datensatzmanipulationen nach einem durchgeführten Datensatzwechsel innerhalb selbiger DAP automatisch der gesamte DB-Tupel abgespeichert.

5.3.3 Bilaterale Kompatibilitätsprüfung

Nachfolgende Tabelle bildet die Software-Kompatibilitätsprüfung ab, welche bezüglich des DAP-Onlinezugriffs durchgeführt wurde und veranschaulicht, dass dieser nur im Falle der Verfügbarkeit aktueller Sicherheitsupdates, ohne dass derzeit bekannte, softwareseitige Sicherheitsrisiken auftreten, angewendet werden sollte:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 09: Bilaterale Kompatibilitätsprüfung für DAP-Onlinezugriff mittels divergenter Clientsoftware

6.1 Verbreitungsgrad & Integrationsmöglichkeiten

DAP-Projekte finden in der Praxis derzeit meist innerhalb firmeneigener Intranets Anwendung, so dass deren Nutzung mittels des Internets (ohne VPN-Anbindungen an firmeninternes LAN) seltener anzutreffen ist. Dies liegt maßgeblich an den innerhalb des Kapitels 3.2 (S. 33) sowie in Kapitel 3.4 (S. 43) thematisierten, notwendigen Server-Softwarekonfigurationen zwecks Maximierung der Sicherheitsfeatures einer DAP-Onlinebereitstellung, welche speziell auf die jeweilige Benutzerumgebung des DAP-Zugriffs auszurichten sind. Zudem werden aufgrund existierender, innerhalb des Kapitels 1.2.1.3 (S. 14) thematisierter, heterogener Clientsoftware-Anbieterstrukturen DAP-Projekte in der Regel ausschließlich für einen definierten, eingeschränkten Benutzerkreis online bereitgestellt. Innerhalb unternehmensbezogener IT-Infrastrukturen, welche keine VPN-Anbindung zum firmeninternen LAN zur Verfügung stellen oder kein solches existiert, wird die DAP-Onlinebereitstellung hingegen aufgrund deren Eignung bevorzugt eingesetzt, so dass beispielsweise Außendienstmitarbeiter mit einer zentralisiert bereitgestellten MSADB mittels Webbrowser interagieren können.

Aufgrund der Gegebenheit, dass DAP-Projekte HTML-basiert (respektive Einbindung von ActiveX-Steuerkomponenten) operieren, kann deren Onlinebereitstellung nahezu uneingeschränkt in existierende Internetportale einer Unternehmung integriert werden. In der Praxis empfiehlt sich die Auswahl einer Integrationsform, bei welcher sämtliche DAP-Projekte auf einem separaten Webserver gegenüber anderweitigen, in der Regel übergeordneten Websites bereitgestellt werden. Darüber hinaus erweist es sich aus praktischer Sichtweise als sinnvoll, möglichst identische, serverseitige Scriptsprachen für eine DAP-Integration einzusetzen, um möglicherweise zu übergebende Webseiten-Parameter ungehindert übermitteln und einheitliche Programmiertechniken anwenden zu können sowie den Aufwand dieser möglichst zu minimieren.

Bei einer DAP-Integration innerhalb existierender Internetportale kann auch die bezüglich erforderlicher Benutzerauthentifizierungen ergonomische Strategie des »Single Sign-On« weiterhin berücksichtigt werden.

Möglichkeiten zur Komponentenintegration innerhalb DAP wurden bereits mittels des Kapitels 1.2.1.1 (S. 12) aufgezeigt.

6.2 TCO-Analyse für DAP-Einsatz

Um innerhalb der Unternehmung einen verursachungsgerechten Kostenverlauf für die Nutzung einer DAP-Bereitstellungslösung berücksichtigen zu können, bietet sich die Analyse mittels des »Total Cost of Ownership (TCO)« an. Bei diesem betriebswirtschaftlichen Berechnungsverfahren werden sämtliche, über die Nutzungslaufzeit des jeweiligen Objekts anfallenden, monetären Aufwendungen berücksichtigt, so dass direkte ¹⁸³ sowie indirekte Kostenträger ¹⁸⁴ impliziert kalkuliert werden.¹⁸⁵

In der Praxis hat sich oftmals »ex post« analysierend herausgestellt, dass Kostenfaktoren für Supportleistungen sowie Schulungen als deutlich zu gering bemessen wurden. Die nachfolgende Abbildung zeigt die exemplarische TCO-Kalkulation für die unternehmensseitige Nutzung von Microsoft Office (Version 2003), welches als softwareseitige Basiskomponente für sämtliche DAP-Clientsysteme bei Ausschluss von DAP-Zugriffsrestriktionen (siehe Kap. 2.3, S. 30) operiert. Da in der Regel der Anzahl clientseitiger DAP-Zugriffssysteme eine größere Gewichtung zugeteilt werden kann, als serverseitig notwendige Komponenten, wird an dieser Stelle auszugsweise auf die in Bezug einer DAP-Bereitstellung maßgebend kostenverursachenden, clientseitigen Faktoren innerhalb der TCO-Analyse fokussiert. Zusätzlich sind demzufolge für die TCO-Gesamtkalkulation der DAP-Onlinebereitstellung serverseitige Hard-& Softwarekomponenten sowie Kosten für Internetanbindungen zu berücksichtigen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 22: Screenshot – TCO-Kalkulation für Microsoft Office-Einsatz (Excel Sheet)

(Quelle: Entnahme aus Akademie (2006), o.S.)

Die innerhalb dieser wissenschaftlichen Ausarbeitung thematisierten DAP ermöglichen in Form einer Client-Server-Datenbankarchitektur die Interaktion zwischen via Internet angebundenen Clientsystemen gegenüber zentralen Datenbeständen eines MSADB-Systems. Diese ermöglichen ins Besondere aufgrund deren integrativer Flexibilität eine Einbindung innerhalb unternehmensbezogener, gegebenenfalls existierender IT-Infrastrukturen in geeigneter Weise.

Microsoft Access-Datenbanksysteme lassen sich innerhalb Relationaler DBMS kategorisieren und wurden stetig um Sicherheitskonzepte sowie datenbezogene Funktionalitäten erweitert. Die mittels der Markteinführung von Microsoft Access-Version 2000 seitens Microsoft eingeführten Access-Datenzugriffsseiten ermöglichen erstmals die unmittelbare MSADB-Interaktion ohne Anwendung serverseitiger Scriptsprachen, so dass deren Implementierung aus Sicht des administrativen Aufwands vereinfacht wird. Zudem gewährleistet die vorhandene clientseitige Versionskompatibilität (siehe Kap. 5.3.3, S. 55), dass zentralisiert bereitgestellte DAP-Implementierungen seitens divergenter Unternehmsbereiche genutzt werden können, falls deren softwareseitige Ausstattung Versionsunterschiede aufweist, um möglicherweise anderweitige Applikationen einwandfrei ausführen zu können.

Die innerhalb des Kapitels 3.4 (S. 43) thematisierten RDS, welche maßgebend die DAP-Kommunikationsschnittstelle zwischen Frontend-& Backendsoftwaresystemen abbilden, sind für den Einsatz innerhalb mehrschichtiger DB-Anwendungsarchitekturen konzipiert, so dass eine 3T-Architektur für eine DAP-Bereitstellung mittels dieser konsequent umgesetzt werden kann.¹⁸⁶

Ebenso existieren für mittels DAP bereitgestellte MSADB Migrationsmöglichkeiten zur DBMS-Basis »Microsoft SQL Server«, so dass deren Bedeutung einer Verwendung selbst bei gegebenenfalls nachträglich erforderlichem DBMS-Upgrade gewährleistet bleibt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1.2/1: Screenshot – Manuelle Konfiguration von DAP-Elementeigenschaften

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2/5: Screenshot – Konfigurationseinstellung für MSADB-Datensatzsperrung

Abbildung in dieser Leseprobe nicht enthalten III. Anhang – Abbildungen (Fortsetzung) [Benutzerschritte 1-6 von 8; siehe Abb. 10, S. 28]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2/4: Screenshots – Zugriffsauswirkungen auf mittels AGI geschützte MSADB

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.2.1/1: Establishing Encrypted Communications (SSL)

(Quelle: Anlehnung an Thomas, S. A. (2000), S. 40f.)

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1.2.3/1: OWC integrierte ActiveX-Steuerkomponenten

(Quelle: Entnahme aus http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odeopg/html/deovrworkingwith

officewebcomponents.asp)

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2.1.2.1/1: Zeichenkodierung der Datei »DAP_Stammdaten.html«

(Quelle: Anlehnung an http://de.selfhtml.org/html/referenz/zeichen.htm; http://de.selfhtml.org/xml/regeln/zeichen.htm)

Abbildung in dieser Leseprobe nicht enthalten

III. Anhang – Tabellen (Fortsetzung)

Abbildung in dieser Leseprobe nicht enthalten

These components are supported in the current release:

Abbildung in dieser Leseprobe nicht enthalten

[...]

Excerpt out of 85 pages

Details

Title: Bereitstellung von Microsoft Access-Datenzugriffsseiten mittels Microsoft Windows Server-Technologien
College: University of Applied Sciences Essen
Grade: 1,3
Author: Dipl.-Wirt.-Inf. (FH) Frank Ritter (Author)
Year: 2006
Pages: 85
Catalog Number: V116032
ISBN (eBook): 9783640193103
ISBN (Book): 9783640193295
File size: 6161 KB
Language: German
Keywords: Access-Datenzugriffsseiten, Windows, Server-Technologien, Microsoft Access, Datenzugriffsseite, Datenzugriffsseiten, Windows Server, Datenbank, Datenbanken, Webserver, Bereitstellung, Veröffentlichung, Access

Quote paper: Dipl.-Wirt.-Inf. (FH) Frank Ritter (Author), 2006, Bereitstellung von Microsoft Access-Datenzugriffsseiten mittels Microsoft Windows Server-Technologien, Munich, GRIN Verlag, https://www.grin.com/document/116032

Comments