„Wir leben in einer unsicheren Welt. Märkte, Finanzen, Unternehmenswerte, Menschen, Arbeit, Gesundheit, Kultur, Werte - alles scheint bedroht.“ (Linkies/Off, 2005, S. 21)

Es stimmt wohl, dass viele Bedrohungen auch realen Einfluss auf uns und unser Umfeld haben und das Grundbedürfnis zu mehr Sicherheit und Kontrolle zunimmt (vgl. Linkies/Off, 2005, S. 21). Dabei ist es nicht verwunderlich, dass speziell in der IT-Branche immer mehr auf die Reduzierung von Risiken und Einflüssen bedacht genommen wird.

Andererseits sind die gesetzten Ansprüche und Erwartungen, dem System gegenüber, auch ständig steigend. Immer weitreichendere Vernetzungen immer mehr Flexibilität.

Vernetzungen die im Sinne der Globalisierung vorangetrieben werden um Geschäftspartner (z.B. B2B, B2G) zu verbinden oder mehr Flexibilität um Mitarbeiter neue Kommunikationsmöglichkeiten durch neue Anwendungen zu eröffnen. Letztlich und keineswegs weniger wichtig sind Kunden und Konsumenten die in diverse Systeme integriert werden.

Eine Vernetzung dieser Art bedeutet aber auch, dass es nicht von den einzelnen Anbietern unzählige „private“ Netze und proprietäre Anwendungen geben kann und darf. Vielmehr wird ein Netz, das Internet, für alle Abwicklungen verwendet. Somit fast überflüssig zu erwähnen, dass nur durch ein ausgewogenes Sicherheitskonzept dies zu realisieren ist.

Um nun auf Datawarehouses einzugehen, der Grundgedanke hierbei besteht grundsätzlich in dem offenen, auf große Datenmengen leicht zugänglichen Konzept um in ihrer Gesamtheit darauf zuzugreifen (vgl. Anahory/Murray, 1997, S. 227).

Einen offenen Zugang auf Daten sollte es in der Praxis auf Grund von erforderlichen Sicherheitseinschränkungen allerdings nicht geben. Diese Einschränkungen stellen vielmehr eine Blockade bei der Erfüllung der Aufgaben dar. Im schlimmsten Fall kann dies sogar zum Verlust von Informationen führen und somit das Bild der ursprünglich abgefragten Information verfälschen.

Sicherheitsaspekte sind dennoch nicht zu vernachlässigen und sollte bereits in der Planungsphase berücksichtigt werden um letztendlich auch die Konsistenz der Daten aufrecht zu erhalten.

In diesem Abschnitt wird speziell auf Sicherheitsaspekte beim Einsatz eines Datawarehouse eingegangen und u. a. praktische sowie rechtliche Seiten behandelt.

[zurück zur letzten Seite] [zurück nach oben]

Die zu bestimmenden Anforderungen zielen auf eine umfassende Vorgehensweise und Lösung ab, die die Erkennung von Unternehmenswerten und bestehenden Gefahrenpotentialen und Risiken mit einschließt.

Wie bereits in der Einleitung kurz angeschnitten bietet die Vernetzung und Zusammenarbeit zwischen unterschiedlichen Teilnehmern einige Vorteile, wie etwa Verringerung von Aufwandskosten z.B. durch aggregierten Einkauf, Erhöhung von Erlösen, Preistransparenz, etc. Allerdings ohne den notwendigen Sicherheitsvorkehrungen wären die genannten Vorteile nicht möglich. Um den Umfang der Sicherheitsvorkehrungen mit ein paar Aspekten zu umreißen hier folgende IT-Sicherheitsziele (Linkies/Off, 2005, S. 28f):

„- Verlässlichkeit von Systemen und Netzen

- Verfügbarkeit von Geschäftsinformationen und Daten

- Vertraulichkeit von kommerziellen Aktionen und personenbezogenen Daten

- Integrität von Geschäftsprozessen, Abläufen, Informationen und Personen

- Nichtverwerfbarkeit von Geschäftsaktivitäten beteiligter Partner

- Einhaltung von gesetzlichen und innerbetrieblichen Anforderungen, Einflussfaktoren (Rechtsverbindlichkeit)

- Zurechenbarkeit von Geschäftsvorgängen

- Beherrschbarkeit und Kontrollierbarkeit von Systemen, Anwendern, geschäftlichen Aktionen

- Authentizität von Applikationsdaten und Anwenderaktionen

- Administrierbarkeit von IT-Systemen, Anwendern, Kommunikationspartnern

- Flexibilität von Applikationen, Kommunikationswegen und Anwendern“

Abbildung 1: IT-Sicherheitsziele und Einflusskomponenten
(Quelle: Linkies/Off, 2005, S. 29)

An dieser Stelle eine Einteilung von Risiken in fünf Typen (vgl. Linkies/Off, 2005, S. 34ff):

Verlustrisiko:

Wie der Name schon erkennen lässt, fallen unter diesen Typ alle Risikopotentiale, bei denen wichtige Informationen verloren gehen können. Ebenso fallen unbefugte Zugriffe durch Dritte oder Diebstahl von Hardware darunter. Daraus resultierend können erhebliche Probleme in bezug auf Image, etc. entstehen.

Prozessrisiko:

Prozessrisiken bestehen, wenn unternehmensinterne Prozesse oder etwaige Transaktionen beeinflusst werden, sprich wenn es zum Auftreten von Störungen und Ausfällen kommt oder eine Kommunikation während der Übertragung verändert wird. Dies kann unter Umständen zu Unterbrechung der Produktion führen.

Technisches Risiko:

Dazu zählen technische Gefahrenpotentiale von IT-Systemen. Hierbei ist zu berücksichtigen, dass bereits ein Fehler in einzelnen Systemkomponenten, wie z.B. in Speichermedien oder der physikalischen Netzwerkverkabelung, zu umfangreichen Problemen führen können.

Legales Risiko:

Durch immer neue gesetzliche Regelungen ergibt sich für Unternehmer ein so genanntes legales Risiko, da dieser den neuen gesetzlichen Bestimmungen verpflichtet ist, unter Umständen diese jedoch noch nicht umgesetzt hat.

Organisatorisches Risiko:

Diese entstehen oft durch fehlende Kenntnisse der Mitarbeiter über organisatorische Abläufe.

Um mögliche Gefährdungspotentiale zu verringern, seien hier zwei Varianten der Kontrolle von Risiken kurz erwähnt. Vorgelagerte Kontrollen sollen Risiken von vorn herein vermeiden bzw. reduzieren, wie z.B. durch eine klare Aufschlüsselung der Vergabe von Benutzerrechten. Nachgelagerte Kontrollen dienen dem Erkennen von bereits eingetretenen Beeinträchtigungen. Dadurch besteht die Möglichkeit Probleme in Zukunft zu vermeiden.

[zurück zur letzten Seite] [zurück nach oben]

Nun ist es unbedingt erforderlich in der Planungsphase von Systemen sich Gedanken bzgl. Sicherheits- und Revisionsansprüchen an ein verwendetes Datawarehouse zu machen.

Da erhöhte Sicherheit, bspw. durch Überprüfung von Berechtigungen, mit dem Bedarf höherer Rechenleistung einhergeht sollte auch darauf rechtzeitig Rücksicht genommen werden.

Nachträglich in ein System Sicherheitseinschränkungen zu integrieren ist meist sehr komplex, zeitaufwendig und nicht zuletzt kostenintensiv. So sollten auch zukünftige Revisionen bzw. Änderungen in der Datenstruktur, neue Datenquellen und auch ein Benutzerwechsel in Betracht gezogen werden.

Um diesen Anforderung gerecht zu werden, müssen einerseits Kenntnisse über den Zweck des Datawarehouse andererseits über die Geschäftsabläufe wie auch der Unternehmensstruktur bestehen.

Es gibt unterschiedliche Herangehensweisen an das Thema Sicherheit, wie z.B. über den Anwenderzugang bzw. den Datenzugang (vgl. Anahory/Murray, 1997, S. 228ff).

[zurück zur letzten Seite] [zurück nach oben]

Hierbei steht die Sensibilität der Daten im Vordergrund. Äußerst sensible Daten, wie beispielsweise Gehaltsaufstellungen erfordern höheren Schutz als etwaige Produktpreislisten.

Die Daten werden somit kategorisiert inwieweit sie schützenswert bzw. bedeutsam für das Unternehmen sind. Ebenso ist es möglich, Daten nach ihrer Funktion zu bewerten. Der Zugriff auf diese wird nach der Notwendigkeit des Anwenders um seine Aufgabe zu erfüllen bestimmt und vereinfacht die Kategorisierung der Daten.

Darüber hinaus stellt sich die Frage in wie weit folgende Überlegungen für eine Zugangs-Berechtigung wesentlich sind (Anahory/Murray, 1997, S. 229) :

„1. Kann ein Analytiker Daten über sein eigenes Konto sehen?

2. Kann ein Analytiker Daten über die Konten anderer Angestellter sehen?

3. Kann ein Analytiker Daten über das Konto seines Chefs sehen?

4. Kann ein Analytiker Daten über andere Mitglieder seines Teams sehen?“

Daten über das eigene Konto einzusehen ist im Allgemeinen nicht problematisch. Anders kann es allerdings bei der Berechtigung auf die Daten des Chefs bzw. die der anderen Mitglieder zuzugreifen aussehen. Hierbei kann es zu unerwünschtem internen Konkurrenzkampf kommen.

[zurück zur letzten Seite] [zurück nach oben]

Eine andere Möglichkeit ist, den Zugang über die Gruppierung von Anwendern zu realisieren.

Dies kann einerseits in Bezug auf Abteilungen, Sektionen Gruppen, etc. vorgenommen werden, andererseits auch mit Bedacht auf die jeweiligen Aufgabenbereiche der Benutzer erfolgen. So kann der Umfang der Berechtigungen, wie in folgenden Abbildungen, beispielsweise in Abteilungen Verkauf und Marketing bzw. für einzelne Mitarbeiter oder aber nach deren Aufgabenbereiche eingerichtet werden.

Abbildung 1: Zugriffshierachie
(Quelle: Anahory/Murray, 1997, S. 230)

Abbildung 2: Nach Aufgaben sortierte Zugriffshierachie
(Quelle: Anahory/Murray, 1997, S. 231)

Es ist auch möglich, beide Varianten zu kombinieren. So wird zuerst in der Berechtigung die Unternehmensstruktur und in weiterer Folge, beispielsweise innerhalb einer Abteilung, eine spezielle Benutzer-Erlaubnis abgebildet. Solche Berechtigungsstrukturen können in der Regel sehr komplex und umfangreich ausfallen.

[zurück zur letzten Seite] [zurück nach oben]

Nr.	Klassifikation	Beschreibung
1.	Gefahrenpotential	Zugriff auf Datenbankressourcen wurde nicht eingeschränkt: Auf wichtige Datenbankressourcen unter dem Betriebssystem UNIX wurden die Zugriffsrechte für die Betriebssystembenutzer nicht eingeschränkt.
	Auswirkung	Durch eine fehlende Beschränkung der Zugriffsrechte (speziell für das Betriebssystem UNIX) auf wichtige Datenbankressourcen können Zugriffsbeschränkungen innerhalb des Datenbankmanagementsystems umgangen werden. Auf diese Weise kann die Datenbankintegrität kompromittiert werden. Eventuell ist ein unautorisierter manipulativer Zugriff auf Tabellen möglich.
	Risiko ohne Kontrolle	Extrem hoch
	Kontrolle	Einschränkung der Zugriffsrechte auf die Datenbankressourcen unter UNIX.
	Risiko mit Kontrolle	Normal
2.	Gefahrenpotential	Keine Passwortänderung: Die Passwörter für Standard-Datenbankbenutzer (technische Benutzer), die für den impersonierten Zugriff auf die Datenbank verwendet werden, wurden nicht geändert bzw. wurden nicht gesetzt.
	Auswirkung	Falls die Standardpasswörter nicht geändert werden, kann mithilfe des Datenbankmanagementsystems bzw. ODBC, JDBC eine Verbindung zur Datenbank aufgebaut werden. Da die Standard-Datenbankbenutzer in der Regel mit Administratorrechten ausgestattet sind bzw. im Falle von SAP-Systemen auch sein müssen, können alle Tabellen und Objekte eingesehen und unautorisiert modifiziert werden.
	Risiko ohne Kontrolle	Extrem hoch
	Kontrolle	Die Passwörter der Standard-Datenbankbenutzer müssen in jedem Fall geändert werden. Die Komplexität des Passwortes muss entsprechend hoch gewählt werden. Falls möglich, ist eine mit dem Betriebssystem integrierte Authentisierung mithilfe eines Betriebssystembenutzers (z.B. <sapsid>) zu wählen.
	Risiko mit Kontrolle	Normal
3.	Gefahrenpotential	Nicht benötigte Datenbankbenutzereinträge: Im Datenbankmanagementsystem sind nicht benötigte Datenbankbenutzer (z.B. Demo-Benutzer) eingetragen.
	Auswirkung	Nicht benötigte Datenbankbenutzer können für eine Kompromittierung der gesamten Datenbank durch einen Angreifer ausgenutzt werden. Durch Ausnutzung dieser Schwachstelle kann ein Angreifer eventuell höhere Rechte erlangen und dadurch die Tabellen in der Datenbank einsehen bzw. auch unautorisiert manipulieren.
	Risiko ohne Kontrolle	Hoch
	Kontrolle	Entfernung von nicht benötigten Datenbankbenutzereinträgen im Datenbankmanagementsystem.
	Risiko mit Kontrolle	Normal
4.	Gefahrenpotential	Ungesichertes Datenbankmanagementsystem: Der Zugriff auf das Datenbankmanagementsystem ist nicht hinreichend gesichert, z.B. ist der Oracle Listener so konfiguriert, dass eine Anmeldung an der Datenbank von jedem Rechner in einem weniger vertrauensvollen Netzwerksegment möglich ist.
	Auswirkung	Durch einen möglichen ungesicherten Zugriff auf die Datenbank können wiederum Tabellen und darin gespeicherte Geschäftsdaten kompromittiert werden.
	Risiko ohne Kontrolle	Hoch
	Kontrolle	Einschränkung des Datenbankmanagementzugriffs und Absichern des Zugriffs aus einem weniger vertrauensvollen Netzwerksegment auf den Datenbankserver durch Firewalls.
	Risiko mit Kontrolle	Normal
5.	Gefahrenpotential	Fehlendes Datenbanksicherungskonzept: Es fehlt eines Strategie und ein Konzept zur Sicherung und Archivierung der Datenbank. Eventuell werden gesetzliche Vorgaben (z.B. aus der GoBS) missachtet.
	Auswirkung	Ein fehlendes Datenbanksicherungskonzept kann zu einem teilweisen Verlust oder sogar zum kompletten Verlust aller Geschäftsdaten führen. Durch Missachtung gesetzlicher Vorgaben können Strafzahlungen erhoben werden.
	Risiko ohne Kontrolle	Exterm hoch
	Kontrolle	Konzeption und Aufbau eines Datenbank-sicherungskonzeptes.
	Risiko mit Kontrolle	Gering
6.	Gefahrenpotential	Fehlendes Upgrade-Konzept: Es fehlt eine Konzeption für ein regelmäßiges Upgrade-Konzept für die Datenbank, um die neuesten Sicherheitspatches zu implementieren.
	Auswirkung	Sicherheitsschwachstellen werden zu spät durch einen entsprechenden Patch beseitigt. Auf diese Weise kann diese Schwachstelle durch einen potentiellen Angreifer ausgenutzt werden. Letztendlich kann die Datenbank kompromittiert werden.
	Risiko ohne Kontrolle	Hoch
	Kontrolle	Konzeption und Implementierung eines Upgrade-Konzeptes für die Datenbank.
	Risiko mit Kontrolle	Gering

Tabelle1: Risiken und Kontrollen für den Datenbankserver
(Quelle: Linkies/Off, 2005, S. 464ff)

[zurück zur letzten Seite] [zurück nach oben]

An dieser Stelle nochmals festgehalten, Überlegungen für die Umsetzungen von Berechtigung erfordern ein frühzeitiges Handeln, um zukünftigen Anforderungen an das System gerecht zu werden. Des weiteren sei hier kurz bemerkt, dass Sicherheit nicht nur im Datawarehouse, sondern bereits im Umfeld, sprich u. a. mit der Netzwerkanbindung beginnt. Mehr dazu in einem späteren Abschnitt.

[zurück zur letzten Seite] [zurück nach oben]

Wie bereits in der Einführung erwähnt ist die Notwendigkeit von zukünftigen Revisionen zu definieren (vgl. Anahory/Murray, 1997, S. 235). Die bei einem Datawarehouse dabei anfallenden Datenmengen sollen keineswegs unterschätzt werden und die entstehende zeitliche und ressourcenerschöpfende Arbeit nur dort durchgeführt werden, wo sie unbedingt erforderlich ist.

Da Revisionsanforderungen unterschiedlich ausfallen können, folgende Liste einer grundsätzlichen Kategorisierung (Anahory/Murray, 1997, S. 235) :

„- Aufbau von Verbindungen

- Abbau von Verbindungen

- Datenzugriff

- Datenveränderung“

Innerhalb der jeweiligen Kategorisierung kann weiters zwischen Revisionen von Erfolgen bzw. Misserfolgen unterschieden werden. Bei Revisionen von Misserfolgen werden beispielsweise unautorisierte Zugriffe bzw. Datenveränderungen unter Augenschein genommen.

Wesentlich bei Revisionen ist es, zu klären wann und warum diese durchgeführt werden soll. Es macht hierbei keinen Sinn, Revisionen von Datawarehouses obligatorisch durchzuführen ohne ein Motiv dafür zu haben. Revisionen sollten grundsätzlich nur dann abgewickelt werden, wenn sie wirklich notwendig sind.

[zurück zur letzten Seite] [zurück nach oben]

Bei der Feststellung der Sicherheitsanforderungen an das Datawarehouse sollte man sich ebenso mit dem zum Einsatz kommenden Netzwerk und dessen Anforderungen befassen (vgl. Anahory/Murray, 1997, S. 236).

Wichtig sind die hierbei entstehenden Überlegungen. Müssen Daten beim Transfer über das Netzwerk verschlüsselt werden und welche Wege durch das Netzwerk werden verwendet.

Die zur Verschlüsselung notwendige Rechnerleistung ist dabei nicht zu unterschätzen und kann, wie auch der zeitliche Aufwand, mitunter sehr hoch ausfallen. Bei der Überlegung über welche Wege sollen Daten übertragen werden, müssen mögliche Engpässe in der Infrastruktur oder auch Abhängigkeit von einzelnen Hardwarekomponenten berücksichtigt werden.

Ein, an dieser Sichtweise, anknüpfender und weiterführender Gedanke sollte sich mit der Frage beschäftigen, in wieweit Daten extern via E-Mail, Webmail, Instant Messaging oder ähnlichem versandt werden (vgl. IT Security Turns Inside Out).

[zurück zur letzten Seite] [zurück nach oben]

Das Datawarehouse und die darin aufzunehmenden bzw. enthaltenen Daten unterliegen natürlich auch rechtlichen Anforderungen (vgl. Anahory/Murray, 1997, S. 234).

Dabei können speziell beim Sammeln von Kundendaten, den Betreiber des Datawarehouses div. gesetzliche Verpflichtungen bzw. rechtliche Beschränkungen treffen. Diesbzgl. Gesetze können von Land zu Land variieren und würden den Umfang dieser DWH-Einführung sprengen.

In jedem Fall, ob bei der Verwendung von Daten für Trendanalysen oder der Weiterverarbeitung zur Unterstützung des Kundensupports, sollte wohl überlegt mit Informationen umgegangen werden.

Auch diese Anforderungen sind bereits bei der Planungsphase zu beachten und klar zu definieren.

[zurück zur letzten Seite] [zurück nach oben]

Für das Thema Dokumentation von Sicherheits- und Revisionsanforderungen und ihren Teilbereichen ist es empfehlenswert folgende zwei Grundregeln einzuhalten (Linkies/Off, 2005, S. 49):

„- Die Anzahl der Dokumente sollte minimiert werden.

- Die Dokumente sollten alle notwendigen Informationen beinhalten.“

Unter notwendige Informationen werden die genauen Details zu Zugriffsberechtigungen bzgl. Daten- und Anwenderzugang, Hardware- und Netzwerkanforderungen und Revisionsanforderungen festgehalten.

Weiters gehören zu einer vollständigen Dokumentation Bestimmungen bzw. Richtlinien zum Schutz der Unternehmenswerte und eine Beschreibung der Sicherheits- und Monitorprozesse.

Nur durch eine dementsprechend aktuelle und vollständige Dokumentation kann ein dauerhafter Betrieb gewährleistet werden.

[zurück zur letzten Seite] [zurück nach oben]

erstellt am: 23.01.2006 | Elmar Huber Themeneinstieg